I am rolling out an SCCM 2007 SP2 infrastructure in a multi-forest environment. All SCCM Servers will reside in forest A and SCCM clients will reside in forest B (for now). Forest A and B will have bi-directional trusts. In the near future, clients will be moved to forest A. Does this action (moving computers, witout re-installing the OS, in another forest) will trigger a change of SMSID on the client? My issue is that the are a great number of direct-membership collections that will need to be managed if the SCCM client modify it's SMSID... Thank you, Richard

I don't think ANYTHING causes the GUID to automatically update. I was under the impression duplicate GUID's were automatically corrected until a recent client had improperly installed the client in their images I foudn out the hard way that they do not auto correct.John Marcum | http://www.TrueSec.com/en/Training.htm | http://myitforum.com/cs2/blogs/jmarcum

Hi John, The GUID / SMS ID will change on events such as hardware modifications. If a certain number of hardware devices are modified, the sms/sccm client will trigger an SMS ID change (ref: KB837374) Richard

I stand corrected. I can tell you though from personal experience that they don't change if someone puts the client in the image. John Marcum | http://www.TrueSec.com/en/Training.htm | http://myitforum.com/cs2/blogs/jmarcum

I am not sure if I understand this sentence:"This process works only if a change was detected by the SMS 2003 advanced client. If the SMS 2003 advanced client has a non-unique Smscfg.ini file, no change is detected and the SMS 2003 advanced client continues to use the original SMSID"A non-unique SMSCFG.ini is what causes the duplicate GUID problem because someone add the client into the image and didn't remove the cert. So in this case, which was what I was experiencing, if I understand this correctly the expected behavior is for the GUID to remain the same. Anyway, this is not related to the original question whether changing the domain would generate a new GUID. I still say that it will not cause a new GUID to be generated.John Marcum | http://www.TrueSec.com/en/Training.htm | http://myitforum.com/cs2/blogs/jmarcum

Hi John,I agree that the sentence in the article is not clear. However I think that the "non-unique" smscfg.ini file stands for a smscfg.ini file that has been tweaked by the SMS Transfer ID utility (TRANGUID.EXE). Using this utility on an smscfg.ini file will strip the Hardware key and prevent the client to change its SMSID.Back to the original question, thanks for your input : I will test the scenario when i'll have the test environment.Richard

I "think" non-unique smscfg.ini means one that was captured and deployed as part of the imaging process. I could very much be wrong though. I can tell you that duplicate GUID's from improper imaging do not auto-correct. I have been fighting that for weeks.John Marcum | http://www.TrueSec.com/en/Training.htm | http://myitforum.com/cs2/blogs/jmarcum