OSD, Troubleshooting

SCCM 2007 – OSD Troubleshooting – SMS_PXE_SERVICE_POINT Message ID: 6314

Leave a comment

Just a short note for those of you (like me) who are continually ensuring that you have the latest drivers working in your OSD environment – whether or not you adopt them. I have multiple task sequences devoted to model injection – primarily because drivers are being constantly updated as problems are resolved by vendors. Personally, I like to make sure that these drivers can be added to the system without causing problems elsewhere.

One issue I run into every so often occurs when I am repeatedly reimaging a specific model to test new drivers. I haven’t quite nailed down the cause of the issue, but I have figured out how to get past it so I can continue working.

Issue:  When imaging a specific machine multiple times and then leaving the machine information in SCCM overnight, regardless of whether you have cleared the last pXE advertisement, the machine will act as those this flag is not cleared. The machine can be deleted from SCCM, recreated, let the deletion sit overnight, etc – and the advertisement will not clear.

Reason:  It seems as though the cache on the WDS server is retaining the data from the machine in question and it is actually preventing the boot and subsequent imaging process from taking place. A message will be received in SMS_PXE_SERVICE_POINT status messages stating “The SMS PXE Service Point intructed device to boot normally since it has no PXE advertisement assigned.” (NOT my spelling… the message actually says “intructed”)

Resolution:  Restart the WDS service on the pXE server. This clears the cache and allows the box to pXE boot and image.

SCCM 2007, Troubleshooting

SCCM 2007 – Troubleshooting – WUAHandler.log – Error = 0xc8000438

Leave a comment

After deploying software updates to a collection the following State ID appears on the report titled: “States 1 – Enforcement States for a deployment”

State ID – 3010006 – “Failed to install update(s)”

When reading the WUAHandler.log file of a machine contained within this report, the following entries are found:

Async searching of updates using WUAgent started.
Async searching completed.
OnSearchComplete – Failed to end search job. Error = 0xc8000438.
Scan failed with error = 0xc8000438.

When noting the time stamps on the first two lines from the above entries, the times are generally seconds apart.

I have found that this is usually an indication of a corrupt or outdated Windows Update Agent. Installing the new agent, followed by an update scan or application will usually solve the issue.

The latest Windows Update Agent can be found here: (scroll to the bottom of the pages for the manual downloads)

http://support.microsoft.com/kb/949104

Featured, SCCM 2007, Status Messages

SCCM 2007 – Status Messages – SMS_MP_CONTROL_MANAGER

Leave a comment

Just a short note to align some field names. Within status message reports, you may occasionally receive messages which reflect an item referred to as a “GUID.”

For the purposes of reporting:

Status messages referring to client “GUID’s” are referring to the field name, “v_R_System.SMS_Unique_Identifier0.”

Personally, I think they should rename the message so that it states something other than GUID, since there are variables wiithin the SCCM database which are referred to as GUID – which can be somewhat confusing to those initially diving into the views.

OSD, SCCM 2007, Troubleshooting

SCCM 2007 – OSD Troubleshooting – Task Sequence WMI queries on computer models returning false results

Leave a comment

I’ve written a few items concerning adding WMI queries to driver packages within the OSD task sequences within SCCM2007. Recently I hit a snag which was somewhat perplexing until I decided to browse the WMI with several different tools.

Generally, I’ve taken to browsing the WMI on various computers models with SCCM Client Center as it is very good, all-purpose tool. As I was building a model injection task sequence for Windows 7 (x64) I discovered that none of my WMI queries for Win32_ComputerSystem.Model were functioning. Where they had performed flawlessly in Windows XP they were failing in Windows 7.

For example:

Running the following query on an OptiPlex 755 returned a 0 value. (I’m using a 755 so testing the query locally via the SCCM console was a good method of verification.)

SELECT * FROM Win32_ComputerSystem WHERE Model = “OptiPlex 755”

For testing purposes, I changed the = to a LIKE and just left the remainder as “OptiPlex%” which returned a positive result. Additionally, changing the remainder to “OptiPlex 755%” also yielded a positive result. At this point I knew that something was different in the way this particular class was either registered within Windows 7 or something was different in the way it was read.

Using SCCM Client Center yielded a value of “OptiPlex 755”. I decided to go download the old WMI Administrative Tools app from Microsoft (located – http://www.microsoft.com/downloads/details.aspx?FamilyID=6430f853-1120-48db-8cc5-f2abdc3ed314&displaylang=en) to see what it would yield. Lo and behold, the value was “OptiPlex 755 ” – the spaces being 17 in total. I tested this by inserting 17 spaces into my query and the result came back positive.

My recommendation at this time, in order to save people the trouble of checking each model in their environment for the number of spaces, is to change the query to the following: (insert your computer model where OptiPlex 755 is in the query below)

SELECT * FROM Win32_ComputerSystem WHERE Model LIKE “OptiPlex 755%”

If this fails on any particular machine, I will post here, and would appreciate readers doing the same.

Losing hair daily in the name of technology