Now I'm sure Robert didn't think this opening remark would attract so much attention because it really isn't the focus of the video. Still it jumped out at me since back in September I blogged about a friend sent me an email detailing that MSI was dropped as a requirement for the Vista Server Logo program. I was really curious to find out if Robert had simply misspoken or if my information was wrong our out dated.
Recently Robert communicated via the Windows Installer team blog:
In recent multi-blog conversations between Windows Installer experts Aaron Stebner, Christopher Painter, and Stefan Krueger, it was noted that my statement that 'Windows Server 2008 logo would require Windows Installer' in the Channel 9 video Application Compatibility - MSI Installer Issues was out of sync with the published requirements.
Sure enough, the Windows Server 2008 Logo team demoted this from a requirement to a recommendation. Unfortunately the Windows Server 2008 Logo didn't let me know they had decided to do this.
Robert also went on to accept responsibility but I feel this is completely unneeded as it isn't his fault that a requirements change wasn't communicated back to him. Regardless, the question is now answered and I'm very grateful to Robert for doing so. More importantly though he gives very good perspective into the `why` so I highly encourage you to read the blog.
I only have two additional comments related to the `why`. First is I've seen many times in my career that developers/managers grasping at straws to put together a installation requirements or design document together will reference the logo requirement by proxy. From Roberts comments the logo program is a marketing program not a standard program so this association may be incorrect. Still it's sometimes difficult to put installation requirements to paper so I doubt that this practice will end.
The second comment is somewhat a question: For those of you in IT organizations, what attitudes do you see towards server care and feeding versus workstation care and feeding?
The reality is, from perspectives, a server is just a glorified workstation. You would think that MSI would automatically be good for both. In my current role at an ISV I have adopted MSI for my server installs as well as my client installs.
However, I remember at Continental Airlines that many people were very skeptical of automating server side deployment. Sure there were a few visionaries like the Sr. Director of Technology that I worked for who wanted to be able to use a graphical designer tool to cause the provisioning and configuration of a brand new blade through tools like ADS, DSI, GPO, AD, SMS and MSI. But many people who otherwise adjusted well to client side automation would get very defensive when you started talking about changing server side processes. If you suggested replacing an old, incomplete, outdated manual process with a zero touch automated process they would be practically afraid to death of the change. If you suggested using GPO, SMS or WSUS to manage these servers they would freak! I don't know if it was inexperience or just protectionism, but the moment you started mentioning production servers everything had to be done by hand.
So perhaps the server community isn't really ready for MSI yet anyways. What does your experience tell you?
3 comments:
Chris,
I'm not really responding to any of your comments directly. I'm just throwing stuff out there as someone who is currently going through the Windows Server 2008 Logo Certification for my product.
Most of the problems I've had to date actually come from the application code side rather than from the install/MSI package. For example, all binaries (executable files, activeX controls, dynamic link libraries, etc.) must be digitally signed as well as have the appropriate requestedPrivileges attribute set in a manifest (either embedded or external manifest). This can be quite annoying if you have a lot of legacy applications to distribute. We actually have legacy binaries compiled using Borland, Delphi, and a couple of other non-Microsoft compilers and those binaries don't accept a digital signature. Other issues relate to kernel mode drivers not being properly authored to meet Microsoft standards (all drivers installed by a logo certified application must be signed by Windows Hardware Quality Labs [WHQL], pass all WHQL tests, and pass all driver tests in the certification tests). That requirement can also be a problem for companies that compile their services to run on different platforms (in my experience, those are the ones most likely to ignore the Windows standards - whether intentionally or not). These have been my two biggest problems so far. The installation requirements for certification (Chapter 2 of the Windows Server 2008 Logo Certification Framework document, see link below) are pretty easy to follow if you're using MSI [and I agree w/ you that Robert can't be blamed for not knowing that MSI was dropped as a requirement - the latest framework document was just released on 1/8/08!, which is another annoying part of this process: MS keeps changing the rules before 2K8 even ships!). Evidently, we're not the only ones having these problems (as Application Compatibility for Windows Vista forum shows [RSS=http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=904&SiteID=1]). In fact, our VeriTest contact has mentioned that a only a very low number of applications have actually been certified thus far.
If anyone is considering Windows Server 2008 Certification, I HIGHLY recommend installing the Certification Tool and using it to do all your Vendor testing. It is the exact tool that VeriTest will use to run the tests and is quite easy to use. In fact, I created a VM for our employees to use that has everything installed for testing and includes recommendations for how to set up the Certification Tool (requires a SQL database to connect to). A copy of the readme is below and shows all the applications and tools necessary to run the certification tests. Most people start by downloading the Microsoft Certified for Windows Server 2008 Application Test Framework document (http://microsoft.mrmpslc.com/InnovateOnWindowsServer/redirect.aspx?u=http://download.microsoft.com/download/7/9/5/7959e7ea-f788-41cb-8b57-67bd122eb9b4/WindowsServer2008SoftwareLogoTestFramework.doc) and struggling through it (currently 230 pages). But if you just download the Word doc and then install the Certification Tool, the tool will pull in all the requirements from the document and is a MUCH easier way to start the in-house Vendor testing required prior to certification submission.
Basically, anyone doing this should START HERE: http://microsoft.mrmpslc.com/InnovateOnWindowsServer/Resources.aspx
I hope this helps your readers who may be looking for Windows Certification!!
BEGIN VM README++++++++++++++++++++++
LOGO CERTIFICATION SOFTWARE INSTALLED
=====================================
Application Verifier (x64) (3.4.158)
Certification Tool (x64) (1.0) [requires configuration, see info below]
Debugging Tools for Windows 64-bit (6.8.4.0)
Explorer Suite (5.0.0)
Explorer Suite II (unknown)
Log Parser 2.2 (2.2.10)
Logo Testing Tools for Windows (1.0.0)
Logo Testing Tools for Windows Server (1.00.0000)
Microsoft Works with Tool (1.0.0)
MsiVal2 (3.1.5346.000)
Orca (3.1.5299.0000)
Windows System State Analyzer (1.0.0)
OTHER SOFTWARE INSTALLED
========================
VMWare Tools (3.1.0000)
Adobe Acrobat Reader 8.1.1 (8.1.1)
Microsoft Office Word Viewer 2003 (11.0.8173.0)
Drivers for Your Printer
WINDOWS FIREWALL CONFIGURATION
==============================
Allow Remote Desktop (Logo Cert req.)
Allow Windows Management Instrumentation (Logo Cert req.)
CERTIFICATION TOOL CONFIGURATION
================================
I. Copy MyApp.msi Installations
a. Browse to the location of your application.
b. Copy the files/folders to the local system.
II. Re-install MSI Validation Utility (sysprep run on the VM wipes this out for some reason)
a. Browse to C:\WSLogo_Tools\Installs\ and double click on 'MsiVal2.msi' to start the installation.
b. Select the 'Complete' option to install the utility.
III. Check Setup Test Environment
a. Browse to printer_share
b. Select "your_printer" and click 'connect' from the right-click menu.
c. Install printer drivers
d. Set the default printer (Start-->Settings-->Printers).
e. Open C:\WSLogo_Tools\Reference\WindowsServer2008SoftwareLogoTestFramework.doc
f. Go to page 11 and review "Preparing the Test Environment" and verify
each of the settings specified are properly configured on the VM.
VI. Print the Certification Tests Checklist
a. Open C:\WSLogo_Tools\Reference\WindowsServer2008SoftwareLogoTestFramework.doc
b. Print pages 184-191.
V. Configure Certification Tool application
a. Start-->Programs-->Microsoft-->Certification Tool
b. set up the SQL Server connection (Tools --> Preferences):
Server Name = ??
Authentication = ??
User Name = ??
Password = ??
Database = ??
Change Report Files Path = C:\WSLogo_Cert\MyApp_Cert\Reports\
Change Log Files Path = C:\WSLogo_Cert\MyApp_Cert\Logs\
c. Click 'Start a new Certification' (or select an existing Certification under 'Resume Certification')
d. Select 'Information' from the left-hand view pane.
e. Click the plus sign in the right-hand view pane to import machine configuration settings.
f. Click the 'Tool Box' tab in the right-hand view pane, then the 'import' button and browse
to the exported tool box settings XML file (same location as this readme).
VI. Test Application
a. For each Test Case, read the information on the 'Test Objectives' tab.
b. Follow the steps listed on the 'Test Steps' tab. You can use the 'Launch' button at the bottom
of the page to launch any scripts listed in the Tool Box. I recommend creating a script for
each Test Case (see the Tool Box tab). If you do create scripts, remember to 'export' the Tool
Box and save the XML file in the same location as this readme. Regardless of whether you use
a test script or not, EXECUTE ALL PROCESSES FROM THE TOOL USING THE LAUNCH BUTTON. If the
process generates a log file, add a reference link to the log file into the database using the
Logs/Other files section at the bottom of the 'Test results' tab. The file itself is NOT
imported into the database, only a link to the file is created so make sure you follow the next
step before exiting the tool to backup the log files to a permanent location.
c. WHEN EXITING THE TOOL, SELECT 'YES' when prompted with the 'Would you like to back up log files
on the local machine to a safe location?' dialog. Browse to a STATIC/PERMANENT network share
and create the folder 'MyApp_Cert' and select the folder as the target of the backup. Also check
the 'Overwrite if file(s) exists' option then click 'Start backup'. This will copy all log files
generated by your testing (and referenced in the database) to a permanent location so they are
not lost when you re-set the VM.
END VM README++++++++++++++++++++++
Good to learn that the Certification Tool is handy.
The requirements around file signatures, manifests and driver signing are of huge benefits to Customers, particularly with the Server OS moving towards a 64-bit only platform.
Also note that the Server Logo team at Microsoft acknowledges that third party binaries included in ISVs products may not comply with some requirements and hence have granted limited waivers to ISVs, only requiring them to document such binaries.
That said, some of the remarks made in this blog are not accurate.
For example the Server Logo team did not change rules midstream. Also the latest test framework document released on 1/8/08 is merely an updated document with better worded tests that include additional notes/clarifications. There were no changes made to the requirements or tests themselves.
If you found the Certification Tool useful, you may also find the Works with tool and the System State Analyzer handy.
Download from here: http://microsoft.mrmpslc.com/InnovateOnWindowsServer/Resources.aspx
The comment about the requirement being dropped was from the Windows Installer Team, I merely quoted it. Interestingly though, that blog is no longer available on their website.
Post a Comment