Microsoft currently has a tool called VHDMount, as part of Virtual Server that lets you mount a VHD on a host as a drive letter. That's great for reading/writing files but it does very little for true offline patching. Installers and patchers as written today, modify the active system. They do pre-req checks on the wrong system, possibly laying down wrong files, etc. More importantly they don't handle changing the registry of the OS in the VHD. Nor do they handle tasks like joining a Windows system to an Active Directory server which is more than a few registry changes.
Microsoft and other vendors need to step up to solve the offline image update problem. What some third-party vendors do is capture the files and registry changes and make these available as file packs or distributed installers. Think of the AutoPatch scheme that Microsoft recently squashed. Some of these tools can copy files, delete files, and load an inactive Registry hive and update it. One negative of a third-party solution is version tracking and integrity checks - do you trust where you get your patches?
There are at least two different ways to do this: patch completely dormantly or patch on boot. Patch on boot can be OK unless that patch requires a reboot, which means more reboots The advantage of patch on boot is that you can usually use the original vendors tested patches in silent mode.
Patch dormantly is very nice too because can you do extended things like arm SysPrep or completely slipstream a series of patches into the OS. The negative is there is nearly no support for this from software vendors and you end up having to roll your own patchers, figuring out files that changed and registry changes. If vendors find out you've patched this way, they may not support you.
Finally, being in the virtualization space, this topic would not be complete without talking about Software Virtualization. There is a solution from Symantec-Altiris called Software Virtualization Solution that captures all file and registry changes in a container called a "layer" Layers are like undo disks in that they capture a set of changes that you can turn on or off at the system level. You can capture installations of a browser like Firefox or a runtime environment like a version of Java, e.g. 1.6_02. When you turn on a layer it looks like that product is installed. And you can activate multiple layers for instance mixing and matching browser versions or different versions of Java.
SVS has two modes one that watches an Installer (to capture changes) and one that monitors the whole system. SVS can be used for patch testing and deployment because you install a patch once and copy the layer to a network share then activate it on multiple systems therefore "patching" those systems virtually. Software Virtualization is fairly new and niche but I thought I would mention it here.
Now some bad news is that images you put in the Surgient System Library depend on their base images not changing, i.e. if you touch the parent all snapshots become invalid, so you really want to patch all snapshots instead. The VHDMount tool is limited in this regard.
A workable solution is to deploy snapshots and automate patching them with SMS, vendor silent installs, etc. and saving the snapshots. This is a normal part of the VQMS test cycle.
Surgient is aware that offline testing is a pain point and considering the above that's a small glimpse of the options we're investigating to address the issue. Keep in mind some of these ideas are more the research phase ("R") than development ("D"). Not all research makes it into shipping product so you may not see immediate announcements in the next release.
Let us know what's important to you, your timeframes on projects, and how offline patching can change your workflows.