Hi guys, I'm tearing my hair out with a problem and could really do with some help! Scenario: Currently have one OSD Task Sequence which caters for bare metal and refresh scenarios. The Task Sequence is error free and works well in both scenarios. The collection I advertise the Task Sequence to will cater for bare metal and refreshes. The advertisment is set to mandatory, ASAP and always rerun, which gives me the ability to bare metal and rebuild using the same collection, regardless of success or failure. I prestage my collection using Computer Association imports for bare metal. Towards the end of the Task Sequence, I have a custom script that works out the Collecion ID (using the Advertisement ID TS variable) and the Resource ID of the computer. The script then removes the computer from the Collection and updates the collection membership to make sure it's gone. This should mean that when the computer completes a PXE initiated TS, it won't receive the advertisement because it's not in the collection, right? Wrong! Within 5 minutes of restarting out of provisioning mode, the TS starts again, even though the computer is not in the Collection and has no advertisements assigned to it on it's properties. I have checked and double checked all my advertisements, and there is only one for the TS and it is only assigned to the build Collection. I've got absolutely no idea how this can be possible - as anyone got any suggestions on this? As always, your help is greatly appreciated! UK Based Integration Specialist

try and remove the alvays rerun part of your adv!Michael Petersen http://blog.coretech.dk/mip/

Thanks Michael for your reply - the only other suitable option for me would be 'rerun if successful' to fit in with our rebuild model. Surely this would have the same effect? I'll try it when I get back to the office tomorrow (I'm not sure I haven't tried it already though) What I can't understand is why it is trying to re run the program when it is no longer in the build Collection - it's the exact reason why I have written the removal script. Weird.UK Based Integration Specialist

Nope, sorry, that hasn't worked - I set it to 'Re run if successful', verified that the computer was removed from the build collection using my script and it still re runs the advertisement within 5 minutes of the TS completing. It shouldn't be receiving an advertisment full stop. How can an advertised program re run on a computer that is not a member of the collection that the program is adverised to? The only way that this could possibly happen is if the advertisment is received before I remove it from the Collection at the end of my TS - but this surely can't be possible if the SCCM client is running in provisioning mode? Completely stuck here I'm afraid!UK Based Integration Specialist

try and run your remove script as the first step after "setup windows and config.mgr" by the way, is it XP or 7??Michael Petersen http://blog.coretech.dk/mip/

I can think of two things that could cause this. 1. The collection where the TS was advertised is "dynamic". That is, it is based on some query. The members of this collection are added or removed each time the collection is evaluated. 2. The TS is advertised to another collection (e.g., All Systems).

Hi guys thanks for your comments. Michael - I have moved the script to just after 'setup windows and config mgr', confirmed that the computer has been removed from the Collection. 5 minutes after completing the Task Sequence (successfuly) the Task Sequence started re-running. I am on XP Kerwin - that is exactly what I thought right at the beginning of this saga. I can confirm that the Collection has no dynamic query and the TS is not advertised anywhere else. I've done a bit of digging In execmgr.log I see the following: Policy arrived for parent package <SITECODE>00016 program *.. (This is the Task Sequence) The created request is a Task Sequence request... Mandatory execution requested for program * and advertisement <SITECODE>20013 (This is the advertisment, so I know it is the same one) I have noticed I can stop the execution if I do a Machine Policy Retrieval before the Task Sequence re runs. In exemgr.log I see the following if I do this: Deleting request from pending queue, package <SITECODE>00016 program *, advertisement <SITECODE>20013 My question is, why is it necessary to do a manual policy retrieval after the client has come out of provisioning mode from OSD? Surely when the SMS Agent service starts after OSD has completed , it will cycle through all the applicable actions. To me, it looks like something is being set right at the beginning of OSD which means it will look to run the TS again after completion, before it has a chance to do a policy refresh and realise the advertisement is no longer valid. It doesn't seem to matter when I remove the device from the build collection, something seems to be cached and wants to run! Any ideas guys? UK Based Integration Specialist

Hi guys thanks for your comments. Michael - I have moved the script to just after 'setup windows and config mgr', confirmed that the computer has been removed from the Collection. 5 minutes after completing the Task Sequence (successfuly) the Task Sequence started re-running. I am on XP Kerwin - that is exactly what I thought right at the beginning of this saga. I can confirm that the Collection has no dynamic query and the TS is not advertised anywhere else. I've done a bit of digging In execmgr.log I see the following: Policy arrived for parent package RP100016 program *.. (This is the Task Sequence) The created request is a Task Sequence request... Mandatory execution requested for program * and advertisement RP120013 (This is the advertisment, so I know it is the same one) I have noticed I can stop the execution if I do a Machine Policy Retrieval before the Task Sequence re runs. In exemgr.log I see the following if I do this: Deleting request from pending queue, package RP100016 program *, advertisement RP120013 My question is, why is it necessary to do a manual policy retrieval after the client has come out of provisioning mode from OSD? Surely when the SMS Agent service starts after OSD has completed , it will cycle through all the applicable actions. To me, it looks like something is being set right at the beginning of OSD which means it will look to run the TS again after completion, before it has a chance to do a policy refresh and realise the advertisement is no longer valid. It doesn't seem to matter when I remove the device from the build collection, something seems to be cached and wants to run! Any ideas guys? UK Based Integration Specialist

any clues about your theory revealed in your smsts.log, particularly at the beginning phase just after you start deploying ? My step by step SCCM Guides I'm on Twitter > ncbrady

Hi Guys Wanted to post an update about this, rather than leave it hanging. After some investigation, I have come to the conclusion that, even though the SCCM client is supposedly in provisionig mode (HKLM\Software\Microsoft\CCM\ccmexec\ProvisioningMode="False"), it seems that policies are being pulled down to the client. During the OSD Task Sequence, I monitored the PolicyAgent.log for activity, and noticed (about quarter the way through) that it stared downloading policies. A quick search through the log located <SITECODE>00016 <SITECODE>20013 as one of the policies downloaded. I confirmed that I was still in provisioning mode - I supposedly was. A quick check in wmi (root\ccm\policy\machine\requestedconfig\CCM_Policy_Policy4) showed the PolicyID in place and waiting. When the machine completed OSD (and part of this was my script that removed it from the build collection) and was in full OS, the exegmgr.log immediately showed the processing of the Task Sequence - then the client started rebuilding almost straight away. It seems that after exiting OSD, the client doesn't have a chance to do a machine policy refresh before the local WMI store is processed. If I run a machine policy refresh before the processing was complete, I could avert the re-run as a refresh removed the policy from the local WMI store (as the computer was no longer in the build collection). I've now updated my build collection script so it a) removes it from the correct collection (based on advertisement ID using a TS variable) b) forces a machine policy refresh and c) waits for the instance in the local WMI repository to disappear (if it exists). I'm still in the process of testing the script, but once I am happy with it, I will post it on here. My final question on this, is why is the client doing a policy refresh during OSD when the SCCM client is in provisioning mode? Has anyone else encountered this behaviour? Fyi my OSD Task Sequence has quite a few steps after the install of the client and can take up to 45minutes to complete, and there is potential that something triggers this in one of the steps (but I can't think what at the moment) UK Based Integration Specialist

well could it be a netlogon script running which is installing the SCCM client ? or a GPO ? have you ruled out both possibilities yet ? My step by step SCCM Guides I'm on Twitter > ncbrady

I saw this same behaviour before on other posts. Just create a non-dynamic collection for Mandatory OS Deployments, and place the advertisement on that collection. After deployment with Mandatory OSD, a timestamp must be placed on the object. Just make sure that the new object isn't placed in the same non-dynamic collection. Also make sure that no Mandatory advertisement is active on the "All unknown computers" collection. Here are a few posts with rerun behaviour: http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/Systems_Management_Server/Q_25090543.html http://social.technet.microsoft.com/Forums/en/configmgrosd/thread/b2446425-a5a3-4ffc-b6bb-6ab86ff9724c http://social.technet.microsoft.com/Forums/en-US/configmgrosd/thread/36a4df70-7265-42eb-ad36-4bca49d571f3/ My ConfigMgr blog: http://henkhoogendoorn.blogspot.com Follow me on Twitter: @henkhoogendoorn

Guys, thanks for your suggestions - I think I've figured out why it is doing a full Machine Policy Refresh during OSD and I'm a bit embarassed to say it was my fault entirely! One of my OSD tasks runs a 'WSUS pre flight check' script to ensure the computer being built is in the correct WSUS collections before it runs the Software Update task. I recycled the code from a script I had written for Task Sequence's that were run on already build machines (to customise them). One of the sub-routines in there, you guessed it, forced a machine policy refresh. I removed the sub-routine from the script and, hey presto, no unplanned rebuilds! My removal script now just removes it from the collection before the OSD build has completed. I can have the advertisement Program re-run behaviour set to Always rerun with absolute confidence now. I've certainly learnt a lot from my investigations, even though it was from an issue I had introduced. Cheers allUK Based Integration Specialist