[SCCM 2007] Maintaining the SMS Resource ID of a machine when redeploying the OS on it..possible?

[tarquel]

Hi all

Here's one I'm trying to work out (and there has to be a way....it may just be a matter of finding it hehe)....

When we rebuild a computer with a OS via SCCM, it creates a new resource ID during the process and the result is two computer resource objects in SCCM.

You may think, whats the big deal? just get the old ones deleted automatically with that maintainance setting to remove obsolete (and other) resource objects.

And you'd be right, however, thats fine when you dont need to / dont use SCCM to keep a inventory of your computers, but alas, we kind of need this system to do that, so I've got to find some decent way on how its possible.

I've seen that in SMS 2003, there was a tool in their toolkit called "Transfer SMS ID", although I've not used it, the description says "Transfers SMS client ID (GUID) from one computer image to another. You can use this tool to help support asset management and to avoid data loss during re-imaging."

The latter part of that sounds perfect, however, im just wonderings whether any of you good good people using SCCM have managed to figure out a way to do it, before I spent potentially countless hours figuring it out.

Also using the Deployment Web Service too in order (very handy, and maybe if i dig, theres a way to do it via that).

As normal, thoughts/ideas/complete noob guides welcome

Cheers y'all.
Nath.

[hofsteda]

Under site properties, Advanced tab, we have conflict management set to manual. This prevents new records from being created for the same hardware and instead creates an entry under conflicting records which we merge. This retains the history of the old object.

Here's a good link discussing the issue including why Microsoft doesn't automerge Elmunjos Blog: Managing conflicting records and duplicate GUIDs in Configuration Manager 2007.

[tarquel]

Thanks for the info but, as I'm sure your about to guess, I've already seen that.... however, for those using the manual merge way, this might be useful:

Obsolete objects - Reuse your ”Old” SCCM Client Objects in Mixed Mode - Windows Live

I think that the security aspect they mention is pretty lame, an "attacker".... from where? anyone using this system surely would have a very strong and secure network in the first place and are people really that bored to try and hack SCCM?

I'm probably having a "moment" but native mode will allow the use /merge of the same SMSID of the machine in question (with certificates and the like), but how does that prevent that same "attack" from taking place?

note: this isnt me having a go or rant as such, im happy to hear the answer

The inventory'ing SCCM does is really good, and includes if hardware has been changed (useful to see if someones sneakily opened up a machine to run off some memory modules etc) so its pretty backwards thinking if the data cant be transfered into the new SMSID (i'm assuming there that it isn't) when a machine gets a clean or refresh of the OS via SCCM, and its especially strange when the machine itself hasnt changed at all.

Other weirdness I notice is two (or more) resource objects with the same computer name... one that looks normal and one that is like its obsolete, but doesnt have any info in the "Blocked, Client Type, Obsolete, and Active" columns and the Client & Approved columns say No and N/A respectively. I'm guessing that these have been here for a while and due to the resource object no longer in use, the Client has changed from Yes to No, and its just sitting there stale, but hasnt been deleted by that maintainance task that clears the Obsolete objects.

I guess more random googling is needed to answer these things, and further scutiny of the SCCM blog is needed

Cheers
Nath

[hofsteda]

In native mode I believe the sccm certificate is available from AD using the machines credentials, which are reset when the machine is re-added to the domain, and this is used to confirm the machine's identity. I've seen the scripts that allow automerging but manually merging hasn't been an issue as it hasn't happened that often.

[tarquel]

That was the only thing I could assume it must be for. Heard that the setup can be a right pain in the particulars so stuck with Mixed.

Perhaps by not having that setting on, it will use the existing by default unless it reaches something that needs a manual decision and thus why you dont get them that often, whereas on the current setting, it'll always create a new SMSID.

I guess the best way is for me to just change it to manual and see what happens

I'll keep ya posted

[hofsteda]

The stale duplicates I deal with most are due to the way we deal with machines having hardware upgraded. We run AD discovery. When a new replacement machine is deployed, it is given a temporary name. When the machine goes out, it is renamed on top of the old machine in ad. The old ccm record is kept alive due to the ad discovery. The new record doesn't get discovered from ad once it is renamed since the dn is already tied to the old record. They show up as you describe with the assigned set to yes.

[tarquel]

ahhh i see.

That sorta explains that then.

I dont think we need anything like that. How it works here is if a user gets a new machine, then they get a new machine. The machines themselves are asset tagged by the manufacturer so the techies have the computername to use (handy but doesnt really mean anything) so a new machine will always result in a new AD comp obj and SCCM obj too. Thats not a prob and I doubt we're too bothered about migrating the SCCM inventory over from one phyiscal machine to a different named one.

Its pretty much only when a techie needs to deploy the OS again via SCCM (either cleanly from PXE or via Refresh - note we arent really doing Refresh at present but will need to look at that again). So I'm hoping switching to manual will help eleviate the issue, and like the blog above containing the script that you can use to run via a scheduled task, it might be enough.