Monday, June 30, 2014

OSD to VirtualBox using SCCM 2012 SP1 R2

Recently, when trying to test my Task Sequence I received this error once WinPE had completed it's initial pass:


The issue can be easily resolved by running the following command:

VBoxManage setextradata [vmname] VBoxInternal/CPUM/CMPXCHG16B 1

You can get your VM names by typing VBoxManage list vms


Wednesday, June 25, 2014

Beware Cut and Paste - 0x800700a1 during Task Sequence WMI Query

Before I go on, this was ALL my own fault. There said it. Honesty being the best policy and all that. I say this because I must confess; confess because I feel like a numpty.

So, what happened..?

I was putting together a Task Sequence to deploy Win 7 x64 SP1 to my Oracle VirtualBox test machine. I do this because it's quicker than walking over to the build desk, unboxing a Dell and plugging it all in. It's all of 5 metres #lazysysadmin. But anyway, serves my lazy backside right. 

Where was I? Oh, yes. Task Sequence:

1) Boot into WinPE
2) Query WMI for Model 'VirtualBox' and if True, then Partition and Format Disk 
3) Proceed with Task Sequen.. oh, wait ...fail step 2 with 0x800700a1(The task sequence execution engine failed evaluating the condition for an action)

I went through my step 2 Task Sequence. It was correct, damned you! I swear. I checked it over. Look!



Even when I ran a wbemtest query from within WinPE, it returned the correct value. Look! See?


And I even checked SMSTS.LOG. Look! See? SEE?!


 Oh. 




Yours truly had copy-pasted from my notes and instead of straight speech marks (" ") I had put some sixty-six speech marks (“ “) in my WMI query. 

What a numpty.

Monday, June 23, 2014

Kernel Mode Drive Framework / Dell's SCCM driver CABs

In a bid to slipstream the 160-odd updates into my existing Config Manager WIM files since Windows 7 x64 SP1 was released, I followed these instructions:


However, upon doing this I <ahem> "broke*" my deployments. I would get a whole load of Task Sequence errors, with one in particular pointing me to a boot-critical driver installation issue. So, I hopped over to Dell's Config Manager site and duly downloaded the A04 Client Driver Pack for the system in question (OptiPlex 9020). However, upon applying this driver, I further <ahem> "broke" my deployments. 

After a bit of research I found the following. Apparently, the Kernel Mode Driver Framework has been upgraded to 1.11 and you need to integrate this into the WIM image file before you can proceed with your Apply Driver Task Sequence step. 

Without further ado, here's the post!




*broke is a rather strong word. I prefer 'Temporarily disabled'

Config Manager 2007: Dell XPS 8700 - OSD

Recently, I was asked to put a 'quick build' together of a Dell XPS 8700 Desktop PC. For me a quick build is often nothing of the sort, instead taking hours of build, re-build and test with plenty of driver applying thrown in for good measure.

Given the deadline nature of the request (why is it always urgent?) I opted for a capture of a fully Windows-Updated, no other applications, vanilla Windows 7 x64 SP1 machine. This snazzy piece of kit had an mSATA drive, so I wanted to use that as the OS disk. Obv.

The initial capture was simple enough, but when it came to deploying the image I started to see a problem. In short, even though I was formatting the disks (there are two; 256gb mSATA and 3gb SATA) in the Task Sequence I was constantly coming up against an teeth-gnashingly annoying 0x80070032 (or sometimes 0x80004001) error when trying to apply my WIM file.

OSD Homepage gave me the infuriating error:

System partition not set Volume C:\ is not on the boot disk and can not be made bootable. Failed to make volume C:\ bootable. Please ensure that you have set an active partition on the boot disk before installing the operating system. The request is not supported. (Error: 80070032; Source: Windows)

"But my Task Sequence has everything it needs!", I screamed. Just look:




Format the 256gb mSATA SSD as C (0, MBR)


...and mark it as bootable


Format the 3gb SATA HDD (1, GPT)


...and do nothing unusual


Next, apply the WIM file to the next available partition



However, EVERY time I built the desktop...BOOM!


This was infuriating. I tried swapping the disks, removing one, unplugging the card reader module and - even - Googling! And, of course, Mr. G was my friend. Whilst it didn't say exactly what to do, I did stumble upon this nugget and also this one and in particular: 



This got me thinking, perhaps the BIOS settings are interfering with the next available drive and overriding Config Manager's own osddiskpart process.

So, I booted into the BIOS settings and checked the settings under Hard Disk Drivers (not sure if that's a typo...). 

I noticed the 1st Boot Device was set as the 3tb HDD and not the mSATA, so I changed the 1st and the 2nd around, so to make the mSATA disk the primary boot disk. 




And what do you know? Format, partition, boot-activation and WIM file deployed without any problems. 

One thing to note, mSATA formatted as C: but the HDD as I: due to all the ODD and card-reader devices. This doesn't matter since when you apply a WIM file the original captured drives are re-allocated upon first boot after the build.