Client Automation - Automating software package delivery in the OSIM process
search cancel

Client Automation - Automating software package delivery in the OSIM process

book

Article ID: 9923

calendar_today

Updated On:

Products

CA Client Automation - IT Client Manager CA Client Automation CA Client Automation - Software Delivery

Issue/Introduction

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:

  • Populating the user defined fields on a PC as part of the OSIM process.
  • Adding an additional parameterized file to the OSImage.
  • Speeding up the registration of assets when the standard collect job takes too long.

In addition this method also requires:

  • Creating a Query based computer group with an associated software policy.
  • creating a software package to reset flag once the packages are deployed.

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.

Environment

Client Automation - All Versions

Resolution

Modifying the OS Image

Populating the user defined fields on a PC as part of the OSIM process

  • There are four user defined fields that can be set on the PC

  • Whilst they have specific titles on the agent when reported back to the server they are more generic.

  • These fields are reported as part of the CAF registration process. In order to populate these during an OSIM job we need to provide the file userdata.xml in the folder C:\program files (x86)\CA\DSM\Agent\units\00000001.
    • for example to define "User data 4: OSIM-Group-1" the xml would be

      • <userdata>
      • <user_item_4>OSIM-Group-1</user_item_4>
      • </userdata>

  • The xml file needs to be copied to the agent after the OS has been installed. To do this place the userdata.xml file in the "oeminst" folder of the osimage and then edit custom.cmd (also found in oeminst).
  • Locate the :installr12 section in custom.cmd and replace it with the code in the file found here. When done it should look as below.

  • These additions will copy the the userdata.xml file into the correct location on the agent so that the data is read when the agent first registers. It is important that the data is included in the initial registration to allow the automation we will configure later to work efficiently.

 

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.

  • First add a new parameter called "OSIMBuildGroup" to the image as per the documentation.
    • Make this new parameter of type "MapListExt". The various types of parameters are documented here.
    • Here is a sample parameter definition.

      • [OSIMBuildGroup]
      • Trans=yes
      • Type=MapListExt
      • MaxLength=128
      • Comment=Define automated software install if required
      • item="" "No build group defined"
      • item=OSIM-Group-1 "OSIM Build Group 1"
      • item=OSIM-Group-2 "OSIM Build Group 2"

  • Now we need to parameterize the userdata.xml file.

    • Edit the file and change <user_item_4>OSIM-Group-1</user_item_4> to <user_item_4>$OSIMBuildGroup$</user_item_4>

  • Finally we need to tell OSIM to pragmatically replace the parameter at run time.
    • open the <imagename>.cmd file in the camenu folder.
    • Find the section .

      • if exist c:\canpc.dat (
      •  x:\amd64\ca-osim\preplace.exe -8 -i c:\canpc.dat C:\windows\panther\unattend\unattend.xml
      •  x:\amd64\ca-osim\preplace.exe -i c:\canpc.dat c:\oeminst\custom.cmd
      •  x:\amd64\ca-osim\preplace.exe -i c:\canpc.dat c:\oeminst\oobecustom.cmd
      • ) else (
      •  echo ERROR: The parameter file doesn't exist 
      •  goto error
      • )

    • and modify it to read

      • if exist c:\canpc.dat (
      •  x:\amd64\ca-osim\preplace.exe -8 -i c:\canpc.dat C:\windows\panther\unattend\unattend.xml
      •  x:\amd64\ca-osim\preplace.exe -i c:\canpc.dat c:\oeminst\custom.cmd
      •  x:\amd64\ca-osim\preplace.exe -i c:\canpc.dat c:\oeminst\oobecustom.cmd
      • if exist c:\oeminst\userdata.xml (
      • x:\amd64\ca-osim\preplace.exe -i c:\canpc.dat c:\oeminst\userdata.xml
      • )
      • ) else (
      •  echo ERROR: The parameter file doesn't exist 
      •  goto error
      • )

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.

  • Run the update wizard to add this new parameter to the OS image.
    • Update the image registration in a domain only.

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:

  • If you have not yet deployed the OSImage package to your SS, unregister the OS Image and prior to making these edits.
    • When you then register the OSImage again select the following
      • Register both the image data and the image package
      • This will create a Software package that contains the full OSImage including the modifications made above

  • If you have already deployed the OSImage package to your SS then running the update wizard will not pick up the edits to the camenu or images folders.
    • In this case you will need to tell the update wizard about the added files so it can include them in the update software package.
      • Run the update wizard as above to register the new parameter into the DSM Explorer.
      • Now edit the file osinfo.ini located in ....\CA\DSM\Server\var\managedPC\images\<imagename>
        • locate the [update] section and add the following 3 lines

          • addfile1=camenu\win10x64-img.cmd
          • addfile2=images\win10x64-img\win10x64-img\oeminst\custom.cmd
          • addfile3=images\win10x64-img\win10x64-img\oeminst\userdata.xml

      • Run the update wizard again this time selecting
        • Update the image registration in a domain only
          • Register the image package in the Software Package Library only.
      • When the wizard completes you will have a new Software Package <imagename>_update and if you examine the source you will see it contains the 3 added files in the correct folders.
        • Deploy this update package to your SS and the updated files will be added to the OSImage already.

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.

  • Expand Control Panel - Engines - All Engines and select the engine that currently runs the collect job for the SS
    • In the Task list click on the collect job to display its properties
    • Select the Collect tab and deselect Asset Registration.

    • Click OK

Now we will create a new engine instance and collect task to process the asset registrations

  • Right Click on the System Engine and select "Create New Instance".
    • Name the new instance something meaningful e.g. registration.
  • Right click on the new engine instance and select "Add New Task".
    • Follow the wizard to create a new collect task for the desired SS..
      • Be sure to deselect all tasks except for "Asset Registration".



    • Set the Scheduling to Always run.



  • By default an engine will wait 60 seconds between each job. To speed this up we will change it to 5 seconds.
    • Right click on the registration engine.
    • Select properties.
    • Select the Advanced tab.
    • Define a 5 second interval between jobs.



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

  • In DSM Explorer right click on Queries and select "New".
  • Select "Computers" as the target type.
  • Expand "General Information" and select "computer".
  • Expand "User Defined Fields" and select "Field 4" (we defined field 4 in userdata.xml above).
  • Use the operator = and type the flag you wish to query e.g. 
    • OSIM-Group-1
  • Click OK and you should see the following in the query designer.



  • Click OK again and name your query e.g "OSIM Build Group 1"
  • Repeat for all the desired build flags.

Create a Group based on the query

  • Right click on "Computers and Users" and select "New Group..."
  • Name your group e.g. "OSIM Build Group 1".
  • Select the Query tab and select the query to be associated with this group.
    • Do not select a specific Engine to evaluate this. Leave with the default of <All Engines>.
  • Repeat creating a group for each flag and associate with the corresponding 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

  • for each package find the install procedure, open its properties and check "Exclude from RAC"

Now we can create the Software Policies

  • In DSM Explorer Expand "Policies", right click on "Software Based" and select "New Software Policy..."
  • Follow the Wizard.
    • add the desired packages for this policy.
    • Select the relevant Group created previously for this policy.
    • Uncheck "Seal and activate Software Policy"
    • Check "Open the advanced software policy settings dialog............"
    • click "Finish
  • Define the following advanced settings
    • Software Policy tab
      • Batch Job Execution.......
      • Ignore cascading install........
    • Automation tab
      • Set-up and activate jobs .......
      • Evaluate Dynamic Groups........
    • Evaluation tab
      • Enable ad-hoc target evaluation
        • only when new (or reinstalled) targets report their inventory

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.

  • Click OK and the new policy is created but not yet sealed.
  • Repeat creating a policy for each Build group.

Currently we have the following in place:

  1. Define flag when building new PC.
  2. Computer added to build group based upon flag.
  3. Software installed.

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

  • Using a text editor create a file called "unset OSIM build Flag.cmd" containing the following 3 lines:

    • sd_acmd.exe UserInfo Comment=
    • caf register
    • exit

  • Create a new Software Package and use this cmd as the install procedure.
  • Exclude this procedure from RAC
  • Add this to each software policy ensuring it is the last in the order of execution.

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.

Additional Information

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.

 

Attachments

1558534198296TEC1951225.zip get_app
Powered by Wolken Software