Fully automating a deployment process is arguably much simpler with the support of Microsoft’s Systems Center Configuration Manager (SCCM). But given the cost involved in procuring and providing ongoing support for it, the zero-touch interface (ZTI) will not be a cost-effective solution for all businesses–particularly SMBs.
With that said, IT can still squeeze a great deal of automation from the lite-touch interface (LTI) with some smartly written configurations and a little creativity. Beginning with the Bootstrap.ini, we’ll cover the different configurations and changes that will make LTI as much like ZTI as possible.
Let’s have a quick look at the requirements first:
- Server running Windows Server 2008 (or later)
- Windows Deployment Services installed and configured on server
- Microsoft Deployment Toolkit installed and configured on server
- Administrative access to the server
- Text editor to edit configuration files
- Network diagram(s) (This is optional, but it greatly assists when working with multiple sites.)
To simplify the Bootstrap.ini file to get the most out of automation, we’ll break it down into three sections: Settings, Custom, and Defaults.
In this first section, we’ll look at the Priority header, how it affects the order in which lines are processed when the script is run, and how to best use that to our advantage.
The entries stipulated after Priority= will be processed in the order in which they are read –from left to right–by the MDT scripts. The Bootstrap.ini file may be edited to include information specific to a site or multiple sites, such as the Gateway IP address or MAC address, which help to uniquely identify a place or device.
Typically, as the headers are read by the MDT script, the information is processed on a first-come, first-served basis. This means that if two or more conflicting entries are detected, the first entry read will be the one written. The subsequent entries will be disregarded.
The final entry, usually Default, will group settings that are less specific or that would apply to many or all of the devices that are processing the Bootstrap.ini file. However, do note that without the accompanying settings in section two, the headers in the Priority entry will not have any information to process and will be skipped altogether.
SEE: Windows 10 spotlight: Prepare, repair, and recover (Tech Pro Research)
The second section works hand in glove with the previous section. Consider this the payload to the title listed in the Priority entry in the Settings header. Take, for example, the DefaultGateway property. This property will read the gateway IP from the device and perform a lookup based on the entries listed in Bootstrap.ini to find its location. For instance, 192.168.1.1 is the gateway IP that belongs to the United StatesHQ of THEMACJESUS.COM.
That gateway IP is now referred to the UnitedStatesHQ custom property below. Under that header, the DeployRoot property points the Bootstrap.ini file to the UNC path to the deployment server it should authenticate to. If the gateway detected were instead to be 192.168.2.1, the Bootstrap.ini file would direct the deployment share to the server at SpainHQ, and so on, changing the server’s UNC path dynamically in accordance with the gateway IP detected.
Say, however, that the location of the deployment share resides in a location without DHCP services available to assign an IP address to the communicating device. A secondary property, MACAddress, may be used to indicate to Bootstrap.ini that if a matching MAC address is detected in the headers, the following IP information should be statically assigned to the device for it to establish a connection with the deployment share.
While the properties above work great to assign IP information to non-DHCP clients, it can also be used to ensure that a specific device gets the IP information temporarily assigned should the MAC address find a match in Bootstrap.ini. Consider this useful for mobile devices that may connect to the network only sporadically and thus would not normally receive static IP assignments since they are often in the field.
The Default section is the third part of this Bootstrap.ini breakdown and arguably the most important. Since many of the settings stored under the Default header may be used in the previous sections, the Default header is often used as a catchall. The settings contained here are applicable to all devices that connect to the deployment share.
Consider the settings above, particularly the UserID, UserPassword, and UserDomain properties. These settings manage the account information used to authenticate to the deployment share listed in the DeployRoot property in the section(s) above. By configuring these entries, the authentication screen will not prompt for credentials, instead running silently in the background.
In addition, the SkipBDDWelcome property is set to NO by default. Setting it to YES would prevent the welcome screen from appearing and hand off silently to the next MDT script, whose configuration is managed by CustomSettings.ini and will serve as the focus of the next article.
Additional Windows how-to’s
- How to configure the Microsoft Deployment Toolkit (TechRepublic)
- How to automate account pre-staging in WDS with PowerShell (TechRepublic)
- How to integrate DaRT into the Microsoft Deployment Toolkit and Windows Deployment Services (TechRepublic)
- How to deploy Windows using MDT and WDS (TechRepublic)
- How to deploy applications with the Microsoft Deployment Toolkit (TechRepublic)
Have you worked with Bootstrap.ini to automate your deployments? Share your experiences and advice with fellow TechRepublic members.