Note: This is part 1 of a series of posts. I decided to break this topic up into multiple posts and to release a post a day to try and keep the content short(er) and retain-able. Sometimes when we have a lot put in front of us all at once, an overly long blog post can be too much. This way we can look at a section a day, and take the time to digest what we’ve read and seen.
The first time I wrote about the Windows ICD tool here, there wasn’t very much to look at. It wasn’t documented well (yet), and it was (is) in a constent state of change. (Although now it’s starting to stay fairly consistent.) With the latest versions we have been starting to see more functionality, so I am going to review this tool again. I would also like to point out the HELP section has improved drastically and more and more about the tool is being documented by Microsoft.
Here is the link to “Provisioning Profiles” on Technet.
The Windows Imaging and Configuration Designer (ICD) is previewing version 10.0.15021.1000 as part of the Windows 10 ADK Insider Preview Build 15021. You can download the ADK at the link below if you are a member of the Windows Insider program.
Once you have installed the ADK you can launch the Windows ICD tool.
If you are familiar with the 1607 version of the tool, you will be familiar with 3 of these sections:
(Note: Any content related to these 3 sections or first 3 series of posts, are applicable to the 1607 version unless otherwise stated.)
We will also notice a few new sections:
These all sound super interesting, so lets dig in and start seeing what they’re all about.
Today’s topic is going to be…
When we select Simple Provisioning, we are provided with a new and simple interface that allows you to start building your provisioning profile as seen below.
The “Set up device” page of the simple interface allows up to define how we are going to name our computers, as well as define a Product key if we would like.
The Device Name section is nice because it allows us to use a couple of variables. Specifically %RAND% and %SERIAL%.
SERIAL – This will get the serial number from WMI and set that as the host name.
You can combine this will a static string to get a dynamic device name.
RAND – This will allow us to generate a random string of characters. We can define how many random characters we want generated by defining the number at the end.
E.g. %RAND:5% – This will generate 5 random characters
We can also use this to combine a static string to generate a dynamic device name.
(I would like to point out that I am not generally a fan of randomization. Although sometimes it has it’s time and place, I am just not a fan. Random = Chaos.)
Here is an example of how we can use them both together to build a dynamic device name.
The Product Key section is pretty straight forward, specifically for folks who do not have a KMS in place for Key management. You can provide your Product key here and it will apply it. Simple.
There is another lesser known feature that this section can assist with, and that is upgrading you SKU of Windows 10. For example changing from Windows Professional to Windows Enterprise without having to reload the operating system. This is actually feature of Windows 10, but this is a utility that allows us to simplify this process.
Watch the silent video below to see a demonstration on how to create a simple provisioning package and watch it upgrade a PC from Win 10 Pro to Enterprise in under 5 minutes.
The “Set up network” page of the simple interface is very basic and provides us with the capability to connect to a basic wireless network using only Open or WPA2-Personal encryption. Otherwise we are required to have our device connected to a LAN cable for configurations that required network / internet communications.
The “Account management” page lets us define how we want to manage our device. It gives us the following options:
Enroll into Active Directory
This section allows us to enroll a device into a standard Active Directory environment by providing the Active Directory domain name, and account credentials that has the right to join the domain.
Enroll in Azure AD
This section allows us to enroll a device in Azure AD.
Note: I will cover Azure AD bulk enrollment in the post about Windows Phone Provisioning
This section can be selected if you do not want to join a device to either AD or Azure AD. If you do choose to join your device to a form of AD, then defining a local account is still optional. If you choose not to join AD, then creating a local account is required.
The “Finish” section of the simple interface allows you to review your details. After you have validated the settings, you can choose to encrypt your provisioning package by providing a password that is 8-16 characters in length. Finally you can create your provisioning package.
When you select the “Create” button, the package will be created and automatically placed in the users Documents directory.
You may have noticed the link in the bottom left of the simple interface in these screenshots that says “Switch to advanced editor”. If you are like me, you just have to click that button. Well when we do, we are prompted with a warning:
What that means is that once we select the advanced view, we can never go back to that “simple interface” wizard again for that specific configuration.
Once we are in the “Advanced Editor” we will the screen that we are used to seeing if the Windows ICD tool.
Here we see our same familiar settings from the previous versions of the Windows ICD tool.
One thing I specifically wanted to point out is how well Microsoft has done at providing us HELP content directly in the tool.
That’s not to say there aren’t still sections that need work…
So what happens if we take the Provisioning profile we have already created in the simple interface and open it in the Advanced view?
Watch this short (and silent) video that see what happens.
One thing to note about these “template” Preference profiles is that there are quite a few settings “pre” configured, which we can see if we dig through the Advanced editor. (I will also show some tricks for seeing what settings are applied in the preference profile in below.)
The image below shows an example of some of the settings that get applied as part of the template.
Now lets take a quick look at some of the files that get created as part of our Provisioning Profile. Like a lot of things these days, a good amount of the configuration data is stored in XML. Who doesn’t love XML? I certainly do.
If we open the directory out project is saved to, we will see a similar file structure as the one shown below:
If we look inside of here we see XML and TXT files. Both things I can work with, because they’re both usually written in “clear text”. So lets take a look at some of these files.
Taking a look at the ICD.txt and ICDCommon.txt files, I found that these are log or dump files containing details about the provision profiles. Nothing that looks to be to useful, but good to know. Below is a snippet from the ICD.txt file.
Now lets look at some of these XML files we have, starting with the Customizations.xml file. This file looks promising. This file contains all of the details we inputted into the UI.
That doesn’t seem to be enough info though. Where is all the pre-configured data? It has to be stored somewhere? Let’s keep looking.
Next we have the SettingsMetadata.xml file. The name alone makes me think this is going to be system data, and looking at the file it seems to be correct. It is an XML file with approximately 7,000 lines of data. It looks to be an XML config file with details about all of the potential settings available to a provisioning profile. I am still trying to find more details on this file, and when I do I will update this section. For now I will provide a quick example of the file and we will take a look at the next file.
The next file we will look at is the .icdproj.xml file that gets created with every project. In the case of this example, our file is named SimpleProv.icdproj.xml. This file doesn’t seem to contain a lot. It definitely doesn’t contain any data for provisioning a Windows device. This file seems to be a configuration file for the profile project itself to help determine what type of provision profile it is. Below is an example of the file:
That leaves us one file left to see if the data is stored in it. This file is called TemplateState.data. The file extension .data is not a file extension I have ever seen. I don’t know what you all do with files that have strange file extensions, but I try and open them with notepad. Sometimes that works out better than others. In this case it was a success. If we open this file, we find XML. Fantastic! I think I mentioned I like XML. Looking through this file seems promising. This looks like just the data I was looking for. All of it too, in one nice little unmarked bundle. This file seems to contain 2 sections. The first section being the section we are interested in, the data. The second section is template metadata. Below you will see a screenshot that contains the data section, and we will see all of the different sections that are defined in the Simple Provisioning profile. It seems it is broken out into sections that go along with what we saw in the simple interface.
IMPORTANT: I noticed this file contains clear text passwords for the wifi profile, the local admin account, and the account that gets used to joined the domain!
So there we have it. A simple provisioning profile. We created a basic package from a profile to upgrade our Windows SKU, and we took at look inside of the XML of provisioning profiles.
In our next post we’ll review the Provisioning School Devices profile preference and digging into those settings.