understand and troubleshoot servicing in windows server 8 beta

Understand and Troubleshoot Servicing in Windows Server "8" Beta

Microsoft Corporation

Published: February 2012

Abstract

This Understand and Troubleshoot Guide (UTG) enables you to learn technical concepts, functionality,

and troubleshooting methods for Servicing in Windows Server “8” Beta. This UTG provides you with:

A technical overview and functional description of this feature.

Technical concepts to help you successfully install, configure, and manage this feature.

User Interface options and settings for configuration and management.

Relevant architecture of this feature, with dependencies, and technical implementation.

Primary troubleshooting tools and methods for this feature.

Copyright information

This document is provided “as-is”. Information and views expressed in this document, including URL and other

Internet Web site references, may change without notice.

Some examples depicted herein are provided for illustration only and are fictitious. No real association or

connection is intended or should be inferred.

This document does not provide you with any legal rights to any intellectual property in any Microsoft product.

You may copy and use this document for your internal, reference purposes.

© 2012 Microsoft. All rights reserved.

Active Directory, Hyper-V, Microsoft, MS-DOS, Visual Basic, Visual Studio, Windows, Windows NT, Windows Server, and Windows Vista are trademarks of the Microsoft group of companies.

All other trademarks are property of their respective owners.

About the Authors

Author: Joseph Conway

Bio:

Joseph is a Senior Support Escalation Engineer on the Windows CORE team based in Charlotte, NC with 13 years of Windows support experience. He has experience in releases of Windows from Windows NT 4.0 to Windows Server 2008 R2 and is currently a beta engineer on the Windows Server "8" Beta team. Joseph has created or contributed to many training courses and Microsoft KB articles and is the author of the Windows Servicing Guy blog (http://blogs.technet.com/b/joscon/)

http://blogs.technet.com/b/joscon/

Table of Contents

Understand and Troubleshoot Servicing in Windows Server "8" Beta ......................................................... 1

Introducing Windows Servicing ................................................................................................................................. 1

Technical Overview ............................................................................................................................................... 2

Componentization terminology ............................................................................................................................ 2

Component state terminology .............................................................................................................................. 3

Features on Demand ................................................................................................................................................. 4

Using DISM ................................................................................................................................................................ 4

In-box Corruption Repair ......................................................................................................................................... 19

Troubleshooting issues with servicing ........................................................................................................ 24

Confirming component store integrity ................................................................................................................ 24

Log gathering and analysis .................................................................................................................................. 25

In-box tools used for recovery ............................................................................................................................ 29


1


Introducing Windows Servicing

What Is Windows Servicing?

Windows servicing describes anything that changes an operating system file, registry value,

or other state configuration of a Windows computer. Windows servicing includes things like

installing a Windows Update, adding a role or feature, or adding a driver. There are several

tools involved in Windows servicing mechanics. In previous Windows releases, this included

tools such as the in-box Deployment Image Servicing and Management tool (DISM), Package

Manager (PKGMGR), and Server Manager, as well as the tools included in the Windows

Automated Installation Kit (WAIK) and externally available releases like the System Update

Readiness tool (CheckSUR).

This guide focuses on the main servicing changes made for Windows Server "8" Beta and the

tools that work with these changes. The emphasis is on the DISM tool as it has replaced the

PKGMGR tool and many of the tools in the WAIK.

Purpose/Benefits

Windows servicing design is based on the concept of operating system componentization.

Componentization allows uniformity in the Windows codebase by allowing all Windows

developers to write to a standard manifest. Additionally, the servicing design allows for a

more robust mechanic for the installation or removal of a specific binary by supporting

transactional rollback of operations.

DISM was created to be a consolidated tool for any operations needed to prepare an image

for deployment or modify an image post-deployment. DISM consolidated many of the tools

previously included in Windows AIK with Windows 2008 and Windows Vista.

Windows Server "8" Beta enhances the DISM tool to include robust new features for pre-

deployment and post-deployment environments. We will discuss these improvements

through the remainder of this guide as well as offer hands-on examples, that can further

increase understanding of this tool and its capabilities. In brief, the new components are:

Features on Demand

In-box corruption repair

IMAGEX ported to DISM

Fully offline capable support

DISM Windows PowerShell cmdlet support


2 © 2012 Microsoft Corporation. All rights reserved.

Technical Overview

Requirements

The Windows Servicing components do not have any prerequisites, as they are included with

every client and server edition.

DISM also does not have any prerequisites; it is included with every client and server version

of the operating system. DISM capabilities introduced with Windows Server "8" Beta are

available on down-level versions of Windows 7 by installing the Assessment and Deployment

Kit (ADK). The ADK has its own prerequisites on those computers.

Functional Description

System builders and administrators use DISM to service both online and offline images

throughout the image life cycle. DISM is a command line tool that offers Windows PowerShell

support (new in Windows Server "8" Beta) for the scriptable installation of drivers, Windows

Updates, localization settings (not available in Windows PowerShell cmdlets) and image

edition management.

Componentization terminology

Component Store: Repository of components that contain all previous versions of

files, including the current version, projected to the file system as needed. The

component store is the \Windows\winsxs directory.

Package Store: Repository of package manifests on the system. The package store is

located in \Windows\servicing\packages. New package manifests are added to this

store as updates are installed.

Component: The basic building block for servicing operations. Manifests define

components. They act as a container for such resources as binaries, registry values,

services and security descriptors. Components have unique names comprised of a

standard set of identity attributes.

Manifest: Used to define components or deployments. Manifests can be broken into

the following types:

o Package (or Update): A container for deployments as well as other packages.

The only type of manifest that does not contain the .man extension; instead,

they use .mum. Package manifests do the following:

Act as a container for deployments or other packages

Define feature selectability (can it be turned on/off)

Define package applicability. For example, do other packages need to

be installed first


3

o Component: Serves as the most basic building block that describes a feature. It

defines the resources required for the feature such as binaries, registry values,

services, dependencies, etc.

Component state terminology

Installed: Going from a state of not being on the system, to being on the system

Absent: Going from a state of being on the system, to not being on the system

Staged: Binaries are present on the system but not installed

Rollback: Attempting to reinstate the previous version of the system

Online: Servicing a running operating system

Offline: Servicing an image that has not been booted

Pending: Implies a package applied offline that requires an online state to complete



Features on Demand Features on Demand is a new option in Windows Server "8" Beta that allows administrators

and image builders to reduce the amount of space used by the component store by removing

the payload of the optional component from a system image. Payload refers to the role or

feature associated binaries. Features on Demand also allow for the addition of roles and

features on an as-needed basis once removed from an image and an appropriate restoration

source. Available sources include Windows Server "8" Beta or Windows 8 Consumer Preview

WIM files, network location with Windows installation files and Windows Update.

Features on Demand is exposed via the DISM command line interface, the new DISM and

Server Manager Windows PowerShell cmdlets.

Using DISM DISM is the platform used for most servicing operations in Windows. DISM is a context-based

command line interface. The image target determines available commands. Variations

include the image state (online or offline) and image type (full operating system, core

operating system or Windows PE image). Commands are specific to these variable factors

and must be taken into account when servicing an image. For example, Windows PE

commands are only available when servicing a Windows PE image.

Online targets are running operating systems. Offline targets are images being prepared for

deployment and currently mounted to a folder. Because DISM.exe commands are image state

specific, some commands can only run against a specific image state. An example is the

command: DISM.exe /online /set-edition that allows a Windows image to transition to a

higher edition on server-based operating systems (i.e. Standard to Datacenter). While you

can run this command against both online or offline images, the syntax of the specific

command is dependent on the image state and operating system type (client or server). For

example, an online image requires the /ProductKey switch to set the operating system

edition, whereas for an offline image the command is /Set-ProductKey and must be run after

the /Set-Edition command.

DISM.exe has a multi-level help structure, that is dependent on the operation and the target

image. For example, when you first run DISM.exe help (using DISM /?), it displays the

following output. New commands for Windows Server "8" Beta are shown in bold:

Deployment Image Servicing and Management tool Version: 6.2.8166.0 DISM.exe [dism_options] {Imaging_command} [<Imaging_arguments>] DISM.exe {/Image:<path_to_offline_image> | /Online} [dism_options] {servicing_command} [<servicing_arguments>] DESCRIPTION: DISM enumerates, installs, uninstalls, configures, and updates features


5

and packages in Windows images. The commands that are available depend on the image being serviced and whether the image is offline or running. GENERIC IMAGING COMMANDS: /Get-MountedImageInfo - Displays information about mounted WIM and VHD images. /Get-ImageInfo - Displays information about images in a WIM or VHD file. /Commit-Image - Saves changes to a mounted WIM or VHD image. /Unmount-Image - Unmounts a mounted WIM or VHD image. /Mount-Image - Mounts an image from a WIM or VHD file. /Remount-Image - Recovers an orphaned image mount directory. /Cleanup-Mountpoints - Deletes resources associated with corrupted mounted images. WIM COMMANDS: /List-Image - Displays a list of the files and folders in a specified image. /Delete-Image - Deletes the specified volume image from a WIM file that has multiple volume images. /Split-Image - Splits an existing .wim file into multiple read-only split WIM (SWM) files. /Export-Image - Exports a copy of the specified image to another file. /Append-Image - Adds another image to a WIM file. /Capture-Image - Captures an image of a drive into a new WIM file. Captured directories include all subfolders and data /Apply-Image - Applies an image. /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 corrupted. 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. For more information about these DISM options and their arguments, specify an option immediately before /?. Examples: DISM.exe /Mount-Wim /? DISM.exe /ScratchDir /? DISM.exe /Image:C:\test\offline /? DISM.exe /Online /?

This output details many of the image mounting options and some of the global command

arguments used with DISM servicing command options. DISM help also shows the commands

used to service an online image. To see the online DISM commands, you need to run the DISM

help command (DISM /online /?). This can also be run against an offline image using the

/image argument. The command displays the following output:

Deployment Image Servicing and Management tool Version: 6.2.8166.0 Image Version: 6.2.8166.0 The following commands may be used to service the image: WINDOWS EDITION SERVICING COMMANDS: /Set-ProductKey - Sets the product key of the offline image. /Get-TargetEditions - Displays a list of Windows editions that an image can be upgraded to. /Get-CurrentEdition - Displays the edition of the current image. /Set-Edition - Upgrades an image to a higher edition. DEFAULT ASSOCIATIONS COMMANDS: /Remove-DefaultAppAssociations - Removes the default application associations from a Windows image. /Import-DefaultAppAssociations - Imports a set of default application associations to a Windows image. /Get-DefaultAppAssociations - Displays the list of default application associations from a Windows image. /Export-DefaultAppAssociations - Exports the default application associations from a running operating system. APPX SERVICING COMMANDS: /Remove-ProvisionedAppxPackage - Removes AppX packages from the image. AppX packages will not be installed when new user accounts are created. /Add-ProvisionedAppxPackage - Adds AppX packages to the image and sets them to install for each new user.


7

/Get-ProvisionedAppxPackages - Displays information about AppX packages in an image that are set to install for each new user. 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. For more information about these servicing commands and their arguments, specify a command immediately before /?. Examples: DISM.exe /Image:C:\test\offline /Apply-Unattend /? DISM.exe /Image:C:\test\offline /Get-Features /? DISM.exe /Online /Get-Drivers /?

Each command has further nested help that gives more information on the command and its

usage. Using the set-edition command, we can see that further information on the command

can be found by running the help for that command (DISM /online /set-edition /?):

Deployment Image Servicing and Management tool /Set-Edition:<edition_ID> [/ProductKey:<product_key>] [/AcceptEula | /GetEula:<path>] Use the /Set-Edition option without the /ProductKey option to change an offline Windows image to a higher edition. Use the /Set-Edition option with the /ProductKey option only to change a running Windows Server operating system to a higher edition. Use /Get-TargetEditions to find the edition-IDs. Example: DISM.exe /Image:C:\test\offline /Set-Edition:"Ultimate"

More Information: For more information about this topic, see:

http://technet.microsoft.com/en-us/library/dd744256(WS.10).aspx

From here we can see the specific options for both online/offline and server/client images.

Current likely scenarios for using the DISM tool include:

Adding additional third party drivers to an offline image prior to releasing the image

for deployment

Adding additional Windows Update security patches to an offline image prior to

deployment

http://technet.microsoft.com/en-us/library/dd744256(WS.10).aspx


9

Adding or removing specific roles/features on an online or offline image

Using DISM to remove roles and features from a Windows image

Before removing roles or features from an installation source, administrators must consider

several factors to ensure that the removal of the role or feature does not adversely affect the

environment once it has been widely deployed in the infrastructure. These considerations

include:

What type of installation source will be used to add roles or features back to the image

event as needed?

Is the installation source widely accessible? For example, if utilizing a network location

but images exist on a protected network segment, how are those images going to utilize

Features on Demand to add the role(s) back into the image?

Growth of the component store, and subsequently the image, when adding new roles

and features. Administrators want to keep at least 10GB of space free for potential

component store growth due to Windows Updates, security updates and additional

features being added to the image.

Once they create a deployment roadmap for the new image, administrators can remove the

roles and features from the selected image. One method to remove roles and features is to do

the following:

1. Copy the installation WIM to a local directory (in this example C:\) 2. Create a mount directory to mount the WIM to (in this example C:\image) 3. Find the index of the image you will be editing:

DISM /get-imageinfo /imagefile:c:\install.wim

4. Mount the image to the folder created in step #2: DISM /mount-image /imagefile:c:\install.wim /index:3 /mountdir:c:\image

5. Determine the name of the role or feature to be removed: DISM /image:c:\image /get-features /format:table > features.txt

6. Determine the name(s) of the features to be removed from the installation source and then remove them: DISM /image:c:\image /disable-feature /featurename:DHCPServer /remove

7. Verify the state of the feature is removed: DISM /image:c:\image /get-featureinfo /featurename:DHCPServer

8. Commit the changes to the WIM: DISM /unmount-image /mountdir:c:\image /commit

9. Prepare the image for deployment by adding it to a WDS or MDT deployment point.

Verification of role and feature removal happens post-deployment by attempting to add the

role or feature back into the operating system using Server Manager, DISM.exe or the

Windows PowerShell cmdlets. The removal event appears differently for each utility. In

Server Manager, the removed feature is selectable but the installation of the removed feature

will fail. Feature on Demand does not support adding features back into the image using

Server Manager.



Figure 1: Features on Demand failure in Server Manager

In DISM.exe, checking the feature information shows that the package state is disabled with

Payload Removed. This allows administrators to know that the feature itself is not present

on the computer.

The following is an example of a command used to query feature status:

DISM /online /get-featureinfo /featurename:DHCPServer


11

Figure 2: Feature state in DISM

You can see further confirmation of feature removal by attempting to install the feature

within DISM. It fails with exit code: 0x800f0906. This error does not occur if group policy

objects (GPO) have been enabled in an environment that allow alternative sources such as

Windows Update or alternate source locations. In this case, the feature would be re-enabled.

The command for this is:

DISM /online /enable-feature /featurename:DHCPServer



Figure 3: Attempting to enable a removed feature

When removing a package from an online image that requires a restart to complete the

package removal, the administrator will be presented with a restart now option as seen in the

figure below. Payload removal will not occur until the reboot is completed and the package

state will show as Disable Pending in DISM. When a removal operation pends a reboot, any

subsequent removal events will also prompt the administrator for a reboot until the

condition for the reboot is satisfied.

The command for this is:

DISM /online /disable-feature /featurename:NetFx4 /remove

Figure 4: Removed Feature that requires a reboot to complete

Using DISM Windows PowerShell to remove features from an

operating system

New Windows PowerShell cmdlets are present in Windows 8 Consumer Preview or Windows

Server "8" Beta for DISM commands. The name of the Windows PowerShell module for DISM

is DISM. The following are a listing of the available Windows PowerShell cmdlets included in

Windows 8 Consumer Preview or Windows Server "8" Beta using the command: get-command -module DISM|ft -auto


13

Figure 5: List of DISM cmdlets in Windows PowerShell

Additionally, there are also Windows PowerShell cmdlets available for Windows Server

Manager. These cmdlets were present in Windows 2008 R2 and Windows 7 and can be

loaded using the module name servermanager. This command gives an available listing of

cmdlets for Server Manager includes. The command is:

Get-command -module servermanager|ft -auto

Figure 6: List of Server Manager Windows PowerShell cmdlets

It is important to understand Windows PowerShell usage for the DISM and servermanager

modules. The servermanager module shares functional parity with the Server Manager User

interface. This means you can use servermanager cmdlets to add and remove Windows

Server roles and features. They can also remove the payloads of those roles and features via

Features on Demand.

The DISM cmdlet set offers the ability to also remove role and feature payloads available with

the Features on Demand option. Additionally, the DISM cmdlets offer the ability to

manipulate packages, drivers, edition settings and more. In the following example, we

remove the DHCP Server role using the Features on Demand DISM cmdlets:



1. Mount the Windows Image to modify:

mount-windowsimage -imagepath c:\install.wim -index 3 -path c:\image

2. Get the list of feature names in the image:

get-feature -path c:\image

3. Disable the feature or roles required:

disable-feature -path c:\image -featurename DHCPServer -remove

4. Confirm the removal of the feature payload:

get-feature -path c:\image -featurename DHCPServer.

Once the feature is removed its State will show as DisabledwithPayloadRemoved

5. Unmount the image, saving the changes:

DISMount-windowsimage -path c:\image -save

6. Deploy the image

Using the Server Manager module, you can accomplish the same task as above. In the

following example, we will remove the DHCP Server role from a running Windows Server "8"

Beta:

1. Open an Administrative Windows PowerShell command prompt

2. Remove the DHCP Server role from Windows:

uninstall-windowsfeature DHCP -remove

3. Confirm removal of role. Install State should have a status of Removed:

get-windowsfeature DHCP

4. Close the Windows PowerShell command prompt

Note: To see all roles and features with a specific installation state, use a command such as the following:

Get-windowsfeature | Where-Object {$_.InstallState -eq "Removed"}

This command would display a list formatted with all of the features who have an Install State of Removed on the local Windows computer.

Adding previously removed features back to a computer using

Features on Demand

Available sources to add roles and features back to computers that have had their payloads

removed using the Features on Demand option include:

Installation Media

Network location of install.wim from media


15

Windows Update (if configured)

Administrators may wish to limit the restoration sources for removed features based on

enterprise security concerns or productivity concerns.

To add features back into an image that have been previously removed, administrators will

need to use DISM.exe from an elevated command prompt, the Windows PowerShell cmdlets

for DISM or Server Manager and a path to the Windows Image file (.WIM) that holds the

necessary payload for the feature to be restored. Source paths are not required if GPO's have

been defined for the environment.

To restore features using DISM.exe:

1. Locate the .WIM file that contains the payload for the restore operation. This can be

located on locally attached storage or a network share.

2. Run the command: DISM /online /enable-feature /featurename:telnetclient

/source:wim:c:\install.wim:2 (where the WIM index is the image in the WIM file that

contains the source of the feature payload)

Note: Starting with Windows Vista and Windows 2008, Windows operating systems are packaged in the Windows Image Format (WIM). The WIM format enables the shipment of multiple editions of the operating system from within the same file. Windows uses the product key to determine the edition channel and index in the \sources\install.wim to install.

Determining the images carried within a specific WIM file can be done with DISM. This is done with the following command:

Get-WindowsImage -ImagePath d:\sources\install.wim

The output of the command is below.

Important: To reduce overall operating system disk footprint, the Windows Server "8" Beta Core installation option has many roles and features removed from its component store. Windows Server "8" Beta Core editions can utilize features on demand functionality to install



roles or features that are not present. When adding features to a Windows Server "8" Beta Core system, administrators should ensure they are using the proper index as an installation source as the Windows Server "8" Beta Core indexes do not carry the required payload to reinstall roles or features that are not already present. To install roles and features on a Windows Server "8" Beta Core computer, use the non-Core indexes found in install.wim (such as index 2 and 4 in the image above).

Administrators who wish to disable the use of Windows Update and WSUS servers from

being used as applicable sources for enabling features can use the /LimitAccess switch inside

of DISM. This will prevent the installation from attempting to contact WU/WSUS servers. An

example of this command would be:

DISM /image:c:\image /enable-feature /featurename:telnetclient /limitaccess

This would enable the Telnet Client feature without attempting to contact external Windows

Update servers or internal WSUS servers.

Completely Offline Capable Updates

Another new feature in Windows Server "8" Beta is the ability to install the majority of

packages and updates to an offline image, without the need for that image to bring them

online to complete installation. The name for this class of updates is Completely Offline

Capable.

This is particularly useful in environments that utilize Virtual machine Hard Drives (VHD's)

mounted in DISM and updates and packages applied against them, without the need to boot

the virtual machine to complete the installation of the update.

To test if an update is completely offline capable, you can use the following DISM command:

DISM /image:c:\image /get-packageinfo /packagename:<pkgname>

This returns a status value for a field labeled "Complete Offline Capable.” Return values for

this field shown below, along with a description.

Value Description

No

The update/package cannot complete installation of an offline image and will require the image be brought online in order to complete install. When adding such a package to an offline image, the package will be of Install State “pending” until the image is brought online.*

Yes The update/package completes all of its actions if installed to an offline image. After adding such a package to an offline image, the package Install State is “installed.”

Undetermined

It is not possible to pre-determine whether the package/update is Completely Offline Capable or not. (This is typically due to the complex dependencies that exist between packages that may not already be on the user’s system. Determination can only be made at runtime.)


17

After adding such a package to an offline image, the package will be in Install State “pending” if it requires online processing to complete its actions, or in state “installed” if it was Completely Offline Capable.

In some cases, Administrators may want to apply updates if, and only if, they are Completely

Offline Capable. The offline capabilities of some packages may be listed as “Undetermined”—

and discernible only at runtime—Administrators can utilize the /prevent-pending switch as

part of their installation command.

The /prevent-pending switch ensures that a package is only applied to a mounted image if it

is Completely Offline Capable. If, at runtime, it is determined the package is not Completely

Offline Capable (thereby generating pended actions), Windows cancels package installation

before applying to the system. Syntax for this command is:

DISM /image:c:\image /add-package /package-path:c:\<update> /prevent-pending

Group Policy for Features on Demand

An available Group Policy option allows for the configuration of an installation source for

domain joined clients. The Group Policy is located in the Group Policy Editor in the

Administrative Templates\System node and named "Specify settings for optional component

installation and component repair".

Figure 7: Features on Demand group policy option

Available policy settings include the following:

Alternate source file path: Specifies the network location for use in installation

operations. This must be a fully qualified path and can be either a folder location or



WIM file. You can specify multiple paths by using ";" between the paths. Valid syntax is

wim:<path to wim>:<index>

Never attempt to download payload from Windows Update: Disables the use of

Windows Update as an installation source

Figure 8: GPO settings for Features on Demand

Values for this policy are in the registry under the following key:

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Servicing

Possible registry values include:

• LocalSourcePath – Specifies location to use for installation source. Can specify more than

one source when separated with a “;”. Valid sources include a network folder path or a

WIM file (using the syntax wim:<path to wim>:<index>)

• UseWindowsUpdate – Enables use of Windows Update as an installation source


19

In-box Corruption Repair In-box corruption repair is a new feature that assists in the recovery of servicing corruption

on Windows images. Prior to in-box corruption repair, the CheckSUR utility (KB947821) was

an administrators only option to determine and repair possible corruption on the component

store. CheckSUR did a good job but required an administrator to download and run the MSU

package each time they wished to determine the component store state on a computer.

CheckSUR was updated frequently, which left administrators with outdated versions of the

utility that did not capture the latest known issues in Windows.

In-box corruption repair offers the same functionality as the CheckSUR utility without

requiring the user to download the utility. The DISM command line tool and the DISM

Windows PowerShell cmdlets include In-box corruption repair. In-box corruption repair also

runs automatically in specific cases where the Windows licensing stack or servicing stack has

reported a corruption event.

From an elevated command prompt, administrators or users can expose the new in-box

corruption repair options using the /cleanup-image option within DISM:

Figure 9: DISM cleanup-image help

Available options include the following:

/CheckHealth: scans for corruption flags on the servicing stack. No corrective action is

taken if this returns a positive result. This operation is very quick and returns a status

of one of the following:

o The image store is healthy

o The image store is repairable

o The image store is not repairable

/ScanHealth: scans for known corruption markers in the servicing stack and report

them back to the user. It takes no action based on the scan results. This operation has

a progress indicator during its scan and can take several minutes to complete. It

returns a status of one of the following:






/RestoreHealth: Scans for component store corruption and proactively repairs any

corruption found. It returns a status of one of the following:




/LimitAccess: When used with /RestoreHealth, does not attempt to download repair

files from Windows Update if they could not be found in the local source

DISM Windows PowerShell cmdlets expose this functionality through the Repair-

WindowsImage verb. An example of usage for Windows PowerShell would be:

Repair-WindowsImage -CheckHealth -online

This command would scan the servicing stack for corruption flags and report the status back

to the user.

For corruption repair, the available sources for files include:

Local or network attached Windows Image file known to carry the payload needed for

repair

Windows Update (if configured)

Standard folder layout (such as the \Sources\sxs folder)

When the in-box corruption repair tool has finished running, the results write to the

C:\Windows\Logs\DISM\DISM.log. The DISM.log will only contain entries for the

/ScanHealth and /RestoreHealth commands. An example of a clean entry in the DISM.log:


21

Figure 10: Example of a clean CheckSUR.log

Group Policy for In-box Corruption Repair

An available Group Policy option allows for the configuration of a recovery source for domain

joined clients. The Group Policy is located in the Group Policy Editor in the Administrative

Templates\System node and named "Specify settings for optional component installation and

component repair".

Figure 11: In-box corruption repair group policy options

Available policy settings include the following:

Alternate source file path: Specifies the network location for use in repair operations.

This must be a fully qualified path and can be either a folder location or WIM file.

Specify multiple paths by using ";" between the paths. Valid syntax is wim:<path to

wim>:<index>

Never attempt to download payload from Windows Update: Disables the use of

Windows Update as a repair source



Contact Windows Update directly to download repair content instead of Windows

Server Update Services (WSUS): Bypasses the WSUS servers and directly contacts

Windows Update as a repair source.

Figure 12: In-box corruption repair GPO settings

Values for this policy are in the registry under the following key:

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Servicing

Possible registry values include:

• LocalSourcePath – locations to use for repair sources. Can specify more than one source

when separated with a “;”. Valid sources include a network folder path or a WIM file (using

the syntax wim:<path to wim>:<index>)

• UseWindowsUpdate – Enables use of Windows Update as a repair source

• RepairContentServerSource – if using a WSUS server for Windows Update, this ignores the

WSUS server and uses the Microsoft Windows Update server (for repair source only, does

not affect servicing)


23



Troubleshooting issues with servicing Troubleshooting servicing issues is a very involved process using many different tools and

logs to determine the root cause of the issue. In this section we cover the various steps that

must be taken when working with a potential servicing issue, the logs that need gathering,

what the logs contain, and then how to use the information solve the issue's root cause. Most

servicing cases involve troubleshooting through several key steps:

Verifying component store integrity

Log analysis

Use of in-box tools for recovery

Confirming component store integrity

Confirming that the component store (\Windows\winsxs) is in a valid state is vital to

troubleshooting servicing issues and is always a good first step. Knowing the layout of the

component store along with how hard linked projection of files works enable us to identify

the possible points of failure within the servicing infrastructure.

Possible component store issues can exist in the three main servicing directories:

\Windows\winsxs

\Windows\winsxs\backup

\Windows\system32

To prevent unwanted changes to system files, the TrustedInstaller account owns the majority

of files in the \System32 directory. This account is part of the TrustedInstaller service used

by the component store to make changes against an online Windows system during a

servicing event. Because the Trusted Installer account owns these files, users must take

ownership of the file/directory to make any meaningful changes to an online operating

system. You can change offline systems at will. Microsoft does not recommend making

changes to the file system in this fashion; it can result in system instability.

In the event of unwanted changes to the file system or component store, the first step in

troubleshooting would be to verify that the current files on the file system are valid. To verify

the validity of the component store use the System File Checker (SFC.exe). SFC can be run

online or offline against an operating system. SFC verifies a cryptographically signed hash; if

this hash value does not match the hash in the component store, the file is re-projected.

Unlike in Windows 2003 and prior, Windows 8 Consumer Preview and Windows Server "8"

Beta does not proactively repair - only as a reactive measure. This means that you must run

SFC for actions to take place against the file system. Prior to running SFC, Microsoft Support

recommends verifying component store integrity with DISM.

SFC contains the following options:


25

SFC [/SCANNOW] [/VERIFYONLY] [/SCANFILE=<file>] [/VERIFYFILE=<file>] [/OFFWINDIR=<offline windows directory> /OFFBOOTDIR=<offline boot directory>] /SCANNOW Scans integrity of all protected system files and repairs files with problems when possible. /VERIFYONLY Scans integrity of all protected system files. No repair operation is performed. /SCANFILE Scans integrity of the referenced file, repairs file if problems are identified. Specify full path <file> /VERIFYFILE Verifies the integrity of the file with full path <file>. No repair operation is performed. /OFFBOOTDIR For offline repair specify the location of the offline boot directory /OFFWINDIR For offline repair specify the location of the offline windows directory

Use of the appropriate switch with SFC is important because not all switches result in repair

operation(s). For example, the /verifyonly and /verifyfile switches do not project any files

when run against a system but does display files that are not correct. The only authoritative

command line switches are /scannow and /scanfile. When running these commands against

an online or offline store, any files that do not match the files in the component store are

projected.

One further consideration with SFC is its usage in offline servicing, such as when booted into

WinRE. When booted in WinRE, the component store is not specified. To specify the proper

component store and ensure any changes take effect, use the /OFFBOOTDIR and

/OFFWINDIR switches.

For example, the following command would project the kernel32.dll file if the file in

\System32 were different from that in the component store on D:\Windows\winsxs:

sfc /SCANFILE=d:\windows\system32\kernel32.dll /OFFBOOTDIR=d:\ /OFFWINDIR=d:\windows

Also note, both the /OFFBOOTDIR and /OFFWINDIR switches must be specified when

servicing an offline store.

Log gathering and analysis

Log analysis is a large portion of troubleshooting servicing issues. The logs used during

troubleshooting of servicing logs are the following:

\Windows\Logs\CBS\cbs.log

\Windows\WindowsUpdate.log

\Windows\Logs\DISM\DISM.log



\Windows\servicing\sessions\sessions.xml

\Windows\winsxs\pending.xml

Windows Event Logs

o System log

o Setup log

Each of the aforementioned log files should be collected for every servicing issue. Each log

details different information about the servicing operations on a computer. The following

sections specify what each log details as well as any additional options available for the logs

verbosity.

CBS.log

The CBS.log is the primary log to use when troubleshooting servicing issues. The CBS.log

gives a verbose listing of most of the actions happening with in each servicing session. The

CBS.log will list such events as the applicability checks for the performed operation, the plan

section that results from those checks, and any failures that may occur during the installation

or uninstall of a servicing component. The CBS.log is also useful in determining the

parent/child relationships that are involved in each operation and what the states of those

manifests or packages are.

The CBS.log is quite detailed by default; however, it does offer an extra layer of verbosity that

will show the file and registry operations being performed for each transaction.

To enable verbose CBS logging:

1. NET STOP TRUSTEDINSTALLER

2. Add the following system environment variable: WINDOWS_TRACING_FLAGS with a value

of 10000. *NOTE: This does not require a reboot.

3. NET START TRUSTEDINSTALLER

Anything new logs

WindowsUpdate.log

The WindowsUpdate.log logs all of the information passed by the Windows Update Agent

(WUA). WUA triggers when users attempt to install Windows Updates from within the

Windows Update control panel or if the user has automatic updates enabled. Using the

WindowsUpdate.log in conjunction with a CBS.log can allow you to line up time stamps to get

detailed information about a specific error.

To enable more verbose WindowsUpdate.log logging, do the following:

Add the following new registry entries:

o HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Wi

ndowsUpdate\Trace


27

Add a DWORD value: "Flags" with a HEX value of 16.

Add a DWORD value: "Level" with a HEX value 3

Stop and restart the Windows Update Service using the command: net stop wuauserv

and net start wuauserv

DISM.log

The DISM.log gives detailed information from the perspective of DISM that is manipulating

packages on behalf of the DISM tool. The log creates entries only when the DISM tool itself

manipulates packages. This makes the DISM.log a required troubleshooting log for instances

of attempting to install, remove or manipulate packages outside of the normal servicing

infrastructure (such as Windows Update).

The DISM.log offers four levels of verbosity via the /Loglevel switch in DISM. Logging options

display in the output below:

Deployment Image Servicing and Management tool Version: 6.1.7600.16385 /LogLevel:<n> Specifies the maximum output level shown in logs. The accepted values are: 1 = Errors only 2 = Errors and warnings 3 = Errors, warnings, and information 4 = All the above and debug output If not specified, it defaults to 3 (maximum logging). Example: DISM.exe /Image:C:\test\offline /loglevel:1.

Sessions.xml

The sessions.xml logs each transaction within a specific servicing session. The sessions.xml

exists as several different files. One complete sessions.xml file that lists all of the CBS

sessions activity on a system, and individual sessions files for the independent sessions.

Microsoft Support recommends gathering the complete sessions.xml log for troubleshooting,

because there may be an issue that persists across sessions.

Sessions.xml breaks a CBS session into the independent actions performed against a specific

set of package(s) during a CBS operation. The log is useful to determine the specific actions

that should have taken place against a package. Sessions.xml lists the client who initiated the

session, such as Windows Update Agent, the package identifier(s), and the various actions

taken against those packages (including state changes).



Windows Event Logs

The Windows Event logs can be very useful when troubleshooting servicing issues as they

provide a means to determine a timeline of events corroborated against the CBS.log entries.

Servicing events are logged in the following format:

Log Name: Setup Source: Microsoft-Windows-Servicing Date: 11/18/2009 9:42:22 AM Event ID: 2 Task Category: None Level: Information Keywords: User: SYSTEM Computer: machine.contoso.com Description: Package Telnet Client was successfully changed to the Absent state. Event Xml: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-Servicing" Guid="{BD12F3B8-FC40-4A61-A307-B7A013A069C1}" /> <EventID>2</EventID> <Version>0</Version> <Level>0</Level> <Task>0</Task> <Opcode>0</Opcode> <Keywords>0x8000000000000000</Keywords> <TimeCreated SystemTime="2009-11-18T14:42:22.690851600Z" /> <EventRecordID>58</EventRecordID> <Correlation /> <Execution ProcessID="4564" ThreadID="5880" /> <Channel>Setup</Channel> <Computer>machine.northamerica.corp.microsoft.com</Computer> <Security UserID="S-1-5-18" /> </System> <UserData> <CbsPackageChangeState xmlns="http://manifests.microsoft.com/win/2004/08/windows/setup_provider"> <PackageIdentifier>Telnet Client</PackageIdentifier> <IntendedPackageState>Absent</IntendedPackageState> <ErrorCode>0x0</ErrorCode> <Client>DISM Package Manager Provider</Client> </CbsPackageChangeState> </UserData> </Event>

Pending.xml

Windows creates the pending.xml file when there are POQ (pending operations queue), AIQ

(advanced operation queue) or DOQ (driver operations queue) operations pending

processing on shutdown or reboot. This file contains the list of changes to the system for


29

when that reboot takes place and can be valuable in determining if there are any actions

missing from a specific servicing action.

Note: There are times when a pending operation fails and generates a pending.xml.bad file. If this file exists on a system, collect it with the pending.xml file.

Following is an example of a CBS.log showing the POQ actions taking place:

2008-12-09 13:54:11, Info CBS Shtd: Processing primitive operations queue. // CBS writes the poqexec string to SetupExecute so that if the system loses power unexpectedly before shutdown processing can occur, SMSS will run the POQ under the hood. This only happens if there are no pending driver operations. Since shutdown processing is actually occurring here, the string is taken from SetupExecute and later removed after success 2008-12-09 13:54:11, Info CBS Obtained poqexec from SetupExecute. C:\Windows\winsxs\x86_microsoft-windows-servicingstack_31bf3856ad364e35_6.0.6002.16601_none_0b471220c46f9bfc\poqexec.exe /display_progress \SystemRoot\WinSxS\pending.xml // The POQ is extracted out of the pending.xml 2008-12-09 13:54:11, Info CBS Running poqexec with: C:\Windows\winsxs\x86_microsoft-windows-servicingstack_31bf3856ad364e35_6.0.6002.16601_none_0b471220c46f9bfc\poqexec.exe /noreboot /display_progress \SystemRoot\WinSxS\pending.xml 2008-12-09 13:54:11, Info CBS Shtd: progress thread started 2008-12-09 13:54:32, Info CBS Attempting to remove poqexec from SetupExecute 2008-12-09 13:54:32, Info CBS Removed poqexec from SetupExecute. 2008-12-09 13:54:32, Info CBS Shtd: Primitive operations completed successfully.

In-box tools used for recovery

Other tools that are useful once confirming the store is in good condition and gathering the

logs include:

DISM:

DISM has several useful commands for troubleshooting servicing issues. Notably the

revertpendingactions command and the new in-box corruption commands.

/Revertpendingactions allows for the cancelling of all pending packages on a system. This is

very handy to use in cases where installing a driver or other update prevents normal boot.

By using the revertpendingactions switch via DISM on a system, a cancelling session is

generated and passed to CBS. Once done, no further servicing actions can take place against



the machine and a reboot is required for the cancelling session to run and remove the

pending updates. The /revertpendingactions command is only meant for recovery scenarios

and should only be used for that purpose.

DISM.exe /Image:C:\test\offline /Cleanup-Image /RevertPendingActions DISM.exe /online /Cleanup-Image /RevertPendingActions

With this release, DISM also has the ability to check for component store corruption using the

health commands. These commands are:

DISM.exe /online /Cleanup-Image /CheckHealth DISM.exe /online /Cleanup-Image /ScanHealth DISM.exe /online /Cleanup-Image /RestoreHealth

The CheckHealth flag checks to see if Windows has already detected a corruption marker on

the component store that needs to be resolved based on the last /ScanHealth operation. If

the corruption marker returns a value of healthy then there is not a corruption marker

currently detected. If corruption is suspected and the /CheckHealth parameter is returning a

value of healthy, the /ScanHealth command must be re-run to check for new corruption.

CHKDSK:

Physical hardware issues can cause issues that manifest themselves in the component store

or during a servicing operation. CHKDSK is a well-known command line utility used to fix

disk corruption. CHKDSK can be a useful tool to ensure that the underlying structures of the

disk are not causing corruption in the component store. It is a good idea to run CHKDSK

against a volume whenever other attempts to resolve servicing issues have resulted in no

progress.

MEMTEST:

Similar to CHKDSK, the MEMTEST tool is an in-box command line tool used to check the

validity of physical RAM on a system. Using this tool can be a good check to make sure that

the physical resources on the machine are not causing corruption.

System Restore

System Restore is a well-known recovery tool included with client level operating systems.

System restore reverts changes from a client version of Windows and is invoked online

through the control panel or offline via the Windows Recovery Environment.

understand and troubleshoot servicing in windows server 8 beta

Documents

windows server

windows nt

windows vista

releases of windows

windows core team

beta microsoft corporation

beta engineer

microsoft product