To earn the Works with Windows Server 2008 designation, you will use the Works with Tool.

Works with Tool:

• Completely a Wizard based tool. No learning curve.
• Testing can be run on physical box or through remote access.
• Test Server and Client components for compliance and compatibility in under 2 to 4 hours.
• View comprehensive report and logs at any time during testing.

Server and Client components will be tested with the Works with Tool on x64 versions of:

• Windows Server 2008 Enterprise
• Vista Ultimate or Enterprise

Install all application prerequisites, prior to testing:

• Applications
• .NET
• IIS
• Devices and Storage depots
• Server Features and Roles
• etc.

Always use latest Works with Tool from the Innovate On web site, where you can:

• Download the Works with Specifications
• Download the Works with Test Framework
• Learn about Windows Server 2008 and the Logo Program
• Learn about other free tools to use during your development cycle

Ready to begin testing

Follow the simple guides of the Wizard to name your Server component and on the Client assure you click the Client component radio button.

If prompted by prerequisite page, install 'amd64' version of Application Verifier by following the link.

Assure that the following are enabled:

• Firewall
• Windows Error Reporting
• IPv6

Assure an Antivirus program is installed and running.

The Works with Tool performs all testing in the background, including monitoring the above prerequisites.

At each page, you will get Pass/Fail prompts for the status of each test case performed. At any time you may click View Report to see current status and logs.

The tests performed are outlined in the Works with Windows Server 2008 Test Framework.

Important: Perform tests manually using the test framework steps, or using the built in automation of the Wizard, but not both concurrently.

When prompted, point the Wizard at the installation executable or Windows Installer package.

Next steps will begin testing of the installation package, take a baseline snapshot of the system, and finish this step by prompting to install your application. This may take a few minutes.

After installation and configuration, one more system snapshot will be taken. You will then be presented with a series of test results.

If your application contains drivers, you may be prompted to reboot to set up special driver testing during boot up and during primary functionality testing.

When testing is complete, you will be prompted to uninstall the application. Rebooting again may be necessary. The Works with Tool will allow you to resume a test at launch. Select this option, and you will return to the last page prior to rebooting.

You will now be presented with a series of quick questions about the testing.

When testing is complete, you will create a Submission package which includes the test results from the Server components and any Client components from another machine.

You may now View Report of the final testing for both Server and Client results.

If submitting test results to a test vendor...

The Works with Tool is a valuable asset during the development cycle of your product.

If you are ready to submit your test results to a test vendor for independent validation:

• Assure all tests are listed as Pass or documentation exists for each failure.
• Establish a Winqual Account that identifies your company with the Windows Logo Program.
• If the application contains drivers, then all Drivers must have passed separate WHQL testing as well. Please submit your WHQL Submission ID.
• Provide Microsoft Pre-approved Waivers. (Only granted on a limited basis.)
• Provide documentation for 3^rd party file failures to test vendor. Include all 3rd party file names installed found by Works with Tool and file owners in public facing documentation. Waivers not required.
• See the Innovate On site for details on above steps and on how to select a test vendor.

When submission package has been validated by test vendor, you will be granted the designation of Work with Windows Server 2008. See the Innovate On web site for benefits associated with each Logo Program.

Interpreting the Logs from Works with Tool

Since the Works with program is one of self testing, you will be interpreting the test logs generated.

Help can be had on the dedicated MSDN Forum for Windows Server 2008 Application Compatibility and Certification issues. There you will find Windows experts, as well as a community of developers and Independent Software Vendors helping each other with the new operating system and Logo program requirements.

Below are the most common issues encountered when attempting to interpret your own logs. Most are common to many of the test case logs, so they do not bear repeating for each log.

Interpreting log failures:

3^rd party files

Definition: Any file not part of your build process, and not owned by your Product group or Company.

If these files do not have signatures or valid file properties, these files will fail the test case, but will NOT block achieving Works with designation.

Do not sign files that do not belong to your Product group or Company.

Do not assign file properties to files that do not belong to your Product Group or Company.

Document, no waiver required.

Documentation must include all 3rd party file names and owners which appear as failing the test cases.

Documentation must be public facing for the use and convenience of your Customers.

Documentation must be provided to test vendor upon submission.

Temporary files

Files in all temp folders that are expected to be deleted by Windows can be safely ignored. These may fail the test case, so must be documented as temporary files on which the application does not have a dependency.

Temp folders:

• Temp IIS, ASP, ASP.NET folders (transient files, or created on the fly, and expected to be deleted)
• Temp .NET folders
• Temp Java folders
• Temp Windows Installer folders (example: x:\Windows\Installer, many icon files appear here as 16 bit executables.)

Document temp files. No waiver required.

Interop files

Interop files do not contain file properties.

This known by Microsoft, no documentation required.

If built and owned by Product group or Company, Interop files must be signed.

Files using known binary extensions

Some (text, log) files used by application using known binary extensions must document these extensions, as they will fail without proper file properties or signatures. (Example, .sys, .bat, .com, etc.)

Internal Consistency Evaluators (ICE) Errors or Warnings in MSI packages

ALL ICE Errors appearing on logs must be fixed.

See ICE Error reference MSDN page for guidance on fixing.

ICE Warnings do not require a fix. All Warnings should be investigated, and as a Best Practice, should be fixed.

These are the ICE errors being validated in Works with Tool:

• (ICE) 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

Custom Action documentation

If using Windows Installer, all your Custom Actions must be documented

• Submit to test vendor
• Documentation should point to full documentation location on media or web page reference
• Test case is considered a failure until documentation is received by test vendor

Custom table starting with MSI : MsiSFCBypass or MsiDriverPackage

• This can be safely ignored. No Waiver required. This is an allowed MSI Prefixed Standard Table.

Custom Action documentation should be limited to a few lines with below information:

Custom Action Name

Brief description of function using key words as they apply:

• Registry modification, Internet Updates, database creation etc, that may be reversible if necessary by Customer
• Custom Action occurs during: Install, Commit, Rollback, and Uninstall
• Custom Action uses an executable, script(VB or Java script), or assembly
• Include workarounds, options, Rights management, location information
• Describe any properties the action needs or sets

Indicate in documentation when Custom Action documentation is embedded into the Custom Action to avoid delays

3^rd party Custom Actions

• To avoid delay, any 3^rd party Custom Action's should be clearly indicated in the submission package to the test vendor.
• Best practice is to document 3^rd party Custom Actions or point to web page where Customer may view Custom Action documentation used by your product.
• Indicate that 3^rd party Custom Actions have no external documentation.

Package Identity

Windows Installer packages must comply with ICE validation as well as identify installer package and properly prepare for upgrade.

To Pass this test case the Property Table and the Upgrade Table must contain:

Property Table:

• Manufacturer
• ProductCode
• ProductLanguage
• ProductName
• ProductVersion (major and minor)

Upgrade Table:

• UpgradeCode
• VersionMin
• VersionMax

The UpgradeCode in the Upgrade table must be identical to the UpgradeCode in the Property table.

Pass this test case if VersionMin and VersionMax are not BOTH null.

16 bit files found

Some installer programs create an icon file with an .exe extension. These will be flagged as failures, and appear as 16 bit files to Work with Tool.

If these are found in the C:\Windows\Installer directory or similar User redirected folder, these are considered to be installed into a temporary directory and can be documented as outside your control.

Be sure you do not own any files you list as 3rd party.

Waivers

As mentioned earlier, there will be very limited Waivers granted.

Examples: Logo Tool errors, Windows limitation, or technical documentation exists why no other workaround existed for exemption (very limited).

When Waiver is necessary, it must be sent to Microsoft for pre-approval, prior to sending submission package to test vendor. Waiver document can be downloaded from Innovate On web site.

Waivers are not required when only documentation is sufficient to detail test case issues as mentioned above.

Hope the above is helpful,

-PaulS