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.

Carol Flamer: Today's presentation is "Microsoft^® Terminal Server: How to Configure Network Load Balancing in Windows^® 2000."

What does Network Load Balancing using Terminal Server add to my business? It adds availability (slide 2), load balancing performance, and scalability. You can use Network Load Balancing in Windows 2000 to distribute a large number of Terminal Server clients among a group of Terminal Servers.

High availability: Network Load Balancing provides high availability by automatically detecting the failure of a server and repartitioning client traffic among the remaining servers within 10 seconds, while providing users with continuous service.

Scalability: Network Load Balancing scales the performance of a server-based program by distributing its client requests across multiple servers within the cluster. As traffic increases, additional servers can be added to the cluster, with up to 32 servers possible on any one cluster. Network Load Balancing hosts periodically exchange multicast broadcast heartbeat messages within the cluster. This allows them to monitor the status of the cluster. When the state of the cluster changes, such as when hosts fail or leave or join the cluster, Network Load Balancing invokes a process known as convergence, in which the hosts exchange heartbeat messages to determine a new consistent state of the cluster and to elect the host with the highest host priority as the new default host. When all cluster hosts have reached consensus on the correct new state of the cluster, they record the change in cluster membership among completion of convergence in the Windows 2000 event log.

During convergence, the hosts continue to handle incoming network traffic as usual, except that traffic for the failed host does not receive service. Client requests report a consistent view of the cluster membership for several heartbeat periods. If a host attempts to join the cluster with inconsistent port rules or an overlapping host priority, completion of convergence is inhibited. This prevents an improperly configured host from handling cluster traffic.

Network Load Balancing is superior to other software solutions such as Round Robin DNS, which distributes workload among multiple servers but does not provide a mechanism for server availability. If a server within the host fails, Round Robin DNS, unlike Network Load Balancing, will continue to send it work until a network administrator detects the failure and removes the server from the DNS address list. This results in service disruption for clients.

The performance impact of Network Load Balancing can be measured in four key areas: CPU work overhead on the cluster host, which is the CPU percentage required to analyze and filter network packets; response time to clients, which increases with the non-overlap portion of the CPU overhead; throughput to clients, which increases with additional client traffic that the cluster can handle prior to saturating the cluster host; and switch occupancy, which increases with additional client traffic and must not adversely affect port bandwidth.

Network Load Balancing is IP load balancing (slide 3). It spreads network the connection load across several systems. Network Load Balancing affects only TCP/IP and related protocols. Network Load Balancing can work across as many as 32 system nodes.

When you open the tool used to configure Network Load Balancing, you will see that one connection is created by default: the RDP/TCP connection. Typically this is the only connection that needs to be defined. Nothing needs to be done to enable this connection.

How does Network Load Balancing load balance (slide 4)? Network Load Balancing resides between the NIC driver and the TCP/IP on each node. Each packet that is bound for the virtual IP address goes to every node. Depending on the port rules and hashing algorithm, each node will know whether to pass a packet up the stack or disregard it. Network Load Balancing implements the address resolution protocol (ARP) functionality needed to ensure that the cluster's primary IP address and other virtual IP addresses resolve to the cluster's multicast MAC address.

The requirements for Network Load Balancing with Terminal Server (slide 5) are Microsoft Windows 2000 Advanced Server or Windows 2000 Datacenter Server; TCP/IP protocol; and fiber optics, Ethernet LAN, or Gigabit Ethernet. If we're using Ethernet LAN, Gigabit Ethernet, or fiber optics, only enable NLB on one NIC per machine. Cluster hosts have to reside on the same physical subnet. Network Load Balancing consumes less than 1 MB of disk space, that's 1 MB of compressed disk space, so actually less than 1.5 MB of space, and 4 MB of RAM under normal conditions. No special cluster interconnect is needed.

To configure Windows Load Balancing/Network Load Balancing to load balance Terminal Server client requests to a group of Terminal Servers (slide 6), we must first install the Network Load Balancing on each server and then configure the port rules on each of the Terminal Servers. We will cover configuring the port rules in a later slide.

The optimal setup (slide 7) for Network Load Balancing is to connect all cluster NICs to a hub uplinked to a switched port. Connect dedicated NICs to individual switched ports. Set the gateway on the dedicated NICs. Set the MaskSourceMAC registry parameter to zero. Traffic will flow in through the hub and out, switched through the dedicated NICs. Network Load Balancing uses Layer 2 broadcasts or multicast to simultaneously distribute incoming network traffic to all cluster hosts. In its default unicast mode of operation, Network Load Balancing reassigns the station address or MAC address of the network adapter for which it is enabled, called the cluster adapter. All cluster hosts are assigned the same MAC address. Incoming packets are thereby received by all cluster hosts and passed up to the network load balancing driver for filtering. To ensure uniqueness, the MAC address is derived from the cluster's primary IP address entered in the Network Load Balancing Properties dialog box, which we will be taking a look at later. Network Load Balancing automatically modifies the clusters at the cluster adapter's MAC address by setting a registry entry and then reloading the adapter's drivers. The operating system does not have to be restarted.

Let's take a look at some of the guidelines for configuring Windows Load Balancing or Network Load Balancing (slide 8). These are just guidelines we want to keep in mind. Store user information, system information, and common data in a single place. Network Load Balancing relies on the client's IP address to determine which Terminal Server services a client. This includes a port number if you're using no affinity. We will be covering affinity later in our slide presentation.

When a Terminal Server client disconnects from a Terminal Server during a session, the Terminal Server marks the client session as disconnected. Because this is just a disconnected session, no data loss occurs. When the client reconnects, all applications and data are once again available. We recommend you use Microsoft Cluster services to share the data.

Network Load Balancing port rules configuration (slide 9): the port range is from 3389 to 3389. We want to keep in mind this is for Terminal Server. The protocol is TCP multiple hosts; the affinity is single client, no client, and Class C affinity; and the load weight can be equal or specified in a percentage range.

Let's take a look at some of the affinity options. This is used in handling client sessions to ensure that all network traffic from a particular client be directed to the same cluster host. When you select None, Network Load Balancing load balances all network requests across the cluster, without respect to their source, to maximize the scale performance achieved by load balancing. You can select single affinity and direct all client requests from the same IP address to the same cluster host. You can also select Class C affinity to direct all client requests from the same Class C address range to the same cluster host. Increased affinity enhances the cluster's ability to support client session, although it may somewhat reduce scaled performance. Port 3389 is the only port used in Terminal Server. This can be changed or specified in the registry.

Let's take a look at the port rules and the dialog box to modify the port rule settings (slide 10). To get to this dialog box you click to select Start, click to select Settings, and then click to select Network and Dial-Up Connections. Right-click on the interface that should act as the virtual adapter, and then click to select Properties. Click to select the Network Load Balancing check box. Click to select the Network Load Balancing component and then click to select Properties. Here you can type in your cluster-specific data cluster parameters, host parameters, and port rules. We'll take a look at this information.

Looking at the example here, we have a port range from 1 to 65,535. Again, we want to keep in mind that Terminal Servers use the port range 3389. We have an option for protocols that we want to use, TCP or UDP, and the filtering mode, and Affinity: None, Single and Class C, which we've already discussed. There are also options for multiple hosts and the load weight. We can set the load weight to a percentage, as we can see here, or we can set it to Equal. We can also use the Single host option and set the handling priority, or we can set it to Disabled.

Now for an example of the port rules (slide 11). FTP uses ports 20 or 21 and 1024 to 65,535 and requires affinity set to single. Secure HTTP uses port 443 and requires single affinity. RDP uses port 3389 and can be used with any affinity setting. RDP is used for Terminal Server.

Network Load Balancing in the registry (slide 12): here we have the key that needs to be modified for Network Load Balancing parameters. Actually, we'll just briefly cover some of the parameters than can be set here. The parameter specifies AliveMsgPeriod. The AliveMsgPeriod can be specified in milliseconds between "I am alive" status messages broadcast by each host. AliveMsgTolerance is the number of periods to wait after the last message from the host before it is declared dead. There are also DescriptorsPerAlloc (slide 13), the number of connection descriptors allocated at one time. The MaxDescriptorAllocs is the maximum number of times connection descriptors can be allocated. And the MaskSourceMAC can be set to 1, by default, if running on a switch in unicast mode; this should be set to 0 if running on a hub uplinked to a switch. As we've previously discussed for Terminal Server, we will want to edit this parameter and set it to 0.

We have some command-line switches or tools (slide 14) that can be used with Network Load Balancing. The slide here has the information and what can be done with it. We want to focus on the start/stop parameter, because this is beneficial if we want to do some sort of maintenance on a particular cluster. We can use this option to start and stop the node.

Here we have some more information on command-line switches (slide 15) that can be used. For example, for querying we've already covered converging and how that works, and that's an option that we want to use. Again, here are some more Network Load Balancing command-line options.

For additional information about load balancing, we have an article from our Knowledge Base (Q186566), as well as additional white paper information (http://www.microsoft.com/SERVICEPROVIDERS/whitepapers/nlb_overviewp72070.asp).

Thank you for joining us today. Now we'll be open for questions and answers.

Jason Bennet: Thanks for that presentation, Carol.

Just a couple of quick notes before we move on to the Q&A portion of the Support WebCast: The Q&A portion of the Support WebCast is intended to encourage further discussion of the Support WebCast topic. One-on-one product support issues are outside the scope of these Support WebCasts. If you need technical assistance, please submit an incident on the Web or call Microsoft Product Support Services and speak to a support professional.

The first question I have in the queue is: NLB is essentially DNS Round Robin plus functions to determine server availability. Are there no functions to take into account system load on each individual node?

Lane Hofmann: Actually, it's not done by Round Robin DNS at all. What happens when the traffic comes into load balance is we take the incoming IP address and the TCP source port address and we hash that. And based on the hash table, that will depend on what server we send the information to.

Jason: My apologies. I forgot to introduce Lane. Lane Hofmann has been with Microsoft for two years. He is a support professional on the same team as Carol. He's going to be joining us for the Q&A. My apologies, Lane.

Lane: No problem.

Jason: Okay. The next question, I guess referring to one of the slides: The slide says only one NIC per server can be enabled. What about systems that have dual- or quad-port NICs set up with teaming to one IP? Will that work, or can we only employ one NIC and one IP per server?

Lane: You can have multiple NICs in the server. That just refers to the Network Load Balancing service. You want to have just one single NIC maintaining the heartbeat connection between the different servers. That will give us the information for failover so that we can fail over the node after we don't get any more communication over the heartbeat. Beyond that, you can have multihomed NICs, but keep in mind that you're adding to the complexity and the potential for problems with your configuration.

Jason: Excellent. What is the optimal configuration for environments where only a single NIC is used for both cluster and public communications, in terms of using a single hub-to-switch configuration?

Lane: If I understand the question properly, I don't believe you can use a single NIC. You have to have two NICs in each server. One will maintain the heartbeat connection and it is a dedicated communication between the two servers. The other NIC will be your public communication to the rest of the world.

If they'd like to follow up, I'll try to do a better job answering that.

Jason: Certainly. The next question: If the port for Terminal Services is changed through a registry hack, can the port rules dialog box be used to specify the new port being used?

Lane: Yes. Whatever you set it to in the registry, by default it's 3389, you can go to the KB article we have at the end of the slides (Q186566) and you can use that information to change the setting. That's the port IP that we use to communicate over RDP. The only gotcha there is the Terminal Server Web client — at this point, we're not able to change the TCP port address for that. If you're using the Web client, you're not going to be able to make that change. You won't be able to make a connection.

Jason: Is Windows 2000 Advanced Server required for all Terminal Service nodes?

Lane: No. You can run Terminal Services on Windows 2000 Server or Windows 2000 Advanced Server or Windows 2000 Datacenter Server, but to do the Network Load Balancing you'll have to load Windows 2000 Advanced Server or Windows 2000 Datacenter Server. It's the only option that's available on those two platforms.

Jason: How are printing issues resolved while load balancing Terminal Servers? Are printer requests also balanced among Terminal Servers that are load balanced?

Lane: Yes. Whichever terminal server the client session connects to through the hash table will generate the redirected printer back to LPT1 for the client.

Jason: Earlier slides show MaskSourceMask and then later make references to MaskSourceMAC. Is this a typo or are these two different?

Lane: Yes. The original slide was a typo. MaskSourceMAC would be the proper registry key to change, and that would be under Parameters. {Editor's note: The slide has been corrected.}

Jason: When a server is recovered, does it rejoin the cluster automatically?

Lane: When you say recovered, I'm assuming from a backup. I don't know the answer to that off the top of my head. We could look into that and get back to you. I do not know the options for what happens on a restore.

{Follow-up answer: If you are restoring a single node on an NLB cluster, the server should rejoin automatically. Just to clarify, if you are restoring a failover cluster node, please refer to the Knowledge Base article Q248998, "How to Properly Restore Cluster Information."}

Jason: You can use Network Load Balancing without cluster service, correct? Can you please go through the process of setting up Network Load Balancing on multiple servers without using cluster service?

Lane: If you go into the properties under your network configuration on the local LAN connection, you go to each server and you enable Network Load Balancing. From there you define the printers. I don't have the interface here in front of me to talk to it, but it is an option and it's very straightforward. There's another WebCast that was given approximately six months ago that goes through the installation and configuration of Network Load Balancing.

Jason: Great. Thank you for that. Did you mention in the presentation how many nodes we can add?

Lane: Yes. The load balancing service will support anywhere from 2 to 32 servers.

Jason: How many servers can NLB be used to scale over?

Lane: Again, that would be between 2 servers and 32 servers.

Jason: This question concerns .NET, and I know we don't typically talk about future feature sets, but as far as you're aware of, in terms of publicly released information: Are there plans for .NET Terminal Services to include features such as CPU memory load calculation, similar to the Citrix MetaFrame solution?

Lane: I'm not aware of any specifics on .NET Terminal Services, to that extent.

Jason: Which method is more efficient, connecting all NICs from all servers in the cluster to a switch and configuring the switch for the broadcast issue, or connecting the cluster NICs to a hub and then uplinking the hub into a switch?

Lane: You have two pathways. The heartbeat connection for the cluster would be done either through a hub or through a switch, ideally probably just a hub, or maybe even through a cross-over, so that the two servers could have their communication. Then on the public side you'd probably want to put the two servers into the hub and then forward that out to the switch, but then out to the rest of the world.

Jason: If I have two IIS servers and I want to use Network Load Balancing, can I just use a crossover cable to connect for private connections?

Lane: You could. I said in the last statement that you could do it. It's not really recommended, because you don't get proper termination on the network. Ideally you'd want to have a hub, and a lot of people do use a crossover cable.

Jason: What do you recommend for port rules configuration? I've just read a Q article stating all ports should be open.

Lane: The default setting is to have all ports open. What we were trying to show with the rules settings was that you could limit it for security reasons or if you needed to change IP ports in your configuration. It's just the flexibility of the product. It's not a requirement either way.

Jason: We did get a follow-up to that earlier question concerning Round Robin DNS. Not using DNS Round Robin, but it sounds like a TCP/IP Round Robin: I don't think there is anything in Network Load Balancing to actually look at system load on each node and direct requests to the least used source. Is this correct?

Lane: That's correct. At this point with Network Load Balancing, there's not an option to really gauge that. On a Terminal Server environment, you would be able to monitor that really closely through the Terminal Services Manager tool. It's not really a Round Robin DNS. I guess I want to clarify that a little bit. It's based off of your TCP/IP address or what you're getting from your DHCP address. That is sort of a random number, and depends on what the subnet does along with the hash of the TCP/IP source port. It's more of a random scattering than a Round Robin.

Jason: Are there any Visio diagrams available showing what a typical Terminal Server farm set up with Network Load Balancing looks like?

Lane: I don't think there is anything in Visio. I believe that the white paper that's referenced at the end of the slides (http://www.microsoft.com/SERVICEPROVIDERS/whitepapers/nlb_overviewp72070.asp) somewhat discusses what a generic setting would look like.

Jason: Are there any issues you have seen about connecting directly to a switch versus a hub uplinked to a switched port?

Lane: I'm not aware of any issues. You want to have the broadcast method set there. The broadcast traffic goes through the hub better than it does through a switch, because you get the individual reports. Other than that, I'm not aware of any issues. I'd have to look through the Knowledge Base to see if we have anything documented for that.

Jason: Do the WLBS command-line tools work outside the subnet that the cluster is on?

Lane: I would guess that they would, but that's purely a guess. I would imagine as long as you have name resolution and the rest of your network configuration is set up properly, the tools would work. They're not really remote tools. It would be something you would run directly on the client itself. I guess, thinking about it a second time, that wouldn't necessarily be an option that you'd want to use or could use.

Jason: We have issues with redirected printing. What can you do to correct 1103 errors?

Lane: You're going to need to open a support incident for that. There are a lot of different reasons for the 1103 errors. I wouldn't be able to do that over this call.

Jason: Fair enough. We have a follow-up. The original question was: What is the optimal configuration for environments where only a single NIC is used for both cluster and public communications in terms of a single hub to switch configuration? The follow up asks: One of the slides showed the use of a hub for all cluster communications connected to a single switch port. I thought you could use a single NIC for all cluster and public communications, just like Microsoft Cluster Service, and I was just curious about optimal configuration for a single NIC in each node in a network load balanced cluster for using a hub to connect all nodes, and then connect it to a switch.

Lane: I'd like to take that one offline. I'm not sure I understand what he is trying to configure. If there are two NICs in the server and we're connecting both of those into the same hub, we're going to have a problem with spanning tree. I'm not sure I understand the question properly, so I'd like to take that one offline.

{Follow-up answer: The slide came from some older information. As long as the switches support layer two, you don't need a hub.}

Jason: Okay. When assigning different percentages of load on different servers, what tools would help track the load so that we can reassign a percentage to the servers to optimize the performance of the server farm?

Lane: I'm not aware of any tools, other than that would just be a task of the administrator to just go in through Terminal Server Manager and watch and see where we have spikes. Basically, the tool is designed mostly for different power processors and different servers. You can scale it that way, based off of, say, a dual Pentium II or a dual Pentium 3, or even Xeon processors. If I have three servers, I can give them different percentages of the load.

Jason: Can I specify a particular IP range to go to a specific Terminal Server in a cluster?

Lane: Yes. That's the single affinity option. When you set up the single affinity option, you can specify the IP addresses that you want specifically to go to that server.

Jason: What is the reasoning behind using the hub rather than running directly into a switch?

Lane: I'm not 100 percent sure on that. The hub would be a shared broadcast medium, whereas the switched ports would break up the broadcasts, but I'm not positive. It was just in one of the design specs.

Jason: How will load balancing support one-time jobs that utilize a large part of a network for just a short time?

Lane: Actually it does a really good job of that. For example, a specific example where that happens a lot would be in a Web server farm, where HTTP traffic comes through and it's really connectionless. It makes a quick connection and then goes. You would want to set the multiple affinity there, and that would be a very good solution.

Jason: When a terminal server reboots and rejoins the load balancing again, does it disconnect other users in the terminal server load balancing to try to balance the load again?

Lane: No. The decision is made on which server you're going to go to when you make the connection.

Jason: Are there advantages with using WLBS compared to a hardware load balancer?

Lane: I think it's more of a preference. There are obviously some cost inhibitors that go along with using the hardware mechanism to do the load balancing, whereas the software load balancing is included in the product.

Jason: Is there a registry setting on a terminal server to limit the amount of memory a single session can be allocated?

Lane: No. That's a very complex question. There is no setting for that. It's a shared memory pool that all of the clients are going to be using.

Jason: Can you explain what filtering mode and handling priority means?

Lane: If you set a higher handling mode, the server is going to be defined as a master server versus a subordinate server. The higher the handling node or the lower the number is the higher priority it's going to get. You'll set a server to a higher handling node, it's going to take control of the load balance, and it's going to filter the traffic that way. It's going to take control of the traffic filter. The traffic is going to go there first, and then it'll disperse it out to the rest of nodes.

Jason: Will the cluster NIC need only one VIP?

Lane: The VIP is the virtual IP address. The cluster itself has a virtual IP address. Behind that each individual server will have its own individual IP address. The setup for Network Load Balancing is where you define the virtual IP address.

Jason: In a farm with NLB, two or more servers, which server becomes or acts as the arbitrator, deciding which server gets the client request?

Lane: The load balancing service will determine it, if you set the handling priority. Whichever server has the lower handling priority will take control of that and then be the arbitrator.

Jason: We have two servers with this platform. Each one has two link cards. I'm guessing they're referring to NICs. If there are any problems, one server turns off, and then when the server restarts, the load balancing doesn't function. Is it necessary to disable the cards and then re-enable?

Lane: I think they need to clarify that.

Jason: Do you have any documents that explain the issues and configuration of user accounts and multi-domain server cluster configurations, some using roaming profiles, others not?

Lane: I'm sure we do, but that's outside of the topic.

Jason: Is there a place they can search? Can they search in the KB?

Lane: When I say it's outside of the topic, what I mean is where user profiles and information are kept, that's much more of a domain issue, versus the load balance on a cluster. The cluster is going to point to the domain for the user profiles and those types of settings. Definitely, there is some information in the Knowledge Base, and I'm sure there are some design features off of http://www.microsoft.com/windows2000/. You can certainly find some information there, I believe.

Jason: Okay. They could just do a search for "roaming profiles"?

Lane: "Roaming profiles" and "configure". I'm sure that there's a good source. There are several articles in the Knowledge Base with best practices and also warnings of potential problems.

Jason: Are there some specific performance monitoring metrics in Performance Monitor that would help in capturing performance data?

Lane: Specific to Network Load Balancing, there is the Network Interface counter that you could monitor, but that's just going to show you bandwidth and packages sent and received per second. It's going to tell you just the general networking statistics.

Jason: This question might be a little bit off the topic. I'm going to ask it. The customer has heard MSCS mentioned in this WebCast. Do you have any information that MSCS provides over or in contrast to Network Load Balancing?

Lane: They are separate items, actually. What we're recommending would be that you would run MSCS on the terminal servers and have multiple clusters set up, and then have the Network Load Balancing disseminate information between those different clusters. That way you still have a high-availability solution where you could potentially lose a terminal server or take it down for maintenance at a regular interval and still not affect the availability that you have in your environment.

Jason: Okay. Can I redirect users to any particular server based on user name?

Lane: Not based off of user name, only on IP address. That would be done, again, under the affinity.

Jason: I do want to take a moment to solicit some feedback from our audience. If you've come in today for the first time or maybe you've seen this four or five times, we'd definitely like your feedback regarding this program. If you have any feedback about the questions answered today in the Q&A session, if you have feedback about the presentation itself, or future topics you'd like to see covered, any of that is fair game and we ask that you send it in. You can send that in through the e-mail alias supweb@microsoft.com. Just include the date or title of the Support WebCast in the subject line. That way we can connect it back to the WebCast that you're referring to. You can even put in just the future topics that you'd like to see covered in the subject line.

Lane: I don't know the answer to that.

Jason: Is that something we can find offline?

Lane: Absolutely. I can definitely take that one offline.

{Follow-up answer: The handling priority needs to be unique for each server.}

Jason: Terminal Servers need access to a license server. Can we set up several license servers so that the license server is not a single point of failure? If the single Terminal Services license server goes down, we would get problems.

Lane: At this point with Windows 2000, I believe that we're only allowed to have one license server in place at a time. At this point, unfortunately, I do not believe that there is a solution for load balancing or for a failover on a licensing server.

Jason: Users typically don't listen to instructions on the proper way to log off of our terminal servers. Is there a way on the terminal client to prevent a user from clicking the X to close the Window and going to a disconnected state? In other words, is there a way to disable the X to close the terminal session window?

Lane: I don't know if there is off the top of my head. I know there are some things you can do inside of a policy to remove the disconnect or remove the shut down option, which normal users wouldn't get anyway, but power users and administrators would see. I'm not aware of a way to disable the X. If you would publish an application, say through the Terminal Server client configuration tool, they would only be able to get that one option. When they click the X, that would log them out of the Terminal Server session. You would take care of that, but the downside to that would be you have to have a different Terminal Server session configuration set up for each individual application you would want the Terminal Server users to use.

Jason: Okay. Can an Exchange server running Network Load Balancing support a SQL Server running Network Load Balancing in peak hours?

Lane: I understand the question, but I'm not sure. I think we're getting the two terminologies kind of confused. Network Load Balancing is just going to handle the traffic that's coming through the network. I believe the question here is more toward the cluster service, and whether or not we could set up SQL Server and Exchange on a single cluster, and then fail that over during peak. If that's the question, then that depends on your hardware, and basically there are too many variables to answer that right now. It would definitely fall into what's in your environment. You would have to test.

Jason: Okay. Suppose a user connects to Server 1, then he connects to Server 2. What does this say about his profile or about the profile?

Lane: Like we said on one of the first two or three slides, we suggested that you keep the user specific information, like their profile, on a separate place, say out on a domain controller or on another network share somewhere. That should not affect them.

Jason: Any comments on the best practices for user profiles on a Terminal Server, i.e., local profiles, roaming profiles? Would you recommend local profiles in conjunction with File Replication Service?

Lane: That's really outside of the scope of load balancing, but it's specific to your environment again. I hate to keep going back to that, but they all have their different pluses, and you would have to test in your environment which would be more practical for you.

Jason: Citrix Server has this feature enabled: is it possible to access our local drives using the Terminal Server client from Terminal Server?

Lane: There is a resource kit utility that they can attempt to use. Just a warning: it is not really a supported feature. You may be able to make it work; you may not be able to. It's called Drive Share. If they do a search on the Knowledge Base, if they do a search for RDPClip, in that same article (Q278139) I believe it discusses Drive Share.

Jason: Okay. That does wrap up all of the questions that we have in the queue. I think we'll end this session.

I want to thank everybody for coming in and listening today and asking really good questions. Thanks again to Carol and Lane for the presentation and the Q&A.

Again, if you have any feedback you want to send us, you can do so through the e-mail alias supweb@microsoft.com. Please include "feedback" at the beginning of your message and let us know what you think about today's WebCast, topics you'd like to see covered, what you thought about the WebCast program in general, and things we can do to improve it. We're constantly looking to evolve this program, so please let us know.

We hope to see you again in the near future. Thanks and good-bye.