Saturday, May 22, 2010

OSTff revisited

In the last post (gosh has it been that long ago?) Blasting the blasted Outlook Secure Temporary file folder… I outlined a number of free utilities that would assist with deletion of the contents of that folder.

The user who had the issue leading us on this learning adventure eventually called back with the same problem again.  Additional monitoring of the user as well as the processes she was doing illustrated to me that some kind of Outlook error and/or interaction with Voltage was causing the opened attachments to remain “orphaned” even when closed out “properly.”

We then were faced with deploying one of the solutions noted.  I was leaning heavily towards OutlookTempCleaner and calling it at startup via a scheduled task or simple bat-file in the Startup folder.

However, in the end, the suggestion was made to just do a batch-file that cleaned it up without any additional third-party code.  OK, I’m game.

There were a number of approaches I could have taken, primarily just making a direct, hard-coded identification to the user’s particular Outlook Secure Temporary file folder location, but if that “randomly” generated location ever got changed, say if Outlook had to be reinstalled, then it might break.

Instead after a bit of research I found a suggested solution offered by GuruGary in this Experts-Exchange post: Outlook Secure Temp Folder Full : outlook, folder, temp, secure.

For a solution how about this in a batch file (that can be run as a scheduled task, or at logoff, etc.:
@echo off
for /f "tokens=3 delims=      " %%a in ('reg.exe query hkcu\Software\Microsoft\Office\11.0\Outlook\Security /v OutlookSecureTempFolder ^|findstr REG_SZ') do rd "%%a" /q /s

Depending on which version of Outlook she is running, you may need to change the 11.0 in the registry key.

However, try as hard as I could in testing, it just didn’t seem to execute correctly.

It was very clever; using the reg.exe utility to query the registry and obtain the key value holding the actual path to the user’s Outlook Secure Temp folder location, then doing a deletion of it.

I then proceeded to rework the batch file using Rob van der Woude’s link: Batch files - Reading NT’s Registry with REG.EXE.

In the end I crafted the following batch file that did work perfectly on our own XP Pro SP3 systems for the problem at hand.

@ECHO OFF

::Place batch file in C:\Windows\32 location so it can find the reg.exe utility.

::Place shortcut to this batch file in the user's Startup folder to run upon login.

::Will auto-clean the user's Outlook Secure Temporary File folder location of all "orphaned" files so gets a clean-slate.

::Queries registry location of that folder location, then uses information to delete all the files present.

:: Note: delims is a TAB followed by a space

FOR /F "tokens=2* delims=     " %%A IN (' REG QUERY "HKCU\Software\Microsoft\Office\11.0\Outlook\Security" /v OutlookSecureTempFolder') DO SET Location=%%B

DEL /s /f /q "%Location%\*.*"

Depending on which version of Outlook you have, you will have to modify the “11.0” number according to this Microsoft Support article 817878 --Attachments remain in the Outlook Secure Temporary File folder when you exit Outlook 2003 or Outlook 2007.

Yes, just having the end user periodically run a free utility when needed probably was much easier, but this will run almost silently in the background at each login and clean things out.  Also, because it queries the actual registry key location each time before running, if that does ever get changed, it can adjust, rather than had I simply “hard-coded” that specific path to begin with.

Rob’s website contains a wealth of detailed and helpful information for CLI junkies and batch-file writers:

He also has lots of great WMI Scripting information as well as an added bonus: Getting Started with WMI Scripting

Wayne Martin has another collection of lots of useful command-line models over at his WWoIT – Wayne’s World of IT blog.

Lots of inspiring commands and operations here…

Cheers.

--Claus V.

Saturday, May 01, 2010

Blasting the blasted Outlook Secure Temporary file folder…

Despite the challenge of the RDC issue last posted about, we did have one small but significant Windows system troubleshooting victory last week.

One of our end-users was working with Voltage to pull mail out of a shared mailbox into the local Outlook client.

When she attempted to open the attached file, the following error was seen:

Can't create file: message_zdm.html. Right click the folder you want to create the file in and then click properties on the shortcut menu to check your permissions for the folder

Several field techs attempted to resolve the issue during multiple site visits, to no avail.

So crack network analyst “Mr. No” and I dropped by while in the neighborhood on an unrelated special project to take a look.

Based on the error message, we doubly-checked the permissions on the user’s Outlook folders. We reloaded different versions of Voltage and fiddled with the enrollment certifications. Checked disk space. Ensured no permission or size limits found on the folders.  Purged the IE temp cache location. Nothing seemed to work.  Comparing this user’s settings in Voltage/Outlook to a co-worker who was similarly configured but not having the issue found nothing different.

So, in a brilliant move, Mr. No decided to Google the error message…and found this:

Turns out the user’s “Outlook Secure Temporary file folder” was filled up and needed to be flushed.

Once those steps were followed, the attachments could be opened again with no fuss.

Problem solved.

However, that wasn’t enough for Mr. Valca here.  What was going on and why was this user, out of the thousand-plus we support, having this particular problem?

Greetings Outlook Secure Temporary File Folder…Nice to meet you.

When I got back to the office I did more research and while not an unknown issue (and not limited to Voltage users by the way), it does seem to be rather uncommon.

I found a few posts in particular that described the issue and potential solutions.

These (and other forum posts) referenced the root-cause as Andy well summarizes from his above-linked post:

“…outlook has a limit on the number of files of the same name that it can store.  If you have 99 “orphaned” files in the temp folder whose source attachment have the same name, when you try to open the 100th, you will get an error saying you can not open any attachments.”

Only my mind was a bit confused.  How you you have up to 99 files with the same name in the same folder location?  That didn’t seem to make sense. And what was our particular user doing so well to cause that many to accrue in the first place?

And how were they being “orphaned” in the first place? The user stayed in Outlook all day long with no Outlook crashes found or reported.

The Experiment

I fired up my own system, dove into Regedit, burrowed down to the location (Outlook 2003) HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Security and copied the folder location found in the Value Name: OutlookSecureTempFolder key.

Then I pasted it into the address-bar of Windows Explorer and was taken to that folder location.

I had a few items in there, but none indicating duplicate names.  So I deleted them all to get a fresh slate.

I then popped into Outlook and sent myself a simple Outlook email with a dummy text file attachment called…wait for it…”dummy.txt”

With Windows Explorer still open to my Outlook Secure Temporary (OST) file folder location on the left, I double-clicked the test message to open it in its own window.  Then I double-clicked the attachment to open it.  Voilla!  the file dummy.txt was showing in the OST folder.  I closed the attachment and then closed the message and the file disappeared, automatically removed as expected by Outlook.

Next I repeated the process.  But this time I kept the attachment open but closed the message.  Then I closed the attachment.  To no surprise, the dummy.txt file was left behind and not deleted.

Then I repeated the process…only this time the file in the OST was automatically re-named to dummy_(1).txt (or something like that…I’m having trouble reading my notes).  Repeated testing found that if the email message Window was closed before the attachment, I could quickly add many more dummy_(#).txt files and leave them “orphaned” and preserved in the OST location.

So it seems that while “technically” the file names are not duplicate names…the attachment name is a duplicate and diff’ed by the addition of the “_(#)” name portion.  When the same file-name is present but the counter reaches “_(99)” then upon reaching the 100th instance, the error happens and the file attachment cannot be opened.  Now that made sense.

What I didn’t test, (and am curious as to) is what would have happened if I just created a file “dummy_(99).txt” in an otherwise emptied OST folder (that’s the only file present) and then tried to open my “dummy.txt” attachment, if the error would trigger due to the “_(99)” counter presence, and not an actual count of files really present.  I’ll try that one on Monday back in the shop but I’m pretty sure I already know the answer…

Knowing this, it is easy to understand the process by which this particular user was tripping over the error when almost nobody else is.

The user is receiving a high volume of inbound messages in the shared mailbox to process as part of her job duty.  These messages include a standard internal form attachment.  That attachment is frequently NOT renamed to something different by the sender. So even though the content of the form attachment is different, the file name is the same.

This end user opens the message, opens the attachment, closes the message (with the attachment still open…now “orphaned”) and proceeds to process the information in the form into another application.  Once done, the attachment gets closed.  This works fine for a while but eventually, enough identically named forms are processed/orphaned and the error trips upon #100.

Again, in our case it was Voltage attachments.  It could easily be PDF files/forms, Excel sheets, Word documents, whatever in your shop.  The attachment type isn’t the issue, it is the attachment “name” and how many times the attachment gets “orphaned” due to Outlook crash or (more likely) closure of the message body Window before the opened attachment itself gets closed.

Mitigation and Utilities

Because the default OST file folder location is typically “super-hidden”, it’s not easy to instruct most end users to browse into the registry and do a copy/past of the key value into Windows Explorer to empty things out.

In this case, it just required showing the end-user that she should either “save as” the attachment first before opening into a different location with an amended name before opening, or consider leaving the email message open, then when done with the attachment, close it, then the message body.

However, there are also some cool utility “toys” that can automate the process to various degrees as well:

  • OutlookTempCleaner -- (freeware) -- HowTo-Outlook. This simple exe file automatically finds and cleans the folder out when run.  What is particularly nice is that it supports CLI options for use in a login batch-file for automated cleaning if needed.  Also cool is the “big-brother” Outlook utility OutlookTools (also free) which brings extra Outlook support options to the table. NYC Tech Guys mentioned OutlookTempCleaner in their Empty Outlook’s secure temp folder post.

  • CleanAfterMe -- (freeware) –NirSoft.  This power-cleaning tool for Windows also has an option in it to clean that folder location, among many other deep-level things. 

  • CCleaner -- (freeware) -- Piriform.  More than one forum post also recommended use of CCleaner (newest versions) to clean this location.  I didn’t see it specifically noted/identified in the options, so maybe it falls into one of the general cleaning options.  Not sure.

  • Outlook Temporary File Cleaner – MSDN by anthonyrsc.  very small exe file (23K) with source-code provided.

So now I and our team are all much wiser to the Outlook Secure Temporary file folder and its solution.

Too bad the error message couldn’t be a bit clearer. I’m sure more than one sysadmin called in on this one has taken a while to check folder sizes and permissions in both Outlook and the local system before eventually associating the issue/solution with the blasted Outlook Secure Temporary File folder.

Cheers!

--Claus V.

In the trenches…

Been burning extra time working out a nagging Remote Desktop issue.  Still unresolved but I am stubbornly pressing on to solution it.

At the local house of worship, there is a pretty nice LAN setup.  At the sound/video desk we recently installed two Windows 7 Ultimate systems.  These are brawny multi-core systems, x64 bit OS, 8GB RAM systems.  More than enough muscle to power video/sound editing and projection work.

However the desk area itself is very limited.  So we dropped one box (with no monitor) under the desk. Then we use the second workstation on the desk to do a Windows RDC session to the 2nd (headless) workstation as needed.

Only the RDC sessions are a bit “wonky”.

Typically after the first RDC session is started, the login goes through, the remote system desktop is displayed, then the following error message appears on the workstation I am initializing the RDC session from:

“Microsoft Visual C++ Runtime Library
Program C:\Windows\system32\mstsc.exe
R6025
-pure virtual function call”

And the RDP session terminates.

If I try again, each time the connection gets briefly established, then kicks off, and the error appears.

After about 7-10 attempts, I am then able to get a “stable” RDC session established with no more kick-offs or errors.  So it does “work”.

I checked the remote system logs and found the following errors noted:

“Event ID: 9015
Desktop Windows Manager was unable to start because the remote client does not support desktop composition remoting.”

and

“Event ID:9003
Desktop Window Manager was unable to start because a composited theme is not in use.”

I’ve already made sure RDC exceptions are enabled on both systems in Windows Firewall.

I have tried reducing the headless system’s theme to “Classic” and disabling all Aero effects as far as I can tell.

I’ve made sure all the theme management services are running “automatic”.

I’ve tried disabling the various extra RDC “experience” options before connecting.

Same behavior.  Only after seven or more aborted RDC connections is a stable RDC session established.

I’ve tried using the RD client files from a “portable” build based on another system’s Win7 RDC files but same thing, so it doesn’t appear to be a corruption issue with the mstsc executable.

I’m still trying to research the root cause.  Other things I need to pursue this weekend:

  • I did have to turn off “Aero peek” on the system I am RDC’ing from as that was pulling “system focus” away from running presentations if accident hovered over.  Not cool during a service…  I’ve not yet re-enabled it to see if that has any bearing.  I don’t think so as the other geek seems to have the same issue from his own independent Win7 system RDC’ing to the target box.
  • I’ve seen lots of forum threads on similar issues.  In many of those cases the posters felt the issues was a bug in the Win7 RDP client itself.  They felt that way as connecting with a “portable” older set of RDP files from, say, XP SP3 didn’t demonstrate the issue.  I think they are using Remote Desktop Connection (Terminal Services Client 6.0).  I need to grab a set of that version to try to see if that makes a difference.

The facts that I see the error start just after the remote system’s desktop get displayed, that the event logs all mention “composition theme” in some fashion even though all settings seem to support a compatible rendering experience, and that with enough attempts, it eventually “works” suggests to me that it might, in fact, be some kind of network issue.  Could it be that the systems are “talking” too fast to keep up with each other as the different services interact and link-up?  I did find this tantalizing post on tweaking RDP network performance: Remote Desktop slow problem solved which tweaks the Receive Windows Auto-Tuning settings in Windows Vista…need to make sure it carries over to Win 7 as well first.

And yes, of course, we could go with a TVNC based remote desktop solution…or one of many others.  However, connection establishment error excepted, RDC fits the internal need just fine.

It doesn’t look like I am the only one wrestling with this issue.

When I finally get it resolved, I’ll post an update.

BTW, one early bonus from this “project” has been the discovery of the Remote Desktop Services (Terminal Services) Team Blog.  Lots of good info there for you Remote Desktop fans….

Cheers!

--Claus V.

Sunday, April 25, 2010

Playing Catch-up

Despite all my best wishes and efforts, I’ve really been under a tremendous production load of projects at work lately.

Hours stretched, long drives into field office locations for “in-the-trenches” work. Stuff like that.

I have still been checking my RSS feeds and building the linkage piles, but goodness, no time for weekend link posting of late.

One small benefit of the delays is that I will often go back now and re-consider that pile of 20+ links and after a week, find that some just weren’t worth posting comments on after all…so they will be struck.

This slow-simmering seems to result in a much tastier collection of tools and utilities.

So here you go.  About a month’s worth of slow-home-cooking served up for your dining pleasure.

Networking Link Portals

One of the things we have been doing lately is doing site-wide network traffic monitoring and analysis.  Our great network team has developed a pretty easy and deployable process to initiate a remote traffic capture and then internal analysis of the traffic/files.  Nothing super sophisticated but we can now pretty clearly generate a response report in record time.  That’s a small miracle in itself.

Here are three “portal” locations for great linkage and reference materials on Network traffic and analysis.

  • Cheat Sheets - Packet Life. Great collection of free PDF-formatted reference sheets on many things network traffic related. This Wireshark Display Filters (PDF) page alone has been very useful.

  • Network Monitoring Tools – Amazing collection of links maintained by Les Cottrell at Stanford.  Be careful. You could easily loose hours looking through the resources documented and organized here!

  • WinPcap Network Tools and Links – Lots of great tools, reference materials, and what-not all lined up and linked regarding WinPcap-supported tools.

Remote System Auditing Tools

In aftermath of yet another incident project, I began looking for an efficient way to remotely audit the physical status and configuration of remote systems in our network.  We haven’t really had a need in the past to do so, and in the past year have only now been running post-deployment audit reports on systems that we initially set up to capture/document key hardware items. However it has become clear I needed the ability to do ad-hoc surveys and reporting on the status of Windows systems long-since deployed in the field.  Our network management infrastructure software can (in theory) do this, but it is non-intuitive and burdensome to do so.  In addition, it requires the workstation objects to have been correctly imported to the container in the first place to access.  Not done so?  No data.  So obviously I could have some big holes in my site/system audit reports.

So I started looking for a simpler reporting solution.

I found a number of great (and free) tools to do so but they were either much more robust that I needed, or required a client/server model of deployment, or the reporting was just not customizable out for rapid site-wide auditing and exportation for additional analysis in Excel/Access.

Some of those tools that “almost” fit the bill but eventually fouled out were:

  • Total Network Monitor – freeware – Softinventive Labs.  Pretty full featured and awesome.

  • Remote System Information 3.0 - (shareware) – nice and had much of the system hardware auditing stuff I needed but the reporting wasn’t robust enough nor was the fact it was shareware and I couldn’t find where the developers were still in business.

  • Network Manager (NINO) - (open source) – Located this one on SourceForge and looks like a really heavy-duty network monitoring tool.  Ended up being too beefy for my targeted needs.

  • OpenNMS – (Open Source) -  Another very robust network management platform.

  • Lan Sweeper – (Free/$$ versions) – I really, really liked this one.  It covers so many of the mission-critical system auditing and monitoring points.  However it is based on a client/server type of model.  I wanted something that didn’t require me to deploy clients on all our systems in addition to the existing network client infrastructure in place.

  • Zenoss – (Open Source) – Another very mature and polished network/systems monitoring platform.  Again, too robust for my needs.

  • Network Inventory - (shareware/$) – Very nice but ultimately not free/OpenSource and cost is king now.

  • Network Inventory Advisor - (free-trial/$) – Also nice, especially in that it was not agent/client based but again, the free trial period is limited and there is no $ in the budget for this project.

  • AdvancedRemoteInfo - (freeware)  — Pet project of Matthias Zirngibl at masterbootrecord.de.  This was an unexpectedly special find from Germany.  Still in development, this beta level utility really has a lot of great bells and whistles.  It provided extensive information about remote system hardware/software and data-points.  It also allowed for some useful remote interactions with the target system and reporting was much better.  However, again, I needed something that let me manage reports on a site-wide number of systems, not one-system-at-a-time reporting.  Still, this is a great tool and I’m going to be keeping an eye on it in the future!

At this point, after almost an entire week of looking for just the right tool, I was almost ready to give up.  I checked in with Michael Pietroforte over at 4sysops.  He referred me to his lineups of Free Windows Networking Tools and Free Windows Inventory Tools  (in fact see his full selection of categorized Free Windows Admin Tools – 4sysops). However, none of those offerings were fitting the bill either.

Then while in the middle of our dialog, I found that an old-favorite had been updated with just the feature-sets I was looking for:

This ended up being perfect as it is a single, portable exe file based utility.  Though not “tiny” at 720K, it still packs an amazing feature set in.

I am now able to remotely run an IP scan against an entire network site range, and then can set WMI-based custom reports to pull data from the systems.  Because by audit is IP based, I’m much more likely to identify the devices on the network rather than those “objects” that were imported and calling home from a client/agent configuration only.

And the WMI-based reporting options are off the hook.

Look for a more detailed post soon on this project, but for now, I highly recommend checking it out.

The only potential “gotcha” is that WMI services and firewall port rules/policy must be configured, up, and running on the remote systems to get all the WMI-accessible data for your reports. If you have that in place, then you can easily run and export tons of highly detailed system audit report data.

Please look below for more useful WMI (Windows Management Instrumentation) resources that are must-reads if you are not yet familiar with it and need to do some homework for deploying and accessing the data it can potentially provide.

New or Improved Fun Utilities

These remaining tools caught my fancy this week.  They “remain” from the many more that seemed interesting from this week but on additional look didn’t make the draft-cut.

Remote Desktop Trick

Windows Remote Desktop is a cool trick to access and manage a system across your network.  But what if you don’t have it enabled on the system? And either the end-user is totally clueless, rights restricted, or otherwise unable to initialize some other remote-control solution?  This might be a trick to try.

Chrome Browser

I’m still nowhere near ready to jump ship from Firefox to Chrome full time, but I do find myself using the Chromium nightly versions in a portable version much more.

Here are the very small set of “add-ons” that I have found useful to load on it.

I’m running a portable version of Chrome (Portable Google Chrome 2.0.172.23 or Portable Google Chrome 2.0.159.0) along with Dirhael’s (portable) Chromium Nightly Updater to keep the package frequently updated.  However, that has required unpacking and copying over the update packages into my the portable Chrome application folders.  No biggie but additional work.

So I was delighted to find that Carsten “caschy” Knobloch has recently started including an multi-build supported updater in his Portable Chrome package: Portable Google Chrome 4.1.249.1059 (German site) has the latest full portable packages for download or you can simply unpack it and copy the single exe updater file to your existing portable Chrome package and use it from there.  It automates the process to check, download, unpack, and install the latest Chrome release versions into you portable Chrome folders.  Way too cool!  See this post Neue Version des Portable Chrome Updaters (German) for additional info on the updater proper.

Firefox 3.7 Stuff

And the next iteration of Firefox is still marching closer to readiness.  I like what I am seeing, but I was surprised when my playing with a portable version of this latest release actually BSOD my Windows 7 x64 system.  First time ever that has happened.  Lots of fun stuff here but be careful!

More Cool Utility Toys and Tips – Part II

I hope you found something yummy for your Windows system here today!

Cheers!

Claus V.

Thursday, April 01, 2010

Security and Forensics Roundup: Heavy Version #7

Oh my.  I may have bit off more than I can chew with this load of links.  I’m having a challenging time breaking them all down into meaningful chunks!

Incident Response

  • The Tiger and the Ghost – Nice and reflective thoughts on the changing landscape of incident preparedness from Hogfly over at the Forensic Incident Response blog.

  • Verizon Incident Metrics Framework Released – Verizon has published a framework for categorizing incidents and elements that comprise them.  One of many out there, nevertheless, it might provide some additional ideals for conceptualizing incident events and help guide you as you form narratives that analyze and summarize them for your audiences. Spotted via the TaoSecurity blog.

  • DarkReading Evil Bytes bloggist John Sawyer has posted a trilogy of articles on incident response as well as drive-imaging thoughts and techniques in that response; Adding Forensic Imaging To Your Standard IR Process, Using Hard-Drive Imaging In Forensics, and Drive Imaging Using Software Write Blocking provide an updated refresher on these topics. Good for a quick review particularly for the unfamiliar.

  • Responding to Incidents – Windows Incident Response blog.  Coming in at the anchor position is a great post by Harlan covering all the major points and issues on why establishment and execution of an organizational incident response plan for the IT shop is critical. If you don’t have one, it’s long past time to start building and implementing one.  Failure to do so comes with great peril.

Timeline Merry-go-Round

Having some time ago been faced with the challenge of preparing a digestible incident timeline of a Windows system, I am now paying even closer attention to timeline issues.  Like many, I had reams of data, much of it all valuable. However, the real challenge wasn’t so much the capture and spin-out of the information, it was presenting the findings in an objective manner that successfully and accurately told a story to management and non-IT consultants.  What was of value to me understanding the sequence of events was less valuable to those who wanted the big-picture and major-plot-points.  It end up being as much the art-of-communication as well as art-of-examination.

It’s all about Analysis

  • Flock shepherds in a Life of Grime – Forensics from the Sausage Factory blog.  In which in this installment, we find DC1743 encountering the Flock browser, which is just a fancified version of Firefox geared to the social media experience.

Tools and Toys

Miscellanea: Don’t count out the value of small things…

Cheers.

--Claus V.

April 1st link-dump

No. No April Fool’s jokes here.  All are refreshingly legit.

Cheers.

--Claus V.

Sunday, March 21, 2010

WinPE Multi-boot a Bootable USB Storage device

Amazing!

Things like this keep up my faith in blogging and the blogging scene.

I’ve posted a number of articles related to WinPE as well as making portable storage devices (USB HDD/ USB flash sticks) bootable for use as WinPE boot media.

It was under that last, most recent post that I mentioned a trick I do to carry multiple WinPE boot.wim varieties on my bootable USB stick:

On my own bootable USB flash stick, in addition to the required “SOURCES” folder and contents, I also have a “SOURCES-ALT” folder.  In there I keep all my additional and scratch-space-adjusted WIM files.  So I have a  Boot-32.wim, Boot-128.wim, Boot-256.wim, and a Boot-512.wim file stored in there.  Typically, I have the 512 MB set scratch-space boot.wim file in my SOURCES folder to boot with.  However, if I know I need to WinPE boot a system that that wouldn’t work on, then I can delete the boot.wim file out of my SOURCES folder on the USB stick, and copy another more appropriate version from my SOURCES-ALT folder over into it, say the Boot-128.wim one.  Then I rename it to boot.wim and I am good to go!

In fact, once the contents of the WIM file are loaded into the scratch-space/RAM Disk, it is then released.  That means if you are going from a system that uses the 512 MB scratch-space, and then progress on to one that will require the 64 MB scratch-space version, it seems you can do the boot.wim delete/copy/rename routine on your USB stick still from within your WinPE boot session!  I’ve done this on a number of occasions.

Even more fun is making up not just different scratch-space flavors of the boot.wim file, but even wholly different versions of the boot.wim file itself!  You could have a custom WinPE 2.0 boot.wim file, a custom WinPE 3.0 boot.wim file, an AntiVirus PE Disk to offline-scan a Windows system, or maybe, say, a Win(FE) forensics build boot.wim, and so on…limited only by the size of your USB storage device and your imagination and efforts.  Even different WIM files with different hardware drivers injected for various system platforms.  Instead of carrying a mess of optical disks, just a single large USB storage may do the trick (assuming the system BIOS supports USB based booting).

Of course, you do have to reboot the system to then load whichever WIM file you have swapped out…but I’m sure you knew that already.  Just keep the originals safely and alternatively named in your “storage” folder location and delete/copy/rename the original boot.wim file as needed.

Brilliance = Bret ?

Well, there I was thinking just how clever a trick this was to sort-of “multi-boot” the WinPE’s off my USB stick.

Then Bret came and visited the blog and dropped an “outside-the-box” kind of comment that was bloody brilliant.

Instead of copying and renaming your boot-*.wim files, have you thought about using bcdedit to add entries to display a bootmgr menu with choices of each wim? You could keep all of the wims in your sources folder, too. I like to have a menu with a 4-second timeout to the default.

I read it and just sat there stunned.

Seriously.

Simple and elegant…and something I was already familiar with (in concept) from my earlier boot to VHD work.

Crap.  Now I’ve got yet another fun project to work on tweaking my super-boot USB stick.

In case you haven’t caught what Bret proposed, he is saying that we can just set the BCD file in the \boot folder to point to additional wim entries as well as the default boot.wim.  You can name then whatever.wim you wish and then when you boot from the USB device, be offered a nice multi-bootloader menu and select which particular flavored wim you want to boot from.

No swapping out/renaming of the extra wim’s you carry.  No rebooting to get the one you want loaded.

See?

Simply brilliant.

How To Resources #1

Amazingly, I didn’t find all too many references to this trick on the Net and forums.  There are a few, and they all seem to be pretty recent.

Below are some of the best resources I located to help guide someone through the process.

Both of these techniques require comfort and skilled familiarity with the command-line bcdedit.

Just take a lot of notes and make sure you have pre-structured which wims you want to use before you get started.  Being organized first will save you a lot of headaches.

How To Resources #2

If you are just not a CLI person, then there is at least one GUI alternative to use: EasyBCD

The current version does allow you to work with PE files.

The trick is to first run the program then load the BCD (Boot Configuration Database) file on your portable WinPE boot stick located in the\boot folder.

However, I discovered that the EasyBCD 2.0 Beta Builds (free registration required to access) have even more robust and enhanced support.

With the latest version (2.0 Beta Build 86) You can actually not just add additional WIM files to your bootloader but VHD files as well. ISOs are another option but I’ve got enough on my hands for now to take in!

Using EasyBCD should allow you to back up your existing bootloader file before making changes.  Just be very sure you are on the USB drive \boot folder and not the one for your primary system.  If you get mixed up and start making incorrect changes, bad things could happen man.

Sure, with the base bcdedit application, you have all you need without extra software, but EasyBCD is very slick and just (basically) provides an advanced GUI wrapper for the bcdedit app at the core.

Choice is yours.

Here are some additional links that while not directly related to multi-booting of USB sticks, do have additional great examples of bcdedit in action for reference.

Final Thoughts

This is a really cool synthesis of concepts and even more could be extended from this on your USB device.  Really the only limits are the size of your storage device to hold the files, the memory of the system it is running on, and the speed of the hardware to make it usable.

You almost certainly don’t have to limit yourself to just WinPE wim files.

Imagine also if you had a VHD file of a full-blown specialized Windows 7 system  or Sever 2008 to pick from your bootloader list, and not just the WinPE flavors.  Awesome.

Spend some time poking around on Mark Wilson’s blog.  He’s got a lot of research and lessons learned on his and other sites he found that we can benefit from there.

  • Running Windows from a USB flash drive– Mark Wilson blog. .

  • Windows 7 and Windows Application Compatibility : Boot from Windows 7 VHD Boot without having any native Operating System.

  • Booting Hyper-V R2 off a USB stick – Virtual PC Guy’s weblog.

  • Create bootable USB drive for Hyper-V Server 2008 R2 – MSDN Code Site.

  • Boot from VHD – the joy of BCDedit and a nice hyper-v gotcha or two – James O’Neill’s blog.
  • My Boot-to-VHD experiment: found some tips, like it, but still haven’t found VM nirvana - Jon Galloway.
  • Anyway…you get the idea.

    I’m likely to stick to WinPE / WinFE wims myself but I’ve already got a project in mind once I get my own USB boot stick squared away.

    We deploy to our techs a bootable WinPE portable HDD.  It boots from the base WinPE boot.wim (32 MB RamDisk). None of the extras and we use it for imagex system image deployments.  I’ve stuck with the base boot.wim as it will work dependably on most all our desktop systems.

    The techs have been clamoring for me to switch out to the heavier customized WimPE image I provide them on a CD-ROM disk.

    I’ve declined as it just doesn’t work on some of our system-RAM limited desktops/laptops while the CLI WinPE base would.

    Now I can give them their cake and let them eat it too.

    Sweet baby jebus.

    All this because of Bret….

    Cheers!

    --Claus V.