Application Compatibility Testing
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.
.gif "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:
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:
https://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:
https://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
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.
.gif "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
https://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
https://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:
https://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
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:
Application Compatibility Issue Mitigation for UrlActions
For more information about Internet Explorer UrlAction Security Settings in Group Policy, see the Microsoft Web site at
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
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.
.gif "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
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.
.gif "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:
Application Compatibility Issue Mitigation for MIME Handling
For more information about Internet Explorer MIME Handling Enforcement, see the Microsoft Web site at
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
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
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
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.
.gif "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
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.
.gif "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
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
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
https://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
https://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.
.gif "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.
.gif "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
For more information about Deploying Windows Firewall Settings for Microsoft Windows XP Service Pack 2, see the Microsoft Web site at
For more information about Troubleshooting Windows Firewall in Microsoft Windows XP Service Pack 2, see the Microsoft Web site at
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
https://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.
.gif "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.
.gif "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:
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:
https://msdn.microsoft.com/library/en-us/com/htm/reg_1166.asp
https://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:
https://msdn.microsoft.com/library/en-us/com/htm/reg_0t9o.asp
https://msdn.microsoft.com/library/en-us/com/htm/reg_3gks.asp
https://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:
Application Compatibility Issue Mitigation for DCOM/RPC
For more information about DCOM Security Enhancements, see the Microsoft Web site at
For more information about RPC Interface Restriction, see the Microsoft Web site at
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
https://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
https://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.
.gif "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.
.gif "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.
.gif "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.
.gif "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.
.gif "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
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
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.
.gif "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.