Windows Server 2008 and Vista Cookbook

MICROSOFT
Windows Vista® and

Windows Server® 2008
Application Compatibility Cookbook
Microsoft Windows
Application Experience Group
Version 6.6
Microsoft / Windows Application Experience
Legal Preamble
THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.
Information in this document is subject to change without notice. The example companies,
organizations, products, people, and events depicted herein are fictitious. No association with any real
company, organization, product, person or event is intended or should be inferred. Complying with all
applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no
part of this document may be reproduced, stored in or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarked, copyrights, or other intellectual property
rights covering subject matter in this document. Except as expressly provided in any written license
agreement from Microsoft, the furnishing of this document does not give you any license to these
patents, trademarks, copyrights, or other intellectual property.
© 2007 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, MS, Windows, Windows NT, MSDN, Active Directory, BizTalk, SQL Server,
SharePoint, Outlook, PowerPoint, FrontPage, Visual Basic, Visual C++, Visual J++, Visual InterDev, Visual
SourceSafe, Visual C#, Visual J#, and Visual Studio are either registered trademarks or trademarks of
Microsoft Corporation in the U.S.A. and/or other countries.
Other product and company names herein may be the trademarks of their respective owners.
Application Compatibility Group| Page 2

"WindowsServer2008andVistaCookbook.doc" last modified on 29 Oct. 07, Rev 1
Table of Contents
Introduction .................................................................................................................................................. 6
Quick Compatibility Check ............................................................................................................................ 7
Operating System Versioning........................................................................................................................ 8
User Account Control .................................................................................................................................... 9
UAC – Application Update Guidelines ........................................................................................................ 11
UAC – COM Per-User Configuration ........................................................................................................... 14
Windows Resource Protection (WRP) ........................................................................................................ 14
Internet Explorer Protected Mode ............................................................................................................. 17
Windows 64-bit ........................................................................................................................................... 19
IIS 7 .............................................................................................................................................................. 20
Microsoft Graphical Identification and Authentication (GINA) .................................................................. 23
Session 0 Isolation....................................................................................................................................... 24
Networking: TCP/IP Stack and the Windows Filtering Platform ................................................................. 26
Networking: Kernel Mode IP Helper APIs ................................................................................................... 27
Networking: IPv6......................................................................................................................................... 28
Compatibility Risks ...................................................................................................................................... 30
Windows Display Driver Model................................................................................................................... 31
Default Programs ........................................................................................................................................ 33
Program Compatibility Assistant (PCA) ....................................................................................................... 36
Graphical Device Interface - GDI ................................................................................................................. 47
User Interface Privilege Isolation (UIPI) ...................................................................................................... 49
High DPI Scaling........................................................................................................................................... 51
PNG Icons .................................................................................................................................................... 52
Named Pipe Hardening ............................................................................................................................... 52
SPAP Deprecation (Pstore).......................................................................................................................... 53
WMI Providers: Default Security Hosting Model ........................................................................................ 54

Volume Shadow Copy Service..................................................................................................................... 54

Standard User Analyzer............................................................................................................................... 57
DHTML Editing Control ............................................................................................................................... 59
Help Engine Support ................................................................................................................................... 59
Junction Points and Backup Applications ................................................................................................... 61
Application Compatibility for Backup and Recovery.................................................................................. 65
Integrating with the Search the Internet Feature....................................................................................... 66
MMCs Must Be Data Execution Protection (DEP) Aware ........................................................................... 68
Networking: Turning off the Windows Firewall .......................................................................................... 68
Issues Relevant to Windows Server 2008.................................................................................................... 71
Read Only Domain Controllers (RODC) ....................................................................................................... 71
Windows Server 2008 Roles ....................................................................................................................... 73
Windows Application Experience in Windows Server 2008 ....................................................................... 74
Windows Server 2008 Server Core ............................................................................................................. 74
Windows Server Failover Clustering on Windows Server 2008.................................................................. 76
Networking: Windows Firewall Enabled by Default on Windows Server 2008 .......................................... 77
Table of Figures
Figure 1: IE Protected Mode Compatibility Architecture ........................................................................... 18
Figure 2: Example of a PCA Error Message ................................................................................................. 36
Figure 3: PCA UI after Installer Termination. .............................................................................................. 37
Figure 4: PCA dialog box for program trying to launch a child.exe............................................................. 39
Figure 5: Detecting installers that need to run as Administrator ............................................................... 40
Figure 6: Legacy Control Panel item that needs to run as Administrator................................................... 41
Figure 7: Dialog displayed when PCA detects a deprecated Windows component ................................... 42
Figure 8: PCA dialog when unsigned driver detected ................................................................................. 44
Figure 9:Hard block apphelp message - displayed when incompatibility would have severe impact ....... 45
Figure 10: Soft block dialog displayed when incompatibility issues would not cause severe impact ........ 45

Figure 11: Values of the Scenario ID ........................................................................................................... 47

Figure 12: Standard User Analyzer Tab Details ........................................................................................... 58
Figure 13: Parent Folder Junction Requirements ....................................................................................... 61
Figure 14: User Data Legacy Folder Junction Requirements ...................................................................... 62
Figure 15: Per User Application Data Legacy Folder Junction Requirements............................................. 62
Figure 16: Per User OS Settings Legacy Folder Junction Requirements ..................................................... 62
Figure 17: Legacy Profile Folders where Junctions Are Not Required ........................................................ 63
Figure 18: All Users Legacy Folder Junction Requirements ........................................................................ 63
Figure 19: User Junction Points .................................................................................................................. 63
Figure 20: Default Users Legacy Folder Junction requirements ................................................................. 64
Figure 21: Program Files Junction Points .................................................................................................... 64
Figure 22: Start Menu Search Box .............................................................................................................. 66
Figure 23: Windows Live Search ................................................................................................................. 67

Introduction
Windows Vista and Windows Server 2008 introduce the next generation operating system technology
and software development platform that will be used by application developers and enterprises
worldwide. As part of enhancing the security and user experience of Windows Vista and Windows
Server 2008, many new features have been introduced and existing features have been improved.
While Windows Vista and Windows Server 2008 are highly compatible with most of the applications
written for Microsoft Windows XP, Microsoft Windows Server 2003, and their service packs, some
amount of compatibility breaks are inevitable due to new innovations, security tightening, and increased
reliability. Overall, Windows Vista and Windows Server 2008 compatibility is high, and Microsoft is
continuously striving to achieve the best possible compatibility solutions for existing applications for
Windows Vista and Windows Server 2008.
This document is the first step for application developers to become familiar with how to verify the
compatibility of their applications. This document also provides an overview of the few known
application incompatibility issues in Windows Vista and Windows Server 2008 and provides links to
detailed white papers and other developer guidance.
There are several new features that will enable developers to troubleshoot and workaround applications
that do not function properly under Windows Vista and Windows Server 2008. Two such features are
particularly useful:
 The Windows XP SP2 compatibility mode allows an application to work as it did on Windows XP SP2.
To run an application in this mode, right-click the application’s EXE or icon and open the Properties
property sheet. Click the Compatibility tab and select Run this program in compatibility mode for
Windows XP (Service Pack 2).
 Security restrictions enforced by the User Account Control (UAC) might prevent applications that
require administrative privileges from running properly, even if the user is a member of the
administrators group. To override the UAC, a user with administrative privileges can run an application
with elevated privileges by right-clicking the applications EXE or icon and clicking Run as
administrator on the popup menu. The system displays a UAC dialog box, and the user can then click
Allow to run the application with appropriate privileges.
NOTE: All items in this document are appropriate for both Windows Vista and Windows Server 2008
unless otherwise noted. There are no architectural changes for Windows Vista SP1. Applications that
are compatible with Windows Vista RTM should continue to be compatible with Windows Vista SP1.

Quick Compatibility Check

This section provides guidance on how to test and evaluate the compatibility of an application on
Windows Vista or Windows Server 2008. There are two primary scenarios to test for compatibility on
Windows Vista and Windows Server 2008, as follows.
Working with a clean installation of Windows Vista

1. Install Windows Vista or Windows Server 2008 on a test machine.
2. Install the application on the test machine. If a prompt is displayed requesting permission to
install the application, click Permit and continue. If installation succeeds, go to step 6.
3. If the application installation failed and no installation permission prompt was displayed, then
right-click the installer EXE and choose Run this program as administrator and re-install the
application. If the install succeeds, go to step 6.
Note: This step is not necessary if an MSI is used to install.
4. If you receive any errors, such as OS version, CLSID registration, or file copy, then right-click the
installer EXE file, choose the Compatibility tab, and choose the Windows XP SP2 compatibility
mode.
5. Go back to step 2. If you cannot install the application, go to step 9.
6. The application should now be installed.
7. Launch the application. If the application did not launch properly or if errors are displayed, apply
the Windows XP SP2 compatibility mode to the application EXE and try again.
8. If the application launches successfully, run through the full suite of tests that would typically be
used to test the application on Windows XP. Verify your application functionality and confirm
that the application performs properly. If all major functionality tests pass, go to step 10.
9. If the application does not install, launch successfully, crashes, encounters an error, or fails
major functionality tests, it may be one of the small set of applications that are impacted by
Windows Vista changes. Use the topics in this document to check your application.
10. You have completed the scenario.
Working with an upgrade to Windows Vista from Windows XP Service Pack 2

1. Install Windows XP SP2 on a test machine and then install the application. Verify all the
functionality of the application before proceeding.
2. Upgrade the test machine to Windows Vista. Follow the Windows Vista setup and upgrade
instructions. Once the upgrade is complete, log on as you would on Windows XP.
3. Launch the application. If the application did not launch properly or if errors are displayed, apply
the Windows XP SP2 compatibility mode to the application EXE and try again.
4. If the application launches successfully, run through the full suite of tests that would typically be
used to test the application on Windows XP. Verify your application functionality and confirm
that the application performs properly. If all major functionality tests pass, go to step 6.

5. If the application does not install, launch successfully, crashes, encounters an error, or fails
major functionality tests, it may be one of the small set of applications that are impacted by
Windows Vista and Windows Server 2008 changes. Use the topics in this document to check
your application.
6. You have completed the scenario.
If both scenarios have been completed and the application has performed properly, then the application
functions properly under Windows Vista and Windows Server 2008. For information about obtaining
certification for your application, see the Windows Vista Home Page.
Links to Other Resources

Windows Vista Home Page
Windows Vista Readiness Virtual Lab
Application compatibility tools
Windows Server 2008 Home Page
Windows Server 2008 Readiness Virtual Lab
Operating System Versioning

Feature Impact
High
Brief Description
The internal version number for Windows Vista and Windows Server 2008 is 6. The GetVersion function
will now return this version number to applications when queried.
Note: This is the next major version number from Windows XP (version 5.x).
Manifestation
The manifestation of this version change is very application-specific, as follows:
 Any application that specifically checks for the OS version will get a higher version number.
 Application installers may prevent themselves from installing the application and applications
may prevent themselves from starting.
 Applications may warn users and continue to function properly.
 Some applications may become unstable or crash.
Mitigation
Most applications will function properly on Windows Vista and Windows Server 2008 because the
application compatibility in Windows Vista and Windows Server 2008 is very high. However, for

applications and installers that check for OS version, a Compatibility mode is provided in Windows Vista
and Windows Server 2008.
Users can right-click the shortcut or the EXE and apply the Windows XP SP2 compatibility mode from the
Compatibility tab. In most cases, this should enable the application to work as it did on Windows XP
without a need for any changes to the application.
Remedies
 Generally, applications should not perform OS version checks or, at minimum, always accept
version 6 or later for the OS. This behavior should be followed unless there is a very specific
legal, business, or system-component need to do this version check.
 Ensure that any drivers an application uses are user mode drivers as much as possible to
maintain multiplatform (32-bit and 64-bit) compatibility.
User Account Control

Standard User Changes
Feature Impact
High
Brief Description
A fundamental step toward increasing the security of Windows is enabling interactive users to run with
a standard user account, which gives them access to only a limited set of permissions and privileges. By
default, Windows Vista and Windows Server 2008 will run every application as a standard user even if
you log on as a member of the administrator's group. Conversely, when users attempt to launch an
application that has been marked as requiring administrator permissions, the system will explicitly ask
them to confirm their intention to do so. Only applications running with administrator privileges can
modify system and global settings and behavior. This feature of Windows Vista and Windows Server
2008 is the User Account Control (UAC).
Manifestation
 Custom installers, uninstallers, and updaters may not be detected and elevated to run as
administrator.
 Standard user applications that require administrative privileges to perform their tasks may fail
or may not make this task available to standard users.
 Applications that attempt to perform tasks for which the current user does not have the
necessary permissions, may fail. How the failure manifests itself is dependent upon how the
application was written.

 Control panel applications that perform administrative tasks and make global changes may not
function properly and may fail.
 DLL applications that run using RunDLL32.EXE may not function properly if they perform global
operations.
 Standard user applications writing to global locations will be redirected to per-user locations
through virtualization.
Remedies
Quick solution for custom installers
 A user can launch the installer or updater by right-clicking and selecting Run this program as
administrator.
 Apply an application compatibility fix to indicate that specific installers require elevation. To do
so, right-click the shortcut or the EXE and apply the Windows XP SP2 compatibility mode from
the Compatibility tab.
Quick solution for applications that require administrative privileges to perform system
modifications or write to privileged areas
 Corporate users will be able to apply an application compatibility fix to indicate that the legacy
application requires administrator permissions or privileges to run correctly.
 Reducing the restrictions of access control lists (ACLs) on certain restricted files may help
applications that attempt to write to these files.
 Check the virtualized folders or registry keys to see if applications are accessing something that
requires administrator privileges. This information can be used to remove the requirements of
accessing administrator-protected locations from future versions of the application. For more
information about virtualized files, folders, and locations, see Shell: Themes and My Documents
Locations on page 32.
 Wrap a "Run DLL as an app" DLL call in a separate EXE and include a manifest for this EXE to
require elevated privileges.
Compatibility test
 Any install, uninstall, or update scenario should prompt the user for consent or credentials.
Upon receiving user approval, the action should succeed.
 Attempt to reproduce the failing scenario as the built-in-administrator. If this scenario passes,
the failure is probably due to a lack of privileges.
 Use the User Account Control predictor tool of the Application Compatibility Toolkit's
Compatibility Administrator to identify those areas of an application that are performing
administrator operations.
Leverage Windows Vista and Windows Server 2008 capability solution

 Windows Vista and Windows Server 2008 based applications need to:

 Follow the prescribed guidelines found in the Windows Vista and Windows Server 2008 LOGO
programs and user experience (UX) guidelines documentation (see the "Links" section).
 Use embedded manifests to indicate their specific requestedExecutionLevel (formerly known as
RunLevel).
 Separate all administrative and non-administrative functions into separate EXEs. All functions
that need higher privileges should be in a separate executable EXE with manifested execution
level or a COM object running with administrative privileges. Launch the administrative tasks
only when required. This holds true for all applications.
 For applications that are not specifically administrative in nature, modify code to eliminate need
for administrator permissions or privileges.
 For applications that are only used by administrators, mark the application so it will run with
administrator permissions or privileges.
 When updating an application, use a separate updater EXE to update the target application.
 Control panel applications must move away from .cpl files to .exe files, and include a manifest
for their EXE-based control panel applications that specifies the execution level required.
 DLLs running under RunDLL32.EXE that need elevation should be modified into an executable
EXE with its elevation level indicated in its manifest.
 Always open files and registry keys with read-only access when possible. Use read-write access
only when needed and revert the permissions back to read-only once the operation is complete.

Windows Vista UAC main page
Getting Started with User Account Control
Developer Best Practices and Guidelines for Applications in a Least Privileged Environment
UACBlog
UAC-related question on Microsoft Forums
Aaron Margosis' WebLog; search for "Not running as administrator"
UAC – Application Update Guidelines

Feature Impact
Medium
Brief Description
Many existing applications have a tendency to incorporate update functionality in their application. The
goal of embedding update functionality is to ensure that the client is running the most up to date binary
that the ISV can offer.

Some applications require more privileges than that of a Standard user when they perform their
updating functions. Often times, the per-machine files that were laid down during installation need to
be serviced. As per the UAC model for running and installation applications, only the elevated
administrator in Admin Approval Mode Admin has sufficient privileges to perform these actions.
Windows Vista and Windows Server 2008 includes built-in Installer Detection heuristics to detect many
application updaters correctly and elevate the updater process appropriately so that the update
completes successfully on elevation. However a few areas remain where application updates cannot be
completed successfully as follows:
 Out of Process Updaters not Install Detected - Updaters that do not get detected through install
detection heuristics
 Multi-purposed executables/In-process updates - Overloaded executables that perform more
than one operation. e.g. The binary is both the main application and the updating application
OR the multi-purposed executable runs as a thread within the application
Manifestation
 Application update functionality fails
Remedies
Out of Process updaters not Install Detected
This is an issue that could occur within any enterprise and could result in that enterprise requiring an
application to be run with Administrator privileges. If an application updates itself by using a separate
process that is not installer detected then this separate process should be marked as requiring
Administrator privileges using App Fix.
Updaters that do not work as a user will prohibit an enterprise from running with least privilege.
 The updater should be written as a separate process with a desired run level of Requires
Administrator.
 This process should only execute when necessary for updating purposes.
 Checking for whether the program needs updates should be done as the user.
Multi-purpose executables/In-process updates

On Windows Vista and Windows Server 2008, there isn’t a good way to create a multi-purpose
executable that performs updates because it is not possible to toggle the state under which an
executable is run. Consequently, the executable will always have to run as Administrator. Instead,
applications should follow one of the following methods to perform updates:
1. Utilizing Patching technology in MSI (Latest versions of Windows Installer, Installshield, Wise for
Windows Installer etc. support this)
a. MSI is a key installer technology because it provides the ability to manage updates for
you.

i. Use MSI to create your initial installer and embed a certificate in the
MsiPatchCertificate table.
ii. Create an update for your application and sign it with the previously specified
certificate.
iii. MSI will perform the elevation for the application when applying the patch.
iv. The main advantage of this method over others is that it works with Standard
User, and keeps the system secure. It provides a better user experience
because the Standard User account doesn't have to ask an Administrator to
install the patch or request permanent Administrator privileges to run the
application.
2. Using other custom installer mechanisms

a. This is discouraged for the enterprise environment because this will prohibit the user
from running as non-Administrators
b. The updater should be written as a separate process with a desired run level of
requiresAdministrator.
i. This process should only execute when necessary for updating purposes.
Checking for whether the program needs updates should be done as the user.
3. Updating while running as a “Standard User” application
a. Updating can occur as a Standard User when using ClickOnce technology. Again, this is
an install platform that allows the user to deploy applications within it and handles the
updating for the app writer.

Patching and Updates
Deploy and Update Your Smart Client Projects Using a Central Server
The following videos on Windows Vista User Account Protection are designed to help developers
understand and write code:
Part 1: Watch Video
Part 2: Watch Video
Part 3: Watch Video
Part 4: Watch Video
Part 5: Watch Video
User Account Control Application Compatibility Toolkit: Watch Video
User Account Control Demo: Watch Video

UAC – COM Per-User Configuration

Feature Impact
Medium
Brief Description
The Component Object Model (COM) leverages the registry to maintain information about all of the
COM objects installed on a computer. This registry hive (HKEY_CLASSES_ROOT) is a virtual registry hive,
which allows for both per-user and per-machine object registration. Per-user COM objects
configurations are stored in HKEY_CURRENT_USER\Software\Classes, while per-machine configurations
are stored in HKEY_LOCAL_MACHINE\Software\Classes. Typically, COM per-user configurations take
precedence.
Beginning with Windows Vista and Windows Server 2008, if the Integrity Level of a process is higher
than Medium, the COM runtime ignores per-user COM configuration, and only accesses per-machine
COM configuration. This reduces the surface area for elevation of privilege attacks, preventing a process
with standard user privileges from configuring a COM object with arbitrary code and having this code
called from an elevated process.
Manifestation
Applications that are run elevated (whether manifested as requireAdministrator or user-selected by
right click  Run as Administrator), as well as applications run from an account that is a member of the
Administrators group where UAC is disabled, will not be able to access any COM objects configured per-
user.
Remedies
Applications that will require administrator rights should register any dependent COM objects during
installation to the per-machine COM configuration store (HKEY_LOCAL_MACHINE\Software\Classes).

HKEY_CLASSES_ROOT Key
COM Classes and Servers
Windows Resource Protection (WRP)

Feature Impact
High (may block the application from installing or running)

Brief Description
As an initiative to increase system stability, predictability and reliability, Windows Resource Protection
(WRP) protects Windows read-only resources specifically OS files, folders, and registry keys that are non-
configurable by design. See the Protected Resource List for a full accounting of protected resources.
WRP enforces this protection using Windows Security by specifying special security descriptors on the
resource. Any process including those running as administrator or system do not have rights to make
changes to WRP resources, they can read and execute. Full access to WRP resources is restricted to
Windows Modules Installer service.
As a result, read-only system state is protected from the inadvertent impact of application installs and
administrator modifications. This improves system stability.
Manifestation
Applications will not succeed in replacing or modifying protected OS resources, (typically this happens
during application install and uninstall) with the following results:
 Attempts to replace, modify, or delete OS files and/or registry keys that are protected by WRP
may fail with an error message indicating that the resource could not be updated. This is
because access to these resources is denied.
 Attempts to write new registry keys or values to protected registry keys may fail with an error
message that indicates that the change failed because access was denied.
 Attempts to write to protected resources may fail if they rely on the application succeeding in
writing to protected registry keys or values.
Because applications are prevented from making changes to WRP resources and related errors are
suppressed, this may result in runtime errors.
Mitigations
Important Note: The following mitigation will not be applied if the application has a
manifest that specifies a requestedExecutionLevel as required by UAC.
For well-known installers, Access Denied errors resulting from attempts to create/modify/delete WRP
resources will be suppressed, and no changes are applied to the WRP resource.
Remedies
 Do not install or update system state (files and registry) on Windows Vista and Windows Server
2008 except when using Microsoft provided redistributable packages designed for Windows
Vista and Windows Server 2008.
 Do not install individual components of a whole Microsoft-provided redistributable designed for
 Use the SfcIsFileProtected API to detect WRP-protected files. If a file is WRP, then the
application installer should not install or modify the file.

 For registry keys protected by WRP, applications should gracefully handle "Access Denied"
messages that are due to WRP.
 Test and verify that legacy applications that rely on WRP mitigation are working properly by
installing the application.
 Use SfcIsKeyProtected API to detect WRP-protected key. If a key is WRP, then the
application installer should not install or modify the key.
WRP Protected Keys

You can expect that if an application attempts to create/modify/delete a WRP key that application will
get an "Access Denied" error. When you encounter an "Access Denied" error, verify that the access
denied error is a result of a WRP Security Descriptor on the key (or a parent key) and not because the
user does not have enough permissions to write to the key.
The decision on how to handle an “Access Denied” error message caused by WRP will
depend on the impact of this failure for the application:
1. If the application is trying to write a key or value that already exists, then the application can
ignore the error message.
2. If the key or value does not exist then as the developer you must decide the impact on your
application. Is this key required for your application to run successfully on Windows Vista? If
not, you can ignore the error. If this key is required, you will need to redesign your application to
write to an alternate key or use some alternate design.
How to recognize whether a resource is WRP

For the Registry:
1. Through code use the SfcIsKeyProtected API.
2. Or use Regedit to check permissions on the key.
o Click Start, and then click Run.
o Type Regedit, and then click OK
o Search for the key. Right-click the registry key. Click Permissions.
o Files that are WRP will show Trusted Installer with Full Control. SYSTEM, Administrators
and Users will only have Read permissions.
For files:
1. Through code, use SfcIsFileProtected API.
2. Or use Explorer to check permissions on the file.
o Open the folder that contains the file whose properties you want to see.
o Right-click the file whose properties you want to see, and then click Properties.
o Keys that are WRP will show Trusted Installer with Full Control. SYSTEM, Administrators,
and Users will only have Read permissions.


Windows Vista Management Features
Functions/APIs
http://msdn2.microsoft.com/en-gb/library/aa382545.aspx
Reference
Internet Explorer Protected Mode

Feature Impact
High
Brief Description
In Windows Vista and Windows Server 2008, Microsoft® Internet Explorer 7 runs in Protected Mode,
which can help protect users from attack by running the Internet Explorer process with greatly restricted
privileges. Protected Mode significantly reduces the ability of an attack to write, alter, or destroy data
on the user's machine or to install malicious code. It can help protect a user from malicious code
installing itself without authorization. This is the default mode for Internet Explorer when Windows Vista
and Windows Server 2008 are installed.
Manifestation
 Applications that use Internet Explorer 7 will not be able to write directly to disk while in the
Internet or Intranet zone.
 Applications may not know how to handle new prompts.
Protected Mode builds on the new integrity mechanism to restrict write access to securable objects like
processes, files, and registry keys with higher integrity levels. When run in Protected Mode, Internet
Explorer is a low-integrity process. It cannot gain write access to files and registry keys in a user's profile
or system locations.
Low-integrity processes can only write to folders, files, and registry keys that have been assigned a low-
integrity mandatory label. As a result, Internet Explorer and its extensions run in Protected Mode, which
can only write to low-integrity locations, such as the new low-integrity Temporary Internet Files folder,
the History folder, the Cookies folder, the Favorites folder, and the Windows Temporary Files folder.
Furthermore, the Protected Mode process will run with a low desktop integrity level when Windows
Vista and Windows Server 2008 ship, which will prevent Protected Mode from sending specific window
messages to higher integrity processes.
By preventing unauthorized access to sensitive areas of a user's system, Protected Mode limits the
amount of damage that can be caused by a compromised Internet Explorer process or malware. An

attacker cannot, for example, silently install a keystroke logger to the user's Startup folder. Likewise, a
compromised process cannot manipulate applications on the desktop through window messages.
Of course, these defenses also limit legitimate changes to higher integrity locations (IL). As a result,
Protected Mode provides a compatibility architecture that reduces the impact on existing extensions, as
shown in the following figure.
Figure 1: IE Protected Mode Compatibility Architecture

A compatibility layer handles the needs of many existing extensions. It intercepts attempts to write to
medium integrity resources, such as the My Documents folder in the user profile and the
HKEY_CURRENT_USER registry hive. The compatibility layer uses a generic Windows compatibility fix to
automatically redirect these operations to the following low-integrity locations:
 %userprofile%\LocalSettings\Temporary Internet Files\Virtualized

 HKEY_CURRENT_USER\Software\Microsoft\InternetExplorer\InternetRegistry
Two higher privilege broker processes allow Internet Explorer and extensions to perform elevated
operations given user consent. For example, the user privilege broker (IEUser.exe) process provides a set
of functions that let the user save files to areas outside of low-integrity areas. In addition, an
administrator privilege broker (IEInstal.exe) process allows Internet Explorer to install ActiveX controls.
Remedies
Quick solution
 Add the site in question to the trusted sites list.
 Turn off Protected Mode (not recommended).
Compatibility test
 Apply the quick solution and ensure that the application can perform the dependent functions
as in Windows XP SP2.

 Change the application to handle Protected Mode, including any related prompts that may be
displayed.

Security and Compatibility in Internet Explorer 7
Understanding and Working in Protected Mode Internet Explorer
Internet Explorer Developer Center
http://www.microsoft.com/windows/ie/ie7/downloads/checklists.mspx
Windows 64-bit
Feature Impact
High
Brief Description
Windows Vista and Windows Server 2008 fully support the 64-bit architecture processors from AMD and
Intel. The 64-bit version of Windows Vista and Windows Server 2008 can run all 32-bit applications with
the help of the WOW64 emulator. However, 16-bit applications, 32-bit installers, and 32-bit kernel
mode drivers are not supported by the kernel.
All 64-bit drivers have to be digitally signed for Windows Vista and Windows Server 2008 64-bit editions.
Unsigned drivers are not supported and cannot be installed on 64-bit Windows Vista and Windows
Server 2008. The digital signature check is done both during installation and driver load time.
Manifestation
 Applications or components that use 16-bit executables, 16-bit installers or 32-bit kernel drivers
will either fail to start or will function improperly on a 64-bit edition of Windows Vista and
Windows Server 2008. In this case, the following error message is displayed:
The program or feature "[exepath]\[app16bit].exe" cannot start or run due to incompatibility
with 64-bit versions of Windows. Please contact the software vendor to ask if a 64-bit Windows
compatible version is available.
 When a 16-bit installer or application is launched, the following error message is displayed:
The version of this file is not compatible with the version of Windows you're running. Check your
computer's system information to see whether you need an x86 (32-bit) or x64 (64-bit) version of
the program, and then contact the software publisher.
 Installation of 32-bit kernel drivers will fail on the 64-bit system. If an installer manually adds a
driver by editing the registry, the system will not load this driver and this action could cause the
system to fail.

 Installation of 64-bit unsigned drivers will fail on the 64-bit system. If an installer manually adds
a driver by editing the registry, the system will not load the driver during load time if it is not
signed.
Remedies
Leverage new capability solution
 All 16-bit components should be removed from applications and replaced with 32-bit or 64-bit
equivalents.
 All 16-bit installers should be converted to 32-bit or 64-bit installers.
 If the application uses kernel mode drivers, then a 64-bit version of the driver needs to be
authored. The application should detect the platform of the OS (32-bit or 64-bit) and then install
the proper architecture of the driver based on the OS platform.
 Ensure that all 64-bit drivers are digitally signed.
Compatibility test
 Install and launch the application on a 32-bit and a 64-bit Windows Vista and Windows Server
2008 machine. The application should function properly on both architectures.

Running 32-bit Applications
Digital Signatures for Kernel Modules on x64-based Systems Running Windows Vista
Kernel Mode Code Signing in x-64 Windows Vista
IIS 7
Feature Impact
High
Brief Description
Internet Information Server 7 provides a revolutionary way to develop and manage web applications. It
introduces granular controls over the various components, reduces administrative costs, provides better
security, and simplifies development.
IIS 7 also enhances features from the older versions in various ways. Some of the changes that could
impact compatibility for applications developed for IIS 6 or older versions are below:
 IIS is componentized and Setup is granular; not all components are installed by default: NTLM is
not installed by default
 Buffering files to memory is on by default
 ISAPI changes

 Metabase changes (backup/restore; import/export)

 MMC snap-in extensions will not work
 IIS reset does not stop W3svc; starting W3svc does not start IISAdmin
 Aspnet_regiis.exe has undergone significant changes
Deprecated components in IIS

The following IIS features have been retired and will not be available in IIS 7:
 IIS 5.0 Isolation Mode
 Metabase account recreation (checker code)
 Sub-authentication (password synchronization and old digest authentication)
 Built-in Passport support
 Convlog.exe
 Clustering UI support
 IISRESET –reboot option
 IIS Shell Extension
 NNTP
 ASP content rotator and nextlink
 Server-side image maps
 Internet Data Connector (HTTPODBC.DLL)
 URLContent Rating UI
 Authorization ISAPI
 Password change code
 IIS*.VBS command-line tools in %windir%\system32
 WebDAV
 Front Page Server Extensions
Manifestation
 Sites using missing components may fail to run.
 Sites using deprecated components will not run without modification.
 Management tools and methods dependent upon the deprecated IIS metabase will break.
 Cycling the W3SVC alone may not resolve problems like it did in earlier versions.
Remedies
Review installed IIS features and enable those that are required to enable proper functionality. IIS 7.0
breaks up the Web server into a lightweight server core and more than 40 feature modules that can be
plugged into this core. These modules - like StaticFileModule, which allows downloads of static Web
content, or WindowsAuthModule, which supports integrated NTLM authentication - can be
independently installed on the server to provide the exact functionality you need.

IIS 7.0 features a new delegated configuration system based on a hierarchy of distributed XML
configuration files. These files provide a portable method of configuration management which allows
the side-by-side storage of IIS and ASP.NET configuration, using clean and strongly structured XML
directives.
Cycling of all IIS 7 related services may be necessary to provide the reset functionality from earlier
versions. Each service should be checked when restarted to confirm the restart.

Details, development guidelines and IIS 7 exploitive features
IIS 7 Virtual Labs
Explore the Web Server for Windows Vista and Beyond

Microsoft Graphical Identification and Authentication (GINA)

Feature Impact
High (frequency: low)
Brief Description
Prior to Windows Vista and Windows Server 2008, to log on to a third-party server or with a third-party
device, ISVs had to replace the Graphical Identification and Authentication (GINA) dynamic-link library in
Windows XP. Such applications also had to replace the existing UI and implement smart card and
remote desktop features on Windows XP.
Note: If an application did not function this way in Windows XP, then this information does not apply.
Windows Vista and Windows Server 2008 introduce a new authentication model where LogonUI and
WinLogon communicate directly with each other. This model provides simplicity, scalability, and
flexibility that did not exist with GINA. Unlike the GINA module, ISVs no longer need to replace the UI for
the logon screen, thus relieving the ISV of the burden of re-authoring the user interface for the user. An
ISV can author a credential provider, which is a module that plugs into the LogonUI, to describe the UI
and to gather the credential and pass it on to WinLogon. Credential providers are completely
transparent to WinLogon.
Credential providers are also additive meaning that users can install multiple credential providers and
pick the one they want to use. Credential providers can be user selected and/or event driven. Multiple
credential providers can coexist on Windows Vista and Windows Server 2008 and are not only for third
parties. In fact, Windows will ship two credential providers in the box: a user name and password
credential provider and a smart card credential provider.
Additionally, credential providers can be reused within CredUI. That is, the same object that describes
and collects credential information on LogonUI can be used to gather the very same credentials in
CredUI scenarios.
The GINA functionality from Windows XP and Windows Server 2003 has been deprecated and removed
from Windows Vista and Windows Server 2008. The GINA modules of applications will not function and
must be re-authored using the new authentication model for Windows Vista and Windows Server 2008.
Manifestation
 User will not be able to successfully install custom logon applications.
 User will not be able to log on using custom logon applications (using the Windows XP
technology) in Windows Vista and Windows Server 2008. These may include biometric devices,
custom UI for logon, or virtual private network (VPN) solutions for remote users with custom
logon UI.

Remedies
Leverage new capability solution.
 The applications or components that use the GINA technology must be re-authored to use the
new logon authentication model for Windows Vista and Windows Server 2008.

For all credential provider information and questions, send e-mail to the Shell Credential Provider alias:
credprov@microsoft.com
Session 0 Isolation
Feature Impact
High (frequency: low)
Brief Description
In Windows XP, Windows Server 2003, and earlier versions of the Windows operating system, all
services run in the same session as the first user who logs on to the console. This session is called
Session 0. Running services and user applications together in Session 0 poses a security risk because
services run at elevated privilege and therefore are targets for malicious agents that are looking for a
means to elevate their own privilege levels.
The Microsoft Windows Vista and Windows Server 2008 and Windows Server 2008 operating systems
mitigate this security risk by isolating services in Session 0 and making Session 0 non-interactive. In
Windows Vista and Windows Server 2008, only system processes and services run in Session 0. The first
user logs on to Session 1, and subsequent users log on to subsequent sessions. This means that services
never run in the same session as users' applications and are therefore protected from attacks that
originate in application code.
Specific examples of affected driver classes include:
 Printer drivers, which are loaded by the spooler service
 All drivers authored with the User Mode Driver Framework (UMDF), because these drivers are
hosted by a process in Session 0
Application classes affected by this feature include:
 Services that create UI

 A service that tries to use window message functions such as SendMessage and PostMessage to
communicate with an application
 Applications creating globally named objects

Manifestation
If a service belonging to an application throws a UI, the application is waiting on the service, and the UI
is not displayed in the user session.
Remedies
Quick solution
 If the application's service uses a UI, a built-in mitigation in Windows Vista and Windows Server
2008 allows the user to interact with the Session 0 UI in a special desktop. This will make
available the UI specific to the application, rather than the entire Session 0 desktop.
 If the application creates globally named objects, then use the Windows XP compatibility mode
to ensure that the application will continue to work with the Session 0 services.
Compatibility test
Test and verify the application on Windows XP in a Terminal Server mode or a Fast User Switching (FUS)
mode. If the application works properly on Windows XP in these scenarios, then it is very likely to work
under Windows Vista and Windows Server 2008.
Verify that the application functions properly after applying the Windows XP compatibility mode, which
contains mitigation for some of the Session 0 issues.
Test the driver in Windows Vista and Windows Server 2008 to ensure that it runs properly. If that is not
possible, test the driver in Windows XP with FUS enabled and multiple users logged on. If the driver
works correctly for second and subsequent logged-on users, it is not likely to be affected by the Session
0 changes in Windows Vista and Windows Server 2008. The only issues that this test does not detect are
those related to the absence of the video driver in Session 0 in Windows Vista and Windows Server
2008.

 Use client or server mechanisms such as remote procedure call (RPC) or named pipes to
communicate between services and applications.
 Use the WTSSendMessage function to create a simple message box on the user’s desktop. This
allows the service to give the user a notification and request a simple response.
 For a more complex UI, use the CreateProcessAsUser function to create a process in the user's
session.
 Explicitly choose either the Local\ or Global\ namespace for any named objects, such as events
or mapped memory that the service makes available.

Impact of Session 0 Isolation on Services and Drivers in Windows Vista
Services
Synchronization

Making a Remote Procedure Call

Client/Server Applications
CreateProcessAsUser
Test Your Application with Fast User Switching
Networking: TCP/IP Stack and the Windows Filtering Platform

Feature Impact
High
Brief Description
The Windows Vista and Windows Server 2008 networking stack has been completely rewritten. Instead
of the dual stack model that exists in Windows XP or Windows Server 2003 (to support IPv4 and IPv6),
the networking stack implements a new architecture whereby there is a single transport and framing
layer that supports multiple IP layers. There are several new features along with several protocol
enhancements. The new stack is very modular, flexible, and extensible. While all attempts have been
made to maintain application compatibility with the existing applications that interface with the stack at
various layers, nevertheless, there are changes (that are mostly side-effects of the improvements) that
may have potential application compatibility issues. Application developers must carefully evaluate to
understand the impact of these changes on their applications.
The Microsoft Windows Filtering Platform (WFP) API allows developers to create code that interacts
with the filtering that takes place at several layers in the Windows Vista and Windows Server 2008
operating system networking stack and throughout the operating system. WFP also integrates with and
provides support for firewall features, such as authenticated communication and dynamic firewall
configuration, based on an application's use of the sockets API.
Note: WFP is not a firewall itself. It is a set of system services and APIs that enable firewalls to be
implemented.
The following elements of the TCP/IP stack will not be supported on Windows Vista and Windows Server
2008:
 The firewall-hook driver functions and the filter-hook driver functions have been deprecated.
 The R-series tools, including rexec, rsh, finger, etc. These tools are available from the Services
for Unix components, if needed.
 The Internetwork Packet Exchange (IPX) protocol. IPX has been deprecated and is no longer
available from Microsoft There should be little, if any impact on application compatibility
because of this change.

Manifestation
 If an application built for Windows XP was using only public functions for networking, it should
not see any break in functionality; it should be tested on Windows Vista and Windows Server
2008 to verify its functionality.
 Applications using any of the firewall-hook driver or filter-hook driver functions will not work.
 Applications relying on internal structures and functions calls that were never published by
Microsoft will fail.
 Transport Driver Interface (TDI) filter drivers written in Kernel mode may not work properly after
an OS upgrade.
Note: The TDI interface is on a path to deprecation in a future release. However, these drivers will still
work on Windows Vista and Windows Server 2008.
Remedies
Leverage new capability solution
The WFP exposes a rich set of functions and services for network security developers and provides
guidance and documentation on the available feature sets.
Note: Applications and scripts that rely on Services for Unix and R-series must now install these tools
first.

WFP MSDN Query
Networking: Kernel Mode IP Helper APIs

Feature Impact
High
Brief Description
In prior releases of Windows, Winsock clients did not have an API set to access the kernel. This has
changed in Windows Vista and Windows Server 2008. Also, Windows Vista and Windows Server 2008
now support IPv6 by default. Instead of providing separate APIs for IPv4 and IPv6, a new Helper API set
has been designed to provide a common functionality across all the new technologies, as follows:
 Kernel mode functions for Windows Sockets in Kernel (WSK) clients

 IPv6 support
 Single set of functions for IPv4 and IPv6 addressing
 Provides a consistent, extensible object model
 Provides a well-defined security model based on the network service interface

 Exposes new stack functionality, such as compartments and sub-interfaces
Manifestation
Applications using the older Helper APIs or undocumented kernel function calls will fail to function and
may become unstable.
Remedies
 Applications need to support and implement the new kernel mode IP helper APIs.
Networking: IPv6
Feature Impact
High (frequency: medium)
Brief Description
The TCP/IP stack in Windows Vista and Windows Server 2008 has IPv6 enabled by default. IPv6
connectivity is preferred, if available. This has the following implications for applications that hook into
the TCP/IP stack:
 Applications and services that are IPv6 compatible can have a much improved peer-to-peer
connection success rate on IPv4 networks due to the built-in NAT traversal capabilities of Teredo
(which encapsulates IPv6 inside of IPv4 across NATs).
 IPv6 traffic will be created by the Windows Vista and Windows Server 2008 stack regardless of
whether the network supports IPv6 or not. Therefore, for example, all Windows Vista and
Windows Server 2008 systems will have at least one IPv6 address (for link-local), and will
attempt DNS lookups for both IPv4 and IPv6.
 The Windows Vista and Windows Server 2008 stack will always prefer using IPv6 when it can
find an IPv6 address for the remote system it needs to talk to. Network communication will take
place for any IPv6 compatible application or service if both systems in a session have IPv6
addresses (e.g. sharing files on a LAN will usually be done over IPv6).
 IPv6 addresses will be present and on by default. There may be multiple IPv6 addresses
associated with link-local, global, temporary, or transition technologies like 6to4, 6over4,
ISATAP, or Teredo.
Note: Teredo will be enabled by default, but remains dormant unless an application or service tries to
use it. The Teredo service becomes active if: 1. The Windows Firewall exception for a listening application
or service has Edge Traversal option enabled (an advanced setting in the MMC snap-in of the Windows
Firewall, or invoked via an option in the Windows Firewall APIs). 2. An application or service attempts to
communicate with a Teredo address (the regular stateful inspection features of the Windows Firewall
will ensure that only IPv6 responses matching the outbound requests will be allowed in).

 Windows Vista and Windows Server 2008 will allow a system to be configured in an IPv6-only
mode. In this case, no IPv4 support will be available.
The TCP/IP stack in Windows Vista and Windows Server 2008 supports a strong host routing model. This
means that packets are routed from a multi-homed machine not only based on the destination address
but also based on the source address of a packet. This change is needed because in IPv6, each machine
gets multiple IP addresses and, with transition technologies, essentially appears as a multi-homed
machine as far as routing is concerned. To ensure proper connectivity happens in these scenarios, the
networking stack has to implement a strong host routing model.
Manifestation
Applications using the Windows XP TCP/IP stack and/or unaware of the IPv6 protocol will not function
properly and may crash or create an unstable system.
The implication of the strong host routing model for the applications is as follows:
 Connection from a non-loopback address to a loopback address and vice-versa will fail.
 Packets with a source address of 127.0.0.0/8 will not be allowed to be sent by a Windows Vista
or Windows Server 2008 machine on a network.
Applications that do not use protocol agnostic APIs, and aren’t IPv6 compatible, will not be able to take
advantage of Teredo IPv4 NAT traversal and connections may fail when one or more parties is behind an
NAT.
Remedies
Applications will need to be re-authored as follows:
 Any application that hooks into the stack must be capable of handling IPv6 traffic. Minimally, it
should not crash on receiving IPv6 traffic.
 Any application that relies on there being a single IPv4 address will need to be modified to
handle multiple IPv6 addresses. Further, any application that picked the first address may have
to more carefully identify the IPv6 address to use. This is because an IPv6 link-local address is
not routable and hence, the application may not work. Instead, the application should use
functions that allow connection by name and choose the most appropriate address
automatically.
 Applications must handle and support IPv6-only scenarios.
 Applications must support and implement the strong host routing model.
 IPv6 compatible applications that set the Edge Traversal flag in the Windows Firewall exceptions
(using Windows Firewall APIs) will automatically take advantage of Teredo for traversing IPv4
NATs.

http://msdn2.microsoft.com/en-us/library/ms738649.aspx

Compatibility Risks
Deprecated Components
The following components from earlier Windows releases will not be present in Windows Vista nor
Windows Server 2008:
 Kernel mode Printer driver support: All printer drivers will now have to follow the User mode
driver framework. All kernel mode printer drivers will be blocked from loading on Windows Vista
and Windows Server 2008. For more information, see the User-Mode Driver Framework (UMDF)
site.
 Windows Help for 32-bit applications (WinHlp32.exe) -Windows Help is not supported and some
of the Windows Help code has been removed for the release. To view 32-bit Help files with the
.HLP file name extension in Windows Vista and Windows Server 2008, you will need to
download and install Windows Help from the Microsoft Download Center. For more
information, see Help Engine Support.
Note: HTML Help and .CHM files will continue to be supported for Windows Vista and Windows
Server 2008.
 Microsoft® FrontPage® server extensions - Windows® SharePoint® Services now provides an
enhanced feature set to the developer community.
 Services for Macintosh - There is no replacement for this component.
 D3DRM - DirectX will be the only supported graphics package for Windows Vista and Windows
Server 2008.
 Web Publishing Wizard - There is no replacement for this component.
 NTLMSSSP Service
 Windows Management Instrumentation Driver Extensions (WMI) Services
 RPC-Locator Service
 POP3 Email Server – There is no replacement for this component.
 NetDDE - For security reasons, Windows Vista and Windows Server 2008 does not support
NetDDE. (NetDDE is disabled by default on Windows XP SP 2 and Windows Server 2003.) Regular
DDE is still supported. NetDDE is a technology that allows applications that use the DDE
transport to transparently exchange data over a network. The result is the application fails to
exchange data over the network. To workaround, use a different networking technology, such
as DCOM or Windows Communication Foundation.

http://support.microsoft.com/default.aspx?scid=kb;en-us;125703 provides details on NetDDE.
Windows Help (WinHlp32.exe) is being deprecated for Windows Vista and Windows Server 2008. To
view 32-bit Help files with the .HLP file name extension in Windows Vista and Windows Server 2008, you

will need to download and install Windows Help from the Microsoft Download Center. For more
information, see Help Engine Support.
Note: HTML Help and .CHM files will continue to be supported for Windows Vista and Windows Server
2008.
Help for Windows Vista and Windows Server 2008
Windows Display Driver Model

Windows Vista and Windows Server 2008 Display Driver Model (VDDM) is a completely new display
driver model that improves display driver stability in Windows. There are a number of key features in
VDDM, including:
 Efficient management of video memory for DX applications and the new Desktop Window
Manager (DWM). Multiple 3-D applications will be using the graphics processor unit (GPU) in
 Driver upgrades without reboot.
 Dynamic detection of GPU hangs and recovery without reboot.
 Hot Plug detection support of monitors.
 Using the hardware features mandated by DX9L.
 Glitch-free video playback.
 An opportunity for a very secure design.
While most of the applications from earlier versions of Windows should not be impacted by VDDM,
some risks include:
 DX Games compatibility, resulting in DX run-time or IHV driver or core graphics stack issues.
 Mobile functionality like hotkey, cloneview, brightness and zoom due to stricter ACPI
requirements.
 Accessibility specifically that screen magnification applications designed by Windows XP will not
work on Windows Vista or Windows Server 2008.
Safe Exception Handling

In earlier Windows versions, the IsBadReadPtr and IsBadWritePtr functions were used to validate
parameters. These functions are now banned on Windows Vista and Windows Server 2008. Also,
applications that rely on Windows components using these functions to validate parameters will find
that Windows no longer uses them. Applications should not rely on Windows to do any parameter
validation (a check for null is done and the application fails if it is a bad pointer).
Safe exception handling (SEH) also goes hand-in-hand with the no-execute flag. Exception handlers are
checked that they are marked page_execute before the exception is dispatched, and also that the
handler is valid code and that it is in the SEH table.

DllMain Operations
The load order of DLLs during process creation is not guaranteed and should never be depended upon to
perform operations. Complex processing in DllMain may cause applications to hang or crash because of
new OS component dependencies. For details, see the following pages on MSDN:
 DllMain Callback Function
 "Calls to an OLE Object Should Not Be Done from DllMain"
 "PRB: Cannot Create an MFC Thread During DLL Startup"
 "Your application may fail with an 'Access Violation' error message when you use ODBC or DAO
in the InitInstance or DllMain functions of a DLL"
 "COM application hangs when you call CoCreateInstance from DllMain"
Outlook Express Renamed

Outlook Express has been changed and moved and is now called Windows Mail. MAPI applications need
to be aware of this change. Most applications that dynamically use the default program for MAPI should
not see any compatibility problems.
Shell: Themes and My Documents Location

The Windows Explorer Shell has introduced new visual themes for Windows Vista and Windows Server
2008. An application capable of handling themes in earlier versions of Windows should have no
compatibility impact with the new themes.
Also, the My Documents location and structure has changed in Windows Vista and Windows Server
2008 to provide a better user experience. The user data is now stored in \users\%username%\ folder
structure. Pictures, Music, Documents, Desktop, and Favorites are all new folders directly under this
structure. If an application uses the ShGetFolderPath function and uses the folder path dynamically, it
will be redirected automatically to the new path and file locations. In general, applications will not see a
compatibility impact due to these changes.
Fast User Switching (FUS)

Fast User Switching (FUS) is now available on Windows Vista and Windows Server 2008 for all versions,
including domain joined computers. Applications and installers need to be aware of FUS and be able to
handle multiple logged in user sessions and terminal server scenarios. For more information, see the
Microsoft Windows XP Fast User Switching: Design Guide for Building Business Applications page.
CriticalSection Code Changes

CriticalSection code was changed to increase security and robustness. Applications using critical section
locks:
 Should always initialize critical sections.

 Should not read into undocumented objects. Applications that read into the undocumented
structures to assess the status of a critical section will most likely break if they are looking for
uninitialized and freed critical sections.
 Should prevent starvation. Applications that call Sleep while holding the critical section lock now
can cause starvation for other threads that need the lock. Sleep calls should be placed after the
LeaveCriticalSection call.
For more information, see the critical section objects topic in MSDN.
Default Programs
Brief Description
Default Programs has a new infrastructure to manage per user file and protocol associations designed
with contentious applications in mind. Applications need to register in order to use Default Programs’
functionality. Be aware that Default Programs will get a lot of visibility in Windows Vista and Windows
Server 2008 and beyond and make certain tasks much easier for applications to code and maintain.
Remedies
Windows Vista In Windows Vista and Windows Server 2008, we have provided a new set of functionality
for applications to take advantage of. This new set of functionality is called “Default Programs”.
Default Programs was designed to help users make choices about their default behaviors. A large part
of this is that defaults in Windows Vista and Windows Server 2008 and beyond will be primarily
controlled at the Per User level instead of the Per Machine level. This allows much more flexibility for
the multi user computer environment that we believe is going to become the standard. Part of this is
adding a new centralized UI for the user, but the other part is giving ISVs the tools they need to help a
user express choice. Default Programs gives an application:
 A simplified process for taking defaults

 Per user file and protocol associations
 Programmatic way to check for defaults
 Common windows UI to reuse
 Advertising area within Windows
This functionality was primarily designed for contentious applications. These are applications that want
to be the default for file types like mp3 and jpeg, or protocols like http and mailto. Applications that
primarily deal in their own protocols and file associations won’t typically need to use this new
functionality since they don’t have to worry about other applications stomping over them. Applications
that aren’t contentious will behave and install like in XP. However, any application can take advantage
of the new Default Programs work.
Default Programs’ functionality is built into the Operating System as a series of Control Panels and open
APIs. For an application to use the control panels or APIs it needs to register at install time to be part of

Default Programs by writing a specific schema. This will allow the application to show up in the Default
Programs control panels so a user can restore the applications default file associations and protocols at
any given time.
Once an application has registered with Default Programs the application can take advantage of new
functionality provided through APIs. Default Programs provides APIs to:
 Restore all registered defaults
 Restore single registered default
 Query for the owner of a specific default file association/protocol/start menu canonical
 Launch Defaults UI for a specific app
 Clear all per user associations
The Default Programs work is intended to make it very easy to express user choice post install and
provide applications a simple framework to contend for defaults and claim them.
Why Use Default Programs?

High level points:
 Default Programs helps applications get discovered
 The underlying architecture that allowed all administrators to write to HKLM is changing for
Windows Vista and Windows Server 2008
 Default Programs allows applications to maintain Windows XP parity process flows while
changing very little code
 Claiming only machine level defaults won’t always give the desired results
There is an obvious consumer gain for contentious applications using the Default Programs framework,
but there is also a significant gain for the application to use Default Programs.
Default Programs provides a rich UI experience for registered applications so it can really advertise to
the user all the amazing things it can do. In addition, applications that are digitally signed with a URL will
be able to display that URL and allow users to easily navigate back to its home website and see what
other apps and enhancements the company offers.
Using the new API set also significantly reduces the development cost for new applications. Almost all
contentious applications monitor or check to see if they are the default. Using the new API set this can
be done in a single API call instead of crawling the registry which was the method in previous versions of
the OS.
Using the new API set also helps applications to function correctly in the new world with UAC (User
Account Control). UAC is implemented by taking an administrator and making her look like a standard
user to the system. This means that an administrator cannot normally write to HKLM in Windows Vista
and Windows Server 2008 and beyond. This is done so processes cannot act on the administrator’s
behalf without her knowledge. Installation will typically always be elevated because there is an
experience for that, but for applications that want to be able to claim defaults post install, they need to

claim the defaults on the per user level instead of the per machine level. Switching to the new API set
does this automatically. Applications that try to claim per machine defaults post install will fail.
The other strong reason to update an application to use Default Programs is to consistently achieve the
desired results. File and protocol associations are derived from a hierarchical structure in registry. Part
of this structure dictates that per user defaults will always be chosen over per machine defaults. This
means that if an application decided to build elevation points in its code to claim defaults by writing to
HKLM like in XP, it would not always achieve the desired result. As soon as another similar application is
installed and uses Default Programs’ APIs that take per user file and protocol associations, the previous
application would no longer be the default because per user defaults have a higher precedence.
Windows Vista Windows Vista Windows Vista
Default User Check List

 Registers correctly for SPAD
 Registers correctly for Program Defaults
 Registers correctly file associations, protocol handling, OpenWith, Start Menu, QuickLaunch
 Install follows guidelines (Sets per-machine registration, does not take defaults)
 First run follows guidelines (ask user for settings, file associations, etc)
 Install or upgrade doesn’t take defaults
 Correctly self-checks for default. User permission before taking default
 Never triggers virtualization
 No AppCompat warnings or blocks (PCA)
 Also continues to work correctly in XP
 [use OS UI for file associations, etc]
 [Signed code – URL in Program Defaults]

File Association Documentation
An Overview
Windows Vista: Default Programs
Default Program UI
API description and Code samples

Videos
Default Programs Videos - Watch Video
Program Compatibility Assistant (PCA)

Introduction to PCA
The Program Compatibility Wizard in Help and Support and the Compatibility tab in file properties are
useful tools for users to fix program compatibility issues in Windows XP. The major limitation with these
tools is the discoverability and the fact that the user needs to know when to use these tools. The
Program Compatibility Assistant (PCA) is a new feature in Windows Vista and Windows Server 2008 that
can make older programs that have compatibility problems work better, in an automated manner. PCA
monitors programs for known issues. If an issue is detected, it notifies the user of the problem and
offers to apply solutions that will be effective before the user runs the program the next time.
The following sections describe the scenarios in which the user is expected to encounter PCA, details on
the user experience, the solutions applied in each of those scenarios and how to manage the settings
made by PCA at a later time. The last section talks about how to exclude programs from PCA.
PCA Scenarios
Detecting failures in setup programs
One of the main scenarios for PCA is to detect setup programs failing to install on Windows Vista and
Windows Server 2008 and to provide the solution of applying the Windows XP compatibility mode.
The most common setup failure is due to installers hard coding the check for the Windows OS version.
These installers will typically fail with an error message saying that the current version of Windows is not
supported and installation will be terminated.
Below is an example of such error message, illustrated by a test program.
Figure 2: Example of a PCA Error Message

Programs commonly use GetVersion or the GetVersionEx APIs to get information on the Windows OS
version they are running on. In Windows Vista and Windows Server 2008 these APIs will return 6 as the

major version. If the program is hard coded to look for the XP version, which is major version 5, then it
will fail in Windows Vista and Windows Server 2008. The XPVersionLie fix included in the Windows XP
compatibility mode will provide the XP version of the OS to the program, when it calls GetVersion or
GetVersionEx APIs.
PCA targets to detect this scenario and will display a user interface similar to the one below after the
installer is terminated. This scenario also covers uninstallers and a similar dialog will soon be shown.
Figure 3: PCA UI after Installer Termination.

When the user selects the option to 'Reinstall using recommended settings', the WINXPS2 compatibility
mode will be applied to the installer program and the installer will be automatically restarted.
More details on what happens under the covers are explained through the Question / Answer below:
1. What is the detection logic and how does PCA know that the setup failed due to version
problems?
PCA does not specifically look for the setup's failing due to version problems. The logic used by PCA is to
detect if a setup did not complete successfully. It monitors a program detected as setup by Windows
Vista and Windows Server 2008 and checks whether the program registers an entry in Add or Remove
Programs (ARP). If no entries are created in ARP then PCA concludes that the installer did not complete
successfully. It will then wait for the install program to terminate before displaying the UI. If it is an
uninstaller then the detection looks for whether an entry was deleted from ARP.
2. How does PCA get information about the setup programs?

PCA relies on the User Access Control (UAC) feature in Windows Vista and Windows Server 2008 to
know whether a program is a setup program. UAC includes detection for setup programs and will make
sure the detected setup programs will be run as administrator. This includes getting administrative
credentials or confirmation from the user before launching the program.
3. What does each option in the PCA dialog for setups do?
'Reinstall using recommended settings'
This will apply the Windows XP compatibility mode and restart the program. Refer to the section
below on managing PCA settings to get more details on how the compatibility mode is applied.
'The program installed correctly'

It is possible that in some cases, PCA might come up for a setup program that completed correctly
but did not create an entry in ARP. In those cases, users can use this option to suppress the PCA
dialog the next time.
'Cancel'
PCA will do nothing.
All these options will result in the PCA dialog disappearing. PCA will not show up again for the same
setup program except when the user selected the 'cancel' option on the previous PCA dialog.
Detecting program failures under UAC

The second main scenario category for PCA is to detect program failures while running under User
Access Control (UAC). PCA detects 3 different types of program failures under UAC, which are described
below.
Detecting program failures while trying to launch installers

PCA detects this particular scenario of a program not running as administrator that is experiencing a
failure while launching a child exe, because the child program is required to run as administrator. This
will typically be the case for programs trying to launch an updater.exe. This is because Windows Vista
and Windows Server 2008 returns a new error code to programs trying to launch an executable which is
detected to run as administrator. If the same updater.exe is run from Explorer it will run as
administrator since Explorer knows how to handle this error code. Explorer launches the UAC consent UI
asking for administrator credentials or approval and finally runs the program as administrator. Below is
an example of a PCA dialog that will show up in this scenario, illustrated by a test program.

Figure 4: PCA dialog box for program trying to launch a child.exe

Here the test program has tried to launch an updater which is required to run as administrator and has
failed. In this case, PCA will apply the ELEVATECREATEPROCESS compatibility mode, which will enable
the program to successfully launch the child exe as administrator the next time. Now when the program
is run the next time and while trying to launch the updater, it will not fail and will successfully run as
administrator. The user will see the UAC consent UI.
More details on what happens under the covers are explained through Question/Answer below.
1. What is the detection logic and how does PCA know that the program failed to launch a child
exe which needs to run as administrator?
The detection for this scenario is accomplished through instrumentation at the CreateProcess
API to detect the cases when a child process launch fails due to the requirement to run as
administrator.
2. Why are there no options in this PCA dialog?
Due to the high confidence on the issue detection in this scenario, the solution
(ELEVATECREATEPROCESS compatibility mode) is automatically applied and the user is not given
any options.
Detecting installers that need to be run as administrator

One of the tenets of Windows is that the installation of most software requires administrative privileges.
This is because installed applications are loaded into system directories and manipulate system
resources. The install detection part of the overall User Access Control (UAC) feature aids in this by
identifying setup programs and automatically prompting the user for administrator approval or
credentials. In some cases it is possible that an install program may not be detected by UAC. These are

typically custom made installers which are not built using standard installer technologies like Install
Shield, Microsoft Windows Installer, etc.,
PCA detects this scenario and will display a user interface similar to the one below after the installer is
terminated.
Figure 5: Detecting installers that need to run as Administrator

When the user selects the option to 'Restart the program as administrator’, the program will be marked
to run as administrator and will be automatically restarted.
1. What is the detection logic and how does PCA know that the program needs to run as
administrator?
The logic used by PCA is to detect whether the program tried to create a sub folder under the Program
Files directory and subsequently tried to copy an .exe or .dll file inside it. PCA assumes these are the
common actions performed by an installer. PCA relies on events from the File virtualization feature as
part of the overall User Access Control (UAC) feature for detecting this. When a program is not running
as administrator, writing to the Program Files directory is not permitted as it is one of the system
locations. File Virtualization tries to address this by redirecting the writes attempted on a system
location to a Virtual store. For example, it supports redirecting a directory creation in the virtual
location and writing document files but does not support redirecting binary files like .DLLs or .EXEs. In
either case, File Virtualization sends events that can be consumed by PCA.
2. What does each option in the PCA dialog for this scenario do?
'Restart the program as an administrator'
This will apply the ‘RunAsAdmin’ compatibility mode and restart the program. Refer to the section
below on managing PCA settings to get more details on how the compatibility mode is applied.
'The program installed correctly'

It is possible that in some cases, PCA might come up for a setup program that completed correctly. In
those cases, users can use this option to suppress the PCA dialog the next time.
'Cancel'
PCA will not show up again for the same program except when the user selected the 'cancel' option on
the 'The program installed correctly’ PCA dialog.
Detecting legacy control panels that may need to run as administrator

The last UAC related scenario addressed by PCA is to detect control panel items that need to be run as
administrator. After a legacy control panel item is run once, a PCA dialog similar to the one below will
show up.
Figure 6: Legacy Control Panel item that needs to run as Administrator

1. What is the detection logic and how does PCA know that the control panel item needs to run as
administrator?
There is no specific issue detection logic used in this scenario and this dialog will show up after a
legacy control panel item is completed running. The target is to provide the user with an option to
run the control panel item as administrator, which is the most commonly needed solution for a
control panel that may not work properly under UAC. This dialog will not show up for control panels
tested to work under UAC and manifested with the proper RunLevel marking for UAC (marked to
run either as administrator or As Invoker) set. For more information about UAC and how to create

this UAC manifest, see

http://blogs.msdn.com/shawnfa/archive/2006/04/06/568563.aspx
What does each option in the PCA dialog for this scenario do?
'Open the control panel using recommended settings'
This will apply the ‘RunAsAdmin’ compatibility mode and restart the control panel item as
administrator. Refer to the section below on managing PCA settings to get more details on how the
compatibility mode is applied.
'The control panel works correctly'

In cases where the control panel item works correctly, users can use this option to suppress the PCA
dialog the next time.
'Cancel'
All these options will result in the PCA dialog to disappear. PCA will not show up again for the same
control panel item except when the user selected the 'cancel' option on the 'The control panel
works correctly' PCA dialog.
Detecting program failures due to deprecated Windows components

This PCA scenario mitigates the impact on programs due to deprecated (removed) components in
Windows Vista and Windows Server 2008. PCA detects programs that are trying to access a DLL or a
COM object removed in Windows Vista and Windows Server 2008. If a program is detected trying to
access a known DLL/COM object, PCA will provide a UI at the program termination to inform the user
and provide options to check online for a solution.
Below is an example of a PCA dialog that will show up in this scenario, illustrated by a test program.
Figure 7: Dialog displayed when PCA detects a deprecated Windows component

Here the test program was trying to use the COM objects associated with the DHTML editing control,
which is removed from Windows Vista and Windows Server 2008.
More details on what happens under the covers are explained through Question/Answer below.
1. What is the detection logic and how does PCA know that the program failed to launch a child
exe which needs to run as administrator?
The detection for this scenario is accomplished through instrumentation at the CoCreateInstance API
and the Loader (NTDLL) to detect load failures on COM objects and DLLs respectively. When there is a
failure due to an object or file not found then it will be checked against a known list of DLLs and COM
objects. If a match is found PCA will trigger after the program termination
2. What happens when ‘Check for solutions online’ option is selected?
'Check for solutions online' sends a Windows Error Report to get an online response from Microsoft. The
responses will be displayed in the client Solutions to Problems (wercon.exe) UI. Typically the response
will point the user to a Knowledge Base article that talks about alternatives to the deprecated
component and in some cases provides a link to download the deprecated component from online.
Detecting unsigned drivers on 64 bit platform

This is a scenario where PCA is trying to protect the system stability due to programs or devices using
unsigned drivers on 64 bit platforms. Windows Vista and Windows Server 2008 do not support unsigned
drivers on the 64 bit platform and enforce a policy that all drivers should be signed. If an unsigned driver
is installed into the system with a 64 bit platform it will not be loaded. After the user reboots the
machine, the system will not start if it is a boot time driver. The device or program trying to use the
driver may experience failures which may also result in a system crash. In order to prevent this, PCA
monitors installation of unsigned drivers and whenever PCA detects installation of an unsigned driver it
will notify the user as shown below.

Figure 8: PCA dialog when unsigned driver detected

If it is a boot time driver PCA will disable the driver so that the system will be able to boot.
PCA detects this scenario first by monitoring changes to the
KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services registry key for addition of new drivers into
the system. Then, based on the location of driver from the registry, each new driver installed will be
checked for a valid digital signature. If the driver does not have a valid signature, PCA dialog will be
displayed. Unlike the other PCA scenarios this message is not related to specific applications and is
related to the driver, irrespective of how it was installed.
Inform Users about Compatibility Issues with Known Programs at Startup

Apart from the runtime issue detection scenarios listed above, PCA also informs users at program
startup if the program belongs to a list of programs known to have compatibility issues. The list is stored
in the System application compatibility database. This scenario also exists in Windows XP and these
messages are known as the Application Help (shortly Apphelp) messages. There are two types of
Apphelp messages.
 Hard Block Messages - If the program is known to be incompatible and if allowing the program
could result in severe impact to the system (for example, a stop error or unable to boot after the
install, etc.) then a blocking message as shown below will be displayed.
Note: Microsoft gets approval from each ISV whose program is going to be blocked.

Figure 9:Hard block apphelp message - displayed when incompatibility would have severe impact
 Soft Block Messages - The other type of message is a non-blocking message similar to the one
below. This will be used in the case of programs that have known compatibility issues but the
impact is not severe to the system.
Figure 10: Soft block dialog displayed when incompatibility issues would not cause severe impact
In both cases, 'Check for solutions' sends a Windows Error Report to get an online response from
Microsoft. The responses will be displayed in the client Solutions to Problems (wercon.exe) UI. Typically
the responses will be of 3 types:
1. Pointing the user to an update from the ISV for that program.
2. Pointing the user to an ISV website for more information.
3. Pointing the user to a Microsoft Knowledge base article for more information.

Managing Settings Made by PCA

The compatibility modes will be applied to programs by setting a registry key under,
Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers registry key. The name of the
value is the full path of the program’s executable, and the value is set to the name of the compatibility
mode that is being applied. For the Windows XP compatibility mode, the value is set to “WINXPSP2”.
The registry key will be set under HKEY_LOCAL_MACHINE to apply the solutions to be effective for all
users except for the scenario where the 'ELEVATECREATEPROCESS' compatibility mode is applied
automatically before the PCA dialog shows up. In that scenario, the registry key will be set under
HKEY_CURRENT_USER and the solution will be effective only for the current user.
Apart from this key, PCA stores the list of all programs for which it came up under the following key for
each user, even if no compatibility modes where applied (e.g. in the case the user reported that the
program worked correctly).
HKEY_CURRENT_USER\Software\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Persisted
Excluding Programs from PCA

PCA is intended to detect issues with older programs and not intended to monitor programs developed
for Windows Vista and Windows Server 2008. The best option to exclude a program from PCA is to
include, with the program, an application manifest with run level (either admin or as limited users)
marking for UAC. This means the program is tested to work under UAC (and Windows Vista and
Windows Server 2008). PCA checks for this manifest and will exclude the program. This applies for both
installer and regular programs.
Another option to exclude apps from PCA is to add the list of .exes with full path under the following
registry key, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags\Compatibility Assistant. The value name is ExecutablesToExclude”
which is type REG_MULTI_SZ.
Note the addition of ‘AppCompatFlags’ in the path.
Apart from this, PCA automatically excludes programs running from network locations and programs
containing fixes applied to them in the application compatibility databases.
A group policy setting is provided to disable PCA for all programs if desired. The name of the policy is
'Turn Off Program Compatibility Assistant'. It can be found under 'Administrative Templates ->
Windows Components -> Application Compatibility' in the group policy editor (gpedit.msc).
There are also individual policies to turn off specific scenarios. These policies are available under
'Administrative Templates -> System -> Troubleshooting and Diagnostics -> Application Compatibility
Diagnostics’ in the group policy editor (gpedit.msc).

Event logging
After the user has acted on PCA, an event will be logged in the event log. The events can be found under
‘Application and Services Logs->Microsoft->Windows->Program-Compatibility-Assistant->Operational’
in the Event viewer. The event log includes the following information: Application name, Application
version, Executable path, Scenario ID, User action and names of the compatibility modes applied if any.
The values of the scenario ID are listed in the table below.
Scenario ID Description
1 Detecting failures in setup programs (installer)
10 Detecting failures in setup programs (uninstaller)
3 Detecting program failures while trying to launch installers
8 Detecting installers that need to be run as administrator
9 Detecting legacy control panels that may need to run as administrator
5 Detecting program failures due to deprecated Windows components
11 Detecting unsigned drivers on 64 bit platform
Figure 11: Values of the Scenario ID

Managing Apphelp Messages
In an Enterprise setting, an IT Professional can use the Compatibility Administrator tool to disable the
Apphelp entries present in the System application compatibility database or add custom databases that
contain Apphelp messages for programs used in the enterprise.
The Compatibility Administrator tool ships as part of the Application Compatibility Toolkit. For more
information about the Toolkit, see
http://www.microsoft.com/technet/windowsvista/appcompat/tools.mspx
Graphical Device Interface - GDI

Painting (WM_PAINT) Behavior Differences
Feature Impact
Low

Brief Description
As part of the Desktop Window Manager work, Microsoft has made subtle but important changes to the
way applications paint to the screen. Prior to Windows Vista and Windows Server 2008, an hwnd was
painted directly to the screen, which had certain benefits but really limited how Windows could display
and manage top-level windows. In Windows Vista and Windows Server 2008, all top-level windows are
rendered to an off-screen bitmap (similar to WS_EX_LAYERED), and the Desktop Window Manager
combines the images together to draw the desktop.
Manifestation
Black areas around tool tips, pop-up menus, balloons, splash screens, etc.
This can happen when the application has not painted the entire hwnd, usually because that application
assumed that the pixels in the background windows are good enough.
Flashes of black
A related issue can occur where the background contains uninitialized pixels that appear to the user as
flashes of black on the screen. This occurs when applications do painting that is not part of a
WM_PAINT message. The system detects that the application is drawing and redraws the desktop, but
the application may not have finished drawing the hwnd. This causes the flashes of black.
Glass disabled for an application

This can happen when an application draws to the non-client area of the window (the title bar).
Rubber bands, custom shadows, and other special effects

These are often done using GetDC(NULL); however, reading and writing to GetDC(NULL) tends to be
problematic when applications are backed by a bitmap rather than drawing straight to the screen.
Reading and writing to the screen is significantly slower than Windows XP. Also, not all GDI rasterops are
supported (but we do support XOR).
Improved Far East fonts

Windows Vista and Windows Server 2008 include numerous changes to the Chinese, Japanese and
Korean fonts to make them more readable; one of the side effects is that text can layout slightly
differently in these new fonts as characters may have different widths. Consider testing how your text
lays out on the screen and on the printer. Also consider testing places where Far East languages can be
mixed with Latin character sets (for example, English).
Rendering Performance
Feature Impact
Low

Brief Description
Most applications will run as fast or faster on Windows Vista and Windows Server 2008, but there are
some changes that may require monitoring.
Manifestation
Overall GDI drawing performance is slower
GDI primitives like LineTo and Rectangle are now rendered in software rather than video hardware,
which greatly simplify the display drivers.
Slower text rendering

Calls such as DrawText better support international and East Asian languages.
Reduced application address space

The bitmap for a top-level window is stored in the application's address space (see section on painting),
potentially reducing available address space by a few megabytes.
Reading from and writing to GetDC(NULL)

This operation is slower than previous versions of Windows because applications now render to an
offscreen bitmap rather than directly to the screen. Where possible, consider drawing to an HDC
backed by your HWND, or creating overlay windows. GetDC(NULL) is still the preferred way to get a
screen snapshot.
User Interface Privilege Isolation (UIPI)

Feature Impact
Low
Brief Description
As an added layer of defense against malicious software, Windows Vista and Windows Server 2008 allow
different UI applications to run with three different levels of UI privilege. Applications can freely interact
with other applications of the same and lower permission, but can’t modify or talk to applications of
higher permission. Most applications will run with the middle permission, while applications that require
administrator privileges run in a higher mode. Restricted processes such as low rights Internet Explorer
use the lowest privilege mode.
More specifically, applications in lower privilege modes cannot generally send messages to higher
privileged applications unless the higher privileged application explicitly allows that message by calling
ChangeWindowMessageFilter(). Similarly, lower privileged applications can read but cannot modify
an HWND owned by a higher privileged application. For compatibility reasons, SendMessage and
other APIs will return success even if the API was blocked because of privilege issues. Similarly, where

compatibility impact is high and security risk is low, sometimes low-privileged applications are allowed
to send unsolicited messages to high privileged applications.
Manifestation
Applications that interact with other applications stop doing so.
Utilities that reposition windows, type keystrokes for you, add extra buttons to windows, etc.
Cut and paste between different applications fails.
An Application may not work at all, or it may not support all the different clipboard formats you expect
(rich text, HTML, etc.)?
Remedies
Journaling hooks
WH_JOURNALPLAYBACK and WH_JOURNALRECORD are inherently cross-process, so they require
the highest privilege level. The SendInput() API, which doesn’t require full UI privilege for many cases,
can often be used instead of journaling hooks.
The WH_JOURNALPLAYBACK and WH_JOURNALRECORD journaling hooks are inherently cross-
process, so they require the highest privilege level. An alternative to journaling hooks is the SendInput()
function, which doesn’t require full UI privilege for many cases.
If you have the source code for the program, consider reviewing any code that uses the following
functions, as they often indicate cross-process messaging. The list is not exhaustive, and might not find
every issue, but it provides a good balance between finding issues and minimizing false positives.
SendInput
RegisterWindowMessage
BroadcastSystemMessageEx
BroadcastSystemMessage
SetWindowsHook
SetWindowsHookEx
CallNextHookEx
CallNextHook
SetWinEventHook
AttachThreadInput
FindWindowEx
FindWindow
CreateDesktop
CreateDesktopEx
OpenDesktop
OpenInputDesktop
EnumDesktops
EnumDesktopWindows
SwitchDesktop

SetThreadDesktop
GetThreadDesktop
CloseDesktop
CreateWindowStation
OpenWindowStation
EnumWindowStations
CloseWindowStation
GetProcessWindowStation
Search for source files with findstr /s /g:temp.txt *.c *.cpp *.h *.hpp where temp.txt is the above
list of APIs copied to a text file. While not an exhaustive search, it will help to identify issues versus
minimizing false positives.
High DPI Scaling

Feature Impact
Low
Brief Description
On systems using the high dpi setting, applications that don’t natively understand high dpi will be
automatically scaled up.
Manifestation
Pixel sizes have been roughly constant for a long time, but LCD manufacturers are increasingly coming
out with monitors with smaller and smaller pixels, also known as high dots per inch (dpi). If an
application uses the same number of pixels on a high dpi screen as it does on a standard 96 dpi screen,
the application will look very small. Windows Vista and Windows Server 2008 introduce the ability to
scale applications that were written for 96 dpi screens, which they do by rendering the application’s
bitmap at a larger size. Like all bitmap scaling, this can result in some blurriness, but otherwise gives a
correctly sized and properly rendered image. Applications can also decide to support high dpi natively,
which will give the crispest possible look. Currently an application can turn off scaling & declare itself
dpi-aware by calling SetProcessDPIAware(). A manifest-based way to declare this is under
investigation. For more information about writing applications that natively support high dpi, see
http://msdn2.microsoft.com/en-us/library/ms969894.aspx .
The rest of this section talks about potential problems with non-DPI aware applications. Applications ask
Windows questions like "how many pixels wide is a scrollbar", so when a 96 dpi application asks,
Windows Vista and Windows Server 2008 give the application the 96 dpi answer. There are, however
cases where Windows doesn’t provide an answer based on the application, usually because Windows
Vista and Windows Server 2008 don't yet have enough information (please give us this feedback), and

sometimes because the “right” answer depends on what the application is trying to do with the answer.
(Screen coordinates often raise this problem.)
Most compatibility problems come from these imperfect conditions. Things to look for when testing:
 Text is clipped (partially hidden).
 Text is too big.
 Something is drawn at the wrong size or in the wrong place.
Remedies
For more information about writing applications that natively support high dpi, see
http://msdn2.microsoft.com/en-us/library/ms969894.aspx .
PNG Icons
Feature Impact
Low
Brief Description
The icon file format (*.ico) now supports PNG images in addition to the older BMP-style icons; many
Windows Vista and Windows Server 2008 icons use the PNG variant.
Manifestation
Applications that view or edit icon files may not understand the new format.

https://blogs.msdn.com/nickkramer/archive/2006/04/24/582365.aspx
Named Pipe Hardening
Brief Description
In Windows Vista and Windows Server 2008, many services are running under lesser privileged accounts
like NetworkService (NS) or LocalService (LS) rather than Local System. Service hardening is an initiative
to improve the compartmentalization between the services such that if one service is compromised, it
cannot easily attack other services on the system. Windows Vista and Windows Server 2008 harden the
named pipes used by RPC servers to prevent other processes from being able to hijack them.

Under Windows XP an RPC server creates a named pipe and the ACL on the pipe grants LocalService or
NetworkService Full Control. This includes the ability to create “server instances” of the pipe, so clients
can connect. The only process that should create instances of a pipe is the process that initially created
the pipe. Microsoft’s ACL change restricts the ability to create server instances to the process that
created the pipe initially.
Manifestation
The following services have been affected; Services that run as LocalService or NetworkService, services
that opt-in to using service Sids and services using RPC over named pipes that request the “default”
named pipe security descriptor.
Services that opt-in to using service Sids means no 3rd party service will be affected by default. Service
Sids is a new feature in Windows Vista and Windows Server 2008 that you have to opt-in by setting a
DWORD in your service configuration. When developers opt-in they have the opportunity to test with
the new service hardening behavior; this change would be one of those behaviors.
Services using RPC over named pipes that request the “default” named pipe security descriptor means
that if some RPC server is specifying a custom security descriptor because of special needs, they will see
no change. Below is a list of the affected Pipes:
Epmapper
Eventlog
Dav rpc
Keysvc
Winreg
Tapserv
W32time_alt
Termsvcapi
Ctx_winsta
Hydralspipe
SPAP Deprecation (Pstore)

Brief Description
Protected Storage (PStore) provides applications with an interface to store user data that must be kept
secure or free from modification. Pstore has been changed to read only in Windows Vista and Windows
Server 2008. This means that any application that tries to create new PStore data items without using
DPAPI will fail.
Remedies
Use DPAPI for future PStore procedures.


To learn more about the existing PStore items and use of DPAPI to manage them instead please read
http://msdn2.microsoft.com/en-us/library/ms995355.aspx
WMI Providers: Default Security Hosting Model
Brief Description
The Default HostingModel for WMI providers has changed from LocalSystem to NetworkServiceHost.
In previous releases of Windows (Pre-Windows Vista and Windows Server 2008 Beta2), if the
HostingModel of a WMI provider (__Win32Provider.HostingModel property) was unspecified, it was
defaulted to LocalSystem. Because LocalSystem is a highly privileged account, the WMI provider running
in this security context exposes the Operating System to a risk of elevation of privileges depending on
the provider code quality and testing.
For most cases LocalSystem is unnecessary and the NetworkServiceHost context is more appropriate.
This is especially true because most WMI Providers must impersonate (ImpersonationLevel=1) the client
security context to perform the requested operations on behalf of the WMI client.
Manifestation
If a WMI provider lacks a definition for hosting model and executes as if it is running under the
LocalSystem level, it will not run properly.
Remedies
The expected hosting model must be changed to ensure that the WMI provider code performs the
operations in the client security context by impersonating the WMI client. Cases that require the
LocalSystem security context are extremely rare; however, if LocalSystem is an absolute requirement,
specify the hosting model explicitly with the HostingModel=LocalSystemHost statement in the provider
MOF file.

Provider Hosting and Security
Volume Shadow Copy Service

Brief Description
The Volume Shadow Copy Service (VSS) is a new service that was introduced in Windows XP and
Windows Server 2003. It is a framework facilitating communication between applications, storage

subsystems, and storage management applications (including backup applications). This service defines,
persists, and exploits point-in-time copies of storage data.
Manifestations
Compatibility with XP backup applications
Several interfaces have changed since XP and the libraries are not compatible with Windows Vista and
Windows Server 2008. At a minimum the application will need to be recompiled using either headers or
libraries from VSS SDK 7.2 or from the Platform SDK released with Windows Vista and Windows Server
2008 Beta 2.
Compatibility with 2K3 SP 1 backup applications

Binaries from 2K3 SP1 are compatible with Windows Vista and Windows Server 2008. Most backup
applications would also need to account for the changes in the inbox writers, file and registry
virtualization, and WRP as well as the use of hard links in %windir%system32. This makes it unlikely that
a backup application from WS 2K3 SP1 would work as is.
Compiling backup applications for Windows Vista and Windows Server 2008
Applications that use interfaces available in Windows Server 2003 can be compiled using the headers
and libs provided in VSS SDK 7.2. To use new interfaces specific to Windows Vista and Windows Server
2008, recompile using the VSS headers and libs included in the Platform SDK for Windows Vista and
Windows Server 2008.
VSS writers
Registry Writer
The Registry writer now performs in-place backups and restores of the Registry as compared to the spit
writer scheme earlier. User hives are not reported by the Registry Writer.
COM+ RegDB Writer

This backs up the contents of %systemroot%\registration. COM+ depends on a registry key being
backed up and hence needs to be backed up and restored with the registry.
MS Search Writer
This deletes the search index from shadow copies after creation
MSDE Writer
This is the default writer for SQL 2000 and SQL 2005 databases.
WMI Writer
WMI VSS writer is used for backing up WMI specific states and data during backup operations. The data
includes files from the WBEM Repository and requires Registry Backup.

Background Intelligent Transfer Service (BITS) Writer

This uses the FilesNotToBackup reg key to exclude files from the directory
"%allusersprofile%\application\data\microsoft\network\downloader.
Automated System Recovery (ASR) Writer

The ASR writer stores the configuration of the disks on the system.
System Writer
On Windows Vista and Windows Server 2008 the System Writer will generate a list of files using the
following formula:
1. All static files that have been installed. These are identified by the attribute writeabletype =
“static “Or writeabletype is “” in the component manifest. This will include all WRP files,
additionally there may be some files marked as static that are not WRP. For example games are
static but not WRP so that administrators can change parental controls.
2. The WinSxS folder which includes all manifests, optional components and 3rd party Win32 files
3. All PnP Files for installed drivers (owned by PnP)
4. All User Mode Services and non PNP drivers
5. All Catalogs owned by CryptSvc
The files in %windir%\system32 are hard links to the winsxs directory.
The restore app is responsible for laying down files and registry and setting ACLs to match the system
snapshot. The appropriate hard links must also be created.
Microsoft Optimization Writer

This writer deletes certain files from the snapshots. The file deletions are done minimize Copy On Write
(COW) I/O during the snapshot maintenance phase and the files are typically temporary files or those
that do not constitute user or system state.

Volume Shadow Copy Service MSDN query
http://search.msdn.microsoft.com/search/default.aspx?siteId=0&tab=0&query=Volume+Shadow+Copy
+Service
Volume Shadow Copy Service Windows Vista MSDN query
http://search.msdn.microsoft.com/search/default.aspx?__VIEWSTATE=&query=Volume+Shadow+Copy
+Service+Vista&siteid=0&tab=0

Standard User Analyzer

Introduction
The “Standard User Analyzer” (previously known as the “LUA Analyzer”) is a tool to help independent
software vendors (ISVs), IT professionals, and end users diagnose possible issues in an application when
it is running as a standard user. The Standard User Analyzer is based upon the “LUA Predictor”
technology, which is part of the Microsoft Application Verifier.
Installation Prerequisites and Compatibility

Prerequisites
 Operating systems: Windows Vista and Windows Server 2008, Windows XP, and Windows
Server 2003.
Note: Currently, only a 32-bit version of the Standard User Analyzer is available.
 Installation prerequisites: The Application Verifier must be installed before the Standard User
Analyzer installation is launched. The Application Verifier is a free download on the Microsoft
Web site.
Installation
 To install the Standard User Analyzer, run the SUAnalyzer.msi file. All Standard User Analyzer
files are installed to the “Program Files\Standard User Analyzer” folder.
Note: Prior to using Standard User Analyzer, you must install the latest Application Verifier.
 Use the Standard User Analyzer to diagnose standard user compatibility issues within an
application.
Note: The Standard User Analyzer should be run on a Windows Vista or Windows Server 2008 computer
to properly identify an application’s standard user compatibility issues.
The following procedure is written to be performed by a standard user on a Windows Vista and
Windows Server 2008 computer:
1. Click Start, point to All Programs, and then double-click Standard User Analyzer.
2. On the App Info tab, in the Target Application field, enter the directory location of the target
application’s executable file or use the Browse function.
3. On the App Info tab, in the Parameters field, enter parameters for the application, if applicable.
4. On the App Info tab, select the Launch Elevated checkbox, and then click the Launch button.
5. If a User Account Control credential prompt appears for SUAnalyzerSrv.exe, provide
administrator credentials and click Submit.
6. In the User Account Control credential prompt for target application, provide administrator
credentials and click Submit.

Note: The SUAnalyzerSrv.exe process may request elevation while performing this procedure. This
process is a backend process that is responsible for managing tasks that require an administrator access
token, such as changing settings in the Application Verifier.
During the test, the Standard User Analyzer will launch the application, monitor its actions, and wait for
the application to be closed. The Standard User Analyzer will then generate and parse a log for the
application, which might take some time to complete. Once the log has been generated and parsed,
click on individual tabs to view specific issues found by Standard User Analyzer.
Tab Details
File Lists file system access issues.
For example, an application attempting to write to a file that normally only administrators can
access.
Registry Lists system registry access issues.

For example, an application attempting to write to a registry key under HKLM, which is a
location that normally only administrators can access.
INI Lists WriteProfile APIs issues.

WriteProfile APIs were originally used for 16-bit Windows but are still popular some modern
applications.
One example is the Calculator in Windows XP. If the view is changed from “Standard” to
“Scientific”, calc.exe calls WriteProfile API to write into windows\win.ini, which is only
writable by administrator users.
Token Lists access token checking issues.
If an application explicitly checks for the “Builtin\Administrators” security identifier (SID) in a
user’s access token, the application most likely will not work for a standard user.
Privilege Lists privilege issues.

For example, if an application explicitly enables “SeDebugPrivilege”, it will not work for a
standard user.
Name Space Lists issues that are caused when an application creates system objects (e.g. events, memory
mappings) in restricted namespace. Applications that have this error will not work for a
standard user.
Other Objects Lists issues related to accessing objects other than files and registry keys.
Figure 12: Standard User Analyzer Tab Details

When you click on an issue in any individual tab, the lower left panel of Standard User Analyzer will
display all related records from the log file; you can then click on any record, and the lower right panel
will display the detailed information for that record, including a formatted message, parameters, and

the stack trace. ISVs can use stack trace data to track down the problem in the application’s source
code.
Standard User Analyzer Main Menu

File menu:
 Open Log File: load a saved log file.
 Export Log File: save current log file.
 View Raw Log File: open the current log file in raw xml format. (Warning: if the file is big, it will
take a long time to open.)
 Exit: exit the program.
View menu:
 Choose what kinds of messages you want to display. Usually only view “error messages” is
necessary.
Options menu:
 Filter Noise: Toggle between display/hide entries that are “noisy”.
 Load Noise Filter File: Load a noise filter file.
 Export Noise Filter File: Save a noise filter file.
 Only Display Records with Application Name in StackTrace: This will reduce the noise; however
since the Standard User Analyzer only captures the first 32 stack frames, enabling this option
might filter out real issues if a call stack is deeper than 32 frames.
 Logging: Logging options. It is recommended that you leave the “Log Information” checkbox
unchecked in order to keep the log file from getting too large.
Help menu:
 Help menu.
DHTML Editing Control

The relevant documentation in the SDK on the built in editing capabilities of IE in 5.5
Overview and tutorials
Help Engine Support

Microsoft is committed to providing Help and Support technology in the Windows Platform and will
continue to investigate new solutions for software developers. The following information clarifies the

support in Windows Vista and Windows Server 2008 for four Microsoft Help technologies: Windows
Help, HTML Help 1.x, the Help and Support Center, and the Assistance Platform client.
Windows Help - WinHlp32.exe

Windows Help WinHlp32.exe is a help program that has been included with Microsoft Windows versions
starting with the Microsoft Windows 3.1 operating system. The Windows Help program (WinHlp32.exe)
is required to display 32-bit help content files that have the ".HLP" file name extension."
Windows Help is being deprecated for Windows Vista and Windows Server 2008. To view 32-bit Help
files with the .HLP file name extension in Windows Vista and Windows Server 2008, you will need to
download and install WinHlp32.exe from the Microsoft Download Center.
Microsoft strongly recommends that software developers discontinue using the Windows Help
application in Windows Vista. Software developers who ship programs that rely on .HLP files are
encouraged to transition their Help experience to an alternative Help file format, such as CHM, HTML, or
XML. You will also need to change your calls from the WinHelp() API to the new content source. Several
third-party tools are available to assist authors in converting content from one format to the other.
HTML Help 1.x (HH.exe)

Microsoft HTML Help 1.x (HH.exe) is a Help system included in Windows releases starting with Windows
98. HTML Help is required to display compiled Help files with the .CHM file name extension.
HTML Help will ship in Windows Vista and Windows Server 2008. However, only critical updates to the
engine will be made. No new features or feature improvements will be added to the HTML Help engine
for Windows Vista and Windows Server 2008 or future Windows releases.
For more information about the functionality of HTML Help and guidance on authoring files for HTML
Help, see the Help 1.4 SDK (http://msdn2.microsoft.com/en-us/library/ms670169.aspx) site.
Help and Support Center (HelpCtr.exe)

The Help and Support Center (HelpCtr.exe) was a Help application designed for Windows XP and
Windows Server 2003. The Help and Support Center displayed compiled Help files with the .CHM file
name extension.
The Help and Support Center is not included in Windows Vista and Windows Server 2008 and its
features are not supported. Compiled Help files with the .CHM file name extension will only be displayed
in the HTML Help application as described above.
Assistance Platform Client (HelpPane.exe)

The Assistance Platform client (HelpPane.exe) is a new Help engine designed for Windows Vista and
Windows Server 2008. It is not compatible with any previous versions of Windows. The Assistance
Platform client is required to display Help files with the .H1S file name extension.

In Windows Vista and Windows Server 2008, the Assistance Platform client can be customized by OEMs,
system builders, and enterprise customers under license agreement, but cannot be used by third-party
programs. For more information on customizing the Assistance Platform client, see the Windows SDK.
Junction Points and Backup Applications

In Windows Vista and Windows Server 2008 the default location of user data has changed. An example
of this change is the Documents and Settings directory which has been moved from
“%systemdrive%\Documents and Settings” to “%systemdrive%\Users”. To enable interoperability with
legacy apps junction points are used at the deprecated locations and point to the new locations in
Windows Vista and Windows Server 2008. For example C:\Documents and Settings is now a junction
point which points to C:\Users. Backup application in Windows Vista and Windows Server 2008 must be
capable of restoring junction points.
These junction points have file attributes of FILE_ATTRIBUTE_REPARSE_POINT &
FILE_ATTRIBUTE_SYSTEM and the ACL’s are set to “Everyone Deny Read”. Applications must have
permissions in order to call out and traverse a specific path. However, enumerating the contents of
these junction points is not possible.
Classes of Junction Points

There are two Categories of Directory junctions that can be created by profiles for application
compatibility in Windows Vista and Windows Server 2008.
1. Per user junctions: These are junctions that will be created inside each individual user’s profile
to provide application compatibility for the old legacy namespace.
a. i.e. Junction from C:\Users\<username>\My Documents to
C:\Users\<username>\Documents
b. These junctions will be created by the Profile service when the users profile itself is
created
2. System Junctions: These represent all the other junctions created on the system and are not
beneath the <username> node:
a. This includes junctions for:
i. Documents and Settings
ii. Junctions within the All User, Public, Default User profiles
b. These junctions will be created by userenv.dll when invoked from Machine OOBE on the
Windows Vista and Windows Server 2008 PC.
Figure 13: Parent Folder Junction Requirements
Directory Junction Creation Location Destination
..\Documents and Settings\ ..\Users\

Figure 14: User Data Legacy Folder Junction Requirements
Directory Junction creation location Destination

..\Documents and Settings\<username\ ..\Users\<username>\Documents
My Documents
..\Documents and Settings\<username>\ ..\Users\<username>\Music

My Documents\My Music
..\Documents and Settings\<username>\ ..\Users\<username>\Pictures

My Documents\My Pictures
..\Documents and Settings\<username>\ ..\Users\<username>\Videos

My Documents\My Videos
Figure 15: Per User Application Data Legacy Folder Junction Requirements

..\Documents and Settings\<username>\ ..\Users\<username>\AppData\Local
Local Settings\
..\Documents and Settings\<username>\ ..\Users\<username>\AppData\Local

Local Settings\Application Data
..\Documents and Settings\<username>\ ..\Users\<username>\AppData\Local\Microsoft\

Local Settings\Temporary Internet Windows\Temporary Internet Files
Files
..\Documents and Settings\<username>\ ..\Users\<username>\AppData\Local\Microsoft\

Local Settings\History Windows\History
..\Documents and Settings\<username>\ ..\Users\<username>\AppData\Roaming

Application Data\
Figure 16: Per User OS Settings Legacy Folder Junction Requirements

..\Documents and Settings\<username>\ ..\Roaming\Microsoft\Windows\Cookies
Cookies\
..\Documents and Settings\<username>\ ..\Roaming\Microsoft\Windows\Recent

Recent\
..\Documents and Settings\<username>\ ..\Roaming\Microsoft\Windows\Network Shortcuts

Nethood\

..\Documents and Settings\<username>\ ..\Roaming\Microsoft\Windows\Printer Shortcuts

Printhood\
..\Documents and Settings\ ..\Roaming\Microsoft\Windows\Send To

<username>\SendTo\
..\Documents and Settings\ ..\Roaming\Microsoft\Windows\StartMenu

<username>\StartMenu\
..\Documents and Settings\ ..\Roaming\Microsoft\Windows\Templates

<username>\Templates\
Figure 17: Legacy Profile Folders where Junctions Are Not Required
Legacy Location Reasoning

..\Documents and Covered by the junction at ‘Documents and Settings’
Settings\<username>\Desktop
..\Documents and Covered by the junction at ‘Documents and Settings’

Settings\<username>\Favorites
..\Documents and Settings\<username>\ Covered by the junction for the Local Settings folder to
Local Settings\Temp Local.
Figure 18: All Users Legacy Folder Junction Requirements
Sym links creation location Destination

..\Users\All Users ..\ProgramData
Figure 19: User Junction Points

..\ProgramData\Desktop ..\Users\ Public\Desktop
..\ProgramData \Documents ..\Users\Public\Documents
..\ProgramData \Favorites ..\Users\Public\Favorites
..\Users\Public\Documents\My Music ..\Users\Public\Music
..\Users\Public\Documents\My Pictures ..\Users\Public\Pictures
..\Users\Public\Documents\My Videos ..\Users\Public\Videos
..\ProgramData\Application Data\ ..\ProgramData

..\ProgramData\Start Menu\ ..\ProgramData \Microsoft\Windows\StartMenu
..\ProgramData\Templates\ ..\ProgramData \Microsoft\Windows\Templates
Figure 20: Default Users Legacy Folder Junction requirements

..\Documents and Settings\Default User ..\Users\Default
..\Documents and Settings\Default User\ ..\Users\Default \Desktop

Desktop
..\Documents and Settings\Default User\ ..\Users\Default \Documents

My Documents
..\Documents and Settings\Default User\ ..\Users\Default \Favorites

Favorites
..\Documents and Settings\Default User\ ..\Users\Default \Music

My Documents\My Music
..\Documents and Settings\Default User\ ..\Users\Default \Pictures

My Documents\My Pictures
..\Documents and Settings\Default User\ ..\Users\Default \Videos

My Documents\My Videos
..\Documents and Settings\Default User\ ..\Users\Default \AppData\Roaming

Application Data\
..\Documents and Settings\Default User\ ..\Users\Default \AppData\Roaming\Microsoft\

Start Menu\ Windows\StartMenu
..\Documents and Settings\Default User\ ..\Users\Default \AppData\Roaming\

Templates\ Microsoft\Windows\Templates
Figure 21: Program Files Junction Points

..\Program Files (Localized name) ..\Program Files
..\Program Files\Common Files (Localized

Name) ..\Program Files\Local Files

Application Compatibility for Backup and Recovery

Introduction
There are several changes in Windows Vista and Windows Server 2008 that affect the compatibility of
backup applications. This document addresses those issues and specific requirements concerning those
changes. This section is intended for backup application developers who are familiar with the Volume
Shadow Copy Service (VSS) infrastructure and Windows backup procedures. Some of these features or
changes may not be an issue, but vendors should verify that they are not impacted or that they have
suitable mitigations in place. This document does not get into exhaustive details of the features and
touches primarily on the impact to backup tools. For details on a specific topic follow the links listed at
the end of this section or look on MSDN.
Compatibility with Windows XP Backup Applications

Several interfaces have changed since Windows XP, and those libraries are not compatible with
Windows Vista and Windows Server 2008. At a minimum applications will need to be recompiled using
either headers or libraries from the Microsoft Volume Shadow Copy Service SDK 7.2 (VSS SDK 7.2) or
from the Windows Vista and Windows Server 2008 Platform SDK.
Compatibility with Windows Server Service 2003 Service Pack 1 Backup

Applications
Binaries from Windows Server 2003 SP1 are compatible with Windows Vista and Windows Server 2008.
Most backup applications would also need to account for the changes in the inbox writers, file and
registry virtualization, WRP as well as the use of hard links in %windir%system32. Therefore these
changes will need to be addressed for Windows Server 2003 SP1 backup applications to function under
Compiling Backup Applications for Windows Vista and Windows Server 2008
Applications that use interfaces available in Windows Server 2003 can be compiled using the headers
and libraries provided in VSS SDK 7.2. In order to use new specific Windows Vista and Windows Server
2008 interfaces, the user would need to compile the application using VSS headers and libraries included
in the Platform SDK for Windows Vista and Windows Server 2008. Note that Binaries compiled using
Windows Vista and Windows Server 2008 headers and libraries will not run on Windows Server 2003.
Interoperability with Transactions

Windows Vista and Windows Server 2008 includes support for transactions and VSS ensures that both
the Kernel Transaction Manager (KTM) and Distributed Transaction Coordinator (DTC) are frozen prior to
the creation of snapshots. This leads to two new timeout errors.
VSS_E_TRANSACTION_FREEZE_TIMEOUT

VSS_E_TRANSACTION_THAW_TIMEOUT
In case the requestor receives either of these errors it must retry snapshot creation. Registry and file
system operations may also be transacted. In the case of the registry, the registry writer ensures
transactional consistency. Transactional consistency of NTFS operations is ensured by mounting the
shadow copy read/write after creation and then rolling pack partially committed operations.
Integrating with the Search the Internet Feature

Overview
Windows Vista and Windows Server 2008 have a new feature that allows users to easily search the
internet from the start menu. This works by the user clicking on the “Search the Internet” option after
entering text into the start menu search bar. To implement the Search the Internet feature Windows
Vista and Windows Server 2008 invoke the application that is the default for the HTTP:// protocol and
appends an argument with the search term.
Extensibility
Below outlines how an application can correctly handle being invoked from the Search the Internet
feature.
 Windows Vista and Windows Server 2008 enable users to launch an Internet Search directly
from the Start Menu search box.
Figure 22: Start Menu Search Box

 When a user clicks on the “Search the Internet” link (see Figure 1.1), Windows Vista and
Windows Server 2008 determines the default program for the http protocol by calling the
AssocQueryString function with the following parameters
AssocQueryString(NULL, ASSOCSTR_EXECUTABLE, L"http", L"open", szBrowser, &cch)
where szBrowser contains the location of the executable file of the browser currently registered.

Figure 23: Windows Live Search

Windows Vista and Windows Server 2008 then call ShellExecuteEX to launch this program and pass "?
<search term>" as the lpParameters argument, where <search term> is replaced with the contents of
the search box. This is roughly equivalent to appending "? <search term>" to the browser's command
line.
Each browser must determine what to do with the passed parameter. The recommended way to
handle the parameter is to pass the search string directly to the browsers default search handler. For
example, in Figure 23, Windows Vista and Windows Server 2008 has launched the Internet Explorer
browser with the search term “Hello World”. Internet Explorer passes the term directly to the default
search handler for Internet Explorer.
Any browser can take advantage of this functionality. For example, assume that the Contoso Internet
Browser has been registered as the default http protocol handler. The executable for this browser is
located at C:\Program Files\Contoso\contoso.exe. A call to AssocQueryString(NULL,
ASSOCSTR_EXECUTABLE, L"http", L"open", szBrowser, &cch) will result in szBrowser containing the path
of the exe file. ShellExecuteEX will use this information to launch the Contoso browser and pass it "?
Hello World".
To handle this correctly, a browser’s must executable must be able to handle being passed an argument
with quotations that is pre-pended with a question mark. Below are 2 examples of an executable
handling the search parameter being passed.
Internet Explorer:

C:\Program Files\Internet Explorer\iexplore.exe "? <search term> "

C:\Program Files\Internet Explorer\iexplore.exe "? Hello World"
Contoso Browser:
C:\Folder\contoso.exe "? <search term> "
C:\Folder\contoso.exe "? Hello World"

Backup and Recovery compatibility in Windows Vista and Windows Server 2008
MMCs Must Be Data Execution Protection (DEP) Aware

Feature Impact
Moderate
Brief Description
MMC.EXE always runs with DEP (Data execution protection) enabled. Snap-ins must be DEP aware. This
feature cannot be turned off, and no compatibility mode exists.
Manifestation
Snap-ins that are not DEP aware may cause a failure to load within MMC or not work properly.
Remedies
This feature cannot be turned off, and no compatibility mode exists.
Networking: Turning off the Windows Firewall

Feature Impact
High
Brief Description
In order to avoid the situation where a user–installed firewall (which is compatible with Windows XP but
is incompatible with Windows Vista and Windows Server 2008) attempts to turn off the Windows
Firewall in Windows Vista and Windows Server 2008, Microsoft has deprecated the Windows Firewall XP
SP2 INetFwProfile.put_FirewallEnabled(VARIANT_FALSE) function in Windows Vista and Windows Server
2008. When called on Windows Vista and Windows Server 2008, this function will
1. Return an error code of E_NOTIMPL

2. Show a message to the user

3. Log an appropriate event in the Windows event log.
Manifestation
Applications using the Windows XP SP2 INetFwProfile.put_FirewallEnabled(VARIANT_FALSE) function to
turn-off the Windows Firewall on Windows Vista and Windows Server 2008 will receive an error code.
Remedies
Applications (typically firewalls) replacing the Windows Firewall with their own firewall solution, must
carefully consider the following security-related points:
 Windows Vista and Windows Server 2008 support IPv6 and IPv4 out-of-the-box and will
automatically have an IPv6 address; therefore, it is essential that your firewall solution filters
BOTH IPv4 & IPv6.
 Windows Vista and Windows Server 2008 also support additional IP protocols (e.g., GRE, L2TP,
PGM & ICMPv6); therefore, it is essential that your firewall solution filters arbitrary protocol
filtering (IANA Protocol 0-255) & ICMP type and code filtering.
 In Windows Vista and Windows Server 2008 there are listening processes in both user mode and
Kernel mode (i.e., system process, http.sys, smb.sys); therefore, it is essential to filter BOTH
User mode and Kernel mode network traffic.
Microsoft further recommends that these applications:
 Do not replace the Windows Firewall unless your application addresses all of the security-
related points specified above.
 Check the firewall status before your application turns-off or disables Windows Firewall with
Advanced Security so that it can be restored later if necessary.
 Do not turn off the firewall service (mpssvc) since this is the service that enforces Windows
Service Hardening restrictions. Instead, use the Windows Firewall API’s to modify the firewall
state to “OFF” so that the firewall is effectively disabled but the Windows Service Hardening
restrictions are still in place.
To protect users, you should only disable Windows Firewall with Advanced Security after: (1) you have
successfully turned on your firewall solution with the recommended settings; and (2) you have notified
the user that Windows Firewall with Advanced Security is going to be disabled.

Windows Firewall with Advanced Security Reference

Additional resources:
http://blogs.technet.com/all_things_appcompat/
Windows Vista Development Center
WWW.Devreadiness.org
Videos
Virtual Labs
Windows Vista Readiness Virtual Lab
Feature Intros:
Application Compatibility with Hatem Zeine - Watch Video
Application Toolkit with John Melton - Watch Video
Error Reporting with Jeff Braunstein and Jason Hardester - Watch Video
Introduction to Default Programs with Ed Averett - Watch Video
Kernel Mode Signing with Ramesh Chinta - Watch Video
Networking with Neeraj Garg - Watch Video
Windows Filtering Platform w/ Madhurima Pawar & Salahuddin Khan - Watch Video
Windows Resource Protection with RoseMarie FitzSimons - Watch Video
Windows Vista Logo Programs with Brad Sullivan & Venkat Krishnamachari - Watch Video,
Watch Video
User Account Control with Chris Corio - Watch Video
Windows Vista and Windows Server 2008: Understanding, Enhancing, and Extending Security
Videos
Part 1: Watch Video (23:23 minutes)

Issues Relevant to Windows Server 2008

The remainder of this document contains items that are applicable only to Windows Server 2008 and
not to Windows Vista.
Read Only Domain Controllers (RODC)

Feature Impact
Moderate
Brief Description
A Read Only Domain Controller is a new type of domain controller in the Windows Server 2008
operating system. With an RODC, organizations can easily deploy a domain controller in locations where
physical security cannot be guaranteed. An RODC hosts a read-only replica of the database in
Active Directory® Domain Services (AD DS) for a given domain.
Before the release of Windows Server 2008, if users had to authenticate with a domain controller over a
wide area network (WAN), there was no real alternative. In many cases, this was not an efficient
solution. Branch offices often cannot provide adequate physical security that is required for a writable
domain controller. Furthermore, branch offices often have poor network bandwidth when connected to
a hub site. This can increase the amount of time required to log on; it can also hamper access to
network resources.
Beginning with Windows Server 2008, an organization can deploy an RODC to address these problems.
As a result, users in this situation can benefit from:
 Improved security
 Faster logon times
 More efficient access to resources on the network
Manifestation
Any application that writes to the Active Directory is potentially impacted by RODCs, and may see
compatibility issues involving failed writes, or failed reads of newly written data.
Remedies
Applications which write data may locate a DC using methods which do not differentiate between
writable and read-only DCs.
There are two methods that applications typically use to request the nearest domain controller:

• Serverless binding, as recommended in Binding to Active Directory Domain Services

(http://go.microsoft.com/fwlink/?LinkId=67636)
• Domain controller Locator calls
In Windows Server 2008, a domain controller Locator call can return any domain controller. This
includes a domain controller running Windows 2000 Server or Windows Server 2003, or a writable or
read-only domain controller running Windows Server 2008.
Problems can occur if an application needs to write to directory objects and it gets an RODC from calling
a serverless bind. In that case, the write operations are referred to a writable domain controller running
Windows Server 2008 at the hub site. Depending on the WAN connection to the hub site at that time,
the application can fail to connect to the hub and can report errors. The application must also correctly
handle these referrals. Even if the write operation succeeds, any subsequent reading of the data that
was just written might fail. This is because of inherent latency that is required to replicate this data back
to the RODC.
Applications which must run on a DC, should be aware of RODCs.

Applications that must run on a domain controller must determine if the domain controller is writable or
if it is an RODC. Checking the registry or using OSVERSIONINFOEX, as discussed in OSVERSIONINFOEX
(http://go.microsoft.com/fwlink/?LinkId=67637), does not distinguish an RODC from a writable domain
controller. An RODC still advertises itself as a domain controller.
To determine this, check the supportedCapabilities attribute on the rootDSE. For more information, see
Serverless Binding and RootDSE (http://go.microsoft.com/fwlink/?LinkId=67638). The presence of object
identifier value 1.2.840.113556.1.4.1920 indicates that the specified domain controller is an RODC.
You can also use the DsRoleGetPrimaryDomainInformation function to determine if the domain
controller is an RODC. A new flag has been added to the DSROLE_PRIMARY_DOMAIN_INFO_BASIC
structure. The following table describes the new flag.

Detailed Compatibility Article (see Appendix C):

http://technet2.microsoft.com/windowsserver2008/en/library/ea8d253e-0646-490c-93d3-
b78c5e1d9db71033.mspx?mfr=true
Active Directory chat:

http://www.microsoft.com/technet/community/chats/trans/windowsnet/06_0222_tn_active.mspx
Windows Server 2008 Active Directory:
http://www.microsoft.com/technet/technetmag/issues/2006/11/FutureOfWindows/default.aspx
Windows Server 2008 Roles

Feature Impact
Low
Brief Description
Windows Server 2008 is now completely componentized. The roles for Windows Server 2008 are now
highly granular and optional. By default, no server roles are activated. Server roles from prior versions of
Windows Server are not exactly the same in Windows Server 2008.
Web Server and Application Server which were one role in Win2k3 and are now split into two roles for
Windows Server 2008.
Manifestation
Installation instructions and scripts may break or produce improper results.
Remedies
Installation instructions and scripts to install new servers will have to be updated.

Product guide: http://www.microsoft.com/windowsserver/longhorn/prodguide.mspx
Webcast: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032297520&Culture=en-US
Installing and Managing Roles:
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032294712&Culture=en-US

Windows Application Experience in Windows Server 2008

Feature Impact
Low
Brief Description
Windows Server 2008 does not, by default, install applications and accessories that are considered to be
part of a user’s desktop experience. These applications can be selectively installed using Server
Manager.
Manifestation
Applications and Installers that rely on windows desktop applications and accessories may fail to run or
install. Desktop accessories and tools have been removed into a separate feature install since most
users of Windows Server do not need desktop applications.
Remedies
Applications dependent upon desktop accessories and tools will need to ensure that they are installed
prior to application installation.
Windows Server 2008 Server Core

Feature Impact
Low
Brief Description
Windows Server 2008 introduces a new concept called Server Core. Server Core is a minimal server
installation option for computers running on the Windows Server 2008 operating system. Server Core is
available for x86 and x64 (note: not Itanium).
Server Core provides a low-maintenance server environment with limited functionality. The server core
supports a limited set of roles. Currently, Server Core supports the following roles:
 DHCP
 DNS
 Active Directory Domain Controller (including RODC)
 Active Directory LDS (formerly ADAM)
 File Server, including:
o DFSR (formerly FRS)
o NFS
o File quota

 Print Server
 Media Services
 Windows Virtualization
 IIS 7.0 (note: no support for ASP.NET and no remote Administration)
Server Core supports the following functionality:
 WINS
 Failover Clustering
 Subsystem for UNIX-based applications
 Backup
 Multipath IO
 Removable Storage Management
 Bitlocker Drive Encryption
 SNMP
 Telnet Client
 (S)NTP
Server Core is remotely manageable via:

 Terminal Server with a command prompt shell
 MMCs for supported components and Server Roles, e.g. Event Viewer and DNS
 WS-Management using ShellExecute – Beta 2
It also does not support .NET functionality; however, it does support development of management
tools, utilities, and agents.
Since Server Core is new, it has little impact on current applications. Understanding the limitations of
Server Core is imperative to proper implementation for maximum benefit. There is no upgrade path
from a downlevel version of Windows Server to Server Core, only a clean install is supported. There is
also no way to upgrade Server Core to Server with the gui shell, this requires a reinstallation.
To determine from the CommandLine if ServerCore is running :

WMIC path win32_operatingsystem get OperatingSystemSKU /value
12 Datacenter Server Core Edition
13 Standard Server Core Edition
14 Enterprise Server Core Edition Since Server Core is new, it has little impact on current applications.
Understanding the limitations of Server Core is imperative to proper implementation for maximum
benefit.


Windows Server 2008 Server Core
DLL’s included with Server Core
Windows Server Failover Clustering on Windows Server 2008
Feature Impact
Low
Brief Description
The existing Cluster API’s have remained largely the same as in Windows Server 2003. A dozen or so
new ones have been added, such as CreateCluster(), DestroyCluster(), AddClusterNode(),
EvictClusterNode(), SetClusterQuorumResource(), and SetClusterResourceDependencyExpression() to
name a few. The only ones that have been completely removed are BackupClusterDatabase() and
RestoreClusterDatabase(). You now need to use the new Cluster VSS Writer to perform backups and
restores of the cluster configuration.
The Cluster Automation Server (MSClus) COM interface is being deprecated, so none of the new API's
are exposed through MSClus. MSClus will still be there for Windows Server 2008, but it will be removed
in a future release. The recommendation is to stay away from writing new code leveraging it. In
Win2008 there now is full parity between the Cluster API and the WMI provider MSCluster.
http://msdn2.microsoft.com/en-us/library/aa372876.aspx
A new control code has been added that will be of interest if you have a storage class resource. It is
called CLUSCTL_RESOURCE_STORAGE_GET_DISK_INFO_EX
Finally, backward compatability has been broken. This means you can’t call Cluster API's from a
Win2008 Cluster to a downlevel cluster (NT4 / Win2k / Win2003). And the same you can’t be on a
downlevel client and remotely call Cluster API's against a Win2008 node. But this does not affect code
running on a Win2008, so in general your code should just work.
Manifestation
Applications that use BackupClusterDatabase and RestoreClusterDatabase will no longer function when
used on a Windows Server 2008 Cluster.

Remedies
Applications that use the API mentioned above will have to be re-engineered for backup and restore.

Cluster Automation Server (MSClus)
Server Cluster Provider (WMI)
Volume Shadow Service
Networking: Windows Firewall Enabled by Default on Windows Server

2008
Feature Impact
Moderate
Brief Description
Windows Firewall is on by default: This means that the application installers need to be aware of the
ports that the application uses so that these firewall ports are explicit opened, or to turn off Windows
Firewall (recommended only if another firewall is installed).
On Server, Server Roles and Optional Components are aware of the firewall and will plumb firewall rules
automatically upon installation. Conversely, the same components and roles will remove their firewall
rules when they are uninstalled.
Manifestation
Legacy application installers may break because dependent TCP/IP ports will not be open by default.
Legacy applications may break after installation because dependent TCP/IP ports will not be open by
default. On Windows Vista, client applications will prompt the user for a decision to Allow or to Keep
Blocking the application. On Server, there’s no such prompt. Instead, a Security audit event is logged to
signal that an application was blocked.
Remedies
For legacy application installers, the ports need to be explicitly opened by an administrator, or turn
Windows Firewall off.
Administrators can leverage:
 The ‘netsh advfirewall’ context to work with firewall rules from scripts.
 Security Configuration Wizard templates to configure their Servers only

Developers can leverage:
 The INetFwPolicy2 Firewall APIs to integrate their installers with the Windows Firewall with
Advanced Security

INetFwPolicy2 on MSDN
Unattended Installation Settings Reference


Windows Server 2008 and Vista Cookbook

Uploaded by

Document Information

Original Title

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

Windows Server 2008 and Vista Cookbook

Uploaded by

Copyright:

Available Formats

MICROSOFT

Windows Vista® and

© 2007 Microsoft Corporation. All rights reserved.

Application Compatibility Group| Page 2

Application Compatibility Group| Page 3

Volume Shadow Copy Service..................................................................................................................... 54

Application Compatibility Group| Page 4

Figure 11: Values of the Scenario ID ........................................................................................................... 47

Application Compatibility Group| Page 5

Application Compatibility Group| Page 6

Quick Compatibility Check

Working with a clean installation of Windows Vista

Working with an upgrade to Windows Vista from Windows XP Service Pack 2

Application Compatibility Group| Page 7

Links to Other Resources

Operating System Versioning

Application Compatibility Group| Page 8

User Account Control

Application Compatibility Group| Page 9

Leverage Windows Vista and Windows Server 2008 capability solution

Application Compatibility Group| Page 10

Links to Other Resources

UAC – Application Update Guidelines

Application Compatibility Group| Page 11

Multi-purpose executables/In-process updates

Application Compatibility Group| Page 12

2. Using other custom installer mechanisms

Links to Other Resources

Application Compatibility Group| Page 13

UAC – COM Per-User Configuration

Links to Other Resources

Windows Resource Protection (WRP)

Application Compatibility Group| Page 14

Application Compatibility Group| Page 15

WRP Protected Keys

How to recognize whether a resource is WRP

Application Compatibility Group| Page 16

Links to Other Resources

Internet Explorer Protected Mode

Application Compatibility Group| Page 17

Figure 1: IE Protected Mode Compatibility Architecture

 %userprofile%\LocalSettings\Temporary Internet Files\Virtualized

Leverage Windows Vista and Windows Server 2008 capability solution

Application Compatibility Group| Page 18

Links to Other Resources

Application Compatibility Group| Page 19

Links to Other Resources

Application Compatibility Group| Page 20

 Metabase changes (backup/restore; import/export)

Deprecated components in IIS

Application Compatibility Group| Page 21

Links to Other Resources

Application Compatibility Group| Page 22

Microsoft Graphical Identification and Authentication (GINA)

Application Compatibility Group| Page 23

Links to Other Resources

 Services that create UI

Application Compatibility Group| Page 24

Leverage Windows Vista and Windows Server 2008 capability solution

Links to Other Resources

Application Compatibility Group| Page 25

Making a Remote Procedure Call

Networking: TCP/IP Stack and the Windows Filtering Platform