Client unresponsive after OSD at a secondary site
This has me stumped. I don't know whether this is a client side problem or a server side problem or a both?? Our Site consists of 1 Primary Site + 5 Secondary Sites SCCM SP2 R2 Primary = Windows Server 2008 Std SP2 (FSP, MP, RP, SLP, SUP, RSP) Secondary = Windows Server 2003 Std SP2 (DP, PMP, PSP, SUP, SMP) The techs at one of our secondary sites have recently reported (in the last week) that after they OSD a Dell Optiplex 960 or Latitude E6400, the SCCM client never retrieves any software deployments or software updates even though they have been left online and connected for over 2 days. In the SCCM console, the computer shows up with blank entries in "Domain" and "Site Code" field. We've had to use one or a combination of the following to get the client working again: Manually "Discover" the site on the local computer Repair or Rebuild the WMI repository Re-install the client This only happens on 1 of our 5 Secondary sites and only affects the 2 models mentioned above, the 745, 755, D620 and D630 models are not affected. The hardware, software and OS of all the Secondary servers are the same. I've rebooted the server with no resolution success. Done the MPList and MPCert test and they look fine. Clientlocation.log and LcationServices.log has entries for the site code, MP and Proxy MP. Execmgr.log exhibits symptoms of a corrupt WMI repository (Failed to open to WMI namespace etc etc errors). Where else should I look?
June 10th, 2010 11:59am

Logged a call with MS. After some more investigation, it was found that the issue was only affecting unknown computers that had just completed an OSD. The MS engineer was able to replicate the issue in his lab and it was determined that the timezone difference between the Primary and affected Secondary was the culprit. Here is the details from MS: Problem When an OSD (bare metal build) has completed on a brand new machine, the SCCM client does not receive assigned advertisements or policies targeted to that machine, even if left connected on the network for several days. This issue only occurs in the Perth office, which is a Secondary Site with OSD capabilities. This issue is not observed on the Sydney, Melbourne or Brisbane Secondary Sites. Cause This problem is caused by the first Discovery DDR from the client is discarded due to the time difference. When an OSD deployment finishes, there would be one .UDR file sent to the Assigned MP(primary site), which stamps the heartbeat discovery time with the primary site’s time (GMT+10). Later, when the client sends the “real” heartbeat discovery data from the agent side, the heartbeat would be sent to the Proxy MP(secondary site MP) as the client belongs to the secondary site’s boundaries. Due to the Proxy MP being in the time zone GMT+8, it would generate the .DDR with its local time, which then forwards the .DDR file to its parent site. Due to the time zone difference, the .DDR file may be “older” than the original .UDR file time, this would cause the .DDR file to be discarded. Under this situation, the SCCM agent would show up as “Assigned=No” in the console, which causes this issue. Current Solution Change the heartbeat discovery cycle from 1 week to 1 day. When the next scheduled heartbeat discovery is due, the client would become assigned and begin receiving policies successfully. Or, manually trigger a Data Discovery Cycle on the machine 2 hours after the OSD completes.
Free Windows Admin Tool Kit Click here and download it now
July 13th, 2010 11:49am

I am having this issue. Is there any permanent fix for this?
March 8th, 2011 9:43pm

We changed the Heartbeat schedule to every 1 Hours. We only have 1 Site and about 2500 machines assigned to it, so the impact on the SCCM server and SQL server was negligible.
Free Windows Admin Tool Kit Click here and download it now
April 27th, 2011 2:23am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics