Share via

Unknown Computers in SCCM 2007 R2- how it works

  • Article

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!

Comments

  • Anonymous
    September 20, 2008
    PingBack from http://hoursfunnywallpaper.cn/?p=7123

  • Anonymous
    September 21, 2008
    Steve Rachui just posted some great information about R2&#39;s unknown computer support on his blog:

  • Anonymous
    April 19, 2009
    This is the final article of a series creating a custom Boot wizard to dynamically choose the Task Sequence

  • Anonymous
    August 20, 2009
    Nice article Steve! I know this an old article but I came across it today itself while searching for info about "unknown computer" support in ConfigMgr2007 R2. I have one question: How we give a particular name to a unknown computer during imaging process? When we import manually we provide a computer name and mac address. thanks, umesh

  • Anonymous
    August 20, 2009
    You would have to do that as part of the task sequence - there are several ways you could make it happen.  I like using variables.

  • Anonymous
    January 16, 2010
    Hi Steve, I really like your blog. Especially the stuff about SCCM. You worte that you can think of some ways to provide computer names - and you like variables. Can you give me an example how this aim is fullfilled with variables in a task sequence? Thanks in advance, Andy

  • Anonymous
    January 21, 2010
    Variables will work great for this.  Just set the variable OSDComputerName to whatever system nameyou want and you should be good to go.  You can define OSDComputerName using a script/input file, using a front end of some sort, defining the variable on individual members of a collection, etc.  For the unknown computer scenario I would likely use a script.  I also always recomment reviewing the list of available TS variables.  The ones that start with _ cannot be modified but there are hints about working in certain scenarios ont he page - http://technet.microsoft.com/en-us/library/bb632442.aspx.

  • Anonymous
    July 09, 2010
    Hi Steve, tnx for this post!! It's really interesting... I have a question, Do you know why in my MP_ClientID.log file I only see : Parse a client ID request MP_ClientIDManager 09/07/2010 17.11.59 6380 (0x18EC) Send reply message to the client MP_ClientIDManager 09/07/2010 17.11.59 6380 (0x18EC) Parse a client ID request MP_ClientIDManager 09/07/2010 17.11.59 5044 (0x13B4) Send reply message to the client MP_ClientIDManager 09/07/2010 17.11.59 5044 (0x13B4) Parse a client ID request MP_ClientIDManager 09/07/2010 19.32.07 6624 (0x19E0) Send reply message to the client MP_ClientIDManager 09/07/2010 19.32.07 6624 (0x19E0) and not a fully log like your file....:-( tnx in advance Alex

  • Anonymous
    July 10, 2010
    Yep - I bet you don't have verbose/debug logging enabled in the registry.

  • Anonymous
    August 24, 2010
    I want to apply a specific task sequence to a prestaged pc. I imported the pc (vm) with a specfic mac, added the pc to a specific collection and also advertised a program. But the PC still is categorized as unknown. Do I have to install an OS first to get the client provisioned and to ensure that further advertisments are listed correctly? Thanks

  • Anonymous
    August 30, 2010
    Hi Joachim - from what you have described the PC should be known.  There is no need to install an OS first - bare metal provisioning will work fine - all you need to do is import the PC (as you have done), advertise an OSD task sequence to the collection with the imported PC and boot from a boot disk - either USB, CD-ROM or PXE.  The scenario you describe is not an unknown computer scenario.  If the PC still shows up as not recognized make sure you entered the MAC in the right format - you can see the attempt at matching in the smsts.log - just make sure your boot image that you created has support for F8 debug.