Windows NT Server, Enterprise Edition Administrator's Guide and Release Notes
| Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
Updated : September 1, 1997
This guide contains the following information:
An introduction to Windows NT Server, Enterprise Edition
A document roadmap to Windows NT Server, Enterprise Edition and its components.
Windows NT Server, Enterprise Edition installation considerations
Enabling 4 GB RAM tuning (4GT)
Clustering Microsoft Message Queue Server (MSMQ)
Clustering Microsoft Transaction Server (MTS)
Windows NT Client Access Licenses
Windows NT Server, Enterprise Edition limitations
Known problems of Windows NT Server, Enterprise Edition
Support information
The Windows NT Server, Enterprise Edition Administrator's Guide supersedes the Windows NT Server Version 4.0 product documentation. Where these documents disagree, rely on the Windows NT Server, Enterprise Edition Administrator's Guide.
On This Page
Introducing Windows NT Server, Enterprise Edition
Documentation Roadmap
Windows NT Server, Enterprise Edition Installation
Windows NT Server, Enterprise Edition Component Installation
4GT RAM Tuning
Clustering Windows NT Server Components
Windows NT Client Access Licenses
Windows NT Server, Enterprise Edition Limitations
Known Windows NT Server, Enterprise Edition Problems
Introducing Windows NT Server, Enterprise Edition
Windows NT Server, Enterprise Edition includes:
Windows NT Server
The foundation is Windows NT Server, an integrated, comprehensive, and easy-to-use server operating system. Windows NT Server provides fast file and print services, robust application support, standards-based communications features, and complete Internet and intranet functionality.
4 GB RAM Tuning (4GT)
With standard Windows NT Server, the per-process address limit is 2 gigabytes (GB) of random access memory (RAM). The 4GT feature of Windows NT Server, Enterprise Edition increases this limit to 3 GB without introducing new APIs. The 4GT does this by reducing the potential RAM allocated to the Windows NT kernel from 2 GB to 1 GB.
Licensed for use on up to 8-processor symmetric multiprocessing (SMP) servers. (Up to 32-processor support is available from some vendors selling original-equipment-manufacturer versions of Windows NT Server, Enterprise Edition.)
Microsoft Cluster Server (MSCS)
MSCS, when run on a validated two-server cluster configuration, automatically recovers from application or server failures to keep your data and applications online. It also enables you to move workload for balancing loads and to unload servers for planned maintenance without downtime.
Microsoft Transaction Server (MTS) version 1.1
MTS supports a powerful environment that makes it easier to develop and deploy high performance, scalable, and robust enterprise, Internet, and intranet applications. MTS defines an application programming model for developing distributed, component-based applications. It also provides a run-time infrastructure for deploying and managing these applications. MTS 1.1 includes MTS 1.0 plus MTS Service Pack 2A. The MTS Service Pack 2A includes a new client configuration utility, support for "Cedar" type libraries, and bug fixes.
Microsoft Message Queue Server (MSMQ)
MSMQ is a fast store-and-forward service that enables applications running at different times to communicate across heterogeneous networks and systems that may be temporarily off line. Applications send messages to MSMQ, and MSMQ uses queues of messages to ensure that the messages eventually reach their destinations. MSMQ provides guaranteed message delivery, efficient routing, security, and priority-based messaging.
Documentation Roadmap
In addition to the Windows NT Server, Enterprise Edition Administrator's Guide, the following documentation is available.
Hardware Compatibility Lists
Microsoft will publish server and cluster Hardware Compatibility Lists for Windows NT Server, Enterprise Edition when the product is released. At that time, Microsoft will only support Windows NT Server, Enterprise Edition when run on a validated platform that appears on one of those Hardware Compatibility Lists.
The beta versions of Windows NT Server, Enterprise Edition may be run with computers and peripherals that appear on the Windows NT Hardware Compatibility List (HCL). You can download the Windows NT HCL from the World Wide Web at:
Windows NT Server
Your primary source for information on core capabilities is the base Windows NT Server Version 4.0 documentation:
Windows NT Server Version 4.0 Start Here provides information you need to get started quickly, including Setup and Setup-troubleshooting instructions. If you do not have a copy of Windows NT Server 4.0 Start Here, the book is available in Microsoft Word .doc files in the \support folder on your Windows NT Server, Enterprise Edition Components CD.
Windows NT Server Version 4.0 Concepts and Planning contains information about implementing and optimizing Windows NT Server. To access the book online after installing Windows NT Server, Enterprise Edition, click Start, point to Programs, and click Books Online.
Windows NT Server Version 4.0 Networking Supplement contains information about networking tools, protocols, and services. To access the book online after installing Windows NT Server, Enterprise Edition, click Start, point to Programs, and click Books Online.
Additional information is available on the World Wide Web at https://www.microsoft.com/ntserver and in the Windows NT Server Resource Kit Version 4.0.
The online Help included with Windows NT Server is your quickest source for getting assistance when using the product.
Preinstallation issues are covered in the Setup.txt file. Platform-specific versions of this file are in the i386 and ALPHA folders on the Windows NT Server, Enterprise Edition Base CD.
Supplemental release notes are available in the Readme.wri file. Windows NT Server, Enterprise Edition Setup installs this file in your system32 folder (typically, C:\Winnt\system32).
Supplemental network and printing-related release notes are available in the Network.wri and Printer.wri files. Windows NT Server, Enterprise Edition Setup installs these files into your Windows NT folder (typically, C:\Winnt).
Microsoft Cluster Server
The following MSCS documentation is available:
MSCS Release Notes, which contain the latest available information on Microsoft Cluster Server, located in \MSCS\Readme.doc on Windows NT Server, Enterprise Edition Components CD
The MSCS Administrator's Guide, which covers concepts required to configure, install, and manage a cluster
MSCS Cluster Administrator Help, which contains context-sensitive descriptions of interface elements and step-by-step procedures, to guide you through common administrative tasks
Microsoft Message Queue Server
The following MSMQ documentation is available:
MSMQ Release Notes, which contain the latest available information on MSMQ, located in \MSMQ\Readme.doc on Windows NT Server, Enterprise Edition Components CD
The MSMQ Administrator's Guide, which covers concepts required to configure, install, and manage MSMQ
The MSMQ SDK Help, which covers MSMQ API usage
MSMQ Explorer Help, which contains context-sensitive help and procedures to guide you through common administrative tasks
Microsoft Transaction Server
MTS includes a Help file with the following documentation:
Readme
Getting Started
Programmer's Guide
Administrator's Guide
MTS Explorer
Frequently Asked Questions
MTS Product Support Information
The MTS version 1.1 release notes are located in \MTS\Readme.doc on Windows NT Server, Enterprise Edition Components CD.
Windows NT Server, Enterprise Edition Installation
The following sections cover the installation of Windows NT Server/E.
New Windows NT Server/E Installations
Upgrading Existing Windows NT Installations
Domain Considerations
Computer Name Considerations
Installing MSCS
Installing MSMQ
Installing MTS
Installing FrontPage 97
Installing Internet Information Server Version 3.0
Installing Debug Files
Reapplying Service Pack 3
New Windows NT Server/E Installations
Installing a new copy of Windows NT Server/E is a two step process:
First, install Windows NT Server/E in the same way that you install Windows NT Server.
After you install Windows NT Server/E, install Service Pack 3. (A prompt reminds you to do this each time you log in, until you have done so.)
Both steps are required to have a functioning Windows NT Server, Enterprise Edition system.
Before installing Windows NT Server, Enterprise Edition, ensure you are using appropriate hardware. For more information, see "Hardware Compatibility Lists" earlier in this document.
Note: Windows NT Server/E Setup places the following string into your Boot.ini file (for Intel processors) or NVRAM (for Alpha-based computers):
/maxmem=256
This string is used to resolve a memory-limitation issue that can occur with Windows NT 4.0 build 1381 on computers with more than 256 megabytes (MB) of physical memory. The Windows NT Server/E component installer removes this switch.
Note: If you plan to cluster MSMQ, it is recommended that you install Open Database Connectivity (ODBC) drivers during this stage of Windows NT Server/E installation.
To do so, make sure that you first select SQLServer on the list of available ODBC drivers when you are prompted to select one or more OBDC drivers, and only then click OK.
Upgrading Existing Windows NT Installations
Winnt32.exe should not be used to upgrade from an existing Windows NT Server installation to Windows NT Server/E if you are running Service Pack 2 or later. If you use Winnt32.exe to install Windows NT Server/E, and then apply Service Pack 3, your system is left in an inconsistent state with incorrect revision levels of some system components. This can cause severe problems, including reboot failures. To upgrade an existing Windows NT Server installation that is running Service Pack 2 or later, use Winntup.exe.
Note: Before installing Windows NT Server/E, ensure you are using appropriate hardware. For more information, see "Hardware Compatibility Lists" earlier in this document.
Using Winntup.exe to Upgrade to Windows NT Server/E
Winntup.exe can be used to upgrade existing Windows NT Server installations to Windows NT Server/E. Running Winntup.exe takes significantly less time to run than does Winnt32.exe, and your system never enters an inconsistent state. After running Winntup.exe, you must still install Service Pack 3 from the Windows NT Server/E Base CD (if Service Pack 3 or later is not already installed).
Note: Winntup.exe does not modify the maximum number of processors supported in your computer. Therefore, if you have a computer that you want to upgrade to Windows NT Server/E and also want to support more than four processors, you must install a new copy of Windows NT Server/E.
Winntup.exe cannot be used to upgrade a Windows NT Workstation installation to Windows NT Server/E. If you have a computer running Windows NT Workstation, you must install a new copy of Windows NT Server/E.
To start Winntup.exe, run the file from the \i386 folder or the \Alpha folder on the Windows NT Server/E 4.0 Base CD. You can also run Winntup.exe from the auto-run screen that appears when you place the Windows NT Server/E 4.0 Base CD into your CD-ROM drive.
Winnt32.exe Changes for Windows NT Server/E
If you attempt to upgrade an existing Windows NT Workstation or Windows NT Server installation that is running Service Pack 2 or later using Winnt32.exe, the following message appears:
You are installing Windows NT Server, Enterprise Edition on a system where a Windows NT Service Pack has been installed. Setup for Windows NT Server, Enterprise Edition is only to be used for a new installation.
Choose 'Cancel' and use the Windows NT Upgrade option to upgrade your current configuration.
If you click OK, Winnt32.exe continues installing Windows NT Server/E. However, if you specified the /u switch, Winnt32.exe exits when you click OK or Cancel -- Windows NT Server/E Winn32.exe does not support unattended upgrades. This change was introduced to prevent you from inadvertently moving backward from a later Service Pack to Service Pack 1.
Domain Considerations
If you intend to install MSCS, MSMQ, or MTS, you should first consider the impact of installing Windows NT Server, Enterprise Edition as a member server, backup domain controller (BDC), or primary domain controller (PDC). For example, if you install MSCS on member servers or on two BDCs in an existing domain, you preserve your existing domain model. If you create a new domain and install MSCS on a PDC and a BDC, you must establish domain trusts with your existing domains to enable users to access the MSCS servers. Installing MSMQ on BDCs or PDCs in a domain where account changes occur regularly or in which users log off and log on frequently can adversely affect MSMQ performance.
For more information on these issues, see "Choosing a Domain Model" in Chapter 2, "Planning Your Cluster Environment" of the Microsoft Cluster Server Administrator's Guide. For complete instructions on installing and troubleshooting Windows NT Server, Enterprise Edition Setup, see Windows NT Server Version 4.0 Start Here.
Computer Name Considerations
For compatibility with MSCS and MSMQ, it is recommended that the computer name should contain only English characters and/or ANSI characters below 128. The name should not contain extended characters.
Installing MSCS
MSCS can be installed from the Windows NT Server, Enterprise Edition Components CD. You can either select the Microsoft Cluster Server (MSCS) check box in the Windows NT Server, Enterprise Edition Installer, or run Setup.exe from the appropriate platform subfolder of the \MSCS\cluster folder on the Windows NT Server, Enterprise Edition Components CD.
For general information on installing MSCS, see Chapter 3, "Setting Up an MSCS Cluster," in the MSCS Administrator's Guide.
Installing MSMQ
MSMQ can be installed from the Windows NT Server, Enterprise Edition Components CD. You can either select the Microsoft Message Queue (MSMQ) check box on the Windows NT Server, Enterprise Edition component installation logon screen, or run Setup.exe from the \MSMQ\MSMQ\Server folder on the Windows NT Server, Enterprise Edition Components CD.
Note: If Microsoft Cluster Server (MSCS) is installed, you can only install MSMQ servers and independent clients as fail safe services – you cannot install them without configuring them as MSCS resources.
For general information on installing MSMQ, see Chapter 2, "Installing MSMQ," in the MSMQ Administrator's Guide. For specific instructions on installing MSMQ for failover in an MSCS cluster, see "Clustering MSMQ" later in this document.
Installing MTS
MTS can be installed from the Windows NT Server, Enterprise Edition Components CD. You can either select the Microsoft Transaction Server (MTS) check box on the Windows NT Server, Enterprise Edition component installation logon screen, or run Setup.exe from the appropriate platform subfolder of the \MTS\ folder on the Windows NT Server, Enterprise Edition Components CD.
For general information on installing MTS, run Mtx10.hlp from the appropriate platform subfolder of the \MTS\ folder on the Windows NT Server, Enterprise Edition Components CD. For specific instructions on installing MTS for failover in an MSCS cluster, see "Clustering MTS" later in this document.
Installing FrontPage 97
FrontPage 97 can be installed from the Windows NT Server, Enterprise Edition Components CD. You can either select the Microsoft FrontPage97 check box on the Windows NT Server, Enterprise Edition component installation logon screen, or run Setup.exe from the \FrontPg\i386 folder on the Windows NT Server, Enterprise Edition Components CD 2.
Installing Internet Information Server Version 3.0
Internet Information Server (IIS) 2.0, if currently installed, will be upgraded by Service Pack 3 to IIS 3.0. If IIS 2 is not currently installed, use the Network option in Control Panel to install IIS 2.0 (by clicking Add on the Services tab) and then upgrade to IIS 3.0 (by reinstalling Service Pack 3 or using the Windows NT Server, Enterprise Edition component installer.
Installing Debug Files
Debug files for MSCS, MSMQ, and MTS are located in the Windows NT Server, Enterprise Edition Components CD in the following path:
\Support\Symbols\Components\
Reapplying Service Pack 3
If you change or add new software or hardware components to your system after you have installed Service Pack 3, you must install Service Pack 3 again. You cannot install new components directly from the Service Pack folder (such as a new keyboard or printer driver). You must install new components from the Windows NT Server/E Base CD and then reinstall the Service Pack.
For example, if you install the SNMP service after installing Service Pack 3, you must reinstall the Service Pack. If you do not, the error "Entrypoint SnmpSvcGetEnterpriseOID could not be located in snmpapi.dll" appears because some of the files in the SNMP service have been updated in the Service Pack and you have a version mismatch. Reinstalling the Service Pack fixes the problem by copying the newer versions of the files to your system.
Note: If you are reinstalling the Service Pack after installing new software or hardware, you must choose to create a new uninstall directory. To indicate this, click Yes, I want to create an Uninstall directory when you are prompted.
Windows NT Server, Enterprise Edition Component Installation
Each time you log on, Windows NT Server, Enterprise Edition Setup:
Prompts you to install Service Pack 3 (if you have not already done so).
Gives you the option to install MSCS, MSMQ, MTS, FrontPage 97, and Internet Explorer 3.02 (after you have installed Service Pack 3).
You are not given the option to install MSCS, MSMQ, MTS, FrontPage 97, and Internet Explorer 3.02, until you have installed Service Pack 3. You can disable the logon prompt for installing these components by clicking to clear the Show this installer next time you start Windows NT check box on the logon install option screen.
Note: The Internet Information Server 3.0 upgrade option will upgrade an IIS 2.0 installation to IIS 3.0. If IIS 2 is not currently installed, open Control Panel, double-click Network, on the Services tab click Microsoft Internet Information Server, and then click OK. After installing IIS 2.0, you can upgrade to IIS 3.0.
If you choose to install multiple optional components, the installer installs each component in the appropriate order. If you click Cancel, you exit from only the install program that is running. For example, if you choose to install MSCS and MSMQ, and then click Cancel to exit from MSCS Setup, you much click Cancel twice more to exit from both MSMQ Setup and from the installer. This cancels the installation of both MSCS and MSMQ.
To run the component installer after disabling it (by clearing the Show this installer next time you start Windows NT check box), run Nhloader.exe from the Windows NT \system32 folder (typically C:\Winnt\system32).
4GT RAM Tuning
Applications developed for the Windows NT Server platform continue to grow, both in terms of size and performance demands. For applications that are I/O intensive, such as database management systems (DBMS), the use of a larger process space can provide considerable performance benefits as time-intensive I/O access to media is reduced.
With the current Windows NT Server product, the per-process address limit is 2 GB. The 4GT feature increases this limit to 3 GB without introducing new APIs. This is done by reducing the potential RAM allocated to the Windows NT kernel from 2 GB to 1 GB.
This feature benefits applications that run on powerful computers with more than 2 GB of physical RAM and that can take advantage of a larger address space. The impact on developers and applications are summarized in the following section, "Writing Applications for 4GT."
Note: If you install Windows NT Server after installing Windows NT Server/E, the 4GT option of Windows NT Server/E will no longer function. This is because Windows NT Server installs an older version of the OS loader. To enable the 4GT option, you must reinstall Windows NT Server/E on your computer.
Windows NT Server, Enterprise Edition supports 4GT on Intel Architecture servers. Microsoft is developing a superior Very Large Memory (VLM) technology for 64-bit processors, such as the Digital Alpha and Intel Merced. VLM and 4GT are mutually exclusive since they employ different algorithms. Therefore, there is no plan to offer 4GT on Digital Alpha servers. Note that 4GT works only on 32-bit processors, so it does not increase the addressable memory of Windows NT Server beyond its current limit of 4 GB. In contrast, VLM will exploit the 64-bit architecture of processors like Digital Alpha to support up to 32 GB of addressable memory, a potential eight-fold improvement for memory-intensive applications.
Writing Applications for 4GT
The following sections document:
User-mode Address Selection
Memory Allocation Issues
Effects Visible in Kernel-mode
User-mode Address Selection
When 4GT is enabled, the highest bit of a virtual address cannot be used to differentiate user-mode addresses from kernel-mode addresses.
Memory Allocation Issues
Some dynamic link library (DLL) files load near the 2 GB boundary; therefore, there is a region of the 2 GB space in which contiguous memory cannot be allocated using VirtualAlloc.
Effects Visible in Kernel-mode
Kernel-mode code can no longer assume the user-kernel boundary is at 0x80…0 or at any other number. Code that uses ProbeForRead/ProbeForWrite macros must be rebuilt using new headers that no longer contain assumptions about kernel space starting at 0x80000000.
Enabling 4GT Support in Your Applications
The changes to support 4GT are done at both the system and application levels.
System Changes
Once you have installed Windows NT Server, Enterprise Edition, you must modify the Boot.ini file to enable 4GT. To enable 4GT, simply add the /3GB parameter to the startup line. For example:
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINNT
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Windows NT Server Version 4.00" /3GB
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Windows NT Server Version 4.00 [VGA
mode]" /basevideo /sos/basevideo /sos
Application Changes
No new APIs are required for 4GT support. Instead, memory allocations remain the same, with the exceptions that are noted in the next section, "Tips for Effective 4GT Support."
However, it would be ineffective to automatically provide every application with a 3 GB address space. To provide a selective use of 4GT, executables that must see the 3 GB address space are required to have the bit IMAGE_FILE_LARGE_ADDRESS_AWARE set in their image header. This can be done using the Imagecfg tool that is included in the \Support directory on the Windows NT Server, Enterprise Edition compact disc. For example, to modify the target file DBMSApp.exe:
Imagecfg -l DBMSApp.exe
Note that the linker also has a new switch (/ LARGEADDRESSAWARE) to link executables with the IMAGE_FILE_LARGE_ADDRESS_AWARE bit. Setting this bit and then running the application on a system that does not have 4GT support should not affect the application.
Tips for Effective 4GT Support
The following guidelines are intended as a summary of changes that developers should review when considering enabling 4GT support within their applications:
Use GlobalMemoryStatus to get the amount of total user virtual space. Avoid using hard-wired constant definitions such as `#define HIGHEST_USER_ADDRESS 0xC0000000'. Try to detect the real value at runtime.
Avoid signed comparisons with pointers, which can cause some applications to fail on a 4GT-enabled system. A condition such as `if (pointer > 40000000)' will be false for a pointer that is above 2 GB.
Code using the highest bit to tag items (data value versus an address value) will fail. For example, a 32-bit word might be considered a user-mode address if it is below 0x80000000 and an error code if it is above that number.
Setting a Paging File Size
If you are using the 4GT option and have a system with more than 3 GB of physical memory, consider changing the default size of your page file. In the Windows NT operating system, the default paging file size is generally 11 MB larger than physical memory. On a 4 GB machine, this results in a 4.01 GB paging file. In this case, the effectiveness of this paging file is probably minimal. Using a 256 MB page file could be a better use of disk space in these circumstances. However, having a smaller paging size will affect the total memory-commit size for applications. You should review these settings with the application manufacturer for database and other applications that run with the 4GT option.
To change the paging-file setting, open Control Panel, which is on the Start menu under Settings. Double-click System. Then, click the Performance tab and, under Virtual Memory, click Change.
Setting the Windows NT Recovery Method
If Windows NT Server, Enterprise Edition encounters a STOP error while the 4GT option is enabled, you can have the system create a memory dump file to help you troubleshoot the problem. Ensure you have sufficient disk space to create and store a dump file for your system.
Also, the paging file in the root of the system partition must be large enough to hold all the physical RAM plus 1 MB.
To configure Windows NT Server to write a memory dump to a file
In Control Panel, double-click System.
On the Startup/Shutdown tab, select the Write debugging information to check box and then type the path and filename for the memory dump file.
For example, on a system with 3 GB of RAM:
Ensure you have at least 3 GB of free space on a single drive for the file Memory.dmp to be created.
Ensure that the paging file in the root of the system partition is at least 3 GB plus 1 MB. This is the minimum requirement for creating the memory dump file. However, the suggested minimum paging file size is the amount of physical ram plus 11 MB.
For more information about memory dump file creation, consult article 130536 in the Microsoft Knowledge Base at //www.microsoft.com/kb/default.asp.
Clustering Windows NT Server Components
This document covers:
Clustering Microsoft Message Queue Server
Clustering Microsoft Transaction Server
Clustering Internet Information Server
Clustering MSMQ
The following sections document how to cluster MSMQ servers and independent clients.
Note: If Microsoft Cluster Server (MSCS) is installed, you can install MSMQ servers and independent clients only as fail-safe services; you cannot install them without configuring them as MSCS resources.
Clustering MSMQ Servers
MSMQ servers can be installed and configured for failover on two-node MSCS clusters. This provides high availability of your MSMQ servers.
The installation of MSMQ servers on an MSCS cluster is identical to the installation of MSMQ servers on non-clustered Windows NT Server/E servers with the following exceptions:
MSCS must be installed on both nodes, and both must be online.
You must run MSMQ Setup twice.
You can cluster MSMQ controller servers (PECs, PSCs, and BSCs) with either the limited version of SQL Server 6.5 (provided on the Windows NT Server, Enterprise Edition Components CD) or SQL Server, Enterprise Edition. You cannot cluster MSMQ with the standard version of SQL Server 6.5. Note that if you use the limited version of SQL Server 6.5 in a cluster, you must allow MSMQ Setup to automatically install it.
To install an MSMQ server in an MSCS cluster
Use Cluster Administrator to make sure that the disk on the shared SCSI bus that will be used to store MSMQ program and data files is online on the first node on which you are going to install MSMQ ("node A").
Run MSMQ Server Setup, following the instructions in the MSMQ Administrator's Guide.
Make sure you store installation, data, and program files on a disk on the shared SCSI bus, and that the disk resource online on the node on which you are installing MSMQ. If necessary, click Change Folder in the Microsoft Message Queue dialog box and specify a different folder on that disk.
After the installation is complete, use Cluster Administrator on the first node (node A) to do the following:
Take MSMQ Service and MSDTC resources offline by right-clicking each of them and clicking Take Offline.
Move the Cluster Group to the second node (node B) by clicking Cluster Group under the Groups folder and then clicking Move Group.
Install MSMQ on the second node ("node B"). Specify the same settings that you used for the first installation and click Update existing database for the MQIS server.
Notes: When you install an MSMQ server and choose to create an MSMQ installation share, the installation share is created as an MSCS File Share resource, providing high availability of both the MSMQ server and the installation share.
The computer cryptographic private keys are stored in the local computer registry. These registry entries are replicated to other nodes in the cluster in clear text. It is recommended that the registry replication will be done through a secured media to ensure that the private cryptographic keys are not compromised.
Installing MSMQ into It's Own Group
Because the Cluster Group is generally reserved for core resources, and because it is best to group services with their corresponding resources to form specific resource groups, you should configure an MSMQ group before installing MSMQ so that all MSMQ resources are installed an configured in an MSMQ-specific group.
If MSMQ Setup does not find a Network Name resource and an IP Address resource in the group that contains the Physical Disk resource for the drive you specify during MSMQ installation, MSMQ Setup installs required resources in the Cluster Group. The MSMQ resources are then dependent on the Cluster Name resource, which is in turn dependent on the Cluster IP Address resource. Although Cluster Administrator can be used to change resource groupings and resource assignments, MSMQ does not support the reassignment of a new Network Name resource.
If MSMQ Setup finds a Network Name resource and IP Address resource in the group that contains the Physical Disk resource for the drive you specify during MSMQ installation, MSMQ Setup installs the MSMQ and SQL resources in that group. For example, you may create an MSMQ group that contains a Network Name resource, an IP Address resource, and a Physical Disk resource for drive L. When you install MSMQ and choose to store the program files on drive L, MSMQ Setup creates and configures all required resources in the MSMQ group. If MSMQ Setup require resources from other groups (for example, MSDTC, SQL and additional IP addresses) Setup will move them from the other groups to the MSMQ group, and set the required dependencies. However, these other resources must be online on the same node that setup is running on.
Clustering MSMQ Independent Clients
To install an MSMQ independent client in an MSCS cluster
Use Cluster Administrator to make sure that the disk on the shared SCSI bus that will be used to store MSMQ program and data files is online on the first node on which you are going to install MSMQ.
Run MSMQ independent client Setup, following the instructions in the MSMQ Administrator's Guide. Make sure you store the installation files on a disk on the shared SCSI bus. To do this, click Change Folder in the Microsoft Message Queue dialog box and specify a directory on that disk.
After the installation is complete, use Cluster Administrator to do the following:
Take MSMQ and MSDTC resources offline.
Move the resource group containing the MSMQ resource to the other node.
Install MSMQ on the second node. Specify the same settings that you used for the first installation.
Clustering Microsoft Transaction Server
The following sections document clustering of Microsoft Transaction Server.
Installing Microsoft Transaction Server
If you are planning on using SQL Server, please make sure that you install SQL Server v6.5 or above before installing the Microsoft Transaction Server.
Remove any existing installation of MTS on all machines in the cluster before proceeding.
To Install Microsoft Transaction Server on MSCS Clusters
Remove any existing MTS installations on cluster nodes if they exist.
Install the Microsoft SQL Server v6.5 on the cluster if needed (consult the readme instructions for SQL Server installation on MSCS clusters before installing).
Make sure that MSCS is installed on all machines in the cluster.
Run the MTS installation (SETUP.EXE) from the Microsoft Transaction Server installation CD. Install MTS on all computers in the same directory and path (for example C:\MTX). See the MTS documentation for more details about MTS Setup.
Restart the computers if the MTS setup requests you to do so.
Run the Cluster Administrator application. This application can be found on the "Start" menu under Programs\Administrative Tools (Common).
Using the Cluster Administrator create a Distributed Transaction Coordinator resource. The Distributed Transaction Coordinator resource must be created in a group that contains at least one resource either of type "Fault Tolerant Disk Set" or type "Physical Disk" and at least one resource of type "Network Name". This requirement exists because the Distributed Transaction Coordinator resource must depend on these resources. This dependency forms a virtual server containing the MSDTC service. The host name of the "Network Name" resource in a virtual server is the name of that virtual server. For more information on groups, resources, resource types and virtual servers please refer to the MSCS documentation. To create the Distributed Transaction Coordinator resource:
7.1 Note down the group that will contain the Distributed Transaction Coordinator resource
7.2 Using the File\New\Resource menu item create a new resource
7.3 Type "MSDTC" as the name and description of the new resource. Select "Distributed Transaction Coordinator" as the resource type. Select the group noted in step 7.1 as the group in which this resource should be created. Click on the "Next" button
7.4 Select all nodes in the cluster as possible owners of the Distributed Transaction Coordinator resource. Click on the "Next" button
7.5 Select a resource of type "Network Name" and a resource either of type "Fault Tolerant Disk Set" or type "Physical Disk" as dependencies for the MSDTC resource. Click on the "Finish" button
Change the location of the MS DTC log file. The MS DTC log file must be placed on the shared disk that MSDTC is dependent on (e.g. D:\). Change the location of the MS DTC log file on the primary machine in the cluster (the one which currently owns the shared disk that Distributed Transaction Coordinator depends upon). To change the location of the log file:
8.1 Run the Transaction Server Explorer which can be found on the "Start" menu under "Programs\Microsoft Transaction Server"
8.2 Right click on "My Computer" and select "Properties". Select the "Advanced" property page. Select the disk noted in step 7.5 as the drive on which the MS DTC log file should be created. Select the desired directory on that drive
8.3 Click on the "Reset Log" button to set the log file location and initialize the log
8.4 Click on the "OK" button to close the dialog box
Use the Cluster Administrator application to bring the MSDTC resource online
To Install Microsoft Transaction Server Packages on MSCS Clusters
If you are using .PAK files to install packages into the Microsoft Transaction Server then you must install all packages on all nodes in the cluster
If you have a packages on a node of the cluster that contains imported components then that package must first be exported. This exported package should then be installed on all the other nodes in the cluster.
Create the required data source names in ODBC for the package on all nodes (for example, for the Sample Bank Package: create the "MTxSamples" DSN). Make sure that the database your package is using is either on a shared SQL Server (outside the cluster) or is one that will fail over (see the instructions for Clustering SQL Server for details)
Create a "Generic Application" resource for the package. The resource must exist in the same group as the MSDTC resource and must depend on the MSDTC resource as well as the System Package Resource. The resource is created under the "Generic Application" resource type and should have a command line of: "MTX.EXE /p:{package guid}". The current directory for the resource should be the root MTX directory (e.g. C:\MTX). You can obtain the package guid by selecting the package ID from properties on the package from the MTS Explorer. Make sure to select "Use Network Name for Computer Name" on the resource. You can now bring the package resource online
Make sure that MSDTC is running on the computer with your database server
The MTS system package in a MSCS cluster should be configured as a MSCS resource. Please refer to the configuration instructions above.
Client Installation
Install the package on the client machine using the MTS Explorer (if using Windows NT clients). Change the "Activation" property on all components in the package to use the name of the virtual server containing the MSDTC resource. For example, if the MSDTC resource is in the "DTCSRV1" virtual server, type "DTCSRV1" in the "In a remote server process on the computer" edit box.
If you are using the CoCreateInstanceEx() API, make sure to use the name of the virtual server containing the MSDTC resource in the pwszName field of the COSERVERINFO structure used by the API (see the online documentation in the Win32 SDK for more details about CoCreateInstanceEx)
If you are using the client install executable created using the MTS Client Install Utility to install clients then you must get a list of the class id's for all the components that will be installed by the executable. After the client install executable is run you must modify the "RemoteServerName" named registry value under the registry key HKEY_CLASSES_ROOT \AppID{class id} for all the class id's that you had listed. The value of the "RemoteServerName" must be changed to use the name of the virtual server containing the MSDTC resource.
If you wish to use another installation technique for configuring client workstations to access server components running in MTS, please make sure to configure the "RemoteServerName" named registry value under the registry key HKEY_CLASSES_ROOT \AppID{your class id}. The value of the "RemoteServerName" must be changed to use the name of the virtual server containing the MSDTC resource.
When a node fails, MTS components fail over to the other node in the MSCS cluster. The client application must release all references to the MTS component(s) on the failing node, and re-instantiate the component(s). The component will be instantiated on the second node.
You can now run the client application
Steps for installing Microsoft Transaction Server Compatible Resource Manager (RM) resources
Ensure that these resources depend on the MSDTC resource
Ensure that the "Use Network Name" option is enabled
Limitations of the software
The steps mentioned above describe how to add failover support to Microsoft Transaction Server Version 1.1, a version of the software released prior to the release of MSCS v1.0. Thus this approach of adding failover support to MTS v1.1 has some limitations. These limitations are listed below:
At a given time only one node in the cluster will be running the MSDTC service and MTS Server Processes. MTS base clients and MTS components that need to access components running on a cluster must either be on a node outside the cluster or on the particular node within the cluster that is currently running the MSDTC service and MTS Server Processes.
The MTS Explorer should only be run on the node on which the MSDTC service is currently running. Running the MTS Explorer on the other node may result in inconsistent configuration on either node. Running the MTS Explorer causes an instance of the MTS process to be created, which persists even after the Explorer is shut down. This may cause errors during registry checkpointing. To prevent this, select the MTS system package, and change the Advanced | Server Process shutdown property from "never shutdown" to a time of 3 minutes.
The "Transaction List", the "Transaction Statistics" and the "Trace Messages" windows under the "My Computer" computer are not usable as they will not show any data. To view the data that you would normally see in these windows you must add a new computer in the MTS explorer. This new computer should have the name of the virtual server that contains the MSDTC resource. The corresponding windows in this new computer will contain all the data for that virtual server. Note: all other administration (e.g. adding package, changing roles) must be done using the "My Computer" computer on all nodes of the cluster. The changes made must exactly the same on all nodes.
If your components require ODBC data source names to connect databases, then these data source names must exist on all nodes of the cluster.
Do not use the "Stop MSDTC" and "Shutdown Server Processes" commands of the MTS Explorer. To achieve the equivalent of stopping MSDTC take the MSDTC resource off-line using the Cluster Administrator. To achieve the equivalent of shutting down all server processes take all the package resources off-line.
During failover in certain situations, MTS packages may not be instantiated in the correct context. To prevent this, launch security should be disabled on the MTS package.
Before the location or size of the DTC log file is modified, the DTC resource must be taken offline. The DTC resource must then be deleted. The log file can now be configured. The DTC resource must then be re-created - please refer to the instructions above.
These limitations will be removed from future versions of the software.
Clustering Internet Information Server
To create a highly available Internet Information Server installation
Install IIS version 3.0 or later on both nodes.
In Cluster Administrator, create a group that contains an IIS Virtual Root resource, IP Address resource, and Network Name resource.
Use Cluster Administrator to configure this group to fail over.
Windows NT Client Access Licenses
MSMQ and MTS do not limit the number of client/server sessions. However, MSMQ and MTS do count against the maximum number of Windows NT Server client access licenses (CALs), so Windows NT Server will restrict concurrent client sessions accordingly. MSMQ and MTS support both Per Server and Per Seat Windows NT Server CALs.
For more information on CALs, see Microsoft Windows NT Server Version 4.0 Concepts and Planning, Chapter 12, "Licensing and License Manager."
Windows NT Server, Enterprise Edition Limitations
This section documents the known Windows NT Server, Enterprise Edition limitations.
Language Packs Not Supported
Language packs support international character sets under the standard release of Windows NT Server version 4.0. Windows NT Server, Enterprise Edition does not support language packs. However, Windows NT Server, Enterprise Edition will be available in additional languages.
Known Windows NT Server, Enterprise Edition Problems
The following sections document known problems with Windows NT Server, Enterprise Edition.
ODBC Version Errors When Installing Software
When you install applications that use ODBC components, errors might appear indicating mismatched ODBC version numbers. With Windows NT Server/E, these errors can occur after you install an MSMQ controller server (PEC, PSC, or BSC), Microsoft Transaction Server, or SQL Server 6.5, and then attempt to install IIS 3.0. Despite these error warnings, the components will function properly.
You can avoid these errors by stopping SQL Server, Microsoft Transaction Server, or any other ODBC application prior to installing IIS.
Error on Digital Alpha Servers: Not enough memory to install
On Digital Alpha Servers, attempts to install applications on a system with more than 4 GB of memory produce the error "Not enough memory to install." By limiting the memory size to 2 GB, you can avoid this error.
To limit the memory size to 2 GB
From AlphaBIOS, press F2 to go into setup.
Select CMOS Setup.
Press F6 to go into Advanced CMOS Setup.
Change the 2 GB memory limit to Enabled and save.
Reset the system and then boot Windows NT with the 2 GB memory limit.
Complete the installation of any applications that have trouble with more than 2 GB of memory.
Reboot the system to AlphaBIOS and change the 2-Gbyte memory limit to Disabled.
Digital Alpha Servers: /maxmem=256 Value in NVRAM
After installing Windows NT Server/E on an Alpha computer, the value "/maxmem=256" will be left in the NVRAM configuration. This value does not affect the operation of your computer. However, you can use the AlphaBios setup program to remove this value.
To remove the /maxmem=256 value
Start the AlphaBIOS setup by restarting the server and pressing F2 during initialization.
Select OS Selection.
Press F6 to edit.
Remove the /maxmem=256 option from the OS Options: box.
Press F10 to save the changes.
Restart your computer.
Additional Known Problems
You can find more information about the known problems of Windows NT Server, Enterprise Edition in the following locations.
Note: Microsoft encourages customers to regularly check https://www.microsoft.com/support for information the latest hot fixes and Service Packs.
Service Pack 3 Readme
Windows NT Server, Enterprise Edition includes Windows NT Service Pack 3. For a list of known problems for Service Pack 3, see the Service Pack 3 Readme.txt file in the \Sp3 folder on your Windows NT Server, Enterprise Edition Base CD.
MSCS 1.0
For a list of known problems for MSCS, see the MSCS Readme.doc file in the \MSCS folder on your Windows NT Server, Enterprise Edition Components CD.
MSMQ 1.0
For a list of known problems for MSMQ, see the MSMQ Readme.doc file in the \MSMQ folder on your Windows NT Server, Enterprise Edition Components CD.