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.

Alvin Loh: Welcome. I'm really glad to be able to present here today. Let's get started.

The agenda (slide 2) for this morning's talk will be a basic introduction and a brief history of Terminal Services, where we've come from, where we are today, and where we might go. Where is Terminal Services today? I'll give an overview of Remote Assistance and Fast User Switching, which are some of the other technologies that are based on Terminal Services. And then I'll give a focused discussion on Remote Desktop. At the end, I'll be open for questions.

Terminal Services technology (slide 3): a lot of people in our audience today may know or have heard about Terminal Services from Microsoft^® Windows NT^® 4.0 Terminal Server Edition. This was the first version of our Terminal Services technology that allowed people to access applications on a remote server as if they were sitting in front of that machine, without actually being in front of it. Microsoft Windows NT Server 4.0, Terminal Server Edition was the first true multi-user version of Windows.

That technology proliferated into the Microsoft Windows^® 2000 Server family of operating systems. There, we continued to do our traditional application serving, as well as add remote administration to each of the Windows 2000 servers. In Windows 2000 it was extremely useful that an administrator could add Remote Administration mode, and then from any machine inside of his corporation, from home or from any location, he'd be able to access that Windows 2000 Server machine and perform tasks in front of it, as if he were sitting in front of that machine.

In Windows XP we use Terminal Services technology to enable some really cool scenarios, which I'll be talking about today.

In Windows XP (slide 4) we have Remote Assistance, which is our first peer-to-peer support tool. This allows two people to be able to work on a common screen and help each other out. We also have Fast User Switching, which uses the multi-user aspects of Terminal Services technology that will allow many people to be able to use a single computer and have their work stored away in sessions, while one single person is using that machine. Then, we have Remote Desktop, which is the focus of our talk today.

To give a brief overview of where you can find these technologies, I've put together a quick feature matrix (slide 5). We have the Windows XP Home Edition and Windows XP Professional. In this table, you'll be able to see that you can get Fast User Switching in Windows XP Home Edition and Windows XP Professional, Remote Assistance in Windows XP Home Edition and Windows XP Professional, and then Remote Desktop only in the Windows XP Professional edition of Windows XP. To make a quick note, Fast User Switching is not enabled by default. That is, you are not going to see the nice friendly logon screen with the multiple icons for each specific user of that machine, if that machine is joined to a domain. I'll speak a little bit more about that in our next slide.

Fast User Switching (slide 6), what is it? This is built on some of the server-side Terminal Server technology. Basically with the Windows XP Home Edition boxes and the Windows XP Professional boxes, when not joined to a domain, we allow multiple people to use that machine, not concurrently, but sort of serially. This means that the father of the household, for example, could be running Microsoft Word, Microsoft Excel, and a whole bunch of other applications and be doing his work. Then, little Timmy comes along and decides, "Hey Dad, I need to check my e-mail really quickly." If there was only one computer in the household, typically what Dad would have to do is shut down all of his applications, save everything, log out, and then let Timmy onto the machine.

Now, with Fast User Switching, you no longer have to do that. What Dad can do is say, "Okay, that's no problem. Let me just freeze my session where it is, and let Timmy log on." Then, Timmy can check his e-mail. When he's done, Timmy can log out. Then, Dad can log back in and continue exactly where he left off. So we allow the user to be able to save his desktop state, put it away for x amount of time, and then come back to it later on. For the Windows XP Professional SKU, you don't get this feature when you're joined to a domain.

So we worked with the Windows Shell team, who did an awesome job of building the very new, cool user interface, which is our new friendly logon. A lot of people may have seen these on store shelves, where you can just click on an icon of Mom, Dad, or Timmy, enter in your password, and log on. That beautiful interface is the front end to Fast User Switching, which leads to the back end, where the Terminal Services team did their work.

Remote Assistance (slide 7) is another one of those top-ten features of Windows XP that I'll briefly touch on today. Basically, a novice can ask an expert for help and have the expert remotely control the user's desktop. So this is really cool, in that my mom, who might be on Windows Messenger at the same time as me, might be having a problem with her computer. She can right-click on my name, ask for Remote Assistance, and then I will be able to see her desktop and request control of her desktop, and then help her with whatever task that she is having difficulties with. This is a really cool scenario, one that we've been able to enable for the Windows XP product. We designed this for the peer-to-peer support scenario.

We have several escalation channels — that is, channels by which you might be able to ask for help. You can send e-mail through Help and Support. You can save a Remote Assistance ticket to a file and throw it out somewhere onto a share, or send it as an attachment in e-mail. You can also ask for help through Windows Messenger. Basically, this Remote Assistance allows shared access to the console that belongs to the novice user.

Now, to the meat of our presentation: Remote Desktop (slide 8) is one of the really cool pieces of technology that we've been able to bring to the consumer platform. I always have an interesting time explaining exactly what Remote Desktop is to people who don't have a great knowledge of computers. The way I usually explain it is it allows a user to access a Windows XP Professional computer from a remote location, and get the experience of a Windows XP computer and all of its applications, without actually having physical access to that Windows XP computer. In the next slide (slide 9), we have a little figure that will explain how this happens.

We have a Windows XP Professional computer on the right, and there is an "X" through the user. The reason there is an X is to denote that you don't actually need to have a user at that location to be able to use that machine. So a user can be at a remote computer, say at a kiosk somewhere, or at a café somewhere, or even at home or a different location, where he's able to get on the Internet. And as long as he has a TCP/IP connection, he can establish a Remote Desktop session with that remote computer and be able to access the programs on that computer as if he were sitting in front of it.

So how does this work? We take the Terminal Services technology, the protocol called Remote Desktop Protocol, and we send mouse clicks and keystrokes up to the remote computer. Then the remote computer sends back to the local computer the screen shots and bitmaps of what the user is actually doing.

Remote Desktop is also a single-session technology for Windows XP Professional, meaning that only one user at a time can be using the remote computer. You can have access to it while you're sitting locally at the machine, or you can have access to it remotely.

When you're accessing the machine remotely, the local computer will display a locked screen. This is really good for privacy. We've done some work in this space to ensure that people will not be able to watch what you're doing when you're accessing the computer remotely. It also avoids violating software license agreements for using software.

How do I enable Remote Desktop? We made it really simple. Go to the My Computer icon, right-click on it, and choose Properties. Then, go to the Remote tab. I have a picture of that in our next slide (slide 10). By default, administrators of the Windows XP Professional machine can connect remotely. So that is to say that if you're an administrator, you're going to be able to have access to the Windows XP Professional machine.

If you have users who are not administrators of the machine, and you would like to give them access, the right to be able to connect remotely, we built a new group called Remote Desktop Users Group. From there, you can add users into this Remote Desktop Users Group and enable them to connect remotely.

After you select this check box, there is nothing else that you need to do. You don't have to reboot the machine or log out or log back in. You just select that check box and you're done.

Here, we have some pictures of the user interface to enable Remote Desktop (slide 11). On the Remote tab inside of My Computer|Properties, you can see that you can enable Remote Assistance and Remote Desktop just by selecting these check boxes. If you select the check box for Remote Desktop, as I mentioned earlier, members of the administrator group are allowed to connect remotely.

To be able to add users that are not members of the Administrators group, so that they can have access to Remote Desktop, what you would need to do is click the Select Remote Users button and then add or remove users. When you click Select Remote Users, you get the dialog box on the right side of this slide.

After you've done that, how can you get access to that remote machine? Well, you need a piece of client software (slide 12). On the Windows XP platform, that client software is installed by default. So if you're using Windows XP Professional or the Windows XP Home Edition, you can get to the Remote Desktop connection client software that will allow you to connect remotely to a Windows XP Professional box.

You can find that by clicking Start, going to All Programs, and navigating to Accessories and Communications. Under Communications, you'll be able to find the Remote Desktop software. The initial experience of the software is pretty simple. All you would need to do is enter the computer name and then click Connect.

You can also specify a fully qualified domain name or IP address as well. When you enable Remote Desktop, in the previous slide, there is a line of text that will tell you what the computer name is, the fully qualified domain name, for that remote computer. All you would need to know is that computer name, and then you'd enter it into the Computer field on dialog box, and then just click Connect.

There are some other interesting things that you can do inside the UI, if you expand the Options button. You can specify your user name, password, and domain, and you can save the password, so that when you want to connect to this machine in the future, you can just click Connect and off you go.

One of the other things you can do is save a shortcut from the UI. At the bottom of the right dialog box, we have a Connection settings area, where you can save a connection to a specific remote computer and put it on your desktop. When you want to connect to it, just double-click on that icon on your desktop.

After you have established a connection with a Windows XP Professional machine, what can you do with Remote Desktop? There are a number of things that we enabled (slide 13) inside of the Remote Desktop Protocol that allow us access to some really cool resources on our local machine.

One of the things that you can is have access to your local file system. What that means is, if you are at your friend's house and you're connecting to your remote computer at your home, if there are some files that you would like to be able to use or access from your friend's computer, while you're connected to your home machine, while you're inside the Remote Desktop session, you can access those files. That's what we call drive mapping.

The other thing that you can do is copy files via cut and paste from the Remote Desktop session and the local computer as well. File copy only works when file system redirection is enabled. Later on, I can show you where in the UI you can turn that on.

The other things that you can do are, while you're inside your Remote Desktop session, you can print to printers that are on your local area network or that are locally attached to your computer. So if, for example, you connect remotely and want to work on your Word document, and you want to print it out to the printer that's attached to your machine, you can do that.

Audio redirection was another one of the really hot requests that a lot of customers came to us with and asked, "Hey, when are you guys going to be able to provide audio on the remote machine and make that audio available to us on the local machine?" So, we've done that. There are a variety of things that you can do with audio. You can choose to leave the audio at the remote computer, you can bring it to your local computer, or you can choose to not play audio at all.

We also support high color, up to 24 bits. This is really cool, in that if there are some rich, colorful programs that require high-color support, you can get the benefits of those programs by connecting to a Remote Desktop session at 24-bit color.

Some of the other things that you can do (slide 14): we learned, from the Windows 2000 world and the Windows NT 4.0 world, that specific keyboard shortcuts were really difficult to remember. For example, if you pressed CTRL+ALT+DEL, if that locked your local computer, and you meant that to lock the remote computer, that wouldn't work. So how do we get around that problem? In Windows NT 4.0 and Windows 2000 we mapped of a number of key sequences to Terminal Server sessions or Remote Desktop session key sequences. Now, in Windows XP Professional, you can have the computer send the keystrokes either to the local computer or to the Remote Desktop computer, with the exception of CTRL+ALT+DEL. CTRL+ALT+DEL is a specific keystroke sequence that is always going to go to the local computer. That's a keystroke sequence that isn't spoof-able, and that's a security feature by design.

If your corporation requires you to log on remotely or into the corporate network with a smart card, Remote Desktop will also support smart cards. All you would need to do is have a smart card reader at your local machine, insert your smart card, and start a Remote Desktop connection. Then, from there, you do what you need to do.

We also provide access to devices that are attached to your local port. Any device that's attached to your COM port or serial ports, we can also get to them from inside of Remote Desktop sessions. With all that, you can also access all the applications that are installed on that remote computer.

On slide 12, we had the Connection settings area of the Remote Desktop UI. We store a lot of the Remote Desktop connection settings in a file called Default.rdp (slide 15). This file is a hidden file in the My Documents directory that contains the settings for Remote Desktop.

So if you choose to have your password saved, we store the passwords using the data protection APIs provided by Windows XP. We store them in the file. So only the user who saved that password is going to be able to unencrypt that password and use it. On Windows 95, Windows 98, Windows Millennium Edition, and Windows NT 4.0, because the data protection APIs aren't present, we never store the passwords on those platforms.

As I mentioned earlier, you can save the .rdp files to your desktop and treat them like shortcuts from that UI.

One thing to note that is a security feature as well is that you cannot connect remotely using Remote Desktop if your user password, the password for the account that you're going to connect from, contains a blank password. If the password is blank, you will not be able to connect remotely. When you enable Remote Desktop, we provide you a quick dialog box that warns you that, if you're trying to connect remotely and you have a blank password, you're not going to be able to do that.

I spoke about the Windows key combinations (slide 16). There are some pretty cool things with the Windows key combinations, in that you can apply them to the local computer. So use ALT+TAB if you want to switch through applications, those can be applied to your local machine, or they can be applied on the remote computer that you're connected to. Or what you can do is connect in full-screen mode and only apply the ALT+TAB keys when you're connected in full-screen mode. So it's really cool, because there's no need to remember a different set of Windows key-combination shortcuts like you had to in Windows 2000.

Just to be clear, when I say Windows 2000, I mean if you were an administrator who used a Windows 2000 server, or one of the flavors of Windows 2000 Server, and you used Remote Administration or Terminal Server in application server mode, you had to remember a specific set of shortcuts. Windows 2000 Professional did not have Remote Desktop. So users of Windows 2000 Professional will not be able to get it. I just want to make that clear, when I'm saying Windows 2000. We just took the feedback that we got from the administrators and users in the Windows 2000 world to make sure we did the right thing when we brought this feature to the consumer platform.

Audio redirection, as I mentioned earlier, you can leave at the remote computer. There's a typo here in the slide {The slide has been updated}. You can choose not to play the audio at all, or you can bring it to the local computer. One of my teammates likes to use Remote Desktop in his house to be able to control his music collection. So he can sit on his couch, with his wireless laptop, connect to his remote computer, and then he can control the music that's playing out of his remote computer. That's kind of a cool scenario that Remote Desktop enables.

To look at the Local Resources tab and where you can change these settings, you would go to the Remote Desktop Connection UI, click on the Local Resources tab, which is shown here in this slide (slide 17). Here you can alter the settings to your liking. Under Local devices, we make your disk drives available, and that was drive mapping that I mentioned earlier; Printers includes local printers and network printers; and then Serial ports — if you have smart cards present, then a smart cards check box will appear underneath Serial ports, and you can select or clear it.

Just to make a quick commentary about audio redirection (slide 18): basically audio redirection was implemented using our virtual channel APIs for Remote Desktop Protocol. Virtual channels are a way for third-party vendors to be able to send data through the Remote Desktop Protocol data stream between applications they wrote that are going to interface with Terminal Server. So we did that with audio redirection, and it's tuned to minimize the performance impact on network bandwidth. So we really try to take up the least amount of network bandwidth possible.

We also do something special with audio redirection in that if we can send the data to the local computer via UDP, then we'll do that. Otherwise, we will send it through the RDP virtual channel. This is negotiated on the fly, in that audio redirection is intelligent enough to determine whether or not it can make a connection, and it can send sound to the local computer via one of the two methods and then decide which method is better, and then use that one.

We also know, because of the way we implemented audio redirection, that we cannot redirect MIDI sound from the remote computer to the local computer. So we know that's an issue, and we're working to resolve that.

One of the other cool things that I really like about Remote Desktop is the Experience tab (slide 19). The Experience tab was designed to optimize your connection experience when connecting to a computer with Remote Desktop. We have specific, predefined settings that turn features on and off, sort of UI elements, which may affect your experience.

Because Remote Desktop sends bitmaps across the wire, animations or movies really affect the performance, because we have to send each of those frames in an animation, down the wire. That is typically not the best use of network bandwidth. So in Windows XP Professional Remote Desktop, we allow the user to filter out certain elements of the desktop experience that are going to impact performance.

For example, if you have wallpaper that's rich and colorful on your background, and you're connecting over a 56-Kbps modem, you can opt to have that desktop background filtered out. So if you select the Desktop background check box, you're allowing wallpaper, and if you clear it, you don't get wallpaper when you're connected remotely. When you go back to your local machine, your wallpaper will still be there, of course.

The other things that affect performance that we allow you to disable are Show contents of window while dragging, Menu and window animation, Themes, and Bitmap caching. By default, when you connect using Remote Desktop, the profile that we select is for 56-Kbps connections. You can select any set of check boxes that you'd like, to build your own custom connection, or you can use one of the predefined ones that are available in the drop-down box.

What happens if you go off to a remote location and they're not using Windows XP? Well, you can tell them how cool Remote Desktop is, and you can ask them to upgrade, or what you could do is take your Windows XP CD along, and if you'd like to be able to connect and show them Remote Desktop from their machine, you can take the Windows XP CD, insert it into their machine, and then go to Perform Additional Tasks. From there, select to install the Remote Desktop connection software. So we provide a redistributable binary that you can install on platforms that don't have Remote Desktop connection — the client piece of the software.

If you don't have the CD available and you have an Internet connection, what you can also do is go to http://microsoft.com/windowsxp/remotedesktop/. From there, you can download the client software.

Additionally, we have another really cool feature of Remote Desktop called the Remote Desktop Web Connection, and I'll speak to that in the next slide (slide 21).

The Remote Desktop Web Connection is an ActiveX^® control that runs inside of Internet Explorer 4.0 or later. What this means is that if you have an Internet connection or you go to an Internet kiosk and you only have the ability to use the browser, what you can do is connect to your Windows XP Professional machine, which has Remote Desktop Web Connection enabled, then specify the computer that you'd like to connect to and click Connect. Then, you will get a Remote Desktop session inside of Internet Explorer. It's really kind of a cool thing to witness when you first see it. The Remote Desktop Web Connection supports all of the features through scriptable interfaces that you can set on the Web page that our standard Remote Desktop connection software allows you room for, or basically allows you to be able to tune.

To enable Remote Desktop Web Connection, install it by going to Add/Remove Programs, choose Add/Remove Windows Components, and then go to Internet Information Services, click Details, click World Wide Web Service, click Details, and then from there, select Remote Desktop Web Connection. After that's enabled all you would need to do is navigate using Internet Explorer to http://<yourcomputer>/tsweb/.

From there, you will get to a screen that looks like this (slide 22). You'll get a connection to the Web server of that Windows XP Professional machine. From there, you'll able to specify the server that you'd like to connect to, the remote computer, and then select the size of the screen that you'd like to be able to use, and then click on the Connect button. From there, a session will launch inside of Internet Explorer.

If you have any questions, I'd be more than happy to take them at this time. If you're looking for additional information, you can go to our http://www.microsoft.com/windowsxp/ Web site to find out more information about Remote Desktop, but I'm free to take questions now.

Jason Bennet: Thank you for the presentation there, Alvin. Just a couple of quick notes before we move in to the Q&A portion of this Support WebCast: To access information on all upcoming Support WebCasts and the archived content from all past WebCasts, an easy-to-remember URL is http://support.microsoft.com/webcasts/.

The Q&A portion of this Support WebCast is intended to encourage further discussion of the Support WebCast topic. One-on-one product support issues are outside the scope of the Support WebCast. So 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, and have quite a few questions, Alvin, is about running it on Windows 2000 and on non-Windows XP boxes. You probably went through that to some degree in the presentation, but there were several folks who came in late. Can you give an overview, in terms of what they need to be looking out for, the scenarios they need to be thinking about, as they do this? And how Terminal Services plays into this as well?

Alvin: To answer the question, there are two components of Remote Desktop. One is the server-side portion, and one is the client-side portion. For the server-side portion, there are only a few platforms available that provide users with the ability to connect remotely. One is the Windows XP Professional platform. Another one is the Windows 2000 Server family platform. And then, there's the Windows NT Server 4.0, Terminal Server Edition platform.

So if you are using, for example, Windows 95, Windows 98, Windows Millennium, Windows NT 4.0 Workstation, or Windows NT Server 4.0, the non-Terminal Server edition, or if you're using Windows 2000 Professional, you will not be able to connect to these machines and use them remotely, because they do not have the server-side component that is available. For these earlier-version platforms, we provide a Remote Desktop Connection client that you can install on these platforms. It's a very small piece of software that you install. That allows Windows 95 machines, Windows 98 machines, Windows NT 4.0 machines, Windows Millennium machines, and Windows 2000 Professional machines to connect to one of these machines that has the server-side component. Those are Windows NT Server 4.0, Terminal Server Edition, the Windows 2000 Server family, and then Windows XP Professional.

If you're a user of Windows XP Home Edition, and you want to get to the benefits of Remote Desktop on the server side, you can purchase Windows XP Professional and then perform an upgrade from the Windows XP Home Edition to Windows XP Professional.

Jason: Next question: Why is Fast User Switching not available on Windows XP Professional when joined to a domain?

Alvin: One of the reasons why Fast User Switching isn't enabled on a domain is we run into some difficult technical issues. We definitely have heard from customers that this is the way they want to see Windows perform in a domain, and we've taken that feedback. We'll definitely look at doing that in a future release of Windows, but there were some very difficult technical issues with enabling Fast User Switching and multiple users on a single machine who were joined to a domain. So we deemed those issues too big to tackle for the Windows XP timeframe and we decided to postpone that to a later release.

Jason: Okay. You might have answered this already. I didn't have a chance to hear your answer to the question about Windows 2000: Can you control a Windows 98 box with a Windows XP box?

Alvin: No, you cannot remotely control a Windows 98 machine from a Windows XP Professional machine without using a third-party piece of software. Remote Desktop does not allow you to do that. You could potentially use Microsoft NetMeeting^®. But otherwise, you'd have to look at a third-party piece of software to enable that scenario.

Jason: The next question: How does Remote Assistance apply to a corporate environment? Remote Desktop is frequently used in our corporate network from help desk personnel using SMS, but as I understand, to enable Remote Assistance you have to get credentials from a Passport server and that the STD security settings on a corporate network prevent this communication.

Alvin: There are some statements from that question that are somewhat incorrect. One of them is you don't have to get credentials from a Passport server to use Remote Assistance. We designed Remote Assistance specifically for the peer-to-peer scenario.

We've had tremendous amounts of feedback from corporate customers telling us that, "Hey, we want to use Remote Desktop in a corporate support scenario, much like we use Systems Management Server from Microsoft today." We offer a very basic and simple set of tools for Remote Assistance in the corporation; that is, users can offer Remote Assistance. In other words, the Remote Assistance will be initiated from the expert and not the user, which is the case today. You can use the use the offer Remote Assistance tool from inside of Help and Support and have an expert initiate help to a novice user.

One of the big things that we've heard back from a lot of customers is that, in the corporate scenario, people who are working at the help desk can typically offer help, or take control of the user's machine, without the user really saying yes or no or having any way of intervening. Because we designed this in a peer-to-peer scenario, we definitely make sure that this is all typically initiated from the novice's side, in that the novice has to ask for help. After that Remote Assistance connection is established, and the expert requests help, the novice again must explicitly say, "Yes, you can help me." That has typically been a little bit of a stumbling block for corporations that want to use Remote Assistance in the corporate space.

We're definitely taking that feedback and looking at things that we can do in a future release of Windows. But yes, we realize that a lot people have been trying to use this in a corporate scenario, and they would really like to be able to tweak some of the behavior of Remote Assistance that is currently not tweakable today.

Jason: I think this has been answered, but I'm just going to read it anyway: We've just finished a Windows 2000 Professional rollout. Will this technology be available for that platform?

Alvin: You will not be able to use Remote Assistance, Fast User Switching, or Remote Desktop on a Windows 2000 Professional machine. You will be able to use the client piece of Remote Desktop to connect to a Windows 2000 Terminal Server or the upcoming Windows .NET Terminal Servers, or other Windows XP Professional machines. But you will not be able to have Remote Desktop, the server side, for the Windows 2000 Professional platform.

Jason: Does Remote Desktop support shadowing?

Alvin: Remote Desktop does not support shadowing. It wasn't designed for that. We had a lot of feedback, during the beta of Windows XP, where a lot of people were saying, "Hey, I want to be able to shadow this Remote Desktop session from another computer." This is not a scenario that we wanted to enable, because of the software licensing issues as well as security issues. It's also one where we've said if you want to able to share the console or you want to be able to share a session, what you need to typically do is use Remote Assistance for that.

Jason: If you want to send in some feedback about today's show, we are taking feedback. If you have comments you'd like to make about future topics you'd like to see covered or what you'd to say about today's presentation, about your question getting answered or not getting answered, we're taking feedback. Just send it to supweb@microsoftcom. We would ask that you type "Feedback" or maybe reference today's date in the subject line.

We just got a question in: What is shadowing? Can you talk a little bit about what shadowing is?

Alvin: Shadowing is a term that we inherited from the Windows NT 4.0 and Windows 2000 platforms. Basically, shadowing allows two people to look at the same session and do things in that session. Remote Assistance is one form of shadowing, where my mom asks me for help, and then I can see her desktop. The term "shadow" means I can sort of shadow her movements, see what she's doing with the mouse and the applications on her screen. Basically, it's just being able to share a session.

Jason: I'm not sure which slide this question is referring to, but: How do you block out the administrators? Does that question make sense? They were asking during the presentation.

Alvin: I guess what this audience member is asking is, "How do we prevent users from connecting to a Remote Desktop machine if they are part of the Administrators' group?" That's an interesting question. I don't believe that there is a way that you can do that. I'm thinking about if there is a specific setting, maybe in Group Policy, that allows us to do that, and I don't think that there is. It would be really interesting to find out why this audience member would like to prevent the Administrators' group from connecting to a Remote Desktop machine, if that is in fact the question. If you could send some follow-up on that, that would be great. I'd like to hear it.

Jason: Just send in any follow-up information you have, and we'll be sure to get to it before the end of the WebCast. Is it possible to set up a customer's computer to have an icon that they can click for Remote Assistance, which will then connect to our computers for support, without re-entering the connection information each time?

Alvin: For Remote Assistance, I don't believe that we can do that at this point. The underlying technology for Remote Assistance, which is like the Terminal Services and the shadowing portion of the technology, was implemented by the Terminal Services team. The PC Health Team at Microsoft implemented the Remote Assistance layer, which are the escalation channels that are on top of Terminal Server technology. So they were responsible for connecting users.

After they were connected, we would establish the Terminal Services connection that users would be able to collaborate on. I don't believe that there is any way to customize some sort of shortcut, so that when the user clicks it, that will automatically initiate help to a specific machine.

That's something we could definitely look in to. There was some talk early on of releasing an SDK for Remote Assistance, but I think we pulled back on that, because we lacked the resources to be able to make that happen in a decent way. So I could definitely look into that further and send some information out. But I don't think that there's a way that you can do that.

{Follow-up answer: Currently the only way to do this is via the Support Automation Framework SDK. This is only made available to OEMs and corporations. OEMs and corporations can get this from their account managers by getting the OPK. They can then register a help support channel, build some client-side novice escalation UI, and then have the Remote Assistance ticket sent to their back end.}

Jason: Does Remote Desktop use encryption? What type or strength?

Alvin: The encryption algorithm that it uses is RC4, the encryption strength is 128-bit encryption.

Jason: Can we use the Terminal Services client from Windows 2000 to connect, or do we have to use the UI?

Alvin: You can connect to a Windows XP Professional machine from Windows 2000 in a number of ways. You can connect with an older Terminal Server client; that is, the RDP 4.0 client that comes with Windows NT Server 4.0, Terminal Server Edition or Windows 2000. You can also connect using the Terminal Services Advanced Client, which we released at the same time as Windows 2000 SP1, for the Remote Desktop Web Connection. You can also install the Remote Desktop Connection software on a Windows 2000 machine.

The Remote Desktop Protocol is backward compatible. To date, it is backward compatible, meaning that any client that supports Remote Desktop Protocol will be able to connect to another server that supports Remote Desktop Protocol. That doesn't matter if it's RDP version 4.0, 5.0, or 5.1.

The thing is, when you connect from a client that supports a lower protocol to a server that supports a higher protocol, you only get the features that are common to both platforms. In other words, you only get the features that are available in the lower protocol. So to give you an example, if you use the Terminal Server client in Windows 2000, that supports only 256 colors. If you connect to a Windows XP Professional machine, you can connect to it, and you'll be able to interact with the desktop, but you only get 256 colors. So if you want the cool features that the Remote Desktop Connection software in Windows XP provides, you need to be able to install that on the Windows 2000 platform. Or else, if you just want to be able to connect, you can use the older client. I hope that I've answered that question correctly.

Jason: Did you say you could connect by specifying an IP address?

Alvin: Yes, you can definitely connect by specifying an IP address.

Jason: Is there a way to enable Remote Desktop on Windows XP machines that are members of a Windows 2000 Active Directory^® domain using Group Policy objects (GPOs), including putting a specific group as being allowed to do it?

Alvin: That's a really good question. This topic came up for discussion, and I believe that you can do this, as long as you have an updated Group Policy file. I can't exactly remember the details, if that is possible or not. We can send that information back out to you. I think Jason will set up an avenue, a way for us to get answers back out to you guys.

{Follow-up answer: Yes, this is possible. The way to do this is to copy the System.adm file from the %SYSTEMROOT%\inf directory on a Windows XP Professional machine back to the %SYSTEMROOT%\inf directory on the Windows 2000 box. After that is done, run Group Policy. What you won't be able to do though is add users to the Remote Desktop Users group because this is an Active Directory schema change. For more information on Group Policy, they can search for the "Group Policy white paper" on http://www.microsoft.com}

Jason: Yes, we can follow-up after, if you've logged in with your e-mail address. What we'll do is, I'll send the information on to Alvin after the WebCast. When he sends me back the information, we'll forward it on to you through our supweb alias. We generally tend to get that material out within a couple of weeks of the WebCast.

We've gotten a lot of questions about firewalls. So, let me read this, because to me it seems to sum up what a lot of other people are asking, and maybe we can point to documents, rather than going through every particular firewall scenario. I'd like to hear the presenter's insights into security concerns with Remote Desktop and any administrative knowledge needed to accompany Remote Desktop and in regard to firewalls and routers? Also, are the internals of the RDP protocol published to help understand the impact on firewalls and routers?

Alvin: That's a really good question, and we discovered, with the proliferation of NATs, Internet Connection Sharing, home firewalls, and home routers that people can go down to the local computer store and pick up, that this presents a little bit of an issue for us, because we have to be able to connect to endpoints.

If the firewall is in the way, that causes some problems for us. So typically what you need to know is that Remote Desktop Protocol uses port 3389. So if that is open on the firewall, and you have some sort of port forwarding mechanism on your firewall, we leave that entirely up to firewall administrators to deal with. If they open port 3389, then they will definitely be able to connect and use Remote Desktop Protocol. Likewise, if people are on the inside of a firewall and they want to be able to connect to a Terminal Server machine outside of the firewall, if they have a proxy enabled, they would have to be able to proxy port 3389.

There are some other issues that are kind of interesting for us, in that if you have a NAT device at your home and you have the Remote Desktop machine that's on your private network, you may have to get into some interesting port forwarding schemes that will allow you to be able to connect using a single IP address to computers that are on your private network. You can basically specify, if an incoming connection to that NAT firewall connects at this port number, to forward it to an internal private IP address. So you could set up a whole bunch of these rules on your NAT device to be able to do that. That's probably not the greatest way to go, and that definitely doesn't work out very well if you have a big corporation.

At Microsoft, we have Remote Desktop enabled, and people can make a VPN connection into Microsoft and then be able to use Remote Desktop. Likewise, we have a proxy server that proxies the connections when we're trying to go from inside of our firewall to outside.

I don't think there is, today, any extensive documentation on how to set this up. We do have a Remote Desktop deployment guide. I believe that may already be available. I do remember reviewing the document, but we don't actually have anything super-intensive. That's probably a good area for us to focus on, developing something like that to ease the deployment of Remote Desktop for corporations or small businesses.

I think there was another part of that question, which was, "Are the internals of the Remote Desktop Protocol published?" We don't publish the protocol and make it publicly available. You can definitely license the protocol from us, and you can do that by going to the Windows 2000 Terminal Services Web site, and looking at the Remote Desktop Protocol licensing program, but we don't publish anything specific. We don't publicly make the protocol available to people. So I hope that answers your question.

Jason: Did you address port forwarding in there with regard to NAT?

Alvin: Yes, I spoke a little bit about port forwarding. We also have some articles on the Windows XP Web site, on Expert Zone (http://www.microsoft.com/windowsxp/expertzone/default.asp), I believe, that also talk about that.

Jason: Okay, great. Thank you for that. Do DirectX^® applications on the remote computer work through the Remote Desktop to the local computer?

Alvin: DirectX applications, or graphics-intensive applications, don't work great over Remote Desktop. We have issues with Windows Media™ Player. We have issues with Shockwave and Flash. So anything that's really rich and aggressive, in terms of screen updates, Remote Desktop doesn't do a very good job of. We're definitely looking at ways of fixing that in our next release of Windows, and that's one of the top requests that we're getting. But today, no, we don't do a very good job of that.

Jason: This question is concerning CTRL+ALT+DEL: How could you connect to your Windows XP Professional computer at work that is logged off and be able to press CTRL+ALT+DEL on the work computer from home to get the login window? Is that possible?

Alvin: Yes. You can hit CTRL+ALT+END; that's pretty much the only magic key sequence now that we require people to remember. CTRL+ALT+DEL is a specific key sequence that we don't ever allow people to spoof. By design, Remote Desktop is not allowed to take that key sequence and do with it as we please. So CTRL+ALT+END is the way to get the logon screen at the remote computer.

Jason: What is the best and most secure way to access Remote Desktop from the Internet? Is VPN required?

Alvin: The Remote Desktop Protocol itself has encryption built into it, and that is quite secure, actually extremely secure. So if your remote computer is sitting on the Internet and you're somewhere else on the Internet, just establishing a Remote Desktop Protocol connection will be very good. If you have no way of getting inside of a firewall, and you need to create a virtual private networking connection, then yes, you'll have to do that. But on the Internet — we provide encryption as part of the protocol, and it's solid. So that's not something people will typically have to worry about.

Jason: I'm currently running SMS Services. Can I use the Remote Desktop tool to do a remote control instead of the one that came with SMS? Are there any differences in features that you're aware of?

Alvin: I'm not sure I'm going to be able to answer this correctly; there are some differences between SMS Remote Control and Remote Assistance. You're not going to be able to use Remote Desktop to remote control a computer. So I think, for the corporate users today, we have Remote Assistance, which supports a rich set of features. In other words, you're going to get a really good experience. You're going to be able to get very close to the Windows XP desktop experience with Remote Assistance, which you're not going to be able to get with SMS Remote Control.

SMS Remote Control, I think, is better designed and better integrated into corporate scenarios than Remote Assistance is. So I think it becomes a bit of a tradeoff issue. I think what the person who asked this question is really going to have to do is, just evaluate Remote Assistance for themselves, and see if using Remote Assistance, the way that we've implemented it, is better for them than what they're currently using with SMS. SMS has a pretty good remote control feature in that it's really easy for people at the help desk to remotely control another user's computer without their permission. They just intervene. Remote Assistance doesn't allow us to do that.

Jason: The next question, and you might have answered this a little bit, when we talked about Windows 2000: I'm currently using the Windows 2000 Terminal Services client to connect to the Remote Desktop. It works fine, but I guess some features will be missing, like audio redirection. Are there any other concerns using this scenario? Is there anything additional you want to add there?

Alvin: No, there are no concerns in this scenario. You can definitely use an older version of the Remote Desktop Protocol client to connect to a higher version server. As I mentioned before, you're only going to get the features that are available to you in the older version of the protocol, rather than the newer one, but there are no implications here. If we've done some performance work in the newer protocol, which we have, and you're connecting over the older protocol, you're not going to get some of the nice performance gains. But in terms of, is there anything bad or anything wrong with doing that? No, there isn't.

Jason: Can you give us a brief description of the differences between Remote Assistance and Remote Desktops?

Alvin: Remote Assistance allows two people to share a single user's desktop. Remote Desktop does not allow for that to happen. Remote Desktop only allows one user to be able to access a computer at any one time, and that's either locally or remotely. Remote Assistance is designed to solve the peer-to-peer scenario, like my mom is asking me for help over the Internet, and I want to be able to fix it for her, rather than walk her through it through the telephone. She can ask me for Remote Assistance. I can connect to her machine, while she's sitting in front of it. Together, we can work on the same desktop to solve her problem. So those are the differences.

Jason: Here's another question about firewalls. Will this work through ISA Server or through a server running NAT multihomed with an external IP and an internal IP?

Alvin: I believe that if there are multiple NICs that are installed on a single machine, you can definitely connect up to that machine and use Remote Desktop. There is typically no issue there. I do know that we work over the ISA firewall. As to the specific configuration, how that is implemented, I'm not entirely certain, but I do know that we work over ISA, because that's what we use here at the company. I hope that answers the question. If it doesn't, please definitely send us more information, and I can research it for you.

Jason: Regarding connecting from Windows 2000 to Windows XP Professional, where can I get the client software for Windows 2000?

Alvin: You can get the client software from the Windows XP CD. You can go to {http://www.microsoft.com/windowsxp/pro/using/howto/gomobile/remotedesktop/remoteclient.asp} and also download the client software from there.

Jason: Can you discuss the specific bandwidth requirements across a wide area network, low-speed serial connections, i.e. 56 Kbps to 128 Kbps frame relay?

Alvin: I'm not exactly sure what the person who's asking this question is looking for. If you're interested in bandwidth requirements of the Remote Desktop Protocol, we work quite well over 56 Kbps. In fact, we do consume a little bit more bandwidth versus Windows 2000, but we still do a pretty good job.

If you're looking for specific numbers, we don't have specific numbers published yet for Windows XP Professional, but you can go to our Windows 2000 Server Terminal Services technology Web site, and there is a scalability white paper that speaks about network bandwidth and network consumption. From there, you can get numbers specific to scenarios like data entry, task-based worker, knowledge worker, or power user. We've done some scenario testing, and we have some performance numbers there with respect to how much bandwidth is consumed over a network connection. Then, you can take information there and see how it fits into your wide area network, or I think you mentioned frame relay network, earlier.

Jason: Does Windows XP Home Edition come preinstalled with the Remote Desktop software to connect to remote computers?

Alvin: Yes. Windows XP Home Edition does come with the Remote Desktop connection client software. It doesn't come with the Remote Desktop server portion; that is, you can't connect remotely to a Windows XP Home Edition box, but you can use a Windows XP Home Edition box to connect to other computers that have Remote Desktop enabled. You can find that software under Accessories and Communications.

Jason: How are other user IDs authenticated? Who can I add as a "Remote Desktop user"?

Alvin: You can add pretty much anybody to the Remote Desktop users. You can add local user accounts or global accounts. So if I am participating in a domain, I can add domain-level accounts to the Remote Desktop users group, or I can create local users of that machine and add them to the Remote Desktop users group as well. It's a very flexible group that we've created.

Jason: Just out of curiosity, when you use the Remote Desktop utility, it locks out the client PC. Is there a way to remotely unlock the client machines so the customers don't have to?

Alvin: I think what the person is asking is, "If I've connected to that machine via Remote Desktop, and I'm done with it, after I'm done with it, I would like to be able to log the user back in — in other words, leave the machine the way it was before I connected." So if the machine was in a logged-in state, where you could see the desktop, and then a remote user connected in, we lock the client PC. I guess the desired behavior that this person is asking for is, "Is there any way that we can, instead of leaving the machine at a locked state, go back to the desktop state?" That's an interesting request. It sounds pretty cool to me, one that would be worth investigation, but currently with Windows XP today, no, you cannot do that.

Jason: This user came in late, and I think they missed you talking about the Experience tab. How do you get to the Experience tab for RDC?

Alvin: To get to the Experience tab, what you'd need to do is start up the Remote Desktop connection software, click the Options button, and then click the Experience tab. From there, you can select the connection that you're going to be running Remote Desktop over, from the drop-down box, and then make a connection.

Jason: I don't know what RDT stands for, but: Will RDT work through a Windows 2000 server dial-in RRAS connection?

Alvin: I'm not exactly sure what RDT is referring to either, but can you use Remote Desktop via a RAS, or a direct dial to a Windows XP machine? You cannot actually dial up, via a modem, from one Windows XP machine to another Windows XP Professional machine and then establish a Remote Desktop connection — in other words, straight computer-to-computer — unless there is a TCP/IP connection. Basically, Remote Desktop Protocol is dependent on TCP/IP. So if you're dialing into a RAS server, and that RAS server gives you connectivity to the Internet, or TCP connectivity to another machine that has Remote Desktop, then through that scenario, yes, you could connect. But we don't support direct modem dialing in Remote Desktop at this time. So to reiterate, Remote Desktop Protocol runs over TCP/IP. So if you have TCP/IP, then you can establish a Remote Desktop Protocol connection.

Jason: Will the program be replacing NetMeeting, and is it as easy to use?

Alvin: I guess "easy to use" is kind of subjective. I think that definitely with NetMeeting, there is pretty much no development going on in the NetMeeting world. The NetMeeting world has pretty much been displaced by Remote Assistance and Remote Desktop. So if you're asking if we're going to see new features in NetMeeting, the answer is pretty much no, you're not going to see any of that.

The two horses that we're going to ride in the future are going to be Remote Assistance and Remote Desktop. I believe that Remote Desktop and Remote Assistance are pretty cool. NetMeeting has a pretty interesting collaboration story, in that they use a server in the center to hook people up together. Remote Assistance doesn't do that. Moving forward, that's definitely going to be something that we'll look at, but there are not going to be any sort of improvements in the NetMeeting world.

Jason: With Fast User Switching, what happens to the other user's applications that are running when the current user gets a message that says there is a new software update to install, they install it, and the system reboots to complete the installation?

Alvin: If the system reboots, then the applications in the other session, they will be lost. At this point in time, we have no way of preserving that information after a power off, so to speak. So typically, the best thing to do is ensure the users are logged off and they're done with their work. Then, apply the software updates.

Jason: Is it possible to set the default Remote Desktop experience on the Windows XP Professional machine, so that downlevel clients connecting to the machine can get those defaults? For example, when a Windows 2000 client uses the Terminal Services client to connect to the Windows XP machine, the default appears to be the 56-Kbps link with a Windows standard Start menu. Does that make sense?

Alvin: I'm not exactly sure if I understand the question entirely. So I'll try to cover this a little bit broadly and hopefully that will clear things up. Jason, did they mention the older Windows 2000 client, like Terminal Server client, in there, or were they specifically just talking about the Remote Desktop that was installed on Windows 2000 Professional?

Jason: [Microphone muted.]

Alvin: I think I know what the user is asking. Currently, if you connect over 256 colors from a Windows 2000 box, the UI gets dumbed-down to a 256-color version. If you're using the Terminal Server client, there's not much that you can do from the client piece of software to be able to configure that connection. The other issue here is that a Windows XP Professional machine, by default, does not support 256 colors. We support 16/24/32-bit. In other words, the lower 256 colors is hidden and put away. Those are not available modes, but they are available if you connect remotely. So there are certain things you can customize, and there are certain things that you can't. One of the things that you can't customize is controlling the desktop that is shown, like the taskbar, or the themes that are shown over 256 colors. You could specify that you want a different kind of a theme that has specific colors that you can tweak and leave them at that, but when you're connecting over 256 colors, you're going to get a dumbed-down UI experience. So I think to answer your question, no, there's no way to configure that 256-color user experience.

Jason: How many sessions per 56 Kbps? Is it like 22 to 32 Kbps per session?

Alvin: I don't remember the numbers that we have for Windows XP Professional. I think that 20 kilobits per second might be accurate. I don't remember exactly off the top of my head what those numbers were. So yes, I think that you can say that that might be the number that this user is asking for. If you're really looking for specific numbers, what you should do is look at our scalability white paper, because these numbers are definitely affected by the tasks that the user is using. So in our scalability white paper on the Windows 2000 Web site, we talk about different scenarios for different kinds of workers and the amount of bandwidth that they consume. So what you could do is take a look at that to get a little bit a baseline or a better idea. I don't remember the numbers, off the top of my head, that we got in our scenario testing with Windows XP.

Jason: Where is that white paper again?

Alvin: That white paper can be found on the Windows 2000 Web site under Technologies. The technology you should be looking at is Terminal Services. On that Web site, there is a white paper, a scalability white paper that talks about network bandwidth.

Jason: Is the Remote Desktop Web connection like the WIN VNC behavior? Do you know what they're referring to there?

Alvin: VNC is another protocol. It's another application that allows people to connect to computers. I've never actually used the VNC software myself. So I don't really know what the person who's asking this question is getting at, with respect to Remote Desktop Web connection. I can say that the Remote Desktop Web connection does allow you to obtain the client portion of Terminal Services and use the client portion of Terminal Services inside of a Web browser. That alleviates the need for you to download the Remote Desktop connection software or install it on a remote computer. What you can do is just navigate to a Web site that has a Remote Desktop Web connection, and then from there, specify the IP address or server name of your Windows XP Professional machine, and then establish a connection.

Jason: Does IIS have to be installed on every client for Remote Desktop Web connection, or can one Web server host several clients on a network?

Alvin: The role of IIS in the Remote Desktop Web connection is only to serve up the Web page. It's only to serve the Web page and the ActiveX control. What that means is that you can have 15,000 Windows XP Professional machines in your corporation, let's say. Then, you could have one machine that serves up this control. In other words, one machine that's running IIS with the Remote Desktop Web connection installed. You can ask all 15,000 of those users of those Windows XP machines to connect to this one IIS Web server, specify the user name, and then connect in.

After IIS serves up this control, it no longer has anything to do with the Remote Desktop Protocol. We serve up the control, and then after the control is on the local computer, we specify the parameters. We set those parameters on the control. The control itself launches a Remote Desktop Protocol connection to the server. Then, IIS is completely out of the picture at that point. So I hope that answers that question.

We're not running Remote Desktop Protocol, RDP, over HTTP or anything like that, when using Remote Desktop Web connection. Remote Desktop Web connection only serves up the client portion. After the client portion is on the local computer, you can then connect to your Windows XP Professional machine using Remote Desktop Protocol.

Jason: Correct me if I'm wrong, a PC running Windows XP Home Edition can connect to an Windows XP Professional machine, but a Windows XP Professional machine cannot connect to an Windows XP Home machine, is that correct?

Alvin: Yes, that is correct.

Jason: Okay.

Alvin: That's using Remote Desktop.

Jason: Okay. Is there a way to enable copy and paste of files in the Remote Desktop session?

Alvin: Yes. You can copy, cut, and paste files, but not drag and drop files — that's a much more difficult problem — but you can definitely cut and paste files between the local computer and the Remote Desktop session, when drive mapping is enabled. So if you go to the Local Resources tab and select the Disk drives check box, then you can cut and paste files between the local computer and the Remote Desktop session.

We've had a lot of people ask us for drag and drop for files. That's a difficult problem. We're looking to address that in a future release of Windows. We have a lot of people who constantly ask, "Oh, why can't I drag and drop from this window to another window," and that's basically because the Remote Desktop session window is actually just a bunch of bitmaps. So we have no way of really knowing what is on top. When we drag the mouse over, we have really no way of knowing where the target location is, because we're just sort of pointing our mouse over a bitmap. We're looking at enabling that in a future release of Windows. There will be some pretty cool development required to make that happen. But yes, you can cut and paste files when disk drives are enabled.

Jason: Without getting into troubleshooting, are there any issues you can comment on around this: I've set up several PCs for RDP, but printer redirection does not work on any of them, even when the host and client printers are identical. Any thoughts about that? Any general issues that you're aware of?

Alvin: Printer redirection was somewhat problematic in Windows 2000, in that if the driver names were mismatched, then you weren't going to be able to have printer redirection occur. For Windows XP Professional, my suggestion is try to use the in-box drivers that are provided on the Windows XP Professional CD. Then, from there, see if you can print through a Remote Desktop. If that does not work, on http://support.microsoft.com/, we have a Knowledge Base that has several articles that talk about printer redirection. There is a special file that you'll be able to add specific driver names to that will enable you to work over Remote Desktop, if that is in fact the problem that you're running into. Beyond that, we have some great people in Product Support Services who deal with this issue. You can contact them, and they'll definitely be able to help you out.

Jason: Okay, thank you for that. If a user is on the computer that you attempt to remotely log on to, what will they see? Will they be prompted to accept this connection?

Alvin: Okay. If there's a user on the local machine and another user connects remotely, he'll be given a dialog box that says, "Another user is connected. Would you like to continue?" If you continue, then you're going to kick that person off. Yes, there is a warning dialog box that occurs. The person who is sitting at the machine, though, unfortunately is not going to get a warning. We realize that that is a little bit of an issue, and we'll work to address that in a future release. But yes, there is a warning message for the remote user. We leave it to the remote user to be savvy enough to say, "Oh, there's somebody else on the machine. Is that person supposed to be there?" If they aren't, then maybe I can kick them off. If they are, maybe I can contact that person and ask them to get off that machine, or have them finish up whatever they're doing and then get off that machine.

We will work, in a future release of Windows, to provide a little bit more information, such as who's connected and maybe the time that they've been connected for, and the time that they've been idle for. These are definitely things that we'll look at to find a good way to solve this problem. Nothing is concrete, of course, but we're aware of it, and we're looking to fix it.

Jason: Can you programmatically send Remote Assistance requests?

Alvin: No, I do not believe that there is any way that you can programmatically send a Remote Assistance request.

Jason: Okay.

Alvin: There was some discussion for customizing Remote Assistance to the specific needs of certain customers, but that was turned down, because we just didn't have the resources to do it; or actually, the PC Health team didn't have the resources to do it. So that might be something that they will look at in a future release, but I don't believe that there's any way that you can do that.

Jason: Is there any publicly available information about whether Topaz will use the remote control features of Windows XP?

Alvin: There is no publicly available information at this time. We've certainly had discussions with the SMS team with respect to using Remote Assistance, but there's nothing that we can comment on at this point in time.

Jason: Okay. Topaz, for everyone's information, is the next release of SMS.

This question is kind of general: Other than the remote computer being turned on, are there any requirements? I don't know what they're looking for here.

Alvin: If the remote computer is turned on and you'd like to connect using Remote Desktop, the only other thing you would need to do is turn on Remote Desktop and make sure that you have a user account that is allowed to connect remotely, and then you definitely need the client software on the machine that you're going to connect from. If the machine is on and it's connected to the network, then you should be able to connect to it using Remote Desktop, barring any firewall issues.

Jason: When you said you could load the Remote Desktop on other computers that didn't have it, did you mean only Windows XP computers, or would it would it work on Windows 2000?

Alvin: What I referred to was loading the Remote Desktop client software on these other machines that were non-Windows XP machines. I wasn't talking about installing the server-side components that enable you to work remotely. So yes, I was only referring to the client-side software of Remote Desktop.

Jason: As a developer, I'm curious if I could develop an application that uses the ActiveX control. Do you provide an SDK for Remote Desktop?

Alvin: Yes. You can definitely use the ActiveX control and put that inside of a Visual Basic^® application, and then do with it as you like. These APIs are publicly available on MSDN^®. You can look at all the methods and interfaces that we publish, and you can definitely use it to build an application that will connect to a Terminal Server or Remote Desktop machine. Yes, that's definitely possible.

Jason: On the Web connection, what do you use as the <mycomputer>, the BIOS name?

Alvin: In my slides for the Web connection, <mycomputer> was just an example name of the name of the computer that was running Internet Information Server, serving up this Web page. So you could definitely use, if you're on a corporate Internet, the NetBIOS name. Or if you are on the Internet and you want to connect using Remote Desktop Web connection, what you can do is connect using the IP address to that Internet Information Server Web site. Then, from there, launch your Remote Desktop session.

Jason: Can you tell us, once again, how to install the software on Windows NT Workstation 4.0 to remote a Windows XP computer?

Alvin: Yes. All you need to do is take the Windows XP CD, either Windows XP Home Edition or Windows XP Professional, and drop it into the CD-ROM of the Windows NT 4.0 Workstation computer. From there, the auto-run program should start. If not, double-click on the icon for the CD-ROM. Then, an intro screen will appear with Windows XP. Click Perform Additional Tasks. When you click that, there will be an option to install the Remote Desktop Connection software on that machine. If you don't have the CD, you're more than welcome to go to {http://microsoft.com/windowsxp/remotedesktop/} and download the client software from there as well.

Jason: Does the Web client run on the Web server or entirely on the client?

Alvin: The Web client is basically run on the client machine. The Web server only does one thing, and that's to serve up the Web page and then set the parameters on the control. The parameters are screen height, screen width, user name, and then the server that it wants to connect to. The only role of IIS is to serve up the Web page that contains the ActiveX control and then set the parameters. After those parameters are set and that Connect button is pressed, everything is done entirely on the client side, and IIS is completely out of the picture.

Jason: Admins can only connect by default after Remote Desktop is turned on, correct?

Alvin: That is correct. You can add additional users to the Remote Desktop users group if they are not administrators.

Jason: Did you say the remote connection works via a direct modem connection?

Alvin: No, it doesn't work with direct modem connections. Remote Desktop does not work over direct modem connections.

Jason: Do you need an IP address on the remote computer to connect to it, and what if someone has the same user name and password?

Alvin: Typically, user names are unique. So if you connect to a remote machine with a user name and a password, you should be able to get into it no problem, if the user name and password are accepted.

I don't know what you mean by if the user name and passwords are the same, and I think the earlier part of that question was, do you just need the IP address? Yes, you could just use the IP address or the fully qualified domain name, which could be <somethingmycomputer>.microsoft.com.

Just to broaden this a little bit, I'm not sure if the user who asked this question was thinking: if the user is already logged in at the machine and then he attempts to make a remote connection with the same user name and password as the user that's already logged in to the local machine, what would happen? What would happen is you would get that desktop that is already running. So if you had Microsoft Word running, you were reading some documents and whatnot, you were logged in at that machine, and then you went home and you connected remotely using that same user name and password, you would continue from where you left off. So we would preserve that state for you, and then you would be able to connect to it. I think that's what the user might have been asking. If not, definitely send in your follow-up.

Jason: Right. I think you've talked around this, and I just want to make sure it gets asked: Would my Windows XP workstation at my office need to have a public IP address to be able to use Remote Desktop from my home?

Alvin: I guess the best way to put it is, if you can ping your machine, the machine that you'd like to connect to, from the machine that you're at, then you can establish a Remote Desktop connection. If you can't ping that machine, let's say your office is behind a firewall, then you need to find a way to get through the firewall. That might be either dialing up to your corporate network or creating a virtual private networking connection to your corporate network. Then, after those were created, I'm sure you'd be able to ping the box. From there, you could establish a Remote Desktop connection.

If your office just happens to be one computer, and that one computer is a public IP address, then yes, you would be able to connect to it as well. There shouldn't be a problem. I hope I'm answering that question correctly. As long as you can establish a clear connection, a clear path to that computer using TCP/IP, then you're definitely going to be able to establish a Remote Desktop connection.

Jason: Is it possible to have multiple users dialed into a single Windows 2000 Terminal Service via RDP, and can each session see each other's printers? Can they be restricted as to which printers are seen?

Alvin: Yes, in the Windows 2000 world, if you have a few users who are connected, and they're all using the same terminal server, and if they have printer redirection enabled, you should not be able to see the other users' printers. There was a fix, I believe in Windows 2000 — if it's not in Service Pack 2, it will be in Service Pack 3 — that hides the users for the other printers.

I believe this is a known issue. I'm not the person who is responsible for the printer redirection feature, but I do remember our team talking about it.

So if you'd like specific information, you can definitely look in the Knowledge Base. This issue has come up before. You can look in the Knowledge Base and try to find information there, with respect to when this fix is going to be available.

If you're already on Service Pack 2, then it's probably going to in Service Pack 3 of Windows 2000. The other thing that you might want to do is see if the users who are connecting remotely are members of the Users group or power users group rather than the Administrators group. Because if you're a member of the Administrators group, you should be able to see everything. Yes, I guess what I'm trying to tell you is, if you're a member of the Users group and you can see other peoples' printers, then there is fix for this.

Jason: With Fast User Switching, with a family of three reasonably active users, how much extra disk cache should one configure to allow swapping of three different users' applications to disk, if needed?

Alvin: That's a pretty good question. I would say that you probably don't need to tweak the page file or any sort of disk settings for Fast User Switching. What you probably want to be able to do is add more RAM. I would say that if you have three really heavy users and you want to be able to swap from user to user to user, between 128 MB and 256 MB of RAM should be acceptable. Again, that really depends on the applications you're using as well. I'm just giving you some ballpark figures.

Jason: My company uses Citrix today for remote connectivity. Will this replace that need? What are the security implications? Do you know anything about the Citrix product that you can comment on?

Alvin: Yes. I'm familiar with the Citrix product. We definitely work with Citrix. Citrix adds some really cool value-added features on top of Terminal Services. That's what we envision will happen moving forward, as well.

If the question is, "Are we going to try to displace Citrix," the answer is no. Citrix is one of our great partners at Microsoft. We work with them constantly to build a great solution on top of Terminal Server. So if you're using some of the very specific technologies that Citrix provides, then yes, continue to do so. If there are some things that you don't need in the Citrix world and the base version of Terminal Services works really great for you, then that's great as well.

For the people who are listening, Citrix provides an add-on piece of software for a terminal server. They use a different protocol, and their product enables some cool features that Terminal Server does not. Some of those are application publishing and sophisticated management of the Terminal Servers. So if those are features that you use today and you require, then yes, Citrix is a great solution for that. If you don't require those, and the base Windows 2000 Terminal Services technology is good enough for you, then that is great as well.

Jason: Can you talk a little about security, anything in addition to what you've already mentioned? Is the remote connection secure? Am I opening the port and exposing myself to hackers while I'm connecting?

Alvin: If you open up the port, which is port 3389, this is sort of like any other port that's going to be opened on your box. It can be scanned, and it can be probed. We're as secure as any other port that is open on your machine. So I don't think there is anything for you guys to worry about in that space.

Jason: What are the hardware limitations for this feature?

Alvin: For Remote Desktop, basically any machine that can run Windows XP will be able to use Remote Desktop. With Remote Desktop, there is only ever one user on the machine at a time, and that's either in front of the computer or connected remotely. So if you can run Windows XP Professional, you can definitely use Remote Desktop, and there are no special hardware limitations. You're going to need a connection to the Internet. So if you're connected using a cable modem, then those might be requirements, but there is nothing specific or out of the ordinary that is going to be required for you to be able to use Remote Desktop.

Jason: Okay, I think we'll take one more question. How do you remote connect if you have a dynamic IP address?

Alvin: If you have a dynamic address, that definitely presents some issues for you. There are some companies on the Internet today that track or can give you a Web page that you can go to, or give you a DNS name that you can go to, that will track your dynamic IP address. I don't remember any of the names of those third-party companies that do that, and I'm not really allowed to make any recommendations in that area, but you can definitely look around on the Internet. Look at dynamic IP address solutions, and with that, you can definitely use some Remote Desktop; that is something I know that a few people on our team use today.

Jason: Okay. We really have run out of time. I wanted to get through more questions, but at this point, we've just really run out of time. We're going to try to get some of these answered offline. So if you have questions that didn't get addressed, we'll try to send you some information after the WebCast. Our apologies, but it's very popular topic, obviously, and we had a huge audience. I do want to thank everybody for coming in and being so patient. Special thanks to Alvin for coming out today and answering all these questions.

Again, we are very interested in your feedback regarding these sessions. If you want to send us feedback, probably the best way to do that is to send it to supweb@microsoft.com. Just include "Feedback" in the subject line or include the topic of the WebCast, or say "Future Topics," if you're going to recommend them. We'll pass your feedback on to the appropriate managers.

We hope you join us again in the near future. Thank you, and good-bye.