Nomad in a depot – part 1

1E-Nomad

Operating system deployment (OSD) is extremely successful with Nomad when there is no local Distribution Point. The ConfigMgr OSD content (operating system WIM, drivers, applications, and packages) is copied or pre-cached using Nomad onto computers in the site beforehand. When computers are refreshed or replaced, or new computers are built during a migration or as business as usual the OSD content stored locally on computers in the site can be used instead of the content being pulled across the WAN during OSD.

A popular deployment method is to deliver computers with an OEM image installed to a build centre or depot, install the custom company operating system, and then ship the built computers to remote sites. The aim at the depot is to build large numbers of computers at the same time. Let’s look at the most efficient way of achieving this by starting with the required infrastructure.

The computers will need to be PXE booted into WINPE where the OSD task sequence is started, a PXE infrastructure will be required. We don’t want the OSD content to be pulled across the WAN from a remote Distribution Point, the OSD content will need to be hosted in the depot location.

Option one:

Commission a Windows server to host a ConfigMgr PXE enabled Distribution Point (DP) and distribute the OSD content to the DP. Note that Internet Information Services (IIS) and Windows Deployment Services (WDS) are required.

Option two:

Commission a Windows server with Nomad and PXE Everywhere and pre-cache the OSD content into the Nomad cache. A Windows server operating system (OS) is required to allow Nomad unlimited concurrent connections. Nomad on a desktop OS allows six concurrent connections.

The specification of the Windows server for both options needs to include fast hard disks to ensure that the read requests are processed in a timely fashion. A gigabit network connection would increase the throughput of the data and ensure quick build times. This type of performance can be obtained from an entry level server hardware.

Option two will reduce the management of IIS and WDS, enable the use of a single OSD task sequence for all locations, and deliver continuity to the OSD process. Designing continuity into the build process will ensure the build engineers and support staff are able to troubleshoot OSD issues at any location as all locations use the same build method.

In the second part of this blog series I will discuss OSD task sequence design and Nomad configuration for a depot.

Read more about Nomad at /nomad/, or follow our LinkedIn Showcase page.

Share this post

Share this post on your favourite social media platform.

Find this article useful?

If so please click here