Versioning / Monitoring SCCM Task Sequences
Update 29.03.2016: Published new script to import the Task Sequence xml files generate by this script back to SCCM 2012 and above.
One thing I’m really missing in SCCM is some kind of versioning or history especially for those quite complex Task Sequences, sometimes consisting of hundreds of steps, each with a bunch of properties. And how often did it happen that you came back to the office and one of your Task Sequences suddenly behaved differently, just to figure out that “someone” changed “something” without telling anybody, especially not you? Or have you ever been working on a Task Sequence, just to recognize that you missed something important and this single time haven’t duplicated or exported this Task Sequence before? And now you are stuck, trying to remember what you just changed to get it working again.
I just published a script to CodePlex that runs on a Primary/Central and monitors all or specific Task Sequences for changes. If a change happened it will export either the previous or the current version of the Task Sequence into a XML file that could then be used to see what has been changed or to restore an older state by importing this xml back into SCCM. It has a bunch of properties that can be used to tweak this process to your specific needs and after it has been started once, runs in the background, not matter if you log off or even reboot the server. So using this script gives you a real history of your Task Sequences that you can use for backup purposes, Versioning and change tracking.
First Steps – The “Installation”
First – get the script from CodePlex and save it to a local folder on the server that you would like to monitor. As Task Sequences can only be edited on the server they have been created on, it might make sense to manage them on one or just a few servers to keep the managing and also the monitoring easy. Be sure to remove the security flag from the script as you downloaded it from the internet (Unblock).
Second – execute the script with administrative privileges. On W2K8 and above it needs to run elevated. If everything works, you should see a message box stating that the event filter and consumer have been created.
That’s actually all you need to do to get it working !!!
From now on, WMI will monitor all changes on any Task Sequence and if a change happened, it will call this script again (Don’t move the script after you executed it the first time). The script will then get some additional information from SCCM like the person that changed it and finally export the Task Sequence into an XML file. This XML file is already prepared in a way that you can import it back again into SCCM. Additionally you can now compare different versions to see the changes. I will write an additional blog post outlining this in more detail.
Making some adjustments
As you have seen, the script works right out of the box. But depending on your environment and your needs, it might be necessary to adjust the behavior a bit. You might want to have it export the Task Sequences to a different path. Add a date-time identifier instead of a version, use it just for OSD Task Sequences or would like to include or exclude specific Task Sequences. Well, the script is flexible enough to cover those demands. It has a couple variables defined at the beginning, that you can use to tweak it to your needs. And as the script gets called every time a change happens, this updated behavior will actually take place on the next execution already.
You will find the following variables at the top of the script:
- ExportPath : Specifies the location the Task Sequences will be exported to. Default is “C:SCCMTSMonitor”
- UsePrevious : If set to “True” it will export the previous version of the Task Sequence. Default is “False” so it exports the current version.
- CreateSubfolders : If set to “True”, which is the default, it will create a subfolder per Task Sequence at the location specified by ExportPath.
- UseName : If set to “True”, it will use the Task Sequence name instead of the Package ID as name for the XML File. Default is “False”, so it will use the Package ID.
- UseVersion : If set to “True”, which is the default, it will add a version identifier to the name of the XML file.
- VersionLength : Defines the length of the version identifier. Default is 3 digits.
- AddDate : If set to “True”, it will add the current Date to the name of the XML File. Default it “False”.
- AddTime : If set to “True”, it will add the current time to the name of the XML File. Default is “False”.
- UseOSDTSOnly : If set to “True”, it will limit the export to OSD Task Sequences only. No custom Task Sequence will be exported then. Default is “False” to cover all Task Sequences.
- IncludePackages : comma separated list of PackageIDs that shall be included in the export. Default is “*” which will export all Task Sequences except the ones specified by ExcludePackages.
- ExcludePackages : comma separated list of PackageIDs that shall be excluded from the export.
So on default it will export the current version of every changed Task Sequence, create a subfolder per Task Sequence, use the PackageID as name and add a three-digit version identifier. Which I think should be OK for most common scenarios.
“Uninstall” the script
As mentioned, the script registers within the WMI namespace and with this survives reboots. To unregister it, simply execute the script again with administrative privileges/elevated. If successful it should show a message box stating that it removed the event filter and consumer. Next execution will register it again. If you e.g. want to move the script to a different folder, just run it once to unregister it, move it to the new location and execute it again to create the filter an consumer again. Pretty simple.
Logging / Troubleshooting
As the script runs in system context, it’s quite difficult to figure out what’s going on if it doesn’t do what it is expected to do. To give some “feedback” the script is writing to a log file that is located at the same location where the Task Sequences will be exported to. On default it will show only informational and error messages. But as mentioned in the “Making some adjustments” part, it’s possible to change the behavior of the script during runtime. One of the additional variables not listed there is called “Debug”, which is set to “False” on default. Just set it to “True” and the script will be a bit more verbose on what it is doing . The logging routine has been taken from MDT and only slightly adjusted. So preferred Log Viewer is Trace32 from the ConfigMgr Toolkit.
Additionally WMI also writes some log information itself. On Servers and Clients before Vista/W2K8 it was a lot easier. WMI wrote text based log filed that could be found at “%SystemRoot%System32wbemLogs”. On Vista/W2K8 and above it’s using the default Event tracing for Windows (ETW), so you need to enable it in the Event Viewer and it’s writing to a binary file. See Tracing WMI activity for more information.
I hope you find this script useful. Even if I still consider it a Beta version at the moment, it has been tested on 32 and 64 Bit Systems and is in use in some larger environments already. And as it is mainly reading/gathering information, it shouldn’t have any negative side-effects. But again, this script is provided AS-IS. Be sure to properly test it before using it in your production environment and be sure to regularly check the CodePlex page for an updated version. If you like what it does, you can also review it on CodePlex and be sure to spread the word so others can benefit from it as well.
As always, I really appreciate any feedback. If you find a bug or would like to suggest an additional feature just get back to me.
I you are interested in some additional information about WMI eventing, especially if it comes to SCCM be sure to check out the following sources:
- Blog from the “quiet shy” WMI guy aka Kim Oppalfens (WMI Event basics). Please be sure to bug him about his still missing Part 3 of his series of WMI eventing Blog posts he started after last years MMS.
- CodePlex Project PowerEvents for Windows PowerShell by Trevor Sullivan. Really nice way on managing WMI Events with PowerShell instead of VBScript.