Introduction
Upcoming SlideShare
Loading in...5
×
 

Introduction

on

  • 460 views

 

Statistics

Views

Total Views
460
Views on SlideShare
460
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Introduction Introduction Document Transcript

  • Works with Windows Server 2008 Compatibility requirements for software products that run on Microsoft® Windows® Server 2008 operating system Requirements for the Works with Windows Server 2008 Program for Software This document outlines the requirements for the Works with Windows Server 2008 Program for Software. Please send any questions to wslogofb@microsoft.com. Version 1.2 March 31, 2008
  • The information presented in these guidelines reflects Microsoft Corporation’s views as of the date of publication. These views can and probably will change in response to changing market conditions. Microsoft makes no warranties or guarantees, implicit or explicit, in or by virtue of this document. Unless otherwise permitted by law, no part of this document may be copied without Microsoft’s prior written permission. © Microsoft Corporation 2007. All rights reserved. Active Directory, Microsoft, Microsoft Win 32 and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
  • Change History Date Version Change 3/31/2008 1.2 PR 4 Added UAC Check, added change history table
  • Contents Introduction............................................................................................................5 Program Overview ..................................................................................................5 Program Policies......................................................................................................5 “Works with Tool” (WWT).........................................................................................6 Background Monitored Prerequisites (PR)..............................................................7 PR 1Conduct tests on both x64 Windows Server 2008 and x64 Vista Ultimate or Enterprise edition operating systems.........................................................................................7 PR 2Support 64-Bit version of Windows running on multiple processors..........................7 PR 3Multi-language requirements..............................................................................8 PR 4Follow best practices in Security and Reliability ....................................................8 PR 5Maintain compatibility with Antivirus software.......................................................9 PR 6Do not cause services to unexpectedly become unavailable....................................9 PR 7All drivers must be WHQL signed.......................................................................10 Chapter 1 – Windows Installer..............................................................................11 1.1ICE Errors in Installation Package........................................................................11 1.2Correctly configure package identity....................................................................11 1.3Installer Custom Action Restrictions.....................................................................12 Chapter 2 – Primary Functionality.........................................................................13 2.1Perform primary functionality and maintain stability..............................................13 2.2Comply with driver related requirements..............................................................13 2.3Do not overwrite non proprietary files with older versions......................................14 2.4All executables must be signed...........................................................................14 2.5Install shared components to safe locations..........................................................15 2.6Do not install 16-bit binaries...............................................................................15 Technical Support..................................................................................................16 Works with Requirements Mapping..........................................................................17
  • Introduction The purpose of this document is to outline the technical requirements a server application and its client components must meet in order to obtain the Works with Windows Server 2008 designation. For details on how to test an application, please refer to the Works with Windows Server 2008 Test Framework document on http://www.innovateonwindowsserver.com/ Program Overview The goal of the Works with Windows Server 2008 Program for software is to highlight and promote applications that are compatible with Windows Server 2008. The Works with program requirements represent a subset of the Certified for Windows Server 2008 (CFW) program requirements, which cover issues of reliability and security, as well as compatibility. For more information on the CFW program check http://www.innovateonwindowsserver.com/ This document details all program requirements. However, the base program requirements are: - Be able to run on x64, natively or with WOW64 - Contain x64 versions of any kernel mode drivers - All drivers are WHQL signed The majority of applications that currently run on Windows Server 2003 also work on Windows Server 2008 with no changes. Of applications that do not run on Windows Server 2008, they may - run with the help of a Compatibility Layer (a setting which provides some Windows Server 2003 functions to the application) - run with the help of an Elevation Layer (a setting which runs the application with administrator privileges) - make code changes to enable it to run on Windows Server 2008 through an update The Works with Windows Server 2008 Program can be applied to applications in all three categories. An application that needs a product update to be compatible may obtain the Works with Windows Server 2008 designation when the product update is made available to customers. Program Policies For detailed information on policies, version testing, updates, and notifications see http://www.innovateonwindowsserver.com/. An application that fully complies with the requirements in this specification may be designated as Works with Microsoft Windows Server 2008 after the following conditions are met:  Independent Software Vendors (ISV’s) must test their application using the Works with Windows Server 2008 Test Framework document.  ISV’s must submit all results and logs generated during testing to a Microsoft approved testing vendor.
  •  Results of the tests must be verified and qualified as ‘Pass’ by a Microsoft approved testing vendor in accordance with the Works with Windows Server 2008 Test Framework document.  Vista and Client Components: All client components that are part of a server application must be tested and verified concurrently.  As part of this process, the ISV must create a Disclosure Document for each application which may later be updated by the test vendor. This document will contain information about the application’s behavior and how the application passed certain requirements. When a requirement calls for behavior to be documented, the information must be included in the document. Documents will be made publicly available for review by customers. Verification is done through a third party approved Microsoft vendor, however Microsoft reserves the right to audit ISV application submissions and deny the Works with Windows Server 2008 designation to an ISV if the application fails. Please read the privacy agreement for Works with submissions available on http://www.innovateonwindowsserver.com/ Microsoft also reserves the right to revoke the Windows Server 2008 designation to an ISV based on WER (Windows Error Reporting) data. “Works with Tool” (WWT) The WWT is a wizard style tool that includes all tests in the Works with Windows Server 2008 Software Test Framework document. The tool is available for download on http://www.innovateonwindowsserver.com/ All of the tests may be conducted manually using the instructions in the Works with Windows Server 2008 Software Test Framework document. However, the WTT compiles test logs and background verifications in a format that can be easily verified by a test vendor. In order to be eligible for the program, WWT must be used by the ISV to perform testing & generate reports. Microsoft Authorized Test Authorities (ATAs) will be using results generated by the WWT for verification purposes. Note: WWT uses Application Verifier in the background for test verification purposes. If you run the tests manually without using the tool, you will not need Application Verifier. Also, in order to use the WWT, the Startup and Recovery setting for system failure must be set to the default, ‘Kernel Mode Dump’.
  • Background Monitored Prerequisites (PR) System prerequisites will be background monitored by the WWT during testing. PR 1 Conduct tests on both x64 Windows Server 2008 and x64 Vista Ultimate or Enterprise edition operating systems To ensure compatibility, a server application as well as all its client components must meet Works with Windows Server 2008 requirements.  To maintain consistency in testing and validation, all Works with Windows Server 2008 testing must be conducted on: - x64 Windows Server 2008 - x64 Windows Vista Ultimate or Enterprise edition The Windows Vista Ultimate edition contains all of the core functionality provided in other versions of Windows Vista. Testing using Windows Vista Ultimate edition ensures that the application will work on other Windows Vista versions. An application may be tested on a different version if it relies on features or functionality only available in a particular version. This must be noted in the disclosure document. If the application doesn’t contain any client components, tests only need to be run on Windows Server 2008. This must be noted in the disclosure document. PR 2 Support 64-Bit version of Windows running on multiple processors Applications must support x64 versions of Windows Server 2008 and all testing must be conducted on a 64bit version of Windows Server 2008. To maintain compatibility with 64-bit versions of Windows, it is necessary that:  Applications install and run properly on at least a dual-core system.  Applications and their installers must not contain any 16-bit code or rely on any 16-bit component, since 16-bit code will not run on 64-bit versions of Windows Vista and Windows Server 2008.  All drivers and executables must be signed to install on a 64-bit Windows OS.  If an application is dependent on kernel-mode drivers for operation, 64-bit versions of these drivers must be available. The application setup must detect and install the proper drivers and components for the 64-bit Windows OS.  If an application is natively 32-bit, it may rely on WOW64 instead of running natively on 64-bit. 32-bit applications must also provide 64-bit versions of kernel mode drivers. Customer Benefits Customers expect modern applications to support multiple processors and install correct drivers when installing under different platforms, such as a 64-bit Windows Operating System.
  • PR 3 Multi-language requirements It is required that ISV’s declare the language of any non-English application in their submission package. If the application is written using Unicode characters, the Works with designation applies to any language release of the application. Otherwise, ISV’s must seek individual Works with Windows Server 2008 designations for each language release. There is no multi-language support requirement for an application to receive the Works with Windows Server 2008 designation. The Works with Tool itself will only be released in English. However, the tests are not language specific and you will be able to navigate through the wizard and run the tests on a non-English application. Recommendations for non-English applications:  Applications which are intended to be used in a certain language should be tested on a localized Windows Server 2008 and Windows Vista also in that language.  Applications should use Unicode. Using Unicode limits an ISV’s risk when localizing. PR 4 Follow best practices in Security and Reliability Windows Error Reporting (WER) Windows Error Reporting is the set of feedback technologies built-in to Microsoft Windows Vista and Microsoft Windows Server 2008 operating systems. WER captures software crash and hang data from end-users who agree to report it. ISV’s can access the data that is related to their applications online at: https://winqual.microsoft.com ISV’s can monitor error trends and download debug information to help developers determine the precise causes for application errors. WER categorizes and prioritizes data for the application, and includes a response feature to provide solutions to your end-users. ISV’s may sign up with Winqual to receive Windows Error Reports.  The application must not disable Windows Error Reporting service at any time. IPv6 Support for Internet Protocol version 6 (IPv6) is built into all versions of Windows since the release of Windows XP SP1. IPv6 is designed to solve many of the problems of IPv4 such as address depletion, security, auto configuration, and extensibility. Its use will also expand the capabilities of the Internet to enable a variety of valuable and exciting scenarios, including peer-to-peer and mobile applications.  IPv6 network layer IP protocol must not be disabled by the application.
  • Firewall Windows Firewall is a built-in, host-based, stateful firewall that is included in all versions of Windows beginning with the release of Windows XP with Service Pack 2. Windows Firewall drops incoming traffic that does not correspond to either traffic sent in response to a request of the computer (solicited traffic) or unsolicited traffic that has been specified as allowed (excepted traffic). Windows Firewall provides a level of protection from malicious users and programs that rely on unsolicited incoming traffic to attack computers.  The application cannot disable the Microsoft Firewall and must work properly with Microsoft’s or any third party certified firewall. A list of certified firewall applications can be found at: http://www.innovateonwindowsserver.com/ User Account Control User Account Control (UAC) is a malware protection feature built-in to Microsoft Windows Vista and Microsoft Windows Server 2008 operating systems. UAC enforces least user privilege principles to help prevent users from running programs that attempt to perform operations that the user doesn't authorize or intend.  The application must work properly with UAC enabled. The application must not disable UAC or require UAC to be disabled. Customer Benefit Modern environments expect applications to send Windows Error Reports, and perform appropriately with IPv6, Firewall solutions, and User Account Control. PR 5 Maintain compatibility with Antivirus software Device conflicts and stability problems can be exposed when an application runs on a system that has kernel mode active virus scanning running. Applications must perform all primary functions while a virus scanner filter driver actively scans all files for viruses in full detection mode.  Applications must install and operate correctly when a certified antivirus application is running.  The antivirus engine must not be disrupted by the application. Customer Benefit Antivirus protection is a requirement in any environment. Customers expect applications to function properly without any loss of performance while the file system is being monitored by a certified antivirus application. A list of certified antivirus applications can be found on http://www.innovateonwindowsserver.com/ PR 6 Do not cause services to unexpectedly become unavailable The issue of services remaining available is critical. The goal of this requirement is to ensure that applications do not cause failures in other applications by making services unavailable.
  •  Applications must maintain stability in general, and violating that is a failure of this requirement and primary functionality  To pass this requirement, applications must notify the administrator at any time any service needs to be shut down.  Services shutting down unexpectedly or shutting down without allowing the administrator to control the timing of the shutdown is a failure. Customer Benefit Robust applications prevent issues in an environment where other applications depend on Services being 100% available. PR 7 All drivers must be WHQL signed Poorly written kernel-mode drivers can crash a system. Applications that include kernel-mode drivers, such as backup, copy protection, and antivirus products, must be thoroughly tested to minimize this risk.  All application drivers must have a Microsoft signature.  All application drivers must pass Windows Hardware Quality Labs (WHQL) testing. Driver signing is a pivotal to receiving the Works with Windows Server 2008 designation. No application will pass if drivers are unsigned or if WHQL Submission ID is missing from the submission package. The WHQL process may be concurrent with Works with Windows Server 2008 testing, but will be considered failing until drivers are signed, a WHQL Submission ID is provided, and no unsigned driver dialogs appear during testing. Customer Benefit Customers can be confident that all drivers that are installed by a Works with application will be signed by Windows Hardware Quality Labs (WHQL) and pass WHQL tests. Additional Information For WHQL Testing & driver signing requirements, see: http://www.microsoft.com/whdc/GetStart/default.mspx http://www.microsoft.com/whdc/winlogo/drvsign/drvsign.mspx For WHQL Policies, see: http://www.microsoft.com/whdc/whql/policies/default.mspx
  • Chapter 1 – Windows Installer 1.1 ICE Errors in Installation Package This requirement applies only to applications that use Windows Installer for installation.  Windows Installation packages must not receive any errors from the Internal Consistency Evaluators (ICEs) listed here: 1-2, 4-7, 9-15, 17-24, 27-29, 31, 33-36, 38, 40-42, 44-56, 59, 61-63, 65, 67-71, 74-78, 81-84, 86-87, 89-94, 96-99 Warnings represent design guidance to the package author which should be studied for applicability. Any warnings that do not apply or will not be fixed must be documented. Customer Benefit Install and uninstall issues are some of the most common sources of application interoperability problems. These requirements help to ensure that the user has successful install and un-install experiences, and that the application co-exists in a friendly way with other applications. Customers should be confident that applications will install on Windows Server 2008 without degrading the operating system or other applications. Additional Information A variety of third-party tools are available that can be used to create Windows Installation packages. The ICEs can be run from the Orca application, which ships with the Windows SDK. For information on ICEs, see: http://msdn2.microsoft.com/en-us/library/aa369554.aspx 1.2 Correctly configure package identity This requirement applies only to applications that use Windows Installer for installation.  For correct identification in ‘Programs and Features’ (Formerly known as Add/Remove Programs), and so that Software Explorer can obtain information about the application as needed, the application must supply all the information in the table below. These values can be set using properties in the Windows Installer package. Property Corresponding Contains (names are case registry value sensitive) ProductName DisplayName Display name of application Manufacturer Publisher Publisher/Developer of
  • application ProductVersion VersionMajor Major version number of application ProductVersion VersionMinor Minor version of application  If the application is installed via a bootstrapper or chainer, the ARPSYSTEMCOMPONENT property can be set in the Windows Installer packages. The legacy Uninstall keys should be written so that they point to the bootstrapper or chainer.  To prepare for an application upgrade, the product must have UpgradeCode, ProductCode, ProductVersion, and ProductLanguage properties for an upgrade to appropriately address the previous package.  To prevent the product from being downgraded, the product must follow Platform SDK guidance for Preventing an Old Package from Installing Over a Newer Version, since downgrading is not what users expect from a package install. Customer Benefit The application is correctly identified in Software Explorer, and properly handles Upgrade scenarios. 1.3 Installer Custom Action Restrictions This requirement applies only to applications that use Windows Installer for installation.  Nested install custom actions (type 7, 23, and 39) have proven to be excessively problematic for application installs and must not be used.  Custom columns must not be added to standard tables. Adding columns to standard tables is reserved for future versions of Windows Installer. Additional Information For more details on custom actions, see: http://msdn2.microsoft.com/en-us/library/aa368066.aspx For more information on Concurrent Installations, also called Nested Installations, or custom install actions of type 7, 23 and 39, see: http://msdn2.microsoft.com/en-us/library/aa368010.aspx Customer Benefits Custom Actions are a powerful tool to extend the capability of installations. Following the best practices outlined below will ensure that customers experience the same level of quality with custom actions as with standard actions.
  • Chapter 2 – Primary Functionality 2.1 Perform primary functionality and maintain stability While users perform the primary functions of the application, it must not hang/crash, lose user’s data, or critically fail. Primary functions must not become inoperable or obstructed and the application must not disrupt Windows or any other applications running on the computers.  Primary functionality includes both installation and un-installation of the application, as well as basic activities of the application and activities that exercise application drivers.  The application (includes both client and server components) must maintain stability when printers and devices are unavailable, removed or not installed.  If the application relies on or changes the system’s display mode it must revert changes to system’s display mode upon exiting.  The application must not prevent the use of any system features that Windows Server 2008 supports and must not cause any critical failure when the features are used.  In the context of this document, critical failure refers to certain types of failures. A failure within a server component or service is not considered to be a crash if it meets the following conditions: • It does not cause loss of data • It does not force shutdown or unscheduled downtime for any server or service • It does not hang/crash due to network connectivity issues  Client components must meet all of the following conditions: • It does not cause loss of data. • It displays information that would allow a typical user to understand what went wrong and how to avoid the problem in the future. • It allows the user to continue running the application or close it. • It does not hang/crash due to network connectivity issues. Customer Benefits Users expect the application to not hang/crash, lose user’s data, or disrupt Windows or any other applications while performing expected primary functionality. 2.2 Comply with driver related requirements Poorly written kernel-mode drivers can crash a system. Applications that include kernel-mode drivers, such as backup, copy protection, and antivirus products, must be thoroughly tested to minimize this risk. If an application includes any kernel-mode drivers, each of these drivers must pass validation testing under the Windows Driver Verifier Manager tool (Verifier.exe). For example, with Driver Verifier installed on your kernel-mode components, the tool
  • must not report any stop error messages or otherwise cause system instability while the system and the application are fully exercised.  All kernel-mode drivers must pass Boot Time verification tests and Run Time verification tests while being exercised. Customer Benefit Customers can be confident that all drivers that are installed by a Works with Windows Server 2008 application pass driver verification tests. 2.3 Do not overwrite non proprietary files with older versions The application’s installation program must ensure that the latest file versions are installed. The installation cannot regress files, unless they are files that you produce or that are shared by other applications which you also produce. Replacing such a file with another language version of the same file is equally inappropriate. However, you own the files in your application’s folder, and you can overwrite them as you want.  You can overwrite your own or third-party files only to update them. Do not prompt the user unless a version update is actually required and can’t safely be done without user input.  Application binaries must have valid file version information. Customer Benefits All executable images that you distribute must contain valid file information. Using correct file version information has several benefits, including making it easier to not overwrite files with older versions. The file’s producer is the only one allowed to regress, so the producer must be identified. Also, if a shared component fails, correct file version information allows customers to identify the associated application and producer. The properties of an executable file (with the extension .exe, .dll, .ocx, .cpl, or other extension) must contain an accurate product name, company name, and file version. This requirement helps maintain system stability and reliability by not overwriting system files. 2.4 All executables must be signed Signing helps users decide if they want to trust an application, and assures users that files have not been tampered with. It also allows applications to run properly in highly secure environments. Drivers signed by WHQL are excluded from this list.  All executable files must be signed with an Authenticode certificate. This includes files with the following extensions: exe, dll, ocx, sys, cpl, drv, scr Customer Benefit Singing gives users more information to decide if they should trust an application and its source. It also allows applications to run properly in locked-down environments.
  • Additional Information For information on code signing certificates available from vendors, see: http://msdn2.microsoft.com/en-us/library/ms995347.aspx Once the certificate has been obtained, these files should be signed using the Sign Tool that comes with the Windows SDK: http://msdn2.microsoft.com/en-us/library/8s9b9yaz(vs.80).aspx 2.5 Install shared components to safe locations  Services and device drivers must be placed in a location that can be safely referenced in all the boot phases and when the administrator re-maps the boot and system drive letters. The System directory is the recommended location. References to the system directory must be done by using the %SystemRoot% environment variable.  Services and Device drivers may be installed under %SystemRoot% or to a custom directory under %ProgramFiles%, %commonprogramfiles%, or for web based applications to <INETPUB>.  Any Services or Device drivers installed to any non %SystemRoot% folder must be documented and may still Fail this test. Win32 applications on x64 may install to: Program Files - %ProgramFiles(x86)% Common files - %commonprogramfiles% Customer Benefit Installing shared components to correct locations ensures greater supportability and reliability. 2.6 Do not install 16-bit binaries  The application’s installer program (or) its dependencies must not install 16-bit binaries. Customer Benefit The x64 editions of Windows Vista and Windows Server 2008 fully support 64-bit processors from AMD and Intel. The 64-bit versions can run all 32-bit applications with the help of the WOW64 emulator. However, 16-bit applications are not supported and hence incompatible.
  • Resources WHQL Testing & driver signing requirements: http://www.microsoft.com/whdc/GetStart/default.mspx http://www.microsoft.com/whdc/winlogo/drvsign/drvsign.mspx WHQL Policies: http://www.microsoft.com/whdc/whql/policies/default.mspx Server Core - Resources/Tools to use while developing/fixing applications: http://msdn2.microsoft.com/en-us/library/ms723891.aspx Server Core - Resources/tools to test Server Core related requirements: http://msdn2.microsoft.com/en-us/library/ms723912.aspx ICE: http://msdn2.microsoft.com/en-us/library/aa369554.aspx Restart manager: http://msdn2.microsoft.com/en-us/library/aa373654.aspx How to avoid Windows installers ‘ForceReboot’ option: http://msdn2.microsoft.com/en-us/library/aa372466.aspx Custom actions: http://msdn2.microsoft.com/en-us/library/aa368066.aspx Concurrent Installations, also called Nested Installations, or custom install actions of type 7, 23 and 39: http://msdn2.microsoft.com/en-us/library/aa368010.aspx Information on effects of breaking component rules: http://msdn2.microsoft.com/en-us/library/aa372795.aspx Signing files using the ‘Sign Tool’ in Windows SDK: http://msdn2.microsoft.com/en-us/library/8s9b9yaz(vs.80).aspx Code signing certificates available from vendors: http://msdn2.microsoft.com/en-us/library/ms995347.aspx Technical Support The following technical support and related information can be obtained from the Internet: Microsoft Developer Network (MSDN®), http://msdn.microsoft.com/ including newsgroups and a library of technical information Microsoft Knowledge Base http://search.support.microsoft.com/kb/ Microsoft Product Support Services http://support.microsoft.com/directory/ Microsoft Partner Program https://partner.microsoft.com/global/program/p rogramoverview/
  • Works with Requirements Mapping The Works with Requirements are a subset of the Certified for Windows Server 2008 Logo Program (CFW). Included here for convenience are the direct mappings to the CFW requirements, which are subject to change. WW CFW Prerequisites Conduct tests on both x64 Windows Server 2008 and x64 none PR 1 Windows Vista Ultimate edition Support 64-Bit version of Windows running on multiple Req 1.7 PR 2 processors PR 3 Multi-language requirements none PR 4 Follow best practices in Security and Reliability Req 4.6 PR 5 Maintain compatibility with Antivirus software Req 3.6 PR 6 Do not cause services to become unavailable Req 4.5 PR 7 All drivers must be WHQL signed Req 1.3 Ch1 – Installer Verification 1.1 Use Windows Components for Installation Req 2.1 1.2 Correctly configure package identity Req 2.1 1.3 Installer Custom Action Restrictions Req 2.11 Ch 2 - Functionality 2.1 Perform primary functionality and maintain stability Req 1.1 2.2 Comply with driver related requirements Req 1.3 2.3 Do not overwrite non proprietary files with older versions Req 2.8 2.4 All executables must be signed Req 3.8 2.5 Install shared components to correct location Req 2.7 2.6 Do not install 16-bit binaries none