Considerations when upgrading OSD to version 12.1 and later

BMC recommends following considerations before upgrading OSD to version 12.1 and later:

Upgrade process

As usual there are two possible upgrade mechanisms:

• Automatic agent upgrade:
  If this option is activated, all your OSD agents are also automatically upgraded to version 12.1 and later. All your projects are still functional, you only need to rebuild them to make them available for deployment again.

• Manual agent upgrade:
  If the automatic option is not activated, and you are rolling out the upgrade manually to your agents, all your OSD agents are still on version 12.0 after your master upgrade, and they are no longer functional. All your current projects are still fully functional and might even run, if so defined. However, it is impossible to make changes to them, or to view any of their data, including the progress of any running installations. If a deployment was in progress when the upgrade started, it failed. This is shown in the status of the device, once the respective OSD agent is upgrade, and in the deployment log.
  BMC strongly recommends to take all your projects offline before starting the upgrade process of the master and subsequently the agents.

  Note:

  As usual, the OSD upgrade mechanism removes all generated files for a clean start. All OSD objects are kept in the database, but all projects require a rebuild.

Consolidating to one OSD Manager

With version 12.1 a number of architectural changes were introduced to the operating system deployment:

• In version 12.0 and earlier many OSD Managers could be defined. Version 12.1 and later favors an architecture with only one OSD Manager and any number of image repositories.
• The OSD proxies that were used alongside the OSD Managers disappear and are automatically converted into Network Boot Listeners that are taking over the proxy's role.

For more information on the new architecture see OSD architecture and components .

Client Management versions prior to 12.1 used an architecture with more than one OSD Manager. When upgrading to version 12.1 or later, you can still keep all your OSD Managers, but you might want to analyze the advantages of the new architecture before deciding to stay with your existing architecture or move to the new one. Following are two examples, one where a move appears advantageous, and a second, where it is probably preferable to stay with the existing architecture:

1. An implementation uses the same projects and images throughout the entire infrastructure. This situation might arise when a company has a limited set of OS images for a limited set of hardware.
   There are 50 OSD Managers spread all over the globe on the different physical sites, and on them are copies of these projects. In this case, it would seem preferable to move to the new architecture and to one OSD Manager. This OSD Manager would then handle all the delta updates, instead of using an external tool to propagate the changes made to the OS images. When deleting all OSD Managers but one, all projects and images located on these other managers are lost. However, this is not a problem, because they are all duplicates of the same data that is still located on the main OSD Manager. All previously existing OSD Managers, which were deleted, can then be added as image repositories and can synchronize the same projects.
2. For an environment that has multiple OSD Managers storing many different projects and images, a migration to the new architecture might not be recommendable. These projects are different for a reason, or are under the supervision of different administrators, and therefore cannot be easily unified. However, the export and import of single projects might make it feasible to reduce the number of OSD Managers and condense the local architectures on individual sites.

Limitations

Windows versions before Windows Vista (XP, XP 64-bit, 2003, 2003 R2, and so on) are no longer supported as OSD Managers due to Windows ADK restrictions, as the Windows ADK cannot be installed on these operating systems. In the new architecture these devices can only have the role of image repository. Former OSD Managers on these operating systems are still shown in the console as OSD Managers, but they are not usable any more. Projects existing on these devices can be exported via the File > Export menu of the console and be imported to other OSD Managers.

Driver by model upgrade side-effects

Sometimes, for recent hardware, not all drivers could be automatically detected by the WinPE WMI script. A workaround was created, which involves determining the model ID of the computer, creating a folder with that name on a Samba share, dumping the drivers in it. After the OSD WIM install is run, the model ID of the machine is compared to this folder and its content is copied to the OSD destination folder on the installed system. On the next boot, Windows installs its components using the local OSD driver folder.

This process is now integrated in the OSD functionality and automated to some extent. However, the workaround does not work anymore, you need to execute the following procedure to make it work again:

1. Copy or move all your driver folders from the Samba share to the new dedicated location on the OSD Manager: <driver cache root>\bymodel\<model name>. You can do so directly under the Drivers by Model node.

   Note:

   The driver cache folder can be changed by the user to another location in the OSD configuration interface in the console, but the content is not moved to the new location, this is a manual operation.

2. Rebuild the projects, concerned by the modified driver folders.

Example:

The previous path was \\10.5.159.46\drivers\Optiplex GX280 . It must be copied manually to the default driver cache folder and becomes C:\Program Files\BMC Software\Client\data\OsDeployment\drivers\bymodel\Optiplex GX280.

Delta versus project transfer

Client Management now uses a stream database module to transfer as little data as possible across networks. This might be especially advantageous in networks with low bandwidth parts.

This new module allows the OSD agent to decide, if it is more advantageous, to transfer the complete new updated version of an object, or if the delta between the last version, currently stored on the transfer target, and the new version is smaller, and thus should be transferred instead. In this case, several deltas might be transferred instead of the complete new version.

Related topics

• Upgrading to Windows ADK and installing Windows ADK
• Upgrading OSD to v12.1 and later by consolidating to one OSD Manager
• Partially upgrading the OSD architecture to version 12.1 and later