While working on a presentation for Microsoft’s Minority Student Day here in the Columbus office, I came across an annoyance with Configuration Manager 1610 in my lab. The ConfigMan server in the lab is virtual, hosted on Server 2016 in Hyper-V. The VM’s OS disk is set to be 128GB and stored on a high speed PCIe SSD (Solid State Disk), but an additional 2TB mechanical disk is assigned to this VM for ConfigMan Content, Images, Packages, etc. This normally works great, but when updating an Operating System Image using Scheduled Updates, Configuration Manager will attempt to do all of the WIM operations in a temporary folder on the disk you installed it on – for many, that will be C:. In my case that’s 20+ extra gigabytes I don’t want on the SSD. That’s a whole bunch of additional write operations, a large amount of data, and a better-suited workload for placement on the rotational disk.
A quick web search turned up this handy article that someone from Microsoft published several years ago. Rather annoyingly, though, the information is a little hard to follow. Right off the bat, if you try connecting to the WMI namespace as suggested in their article, you’re going to have a bad time. You will scratch your head, wonder if this is worth even pursuing, and begrudgingly flip back to the search results to look for a better written article. Unfortunately, you’re not going to find one.
To attempt to help shed some light on the subject, I thought I’d document my experience with this whole process. So first off, let’s have a look at the steps our well-meaning poster suggested in the original article.
- Launch WBEMTest
- Connect to the WMI Namespace for Configuration Manager
- Query WMI for Offline Servicing Manager settings
- Drill down into the properties to change the StagingDrive property
- Save the changes
To get started, launch WBEMTest. Right click your Start button, select Run, type wbemtest into the box, then click okay. A happy little window will show up on your desktop.
Now we need to connect to the proper WMI Namespace. Fortunately, you can query these with PowerShell if you’re lost! This is how I determined the error in the original post!
gwmi -namespace "root" -class "__Namespace" | Select Name
If you followed the original article’s advice to "Connect to the Configuration Manager namespace on the site server. For example, if your site code is “CCP”, connect to namespace 'rootsmssite_CCP'." you won’t get very far.
I think the original poster left off several characters, namely ‘\’ where they should have separated root, sms, and site! So, the proper advice here is if your site code is “HHQ” (mine), connect to the namespace using “root\sms\site_HHQ”.
Once you’re successfully connected, click the Query button and paste in the following substituting your own Site Code for HHQ:
SELECT * FROM SMS_SCI_Component WHERE SiteCode='HHQ' AND ItemName LIKE 'SMS_OFFLINE_SERVICING_MANAGER%'
This will hopefully return a Query Result! Double click the result. This will open the Object Editor.
Look for and double click Props in the properties list. This will open the Property Editor.
Click the button titled View Embedded. There will be four objects in an embedded array to inspect in order to find the StagingDrive property.
Once you’ve located it, change Value1 in that list to whatever drive letter you want the temporary working folder to be placed on. I’ve chosen E:.
You’ve come all this way – now for the most important part: Save your changes! If I took screen-shots of every click, this post might tie for a Guinness World Record for Longest Blog Post in Vertical Pixels. So follow loosely – basically click Save and Close for each window. My exact cadence was like so: Click Save Property. Now click Save Object and then click Close. Next, click close on the Query Result. Click Save Property and then click Save Object, and finally click Close. Whew! That was a lot of clicking. You may now exit WBEMTest.
I’m not sure if you need to restart the Site Server to pick up this change, but the original article mentioned it would be used on the next Offline Servicing run. I bounced my VM for good measure. I truly hope this post was helpful and saved you a bit of headache. With any luck, you were able to switch your temporary working folder to your drive of choice!