One of the most important files in MDT (and in SCCM with MDT) is customsettings.ini, it is the rule file to rule your deployment. Yesterday Johan and I did a session at MMS and besides getting great scores and that is always fun. During that session I did a couple of demos around customsettings.ini and I would like to explain this a bit more. Because if you do understand the rules you can become much more dynamic and that will hopefully lead to less hassle and more work done in less time.
So, let’s start from the beginning:
When you use the MDT Toolkit (standalone, with WDS, with SCCM, it does not matter) the toolkit will as a part of the process run a script called ZTIGather.wsf, this script will do an asset inventory and also read the customsettings.ini file. This will result in a massive amount of information stored in memory (and in a file) during deployment that we then can use to dynamically update the unattend.xml file on the fly and also control conditions and that way also settings and steps in the TaskSequence
The best thing is that you can run this script without deploying any OS, so this way you can test the rules before you even begin deploying, and you can also test thousands of deployments in a couple of hours. (Here is a blog post on that http://deploymentbunny.com/2011/04/27/quick-and-dirty-testing-customsettings-ini-variables-in-mdt)
CustomSettings.ini – Act I
The basic Customsettings.ini looks like this
In the first row we see the section called [Settings] and this is what the script are looking for and on the next row you can see Priority=Default. That means that it will now consume everything in that section and convert all those lines in to varables in MDT. All the Properties you see under the Section [Default] is built into MDT, there are +100 properties that can be used and most of them are documented in the help file, just search for Properties and you will find a huge list. If we run ZTIGather.wsf against this file we will get the following output
And as you can see, it is using my customsettings.ini file that I pointed out by running cscript.exe ZTIgather.wsf /Inifile:”..\Control\customsttings.ini”, we can also see that the script is reading settings and finding the priority and then process the [Default Section]
CustomSettings.ini – Act II
Now let us assume that you would like to automatically set some settings based on location, things like computer name, language, time zone, something like that In that case, we would use the default gateway as an identifier for the location and would use part of the serial number to calculate a unique name for the computer that is based on the location and the serial number, but hey, let us do something crazy here, let us also add laptop or desktop into the name, so if the laptop is located in Stockholm the name should be STH-LT-0123456 and if a desktop is located in Redmond it would be called RDM-DT-0123456. So, that would look like this
Now, this is slightly “bigger”, but let me guide you through this one, it is not that hard.
The Settings Section
In the [Settings] section we added Init, ByLaptop, ByDesktop and DefaultGateway. The [Init] Section is things that I would like to be set in any situation, like default, but BEFORE default is running. The ByLapTop and ByDesktop contain something called SubSection and we will get back to that. DefaultGateway is a property in MDT so the script will take my current default gateway and match that to what I really have, more on that later.
Next line is the CustomProperties= and here we added a couple of properties that we will fill with data so that we later can use them to populate many variables into one, that’s how we can “build” the computer name, since that will be a combination of computer location + computer type + the first 7 characters in the serial number. So the complete Settings section look like this:
Priority=Init, ByLaptop, ByDesktop, DefaultGateway, Default
Properties=ComputerLocationName, ComputerTypeName, ComputerSerialNumber
The Init Section
The Init section will use the serial number (that has been inventoried by the script already), pick the 7 characters to the left and put that into my custom property ComputerSerialNumber, so that section would look like this: (You can to basically any kind of calculations like this, just go ahead and play with it)
The ByLapTop Section and the ByDeskTop Section
These two sections are a bit fun, what we do here is that we tell the script to jump to a subsection called LapTop-%IsLapTop% and %IsLapTop% will either be true or false and we will tell it to do the same for Desktop, and will also return the value of True or False, and since it cannot be a Laptop and an desktop at the same time, either will LapTop-True be true or DeskTop-True be true, so it will pick up regarding case type and then set the name to match that, like this:
In my case I have a laptop, so it will set the value of %IsLapTop% to True and the value of %IsDeskTop% to false, resulting in that the ComputerTypeName will be set to LT
The Default Gateway Section
This section will use the value from the gather script regarding the Default Gateway and based on the set jump to the name I have set for that Gateway, so in this case it will go to the section Stockholm if my Default gateway happens to be 10.2.0.4 and in that case it will set the Swedish keyboard and compterlocationname to STH and that part looks like this:
The Default Section
This section will run last, not because it is last, it will be the last section since it is last on the priority line. That also means that if I have any property value here that has already been set the rule of thumb is that “First Writer Wins”, so they will not be over written (there are exceptions). Here you can see that I have property values for ComputerLocationName and ComputerTypeName, so why do I have that? Well I will set the name to UNK (Short for Unknown) if the computer is not a Laptop and neither a Desktop (Could be a Server? And yes, we could create rules for that to), also if the default gateway is something that I did not add in the customsettings.ini file, and then it will get the location name set to UNK to. So here is how it looks:
The fun part is that OSDcomputername is built by parts of location, type and serial number.
Running the Script will result in this:
So, here is how you could create dynamic deployment rules using notepad and a textile, I think that is really cool, but hey, I’m just a Bunny anyway J
(if you would like more samples, let me know…)