well you could use optional task sequences instead or try using dedicated Deploy collections where objects are only added to the collection when they are due to get an OS deployment, My step by step SCCM Guides I'm on Twitter > ncbrady

I'm normally create a new ZTI collection for advertising a ZTI Task Sequence. Putting all devices in that collection manually prevents that they will synchronize in that specific collection again after deployment. This because (like you wrote) other collections will synchronize with Active Directory. This seems the easiest way for me to manage. With ConfigMgr R2 implementation I'm using Right Click Tools for getting (multiple) devices at once in a ZTI collection. With ConfigMgr R3 it becomes even easier. Then just right click on on a device or collection for getting (multiple) devices in a ZTI collection. Other possibilities are make a collection temporarely a subcollection of the ZTI collection (New -> Link to Collection), and set the advertisement to "Include members of subcollections". That way devices don't will be placed in that collection after deployment, but in the collection which being bound to Active Directory. Because it's creating a copy of the original collection, that subcollection can be deleted safely after deployment. (not tested it myself, but it could work!?) Another possibility is (like you wrote) to set a expiration date on the advertisement for a few hours (for example). Because ConfigMgr R2 will synchronize default once a day, just make sure the expiration date on the advertisement is finished before synchronizing begins. My ConfigMgr blog: http://henkhoogendoorn.blogspot.com Follow me on Twitter: @henkhoogendoorn

Hi, You could merge the SCCM client objects instead of creating a duplicate record after the reimaging, that should solve it aswell.. Here are a guide to how to trigger a script which will merge the objects ..http://ccmexec.com/?p=1047 Regards, Jörgen -- visit my System center blog at http://ccmexec.com --

Bring up the properties of a tasksequence, advanced tab and set "This task sequence can run only on the specified platform" to an OS that's not used in your environment (for example Win2k). The advertisement will then be received by the re-imaged clients, but it will be rejected then.Torsten Meringer | http://www.mssccmfaq.de

I normally create a new ZTI collection for advertising a ZTI Task Sequence. Putting all devices in that collection manually prevents that they will synchronize in that specific collection again after deployment. This because (like you wrote) other collections will synchronize with Active Directory. This seems the easiest way for me to manage. With ConfigMgr R2 implementation I'm using Right Click Tools for getting (multiple) devices at once in a ZTI collection. With ConfigMgr R3 it becomes even easier. Then just right click on on a device or collection for getting (multiple) devices in a ZTI collection. Other possibilities are make a collection temporarely a subcollection of the ZTI collection (New -> Link to Collection), and set the advertisement to "Include members of subcollections". That way devices don't will be placed in that collection after deployment, but in the collection which being bound to Active Directory. Because it's creating a copy of the original collection, that subcollection can be deleted safely after deployment. (not tested it myself, but it could work!?) Another possibility is (like you wrote) to set a expiration date on the advertisement for a few hours (for example). Because ConfigMgr R2 will synchronize default once a day, just make sure the expiration date on the advertisement is finished before synchronizing begins. My ConfigMgr blog: http://henkhoogendoorn.blogspot.com Follow me on Twitter: @henkhoogendoorn

All our collections were created in a way that mirrors our AD structure. Our AD structure is divided down to physical rooms. At the moment, if we want to re-image a whole room, we create a mandatory advertisement set it to never re-run and link it to the collection mirroring the AD structure. The PCs are re-imaged with the same name, which means the old computer object in AD is used. However, a new object is created in SCCM for the newly imaged computer. As a new object is created in SCCM for the computer that has just been re-imaged, and seeing as it the computer object in AD is in the same OU as the "old" one was, it will make its way to the same collection, which then means it will receive the same mandatory advertisement, causing the PC to re-image over and over and over again. How can we prevent this from happening? I know that the short answer would be to set a expiration on the advertisement, but there is no guarantee that all computers will have received the advertisement by the time the first one finishes. At the moment we are still running R2, so we have been able to get away with it due to collections only updating once a day. However, I can see this becoming a massive problem once R3 is installed and Delta Discovery enabled. Regards, Cogu

well you could use optional task sequences instead or try using dedicated Deploy collections where objects are only added to the collection when they are due to get an OS deployment, My step by step SCCM Guides I'm on Twitter > ncbrady That would defeat the point having collections that mirror the AD structure. Not a solution. Also, it has to be a mandatory assignment Bring up the properties of a tasksequence, advanced tab and set "This task sequence can run only on the specified platform" to an OS that's not used in your environment (for example Win2k). The advertisement will then be received by the re-imaged clients, but it will be rejected then. Torsten Meringer | http://www.mssccmfaq.de That would only make things worse: either PCs would never get re-imaged at all (not even the first time because they would still fail at the OS condition) or it would mean that we'd have to go round and manually PXE every single one of the computers and select the image we wanted to apply. It would just prevent it from being applied from within Windows, not actually fix the problem. Hi, You could merge the SCCM client objects instead of creating a duplicate record after the reimaging, that should solve it aswell.. Here are a guide to how to trigger a script which will merge the objects ..http://ccmexec.com/?p=1047 Regards, Jörgen -- visit my System center blog at http://ccmexec.com -- How would that cope with previous advertisements having been successfully deployed to the "old" computer? For example, if we had a mandatory software assignment of Adobe Reader for all computers in that collection, and they all stated Adobe Reader as having been successfully installed prior to the re-image, once they are re-imaged and the objects merged, does SCCM continue to think that Adobe Reader was already successfully installed (because it is the same object) or does it attempt to deploy Adobe Reader again because the computer has been re-imaged and therefore it doesn't have Adobe Reader anymore? Regards, Cogu

In my humber opinion, collections for deploying a mandatory OS should only contains computers that need the os deployed onto, or computers that have just been imaged, I would separate my Deployment collections (deployment of Operating Systems) from all other collections for this (and other) reasons, you could go ahead and try various fixes, workarounds etc but why bother, keep your OSD collections separate from the normal collections and you won't have this issue My step by step SCCM Guides I'm on Twitter > ncbrady

Hi, to answer your question above. "How would that cope with previous advertisements having been successfully deployed to the "old" computer? For example, if we had a mandatory software assignment of Adobe Reader for all computers in that collection, and they all stated Adobe Reader as having been successfully installed prior to the re-image, once they are re-imaged and the objects merged, does SCCM continue to think that Adobe Reader was already successfully installed (because it is the same object) or does it attempt to deploy Adobe Reader again because the computer has been re-imaged and therefore it doesn't have Adobe Reader anymore" The answer is NO. The SCCM client on the computer will process all mandatory advertisements as it has not run on that client before. If you want to solve your above issue with ADobe you should advertise Adobe to a query based collection where only computers without Adobe Readers are members. I agree with Niall as well, I would keep the OSD advertisement in separate collections with the single purpose of OSD. Regards, Jörgen-- visit my System center blog at http://ccmexec.com --

Keeping a separate collection means doing a direct membership collection. If we are talking about re-imaging 100 computers there is no way I am going to manually add 100 computers to a collection. If we don't do direct membership, that is going to be exactly the same query as we have now: all computers in a particular OU. Which will also mean it will have exactly the same issue we have now: after re-image, because they re-use the same AD computer object they effectively are in the same OU, which means the new SCCM object for that computer will see the task sequence as something it needs to do and keep doing it over and over again. Actually the whole thread is kind of futile. The reason why they kept re-imaging themselves was because someone remembered it would be a good idea to have a second mandatory advertisement targeted at the same collection. Effectively what was happening was: CompA gets mandatory task sequence TS1. It completes successfully, creates a new object on SCCM called CompA-1, old SCCM object CompA-0 changes to obsolete. CompA-1 states that TS1 was successfully completed. TS1 is set to never rerun. Mandatory task sequence TS2 gets created and assigned at CompA. CompA-1 says TS2 has never run and therefore sends it to CompA. It successfully completes and creates a new object on SCCM called CompA-2, old SCCM object CompA-1 changes to obsolete. CompA-2 states that TS2 was successfully completed. TS2 is set to never rerun. Whilst evaluating the machine policy for CompA-2, it realizes that TS1 is mandatory and has never run. So it runs TS1, creates a new object, sets the old one as obsolete etc etc etc bla bla bla, all over again. Provided only one mandatory task sequence is assigned to a computer/collection at any given point in time, the new computer object that gets created in SCCM is the one that says the TS was completed successfully. This is because the SCCM client that gets installed during the TS (which is what causes the new SCCM object to be created) is installed prior to the TS finishing completely. So it will go something like... Start in PE, Apply OS, Install SCCM Client (which causes a new SCCM object to be created), Apply post-build configuration - send information to SCCM to say TS was completed successfully. Because the "success" flag came from the "new" client that was installed, it will be associated with the "new" SCCM object that is linked to the client. That prevents it from being re-imaged over and over. However, that also means that on the "old" SCCM object it will say "started" this TS but there is no information about whether it failed, succeeded or anything else. As far as that information goes, it things it is still running.

since when does having a separate collection force you to use direct membership ? you can create a query to query yet another active directory security group to add computers in there, or you can use other methods to populate the collection I still think now is a good time for you to look at your SCCM design and rethink things a bit, decide how its best to deploy systems and keep that part of your collection structure separated from your daily use systems, otherwise you might just end up imaging a room by accident My step by step SCCM Guides I'm on Twitter > ncbrady

Having a security group where you add computers to - again requires manual intervention. And it is not like drag and dropping a group of objects which is what you can do to place computers in an OU. Besides, that's implementing a workaround to help yet another workaround work "better". Don't get me wrong, I never said I was linking it directly to the collection structure that is used for any other daily activities. What is being done is create a "blank" collection called something like "PCs in here will get re-imaged automatically" and then linking the room collection that I want re-imaged into that collection. Besides, if you read my original question again, had the issue that I originally described been true, anything short of a collection with direct membership would have still caused the PCs to re-re-image themselves with no end. Adding the AD computer object to a security group would have made no difference because we are reusing the old AD computer object, meaning that after the computer gets re-imaged it is still a part of that same security group, which in turn means that if the originally described issue was true, it would have still tried to re-re-image the same machine afterwards, because the "new" PC is still part of the security group that says "everything in here gets re-imaged ASAP" and SCCM doesn't know it has already done that PC....