Understand and Troubleshoot Servicing in Windows Server 8 Beta
-
Upload
sekretusername -
Category
Documents
-
view
253 -
download
2
description
Transcript of 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/)
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
Understand and Troubleshoot Servicing in Windows Server "8" Beta
1
Understand and Troubleshoot Servicing in Windows Server "8" Beta
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
Understand and Troubleshoot Servicing in Windows Server "8" Beta
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
Understand and Troubleshoot Servicing in Windows Server "8" Beta
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
Understand and Troubleshoot Servicing in Windows Server "8" Beta
4 © 2012 Microsoft Corporation. All rights reserved.
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
Understand and Troubleshoot Servicing in Windows Server "8" Beta
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).
Understand and Troubleshoot Servicing in Windows Server "8" Beta
6 © 2012 Microsoft Corporation. All rights reserved.
/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.
Understand and Troubleshoot Servicing in Windows Server "8" Beta
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.
Understand and Troubleshoot Servicing in Windows Server "8" Beta
8 © 2012 Microsoft Corporation. All rights reserved.
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
Understand and Troubleshoot Servicing in Windows Server "8" Beta
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.
Understand and Troubleshoot Servicing in Windows Server "8" Beta
10 © 2012 Microsoft Corporation. All rights reserved.
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
Understand and Troubleshoot Servicing in Windows Server "8" Beta
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
Understand and Troubleshoot Servicing in Windows Server "8" Beta
12 © 2012 Microsoft Corporation. All rights reserved.
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
Understand and Troubleshoot Servicing in Windows Server "8" Beta
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:
Understand and Troubleshoot Servicing in Windows Server "8" Beta
14 © 2012 Microsoft Corporation. All rights reserved.
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
Understand and Troubleshoot Servicing in Windows Server "8" Beta
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
Understand and Troubleshoot Servicing in Windows Server "8" Beta
16 © 2012 Microsoft Corporation. All rights reserved.
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.)
Understand and Troubleshoot Servicing in Windows Server "8" Beta
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
Understand and Troubleshoot Servicing in Windows Server "8" Beta
18 © 2012 Microsoft Corporation. All rights reserved.
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
Understand and Troubleshoot Servicing in Windows Server "8" Beta
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:
o The image store is healthy
Understand and Troubleshoot Servicing in Windows Server "8" Beta
20 © 2012 Microsoft Corporation. All rights reserved.
o The image store is repairable
o 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 The image store is healthy
o The image store is repairable
o 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 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:
Understand and Troubleshoot Servicing in Windows Server "8" Beta
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
Understand and Troubleshoot Servicing in Windows Server "8" Beta
22 © 2012 Microsoft Corporation. All rights reserved.
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)
Understand and Troubleshoot Servicing in Windows Server "8" Beta
23
Understand and Troubleshoot Servicing in Windows Server "8" Beta
24 © 2012 Microsoft Corporation. All rights reserved.
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:
Understand and Troubleshoot Servicing in Windows Server "8" Beta
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
Understand and Troubleshoot Servicing in Windows Server "8" Beta
26 © 2012 Microsoft Corporation. All rights reserved.
\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
Understand and Troubleshoot Servicing in Windows Server "8" Beta
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).
Understand and Troubleshoot Servicing in Windows Server "8" Beta
28 © 2012 Microsoft Corporation. All rights reserved.
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
Understand and Troubleshoot Servicing in Windows Server "8" Beta
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
Understand and Troubleshoot Servicing in Windows Server "8" Beta
30 © 2012 Microsoft Corporation. All rights reserved.
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.