Prerequisites for OSD

To be able to execute the examples described for operating system deployment, a number of general Client Management and OS deployment prerequisites must be fulfilled, which are listed in the following two paragraphs. The examples then guide you step by step through the different possible procedures installing a new operating system on a remote device or creating a new image to be deployed. The procedures, however, only refer to parameters that need to be filled in or must be modified, any parameters of which the prepopulated default values are used are not mentioned here. You can find detailed information about these parameters in the knowledge center of this functionality.

Before actually deploying a new operating system to new devices in your network, you must ensure that the components and devices listed here are available and configured.

Note:

Be aware that operating systems cannot be deployed to devices with IPv6 addresses.

OSD Manager

The OSD Manager is a device of the CM infrastructure, it must have a Windows operating system. By default, it is the master, as it is for our examples.

If your master is a Linux device, you must first select another device as the OSD Manager.

The following prerequisites apply to this device:

The OSD Manager must have a BCM agent installed and have the OSD module loaded.
The operating system must be one of the following:
- Windows 7 Service Pack 1
- Windows 7 family
- Windows Server 2008 R2 family
- Windows 8 family
- Windows 8.1 family
- Windows 2012 family
- Windows 2012 R2 64 bit
- Windows 10 family
- Windows 2016 family
- Windows 2019 family
The Windows ADK (Windows Assessment and Deployment Kit) must be installed on the OSD Manager/TFTP server device.
If you want to manually install it, you can download it from the Microsoft site at https://developer.microsoft.com/en-us/windows/hardware/windows-assessment-deployment-kit . On the Microsoft website you can find official installation instructions for the setup.
The Configuration node allows you to automatically download and install the new Windows ADK.
By default the OSD Manager is an Image Repository and a Network Boot Listener so having the OSD Manager is enough to make a deployment.

Image repository

At least one image repository must be defined, it can be the same device as the master. It is recommended to have one image repository per physical location. The operating system of the image repository can be any of the supported systems.

Network boot listener

At least one network boot listener must be defined, it can be the same device as the image repository. It is recommended to have one network boot listener per subnet. The operating system of the network boot listener can be any of the supported systems.

For hardware requirements for the OSD Manager, Image Repository, and Network Boot Listener, you can refer to Hardware-requirements. Consider the requirements in the Relay column depending on the number of nodes.

The main requirement is to have a fast processor for building projects and sufficient disk space to store images (operating system distribution approximately 5 GB per image).

Sysprep deployment

The Sysprep deployment has a number of limitations as follows:

a uniprocessor/core image can only be deployed on other uniprocessor/core devices.
a multiprocessor/core image can only be deployed on other multiprocessor/core devices.
the operating system language is fixed by the initial capture.
no static IP address can be used.
the administrator logon/password of the captured system must be the same as the one specified in the deployment parameters in the unattended information tab. If this is not the case an invalid login or password Windows error is generated.

Storage device

At least one device with network shares on which the OS setup, image and ghost are to be deployed can be stored. For this you can use the OSD Manager or the DHCP server, however, BMC recommends that you use a dedicated device. In our examples we deploy the 32-bit version of Windows 10 therefore these setup and image files must be copied to a share called /Win10, a ghost image is to be copied to a directory called /Ghosts32. This directory must contain the ghost executable file and the ghost image. 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.

Target devices

The target devices must have PXE boot set as the first boot device in the BIOS.

Ghost images

If you want to use ghost images the following prerequisites apply:

the ghost32.exe (executable found in the install folder of the win32 install) and the GHOSTCDR.DLL library must be located in the folder where the .iso image is stored.
the account specified in the image configuration must be the same specified in the OSD manager configuration (Windows limitation).

This example restores a device that was installed via a ghost.

Path: \\hotline\OS Setup\personnalise\GhostOsdSupport261009\ghost.GHO

Command line: ghost32.exe -clone,mode=restore,src=ghost.GHO,dst=1:0 -SURE

The path mounts a network share ( W: ) which is used to find ghost32.exe and ghost.gho (do not use UNC paths, these don't work). The dst option indicates which disk/partition to restore the image on.