Here's the scenerio I am looking at.

I have a single Task Sequence for deploying my XPSP3 image. I want to schedule a push to a machine or groups of machines.

I create a an advertisement that is set to never re-run (to prevent the machine from getting into an imaging loop) and assign it to a collection containing the machine(s) I wish to reimage.
The advertisement is received and the machine rebuilds, backing up most stuff via USMT. Everything works like a champ!

Now a month goes by and for whatever reason I need to re-deploy the OS to onr of those machine and I need to do it on a schedule. I then create a new advertisement for my TS with a mandatory assigment for 2:00AM and assign it to the workstation. I have to set that advertisement to "Always re-run" otherwise the computer rejects it as it sees that the previous execution of that TS already ran.

Once the machine is back online and receives its policies the OS advertisement is set to "Always re-run" thus it kicks off again and re-images the computer.

Knowing this I think its safe to say to never have and OSD advertisement set to "Always re-run".

Whats another option?
You can reimage via PXE but if you wish to merge GUIDs then the Advertisement would potentialy come back down after the PXE boot and re-image the machine "again".

You could however always blow away the resource object and create a new one but thats not a desireable solution in many cases. Guid history can be a great thing!

After beating my head on it awhile I think I have come up with a solution that should meet my needs.

I have attached a wsf script that I downloaded and have modified a bit to work stricly with OSD in SCCM 2007.

There are several variables near the top of the script

strCollID = "collection"
strServer = "sccmserver"
strsitecode = "sitecode"
strUserName = "user"
strPassword = "pwd"

You could (and probably should) create these as arguments that you can pass to the script. In my environment I have compiled these into an EXE (using WiseScript) I then schedule this script to run at my desired time with an expiration time of 1 hour.

At a high level the script does the following:
You pass it an Advertisment ID you wish to run. (This will be the advertisement that advertises the OSD Push Task Sequence.)
Validates the machine object exists
If it already has the OSD deployment advertised to it it simply triggers the schedule to re-run.
If the local policy does not exists for this advertisement it adds the current machine (running the script) to the OSD Collection specified in the script, triggers a machine policy update cycle, waits 2:30 minutes for the OSD policy to be received thus starting the OSD process.

The script itself should be commented enough to get more detailed explenations of how the script works (I hope!)

So again, the front end script effectively handles all the OSD needs for Push deployments. This also gives you the flexability to schedule the OSD push as well.

Disclaimer:
Your use of this script is at your sole risk. This script is provided "as-is", without any warranty, whether express
or implied, of accuracy, completeness, fitness for a particular purpose, title or non-infringement, and is not
supported or guaranteed by mw. I shall not be liable for any damages you may sustain by using this script, whether
direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.



Hope this helps someone else!

The scripts can be downloaded here:
Front End WiseScript:
http://www.clientarchitect.com/media/blogs/a/scripts/1runosd_wsescript.zip

WSF Script:
http://www.clientarchitect.com/media/blogs/a/scripts/1runosd_wsfscript.zip

Source: jgilbert (myITForum)

How to check the WMI repository before rebuilding it.
I've had some WMI repository repair tidbits stashed away in my e-mail that I was going to blog about sooner or later. I'm not sure if today is sooner or later, but I did have to go looking through my old e-mails to find these steps for a lab machine today, and figured that was a sign I should finally post this information to the blog. If you suspect that the WMI repository has been corrupted, before throwing in the towel and blowing it away you can/should try to repair it

I couldn't remember where I got these command lines so I had to go look them up again! Looks like if the repository can't be repaired, it will be recreated anyway: http://www.microsoft.com/technet/scriptcenter/topics/help/wmi.mspx

Of course, you could use the WMI Diagnosis Utility to check for WMI corruption, but I'm a pretty impatient person at heart and find that this is just faster for me. The steps when using these commands go kind of like this--check it, fix it and worst case replace it.

Anyway, to check the WMI repository for errors on a Server 2003 SP1 or SP2 systems, run the following command from command prompt:

rundll32 wbemupgd, CheckWMISetup

Once you've run that command, check the setup.log file located at: %windir%\System32\Wbem\Logs\Setup.log. Check for entries from today's date. If you find none, then WMI is probably OK and you should continue troubleshooting somewhere else. If however, you see an error message from today saying that it can't find a namespace then yes, your WMI repository does have issues and you should do the below:

rundll32 wbemupgd, RepairWMISetup

This will re-create your WMI repository minus any custom .mof additions that were implemented without the -autorecover switch.

For Windows XP SP2, use the following command to check for corruption, and repair if necessary:

rundll32 wbemgupgd, UpgradeRepository

For Windows XP SP1, the check and repair commands are below and function just like the Windows Server 2003, SP1 commands:

rundll32 wbemupgd, CheckWMISetup

and

rundll32 wbemupgd, RepairWMISetup

If anyone has used Sysprep with XP on a machine that uses an Intel Graphics chipset you have likely ran into the dreaded hang during mini-setup when plug and play installs the graphics driver. (Sits at the please wait screen and must be manually rebooted to continue)

Microsoft offers a hotfix for this (must be requested via the web form or through calling PSS)
http://support.microsoft.com/default.aspx/kb/883667

It is effectively a single dll file that needs to be replaced.

12-Aug-2004 17:50 5.1.2600.2505 247,808 Newdev.dll SP2QFE

I have run into scenerios where I needed access to the Windows Installer service while in Safe Mode. You may be suprised to know that this service is not enabled by default. The following info will get it back for you:

To start Windows Installer in Safe Mode:
1. Restart your computer and press F8 before the Boot Menu or splash screen.

2. Open a CMD.EXE window.

3. Type the following commands and press Enter:

REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal\MSIServer" /VE /T REG_SZ /F /D "Service"
net start msiserver

NOTE: You can use this technique to uninstall an application in Safe Mode.

Some great resources around virtualizing applications:

Application Virtualization Operations Guide
http://blogs.technet.com/softgrid/archive/2007/11/13/softgrid-operations-guide-part-1.aspx
http://blogs.technet.com/softgrid/archive/2007/11/14/softgrid-operations-guide-part-2.aspx

List of applications that can be virtualized
http://blogs.technet.com/softgrid/archive/2007/09/27/list-of-applications-that-can-be-virtualized.aspx

Virtualworld Blog
http://blogs.technet.com/virtualworld