I’ve been using MDT to automatically install applications as part of the task sequence to install or refresh the operating system. This has been very successful, particularly when using a process first described by the Deployment Guys where you have a security group for each application, you put the computer account into the groups that are for the applications you want installed and, hey presto!, the applications are automatically and consistently installed for that computer.
Recently, though, I hit a snag where the application installation process would reach a certain point and then skip to the finishing off stages of the task sequence. I’m not an expert at all when it comes to MDT so, when it breaks, it becomes a bit of an uphill struggle to figure out what has gone wrong.
Here is what I learnt.
1. Use the SCCM Tracing Tool
This tool is invaluable at turning the logs created by MDT into an easier to read sequence of steps. The tool, trace32.exe, can be found in the ConfigMgr 2007 Toolkit. Install the toolkit and then copy just that executable into the deployment share somewhere so that you can easily run it on the offending client.
2. Read ALL of the Task Sequencer Log!
So a number of logs get created when MDT is running and they can be found on the OS drive under MININT\SMSOSD\OSDLOGS. The name of each log follows the name of the script being used. The exception to this is the main task sequencer log which is, while MDT is running, located in <profile>\AppData\Local\Temp\SMSTSLog\SMSTS.LOG.
Initially, I was getting flummoxed because the log wasn’t showing up any issues with the task sequence. However, what I didn’t appreciate for a while is that the first bit of logging is MDT parsing the task sequence and creating something like an execution stack. In other words, it isn’t actually executing anything at this stage. If you continue reading through the log, you’ll get to the actual execution steps and that is where you can really see what is going on. The key logging point here is Starting Task Sequence Engine.
It was at that point that I discovered an error was being generated when the CUSTOM_AppInstall.wsf script was being called for a specific application. After the error, MDT was looking to see what should happen next. It bumped out of the nested groups I’d created for the application installs and continued with the rest of the sequence.
3. Set Application Installs to Continue on Error
To provide a bit of background here, there is a “parent” group (DANTE – Auto-install Applications) that is the start of the process to install all of the packaged apps based on group membership. Then, for each application, there is another group (e.g. Install – Microsoft Office 2010) which contains three steps – define the group name, query group membership and install the application.
It was the querying of the group membership that was failing (see #4 below) and then MDT was backing out of that group, out of the parent group and continuing on with the remainder of the task sequence.
So the third thing I learnt was to set the Continue on error option on each application’s install group:
By doing so, if any error occurs in the steps contained with the group, the task processing will automatically move on to the next application rather than completely bailing out of the nested groups.
4. Empty AD groups have no members!
So it turned out that the root cause of the failure was that one of the groups for an application didn’t have any computer accounts in it. Therefore, when the VBScript tried to go:
arrMemberOf = objGroup.GetEx(“member”)
an error occurred because the VBScript wasn’t doing any error trapping. As noted above, if you don’t set Continue on error, MDT works back up the group stack to figure out where to continue execution from.