The Windows Servicing Guy

Tips and tricks from a Windows support engineer on issues related to servicing

Doing things differently with Windows 7

Doing things differently with Windows 7

  • Comments 18
  • Likes

Because I wanted to keep a lot of these blog posts relevant to servicing the operating system, I thought I would talk a little about the changes to how we service the operating system in Windows 7. 

The first concept I wanted to cover was the idea of "online" vs "offline" servicing.  In online servicing, you are making changes to a live system using any variety of tools.  The easiest way to online service an installation is to simply install a Windows Update.  You can manually do this with PKGMGR or other tools as well, but the idea is that the system is live.  With offline servicing, you're mounting an image (a .WIM file in this case) to a folder and then performing operations against it using tools such as PEIMG or PKGMGR to inject drivers, fixes, etc into the image so that it can be deployed at a later time.

In Windows Vista and 2008, we had a lot of tools that we used to service the operating system and they could be confusing as to which tool did what.  Most people ended up using PKGMGR for the majority of their servicing operations online or offline, and while this isnt a bad thing, it can cause issues.  Because PKGMGR doesnt do any real checking against dependancies for things such as required reboots, customers would sometimes find themselves in the position of having random component store corruption, or post deployment corruption because of a few manually installed updates that both had reboot requirements.

Because there were so many tools and ways to do things, we decided it might be a good idea to have a "one stop tool" that does both the online and offline servicing of images and installations in Windows 7.  Enter DISM.exe.  DISM (Deployment Image Servicing and Management Tool) will act as the replacement for several tools that existed with Windows Vista and 2008.  The largest of which is PKGMGR.  Anything you could do with PKGMGR you can do with DISM.  The structure is a little different but the core concepts are the same.  The main difference is that DISM has built in logging, which is logged to \Windows\Logs\DISM\DISM.log and that you can specify what kind of servicing you wish to do (online or offline).

The general help for DISM looks like this (as of RC1 and subject to change by RTM):


Deployment Image Servicing and Management tool
Version: 6.1.7100.0


DISM.exe [dism_options] {WIM_command} [<WIM_arguments>]
DISM.exe {/Image:<path_to_offline_image> | /Online} [dism_options]
         {servicing_command} [<servicing_arguments>]

DESCRIPTION:

  DISM enumerates, installs, uninstalls, configures, and updates features
  and packages in Windows images. The commands that are available depend
  on the image being serviced and whether the image is offline or running.

WIM COMMANDS:

  /Get-MountedWimInfo     - Displays information about mounted WIM images.
  /Get-WimInfo            - Displays information about images in a WIM file.
  /Commit-Wim             - Saves changes to a mounted WIM image.
  /Unmount-Wim            - Unmounts a mounted WIM image.
  /Mount-Wim              - Mounts an image from a WIM file.
  /Remount-Wim            - Recovers an orphaned WIM mount directory.
  /Cleanup-Wim            - Deletes resources associated with mounted WIM
                            images that are corrupt.

IMAGE SPECIFICATIONS:

  /Online                 - Targets the running operating system.
  /Image                  - Specifies the path to the root directory of an
                            offline Windows image.

DISM OPTIONS:

  /English                - Displays command line output in English.
  /Format                 - Specifies the report output format.
  /WinDir                 - Specifies the path to the Windows directory.
  /SysDriveDir            - Specifies the path to the system-loader file named
                            BootMgr.
  /LogPath                - Specifies the logfile path.
  /LogLevel               - Specifies the output level shown in the log (1-4).
  /NoRestart              - Suppresses automatic reboots and reboot prompts.
  /Quiet                  - Suppresses all output except for error messages.
  /ScratchDir             - Specifies the path to a scratch directory.

What is interesting about the DISM help is that it doesnt give you all of the options.  You have to specify the /online switch to see the other options.

The following commands may be used to service the image:

WINDOWS EDITION SERVICING COMMANDS:

  /Set-ProductKey         - Populates the product key into the offline image.
  /Get-TargetEditions     - Displays a list of Windows editions that an
                            image can be upgraded to.
  /Get-CurrentEdition     - Displays the editions of the specified image.
  /Set-Edition            - Upgrades the Windows image to a higher edition.

UNATTEND SERVICING COMMANDS:

  /Apply-Unattend         - Applies an unattend file to an image.

DRIVER SERVICING COMMANDS:

  /Remove-Driver          - Removes driver packages from an offline image.
  /Add-Driver             - Adds driver packages to an offline image.
  /Get-DriverInfo         - Displays information about a specific driver
                            in an offline image or a running operating system.
  /Get-Drivers            - Displays information about all drivers in
                            an offline image or a running operating system.

INTERNATIONAL SERVICING COMMANDS:

  /Set-LayeredDriver      - Sets keyboard layered driver.
  /Set-UILang             - Sets the default system UI language that is used
                            in the mounted offline image.
  /Set-UILangFallback     - Sets the fallback default language for the system
                            UI in the mounted offline image.
  /Set-UserLocale         - Sets the user locale in the mounted offline image.
  /Set-SysLocale          - Sets the language for non-Unicode programs (also
                            called system locale) and font settings in the
                            mounted offline image.
  /Set-InputLocale        - Sets the input locales and keyboard layouts to
                            use in the mounted offline image.
  /Set-TimeZone           - Sets the default time zone in the mounted offline
                            image.
  /Set-AllIntl            - Sets all international settings in the mounted
                            offline image.
  /Set-SKUIntlDefaults    - Sets all international settings to the default
                            values for the specified SKU language in the
                            mounted offline image.
  /Gen-LangIni            - Generates a new lang.ini file.
  /Set-SetupUILang        - Defines the default language that will be used
                            by setup.
  /Get-Intl               - Displays information about the international
                            settings and languages.

APPLICATION SERVICING COMMANDS:

  /Check-AppPatch         - Displays information if the MSP patches are
                            applicable to the mounted image.
  /Get-AppPatchInfo       - Displays information about installed MSP patches.
  /Get-AppPatches         - Displays information about all applied MSP patches
                            for all installed applications.
  /Get-AppInfo            - Displays information about a specific installed MSI
                            application.
  /Get-Apps               - Displays information about all installed MSI
                            applications.

PACKAGE SERVICING COMMANDS:

  /Add-Package            - Adds packages to the image.
  /Remove-Package         - Removes packages from the image.
  /Enable-Feature         - Enables a specific feature in the image.
  /Disable-Feature        - Disables a specific feature in the image.
  /Get-Packages           - Displays information about all packages in
                            the image.
  /Get-PackageInfo        - Displays information about a specific package.
  /Get-Features           - Displays information about all features in
                            a package.
  /Get-FeatureInfo        - Displays information about a specific feature.
  /Cleanup-Image          - Performs cleanup and recovery operations on the
                            image.

So as you can see, there are a ton of options available with this tool.  I will discuss some of the specific uses and PKGMGR parity in a later blog.  I just wanted people to start thinking about this now.

As a side note, PKGMGR and the other tools DISM replaces are still in box but they are being deprecated, so it would be a good idea to update any current scripts that utilize the older tools to include the new DISM commands.

Comments
  • I have several beefs with Windows Vista/7 servicing lately:

    -  Service Packs are not cumulative anymore (probably to reduce download sizes) which is ridiculous. We want cumulative Windows SPs. Hope this'll change for Windows 7.

    -  According to http://blogs.msdn.com/e7/archive/2008/11/19/disk-space.aspx, the only way to keep WinSxS size in check is to install fewer updates? WTH? No way to skip backing up of files for "reliability" reasons? WinSxS size increases even if I turn on/off Windows components. Not done.

    - Service packs take too long to install and too many reboots

    - Service packs can't be quickly and easily slipstreamed. Sure you could mount the image and do offline/online servicing, generalize and recapture the image but that's a pain.

    - DISM has no GUI, we need a GUI which builds an answer file/XML like we had Setup Manager.

    Hope this'll improve for the better for Windows 8. Particularly, slipstreaming ability.

  • In reponse to your comments...

    Winsxs will scavenge during an uninstall event.  Meaning, that if you uninstall something like Games for instance, the scavenger will kick off and remove files that are no longer in use.  Installing fewer updates would reduce the size of Winsxs of course, but its not the only way to do it.  There are other tools that will allow the removal and pinning of files on a system.

    Service pack installation times are long if you download the package from WU because it needs to be built.  In general though, I dont think that they are crazy long.  Care to elaborate?

    I agree with you about slipstreaming and this is something that has come up several times, I will keep fighting that fight internally, we'll see what happens.

    The Windows System Image Manager is the tool to use for creating unattend.xmls now and it is GUI based, as is the Microsoft Deployment Toolkit.  What do either of those tools not do that would require DISM to be GUI based?

    I'm all for comments and suggestions and I will take them to the product group.  I cant say what will get fixed and what will not, but you never know until you ask, right?

  • "There are other tools that will allow the removal and pinning of files on a system."

    Meaning tools that reduce the size of WinSxS that are not a threat to the integrity/reliability of the system? Can you point me to some? I don't want to use unofficial third party tools like vLite. AFAIK, VSP1cln/compcln are only for Service Packs. I am not aware of any tools that clean up WinSxS while maintaining integrity of the servicing store.

    For service pack installation times of course I was referring to the network (full) installation package which also requires several reboots starting with Vista and takes at least 1 hour (SP1) on faster systems and more on slower systems (compared to 8-10 mins for XP SP3). Plus service packs being not cumulative, it is even more of a pain. I upgraded from XP to Vista so I have an upgrade DVD. Currently, if I want to reinstall after a fresh format, I have to install XP, then start Vista setup, install Vista, install SP1, install SP2. Too long. If it was slipstreamable, the install time issue also goes away.

    You said about DISM replacing WISM (and all other deployment tools-ImageX etc). I know WISM has a GUI, I wished for DISM to be GUI based.

    Thanks for replying. I'm glad user comments are being heard at Microsoft. :-)

  • I forgot to mention: To provide transparency to users, I'd like a CLI/GUI tool that correctly calculates the size of a folder minus its hard links, sym links and junction points so I'm aware of the true size of WinSxS.

  • Thanks for the comment.

    As for the other tools, I was referring to the CLN tools already mentioned here and elsewhere, aside from that, there is only an uninstall of a feature or hotfix.  But.....what I will do is bring up the possibility for another tool like this to be built or looked at.  You can also send mail as a customer to mswish@microsoft.com and request the same thing.  If enough people do that, it will get attention.  Sorry for that added confusion, thats on me.

    I do agree with you, like I said before, about the slipstreams.  I understand the pain of reinstallation in your case due to the fact that you upgraded.  The only real suggestion I can give you (and I know its not much) is to use MSDN if you have an account and use integrated media for future installations.  Or, you can build your own integrated installation using SYSPREP.

    For DISM, I'll see what others think about the idea.  I also miss SETUPMGR, and I know others do as well, maybe there is something that can be done here.

  • Just for the note: 'mswish@microsoft.com' is dead since long. I always get a postmaster email delivery failed error message.

  • Weird, I thought it was still working.  I will see what it is internally and post the new (if existant) address.  Sorry about that.

  • So it looks like all customer feedback now is being sent through the Connect portal for each project.  Its located here: https://connect.microsoft.com/intro/?wa=wsignin1.0

    That being said, I will take feedback to the product group from comments here as well, that was the entire point of my blog in the first place :)

  • +1 on the razz for mandatory, undeleteable, redundant WinSxS backup of every MS file revision that ever existed on my system.  This is onerous on technical and philosophical grounds:

    a) I want to install Win7 on a small SSD to boost desktop performance affordably.

    b) I multi-partition my system linux-style for performance and security, and want to continue generating system images free of redundant "internal" backups.

    c) It feels like the paying customer's right to configure a system according to their own risk tolerance is about to be sacrificed for the goal of reducing someone else's IT support liability.  Make me edit a registry key, require license key re-entry, void my online help support, add me to a blacklist of non-certified backward thinkers... just don't make a bare-bones installation impossible!

    A couple other ideas to address robustness concerns:

    * Back up only file meta info in the WinSxS folder.  Provide me the option to either (a) Store the actual file backups to a separate path, or (b) for MS files, rely on download from Windows Update as needed.

    * For corporate networks, give IT staff a way to lock in each workstation's WinSxS backup.  Just don't make it impossible for rogue individuals like me to defeat my own safety net for my own purposes.

    >>> someone said:

    -  According to http://blogs.msdn.com/e7/archive/2008/11/19/disk-space.aspx, the only way to keep WinSxS size in check is to install fewer updates? WTH? No way to skip backing up of files for "reliability" reasons? WinSxS size increases even if I turn on/off Windows components. Not done.

  • Thanks for the comment Kevin.

    In Win7 the whole idea behind the design of 7 was to alleviate some of the space considerations for install to smaller SSDs and drives.  As such, 7 has a noticabley smaller footprint than Vista does.

    As for the WinSxS backups, you have to keep in mind that the component store is a flat of the operating system, so its not really so much a backup as it is the actual OS.  Because the files are hardlinked, the actual space to be gained within the OS from a flat binary installation method is probably a moot point (although I will freely admit that I dont know what it would be because it never existed).

    That all being said, I agree with you and other posters who would like a way to trim the size of WinSXS without using a tool like VSP1CLN and I will continue to give that feedback to the product group.

  • DISM can do so much and yet there is one image servicing function that is curiously absent, and that is the ability to create catalog files (*.clg). Why is there no /make-catalog (or similarly named) switch/feature? Everything can be automated by DISM, except the building of catalog files which require the WSIM GUI app. Could this functionality be added in a future update?

    "I agree with you about slipstreaming and this is something that has come up several times, I will keep fighting that fight internally, we'll see what happens."

    Could you explain the technical reasons why slipstreaming is currently not available?

  • Drew;

    The catalog piece is really a function of WSIM, that's why its not included here.  The catalog is really only useful when building an unattend.xml.

    As for the integration of the service pack, it has to do with binaries not being servicable in an offline state.

    --Joseph

  • The reason I ask about making catalog files from the command line is that I'm working on some scripting that will successively image a system with each SKU in install.wim, and then apply updates, both online (SP, etc), and offline (IE, etc). I'm sure I can pull it off but ultimately the only operation that will not be scriptable will be the creation of catalog files.

    Btw, having to apply service packs online in this scenario will not make servicing Vista/7 more complex than XP, since XP has to go online to install some updates, like IE8 and WMP11. So in my case, offline slipstreaming of service packs would only be a plus if *all* updates for an OS can be applied offline.

  • Why not use MDT for this?  It can enable you to take care of your image servicing scenarios and take care of multiple operating systems: technet.microsoft.com/.../dd407791

  • I should learn more about the MDT. However I can do most of the things i need to do for the small-scale scenarios I normally deal with using only the WAIK and other inbox tools. The MDT would be one more layer of 'infrastructure' and one more technology to master. The WAIK is simple and I like writing batch files (seriously), but I will have another look at the MDT soon.