SCCM OSD - Duplicate systems in Console after OSD
Hello all!I am using SCCM OSD to install Windows XP and all the programs we need. Most of the process is working great, except for the fact that after the computer is completely built and the Task Sequence has finished running, I see 2 system objects in the All Systems collection for the computer. One of the objects is approved, has client etc., but the other is not approved and has no client.I know I can just delete the not-approved object, but I am trying to keep the administration overhead of our imaging process to a minimum.One note: I use a GetComputerName vbscript to prompt the technician for a computer name during the task sequence. I am suspicious that this may have something to do with my problem. Anybody have experience or any tips? Thanks in advance!
January 7th, 2010 12:27am

Was this a pre-existing system in the environment? I have seen something similar occur when imaging a pre-existing client, a new Client ID is generated instead of using the old one, and this creates the second entry.Scott Gill SCCM Consultant
Free Windows Admin Tool Kit Click here and download it now
January 7th, 2010 3:14am

Well...kinda. I have been using the same system for testing OSD, but I have been deleting the SCCM and AD objects each time before I reimage the machine.
January 7th, 2010 5:04pm

Can you image a brand new machine that hasn't been in the SCCM environment to see if the issue still occurs?Scott Gill SCCM Consultant
Free Windows Admin Tool Kit Click here and download it now
January 7th, 2010 8:07pm

OK, I have imaged a brand new, fresh out of the box machine, and I still have 2 objects with the same name in the console. One has a client and is approved, and one has client:no, approved:N/A.ANy ideas?Thanks for your help.
January 8th, 2010 6:28pm

sounds like one is obsolete, what is the obsolete= status like ? My step by step SCCM Guides Follow me on Twitter
Free Windows Admin Tool Kit Click here and download it now
January 8th, 2010 6:31pm

sounds like one is obsolete, what is the obsolete= status like ? Yes, I'm certain one is obsolete, but this does not address the core issue... This should not be happening on a brand new out of the box machine that has never been connected to SCCM before.Scott Gill SCCM Consultant
January 8th, 2010 8:45pm

What does your TS look like? Do you have a step that installs the SCCM client or messes with the certificates?Scott Gill SCCM Consultant
Free Windows Admin Tool Kit Click here and download it now
January 8th, 2010 8:46pm

Not to hijack the thread, but I'm having the same issue (I think). It happens for me when the computer joins the domain during OSD and an AD system discovery runs before the client on the machine registers and heartbeats in to the MP. If the AD discoveries run after the client does the MP_ClientRegistration and Heartbeat discovery it only has one record. But if the AD discovery runs between the the time the TS binds the computer to AD and the ConfigMgr client talks to the MP I'll have 2 systems in the console with the same name. One will have the client and one will be found by the AD system discovery. If I delete the duplicate that doesn't have the client, the next time AD discovery runs, it adds the information to the existing computer.It is a small AD implementation, so I was running discovery hourly. Since I backed it off to every 2 hours it doesn't happen (since it is less likely discovery will run during the time between the binding and the client checking in), but I can force it to happen by manually running a discovery after the computer has been joined and before the client talks to the MP (since discovery takes about 90 seconds). I don't see this in my larger production domain, but it is at ConfigMgr SP2 R2 and the domain I'm seeing the issue in is still at ConfigMgr SP1 R2. They are both in native mode.Thanks! Joe
January 8th, 2010 9:05pm

Running AD discovery that often is unnecessary. The purpose of AD discovery is to bring in computers that for some reason haven't been provisioned with OSD, or some other method that automatically installs the client, or computers that were randomly joined to the domain by a user/IT admin without the client being installed. In a "perfect" world AD discovery wouldn't even be necessary after a couple of months with SCCM running as all clients would be installed and no new clients would appear in the environment without the client being installed.Anyway, just set your AD discover to once a day or week and you won't have the issue.Scott Gill SCCM Consultant
Free Windows Admin Tool Kit Click here and download it now
January 8th, 2010 9:14pm

Definitely doable. Thanks for the insight. Do you know of how to prevent the issue I'm seeing though, beyond reducing how often AD system discovery runs. We run a widely distributed IT support structure that we are working on bringing under management (I work for a University). Is there a way I can eliminate this issue, with turning AD system discovery off? Or would you recommend to just turn it off, since we install the clients with a startup script?Thanks! Joe
January 8th, 2010 10:38pm

Scott - Yes we have a step to install the ConfigMgr client.Joe - Yes I think the AD Discovery must be running during the OSD TS, which is causing my problem. We have AD discovery set to run every 15 minutes because we are not yet using SCCM OSD for our image deployment (we are still in testing). Currently we use Ghost images, and we want the systems to get Software Updates ASAP, so we needed the systems to be discovered, client installed, etc ASAP. Once we go full production with SCCM OSD, it sounds like we could dial back the AD Discovery to something more reasonable, and this may eliminate my duplicate objects problem.If only my boss would spend the money to give me an SCCM Test environment I could test this out and let you know!Thanks alot for your help. I will try to test this in our production environment and post the results here.
Free Windows Admin Tool Kit Click here and download it now
January 8th, 2010 10:55pm

You don't have to completely turn it off, just reduce the time to once a day. You're talking about a very narrow window of time between when the machine is joined to the domain and when the client is properly installed via the TS (I'd say about 5 minutes max) so the AD system discovery would have to run during this window for this issue to occur. If it's set to once a day (at night) it's very unlikely this will happen.Scott Gill SCCM Consultant
January 8th, 2010 10:57pm

I am going to test with all discovery methods turned off during the period the OSD TS is running and see if the problem is eliminated. At least then I will know if it is in fact the discovery that is causing the issue.
Free Windows Admin Tool Kit Click here and download it now
January 8th, 2010 11:40pm

Be sure to keep in mind the first issue we tackled here which will cause this to happen if the machine is already in the SCCM environment -- old entry becomes obsolete and new entry created.Scott Gill SCCM Consultant
January 8th, 2010 11:44pm

Actually, I'm not seeing an obsolete object. This is what it looks like:Name ResourceType Domain SiteCode Client Approved Assigned Blocked Client Type Obsolete Active==============================================================================COMP1 System MyDomain 123 No N/A YesCOMP1 System MyDomain 123 Yes Approved Yes No Advanced No Yes (I hope that displays OK on your screen)
Free Windows Admin Tool Kit Click here and download it now
January 9th, 2010 12:51am

That report that you have there is what I saw. Check the properties of the computer without the client. See if the AD system discovery populated the computer in ConfigMgr and it doesn't show up (AD system discovery) for the computer with the client. But that should come to light if the second object doesn't show up anymore once discovery is set to once a day.Thanks! Joe
January 9th, 2010 3:18am

The obsolete issue only applies to machines that were previously in the SCCM DB and were re-imaged using PXE or a boot DVD/USB. I think both of your issues can be traced back to AD System Discovery, setting it to run at night should eliminate the issue.Scott Gill SCCM Consultant
Free Windows Admin Tool Kit Click here and download it now
January 9th, 2010 5:50am

Prior to reading this thread, I thought that AD system discovery was required to find machines. As part of my OSD I am installing the client, and I am wondering why it can take 6+ hours sometimes for that client to appear in the console and be approved, and get advertisements? My clients are set to update their policy every 20 minutes. My collections are also based upon AD OU. Does configmgr determine a computers OU from AD System discovery, or by running an inventory through configmgr client? I have a few collection based upon model number, these can take 2-3 days to populate. How can I speed up new system detection after OSD? Also, whenever I deploy a new OS to a machine it always makes a duplicate record, one marked obsolete. I set configmgr to just delete old machines after 2 days which keeps it clean, but if I understand this thread, is that not supposed to happen when doing an in place OSD? What do I have set wrong? If the machine is reimaged through the windows client vs. PXE booted does it make a difference? If the TS is executed through windows does it keep the same SMSID? Thanks A lot!
January 9th, 2010 10:47am

Prior to reading this thread, I thought that AD system discovery was required to find machines. As part of my OSD I am installing the client, and I am wondering why it can take 6+ hours sometimes for that client to appear in the console and be approved, and get advertisements? My clients are set to update their policy every 20 minutes. Nope, AD system discovery is only required to find machines that don't have the client installed. SCCM is basically made up of hundreds of unrelated "cycles" that all do their own thing. For example, for a client to be detected, it first has to be installed, then the client goes through a cycle of finding the correct site to assign itself too. Once this happens, there are cycles in place for determining if the client can join the site, is in the correct boundaries, etc. Then for inventory, it has to kick off both the HW and SW inventory cycles (also unrelated) to load that data into files and throw them on the MP. On the server side there are cycles that take the HW and SW inventory files and convert them into data that can be put into the DB (there are also DDR's generated for the client to be put into the DB in the first place -- skipped a step there). Then you have collection evaluation cycles, each collection's cycle is independent of the others, this determines when the client will appear in the collection. There are plenty more cycles, but I'm going to stop there as I think you can start to see why it could take time for the client to show up in the console. Generally, I'd say wait until 20 mins after the TS is complete, and then do an update collection membership on the collection, and chances are, you will see the client. My collections are also based upon AD OU. Does configmgr determine a computers OU from AD System discovery, or by running an inventory through configmgr client? I have a few collection based upon model number, these can take 2-3 days to populate. I believe I saw somewhere that this data is based on AD System Group Discovery. But again, we're back to cycles here, AD discovery runs, then collection update cycles, I could easily see this taking 2-3 days to occur. EDIT: I should have said I could easily see this taking 2-3 days without "Help" or additional configuration (just using default daily update cycles). How can I speed up new system detection after OSD? As mentioned above, chances are you'll see the client shortly after the TS is done, but you just need to do an update collection membership. Also, whenever I deploy a new OS to a machine it always makes a duplicate record, one marked obsolete. I set configmgr to just delete old machines after 2 days which keeps it clean, but if I understand this thread, is that not supposed to happen when doing an in place OSD? What do I have set wrong? That statement is slightly wrong... If you deploy a new OS via PXE boot, or CD/USB boot, the TS has no idea that the machine was previously part of the SCCM environment and will therefore generate a new GUID for the client. This results in the machine reporting into SCCM with the same machine name (or it could also be a different machine name), but a new GUID, and SCCM will work out that this new machine is the correct one, while the old one is obsolete. To get around this, you have to run the TS via Run-Advertised Programs (or via a Mandatory advertisement, that kicks off while the machine is still fully booted into the Windows environment) and have the step capture machine settings in the TS prior to rebooting into WinPE to start the image process. If the machine is reimaged through the windows client vs. PXE booted does it make a difference? If the TS is executed through windows does it keep the same SMSID? I was answering one question at a time, I believe I just answered this one above... Scott Gill SCCM Consultant
Free Windows Admin Tool Kit Click here and download it now
January 9th, 2010 8:14pm

Rybal,The AD system group discovery is the one that finds the OU of the object. Here's a link: http://www.myitforum.com/articles/42/view.asp?id=11264For it taking 2-3 days to get advertisements, if you nest your collections and left the default settings it's quite expected . If the collections are based on each other they won't update until the one above it updates, which the default is once a day. You could try shortening the time your collections update and that should speed your delivery.That's all I have to add to Scott's very thorough answer.Thanks! Joe
January 9th, 2010 8:50pm

Hey everybody, just wanted to post that I had the admin pause all discovery methods, then I built a new out of the box machine with SCCM OSD.After the OSD completed I only had one, approved client showing in the console. Great!I should note that the computer did not show up in the console until near the very end of task sequence. I was refreshing the console the whole time, and even after the step "Setup Windows and ConfigMgr", no object in the console. I am not sure exactly when it appeared in the console, but I did notice a message on the machine being built, right after a reboot, that said "initializing ConfigMgr client". I suspect this is when the object appeared in the console.Thanks for your help everybody.
Free Windows Admin Tool Kit Click here and download it now
January 11th, 2010 7:48pm

Where are the exact settings for AD Discovery that you were referencing. I am seeing the same issue, but it looks like all of our AD Discovery options are set to run nightly.Thanks,Allan
March 10th, 2010 12:31am

Site Database>>Site Management>>SITE>>Site Settings>>Discovery Methods
Free Windows Admin Tool Kit Click here and download it now
March 10th, 2010 5:13pm

Guys I dont think this has anything to do with discovery. ours is set to 10am and i reimaged (at 5pm) a laptop via sccm pxe and part of the ts is to add to the domain this will create a duplicate in the console. I think there could be something in running the ts from the os rather than just F12 the pc but will try this one.....
July 20th, 2010 11:11pm

Scott, I have this same issue also and I would like to point out that although I would like to stop/reduce the frequency of discovery of clients using the AD discovery task this is not always practically possible. We have quite a large and distributed organisation and therefore there are many AD layers where we place our computer objects. We have to pre-populate AD with the computer in the correct "OU" location in our tree otherwise if we didn't they would not receive the correct policies / setups due to them being in the default "computers" OU in AD. discovery method allows SCCM to work out the security group memberships also, but this does not work at the moment as I think my discovery method is too frequent and therefore picking up the DDR and hearbeat during an OSD build and then again once the client checks in on a completion of the build.
Free Windows Admin Tool Kit Click here and download it now
February 21st, 2011 8:24am

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

Other recent topics Other recent topics