My previous blog entry discussed how to configure unknown computer support in SCCM 2007 R2 - but how exactly does it work?  I was curious so dug in a bit.  Let's start by reviewing the logs from an 'unknown' system that has booted from a CD configured for 'unknown' computer support and walk through the imaging process step by step.

On the imaging system in the smsts.log

Loading Media Variables from "D:\sms\data\variables.dat"   
Setting CEN00001 TS environment variable   
<similar log entries edited>
Setting _SMSTSx64UnknownMachineGUID TS environment variable   
Setting _SMSTSx86UnknownMachineGUID TS environment variable   
MP Public Certs=308201<publickeylength edited>5C2E16
 

In the section above we see that two new environment variables are set - these environment variables define known GUID's that specifically flag a system as 'unknown'.  These GUID's are stored in the database associated with placeholder entries that are used by 'unknown' machines - we will see more about this shortly.

Continuing in the smsts.log we see the imaging system submitting a request to the management point to determine whether it is a 'known' or an 'unknown' client and to download policy as appropriate.

Preparing Client Identity Request.    
Setting transport. 
Setting SourceID = 264AD30F-CDAF-4D77-AA57-ECC4D8F88003.       
Setting site code = CEN.
Setting SMBIOS GUID =
                     B70EBBE5-2A7E-4C5B-BAEF-01D005621169.       
Adding MAC Address 00:10:20:30:40:50.
Executing Client Identity Request.
Requesting client identity
Formatted header:
<Msg SchemaVersion="1.1" ReplyCompression="zlib"><ID/><SourceID>264AD30F-CDAF-4D77-AA57-ECC4D8F88003</SourceID><SourceHost/><TargetAddress>mp:[http]MP_ClientIDManager</TargetAddress><ReplyTo>direct:OSD</ReplyTo> <Priority>3</Priority><Timeout>3600</Timeout><SentTime>2008-09-20T22:34:44Z</SentTime><Protocol>http</Protocol><Body Type="ByteRange" Offset="0" Length="412"/><Hooks/><Payload Type="inline"/><TargetHost/>
<TargetEndpoint>MP_ClientIDManager</TargetEndpoint>
<ReplyMode>Sync</ReplyMode><CorrelationID/></Msg>
CLibSMSMessageWinHttpTransport::Send: URL:               
                         
STEVERACCEN:80  CCM_POST /ccm_system/request
The request has succeeded. 200 OK

A couple of notes from the log snip above.  First, this log snip has been edited to remove date/time information but all of these entries took place between 5:34:38 and 5:34:44 PM.  This will be important shortly when we shift our focus to the management point processing.  Also, note the SMBIOS GUID that is recorded in the log along with the MAC address.  The next step in the smsts.log is to submit this information to the management point for use in determining what options are available for this imaging system.

Shifting focus now to the management point   Note that the last entry from the log snip above took place at 5:34:44.  Picking up on the management point side we turn to the MP_ClientID.log.  Here we see that at exactly the same time as our submit from the previous log we see the management point receive the request and start processing it.

Parse a client ID request 
Client ID request body:
<ClientIDRequest SchemaVersion="1.00"><Identification><Machine>
<MacAddress>00:10:20:30:40:50</MacAddress>
<SMBIOS>B70EBBE5-2A7E-4C5B-BAEF-01D005621169</SMBIOS>
</Machine></Identification></ClientIDRequest>
Received SMBIOS: B70EBBE5-2A7E-4C5B-BAEF-01D005621169
Add a new mac address: 00:10:20:30:40:50

Note that the information in the request body above reflects what was submitted by the imaging client - pay specific attention to the MAC address and SMBIOS address.


Querying for SMBIOS: B70EBBE5-2A7E-4C5B-BAEF-01D005621169

In the above snip the management point is querying to try to find a match for the SMBIOS information.  Remember, when you are imaging systems that are not in the ConfigMgr database prior to R2 you had to ensure a entry existed in the database that would make the system 'known' to ConfigMgr - either by SMBIOS address or MAC address.  With 'unknown' support this is no longer required - if the imaging system doesn't exist in the database we will add it at this step based on finding that it is 'unknown'.  In my case, this system already exists in the database from previous work and is still defined as 'unknown' so we just find the existing entry.  We can see this by looking at the 'all systems' collection.

image Looking at the properties of this system we see the SMBIOS information and the client GUID.

image
SMBIOS query succeeded:
                       GUID:f3a406d7-2d67-4b1e-99d4-0aff8f6bcc70

Continuing in the MP_ClientID log we confirm that the SMBIOS query succeeded and we have also picked up the client GUID.

Using SMBIOS: GUID:f3a406d7-2d67-4b1e-99d4-0aff8f6bcc70
Using Netbios Name: Unknown 

We flag that we are using the GUID we just found and assign the name of 'unknown'.  If this record had not already existed we would have created it and given it the name 'unknown' with it's own unique client GUID.

Construct a reply message:
<ClientIDReply RequestReceivedTimeHigh="29956977" RequestReceivedTimeLow="340648488" ReplySentTimeHigh="29956977" ReplySentTimeLow="342210948" ReplyServerTimeZoneBias="360"
<similar log entries edited>
ReplyServerTimezoneDaylightDateMilliSeconds="0" Unknown="1"><Identification><Machine><ClientID>GUID:f3a406d7-2d67-4b1e-99d4-0aff8f6bcc70</ClientID><NetbiosName>Unknown</NetbiosName>
</Machine></Identification></ClientIDReply>
Send reply message to the client
  

Based on our finding we construct and send a reply to the imaging system so it knows what to do.

Shifting back to the imaging system we pick back up in the smsts.log immediately after we receive the management points reply.

Decompressing reply body.   
::DecompressBuffer(65536)   
Decompression (zlib) succeeded: original size 468, uncompressed size Client identity reply: <ClientIDReply RequestReceivedTimeHigh="29956977"
<similar log entries edited>
ReplyServerTimezoneDaylightDateMilliSeconds="0" Unknown="1"><Identification><Machine>
<ClientID>GUID:f3a406d7-2d67-4b1e-99d4-0aff8f6bcc70</ClientID>
<NetbiosName>Unknown</NetbiosName></Machine>
</Identification></ClientIDReply>
-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:f3a406d7-2d67-4b1e-99d4-0aff8f6bcc70    Netbios name: Unknown
Client GUID = GUID:f3a406d7-2d67-4b1e-99d4-0aff8f6bcc70, Netbios name = Unknown, State = Unknown   

The imaging client receives the client ID info from the management point above.  Note that we call out that the state of the machine comes directly from the database record for this system.

Client is unprovisioned   
Using unknown machine GUID: 607de478-9a89-4f0f-962b-aedac28190ba   
Unknown client identity: GUID:f3a406d7-2d67-4b1e-99d4-0aff8f6bcc70

The log snip above is interesting - first, we see that the client is flagged as unprovisioned.  How do we know that?  It's in the database - but we can also quickly see a list of unprovisioned systems in the OSD node of the admin console under unprovisioned computers as shown.

image
Next, we see that the unknown machine GUID has changed - the original client GUID as identified from the database was f3a406d7-2d67-4b1e-99d4-0aff8f6bcc70 but it has now changed to 607de478-9a89-4f0f-962b-aedac28190ba.  Why the change?  Very simply, configmgr has discovered this system as unprovisioned - meaning that there is no admin entered record for it as might be created through the import computer wizard - and, as a result, it is considered 'unknown'.  In order to image an 'unknown' system we map the imaging system to the database entry of appropriate architecture type as seen in the 'all unknown computers' collection.  If we go to that collection and look at the properties of the x86 entry we see that the GUID we have now shifted to use matches the GUID information of the 'unknown' x86 entry as shown.

image 

From here we prepare a policy request to find out which OSD task sequences are available for use.

Preparing Policy Assignment Request.

We get back a list of policy that could apply to our imaging system

Retrieving Policy Assignments:
Processing Policy Assignment {73c7de5b-b23e-4732-85e1-1c32920263ea}.   
<similar log entries edited>
Processing Policy Assignment DEP-CEN2002A-CEN00031-DBBBC9D6.    Successfully read 25 policy assignments.

From here we present the available task sequences to the user in the wizard of the imaging system - or if we find a task sequence that is mandatory we just start to execute it.

That's about it - as you might expect, some detail has been left out for brevity but this gives a good feel for the nuts and bolts of how his feature works.  One more thing I found interesting.  Up until now we would expect to see every system from all of our computer collections in the 'all systems' collection.  Take a look at my 'all systems' collection as shown

image
Now take a look at the membership of my 'All Unknown Computers' collection

image

So, why are there 'systems' listed in the 'All Unknown Computers' collection that don't show up in the 'All Systems' collection?  Great question.  The answer is that these entries in the 'All Unknown Computers' collection are simply generic placeholders for us to use as a template when unprovisioned computers enter the environment for imaging.  They are not truly managed systems.  When we encounter unprovisioned systems an 'unknown' entry is created in the 'All Systems' collection that we fully expect will become a managed system after the imaging process completes.  To know which images are targeted to these unprovisioned systems we have these placeholders that we can target with images in the 'All Unknown Computers' collection.

OK, thats it.  Hope it helps in understanding 'unknown' computer processing with OSD!