The development team behind OCS-NG created a so-called OCS Inventory NG Packager utility. This tool works together with the Windows service internals and is able to register anything as a service, even without administrator privileges. The admin account is specified prior to creating the package. The installer will run under that account. It was designed to package the OcsLogin.exe launcher according to your agent preference.

Once the package is installed, it's called OcsPackage.exe, and it means that we can hook it up on the OCS-NG communication server. The final step is deploying the package.

Let's not get ahead of ourselves now. We can download the packager from the same OCS NG repository on SourceForge. Check the following URL:

http://sourceforge.net/projects/ocsinventory/files/OCS%20Inventory%20NG

The latest packager at the time of writing is the 1.02. Download and extract it.

Inside we will find only one executable. Its interface is straightforward.

The Exe file is going to be the OcsAgentSetup.exe. We discussed its command-line switches, and we know that it is much more than just a GUI installation wizard. It can be scripted, run in silent mode, with specific commands, and thus, it's exactly what we need.

We can use SSL certificates to check the server prior deployment. This means that clients are given certificates which can act as fingerprints to authenticate the deployment server. This is critical as package deployment and remote command execution is practically an open door for exploits and malicious undertakings. In this way, we can always be sure that the source server of packages is not compromised. Clients can test this themselves.

Finally, the last step, which is the most important one, is that we need to specify the account through which the installer runs. In the case of a domain, this account must have administrative privileges on the local machine to install new services and copy files. As such, it's recommended to create a special account dedicated to this task that has the necessary privileges.

Using the domain admin account is dangerous, but it works (please refer to the Microsoft service security planning guide linked earlier in this chapter). It depends on how the overall security is tightened and monitored. It can be any other account with local administrative rights. The same applies in the case of workstations.

The next window asks for the destination where the packaged end result is placed.

The OcsPackage.exe needs to be uploaded on the OCS-NG server. We're going to do this by logging into the administration console. Keep in mind that this time, we won't get into each and every functionality that lies there because that is what the next chapter will cover. Right now we are taking an action-oriented approach.

We point our browser to the OCS-NG administration console interface's URL:

http://ocsinventory-ng/ocsreports

In the previous path, ocsinventory-ng stands for the OCS-NG server name. If we haven't changed our admin user and password yet, then we log in with admin and admin. On the Users toolbar, we can find the predefined users, edit them, and set up new ones. Once we are in, we will navigate to the agent toolbar, it's the fourth icon on the right (the longest) toolbar. It looks like two gears working.

Alright, now we're already seeing the path to the source of the package we just created. On uploading the OcsPackage.exe, the agent is practically ready to be deployed.This means that the OCS-NG communication server can serve the requests of agents. Deployment happens in the following fashion:

As you can see, the OCS-NG Packager can be used to install and set up other files as well. The OcsLauncher.exe just checks whether an agent exists on the client machine. If it finds it installed, it executes it. If no agent can be found, it proceeds to request one from the OCS-NG server, and depending on the specified flags it sets up either of the agent types.

It downloads the entire OcsPackage.exe just as it was uploaded on the OCS-NG server. Therefore, if we want to build in more files, then we can use the Packager's Select Additional Files option to add them. In this way, once it logs into the specified account, along with the OcsAgentSetup.exe, the other files are downloaded to the client machine.

We can also remotely execute Visual Basic script files (.vbs). We add the Cscript.exe path to the Exe file. Add our .vbs script via the Select Additional Files option, and finally write script.vbs /B in the command-line options.

It is beyond the scope of this book to explain what Active Directory is about or what group policies are about. As such, we will assume the following; if we want to use these deployment methodologies, we can deduce that we have some kind of familiarity with these Microsoft administration technologies.

If you are managing such a tiny environment that these concepts are unknown to you, but still want to get your feet wet with remote agent deployment, then we wholeheartedly recommend the PsExec solution that's going to be covered in the following pages.

Here we're going to create a login script and enforce it via group policies.

Now that we're past the general assumptions, let's launch the Active Directory Users and Computers MMC snap-in. Start | Run| dsa.msc. Find your Active Directory domain or organizational unit that you are managing. For the sake of keeping things simple and uniform, let's call our domain mydomain.com. Once you selected your domain, right-click and select Properties.

Out of those tabs, let's navigate to the Group Policy tab. There we can find our policies (if there are any). We can either edit an existing one or create a new one. Whichever option we pick, there are two main categories, namely, computer policies and user policies. The former is computer specific, and in our case, they are executed when the computer starts up. The latter is user specific, and requires some user to log in.

Nowadays, there is a new MMC snap-in called gpmc.msc—Group Policy Management. This tool is installed by default on Windows Server 2008 operating systems but not on Windows 2003 or earlier. This snap-in gives us a slightly more advanced interface. It lists the forest, inside which we can pick our domain mydomain.com.

Here we are going to find our organization units and Group Policy Objects. When we expand the GPO field by clicking on the '-' (minus), all of our policies will be displayed (if there are any). We can also monitor which ones are enforced, which are linked, and so on. This is also the place of security filtering, such as deciding whether the policy applies to specific users, groups, or computers. Under most circumstances, this is Authenticated Users.

Without trying to sound like an Active Directory tutorial, let's focus on how to edit such a policy with this new GPMC snap-in. Right-click on one of the existing policies or create a new one. The Group Policy Management Editor will pop up as a new window. From this point onwards, everything remains the same. We have computer and user policies too.

Scripts that are inside computer policies are called Startup and Shutdown scripts. These are executed on computer startup and shutdown. What matters to us right now is the startup category. That's where we should place the inventory agent.

The scripts that are inside user policies are called Logon and Logoff scripts. The reason for that is self-explanatory, these are executed when a user either logs in or logs off. The agent can be deployed this way too, though in most situations it's not an ideal option.

The following screenshot gives us a sense of where to find these scripts inside the GPO:

Now, let's right-click on the Scripts (Startup/Shutdown) right inside the Windows Settings tree. We pick Startup and select Properties. A new window will be displayed, and we can see our already existing startup scripts (if there are any). Before we head over to add a new script, click on the Show Files button. It will bring up an Explorer window showing the destination where these scripts are located.

This is where we are going to copy our OcsLogon.exe launcher. Let's not forget that there are situations when this file gets renamed. If that's the case, then copy the renamed launcher. Once the file is stored there, you can click on Add on the Startup Scripts window. This will bring up a new window where you can specify the path of the new script. As we just copied there, you can easily specify this.

The command-line arguments can be added to the special parameters field. These are additionally added at the end of the launcher, just like if it were done manually. This means that if we want to install the service type agent, now is the time to specify the /install command-line switch. Also add the /S, /DEBUG, and other parameters.

The following screenshot shows a simplified version of the tasks that were mentioned:

Should we opt for the login scripts instead of startup scripts, it can be done in a similar fashion. Instead of messing with computer policies, we fiddle with user policies.

Keep in mind that deploying scripts via Active Directory GPOs is not the only solution.

At first glance, these two solutions are similar. The previous modality was based on policies. This meant we could enforce different policies on Organizational Units(OUs) based on whatever criteria we wanted. This has given us flexibility, which is necessary in specific cases, but there are those situations when we don't want to use group policies. For example, if we have just one domain, and we're looking for a solution to deploy the agents based on users.

This time, we want to set up a session login script across our domain.

The first step is to copy the OcsLogon.exe launcher to a place on the network that is going to be readable by everyone from the domain. It's advised to set up that location as shared to Authenticated Users. The script that we're going to create will download the launcher from this path. That's why it is critical to be available (readable).

The script can be either a traditional batch file or vbscript. What we want to do is quite trivial. We want to execute the launcher from that path using a few command-line switches.

Here's an example where the renamed launcher is on file-serv at the ocsagent-kit folder:

\\file-serv\ocsagent-kit\10.10.10.05.exe /debug /np /install /s

This line can be thrown into a batch script, with an @echo off in the first line in order to prevent echoing on the display. In this way, no output will be presented, just a flashing command/terminal box at most. The extension must be .bat as expected.

Once the script is done, the next step is to copy into our primary domain controller's scripts folder. This is along the lines of the c:\windows\sysvol\sysvol\<mydomain.com>\scripts path.

Now, fire up the Active Directory Users and Computers MMC snap-in (dsa.msc). Find your users within the domain tree, and then link the scripts to each of them. We can do this by clicking Properties, and then we have the following alternatives. We either set it up as a User Profile | Logon Script: [specify the path] using Browse, or at the Environment tab, we check the box Start the following program at logon and add our script.

As you can see, this modality is much more recommended when there are just a handful of users. We pick those users, set the agent up as a login script, and we are done with it. We can add the creation of response files, such as create ok.txt on some predetermined folder. The script checks whether this ok.txt exists, and if yes, then the agent is already installed, and it is not executed anymore. You can also check this manually.

Command execution, via scripts, opens up lots of doors. In corporate environments, usually there are login and logoff scripts, and users are categorized into different organizational units. We might also have dozens of groups, but it's not that hard to decide which options are better. The best practice is to use a combination of the previously mentioned solutions. Furthermore, we can mix in a little bit of PsExec. This is what we're going to cover right now.