The question below was solved with the help of the accepted answer below. However, the actual cause of the problem was due to a bug. I have added another answer to this question below that contains the details of this bug as well as details on a hotfix solution that has been released.


At my organization we have a lab of computers that must be reimaged every week. We are currently doing this via SCCM 2007. At the moment this is done by creating a new mandatory advertisement each week for a working OSD task sequence (TS). However, I would like to do this by setting one advertisement on a recurring schedule.

In order for a TS to repeatedly run on a machine you must enable the advertisement option "Always rerun program" or the TS will only run the one time.

The problem I am running into is that when performing a reimage of the machine a new client gets installed and thus a new GUID is created. This means I must provide some automatic way to readd that new client GUID to the collection where the recurring TS is advertised. Of course since the client has a new GUID this means SCCM thinks the TS has yet to run on this machine and begins the reimage as soon as it is readded to the collection thus effectively putting the machine into an infinite rebuild loop.

I have considered simply building the client into the image so that it maintains the same GUID through the reimage but there are other issues with that approach.

Any suggestions on how to setup a recurring TS that will reimage a machine once a week?


To clarify a few things I will explain the situation a little better:

  • The OSD Task Sequence I am trying to run will take about an hour and a half to complete and this will occur around 3am. After the OS deployment is done another TS will need to run in order to install one last program that must be done through a separate TS due to certain program constraints.

  • Secondly, when I refer to the GUID above I am in fact referring to the SMS GUID that gets assigned to newly installed ConfigMgr clients. Of course there are other reasons a new SMS GUID would be created but those aren't of any concern in this situation.

Solution Details:

With the suggestion from newmanth below I did the following to resolve this issue:

  1. For the OSD Task Sequence and associated advertisement I set the following settings:

    • Maximum allowed run time (minutes) : 90 (TS Properties -> Advanced)
    • Program rerun behavior : Always rerun program (Advertisement Properties -> Schedule)
    • Advertisement Schedule : 3am, recurs once per week
  2. For the collection containing the computers in question I used the following settings:

    • Maintenance Window Duration : 3am - 4:35am, recurs once per week.

      I also check the option, "This schedule applies only to operating system deployment task sequences". This allows me to run my second TS mentioned above outside the maintenance window but prevents the rebuild recurring immediately after re-adding the client to the collection.

      A maintenance window must be greater than or equal to the max run time of the TS or program plus the Advertised Programs Client Agent countdown duration (mine was set to 5 minutes). Since my TS will have a max run time of 90 mins, I will have to set my window to 95 mins.

    • Collection Membership Update Schedule : 4:45am, recurs daily.

      Rebuild is complete, maintenance window closed at 4:35am. I now wait 10 mins for good measure and schedule a collection membership update in order to re-add the newly installed client. I could do this weekly on the same day as the rebuild but I do it daily for other reasons.

      Depending on how your collection adds new client members, you may also need to schedule your discovery methods to run before this update happens. For instance if your collection adds new client members based on an Active Directory group then you will need to run the respective Active Directory discovery methods first so that the newly created client record has its corresponding Active Directory information populated. Otherwise the new client record will not have any AD group info and it will not get added to the collection.

With the settings above the rebuild process should go something like this:

  1. Maintenance Window opens at 3am.
  2. OSD Task Sequence starts at 3am.
  3. OSD Task Sequence ends roughly 1 hour and a half later (4:30am).
  4. Maintenance Window closes at 4:35am preventing an immediate repeat of the TS.
  5. Collection Membership updates at 4:45am re-adding the newly installed client.
  6. After the client policy retrieval the second TS mentioned above runs.
  7. Steps 1-6 should automatically repeat themselves the following week.
  • Doesn't exactly answer your question, but if you're lab is running Win7 you should be able to use VHD native boot to boot from a differencing disk. The parent disk would stay the same, so the GUID and basic configuration would be fixed.
    – Chris S
    Commented Jan 17, 2012 at 3:29
  • Also, not 100% sure it would work the way you expect but you might be able to make a condition of the collection members be that the client's join date.
    – Chris S
    Commented Jan 17, 2012 at 3:35
  • You don't need to build the client into the image, you can include a step to install it in your task sequence.
    – Matt
    Commented Jan 17, 2012 at 3:38

2 Answers 2


I think you might be able to get this to work by setting a once-per-week maintenance window on the collection in question, in conjunction with always re-running the advertisement. Make sure the window is just long enough to allow the advertisement to run once. This will prevent a subsequent run until the maintenance window hits again. Technet: http://technet.microsoft.com/en-us/library/bb632801.aspx

  • I haven't tested this (since I'm at home right now), but will see if this actually works when I get into the office tomorrow :P
    – newmanth
    Commented Jan 17, 2012 at 4:40
  • Thank you for that suggestion. I have tested this and it seems to be working. Once I iron out the details I will post them as an edit to my original question.
    – New Guy
    Commented Jan 18, 2012 at 23:14

The accepted answer to this question did indeed help me setup a working solution for the described circumstance and using the above settings in my appended solution will work. However, it turns out this was not needed as the real issue at the heart of my problem was due to a SCCM 2007 bug that has since been hotfixed.



Don't let the title of that KB article fool you as this particular bug affects more things in SCCM 2007 than what it initially indicates.

Note: While this hotfix has been superseded by several other hotfixes, the CCMCertFix.exe utility that comes with this hotfix in particular is still needed and only comes with this particular hotfix.

Here is an excerpt from KB2028442 which explains what is happening:

The problem is caused by the self-signed certificates automatically generated by the ConfigMgr 2007 client in mixed mode. If the KB977203 ConfigMgr 2007 client patch was not installed on the client PC when the certificates were generated, then the certificates will have an embedded NULL character in the friendly name as described in KB974571.

When an OSD Task Sequence is used to Refresh a PC, the ConfigMgr 2007 client certificates are migrated from the old Windows OS to the new Windows OS. If the ConfigMgr 2007 client certificates on the original Windows OS have an embedded NULL character in the friendly name as described in KB974571, and if KB974571 is installed as part of the reference image being deployed by the Task Sequence, then when the new Windows OS is installed, KB974571 will block the ConfigMgr 2007 client certificate with the embedded NULL character in the friendly name from being migrated over. This will cause the ConfigMgr 2007 client to fail to install.

Now in my case the clients were installing just fine but due to this NULL character the certificates were still not getting migrated over properly and as a result it was simply creating new client records in SCCM with different SMS GUIDs. Hence, every time I did a rebuild of a client machine I had to run a collection membership update to re-add the client to the collection. Of course since ConfigMgr thinks this is a new client machine it has no record of it ever running the OSD Task Sequence and therefore immediately runs it again effectively putting it into an infinite rebuild loop.

After applying this fix to the client (I actually use the KB977384 fix that supersedes it) and then running the CCMCertFix utility before the OSD Task Sequence runs, I would no longer get new SMS GUIDs for clients that were recently rebuilt and therefore no longer have to re-add the client to the collection and the OSD TS would now see that it just successfully ran on the client and would not attempt to rebuild it yet again.


The CCMCertFix.exe utility must be ran before the TS ever starts. This means it will not work as a step in your TS. To do this you must go the properties of the TS and on the Advanced tab is an option for "Run another program first". You will also need to set the option "Always run this program first".

To obtain the CCMCertFix.exe utility you must install the KB977203 hotfix on the server for which you will then be prompted to automatically create a package for it. Using the package that gets created, add a new program simply running the CCMCertFix.exe utility.

For me it did not matter that I had already installed KB977384 first which supersedes this hotfix. It still ran successfully and created the package for me. I also did not need to deploy that hotfix to the clients since I was already applying the KB977384 hotfix.

  • Interesting.... We had an unrelated issue with KB974571 which caused us to install this hotfix some time back. I was not aware that it fixed this issue as well. Thanks for the new info.
    – newmanth
    Commented Feb 6, 2012 at 19:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .