OSD Machine Import and the GUID

A common step in imaging through OSD, especially when unknown computer support is not in use for the environment, is to import a new machine record and then target image deployments to the imported machine. I was testing this a few days ago and came across a difference in behavior from ConfigMgr 2007 to ConfigMgr 2012 that were interesting and worthy of a post to discuss. This is more of an academic post because the end result for the administrator, assuming everything is working, should be no different. But to me it is always interesting to know how processing works ‘behind the scenes’ as that information is useful for troubleshooting when things don’t work as expected.

To get started, let’s import a new machine entry using the Import Computer Information wizard. For the example I will import a single entry.

Now that the new machine entry is created we take a look at the properties and notice this is a very basic entry, as mentioned. But scrolling down we see something interesting. This imported machine already has a GUID associated! That is odd because historically the client GUID is created on the client at install time!

Also worth noting is that if this machine entry were to be deleted and recreated with all of the same information, the GUID generated would be different which suggests the GUID generated as a result of importing the record is a random entry.

OK Steve, that is interesting but who cares that the machine entry has a randomly generated unique identifier? Glad you asked! Let’s continue to follow the process. With a machine entry created we now deploy a basic image to the imported system. In my case I’m using a Windows 8 image but any operating system supported by ConfigMgr 2012 would be fine.  Also, for this example the lab system is booting from either ISO media or USB media.  Haven’t tested in depth with PXE yet.

The Setup Windows and ConfigMgr step in the imaging process results in the ConfigMgr client being installed. As mentioned, it’s common knowledge from years of experience that when the ConfigMgr client is installed a unique client GUID is generated. That is what I expected to happen in this case and wasn’t really paying attention to the process. I just happened to stumble onto the fact that the process is now different. What I found is that in ConfigMgr 2012 a specific component used as part of running the task sequence (called TSMBootStrap) now queries the site to determine if a client GUID has been generated proactively. If so, we use it. If not, we proceed to generate our own.

Looking at the SMSTS.log (typos native to the log! J) we see a section similar to the following.

Can not find DeploymentType in file TsmBootstrap.ini or the file doesn't exist. This is not running on Windows To Go.
Setting SMBIOS GUID = F2380883-D0CD-408C-9D2A-A4742D7E12BE.
Adding MAC Address 00:15:5D:00:08:17.
Executing Client Identity Request.
Requesting client identity
Setting message signatures.
Setting the authenticator.
CLibSMSMessageWinHttpTransport::Send: URL: labsrvcmps1.contoso.com:80 CCM_POST /ccm_system/request
Request was succesful.
::DecompressBuffer(65536)
Decompression (zlib) succeeded: original size 615, uncompressed size 2944.
-60 –60
Server time zone info: 360, , [0 11 0 1 2 0 0 0], 0, , [0 3 0 2 2 0 0 0], –60
Client Identity: GUID:C977C3A8-9AAF-4BED-BC47-EB52BA7EE2DA
Netbios name: testOSDImport
Client GUID = GUID:C977C3A8-9AAF-4BED-BC47-EB52BA7EE2DA, Netbios name = testOSDImport, State = Known
Set media certificate in transport
Set authenticator in transport
CLibSMSMessageWinHttpTransport::Send: URL: LABSRVCMPS1.CONTOSO.COM:80 GET /SMS_MP/.sms_aut?MPKEYINFORMATIONMEDIA
Request was succesful.

This information is good to know to enhance general knowledge of how processing works and also for potential troubleshooting scenarios. The best way to illustrate is by example. Assume you have imported a machine record in the console and initiated imaging of that system. During imaging there is a brief network glitch and the system being imaged is not able to contact the infrastructure to request client identify. In this case your imaging will continue and the client will be installed as a part of the process but will generate it’s own unique GUID. Then, when the client contacts the infrastructure it will be seen as a new client and will be added as if it were a new client – which means any direct membership entries based on the imported record – such as variables, deployments, etc. - will no longer be in place against the new record. Remember, while the machine name is the same the resulting GUID is not. Since the GUID is THE unique identifier for the system then it is key.

As stated at the beginning, if the infrastructure is working there shouldn’t be any perceived difference from how things have always worked. Still, knowing this information will help in the event something unexpected comes up.