Monthly Archives: October 2009

MDT 2010 Driver Injection Slowness

Posted on by
Reply

After upgrading from MDT 2008 to 2010, I recently experienced an issue with MDT / WinPE 3.0 that was simply a driver issue. The initial symptom reported to me was: Driver detection / copying (ZTIDrivers.wsf) is taking a long time in WinPE on a Lenovo T60. The build completed, but hung on the driver injection step for about an hour.

To start diagnosing, I booted WinPE 3.0 off of USB flash drive (UFD) on a Lenovo T60, brought up a command prompt (press F8) and tried to browse the disk (just by typing “c:”) I got: “The volume does not contain a recognized file system. Please make sure that all required file system drivers are loaded and that the volume is not corrupted.“ Upon issuing “format fs=ntfs quick” to diskpart, I received: “DiskPart has encountered an error: The parameter is incorrect. See the System Event Log for more information.” Running “ipconfig” yielded normal results, and I was also able to mount network shares, and browse them without any issue.

Note: I typically use a UFD because they boot significantly faster than off of optical media. :)

After posting on the MDT-OSD discussion list on MyITforum, I discovered that I may not have the correct drivers in my boot image. Most other people have reported that they haven’t had to inject any drivers, and I figured that the Vista drivers I had in my old WinPE 2.x boot images should have worked alright. As it turns out however, the Intel NIC was using a built-in driver from Microsoft according to wpeinit.log, and there was no mass storage driver being loaded according to the output from “devcon driverfiles *“.

Resolution

So, simply updating the mass storage and NIC drivers resolved the issue(s). The network drivers can be found here: http://www.intel.com/support/network/sb/cs-006120.htm. The storage drivers can be found here: http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=17882&lang=eng.

Deployment Workbench: Windows Imaging Error

Posted on by
Reply

I just installed the Windows AIK for Windows7, and MDT 2010 on my 64-bit Windows 7 Release Candidate system, and attempted to open the Deployment Workbench. It opened just fine, but when I selected the Deployment Shares node in the snap-in, I got this error: “The file C:Windowssystem32wimgapi.dll(version 6.1.7100.0 (winmain_win7rc.090421-1700)) is older than the installed Windows Automated Installation Kit (version 6.1.7600.16385).  Please remove the C:Windowssystem32wimgapi.dll file so the proper one is used.”

Windows Imaging Error

Windows Imaging Error

I am unable to remove the file, or replace it with the newer AIK one, due to a lock on the file (my guess would be that it’s Windows System File Checker).

Most likely, the solution (or at least it might help) would probably be to upgrade to Windows 7 RTM, but I’ve been putting that off for so long, what’s a couple more weeks? :) I just wanted to document this error / scenario in case anyone else comes across it.

MDT 2008 to 2010 Upgrade Successful!

Posted on by
Reply

Yesterday, I upgraded MDT from 2008 to 2010. The high-level steps I followed to upgrade it were as follows:

  1. Uninstall Windows AIK 1.1
  2. Uninstall MDT 2008
  3. Install Windows 7 / 2008 R2 AIK
  4. Install MDT 2010
  5. Open MDT 2010 console and upgrade deployment shares
  6. Test task sequence on virtual machine

Please note: The Microsoft .NET Framework and Windows PowerShell are also both required, but we already had them installed.

The application upgrade went flawlessly, and I only got a couple of warning messages during the deployment share upgrades. Here is what I got (and yes, the share still existed):

Unable to transfer settings to deployment share \<imageserver>LTIDeploy$.  If the share still exists, the settings will need to be reconfigured.

System.IO.DirectoryNotFoundException: Could not find a part of the path ‘d:DistributionControl{f3123492-005e-499f-9c9b-982a401e1ff9}Settings.xml’.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite)
   at System.IO.File.Copy(String sourceFileName, String destFileName, Boolean overwrite)
   at Microsoft.BDD.PSSnapIn.DeploymentPoint.TransferSettings(XmlNode deployNode, String settingsFile)
   at Microsoft.BDD.PSSnapIn.DeploymentPoint.UpgradeDeployXML()

For whatever reason, this didn’t negatively impact the deployment point, so I proceeded with testing out our standard Windows XP task sequence for workstation builds. The only errors I experienced were actually in a couple of custom scripts that we wrote, one of which handles Windows XP HAL injection, and the other which sets the computer name for virtual machines by truncating the serial number (we name some computers based on their serial #). After doing some research, it turns out that the DeploySystemDrive task sequence variable no longer existed for some reason. I searched BDD.log for ‘c:’ to see if there was another variables that contained the target OS drive, and sure enough, I found one named DestinationLogicalDrive. After updating the two scripts with this new TS variable, the task sequence completed successfully!

All in all, I would say the experience upgrading from MDT 2008 to 2010 was quite simple. It was completed in under 4 hours of my time. Thanks to the MDT team at Microsoft for making upgrading simple!

GemBox’s Excel .NET Library

Posted on by
Reply

If you’re at all familiar with the Excel APIs, you’ll know that they’re often quite frustrating to work with. The fact that the Office 2007 .NET API is simply a wrapper around the COM interface doesn’t make it very appealing either.

I e-mailed my dad, who develops software, and he sent me a link to this handy .NET library by GemBox Software. It simplifies the Excel API, and allows you to get things done much more logically than the Excel API does. Here is a link to their product page:

http://www.gemboxsoftware.com/GBSpreadsheet.htm

Failing software updates in SCCM / WSUS

Posted on by
Reply

I recently was troubleshooting an issue with some failing software update installations being deployed via SCCM / WSUS, and finally found out what was affecting them. All of the failed updates were related to Microsoft Office, so that kind of tells you something right there. It turns out, the root cause of the installation failure was that the “Office Source Engine” (short name ‘ose’) was disabled.

A quick, easy way to re-enable the service remotely is to use Windows PowerShell. Here is a command you can issue to set the start mode to manual:

(Get-WmiObject -Query “select * from win32_service where name = ‘ose’” -ComputerName RemoteMachine).ChangeStartMode(“Manual”)

The error messages I was getting in the UpdatesHandler.log are below:

WSUS update (32cd1fb9-5401-4025-b8dc-22a3b41060cc) installation result = 0×80070652, Reboot State = NoReboot
Update execution failed.
WSUS update (880f4592-a57e-4af6-ae6c-c2988519df4e) installation result = 0×80070652, Reboot State = NoReboot
Update execution failed.
WSUS update (8fe60694-94c6-4568-8094-17e2e92045ea) installation result = 0×80070652, Reboot State = NoReboot
Update execution failed.
WSUS update (938d8bbf-f928-4dac-baef-b66005583409) installation result = 0×80070652, Reboot State = NoReboot
Update execution failed.
WSUS update (ae97d343-7c0d-4c06-9a62-67eff01890a9) installation result = 0×80070652, Reboot State = NoReboot
Update execution failed.
WSUS update (bf20a84c-6662-4755-b60d-7fe3a090eb01) installation result = 0×80070652, Reboot State = NoReboot
Update execution failed.
WSUS update (e33db88f-49ab-4cce-aa24-16d952526b6b) installation result = 0×80070643, Reboot State = NoReboot
Update execution failed.
WSUS update (f6e3e036-eaf1-4423-9eab-9359a23fcb9e) installation result = 0×80070643, Reboot State = NoReboot
Update execution failed.
WSUS update (f75401a0-0419-48fc-8011-bb0b30c061f8) installation result = 0×80070643, Reboot State = NoReboot
Update execution failed.

Update (2009-10-29): I thought I had posted this somewhere, but I guess not. While the suggested PowerShell code above would work for a one-off fix, a better way to manage this configuration would probably be to use the Microsoft Group Policy Preferences Client Side Extensions (CSE). You can use these GPO extensions to enforce service configurations for systems with the CSE installed, thus reducing helpdesk tickets resulting from improper configurations (whether done maliciously or non-maliciously).

SCCM – Changing Client Cache Location

Posted on by
Reply

Update (2009-10-05 12:30 PM): Thanks to Todd Hemsell, I now know that you have to restart the ccmexec service in order for the change to take effect. I’ve updated the scripts appropriately.

—

So you’ve got System Center Configuration Manager (SCCM) 2007 in place, and for whatever reason, you’re looking to change the location of the client cache. One method of doing this is to send an e-mail to all your users with instructions on how to change the cache location from the Control Panel applet, right? Well, technically yes, but I’d only suggest doing that if you want more than 5 users to actually do it, much less type the path correctly.

In any event, if you want to script / automate the changing of the SCCM cache location, you can simply use the following PowerShell code as a deployable script:

$ccmcfg = Get-WmiObject -Namespace rootccmSoftMgmtAgent -Class CacheConfig -ComputerName omxg69cg81d
Write-Host "Current cache location is " $ccmcfg.Location
$ccmcfg.Location = "C:WINDOWSSysWow64CCMCache"
$ccmcfg.Put()

Get-Service ccmexec | Stop-Service
Start-Sleep 10
Get-Service ccmexec | Start-Service

In VBscript, it would look something like this:

set ccmcfg = GetObject("winmgmts:rootccmSoftMgmtAgent:CacheConfig.ConfigKey=""Cache""")
ccmcfg.Location = "C:WindowsSysWOW64CCMCache"
ccmcfg.Put_()

set ccmexec = GetObject("winmgmts:rootcimv2:Win32_Service.Name=""ccmexec""")
stopresult = ccmexec.StopService()
wscript.sleep 10000
startresult = ccmexec.StartService()

Please leave any questions in the comments section!