We are using SCCM 2007 sp2 R2 (server 2008) and MDT 2010 update 1. It's working very well. Except for one very perplexing problem.
I'm working on getting an automated Build and Capture task sequence for our environment. The task sequence works perfectly. Installs all my apps, captures the image, and puts the image up on the server ready to use.
However, this exact same Build and capture TS will fail if I add a windows update step (in the normal location for such steps) using the ZTIWindowsUpdate.wsf script. I follow the instructions found here http://myitforum.com/cs2/blogs/cnackers/archive/2011/04/28/using-ztiwindowsupdate-wsf-to-install-updates-in-a-system-center-configuration-manager-task-sequence.aspx We do NOT have WSUS integrated with SCCM. So, I have the WSUS variable set in the customsettings.ini file as per the instructions. Seems to pick up on that correctly (you can see the WSUS server setting acknowledged in SMSTS.log file in various places.
The interesting thing is, the update step works through two reboots (initiated by the script), and then the Build and Capture Task Sequence stops and the computer ends up at the desktop (no other steps in the TS are attempted).
Here is the overall sequence.
1. The TS gets to the WindowsUpdate step and starts the script. Both the smsts.log and the ztiwindowsupdate.log all show the correct activity.
2. Updates are downloaded and installed.
3. All logs show a request for a restart.
4. Computer restarts
5. Smsts.log comes back up and acknowledges that ZTIWindowsUpdate.wsf still needs to run and let's it continue.
6. More updates downloaded and installed.
7. All logs (and the activity log on SCCM server) show that the script has again asked for a restart.
8. Computer restarts.
9. Smsts.log shows the exact same activity as before as it recovers and starts recording.
10. But only after a few seconds the smsts.log deviates from before and shows "Task Sequence environment not found. Task sequence completed in Windows PE."
No other steps in the Build and Capture TS are attempted after that point. No other activity is shown in the ZTIWindowsUpdate.log nor the BDD.log. They both end up at the point where they were waiting on the 2nd restart.
Here is the SMSTS.log section where it deviates and then ends. There are some error messages, but I have been unable to successfully use them to troubleshoot the correct root problem. This is from the SMSTS.log from c:\windows\system32\CCM\logs (x86 system)
"
Unlocked \\GEOFFGW-SCCM20\ROOT\ccm\policy\machine\RequestedConfig for source CcmTaskSequence successfully TSManager 4/18/2012 2:19:18 PM 568 (0x0238)
Machine RequestedConfig policy instance(s) : 334 TSManager 4/18/2012 2:19:18 PM 568 (0x0238)
>>>>>>>>>>This following line is the first difference in the sequence compared to after the first restart. I have no idea why it is doing this "networkaccessaccount update. It did not need it after the first restart.
Added/updated setting 'ccm_networkaccessaccount:sitesettingskey=1'. TSManager 4/18/2012 2:19:18 PM 568 (0x0238)
>>>>>>>>>> These lines are the same as after the first restart
Policy evaluation initiated TSManager 4/18/2012 2:19:18 PM 568 (0x0238)
Waiting for policy to be compiled in 'root\ccm\policy\machine' namespace TSManager 4/18/2012 2:19:18 PM 568 (0x0238)
Query = 'CCM_SystemHealthClientConfig.SiteSettingsKey="1"' TSManager 4/18/2012 2:19:18 PM 568 (0x0238)
Verified policy for instance path 'CCM_SystemHealthClientConfig.SiteSettingsKey="1"' compiled in 'root\ccm\policy\machine' namespace TSManager 4/18/2012 2:19:18 PM 568 (0x0238)
Query = 'CCM_SoftwareUpdatesClientConfig.SiteSettingsKey="1"' TSManager 4/18/2012 2:19:18 PM 568 (0x0238)
Verified policy for instance path 'CCM_SoftwareUpdatesClientConfig.SiteSettingsKey="1"' compiled in 'root\ccm\policy\machine' namespace TSManager 4/18/2012 2:19:18 PM 568 (0x0238)
Query = 'CCM_SoftwareDistributionClientConfig.SiteSettingsKey="1"' TSManager 4/18/2012 2:19:18 PM 568 (0x0238)
Verified policy for instance path 'CCM_SoftwareDistributionClientConfig.SiteSettingsKey="1"' compiled in 'root\ccm\policy\machine' namespace TSManager 4/18/2012 2:19:18 PM 568 (0x0238)
Query = 'CCM_NetworkAccessAccount.SiteSettingsKey="1"' TSManager 4/18/2012 2:19:18 PM 568 (0x0238)
Verified policy for instance path 'CCM_NetworkAccessAccount.SiteSettingsKey="1"' compiled in 'root\ccm\policy\machine' namespace TSManager 4/18/2012 2:19:18 PM 568 (0x0238)
Policy verification done TSManager 4/18/2012 2:19:18 PM 568 (0x0238)
Config policies compiled successfully TSManager 4/18/2012 2:19:18 PM 568 (0x0238)
Waiting for CcmExec service to be fully operational TSManager 4/18/2012 2:19:18 PM 568 (0x0238)
Succeeded loading resource DLL 'C:\Windows\system32\CCM\1033\TSRES.DLL' TSManager 4/18/2012 2:19:19 PM 568 (0x0238)
>>>>>>>>>>>>>>> Full deviation from this point on. TS ends shortly after this point.
LOGGING: Finalize process ID set to 764 OSDSetupHook 4/18/2012 2:20:29 PM 768 (0x0300)
!sVolumeID.empty(), HRESULT=80004005 (e:\nts_sms_fre\sms\framework\tscore\resolvesource.cpp,467) OSDSetupHook 4/18/2012 2:20:29 PM 768 (0x0300)
!sTSMDataPath.empty(), HRESULT=80070002 (e:\nts_sms_fre\sms\framework\tscore\resolvesource.cpp,1395) OSDSetupHook 4/18/2012 2:20:29 PM 768 (0x0300)
TS::Utility::GetTSMDataPath( sDataDir ), HRESULT=80070002 (e:\nts_sms_fre\sms\client\osdeployment\osdgina\osdsetuphook.cpp,174) OSDSetupHook 4/18/2012 2:20:29 PM 768 (0x0300)
Failed to set log directory. Some execution history may be lost.
The system cannot find the file specified. (Error: 80070002; Source: Windows) OSDSetupHook 4/18/2012 2:20:30 PM 768 (0x0300)
Executing task sequence OSDSetupHook 4/18/2012 2:20:30 PM 768 (0x0300)
!sVolumeID.empty(), HRESULT=80004005 (e:\nts_sms_fre\sms\framework\tscore\resolvesource.cpp,467) OSDSetupHook 4/18/2012 2:20:30 PM 768 (0x0300)
!sTSMDataPath.empty(), HRESULT=80070002 (e:\nts_sms_fre\sms\framework\tscore\resolvesource.cpp,1395) OSDSetupHook 4/18/2012 2:20:30 PM 768 (0x0300)
Task Sequence environment not found. Task sequence completed in Windows PE. OSDSetupHook 4/18/2012 2:20:30 PM 768 (0x0300)
Uninstalling Setup Hook OSDSetupHook 4/18/2012 2:20:30 PM 768 (0x0300)
Removing setup hook from registry. OSDSetupHook 4/18/2012 2:20:30 PM 768 (0x0300)
Successfully removed C:\Windows\system32\OSDGINA.DLL OSDSetupHook 4/18/2012 2:20:30 PM 768 (0x0300)
Could not delete the file C:\Windows\system32\OSDSETUPHOOK.EXE. Error code 5 OSDSetupHook 4/18/2012 2:20:30 PM 768 (0x0300)
Marking the file C:\Windows\system32\OSDSETUPHOOK.EXE for deletion on Reboot OSDSetupHook 4/18/2012 2:20:30 PM 768 (0x0300)
Successfully removed C:\Windows\system32\OSDSETUPHOOK.EXE OSDSetupHook 4/18/2012 2:20:30 PM 768 (0x0300)
Successfully removed C:\Windows\system32\_SMSOSDSetup OSDSetupHook 4/18/2012 2:20:30 PM 768 (0x0300)
Finalizing logging from process 764 OSDSetupHook 4/18/2012 2:20:30 PM 768 (0x0300)
Successfully finalized logs to SMS client log directory from C:\Windows\system32\CCM\Logs OSDSetupHook 4/18/2012 2:20:30 PM 768 (0x0300)
Cleaning up task sequencing logging configuration. OSDSetupHook 4/18/2012 2:20:30 PM 768 (0x0300)
>>>>>>>>>>>>EOF
"
Obviously, an inability to do the fully automated build and caputer would not be the end of the world. I would just not do the capture part. Just do the fully automated install with all software. Then manually update the OS patches, and then do a separate capture.
But if anyone has any ideas on why it is failing I would much rather have the process fully automated.
I see that MDT 2012 is out. Does anyone know if it is more robust in nature and able to handle these types of situations better?
Anyway, appreciate any help.
Thanks,
Geoff Weatherford
CSU