Do you find the Support WebCast transcripts helpful?
Let us know!

Note This document is based on the original spoken WebCast transcript. It has been edited for clarity.

Steve Mathias: Today we are going to talk about Microsoft® Windows® .NET Server 2003 server clustering. We're going to do a little comparison of Windows .NET server clustering to Windows 2000 server clustering, and we'll discuss the new features of Windows .NET server clustering.

My name is Steve Mathias. I'm currently in Alliance Support. The objectives of this WebCast (slide 2) will be first to go over the new features of this technology. We will not be talking about Network Load Balancing (NLB) or some of the other Application Center clustering. We'll be focusing on the MSCS Cluster Service technology.

Here we have the basic agenda (slide 3). We'll quickly talk about how server clustering works in general. Then we will go on to the new features. At the very end there are a couple of links to some of the new features, and where to get some more information.

For those of you familiar with Windows 2000 or even Windows NT® 4.0 Enterprise Edition clustering, Windows .NET clustering builds on those as foundations (slide 4). The basic goals of clustering in .NET are to maintain high availability and to have scalability for mission-critical applications like SQL Server™ and Exchange, or services like file and print services, and so on. The goals are, for the most part, unchanged.

The main goal of clustering technology is to protect against downtime (slide 5). You want to protect against application failure or service failure. You also want to protect against certain hardware failure, if we lose a node, with CPU or drivers, or a drive or network adapters, for example. We want to be able to protect against any type of hardware failure. Last, for any downtime from maintenance, service pack or hotfix installation, updating hardware, replacing network cards with faster network cards, and so on, we want the application or services to still be available during some of these upgrades, so that we can perform rolling upgrades. This is a term we will often use.

When we look at a cluster (slide 6), a cluster is a group of independent systems that appear as a single logical system under a single namespace. Users will simply go to a single server that they see on the network. A logon script or Visual Basic® scripts will connect to a single namespace. Then one of the nodes will host that particular namespace. We can lose one of the nodes, and that logical entity, single namespace, or virtual server, as it will be called, will always be available to clients, services, or applications.

Windows .NET Server 2003 server clustering is still based on what's called the "Shared Nothing Model" versus the "Shared Everything Model." The "Shared Nothing Model" is basically where one node in the cluster will be hosting an application or a resource, and only one node at a time. If that node goes down or we want to take it down for maintenance, those resources that were owned by that node are transferred to another node in the cluster. A "Shared Everything Model" is different, and it's where all the resources in the cluster can be owned by any resource in the cluster. Again, Windows .NET Server 2003 server clustering follows Windows 2000 and Windows NT 4.0, with the "Shared Nothing Model." It is the same.

When we look at some of the new features in Windows .NET (slide 7), Windows .NET Server 2003 server clustering is supported in the Enterprise Edition and Datacenter Edition of Windows .NET Server 2003. Both of those products will support eight-node clustering. Windows 2000 Advanced Server supports two nodes. Windows 2000 Datacenter Server supports four nodes. But Windows .NET Server 2003 Enterprise and Datacenter Edition servers will support eight-node clustering. Windows .NET Server 2003 Standard Edition does not have a server clustering product in it, only the Enterprise Edition and Datacenter Edition have that.

Server clustering is supported on the IA-64 platform or 64-bit version of the Windows .NET Server 2003, running the same amount of nodes, eight nodes, in both of those products. However, you cannot mix x86-based nodes and IA-64-based nodes (64-bit nodes) in the same cluster.

In Windows .NET, the Cluster Services are installed by default (slide 8), which means you no longer have to worry about when to configure the cluster, like when to provide a Windows CD or a service pack CD. The files are always there. That makes configuration easier. The entire installation of the cluster software has been revamped. There are half as many dialog boxes to go through, and we use some heuristics or logic to determine which disk is a Quorum disk and how to configure the networks. There is an Advance button so that some of these options, especially when it comes to the disk management (when you're configuring or installing the cluster in a SAN environment), are a little bit easier. When you add a node to a cluster, that newly added node does not interrupt services on the other nodes in the cluster.

For installation, you no longer go through Add/Remove Programs, as you do in Windows 2000 (slide 9). The cluster software, the files, and the binaries are already installed. Simply launch Cluster Administrator and you'll have an option to create or join a new cluster. You can join multiple clusters at once. You would have to create your initial cluster first, the first node in the cluster that you can do from one node. And then if you had a seven-node cluster, you could actually configure them all at the same time. Enter the names of all seven other nodes, and it will configure the cluster software remotely on the other seven nodes. We can also use Cluster.exe to configure the cluster. It makes it easy for scripting, or if you have a lot of cluster nodes and new clusters to create, you can script the installation with Cluster.exe.

Along with installation of a cluster, often you want to be able to evict a cluster node (slide 10). The eviction process is easier than it was in Windows 2000. You simply use Cluster Administrator and evict the node. When you evict that node, the cluster software will contact that node and unconfigure the Cluster Services. The binaries will stay on the disk. However, the service will be shut down, and the drivers that go along with the Cluster Services will also be removed. There is no restart required when you evict a node.

In Windows 2000, we had to configure it to perform a local Quorum installation only during install time. In Windows .NET you can create a local Quorum at any time. The only caveat with that is you can only be one node up. You cannot use Local Quorum if you have more than one node. Local Quorum is typically used for testing applications when you don't want to spend money on a full cluster to simply test a cluster application. Local Quorum installation is still available after the fact.

Cluster software installation in Windows .NET now has an analysis phase (slide 11). The analysis phase will look at the machine and detect any possible issues with the hardware configuration. It will also detect any issues with possible software configuration. You will get a report on screen. As we'll see later, you can save the report as a log file.

On this next slide we have a screen shot of the analysis phase (slide 12). At this point everything is okay, there are no warnings. But, as you can see, we're scrolled all the way to the bottom here, and these are less than half of the items that we check.

When we go to the next slide (slide 13) you'll see a screen shot of a possible error. You'll see a symbol for errors, and an explanation. There are three levels of errors during setup. You have a check mark, a yellow exclamation point, and a red X, which indicates that the configuration of the cluster cannot go forward in the current state.

The yellow exclamation point is a warning. The installation will be allowed to go through, but as it shows here, the cluster is only detecting one network card on each node. As those of you who deal with Windows NT 4.0 or Windows 2000 know, you want to have multiple network cards available for the cluster software, for redundancy. It's giving a warning here. You can click the Details button to get more detail. There are links to articles and help files that you can access through the Details button.

Suppose with this particular issue we go out and see that one of the network cards was disabled; we can fix that and then click the Re-analyze button. We do not have to cancel setup. We can simply click the Re-analyze button. It will go through that analysis phase again.

The analysis phase is checking for some basic hardware and making sure that all nodes have access to the shared disks; that is new (slide 14). It's going to verify that all nodes in the cluster have access to the shared disks. It's going to verify that all the shared disks are formatted NTFS, that they all are basic disks, not dynamic. It's going to look at some basic network configuration in multiple paths. Are any of the network cards using DHCP? All networks in the cluster should typically be using static IP addresses. And there are several other things.

At the end of setup we get a proposal. Here's a screen shot of that proposed configuration (slide 15). This is after we've gone through the analysis phase and it's listing how it's going to configure the cluster, the name, the IP addresses, the different networks, the service account that it's going to be using, and so on. At this point if you see something in here you do not like, you can change it. One option you also see here is a Quorum button. As I stated earlier, the cluster software will detect the smallest NTFS-formatted hard drive on the shared bus that is 500 MB or larger and formatted. At that point it will pick that disk as the Quorum. If for some reason we have multiple disks that fit those criteria and the cluster software picks the incorrect disk that you want as your Quorum disk, click the Quorum button and move it. You can also move it after the cluster is fully installed.

There are some issues with the software configuration that the analysis phase looks for (slide 16). NLB, the Network Load Balancing service, should not be installed on server clusters, and you'll get a warning about that.

Terminal Services in Application mode are supported on a cluster. However, you cannot fail over to Terminal Services. This is a change from Windows 2000. In Windows 2000, Terminal Services in the Application mode and the Cluster Services were mutually exclusive, meaning that you could not have Terminal Services in Application mode running on a server cluster. It was actually blocked in the interface. In Windows .NET you can have Terminal Services in Application mode, but you cannot fail over Terminal Services. It's still primarily for remote administration, or possibly if you want to use the passive node as an Application Terminal Server.

We still require domain access for a service account; that is the same.

The version of the joining nodes — you can have a Windows .NET node and a Windows 2000 node in the same cluster. However, you cannot have a Windows NT 4.0 node and a Windows .NET node in the same cluster. There can only be one version difference between the operating systems. If you have a Windows NT 4.0 cluster that you want to upgrade to Windows .NET, there are instructions on how to do that, but you cannot take advantage of a rolling upgrade. You have to either do a rolling upgrade to Windows 2000 and then upgrade to Windows .NET, or you could perform an offline upgrade from Windows NT 4.0 to Windows .NET, but not a rolling upgrade.

As I mentioned earlier, when you go through the installation in the analyze phase, all of that information is saved to a log file (slide 17). The path is listed here (%SystemRoot%\System32\LogFiles\Cluster\ClCfgsrv.log). This is great for reviewing the information after the fact, and it's also great for archiving, so that if you have a problem down the road you can refer back to the log to see how the cluster was previously configured, to see if something has changed.

Moving forward with the new enhancements in storage (slide 18), we now have volume mount point support. Windows 2000 could not use the volume mount point feature on a server cluster. The volume mount point, for those who don't know, allows a drive or the disk to be grafted on to another disk so that target disk does not have a drive letter. The key point of this is to get around the 23-drive letter limitation. This is fine in Windows 2000, except when it's on a server cluster. In Windows .NET you can now use disks that have no drive letter, that are grafted to another disk with a volume mount point.

This goes into the next bullet, which is that no drive letter is required. The shared disks on the cluster do not have to have drive letters if you have an application that can explicitly write to a device. Some applications can be written to talk not to a drive letter but directly to a device. You can now use those types of applications on a server cluster.

The client-side caching is another feature in Windows 2000 that did not work properly when it was used on a cluster. Client-side caching, for those of you who don't know, is used to store client information like the My Documents folders, and cache it to make it available when it's off the network. If you have a laptop and you want to have client files available when you're at the airport, you can use client-side caching. So that way when you're at the home office, you can get your files, then cache them locally on your laptop, so that those files are available when you leave. However, in Windows 2000, if those files were stored on a cluster, you couldn't use the client-side caching feature. In Windows .NET we now can use client-side caching on the clustered file share.

Moving on with supportability features (slide 19), we now can use something called software tracing for some of the key features. This allows the Cluster Service to do extra debugging without having to load up the checked build of the different drivers. ClusDisk and ClusNet driver can now do some enhanced logging. We also have verbose output of Chkdsk. If Chkdsk is ever run against a shared disk, it will output its information to cluster logs. Previously, in Windows 2000 and Windows NT 4.0, it would not write anything to the cluster log.

Along with supportability, we now have a new utility called the Cluster Diagnostics and Verification Tool (slide 20), often referred to as ClusDiag. This is a new utility for verifying the cluster to make sure that it's working. This will be available through the Windows .NET Resource Kit. It will have some logic in it that will check for some very common configuration mistakes. As we'll see in the next slide (slide 21), you can run a couple of different tests to verify that the cluster is functioning. You can set it to perform fail-overs between the two nodes. You can run it for a set time, and it will simply fail back and forth over a period of time and log any errors that occur, checking for resources that don't come online the first time, resources that might take a while to come online, and so on.

ClusDiag will be a very good troubleshooting tool for customers. It will have a lot of logic. As you can see in the screen shot, there's an Analyze Logs option, and after you've run the report it will automatically analyze the logs that were generated. It will automatically analyze the logs it created and look for common issues that have occurred. There are a lot of cool new options in this utility.

In Windows 2000, we had the cluster log. Any time a resource is created or deleted or a resource fails, this information is written to the event log. But now everything is written to a cluster log. One issue with cluster logs is everything is referenced as a GUID. A file has been created, Cluster.obj, that simply has a mapping of GUIDs to resource names. It makes reading the cluster logs a little bit easier. Also in the cluster log, every event will be marked with an information, warning, or error flag. This will tell you, when you're reading the cluster log, which of these entries you need to look at, which of these are warnings, and which are error messages. So this is very similar to the Windows event logs. The additional error reporting in the cluster log is new to Windows .NET.

On the next slide (slide 23) we have a sample of a cluster log. You can see, circled in red, warning entries, information entries, and an error entry. Here we have a duplicate IP address error.

With Windows .NET we have some modifications or updates to some existing resources (slide 24). We also have some new resources. On the next few slides we're going to go over these eight or so different resources. Some of them are new. Some of them you may recognize. But there is some new functionality that has been added.

The first one we'll start with is the Spooler Resource (slide 25). In Windows 2000, there were quite a few steps for setting up a cluster print server. You had to install the drivers to each node. You then had to connect to the virtual server, and then create the ports and share out the printer from the virtual server.

In Windows .NET the print server installation has been simplified and is very easy. The steps are pretty much these three bullet items. Create the spooler resource in a group that has a name, an IP address, and a disk. You then connect to that virtual server. And you then install and configure the printer against the virtual server. The cluster software will automatically copy the drivers to all nodes in the cluster. You no longer have to go to each node in the cluster and install the drivers individually.

If you need to update a print driver, you simply go to the virtual server, update the driver there, and the cluster software will take care of updating drivers on all nodes in the cluster. You no longer have to worry about print driver management or updating the drivers on each individual node. This makes managing a print server or a print cluster much easier.

The next resource is the Network Name resource (slide 26). The biggest new feature with this is we now support Kerberos authentication against virtual servers. This was back-ported to Windows 2000 and Service Pack 3, but in Windows .NET it is enhanced. You can configure it in Cluster Administrator. There is now an option to enable Kerberos support. In Windows 2000 it was a feature, but you had to use the command-line Cluster.exe to do that.

There's an option to have the Network Name fail if DNS registration fails. If you have DNS as your only means of name resolution, which is very common, we can have the cluster virtual server resource or the Network Name resource fail to come online if it cannot register with DNS. So it will fail over to the other node, which hopefully will be able to register with DNS. That is an enhancement in Windows .NET for the Network Name.

In Windows .NET, the Distributed Transaction Coordinator (DTC) and the Microsoft Message Queuing (MSMQ) resources have been updated (slide 27). To create your DTC resource in Windows .NET you simply go to a group that has a disk name and IP address, right-click and select New Resource, and select the Distributed Transaction Coordinator. You simply create that as a new resource. You no longer have to run COM+ on each node of the cluster, as you did in Windows 2000. The installation has been simplified.

MSMQ now supports active/active. It also supports MSMQ triggers as a cluster resource. These are new features and enhancements for MSMQ as well.

A new feature in Windows .NET is called Shadow Copy (slide 28). I'm not sure if any of you are familiar with Shadow Copy. Shadow Copy is for file servers that back up a point-in-time copy of a file. The basic premise of Shadow Copy is that a user can connect to a file share, open a PowerPoint® presentation or a Word document, for example, make a change, close the file, open it again, and if they make a change again, they can revert to a previously saved copy. Shadow Copy support has been added as a cluster resource. This functionality will work on a server cluster in Windows .NET. It is set up automatically. If you have the Cluster Services installed and you create a Shadow Copy, it will automatically create a file share and set up the dependencies for you.

The next update is the DFS Root (slide 29). In Windows 2000 you could have one DFS Root. In Windows .NET, you can have multiple standalone roots for DFS. That allows you to perform active/active implementations of DFS, or multiple DFS roots in the same group. That's an enhancement for the DFS resource on a cluster.

Along with the Generic Application and Generic Service resources that we had in Windows 2000, Windows .NET adds Generic Script as a resource (slide 30). You can use VBScript or JScript® and have it run as a cluster resource in Windows .NET. This is something many customers have been asking for.

We now are integrated with Automatic Server Recovery support (ASR) (slide 31). ASR is new to Windows .NET, and Cluster Services is integrated with it. The main purpose of ASR is if you lose an entire server, you can run ASR to perform a full server recovery. ASR in Windows .NET is supported in conjunction with the Cluster Service. If you lose an entire cluster, you lose all nodes in the cluster; you lose the shared disk. You can use ASR to restore the service, the Windows .NET Server, the cluster information, the cluster database, the Quorum information, and also the disk configuration — how the drives were formatted. The ASR will automatically set or restore all of that information. We are integrated with ASR.

In Windows .NET we have a new way to change the Cluster Service account password (slide 32). In Windows 2000 there was some required downtime if the Cluster Service account password needed to be changed, which is recommended. In Windows .NET, we can change the Cluster Service account password without any downtime and change it immediately. It also takes into account that if you have multiple clusters that share the same Cluster Service account password or the same Cluster Service account, you can use Cluster.exe to change those passwords on all clusters all at the same time. If you want to change the Cluster Service account password every 30 days, every 10 days, whatever your company standard is, you can do that to all clusters that share that same Cluster Service account. One thing to note is that if you share the Cluster Service account with other applications, it will not change the passwords for those applications. If you have SQL Server or Exchange, those passwords will have to be changed manually.

One of the next features is the Heartbeat. For the cluster Heartbeat we will automatically use multicast when you have a three-node or higher cluster. The main purpose to this is when we get more than three or four nodes, if every node is communicating with every other node, there are direct connections between the nodes. If you have an eight-node cluster, that can use a lot of network bandwidth on that private network. So in Windows .NET we'll automatically configure multicast. It's all automatic, there's no user intervention. It can be configurable. There's a document in the Help file if you want to make some changes for multicast. But it does this by default on a three-node or higher cluster.

In Windows .NET we have some improved failure detection (slide 34). In the past there have been some issues with Windows 2000 and Windows NT 4.0 where a user mode hang may affect the Cluster Service, where the Cluster Service may hang and cannot fail over because that node is hung. The Cluster Service, as it says here, will periodically report its status to the network driver to let it know that the service is still up and functioning. If the Cluster Service does not report itself, we can configure the nodes to do an automatic reboot so that any application that node was hosting can automatically fail over to the other nodes.

The Resource Monitor will now detect or attempt to detect and respond to deadlocks in the Resource Monitor. This is to ensure that LookAlives and IsAlives are occurring. Again, this is to help further ensure the high availability of any services or applications that are running. It's an added level of protection to make sure that all the resources are running as expected.

We have something called Group Affinity (slide 35). This behavior is very similar to the "Preferred Owner" setting. Group Affinity is to keep an application from running on a node that already has that application running. This is typically more applicable if you have three or more nodes in a cluster. But the basic rule is that it will attempt to keep an application, such as Exchange — say you have a three-node or four-node Exchange cluster — from trying to start on a node that already has Exchange running on it. The Exchange group will run on a different node, on the node that doesn't have anything running on it.

You have some SAN improvements (slide 36). The purpose of some of these improvements is to better work on geographically dispersed clusters. We can now do what's called a Targeted Reset. In Windows 4.0 and Windows 2000, whenever we detect there's a problem with the storage, our cluster driver can issue what's called a bus reset. A targeted reset plays a little bit better when you're on a large SAN, or the nodes are not in the same location.

We can also disable Dynamic Scanning. This allows you to add nodes to the cluster and not have the additional nodes try to scan for disks when they come up.

The last SAN improvement that we have is Majority Node Set (MNS) for a Quorum resource (slide 37). When we look at the Majority Node Set, it is a replacement for the Quorum resource. It is not a replacement for the storage. It's simply to help with geographically dispersed clusters so that there is not a single disk that we rely on for a Quorum. The main purpose of the Quorum is to select which nodes can own resources and which nodes can't, and to make sure that only one node is hosting that particular application at a time. MNS can be used to help with that, when the nodes are geographically dispersed. You can also use it for clusters that do not require a shared disk. Maybe you have an application that takes care of its own data replication, so that this application data is stored on a NAS device or stored locally on local disks. You can use MNS as a Quorum with having a shared disk. Again, MNS is a new way of handling the Quorum resource and does not take into consideration the actual data.

When we look a little bit more into MNS, this chart (slide 38) shows how many nodes have to be up for a cluster to be up and running. Majority nodes implies that you have a number of nodes, and the majority of the nodes have to be up and running and reporting to the cluster for the Cluster Services to continue running.

When we look at the next slide (slide 39), we get a better visualization. We have two sites — Site 1 and Site 2. This is a five-node cluster. If Site 2 were to go down, or if the network connection between the two sites were to go down, Site 2 would shut itself down. Cluster Services on those nodes would stop. Site 1 would remain up and running because Site 1 has a majority of the nodes. It has three of the five nodes up and running, whereas Site 2 only has two nodes. If the network connectivity between Site 1 and Site 2 were to be cut or the two sites could not talk, Cluster Services on the nodes in Site 2 would shut down. Site 1 would remain running. The reason is that Site 1 has a majority of the nodes; it has three of five. Using MNS on anything less than a three-node cluster does not provide a good benefit.

Here's the last slide (slide 40). This has links to a lot of the information that we have talked about today. The first one (http://www.microsoft.com/windows.netserver/evaluation/overview/technologies/clustering.mspx) is a link to the new features in .NET clustering. The second one (http://www.microsoft.com/windows.netserver/techinfo/overview/clustering.mspx) is a list of the different cluster technologies that are going to be included in Windows .NET.

That is the end of the PowerPoint presentation.

Otto Cate: Thank you very much. Before we jump into the Q&A today, I'd like to share a couple of quick program notes with our audience.

Just a reminder, the Q&A portion of the Support WebCast is really intended to encourage further discussion of the topic today. One-on-one product support issues are outside the scope of what we're able to address during the live event. If you need some more complex technical assistance, your best bet would be to contact Product Support Services directly by phone or through an online incident.

We have quite a few questions that have rolled in. I'm going to start with the first one here. This is a question about Group Affinity. Why can it only be set through the command line? We're having some problems finding it in the online help. They're looking to incorporate Group Affinity to the cluster admin GUI.

Steve: That is a very good question. I do not know, to be honest, where the Group Affinity option will be set. I think it's typically going to be an option that the application will set, but that would be something I would need to follow up on.

{Group Affinity is documented online (AntiAffinityClassNames) and in the Help file included in Windows .NET. Its original intention was for applications to set this property during their install, but was it later exposed with Cluster.exe. You need to understand how to use it before implementing this feature. Below is a link to the current online version of the Windows .NET Help File:

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsnetserver/proddocs/entserver/sag_mscsaclstexe_4.asp}

Otto: The next question: Did I hear correctly that both editions can use eight nodes? I heard that Enterprise Edition does four and Datacenter does eight. Has that changed?

Steve: Yes, that has changed. Both Windows .NET Server 2003 Enterprise Edition and Datacenter Edition will do eight-node clustering. I do believe quite a while ago, in the earlier versions, that Enterprise Edition was targeted at four nodes and Datacenter was eight, but they both now support eight nodes.

Otto: Can Windows 2000 nodes be mixed with IA-32 .NET clusters? More importantly, are rolling upgrades still supported?

Steve: Yes. If you have an existing Windows 2000 cluster, a Windows 2000 x86 cluster, or I guess IA32 would be another way of saying x86, you can perform a rolling upgrade to Windows .NET x86 cluster nodes. However, you cannot mix any of the 64-bit operating systems with 32-bit operating systems when they're on a cluster, whether the 32-bit node is Windows 2000 or Windows .NET. All nodes in the cluster need to be either 32 bit or 64 bit. You cannot mix the two technologies. The simple answer is, a Windows 2000 cluster can use a rolling upgrade to upgrade to the Windows .NET 32-bit edition.

Otto: Moving on to the next question: Do you know if .NET clustering will support the Veritas Volume Manager?

Steve: That would probably be a question for Veritas. I do believe they will have a version for Windows .NET.

Otto: How about multiple instances of SQL Server having the ability to listen to separate virtual IPs? Is that something that we can address?

Steve: SQL Server 2000 has the ability to do multiple instances of itself. You can do that with Windows 2000 and SQL Server 2000 by having multiple instances of SQL Server running on the cluster. You'll be able to do that with Windows .NET and future versions of SQL Server on a cluster as well.

Otto: How does the new Quorum configuration work where you don't need a shared disk?

Steve: The basic premise of MNS is that each node will effectively have a file share that each node in the cluster can write to. They will use these file shares on each node of the cluster to maintain the updated Quorum information. Typically, for example, on a four-node cluster there would always be five copies of the cluster database or the cluster registry — one on each node, and then one on the Quorum disk, whichever disk is designated as the Quorum disk. The four nodes plus the Quorum disk copy of the cluster registry would be five copies.

When you're using MNS on a four-node cluster, you would end up, realistically, with eight copies. You would have two copies of the cluster registry on each node, and then another copy on each file share on each node. So the cluster nodes would update the cluster registry or the cluster database on the file share of each node. That is considered an atomic operation. That means that if for some reason you create a resource and we're trying to update the cluster registry on all the nodes, on the local copy, and on their file share, and it fails to copy to one node, it will roll back that change so that the nodes are always in sync. There is never an issue of one node being a little bit different than the others. Then, of course, you would have to figure out why it couldn't do the update. When you use the MNS as your Quorum resource, it does use a file share, and that's how they keep them up to date with each other.

Otto: We have a follow up to that SQL Server question. The original question was: How about multiple instances of SQL Server having the ability to listen to separate virtual IPs? Then the follow up is: But not to separate IP addresses? It sounds like that might be a clarification.

Steve: Some of this might be a little out of the scope, because it will be up to SQL Server as a cluster-aware application. That would be more a functionality of the SQL Server resources versus the Windows clustering software.

Otto: Okay. Next question, regarding Quorum again: Are there any new tools for recovery of corrupt cluster configurations?

Steve: Yes. There are a couple of tools that I didn't mention. One is called Cluster Recovery, which will also be in the resource kit. If you lose a Quorum disk, or if your Quorum disk, for whatever reason, is corrupted, there's a utility that will be downloadable and that may even be on the .NET CD that will allow you to replace or repair that bad Quorum disk, move it to another drive, and so on. Also, there's some functionality in there to help repair any checkpoint files that may have been lost. Yes, there have been some fixes with that.

Otto: I have a question here about clustering print servers. You may have already covered this, but the user is asking: Do you still have to manually install the print drivers on each node in the cluster, or are all the drivers propagated automatically?

Steve: Yes. The drivers are automatically copied to all nodes in the cluster. One thing I didn't mention is when you connect to the virtual server and you add a printer and share it out, the driver is copied to the shared disk that that Spooler Resource is dependent on. From the shared disk, the driver is automatically copied to all nodes in the cluster. The quick answer is, no, you don't have to install the driver manually to each node in the cluster. You install it once to the virtual server, and then the cluster software will automatically copy that driver to each node in the cluster.

This helps for print server recovery. If you have a Windows .NET print server and you evict a node, if you add a node back into the cluster, the first time you move that spooler resource to that new node, it will automatically copy all the drivers to that node for you. For print servers, there should be no manual moving of drivers at all.

Otto: This question might be better handled through a support incident; however, I'm going to ask it just in case: Will there be improved support for dual host bus adapters (HBAs)? I cannot speak in too much detail on our specific problems, but my cluster expert tells me that he's had some issues with Windows 2000 clustering.

Steve: I don't have the link (http://www.microsoft.com/presspass/press/2002/sep02/09-05MultiPathIOPR.asp), but we, as Microsoft, have written a core MPIO driver, a Multipath Input/Output driver for vendors to customize for their particular hardware. That is for .NET, and I believe it's being done for Windows 2000. Now all the different vendors out there who make storage, from the HBAs themselves to the actual SAN, we, as Microsoft, are writing a core MPIO driver for all of our different vendors to customize for their hardware, then effectively repackage and send out to the customers.

That question is not really a cluster-specific issue. From a cluster perspective, there's not really a whole lot that we really care about with multiple paths to the shared disk; that's really more of a core Windows matter. From the base operating system, there are going to be some improvements with that MPIO software.

Otto: Currently with Windows 2000 clustering, administrators are not allowed to increase the disk size to SAN external storage due to a limitation of the OS. We were wondering if that has been addressed in .NET.

Steve: Yes. There are a couple issues with that. In Windows .NET, we still cannot use Dynamic Disk, and that might be partially what that refers to. You cannot use Dynamic Disk for your share drive on a cluster. This means that you cannot create spanned volumes or striped volumes and so on.

However, there is a utility called DiskPart that will allow you to extend a disk into free space, even if the disk is basic. DiskPart is included in Windows .NET. It's part of the base package. The limitations with DiskPart are if you add space, if you add drives to an existing volume, that free space has to show up at the end of an existing volume. You can then use DiskPart to extend the existing data into that free space. That works with .NET.

You can also download DiskPart from the Windows 2000 Resource Kit Web site. It will work with Windows 2000. Use DiskPart with Windows 2000 to extend disks into free space, or expand the disk into the free space that you've added into your SAN.

Otto: Will ClusDiag work with Windows 2000 clusters?

Steve: No. At this point it does not work with Windows 2000.

Otto: I'm not sure what slide we're referring to here, but the question is: Why is the cluster log not integrated into the event logs?

Steve: In the event log, any resource or Cluster Service failure is put into the Windows system event log. But the cluster log is considered a verbose log, so it has anything that happens to the cluster — anything. If you change the display name of a resource, that gets written to the cluster log.

I suspect the reason would probably be that it would put way too much information into a log, like an event log. The amount of information that would be in there would be phenomenal.

Most of the time, in troubleshooting a cluster, we don't have to use the cluster log. It's relatively rare that we have to open up the actual cluster log. It's usually only on very technically deep issues that we have to look at a cluster log to find out what the problem is. Using the system event log and looking at the source of Cluster Service will typically give us enough information about what failed or what didn't fail. That's why it's written there.

Otto: Are there any .NET features that will be back-ported to Windows 2000 Advanced Server?

Steve: Looking through the list, most of the features are pretty much going to be Windows .NET features. I'm not aware at this point of any features that will be back-ported. If anything does come out, it will documented in the release notes or the service pack or something like that, such as the Kerberos feature, where the network name resource is documented in Windows 2000 SP3 release notes. We talk about that as a new feature, but that's one of the main things that has been back-ported at this point.

Otto: Are shadow copies maintained at the file level, not the volume level?

Steve: With some hardware vendors you can take a snapshot of an entire volume. With Shadow Copy you specify a folder to which you want to create these volume shadow copies. I don't know if that answers the question, but you do it per folder. You have, effectively, a file share; it's kind of like client-side caching — for a particular file share you specify and on which you want to enable the shadow copies.

Otto: Within the Generic Script resource, is there any Perl support?

Steve: I do not know. I can find out.

{Follow-up answer: At this point (RC2), Perl scripts will not work with the Generic Script resource. Whether Perl support can be added for the Generic Script resource is being investigated.}

Otto: Okay. It sounds like ASR might require integration with third-party backup products. Is that accurate?

Steve: ASR will be integrated with Ntbackup. I think there is an API for third-party backup vendors so that they can use our ASR. But out-of-the-box, ASR will work with the in-box Ntbackup. You can use Ntbackup along with ASR to do a complete disaster recovery. Whether third-party vendors will also offer something with ASR would be up to them. I suspect that they will.

Otto: Moving on to the next question: Regarding multicasting, does that require a specific IP address range?

Steve: No. However, whatever addresses you use for the Windows 2000 private network heartbeat will work fine with Windows .NET, as far as multicasting. Again, the online help talks about all the different options. If you already have a multicast server that for some reason is on the private network, you can use that as well. But out-of-the-box, the cluster nodes will automatically set up a multicast between them.

Otto: Regarding the geographically distributed clusters, is that a new feature in the .NET version?

Steve: For a geographically dispersed cluster, it's not simply a software requirement. You have to have certain hardware for geographically dispersed clusters. In Windows .NET we're not, per se, adding support for geographically dispersed clusters. We're simply making it easier for the hardware vendors to create offerings for geographically dispersed clusters.

One thing that helps a geographically dispersed cluster is something like MNS. The hardware vendors do not have to worry about keeping the Quorum up and available to all nodes in the cluster real-time, whereas that is a requirement in Windows 2000. In Windows .NET we can use MNS to have the Quorum information copied to the different file shares to the different nodes that may not be in the same city. We are not, per se, adding support for geographically dispersed clusters. We're simply making it easier for our partners and vendors to create a geographically dispersed offering.

Otto: A couple of users are looking for a little bit more information about Shadow Copy, specifically: Who has access to the shadow copy of a file and how easily is it replaced? Say, for example, I created a document that has whatever information in it and I save it off. Then I want to make changes to update it later. Can any user come in and load the shadow copy of the file and overwrite what I had?

Steve: It will be based on the same NTFS permissions that are on the original file. The basic principle of the Shadow Copy feature is that you allocate a percentage of a disk for shadow copy storage. When a user goes to this file share that has the Shadow Copy enabled, and they create a file, if they close out the file, like if they select File, Save, the original copy is put in this hidden area of the disk that you've allocated for shadow copies. It has the NTFS permissions assigned to it that the original file had assigned, because it is the original file. Whoever has permissions for that file will have the same permissions that the new file has or that the old shadow copy had. If the user and administrator have full control over it, then that same user and administrator will still have full control over it. NTFS permissions still apply to those shadow copies.

Otto: Regarding Shadow Copy: Do you know how often it saves the information? For instance, if I have a file open and a fail-over occurs, is a copy made?

Steve: The shadow copy is based on the task scheduler. You can customize how often you want the Shadow Copy process to run. I believe, if there is a lot of interest on this, you can view a demo on microsoft.com. Mark this for offline follow-up and we'll supply a link that talks about the Shadow Copy feature in Windows .NET (see http://www.microsoft.com/windows.netserver/evaluation/demos/default.mspx and http://www.microsoft.com/windows.netserver/docs/VolumeShadowCopyService.swf). It's not geared toward clustering the shadow copy, but it does talk about the Shadow Copy feature of Windows .NET.

Otto: Okay. I'll send that URL out to the group. It looks like it's on the Windows .NET Server site, under the Demos.

Moving on, this is another one that's related to Shadow Copy: How is the configuration identifiable from the registry hive when I'm viewing MPS reports? Is that possible?

Steve: On a cluster? I would have to get some clarification.

Otto: I'm not really sure. Perhaps that user can provide a little bit of extra detail as to whether this is on a cluster or not, and we'll certainly attempt to get back to that one for you.

Steve: There are probably a hundred different scenarios of things that can happen when we're talking about a geographically dispersed cluster, where Site 1 is in one city and Site 2 is in a different city. It's going to depend on the network topology between the two sites. If you had a single link between the two sites and that link goes down, the nodes in the cluster that are at the different sites cannot communicate to each other. It is important to understand this concept, the Cluster Services on the node in Site 2 will be shut down by default. That is because they cannot maintain the Quorum. They cannot run because they only have two of the five nodes in the cluster, so they are not a majority of the nodes. They will shut themselves down.

Now users in Site 2, if they were going across the same link that the nodes were talking to, they will not have access to cluster resources. There are a couple different options for doing this. There may be some manual intervention that an administrator would have to perform to get this up and working again.

The Majority Node Set is not the end all/be all for geographically dispersed clusters. There are a lot of other things. Really, the two sites should have multiple links between each other for redundancy, so that users can get to the other site if something happens to all the nodes in Site 2, or if one link is cut between the two sites. It does depend on the situation.

Otto: Related to Majority Node Set: How does it work if, for instance, Site 1 and Site 2 both had the same number of nodes, like three each, or something like that?

Steve: If you flip back to slide 38, which has a list of the nodes, if you had three nodes at each site, and the two sites could not communicate to each other, that would mean that each site has lost three nodes, or each site thinks that it has lost three nodes. At that point those sites would shut down.

From a planning perspective, a geographically dispersed cluster using MNS needs to be an odd number of cluster nodes — seven, five, or even three, as examples. An even number of cluster nodes will work, but you do run into the situation that person was describing, where both sites, because they cannot maintain a Quorum, don't have the majority of the nodes — both sites will end up shutting down.

You can bring one of the sites back up. There is a way so that, even though we don't have a Quorum, we don't have a majority of the nodes, we can still start the Cluster Service up, and that's documented in the help file for MNS.

A best practice would be when using MNS as a Quorum resource, you want to have an odd number of cluster nodes.

Otto: Thank you for the clarification. We have a follow up to the question we had asked about Shadow Copy and MPS reports: When confirming a cluster configuration on a file share, it would be confusing to see the share dependent on more than one disk in normal circumstances. Are there any special registry entries that we could use to define the share as functioning for shadow copies?

Steve: To be honest, I do not know. At this point the current version of MPS reports for a cluster does not have that information, but I will let the person who does the MPS reports for cluster know, to see if they can add that functionality. I would say there probably is not a way to do that with the current version of the cluster MPS reports.

Otto: Okay, good product feedback, though. Thank you. What type of performance benefits are gained by implementing .NET clustering versus Windows 2000 clustering? Is there a URL we can point to that has some data?

Steve: Yes. I think one of the two links referenced on slide 40 does talk about some improvements. One thing to remember with clustering in general is that it takes advantage of the functionality that is in Windows. Having the cluster software installed doesn't boost the performance of a Windows .NET server. We are just taking advantage of the function that's already there. For instance, the server service is still what is in charge of sharing out files for a file server, whether that's a standalone server or a clustered server. There have been some benchmarks with regard to things like file server and some improvements that they have done, when comparing Windows 2000 versus Windows .NET. That's just from a general Windows perspective.

There are some improvements, most notably in the SAN area, where we do targeted resets versus bus resets. That will allow for disks to fail over a little bit quicker. That would be one of the main improvements for fail-over time. But a lot of the performance of a cluster is really application-specific — how long does it take an application to fail over from one node to another.

Otto: If you had a mixed balanced cluster pair, for instance Windows 2000 on Node 1 and .NET on Node 2, what service pack should we be on for Windows 2000?

Steve: I do not believe that has been locked down at this point. It will depend on some of the features that you're using. For instance, if you are using the Kerberos functionality in Windows 2000, you'll need to be at Windows 2000 Service Pack 3. At this point I do not believe that we have this documented. I can research that. Table that one, and I'll see if we have any documentation that talks about which service pack you need to be at to do a rolling upgrade for a mixed node cluster.

{Follow-up answer: The service pack requirement for Windows 2000 to be in a mixed mode cluster has not been finalized at this stage. Service Pack 4 is the current candidate.}

That might change by the time Windows .NET releases, because of some new functionality that's added to Windows 2000, or something that's back-ported to Windows 2000 may require a higher service pack. I'll see if I can find anything.

Otto: Okay. Are there going to be any tools available to measure the benefits of clustering, like measuring resource uptime in a cluster versus a standalone system, for instance? Or is there anything available now?

Steve: I don't know, offhand. That's an interesting question. I don't know enough about some of our other products, like Microsoft Operations Manager, if Service Pack 1 is going to include knowledge packs for Windows 2000 clustering and Windows .NET clustering. I think that will help monitor a server that's acting as a cluster. As far as measuring, I'm not sure if that really measures the uptime. I don't know about that.

Otto: Is domain membership for cluster members still required?

Steve: Yes. All nodes in the cluster must be a member of a domain. It still requires domains. It can be a Windows NT 4.0 domain, a Windows 2000 domain, or even Windows .NET. You can use Active Directory for Windows 2000 or Windows .NET, but it does require a domain. It will not work in a workgroup.

Otto: Regarding Quorum loss, is that MNS-specific?

Steve: I'm not sure if I 100 percent understand the question, but the cluster software, in any of our products — Windows NT 4.0, Windows 2000, or Windows .NET — requires a Quorum. That is how we ensure that all nodes are running the same cluster database so that they all have the same resource.

It's also how we do something called avoiding split brain. Split brain is where multiple nodes come up, and each of the nodes thinks or attempts to host the same resource, when in actuality only one should be. An example would be two cluster nodes, both come up, and they both take ownership of a disk, they both start up the Exchange or the SQL Server services, and they both try to start servicing clients and servicing requests coming into the cluster. That would be a bad thing, because you have two instances of an application writing to the same disk at the same time, and that will lead to disk corruption and things like that.

If one of the nodes does not have ownership of the Quorum, the Cluster Services will shut down. MNS is just a different way of keeping ownership of that Quorum, to ensure that we don't have split brain and to ensure that the data is consistent. That's the key feature or key reason for the Quorum, is to ensure that we are able to have consistent data, and that only one node is hosting a certain application at a time.

Otto: I know that we touched on this a little earlier. It looks like this is just a clarification: What about the number of nodes supported by the 64-bit versions, the [Windows .NET Server 2003] Enterprise Edition and Datacenter Edition?

Steve: It is the same. The x86 and the IA-64, the 32-bit versus 64-bit, are both eight nodes a piece for both versions.

Otto: What kind of memory support is available? Do we have something better than the Address Windowing Extensions (AWE) or Physical Address Extension (PAE) memory support?

Steve: It's a little off topic for cluster, but when you move into the 64-bit operating systems, the whole memory model is changed. You don't necessarily have to do PAE or AWE. When you're referring to the 32-bit versions of Windows .NET, I believe it is the same. You still have the 3 GB. You still have the PAE switches to use. With the 64-bit operating systems, the whole memory model has changed.

Otto: Regarding some of the rolling upgrades we addressed a little earlier, is there a way to apply this technique without affecting online users of the cluster?

Steve: Like Windows 2000, performing a rolling upgrade will require a little downtime when you need to perform the actual fail-over. The fail-over is pretty much going to be your downtime. If Node A is currently hosting your cluster application, you can do a rolling upgrade of Node B to Windows .NET. During the upgrade, users can still be serviced by Node A. They will not be affected. Only when you have to fail that application or that group that contains the application over to Node B, will the application will be shut down on Node A and then started up on Node B. That is pretty much the same for Windows 2000 upgrading a Windows NT 4.0 cluster. Your downtime is when you fail over.

Otto: Are there any dependencies on Active Directory version for Kerberos authentication to cluster resource or any other new .NET Server cluster functions?

Steve: No. The Kerberos functionality in Windows .NET, having a computer object created for the virtual server in Windows .NET, will and does work fine in a Windows 2000 Active Directory. There is no inherent dependency to have a Windows .NET cluster in a Windows .NET Active Directory. A Windows .NET cluster will work fine in a Windows 2000 Active Directory.

Otto: Does the .NET clustering still assume that all nodes connect directly to all shared disks? MNS can only partially address this issue. For instance, if a cluster is spanned in geographical sites, we're wondering how the node accesses the shared disks that are located at a different site.

Steve: Right. This goes along with what I was saying earlier, when someone asked, "Does Windows .NET support geographically dispersed clusters?" Again, the answer is we cannot support geographically dispersed clusters without the partnership of the hardware vendors. Typically, with geographically dispersed clusters, you would have two SANs at each site that are mirror copies of each other. For disaster recovery, for instance. If you lose an entire site, the data is the same between the two SAN sites. The hardware would still have to take care of getting the data replicated between the different sites, between the different SANs.

With MNS, we're simply making it so that the vendors don't have to worry about replicating over that Quorum information or that Quorum disk. MNS will take care of the Quorum disk. The vendors simply have to focus on what they do best and focus on mirroring the SAN data. That's how the two key in together.

Otto: Can you run the same named sources on a same node in the cluster? For instance, if two servers with the same resource called Share were to fail, can they fail to a single server? In Windows 2000 or Windows NT 4.0, no two resources of the same name were ever really allowed to run on a single clustered node.

Steve: Yes, and that functionality has not changed in regard to a something like a file share. It's inherent because we're using the same server service. We're using the server service on each node so you can't share it out as the same name.

Otto: Currently we have two active/passive SQL clusters requiring four servers. We're wondering if we could configure a three-node cluster with Node 1 and Node 2 running SQL and use Node 3 as the passive node. Or can the two instances of SQL run on any of the three nodes?

Steve: With SQL Server 2000, I think it's going to depend on the version of the application that you're running. SQL Server 2000 was written with support for Windows 2000 Datacenter, which does do four-node clustering. You could configure SQL to run on a four-node cluster. That is built into SQL. You could do that today with the Windows 2000 Datacenter product, as well as Windows .NET Enterprise and Datacenter Editions. You can have, effectively, two active nodes and a passive nodes.

Otto: We're wondering if .NET clustering offers replication of SQL databases.

Steve: No. We're still the "Shared Nothing Model." SQL will only be running on one node at a time, writing to one shared disk at a time. That shared disk fails over to either node, so that the Cluster Services do not replicate the SQL data. But that may be a feature that the SQL group is looking at in their products.

Otto: Regarding fail-over, especially in geographically dispersed clusters, I'm not sure if you've already touched on this, but the question is: Does .NET have the option to determine the fail-over order of resources?

Steve: We're looking at something like dependencies. Dependencies are what determine which resources come online at which time. That determines the order that a resource will come online when it is in the same root. Now if we're talking about if we have multiple groups on a node, and that node fails, then all the groups are all going to try to fail over to the other nodes. Then each group will come online, or all the resources in their individual group will come online in the order of dependencies.

That would typically mean that the disk resource in the different groups would all come online, followed by the IP address and the network name resources in each group. Then the applications, the file services, and the print services would all start coming online. There is no order to which groups come online, however.

Otto: Does the Cluster Service still need read access to a directory to share it in the cluster?

Steve: Yes. That's a permissions limitation, if you will. It's part of the security model. There's no way of getting around that. The Cluster Service account has to be able to read a file share to be able to share it out. If we can't read it, then we can't share it out. That would be a security breach, if we could. That's not something that we would try to fix.

Otto: I've read something about placing the Quorum within the Active Directory. Is that something we're able to address?

Steve: Not that I have heard of. I think that sounds like something that could be confused with MNS, as far as how it works. I've not heard of that. Again, there is no dependency of .NET against Active Directory. There are only two available resource types for the Quorum, actually three. One is a disk; the second one would be a Local Quorum resource for a single-node cluster; the third would be MNS. No, Cluster Service cannot really use the Active Directory for Quorum information.

Otto: Can you explain a little bit about how the multicast LooksAlive or IsAlive is achieved?

Steve: The multicast feature is an update to the way the heartbeat works. Typically, in Windows 2000, a heartbeat packet is sent to each node every 1.2 or 1.5 seconds, from node to node. If you had a multinode cluster, more than two nodes, like a three-node or four-node cluster, every single node has to set up a direct connection to every single node. The amount of traffic goes up exponentially.

When we looked at an eight-node cluster, as we support in Windows .NET, all eight nodes directly communicate to all other eight nodes; that's a lot of network traffic for simple heartbeat or communication for the heartbeat information. For the multicast, there is no, per se, IsAlive or LooksAlive for that. It's not really tunable, as far as it does do LooksAlive or IsAlive like a resource does. Really the configuration for the multicast is the scope, the IP address you wanted to use. Again, it is automatically configured; but if you want to change any of it, you can change things like the scope, the address and scheme it uses, things like that. There is really no IsAlive or LooksAlive option for the heartbeat of the Multicast.

Otto: Another clarification here: At this point, the final release of .NET Server will not support active/active clustering for Terminal Services in Application mode, but it will support active/passive. Is that accurate?

Steve: No. More what that slide is trying to address is that you cannot cluster the Terminal Services. There is no fail-over of the Terminal Services. That is not an option with Windows .NET. What you can do in Windows .NET, however, is you can have the Terminal Services running in Application mode. This is regardless if you're using active/active or active/passive for SQL Server, for Exchange, or for your file server. If you want to use active/active or active/passive with those, that is completely independent of Terminal Services.

However, one thing that some customers have inquired about is having an active/passive cluster with, for example, a file server. They would make these so-called active nodes always run the file service, the file shares for the users. The passive node, however, would be configured for Terminal Services in Application mode. It does not mean, however, if Node B, which is running the Terminal Services, fails, that Terminal Services will then go down. It will not fail over to the other node.

Allowing Terminal Services in Application mode is coming from the principle that some customers do not like having an active/passive cluster a passive node that is doing nothing, if you will. It's sitting at very low utilization. In a workgroup environment or in a small customer environment, they may want to make use of that passive node by making it a Terminal Server.

Again, because you can run the Cluster Services in an active/active configuration, and you can run Terminal Services in Application mode running on a cluster, they are mutually exclusive. Again, the Application mode of Terminal Services doesn't do anything with the Cluster Service.

It's also there to allow more than two administrators to connect to a cluster node. Currently, in Windows 2000 and in Windows .NET, the Remote Administration mode only allows for two users to connect to Terminal Server into a server. So being allowed to run in Application mode will allow more than two users to connect to a cluster node.

Otto: A couple more questions here. Regarding the DiskPart utility: To be able to extend a basic disk with this DiskPart utility, I need to have the ability to expand a LUN on my SAN equipment by adding free space after the existing partition, is that correct?

Steve: Exactly. Typically, if you have a SAN and if you have an existing RAID 5 set, and that is configured as one large, logical partition or logical disk that is comprised of one LUN, as far as the operating system sees in disk management, the steps would simply be you would physically add your new drive. You would go into your storage controller, the configuration for the storage controller in your SAN, and in the hardware you would extend that existing RAID 5 set, for example, onto those new disks that you just added. The hardware, what was 10 drives, comprised of a RAID 5 set, is now 20 drives that have been extended at the hardware level.

The problem in the past has been the file system at the partition level defines how big a particular disk is. After you've added the drive and have physically extended it at the hardware level, you could then use DiskPart to extend the file system into that free space that you just added. That's the basic premise.

Otto: This is the final question we're going to be able to address here today: Is domain DFS supported in .NET Clustering?

Steve: There are two types of DFS. There is standalone DFS and there is Active Directory DFS, or sometimes it's called fault-tolerant DFS. By the nature of domain DFS, you don't need to cluster, because when you use DFS in the Active Directory, it is automatically replicated to all domain controllers. Any good Active Directory model or any domain model, you always have more than one domain controller. The quick answer is, no, you can still only have a standalone DFS root cluster. But there is no reason, however, to really do an Active Directory-integrated DFS and try to cluster it, because by nature it's already protected in Active Directory by normal replication.

Otto: Great. Thank you. It appears that we have been able to address all the questions that came in before our cut-off point for incoming questions. I'm going to wrap up the session. I want to thank everyone for joining us and I hope that the information was useful to you. I definitely want to thank Steve for coming out and giving us a great presentation, and rolling through the questions that we had today.

You can e-mail us 24 hours a day at supweb@microsoft.com with any additional feedback, comments, or suggestions for upcoming events.

I hope that everyone has the opportunity to tune in again soon. Thank you, and have a great day.