Hopefully someone can make some sense of this and point me in the right direction. I am new to SCCM and do not know exactly how everything works yet or where to begin looking to troubleshoot this issue. If this should be posted in another forum please let me know and I will try to re-post. I thank you in advance for any information you can provide. Background: SCCM 2007 R2 SP2 running on Server 2008 R2 We have about 2500 notebooks/desktops all running XP Pro SP3 About 25 different models of notebook/desktop in all and each with a model specific image All images are created using the same volume media and other than hardware the images are configured identically. All task sequences are configured identically. Everything works great except one model of notebook, the HP ProBook 6545b. This also happens to be our only AMD system and we have about 400 of these units. Problem: After a 6545b has been imaged it boots up with the computer name of an existing computer account in AD that also happens to be a 6545b. Of course this can cause major problems if we have the task sequence set to join the domain automatically, so we set the task sequence to join the workgroup and then manually join the domain after imaging/renaming. We found this to be an acceptable workaround, but would prefer to resolve the issue so that we can join the domain automatically via the task sequence. This happens with both new and existing systems previously imaged with SCCM. However, it does not happen consistently, maybe 95% of the time and we have been unable to identify any pattern as to why this happens (or doesn't happen). The sysprep.inf file is configured as follows: ComputerName=* and in our Task Sequence we are migrating the following: Computer Name, registered user and org. names, timezone and network adapter configuration. We are not migrating domain and workgroup membership in the task sequence. This task sequence configuration (as well as systprep.inf config) is identical to all other task sequences for all other models that work fine. I just completed rebuilding this image from scratch in case something went wrong with the build but we are still experiencing the problem. Additionally, this "master" image is used to create a few other specialty type images and those exhibit the same problems as well. The only thing that stands out to me is that this is our only AMD system, but not sure how that relates to the naming. Also, sometimes it seems like the computer will take the name of another 6545b that was recently joined to the domain, but not always. Is there anything special that needs to be done for an AMD image?

How did you create your images? Are they syspreped?Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys

Yes, the images are sysprepped. Specifically, the sysprep folder (including sysprep.inf file) is copied to c:\. Next, a capture cd is run to capture the image. Then when the image is deployed there is an option in the "Apply Operating System" section to "user an unattended or sysprep answer file for a custom installation" but we leave that option disabled. Once the image has been applied the system reboots and runs through sysprep mini-setup using our sysprep.inf file from c:\sysprep. This process is used for all other models using an identical sysprep.inf file, capture cd and task sequence and we do not have this problem.

In your "gold" image that you use for your deployments is the SCCM client installed and pointing to your management point? I have seen some odd behaviours in the past if the client was already installed in the initial image. Just a thought. Robert

Yes, the SCCM client is installed on the image. However, it is not pointed to the management point or is not currently assigned to a site code. It is installed/configured identically to all other images that do not have this problem.

Have you verified that these systems have unique SMBIOS GUIDs and MAC Addresses?Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys

Jason, thank you for the reply. Can you please clarify the best way to check for duplicate smbios guids? Should I check in BIOS and compare UUID between the imaged system that takes on the name of the existing system, and the existing system? I am assuming by the time an sccm record is created for the newly imaged system the issue has already been resolved so comparing System UUID in sccm at that point will not be helpful. Also, another piece of info. that I left out previously... after imaging and sysprep mini-setup the system comes up with the name of an existing system and I said that we then manually join the domain. I left out the step where we re-sysprep before manually joining the domain. If the imaged system comes up with the name of an existing system we re-sysprep and all is good because then it comes up with a generic name. Can anyone clarify at what point in the process the smbios guid is used? Thank you - twlz

Is your site in mixed or native mode?Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys

Mixed mode.

At this point, we've pretty much rules out anything that I can think of -- this is not normal behavior and or we're overlooking something that is difficult to discover in a forum. I recommend contacting CSS.Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys

Jason, or anyone else, I still have a couple of unanswered questions above regarding the SMBIOS GUID, UUID and which point in the process the UUID comes into play. I was also wondering if the fact that re-sysprepping one of these systems corrects the issue does that rule out the duplicate SMBIOS GUID issue? I will be re-imaging some of these systems in the near future and when it happens again will compare the UUID of the imaged system to the UUID of the system it took its name from.

One quick question to clarify a previous statement above. You said you use a capture CD, which capture CD? The one generated by ConfigMgr?Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys

Correct, we use the capture CD generated by ConfigMgr.