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: Bio: Joseph Conway 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/)
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

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 predeployment 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
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
2012 Microsoft Corporation. All rights reserved.
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
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 /Get-ImageInfo /Commit-Image /Unmount-Image /Mount-Image /Remount-Image /Cleanup-Mountpoints WIM COMMANDS: /List-Image /Delete-Image /Split-Image only /Export-Image /Append-Image /Capture-Image data /Apply-Image /Get-MountedWimInfo /Get-WimInfo /Commit-Wim /Unmount-Wim /Mount-Wim /Remount-Wim /Cleanup-Wim - Displays a list of the files and folders in a specified image. - Deletes the specified volume image from a WIM file that has multiple volume images. - Splits an existing .wim file into multiple readsplit WIM (SWM) files. - Exports a copy of the specified image to another file. - Adds another image to a WIM file. - Captures an image of a drive into a new WIM file. Captured directories include all subfolders and Applies an image. Displays information about mounted WIM images. Displays information about images in a WIM file. Saves changes to a mounted WIM image. Unmounts a mounted WIM image. Mounts an image from a WIM file. Recovers an orphaned WIM mount directory. Deletes resources associated with mounted WIM images that are corrupted. - Displays information about mounted WIM and VHD images. - Displays information about images in a WIM or VHD file. - Saves changes to a mounted WIM or VHD image. - Unmounts a mounted WIM or VHD image. - Mounts an image from a WIM or VHD file. - Recovers an orphaned image mount directory. - Deletes resources associated with corrupted mounted images.
IMAGE SPECIFICATIONS: /Online /Image - Targets the running operating system. - Specifies the path to the root directory of an offline Windows image.
DISM OPTIONS: /English /Format /WinDir /SysDriveDir /LogPath /LogLevel Displays command line output in English. Specifies the report output format. Specifies the path to the Windows directory. Specifies the path to the system-loader file named BootMgr. - Specifies the logfile path. - Specifies the output level shown in the log (1-4).
/NoRestart /Quiet /ScratchDir
- Suppresses automatic reboots and reboot prompts. - Suppresses all output except for error messages. - 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 DISM.exe DISM.exe DISM.exe
/Mount-Wim /? /ScratchDir /? /Image:C:\test\offline /? /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 /Get-TargetEditions /Get-CurrentEdition /Set-Edition - Sets the product key of the offline image. - Displays a list of Windows editions that an image can be upgraded to. - Displays the edition of the current image. - 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.
/Get-ProvisionedAppxPackages - Displays information about AppX packages in an image that are set to install for each new user. UNATTEND SERVICING COMMANDS: /Apply-Unattend DRIVER SERVICING COMMANDS: /Remove-Driver /Add-Driver /Get-DriverInfo /Get-Drivers - Removes driver packages from an offline image. - Adds driver packages to an offline image. - Displays information about a specific driver in an offline image or a running operating system. - Displays information about all drivers in an offline image or a running operating system. - Applies an unattend file to an image.
INTERNATIONAL SERVICING COMMANDS: /Set-LayeredDriver /Set-UILang /Set-UILangFallback /Set-UserLocale /Set-SysLocale - Sets keyboard layered driver. - Sets the default system UI language that is used in the mounted offline image. - Sets the fallback default language for the system UI in the mounted offline image. - Sets the user locale in the mounted offline image. - Sets the language for non-Unicode programs (also called system locale) and font settings in the mounted offline image. - Sets the input locales and keyboard layouts to use in the mounted offline image. - Sets the default time zone in the mounted offline image. - Sets all international settings in the mounted offline image. - Sets all international settings to the default values for the specified SKU language in the mounted offline image. - Generates a new lang.ini file. - Defines the default language that will be used by setup. - Displays information about the international settings and languages.
/Set-InputLocale /Set-TimeZone /Set-AllIntl /Set-SKUIntlDefaults
/Gen-LangIni /Set-SetupUILang /Get-Intl
APPLICATION SERVICING COMMANDS: /Check-AppPatch /Get-AppPatchInfo /Get-AppPatches /Get-AppInfo /Get-Apps - Displays information if the MSP patches are applicable to the mounted image. - Displays information about installed MSP patches. - Displays information about all applied MSP patches for all installed applications. - Displays information about a specific installed MSI application. - Displays information about all installed MSI applications.
PACKAGE SERVICING COMMANDS: /Add-Package /Remove-Package /Enable-Feature /Disable-Feature /Get-Packages /Get-PackageInfo /Get-Features /Get-FeatureInfo /Cleanup-Image Adds packages to the image. Removes packages from the image. Enables a specific feature in the image. Disables a specific feature in the image. Displays information about all packages in the image. Displays information about a specific package. Displays information about all features in a package. Displays information about a specific feature. 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>] /GetEula:<path>] [/AcceptEula |
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" For more information about this topic, see: http://technet.microsoft.com/en-us/library/dd744256(WS.10).aspx
More Information:
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
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: 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 DISM /image:c:\image /get-features /format:table > features.txt
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
10
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
11
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
12
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:
13
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

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.
Note:
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
14
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)
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.
Note:
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
15
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 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.* 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. 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 users system. Determination can only be made at runtime.)
No
Yes
Undetermined
16
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 runtimeAdministrators 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
17
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
18
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 o o The image store is healthy The image store is repairable 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: o The image store is healthy
19
o o
The image store is repairable The image store is not repairable
/RestoreHealth: Scans for component store corruption and proactively repairs any corruption found. It returns a status of one of the following: o o o The image store is healthy The image store is repairable The image store is not repairable
/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 RepairWindowsImage 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:
20
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
21
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)
22 2012 Microsoft Corporation. All rights reserved.
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:
24
SFC [/SCANNOW] [/VERIFYONLY] [/SCANFILE=<file>] [/VERIFYFILE=<file>] [/OFFWINDIR=<offline windows directory> /OFFBOOTDIR=<offline boot directory>] /SCANNOW with /VERIFYONLY operation is /SCANFILE problems are /VERIFYFILE repair /OFFBOOTDIR directory /OFFWINDIR directory Scans integrity of all protected system files and repairs files problems when possible. Scans integrity of all protected system files. No repair performed. Scans integrity of the referenced file, repairs file if identified. Specify full path <file> Verifies the integrity of the file with full path <file>. operation is performed. For offline repair specify the location of the offline boot For offline repair specify the location of the offline windows
No
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
25
\Windows\servicing\sessions\sessions.xml \Windows\winsxs\pending.xml Windows Event Logs o o System log 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
26
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).
27
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-4A61A307-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
28
when that reboot takes place and can be valuable in determining if there are any actions missing from a specific servicing action.
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.
Note:
Following is an example of a CBS.log showing the POQ actions taking place:

2008-12-09 13:54:11, Info operations queue. CBS Shtd: Processing primitive
// 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-windowsservicingstack_31bf3856ad364e35_6.0.6002.16601_none_0b471220c46f9bfc\poqexec.ex e /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-windowsservicingstack_31bf3856ad364e35_6.0.6002.16601_none_0b471220c46f9bfc\poqexec.ex e /noreboot /display_progress \SystemRoot\WinSxS\pending.xml 2008-12-09 13:54:11, Info 2008-12-09 13:54:32, Info from SetupExecute 2008-12-09 13:54:32, Info SetupExecute. 2008-12-09 13:54:32, Info completed successfully. CBS CBS CBS CBS Shtd: progress thread started Attempting to remove poqexec Removed poqexec from Shtd: Primitive operations
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
29
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.
30

Understand and Troubleshoot Servicing in Windows Server 8 Beta

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Understand and Troubleshoot Servicing in Windows Server 8 Beta

Uploaded by

Copyright:

Available Formats

Understand and Troubleshoot Servicing in Windows Server "8" Beta

Microsoft Corporation Published: February 2012

All other trademarks are property of their respective owners.

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