Operating System Installation Management (OSIM) is a very powerful tool for the automation of installing or reinstalling the OS of a PC.
However this is only half the story. Once the PC is built there is often the requirement to deploy a standard set of applications. The applications required may also differ depending on the business function of the PC.
Whilst standard Software Policies can be used for this, the time it takes to deploy the packages is often longer than desired delaying the overall build process.
This document will describe a method to automate this in a much more timely fashion thus speeding up the overall time to build the PC. We will use the user defined fields of the agent to set a flag denoting that the PC is rebuilt and also which set of applications the PC should receive.
There are several advanced steps to this method which are:
In addition this method also requires:
It is assumed that the required OS and Boot images are already created and OSIM is functioning as expected. And that you have a good understanding of OSIM and how the OSimages are structured.
Client Automation - All Versions
Modifying the OS Image
Populating the user defined fields on a PC as part of the OSIM process
Adding an additional parameterized file to the OSImage
To allow you to define the correct flag as part of the OS job we need to parameterize the userdata.xml file.
Note the above assumes that the OSImage is a 64 bit OSImage. If it was a 32 bit OSImage then x:\amd64 would be x:\i386.
This additional code will substitute the parameter into userdata.xml on the PC.
When updated the new parameter will be available in DSM Explorer.
This will work fine if the Domain Manager is your only boot server. If you have remote boot servers you will need to create the software package containing these updates that you can deploy to your scalability servers, you have 2 options:
Be very careful NOT to select any of the options that update the image with the current template files. This will erase all the modifications you have made to your image.
Speeding up the registration of assets when the standard collect job takes too long.
Registration of an asset is carried out by the engine when the SS collect job runs. This works fine for normal operations but when automating the build process this could introduce a considerable delay.
If the engine is responsible for multiple collect jobs and there are 100's or 1000's of agents the delay from when to agent registers to the SS and this is collected and registered into the mdb could be considerable.
To overcome this we can split the registration process from the rest of the collect process (Inventory, Discovery, Usage.....) and assign this to a separate engine instance configured to run much more frequently than the collect job.
First we remove the asset registration task from the original collect job.
Now we will create a new engine instance and collect task to process the asset registrations
Now the original collect task will do the heavy lifting of processing the inventory etc and the new engine and collect task will process new registrations very quickly.
Configuring the automation
With the above in place we are now able to set a flag on a computer when it is built via OSIM and process the registration of this new PC very quickly. We now need to setup the Groups, Queries and policies in Client Automation in order to automate the delivery of packages.
Create a query to select only the PC's with one of the build flags
Create a Group based on the query
Now when a computer is built via OSIM and one of the flags is set the computer will be added to the corresponding computer group automatically when it is registered.
Create the Software Policies
Before we can create the policy we need to decide which packages will be included and deactivate RAC on the relevant procedures. Failure to do so will cause the PC to be "locked by RAC" if the PC is rebuilt and thus prevent the automation we are configuring from deploying the software in the policy
Now we can create the Software Policies
This last setting is why we need the userdata file in place before the agent first registers as we will only evaluate the policy for the first registration event. If the userdata was not reported with the first registration the policy will not be activated. If ad-hoc was evaluated every time targets reported their inventory this would put a massive load on the server and adversely impact performance.
Currently we have the following in place:
What we are missing is the removal of the flag once all the required packages are installed. Doing so will remove the computer from the build group and ensure the policy is not reapplied.
To clear the flag we need to create a new software package that will run a simple script on the PC
When this last procedure is run it remove the flag from the user data field. The agent is then told to register again and when this is processed the computer is removed from the build group.
After the initial setup it is possible to add additional build groups without having to update the OSImage.
We defined the parameter as a MapListExt which means we can add new items without having to edit default.ini and update the image
Simply doble click the parameter when planning an OS job and type the new flag. This will then be stored in the DB and can be selected at will for any other target. You cannot define a different parameter name and value like we did when we edited default.ini. If you wish to add the new flag to the image and use a different string for the name and value then simply edit default.ini and update the image as before.