The previous article in our Microsoft Deployment Toolkit (MDT) series explained how to use Bootstrap.ini, the file that controls access to the shared drive that stores the deployment repository. We looked at how Bootstrap.ini works and how it can be further modified to provide for an automated deployment process using the lite-touch interface (LTI).

To enter all six letters as the prefix (WSDELL) you would need to run a post-image task to update the computer name in the answer file. The following code is an example of this for Windows 7 deployments. Renaming a computer name to the serial number. If you are renaming the local computer, is the new name. So this should work. My work computer does have a.

This article aims to further that work by extending the capability of MDT to deliver an automated deployment scenario using the CustomSettings.ini file. This file handles the order in which the deployment process will execute scripts, but it also provides the avenue by which answers to scripted events can be provided for a truly hands-free deployment.

Let's first have a quick look at the requirements:

• 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 greatly assists when working with multiple sites or balancing the load across multiple servers.)

Similar to Bootstrap.ini, the file can be broken down into three sections: Settings, Custom, and Default.

SEE: How to set up Microsoft Deployment Toolkit: Step by step

Settings

Under the Settings section, the Priority header will affect the order in which subsequent sections and the lines contained therein are processed as the scripts are run during the deployment phase. By rearranging these entries, we can control the execution of the deployment phase. We can use that to our advantage to wring out some extra productivity without having to upgrade to Systems Center Configuration Manager (SCCM) to accomplish many of the same tasks.

Much like the Bootstrap.ini file, CustomSettings.ini (CS) may be edited to include information that you wish to take into account prior to beginning the deployment process—such as data that will exist as variables that can be called upon as needed. This is extremely useful when working with multiple sites or when you want certain settings to apply to desktops, while mobile devices receive a different set of settings.

Wds Computer Name Serial Number Free

If you look at the snippet above, you'll see that there is an additional header under Priority, titled Properties. Priority will include the sections that are present in the CS file and the order in which they should be read by MDT. Properties refers to the variables that are being used in the CS file and as such, MDT will recognize these variables when they are used throughout the deployment process.

When working with variables and modifying the Priority headers, it's imperative to exercise due diligence and to test each component of the CS file prior to being put into production. One last bit to keep in mind is that the information in the CS file is processed on a first-come, first-served basis. If two or more entries are conflicting, the first one detected will be written—the others will be discarded.

SEE: Windows 10 spotlight: Prepare, repair, and recover (Tech Pro Research)

Custom

Custom entries in the CS file are not required for it to operate at the automated level. However, depending on the needs of your environment, it may be a good idea to implement a few custom entries to simplify management of the MDT settings.

One of the common sections listed is [Init], short for initialization or initialize. Entrees in this section are typically placed as first priority and contain data that must be present at the start of the deployment process, before the first deployment script has even run.

The reasons for this type of section vary, but a common use is in determining the computer's serial number. For example, consider the computer naming scheme used in the CS file. It requires that the LocationName variable (which is matched to the DefaultGateway) be entered as the first three characters of the name, followed by a '-' and the computer's serial number. On a computer with fewer than 11 characters for a serial number, this isn't an issue. But for one that carries a serial number with more than 11 characters, the computer name as generated in MDT will be truncated and likely not match what's been prestaged in Active Directory (AD). This can and will produce problems down the line when the script executes the domain join command and fails since it can't find a match in AD—resulting in the deployment process failing altogether.

In the default gateway above, 192.168.2.1 pertains to LAX, an abbreviation that links it to the section of the same name that contains the additional variable of LocationName=Los Angeles and provides the path to the OU for creating new computer objects in AD for the Los Angeles branch.

Other entrees may be included, such as to specify the KeyboardLocalePE=, which sets the default keyboard layout's language—ideal if you are managing locations in other countries that require a different language layout from other sites.

Up next is the [ClientType] section, which is optional, but one that I find makes deployments hum along quite smoothly when managing multiple types of equipment, such as desktops, laptops, and servers.

By chaining these entries together, the CS file is telling the WMI script to first check the hardware type of the device to be imaged. If it returns a value of IsDesktop, it will write the TaskSequenceID=WIN10_X64 variable to the script since the desktop computer has been identified correctly, and it will install Windows 10 - 64-bit as the OS on that device. If another value is detected during hardware check, say IsServer, the variable assigned will dynamically change to assign TaskSequenceID=WIN2012_X64, which will in turn instruct the script to install Windows Server 2012 - 64-bit edition as the designated OS for server hardware.

The header can also be modified to the product name of the device in question. This will provide a more precise match for the script to assign one or more variables based on the internal product name instead of dreaming what type of hardware ID it has.

What Is A Computer Name

Note: One of the easiest way to determine the product name on a computer is to launch the command line, type the following command, then press Enter:

Default

The third and final section—and arguably the most important—is the Default section. It is often viewed as the most important because by default, all the entrees are placed here and applied to all deployment sessions for all devices. While this concept would seemingly work perfectly if your site(s) all had the same make/model of equipment running the same version of Windows and identical settings across the board, this is seldom the case in the real world.

That's why the default section is often considered the 'catch all,' as it will apply the settings and variables that will remain static for all devices, as well as serving as the main source of settings that will direct the MDT scripts throughout the deployment process.

Certain entries, like the TimeZoneName=, can be placed here if the devices all reside within the same time zone. This setting among others, like OSInstall=Y and _SMSTSORGNAME=, enable MDT to install operating systems (a core function of the deployment process) and provide a title during the deployment process, like a company name. You can also use a variable, like %OSDComputerName%, which will dynamically populate that field with the name of the computer as it's being imaged so you can determine at a glance which computer it is.

In the figure above, the entries here which are still part of the default section, serve as further examples of settings that may be modified to perform functions like performing a workgroup or domain join by using the JoinWorkgroup= or JoinDomain= entry and specifying the name of the workgroup or domain you wish to join. To further automate the process, the DomainAdmin=, DomainAdminDomain= and DomainAdminPassword= entries should be added to include the name of the account with domain rights, the password for this account and the domain name that the account belongs to.

Wds Computer Name Serial Number Search

Note: Bear in mind that all entries included in the CS file are listed in plain text. Best practices would either leave these settings blank (which would force MDT to request the credentials prior to commencing the deployment process) or create an account in AD that would serve to only join computers to the domain by delegating only the rights needed to perform this singular admin task. This way, should the account become compromised, it is fairly easy to reset the password and mitigate the threat.

It is also a good idea to reset the default machine quota imposed by Microsoft (MS) on joining computer objects to the domain using standard accounts with elevated privileges, as MS has it set to 10 devices. After which, the account is barred from joining any more devices to the domain. Extending this limit or removing it altogether if you have a large network is easily done through a minor edit to the Active Directory Service Interfaces (ADSI).

Displayed above is the crux of the settings that will both disable the wizard panes from appearing and answering the questions they are asking at the same time to truly automate the lion's share of the MDT scripting process.

Let me preface this by saying that these last few settings are optional but are truly recommended for inclusion in your CS file. They handle security settings, like FinishAction=Reboot and HideShell=Yes, by asserting that at deployment's end, the reboot command should be executed to perform the first boot into the newly installed machine. Also, that the Explorer shell should be hidden during this first time boot, as the system is automatically logged on as a local admin and would otherwise be exposed for anyone to use while it is completing the post-deployment processes.

The EventService= setting will enable system logging on the server and share path you enter here, which can be helpful in troubleshooting certain failures or issues that cause MDT to not execute correctly.

Computer Name Vista

Lastly, there are nearly hundreds of settings that may be used in MDT through the entire CustomSettings.ini file. Some have forks that allow for multiple responses, while others are simple yes or no entries. Alas, there are far too many to possibly cover here. However, Microsoft has made the documentation available via TechNet should you wish to learn more about certain settings and how they may be linked to others to better serve your environment.

Microsoft Weekly Newsletter

Be your company's Microsoft insider with the help of these Windows and Office tutorials and our experts' analyses of Microsoft's enterprise products. Delivered Mondays and Wednesdays

Sign up today Sign up today

Name Serial Number

Also see...

• 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)

Computer Name On Windows 7

Your thoughts

Computer Serial Number Location

Have you used the CustomSettings.ini file to automate the deployment process? Share your advice and experiences with fellow TechRepublic members.