OSD architecture and components

The new OSD architecture is based on one single OSD Manager and image repositories at each physical site with one network boot listener per subnet. The image below shows an example for such an architecture:

Operating system deployment in the BMC Client Management - Software Distribution requires a number of different components and objects working together:

OSD agent

An OSD agent is any type of BCM agent on which the OSD module is loaded. This means it can either be the OSD Manager, if it is a Windows device, or an Image Repository or a Network Boot Listener or both, for any type of operating system.

OSD manager

The OSD Manager is a device within a subnet that is responsible for the creation of the deployment projects and their publication. It is recommended to only have one OSD Manager, but multiple OSD Managers are possible. The OSD Manager is by default also Image Repository and Network Boot Listener. The Image Repository role is mandatory as it is the parent of all the subsequent image repositories. The network boot listener for the subnet is optional and can be deactivated.

Note:

For legacy installations, if you have more than one OSD Manager, these can still exist in parallel, but it is recommended to consolidate them into one single OSD Manager and replace the other OSD Managers with image repositories.

Image repository

Image repositories are the bridge between the OSD Manager and the targets. They are assigned OSD objects (projects, images and so on), that is, the repositories store the objects in their cache and thus require large amounts of disk space to store the data. Each repository should have several Network Boot Listeners, one per subnet. It is recommended to use relays as the image repositories. The parent of an image repository should be either the OSD Manager, or another repository in more complex environments. An image repository can be deactivated if there is no child to the node, it then becomes a network boot listener.

Network boot listener

Formerly called OSD Proxy. It cannot have children. The network boot listener for the subnet is optional and can be deactivated. If the image repository role is activated as well, it becomes an image repository and can have children. The network boot listener executes the actual deployment: it informs the targets and provides the link to the source data for the installation.

Storage device

This is a device with network shares on which the OS setup files, WIM images and custom images to be deployed can be stored. Be aware, that Windows XP has a limit for concurrent SMB connections per share so a Linux server with a samba share or a Windows Server Edition is advised. The storage device can be an independent device or it can be located on the DHCP or TFTP server.

NAMPUser

The BCM agent is a service and runs as the LocalSystem user. To access the Windows network shares defined in the Images objects using Samba, the OSD module creates a local administrator called NAMPUser. The NAMPUser account enables the BCM service to use the network share APIs required to access and check the specified UNC path and credentials. It is also used to cache the image content on the OSD Manager.

The NAMPUser account also performs the assisted installation of the Windows ADK on the OSD Manager. Running the OSD Manager on a Windows Domain Controller might prevent the NAMPUser from installing Windows ADK correctly; BMC recommends that you install the Windows ADK manually On Windows Domain Controllers. Other operations by the NAMPUser are not affected.

For enhanced security, the NAMPUser password is generated each time it is used by the OSD Manager; it obeys strong rules regarding complexity (upper case, lower case, numbers, special characters, and length between 18 and 22 characters). The password is never stored in the BCM agent.

If the NAMPUser is deleted from the system, the BCM agent automatically recreates it when the OSD module is reloaded.

Projects

The project is the central point which collects all the different elements that are required for an operating system deployment. Via these elements, it receives all the information which is then compiled during the project build process. After this process has terminated with success, the project becomes active and published, that is, all required information is made available to the target devices for installation.

OSD wizard

BMC Client Management - Software Distribution also provides a wizard which guides you through the different steps of creating the individual OSD components or even a complete OSD project for all different types of distribution.

Was this page helpful? Yes No Submitting... Thank you

Comments