Michael Niehaus' Windows and Office deployment ramblings
Now that Configuration Manager 2012 RTM is available, people will certainly start installing it, both in their labs and in production – and will start finding out that the SQL version check in the ConfigMgr installer is looking for some very specific SQL maintenance levels. (I’ve pulled out plenty of my own hair doing this recently, just like I did with the prerelease versions.) The supported versions can be found at http://technet.microsoft.com/library/gg682077.aspx#BKMK_SupConfigSQLDBconfig. The summary (always subject to change):
If you are running SQL 2008 SP2, install CU9 from http://support.microsoft.com/kb/2673382/. If you are running SQL 2008 SP3, install CU4 from http://support.microsoft.com/kb/2673383/. If you are running SQL Server 2008 R2 SP1, use CU6 from http://support.microsoft.com/kb/2679367/. If you aren’t yet on the needed service pack levels, upgrade now, then install the cumulative updates :-)
I’m still looking for a statement on ConfigMgr 2012 RTM and SQL Server 2012. (ConfigMgr 2007 now supports it, see http://blogs.technet.com/b/configmgrteam/archive/2012/04/17/configuration-manager-support-announcements-for-april-2012.aspx.) There’s already a CU1 for SQL Server 2012, http://support.microsoft.com/kb/2679368/.
I’ve done a few sessions now where I demonstrated how to put some hooks into a task sequence so that you can single step through the process and “poke around” to see exactly what is going on. Since I’ve promised to make those scripts available, and will get lots of e-mails from people if I don’t do that, I’ll provide those at the bottom of this blog posting.
But the scripts by themselves require some explanation, some instructions, and some caveats.
First, let’s talk about the basic setup. If you look at a ConfigMgr task sequence, it contains a number of steps and groups that define the sequential process that is going to be executed. This is actually converted into XML, where each step and group becomes a series of XML entries that define:
Before the client computer begins to execute the task sequence, it receives (as part of the task sequence policy) the entire XML blob. That XML blob is then processed by the Task Sequence Manager, TSManager.exe, which is what actually starts the commands for each step (at least those where it has decided the conditions have been met).
So that’s a key part of what we want to do: We want to intercept each of the commands that are being executed by the TSManager.exe process before they actually start. That way, we can look at the task sequence variables currently defined, the command line details, the step’s XML, etc. How do you do this intercepting? That’s where a debugger comes in. A debugger can attach the TSManager.exe process, then set a breakpoint on the Windows API call, CreateProcessW, that is used by TSManager to run the command for each step. Each time TSManager.exe then tries to run a new command, the debugger will stop the process until you manually say continue.
That’s where the scripts come in: The provided “InsideTS” scripts take care of setting up the debugger (attaching to the TSManager.exe process, setting the breakpoint), watching for breakpoints (checking the log for “breakpoint hit” messages), and showing the current state (displaying the step details, task sequence variables, logs, etc.). The pieces involved:
In addition to the files listed above, you need to gather these additional files:
Once you have gathered all of these files into one folder, they need to be added into the ConfigMgr boot image that you will be using and into the new OS image that you are deploying. Create an “InsideTS” folder at the root of both of these. (The simplest way to do this: mount both of the WIMs, XCOPY the folder to X:\InsideTS, commit the changes, then update the DPs.) Why do I include these files in the images? Well, it was easier to do it that way. (More on that later.)
Now that the files have been added to the boot and OS images, you then need to add commands to the task sequence to run InsideTS_Attach.wsf. How many steps you need to insert into this depends on how many reboots you expect the task sequence to perform; you need one after each reboot. At minimum, you will need two, one to run in Windows PE for preinstallation steps and a second to run in the new OS. The step should look like this:
Assuming you have set everything up right, you should be able to start the task sequence and see something like this show up:
This shows the step after the “InsideTS Attach” as being the next one to execute. You can then click on the “Variables” button and see that all of the variables are highlighted in green because they are all considered “new” (as in “never seen before”) at this point:
Once you’ve poked around enough, click the “Finish” button to close the wizard. At that point, you’ll see a strange sight: the NTSD debugger. In a perfect world, the InsideTS_Monitor.wsf script would feed the commands to continue with the step execution once you’ve clicked “Finish” on the wizard, but after messing around with that for a couple of hours, I gave up on that and went with a lower-tech approach: Type in the needed commands yourself. In case you aren’t familiar with NTSD command line options, here’s a quick reference to the ones you’ll need to know:
That’s really all you need to know. (I used one other command, “du rdx”, to dump out the CreateProcessW command line parameter during the session, but you can see the same value at the end of the SMSTS.LOG, which you can open by clicking the “Log” button in the wizard.)
Some people know the story behind this little tool: I originally put these scripts together for a BDNA “SCCM Guru” webcast back in November. The webcast was scheduled months in advance, so I assumed I had plenty of time to prepare. For a variety of reasons (including procrastination) I didn’t prepare for this nearly as soon as I had hoped. In fact, I didn’t start most of it until about 30 hours before the presentation was due to start. And for about 18 of those hours, I was travelling back to Seattle from Moscow – in coach of course. So all the preparation work was done on the airplane, with the scripting done on the Moscow to New York flight, when there was no internet connection, and the testing (and bug fixing) happening on the flight from New York to Seattle (VPN connection from the airplane to my office Hyper-V server, thank you http://www.gogoair.com). The next morning, I presented the session, completely jetlagged…
So there’s my excuse for the following caveats:
This script code is provided as is with no guarantee or warranty concerning the usability or impact on systems and may be used, distributed, and modified in any way provided the parties agree and acknowledge the Microsoft or Microsoft Partners have neither accountability or responsibility for results produced by use of this script. Microsoft will not provide any support through any means.
If you manage to set this up successfully, or if you run into any issues, please e-mail me at mniehaus@microsoft.com to let me know. I think the instructions and scripts should work, but I offer no guarantees