Hello internet! Here I’m going to delve into the world of automatic computer naming by gateway using ConfigMgr. Using a reference from Mikeal Nystrom (see links at the bottom of the page) I’ve got this going with great effect in my environment so I though I’d share.
Firstly, before we go any further you are going to require MDT integration to get this to work. We will create a MDT Settings package along the way as we create a task sequence and then configure the customsettings.ini to name the devices as we see fit.
So, before we begin we’re going to pre-stage two new folders which is where I want the packages (source) to be stored (I’ll leave the decisions on this up to you) …
..and then create a new MDT integrated task sequence.
Here are the steps I take:
Chose Template – Client Task Sequence
General – Name the task sequence
Details – Set your own details here as you see fit
Capture Settings – This task sequence will never be used to capture an image
Boot Image – Select your boot image
MDT Package – Create a new Microsoft Deployment Toolkit Files package & browse to to the shared UNC of the folder you set up for the files package
MDT Details – Fill in as required
OS Image – Specify your operating system image.
Deployment Method – Perform a “Zero Touch Installation” OS Deployment, with no user interaction
Client Package – Specify your client package
USMT Package – Specify your USMT package
Settings Package – Create a new settings package & browse to to the shared UNC of the folder you set up for the settings package
Settings Details – Set your own details here as you see fit
Sysprep Package – No Sysprep package is required
Now you should have your settings and files packages created and those of you who are familiar with MDT can browse the package source folders and recognise what you’re seeing. Next we’re going to examine how we’re going to set this up moving forward. Here is a diagram of my current setup
In my situation our main site server is located in a Data Center, it has a WAN link directly to each branch office (of which there are lots!) and in each Branch Office we have a PXE enabled distribution point ready to image OSD Clients. Each Branch office has its own subnet and in turn, gateway, so if we imagine creating a singular task sequence that can read the gateway address and then apply local settings that suit – That would be awesome! Lets do that….
First thing we need to do is to crack open customsettings.ini and start programming it as we require. So if you browse to the sources folder on your site server and locate the folder for the MDT Settings package we created earlier you should see two files.
Open customsettings.ini and lets start editing!!! Here is how I am going to build up my naming convention. Four letters to identify the site, followed by a hyphen, followed by a singular letter to denote a laptop, desktop or virtual machine, followed by a hyphen and finally the last 6 digits of the serial number of the machine (some people use the first few digits but in my experience only the last few differ whereas the first few can be the same across multiple machines – this may differ from vendor to vendor please examine the format of SN’s from your vendor carefully). As an example if my desktop computer was in London, then a generated name example would be LOND-L-123ABC. Looking at this I can determine where is it and what type of machine it is. Also, AD is happy because the name is unique as its added on the domain during the process.
Here is a copy of my customsettings.ini
This assumes a couple of things.
1. You want the local admin account to be on and set to a singular password for each site, in the examples case this is set to [email protected]
2. That you want the domain admin account to be used to add the computer to the domain and the domain admin account has the same password in each branch office, in the examples case this is [email protected]
Should you not want this (which I’d advise against) you can change this up as you see fit to match your own environments – Here I’m just testing the theory. I’ll show you how later. Lets break down the settings and try to make sense of them bit by bit.
Here we are stating that the priority order in which the ‘settings’ get processed is denoted by what follows the ‘Priority’ section and that we are setting three properties which are named after the ‘Properties’ section.
Here we are processing the building of the computer name. The section “GenerateSN” reads the serial number from the computer. The number denotes how many characters we want and the word “Right” means its taking them from the right inwards so reading left to right that would mean the last 6 digits. You can change “Right” to “Left” and also the number, should you wish. It also uses code to replace any dashes and spaces with nothing. so 65-1234 would become 651234 before it is read into the setting. (Cool huh!?). The proceeding sections read the MDT variables and set accordingly. If you have a desktop, the Am_I_a_Desktop setting becomes Desktop-True and the rest are set to false. This results in the ComputerTypeName being set to a letter (either V, D or L)
Once we get this far we have processed the settings for GenerateSN, Am_I_a_VirtualMachine, Am_I_a_Desktop, and Am_I_a_Laptop with only DefaultGateway and Default settings left to process.
From this section we generate our “ComputerTypeName” and “ComputerSerialNumber” properties for the name of the computer we are deploying. The rest of the settings I want to set based on gateway, so here I set up some gateways:
Here we are saying if the default gateway is X process the settings labelled as X. The first example states if the default gateway is 192.168.1.1 then run the settings for London. The settings in “London” will be classed as our Gateway settings, so here we can set whatever we like that’s going to be specific to the site. In my case I set the following:
1. Please put all logs for computers deployed at this site into the folder \SCCMServerOSDLOGS$London. It will create a folder for each computer so you can trace the logs in case of errors.
2. Please set the SitePrefix property to “LOND”, which is the final property that builds up the computer name
3. Join the computer to london.local
4. Set the OU for the computer account on this domain to be LONDON.LOCAL> LONDON COMPUTERS
It is here you can set alternative security options. For example if you wanted a different local admin password or domain join account password, they could be set here and built up per site/gateway you configure. Hopefully as you study the settings we’ve set in this example you should understand how to build up your own custom ones. If you aren’t sure, feel free to ask and I’ll do my best to answer. Follow me and DM me on Twitter and I’ll help you out, should you need it.
Before I move further, this is a basic example, but consider if you had distribution points in other countries. At this point you could add any number of the MDT properties to set locale settings, keyboard layouts, time zones – all sorts of things relevant to your environments. I think that’s pretty cool! There are lots of MDT properties to explore take a look in the help section of deployment workbench to explore more.
Next we process Default options, which are the settings I want to process on every computer everywhere because they process for each OSD deployment.
OSDInstall = Yes and the strange resolution settings of 1 by 1 pixel is a trick I learned from Johan Arwidmark to trick the computer to use the recommended display settings after deployment. It tricks the computer because 1 by 1 is an invalid resolution so during OSD the computer will assume the operator is drunk and will ignore your request and set it to the recommended resolution for the graphics card instead meaning you don’t have all your PC’s deploying with 1024×768 and then having to manually change them all. Cheers Johan!
The Timezone settings are pretty straight forward, I’m setting things up for the UK here. Adjust to suit.
The rest of the settings should hopefully make sense. We are building up aspects of our settings bit by bit. The OSDDomainName property set in our Gateway settings forms part of the account used to add the machine to the domain, in the case of london it would form LONDONadministrator. In the case of the computer name it builds it up using the properties set earlier and adds a hyphen in between each section. A London Desktop computer example, therefore, would become LOND-D-123456 (where 123456 are the last 6 digits of the serial number). This makes each computer unique! Just what we wanted.
Fleshing out the task sequence
Now that we can predict what the computer name format is going to look like for each subsequent OSD deployment, we can now flesh out our singular task sequence and deploy apps to certain sites by using WMI queries on the computer name. We know now, for example, that a computer in London will have a naming convention whereby the first four letters of the computer will be LOND. Now we can add a sections in out task sequence that will only run if the computer name is prefixed with LOND. Clever right? This should give you a great foundation for creating the ‘One Task Sequence to rule them all!’ which is where I want my Zero Touch installations to go.
Don’t forget that this isn’t MDT so changes to customsettings.ini are not instant. When you make a change, you must update the distribution points so that they process the change ready for the next test.
Well, I hope this has been useful for you. I certainly enjoyed getting this set up and am now in a position where I’m fleshing out that all mighty task sequence to cover multiple sites.
https://deploymentbunny.com/2012/04/21/back-to-basic-customsettings-ini-explained/ – Mikael Nystroms page