Sunday, July 14, 2013

File under “That’s one way to do it.”

A KACE solution is used to produce a multi-platform image of our systems.

I’m not exactly sure how they make the master editions. The Home Office works behind closed doors once every few months when the moon cannot be seen at midnight. I guess it’s an “eye of newt, toe of toad” thing.

Anyway, we get the master USB stick, deploy it with much chanting and spinning to a local system, then pass some Latin command-line FU to the all powerful “Run" box. About 3-4 hours later a completely built KACE system (re)imaging stick spawn results. Then we have to repeat to build the next storm trooper clone.

It’s a time consuming process, and since I don’t have a physical multi-USB drive replication device, it can take up to a week (while multi-tasking) to update all the drives our team carry for system reimaging when a new refresh occurs.

So what I do is to to build a single updated one, then use Alex’s awesome USB Image Tool to capture a full image of the built stick. For the standard 16 GB stick we use, it doesn’t take too long to capture the “IMG” file back to the system HDD.

Once I have that, I just turn around and write that image back to each of the follow-on USB sticks. The process still takes up to an hour per stick to write back out, but that’s several hours faster than the standard process takes.

One alternative is OSForensics - ImageUSB. I like it and USB Image Tool as they allow you to take an image and write an image all with the same tool.  I also found Flash Drive Image Creator which just lets you take an image, and Win32 Disk Imager or USBWriter which then allow you to write that image to a USB drive. I haven’t used them unlike ImageUSB or USB Image Tool so YMMV.

All this is well and good until recently we got some 64 GB USB sticks to use.

The stock scripted process we follow from the master set of building files works fine with them…up to a point. See when done, it results in a 16 GB formatted partition. The remaining volume space is left unallocated in the process.

As I understand it (but haven’t verified myself) the process the KACE tool uses to create each of the sticks using the long-process uses UFDPREP.EXE to do the target USB drive’s formatting and conditioning to make it bootable to the KACE PE (just a custom WinPE) environment from which the image deployment scripts run out of.

It has been said (again I haven’t been able to find documentation to support) that UFDPREP only supports setting the formatting size for the flash drive up to 16 GB.  As I haven’t tested it independently, it might be that the script that the UFDPREP runs for in the drive building process is set somewhere to just use a 16 GB size. Changing its “/size=n” argument value to /size=65536 might work. Maybe.

(Side note: yes I know there are lots of ways and tons of tools to accomplish the formatting and boot-support prepping of a flash drive to almost whatever upper size you want limited only by the physical memory capacity of the device. The challenge here is that the official tool/process automates use of UFDPREP at the very onset of the scripted build process to the target device. So a maximum 16 GB formatted partition is what you get on the output if you want to also get the built image deployment tools and files with it.)

Anyway, I didn’t have the spare time to look into this too deeply. I needed a solution now.

So what I did was take my previously captured IMG file of a 16 GB built USB imaging stick and used “USB Image Tool” to restore it to one of the 64 GB sticks.

It went on fine and quick and resulted (as expected) in a fully functional USB stick for imaging purposes that had a 16 GB volume (just like the original it was captured from) with the remainder unallocated space. That would work “as is” for image deployments but we can’t let that unallocated space go to waste can we?

So I then booted a lab system with a Parted Magic “LiveCD”.

I attached the 64 GB stick and used the “Partition Editor” utility to first locate the device (I think it was listed as “/dev/sdb”), then went though the process to resize the 16 GB partition to take in the remaining unallocated space. I ran the operation and after a warning that it might screw up the data it completed with no fuss. See a visual walkthrough on the process concept below.

When the properties for the updated device were checked on a Windows system, the full 64 GB size available on the stick partition was now showing!  Further testing in image deployments found that no corruption to the files/data occurred. It worked great.

I understand that if instead of XP we were running Windows 7 (or Vista) -- which we are not -- then I could have accomplished the same thing natively with the Disk Management tool. Maybe that day will come soon.

I found using Parted Magic a breeze. It was super fast and has been dead-on reliable all the years I have used it to clean up and fiddle with drive partitions.

However there are some other free partition management software tools that run natively in Windows. Check the licensing requirements to make sure they are not “personal use only” and respect accordingly. Some of the free versions have stripped down feature from the “pro” paid version the same company offers.

I keep one or two of these on my USB utility stick as a “just in case” if either DISKPART or Parted Magic fail me. But they really aren’t the butter for my bread.

That said, they look like they could do the same thing that Parted magic is delivering if Linux isn’t your thing.

Like I said, file this under “that’s one way to do it” for using a USB IMG file created from a smaller sized partition on a larger sized USB flash drive, then restoring the additional unallocated space.

If any GSD readers have any additional ways to accomplish the same thing via Windows Command-Line Fu or a small GUI utility I’d love to hear your suggestions; especially if the utilities are freeware/open-source or command-line only and especially if they would work in XP.

Also, if anyone can find documentation on any formatting size limitations that UFDPREP.EXE carries, I’d love to see the linkage. My Google search skills are not too shabby but I haven’t had luck with the right key search terms just yet. I’d like to know formatting limits of the tool before I tear into the actual process to see if our method is passing it a hard-coded \size=16384 or not.


--Claus V.

PS: Misc links I found in the process of searching for info on UFDPREP.EXE that might be interesting to someone:

WinPE Bootable USB - Creating from XP - The CD Forum - Walkthrough on where to get the binary file (from original source) and how to extract it (note it involves Microsoft’s Windows Embedded feature pack).

A Deep Dive into USB Boot - msdn - How UFDPREP actually does it’s magic.

No comments: