Export (0) Print
Expand All

Application Compatibility Testing

Published: November 19, 2004
On This Page

Introduction
Implementing a Deployment Roadmap
Understanding Compatibility Issues
Summary

Introduction

Chapter 1 of this guide covered the new security features that Windows XP SP2 implements. This chapter describes an approach to testing for specific application incompatibilities that these new features may bring.

Implementing a Deployment Roadmap

Figure 2.1 provides a recommended path for deploying Windows XP SP2. The first section of this chapter covers these phases in order.

ACXPSP03.gif

Figure 2.1 Phases involved in testing for application testing for compatibility with Windows XP SP2

Prioritizing Systems for Upgrade

Initially, an organization must decide on how to prioritize the computers that require the service pack. This prioritization process uses one of the following two approaches:

  • Deploy the service pack to the most valuable systems first. The most valuable systems are running the most critical applications to the business, so application compatibility issues on these systems are crucial.

  • Deploy the service pack to the most common or generic systems in the organization. These computers run standard business applications and are therefore likely to have fewer application compatibility issues.

The second approach allows an organization to deploy Windows XP SP2 more quickly to a larger number of systems and so reduces the overall attack surface of the organization in a shorter time. Using inventory management software, such as Systems Management Server (SMS), may help with this process.

Determining High Value Computers

The easiest way to define the most valuable computers is to consider the cost to the organization from system downtime. For example, every minute that a trading application for a financial institution is unavailable may cost the business hundreds of thousands of dollars. Large organizations understand this and usually have backup systems in place. However, a small law firm may have a single computer running the accounting software or the business-critical case management and billing application. The loss of these systems could force the company out of business. For more statistics on data loss and business failure, see the Boston Computing Web site at http://www.bostoncomputing.net/consultation/databackup/statistics/

The vulnerability to attack of these high value systems needs to be assessed. For example, they may not be connected to the Internet or they may already be locked down with restricted physical access and may therefore be less vulnerable. However, any system with e-mail and Internet access is vulnerable and will benefit from Windows XP SP2.

Carefully managing the deployment of Windows XP SP2 to high value computers is critical to minimize downtime. Unless these systems are tested to ensure application compatibility, a Windows XP SP2 deployment may cause disruption to the business if applications do not meet the more stringent security settings.

Determining Generic Systems

An organization may specify the goal of deploying Windows XP SP2 to as many seats as possible in a short time frame. This approach ensures that the majority of desktop computers enjoy the enhanced security features of Windows XP SP2 within a short time frame, which reduces the overall attack surface of the organization. These generic systems are more likely to have access to the Internet, run e-mail software, and have fewer security-aware users. Hence, targeting generic systems first is the recommended approach for most organizations.

Prioritizing Applications

When you have prioritized your computers, you need to identify the applications these systems are running. SMS 2003 can provide this information and is particularly suitable for larger organizations. An alternative approach is to use the ACT, because ACT can identify the applications installed on networked computers and can create and distribute custom compatibility fixes.

After application identification is complete, you can consider the order for testing systems. There are a number of different factors to consider when prioritizing applications for compatibility testing. These factors are:

  • Importance to business

  • Number of users

  • Likelihood of compatibility issues

  • Vulnerability of the application to attack

Note: Many vendors have worked with Microsoft and have tested the effects of Windows XP SP2 on their applications. Microsoft advises you to contact your vendor and check if they have any information concerning their applications and compatibility with Windows XP SP2.

Selecting Test Systems

Organizations with a defined methodology for deploying software always test software updates, such as service packs or hotfixes, before deploying them to production computers. Because Windows XP SP2 implements a significant number of new security features, this pre-deployment testing is essential to identify deployment options and compatibility issues.

Note: It is recommended that organizations that do not have a test procedure implement one prior to deploying Windows XP SP2, even if testing means installing on a single computer prior to deploying across the network of the organization. This recommendation applies even to smaller organizations because it is a valuable investment that can be easily used again in the future.

Testing of each application should ideally take place on each system configuration within your organization. To do this, a test system is created for each client configuration. The application is then tested in the same local environment in which it is to be used.

Many organizations have a pilot or test lab where they test system deployments and create baseline standards. Remote Installation Services (RIS) or disk imaging software can then be used to deploy those baseline systems.

For more information about Remote Installation Services, see the Microsoft Web site at:

http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/Windows/XP/all/reskit/en-us/prbc_cai_byil.asp

If an image of each client build is not available, you have to build the client system manually for testing purposes. This build process must be repeated for each client configuration.

Organizations that do not currently have a testing environment can use virtual machine software such as Microsoft Virtual PC 2004. A single host computer can run multiple virtual PCs to create several application test environments. Virtual PC also gives the option to accept or reject writes to the disk, which enables simple rollbacks at the end of the test run. Whether you use disk images or Virtual PCs, maintain a read-only copy of the disk image for quick duplication and rollback.

For more information about Microsoft Virtual PC 2004, see the Microsoft Web site at:

http://www.microsoft.com/windows/virtualpc/default.mspx

Table 2.1 shows the suitability for the various testing mechanisms for Windows XP SP2 with different sized organizations.

Table 2.1 Suitability Matrix for Application Test Options

Platform

Small(up to 50 Users)

Medium(50-500)

Large(500+)

RIS

 

Non-Microsoft disk imaging software

Microsoft Virtual PC 2004

 

Creating or Obtaining Baseline Images

Many organizations use baseline disk images in conjunction with RIS to deploy desktop operating systems. Organizations that use this technique are well placed to test the effect of Windows XP SP2 in their environment, because it is likely that they have only a few possible operating system configurations. Organizations that do not use baseline images or any disk imaging system need to test a representative range of system configurations for application compatibility.

The Microsoft Solution Accelerator for Business Desktop Deployment includes information on deploying systems using imaging technology.

For more information about Microsoft Solution Accelerator for Business Desktop Deployment, see the Microsoft Web site at:

http://www.microsoft.com/technet/desktopdeployment/bddoverview.mspx 

Testing Applications Individually and Together

It is recommended that the initial testing platform has Windows XP with SP2 installed together with relevant applications. The platform should, where possible, mirror systems deployed in your organization with regard to processor speed and memory configuration.

It may also be useful to mirror the testing on a representative pre-Windows XP SP2 computer to ensure that the issue does not exist on a pre-Windows XP SP2 build.

When the test environment is set up and configured, you can run a series of tests. First, run each application separately, identifying and documenting any issues. Then, run the applications together in typical combinations and identify and document any issues caused by multiple applications.

Note: When testing multiple applications, monitor memory usage on the test platform. This is because low free memory can cause spurious application errors that are not related to compatibility with Windows XP SP2.

Creating a Recovery Process

During the testing phase, you should plan and test a recovery process for deploying Windows XP SP2. This recovery process is most important when you deploy the service pack onto your high value computers. Windows XP SP2 includes a rollback option that uninstalls the service pack. However, your recovery process planning should cover scenarios where the computer fails to restart after the upgrade, which would make a restore from a backup or rebuild necessary. Although this is an unlikely outcome, you should be able to perform a full system restore in the event of an unsuccessful upgrade. For more information about Back up and Restore, see the Microsoft Web site at

http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/Windows/XP/all/reskit/en-us/prdg_dsm_htwo.asp

Implementing a Mitigation Strategy

When testing applications with Windows XP SP2, it is recommended to test applications with all the default security features enabled. If all the applications work correctly in the test environment, you can proceed to the deployment phase. However, if applications do not work, you may need to redevelop, reconfigure, or upgrade applications to operate successfully with the new security technologies. However, in the short term, it may be possible to apply fixes to computers or applications to allow these applications to run with Windows XP SP2 installed. These fixes may reduce the security of the operating system, so you should only apply them when you have a full understanding of the effects, and you should ensure that you track these carefully for later removal, so you can achieve the full security benefits of Windows XP SP2.

Using the Windows Application Compatibility Toolkit

Version 3 of the Windows Application Compatibility Toolkit (ACT) is currently available from the Microsoft Web site, with a new version targeted for beta release later this year. The ACT provides the following functionality:

  • Application inventory collection

  • Application issue detection

  • Application inventory and issue data analysis

  • Application compatibility fix deployment through Compatibility Administrator

ACT can be used in all phases of application compatibility testing and deployment.

Figure 2.2 Using ACT in application compatibility testing and deployment

Figure 2.2 Using ACT in application compatibility testing and deployment

For more information about using the Windows Application Compatibility Toolkit, see the Microsoft Web site at

http://www.microsoft.com/windows/appcompatibility/default.mspx

For a preview of the upcoming Windows Application Compatibility Toolkit 4.0, see the Microsoft Web site at

http://www.microsoft.com/windows/appcompatibility/act4.mspx

Understanding Compatibility Issues

The introductory chapter of this guide, Chapter 1, described the new features in Windows XP SP2 and how these features enhance the security of a computer by making it more resilient to attack. This section looks at these technology areas in detail and discusses how an application incompatibility issue may appear to the end user.

Internet Explorer

Internet Explorer is the application in Windows XP that benefits the most from the security enhancements in Windows XP SP2. The use of Internet Explorer as an application front end makes it an important component of any test plan.

For more information about Internet Explorer, see “Part 5: Enhanced Browsing Security” in the “Changes to Functionality in Microsoft Windows XP Service Pack 2” guide at:

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2brows.mspx 

Feature Control

Feature Control provides the means to control the security features in Internet Explorer. Windows XP SP2 creates new registry settings that apply the security features to specific processes. Any corresponding Internet Explorer zone specific security setting will then affect that process. This approach allows greater configuration flexibility in Internet Explorer than was possible with previous versions of Windows XP, even using the Internet Explorer Administration Kit (IEAK).

Application developers must always be aware of the security zone in which their application runs, so that they know the security configuration that is applied.

To view additional information regarding this technology in this guide, click the following links:

Introduction to Feature Control

Application Compatibility Issue Mitigation for Feature Control

For more information about Internet Explorer Feature Control Settings in Group Policy, see the Microsoft Web site at

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2brows.mspx#XSLTsection130121120120  

UrlAction Security

UrlActions are configurable features of Internet Explorer and are found on the Security tab of the Internet Options applet in Control Panel. Developers must be aware of the zone in which their application executes and what actions are allowed in that zone. An application may fail if it attempts to use features that an administrator has disabled. This failure then generates messages in the Information Bar.

To view additional information regarding this technology in this guide, click the following links:

Introduction to UrlActions

Application Compatibility Issue Mitigation for UrlActions

For more information about Internet Explorer UrlAction Security Settings in Group Policy, see the Microsoft Web site at

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2brows.mspx#XSLTsection132121120120 

Binary Behaviors

You can use Feature Control to configure binary behaviors for a specific process or security zone. Because the binary behaviors automation can also be put to malicious use, Windows XP SP2 disables binary behaviors in the Restricted Sites zone by default. This restriction reveals itself during application testing as a failure to render HTML documents correctly.

To view additional information regarding this technology in this guide, click the following links:

Introduction to Binary Behaviors

Application Compatibility Issue Mitigation for Binary Behaviors 

For more information about Internet Explorer Binary Behaviors Security Settings in Group Policy, see the Microsoft Web site at

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2brows.mspx#XSLTsection126121120120 

Local Machine Lockdown

Prior to Windows XP SP2, the Local Machine zone had less restrictive security settings and was not configurable. After installing Windows XP SP2, any application that uses the less restrictive lower security settings in the Local Machine zone may experience compatibility issues.

Because content on the local file system is no longer assumed to be safe, Local Machine Lockdown is even more restrictive than the Internet zone. Scripts and ActiveX® controls are blocked when Local Machine Lockdown is applied.

If an application downloads content from the Internet zone and accesses it locally, the page may not load and the warning message in Figure 2.3 appears in the Information Bar.

Figure 2.3 An application attempts an unsafe action with Local Machine Lockdown applied

Figure 2.3 An application attempts an unsafe action with Local Machine Lockdown applied

The same issue can also occur when running active content from a CD.

To view additional information regarding this technology in this guide, click the following links:

Introduction to Local Machine Lockdown

Application Compatibility Issue Mitigation for Local Machine Lockdown

For more information about Internet Explorer Local Machine Zone Lockdown, see the Microsoft Web site at

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2brows.mspx#XSLTsection133121120120 

MIME Handling

Internet Explorer no longer executes files if there is a mismatch between the MIME type and the file extension. This restriction protects the user from executing a dangerous file that was previously downloaded as another file type. If the server misreports MIME type information, the application may fail and display the message in Figure 2.4.

Figure 2.4 When a server incorrectly reports MIME type, Internet Explorer prevents the file from executing

Figure 2.4 When a server incorrectly reports MIME type, Internet Explorer prevents the file from executing

Windows XP SP2 users may also experience additional file download prompts due to file types being defined by AssocIsDangerous, such as, .exe or .bat files.

MIME sniffing in Windows XP SP2 identifies the content type using a bit signature. Web servers that do not include the correct content-type header with files and that use non-standard file name extensions for HTML pages may now have those pages rendered as plain text rather than HTML.

To view additional information regarding this technology in this guide, click the following links:

Introduction to MIME Handling

Application Compatibility Issue Mitigation for MIME Handling

For more information about Internet Explorer MIME Handling Enforcement, see the Microsoft Web site at

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2brows.mspx#XSLTsection134121120120 

Object Caching Protection

Object caching protection prevents cached objects from being referenced after navigating away from a Web site. Object caching protection is turned on by default. Application developers should be aware of this greater security restriction and not develop applications that use objects from other Web sites because they may cause problems for the UI.

To view additional information regarding this technology in this guide, click the following links:

Introduction to Object Caching

Application Compatibility Issue Mitigation for Object Caching

For more information about Internet Explorer Object Caching, see the Microsoft Web site at

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2brows.mspx#XSLTsection135121120120 

Window Restrictions

Applications that create windows using scripts may experience some compatibility issues. Windows cannot be created off screen (for example, to hide background processing) and must have the status, address, and title bars viewable. This requirement may affect the UI of the application because previously hidden windows may now be visible.

To view additional information regarding this technology in this guide, click the following links:

Introduction to Window Restrictions

Application Compatibility Issue Mitigation for Window Restrictions

For more information about Internet Explorer Window Restrictions, see the Microsoft Web site at

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2brows.mspx#XSLTsection138121120120 

Zone Elevation Blocks

Elevation of privilege is one of the most common exploits with Internet Explorer. Windows XP SP2 prevents navigation from a less privileged to a more privileged zone. Applications that need to switch zones function only with user interaction. Navigation to the Local zone is blocked and navigation to other zones is preceded by a warning message that the user can choose to bypass.

To view additional information regarding this technology in this guide, click the following links:

Introduction to Zone Elevation Blocks

Application Compatibility Issue Mitigation for Zone Elevation Blocks

For more information about Internet Explorer Zone Elevation Blocks, see the Microsoft Web site at

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2brows.mspx#XSLTsection139121120120 

Information Bar

The Information Bar significantly changes the browsing experience for users. Messages that normally appear in dialog boxes now display in the Information Bar. Windows XP SP2 may block content that is necessary to complete specific tasks, and the Information Bar provides the notification area in these instances.

Applications that automatically navigate users to pages for add-on install, or content download, may experience issues. Navigation may be halted until the user allows it through the Information Bar menu. This change can cause compatibility issues because processing could occur out of order.

The Information Bar options vary, and depend on the original blocked feature. These options include allowing a download to continue or a pop-up window to display.

The first time the Information Bar displays any messages, a dialog box appears that explains the purpose of the Information Bar. Users can elect not to receive further notifications. Figure 2.5 shows this dialog box.

Figure 2.5  Dialog box informing the user about the Information Bar

Figure 2.5  Dialog box informing the user about the Information Bar

To view additional information regarding this technology in this guide, click the following links:

Introduction to the Information Bar

Application Compatibility Issue Mitigation for the Information Bar

For more information about Internet Explorer Information Bar, see the Microsoft Web site at

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2brows.mspx#XSLTsection129121120120 

Pop-up Management

The Pop-up Blocker blocks pop-up windows that are initiated automatically from a Web site. The pop-up windows are blocked by default for the Internet and Restricted Sites zones. However, the Pop-up Blocker has no effect on windows that are initiated by user action. The Information Bar shows when a pop-up is blocked, and a user can allow the pop-up to appear. Applications or sites that use pop-up windows may experience errors even if specifically allowed from the Information Bar. If the pop-up window performs data processing, for example, this processing may occur out of order and cause the application to fail.

Figure 2.6 Information Bar showing pop-up has been blocked

Figure 2.6 Information Bar showing pop-up has been blocked

Introduction to Pop-up Management

Application Compatibility Issue Mitigation for Pop-up Management

For more information about Internet Explorer Pop-up Blocker, see the Microsoft Web site at

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2brows.mspx#XSLTsection136121120120 

Add-on Management

If an application installs add-ons for Internet Explorer, they appear in the Manage Add-ons interface. It is possible that the add-ons could make the application running in Internet Explorer unstable. Windows XP SP2 includes Add-on Crash Detection that can identify and allow a user to disable problematic add-ons. Disabling an add-on does not remove it from the computer. If an attempt is made to instantiate a blocked ActiveX control, a Yellow Shield icon appears in the Internet Explorer status bar. Clicking the icon displays the Manage Add-ons dialog box. Applications that attempt to access disabled ActiveX controls may not operate as expected.

To view additional information regarding this technology in this guide, click the following links:

Introduction to Add-on Management

Application Compatibility Issue Mitigation for Add-on Management

For more information about Internet Explorer Add-on Management and Crash Detection, see the Microsoft Web site at

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2brows.mspx#XSLTsection125121120120 

Windows Firewall

The default setting for Windows Firewall is to block any inbound communication. External applications that initiate contact with the client computer, such as management systems, fail. Applications that receive initial contact from the client but then attempt to open an additional port on the client, such as active FTP, also fails. This behavior means that remote system management and automated downloading of content to the client, such as virus updates, may fail.

For information about programs that may behave differently in Windows XP SP2, see article 884130 in the Microsoft Knowledge Base at

http://support.microsoft.com/default.aspx?kbid=884130 

In addition, see article 842242, “Some programs seem to stop working after you install Windows XP Service Pack 2,” in the Microsoft Knowledge Base at

http://support.microsoft.com/default.aspx?kbid=842242 

Client computers may also not be able to act as Web or file and print servers without further configuration. Testing network connectivity by sending PING packets to the remote system also fails.

Figure 2.7 shows the dialog box that Windows Firewall generates to indicate that an application is attempting to allow inbound communication.

Figure 2.7 Dialog box informing an administrator that an application attempted to allow a connection from an external source

Figure 2.7 Dialog box informing an administrator that an application attempted to allow a connection from an external source

If the user is an administrator, the dialog box gives the option of unblocking the application, otherwise the message is informational. A user with administrative privileges can allow an end user to suppress further notifications for attempts to open a port by the same program, as shown in Figure 2.8.

Figure 2.8Dialog box informing a user that an application attempted to allow a connection from an external source. This dialog box allows the user to suppress further notifications from this application

Figure 2.8Dialog box informing a user that an application attempted to allow a connection from an external source. This dialog box allows the user to suppress further notifications from this application

The Windows Firewall has a Default Boot Policy applied when the system starts up. This allows DHCP, DNS, and domain logon operations to perform normally. Once the system is up and running, the Run-time Policy is applied and any configuration is set, such as enabling remote management or a local server component, for example, as an FTP or HTTP server. Administrators should be aware that if the Windows Firewall service fails to start, the Boot Policy remains in effect and no incoming communication is accepted, which makes remote diagnostics difficult.

To view additional information regarding this technology in this guide, click the following links:

Introduction to Windows Firewall

Application Compatibility Issue Mitigation for Windows Firewall

For more information about Windows Firewall, see the Microsoft Web site at

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2netwk.mspx#XSLTSection130121120120 

For more information about Deploying Windows Firewall Settings for Microsoft Windows XP Service Pack 2, see the Microsoft Web site at

http://www.microsoft.com/downloads/details.aspx?FamilyID=4454e0e1-61fa-447a-bdcd-499f73a637d1&DisplayLang=en 

For more information about Troubleshooting Windows Firewall in Microsoft Windows XP Service Pack 2, see the Microsoft Web site at

http://www.microsoft.com/downloads/details.aspx?familyid=a7628646-131d-4617-bf68-f0532d8db131&displaylang=en

Data Execution Prevention

Data execution prevention (DEP) is a set of hardware and software technologies that perform additional checks on memory to help protect against malicious code exploits.

By default, DEP is configured to only protect core Windows applications and services. In this default configuration, application compatibility issues are limited to applications that extend core Windows components or run in host processes that are a core part of Windows.

Some application behaviors are expected to be incompatible with DEP. Applications that perform dynamic code generation (such as Just-In-Time code generation) and that do not explicitly mark generated code with Execute permission might have compatibility issues with DEP. Applications that are not built with SafeSEH must have their exception handlers located in executable memory regions.

Another application compatibility concern is Physical Address Extension (PAE) mode. PAE mode is a requirement for 32-bit processors that support hardware-enforced DEP. Although some drivers may have compatibility issues with PAE mode, PAE mode in Windows XP SP2 has been changed to minimize impact to driver compatibility.

For more information on compatibility issues with DEP, see “Changes to Functionality in Microsoft Windows XP Service Pack 2” at

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2chngs.mspx

If a program that is a core component of Windows encounters a problem with DEP, the user sees a dialog similar to the one shown in Figure 2.9.

Figure 2.9 User warning when a core Windows component encounters a problem with DEP

Figure 2.9 User warning when a core Windows component encounters a problem with DEP

However, if an application that is not a core component of Windows encounters a problem with DEP and the current user is a member of the Local Administrators group, the user sees a dialog similar to the one shown in Figure 2.10.

Figure 2.10  Administrator warning when an application encounters a problem with DEP

Figure 2.10  Administrator warning when an application encounters a problem with DEP

To view additional information regarding DEP in this guide, click the following links:

Introduction to DEP

Application Compatibility Issue Mitigation for DEP

Dcom/Rpc

Changes to DCOM and RPC may cause problems if the Windows XP system is an application server. When a system is upgraded, all application-specific permissions are maintained but the new system-wide permission limits are added. Table 2.2 shows the default system-wide permission limits.

Table 2.2 DCOM System-wide Permission Limits

Permission

Administrator

Everyone

Anonymous

Launch and Activation

Local Launch

Local Activation

Remote Launch

Remote Activation

Local Launch

Local Activation

 

Access

(see note)

Local Access

Remote Access

Local Access

These new permission limits allow the Everyone group to have Local Launch, Local Activation, and Local and Remote Access permissions. The remote permissions for the Everyone group are limited to Access. The Everyone group has remote access to keep callback scenarios working for COM applications. Typically, in a callback scenario, a COM application connects to a remote COM application, and the COM application passes an interface that will be used by the remote COM application for callback.

Note: The DCOM system-wide permission limits do not explicitly specify “Access” permissions for the “Administrators” group. However, the “Administrators” group is part of the “Everyone” group, thus administrators get Local and Remote Access permissions.

For more information on DCOM system-wide permission limits, see:

http://msdn.microsoft.com/library/en-us/com/htm/reg_1166.asp

http://msdn.microsoft.com/library/en-us/com/htm/reg_1226.asp

Local access scenarios should not incur compatibility issues. Because of the inclusion of the system wide security, you may experience compatibility issues if you have a COM server application that meets one of the following criteria:

  • The application is not normally launched through COM, and the access permission for the application is less stringent than the launch permission.

  • The application is usually activated on a computer running Windows XP by a remote COM client without using an administrative account.

  • The application uses unauthenticated remote callbacks on a computer running Windows XP, by default.

For these applications, the user experience depends on the network implementation. Applications should be tested for errors before rolling out Windows XP SP2 and any issues mitigated by changing the default DCOM access permissions or rewriting the application. To identify compatibility issues, the System and Application event logs can be queried and CallFailureLogging can be implemented by creating the following registry value:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\Ole\CallFailureLoggingLevel

Set the value data to:

1 – Always log event log failures during a call in the COM server process

2 – Never log event log failures during a call in the call server process

This registry key is not present by default; however, a missing key or value is interpreted as 2.

Call failure is not logged by default. If you change this value to 1 to start logging this information to help you troubleshoot an issue, be sure to monitor the size of your event log because this is an event that can generate a large number of entries.

For more information, see:

http://msdn.microsoft.com/library/en-us/com/htm/reg_0t9o.asp

http://msdn.microsoft.com/library/en-us/com/htm/reg_3gks.asp

http://msdn.microsoft.com/library/en-us/com/htm/reg_3p9o.asp

RPC applications may also fail if the client attempts to make anonymous calls to remote computers. Windows XP SP2 includes the RestrictRemoteClients registry key, which modifies the behavior of security applied to RPC interfaces. If an application makes remote anonymous calls to the Windows XP SP2 computer, the application may fail with network errors.

To view additional information regarding this technology in this guide, click the following links:

Introduction to DCOM/RPC

Application Compatibility Issue Mitigation for DCOM/RPC

For more information about DCOM Security Enhancements, see the Microsoft Web site at

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2netwk.mspx#XSLTSection128121120120 

For more information about RPC Interface Restriction, see the Microsoft Web site at

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2netwk.mspx#XSLTSection128121120120 

Changes to DCOM and Windows Firewall directly affect deployments of SMS.

For more about SMS Clients Frequently Asked Questions information, see the Microsoft Web site at

http://www.microsoft.com/technet/prodtechnol/sms/sms2003/techfaq/tfaq03.mspx

Windows Firewall may also affect applications based on SQL Server.

For more information about How Windows XP Service Pack 2 (SP2) Affects SQL Server and MSDE, see the Microsoft Web site at

http://www.microsoft.com/sql/prodinfo/previousversions/winxpsp2faq.mspx  

Attachment Execution Service

Attachment Execution Service (AES) is a new feature for Windows XP SP2 and because applications have to be written specifically to interact with AES, there will not be any direct application compatibility issues. Users receive more informative download dialog boxes in Outlook® Express and Internet Explorer and the list of blocked file types is extended. Executable attachments sent from publishers who have been blocked in the Add-on Management console are not available for download.

Outlook Express blocks certain attachments types by default. The user sees the attachment and its size, but the file itself is unavailable. Figure 2.11 shows an example of a blocked attachment.

Figure 2.11 Blocked attachment. Attachment Manager is preventing the user from saving an unsafe attachment

Figure 2.11 Blocked attachment. Attachment Manager is preventing the user from saving an unsafe attachment

If the Administrator chooses to allow users to download attachment types, such as, .exe and .hta, AES handles the attachment and warns the user. The attachment or application is handled slightly differently if it has a digital signature. If the application has a digital signature that verifies the publisher, you see the dialog box shown in Figure 2.12.

Figure 2.12 AES informs the user that a mail attachment has a digital signature

Figure 2.12 AES informs the user that a mail attachment has a digital signature

The Publisher link allows the user to check the signature and decide if they want to run the program. The Digital Signature Details dialog box then appears, as shown in Figure 2.13.

Figure 2.13 The user checks the publisher details to decide if the attachment is from a trustworthy source

Figure 2.13 The user checks the publisher details to decide if the attachment is from a trustworthy source

If the application does not have a digital signature, the dialog box in Figure 2.14 appears.

Figure 2.14 This attachment does not have any publisher information to assist the user

Figure 2.14 This attachment does not have any publisher information to assist the user

This dialog box warns the user against running the application. Ultimately, the choice and responsibility is still with the user.

AES also protects the user if they save the attachment locally and then try to run the application. In this case, the user also receives a warning message.

Figure 2.15 shows the warning that appears when trying to run a downloaded file.

Figure 2.15 Warning message when trying to run a downloaded file

Figure 2.15 Warning message when trying to run a downloaded file

To view additional information regarding AES in this guide, click the following links:

Introduction to Attachment Execution Service

Application Compatibility Issue Mitigation for Attachment Execution Service

For more information about Internet Explorer Download, Attachment, and Authenticode Enhancements, see the Microsoft Web site at

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2brows.mspx#XSLTsection124121120120

Outlook Express

Outlook Express specifically uses the additional enhancements in Windows XP SP2, for downloading pictures and running in plain text mode.

For more information about Changes to Functionality in Microsoft Windows XP SP2, Part 4: E-mail Handling Technologies, see the Microsoft Web site at

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/SP2email.mspx#XLSTsection124121120120

Picture Downloads

Outlook Express now has picture handling facilities similar to Outlook 2003. This prevents senders of spam e-mail from determining whether a recipient opens a message. It does this by preventing the automatic display of pictures from Internet servers. The user is presented with place holders and the Information Bar gives the user the option to display the picture. Figure 2.16 shows the prompt that the user receives.

Figure 2.16 Blocking picture downloads in Outlook Express now matches Outlook 2003

Figure 2.16 Blocking picture downloads in Outlook Express now matches Outlook 2003
Plain Text Mode

Plain text mode is now the default setting with Outlook Express in Windows XP SP2. In plain text mode, Outlook Express uses the rich edit control rather than the MSHTML control. This avoids some security issues that result from the use of MSHTML by using the rich edit control. You can reduce the attack surface by operating in plain text mode.

The following Outlook Express features are not available when running in plain text mode:

  • Changing text size

  • Full text searching through the body of a mail message

Windows Messenger

Windows Messenger is another application that uses the Attachment Manager, which brings security improvements to Windows Messenger, such as blocking file transfers with certain file types. You are now prompted before opening the following file types:

  • Microsoft Office files, such as .doc, .ppt, .xls

  • Files from other applications, such as, .zip, .wpd, and .pdf

  • Computer applications, programs, or any file that contains software code or script, including macros, executables, and JavaScript

  • Files with extensions .exe, .cmd, .wsh, .bat, .vb, .vbs; .pif, .scr, and .scf

Windows Messenger no longer allows the display name and e-mail address of the user to be identical. Users are unable to log on until they change their display names.

Summary

You have now covered how to test for and identify the effects that installing Windows XP SP2 can have on application compatibility. You have reviewed the recommended approach for application compatibility testing and covered the detailed issues that this service pack can introduce. In the next chapter, you are now going to examine methods of mitigating these application compatibility issues.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft