Microsoft Transaction Server Installation Tips
A reader sent in some tips, which he developed over several weeks of trial-and-error builds on servers and workstations, for installing Microsoft Transaction Server (MTS) from the Windows NT 4.0 Option Pack. His group determined that MTS won’t install or won’t update correctly if any of the following are true:
- If you originally install MTS on top of Service Pack 3 (SP3) to a drive other than the default, C:\.
- If you originally install MTS on top of any service pack other than SP3.
- If you apply the Microsoft Data Access Components (MDAC) updates out of sequence (e.g., 1.5, 2.1, 2.01, 2.2).
Microsoft has released two MTS hotfixes, Q195015_i386.exe and Q196021_i386.exe, that address the first two of these nasty installation problems (you have to contact Microsoft Support to get them). The MDAC services pack issue is still a problem; our fellow administrator recommends that you confirm the MDAC version at each pause point in the MTS build.
A New Microsoft Search Page
I tried Microsoft’s new generic search page recently and had good results, even when digging for arcane details. The search dialog box (http://search.microsoft.com/us/SearchMS.asp), the second generation of the generic Microsoft Web site search page, is a two-tabbed box. The first tab offers checkboxes for all major categories of information—I usually check "IT Resources" and "Support and the Knowledge Base." The second tab (Search within Results), appears with a list of matches after you submit a query. Here you can enter a secondary keyword or phrase to further refine your search.
When I searched for "create a Web folder," the search engine returned 17 matches, nearly all relevant. For comparison, I entered the same search string at the TechNet search page (http://www.microsoft.com/technet/ support/search.htm?FR=1) and got 81 matches, most not relevant. So the next time you’re trying to find an answer, see if you get better results with the improved generic search page, and let me know how it goes.
Personal Web Server and Windows 9x
According to several Microsoft Support Online articles, Microsoft Personal Web Server (PWS) might not be quite ready for prime time. Here’s a list of articles you might find helpful in troubleshooting PWS problems. Given our collective experiences with the Windows NT 4.0 Option Pack, this list is hardly reassuring.
Microsoft Support Online article Q158721 (http://support.microsoft.com/support/ kb/articles/Q158/7/21.asp) contains reasonably straightforward instructions for installing and configuring HTTP and FTP on a Windows 9x PWS. Although the article doesn’t mention NT, I believe you can also install PWS on NT Workstation or Server. The article also discusses several PWS authentication options.
PWS installs into different folders, depending on whether you use a distribution CD-ROM or a download version. Microsoft Support Online article Q158414 (http://support.microsoft.com/support/ kb/articles/Q158/4/14.asp) documents the installation difference between the two versions.
If you install PWS on a system created from a network share point, the PWS installer can’t find four files. You can find instructions on how to copy these missing files in Microsoft Support Online article Q173189 (http://support.microsoft.com/support/ kb/articles/Q173/1/89.asp).
In some circumstances, PWS doesn’t appear in the list of installed applications, which of course means you can’t remove it by clicking the Add/Remove button in the Add/Remove Programs applet. If you encounter this problem, check out Microsoft Support Online article Q188681 (http://support.microsoft.com/support/ kb/articles/Q188/6/81.asp) to learn how to manually peel it off of your system.
More Option Pack Commentary
I now understand why I had an impossible time trying to a running version of Office Server Extensions—Office Server Extensions requires Microsoft Transaction Server (MTS). I installed Office Server Extensions and MTS on top of Service Pack 5 (SP5), and I didn’t have any hotfixes at the ready. Clearly, Windows NT 4.0 Option Pack software is out of control. We shouldn’t have to suffer through weeks of experimentation to get a prototype application running successfully. Those of us committed to the NT platform are suffering well beyond what’s reasonable. We don’t design our IT budgets to support testing and debugging software that should be production ready.
If Microsoft expects us to adopt these products, it’ll have to do a much better job of packaging each NT Option Pack application with the latest mandatory updates, including the myriad of Y2K fixes tacked on at unpredictable but frequent intervals. If Microsoft plans to build additional products like Office Server Extensions on top of Option Pack applications, we need to have absolute confidence in each layer with respect to installation and troubleshooting. Unfortunately, with the current condition of the Option Pack, we have no hope of reaching the solid state we need for production systems after three or four layers. Can you imagine trying to get MTS, Index Server, or other products to run on Windows 2000 (Win2K)? I sure can’t.
I recommend that the NT Option Pack team rebuild every application with the latest required updates, thoroughly test each installation procedure, completely document all required installation and configuration steps, clearly identify order dependencies, and test each application standalone and with all others. Once the applications pass rigorous quality assurance testing, the NT Option Pack team can package each component individually for public download and ship an updated MSDN distribution CD-ROM. If Microsoft doesn’t provide current tested builds, order dependencies, and comprehensive installation and configuration procedures, I advise you to stay away from this entire suite of software, including Office Server Extensions.
IT departments face similar packaging challenges each time they update the corporate infrastructure. I know—I’ve worked on many infrastructure projects, including one that received Microsoft’s top award this year. As such, I think it’s fair to compare the challenges of deploying a new standard workstation to Microsoft’s challenge of creating a working NT Option Pack. Success requires rigorous testing and meticulous attention to detail.
Part of every infrastructure project involves updating the desktop. Because desktop workstations come in many flavors, our images must accommodate the differences in workstation hardware—which translates to creating endless versions of a baseline image and testing it against 10 or more motherboards and many combinations of internal components and peripherals. In a worldwide deployment, we also have to build images in multiple languages. Once we have a working baseline, we adjust the image to support numerous combinations of video boards, network adapter cards, and peripherals. Two common solutions exist for managing these differences: a baseline image that works on a specific hardware configuration combined with a second installation round of tested drivers or a full library of images organized by workstation hardware components that include the requisite drivers. A third solution entails replacing old workstations with new standard hardware so we can use the same image for the majority of the desktops. And we must carefully document every installation procedure to ensure reproducible results and IT credibility.
If IT departments followed Microsoft’s lead with the NT Option Pack, every CIO in the country would be looking for a new job. Imagine deploying a workstation that works only part of the time and responding to users with, "Oh, just reinstall all your applications, and while you’re at it, apply these 16 hotfixes, 27 bug fixes, and 9 Y2K fixes. And oh, by the way, we don’t have any comprehensive installation instructions or a recommended order in which to apply the updates."
