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.

Wally Mead: Today's session is on Topaz and its remote control options. In previous WebCasts we've discussed each of the various feature areas of Topaz which, by the way, is now called SMS 2003. At the Microsoft^® Management Summit last week in Las Vegas, it was announced that the official product name for Topaz, which is the code name, is now Systems Management Server 2003. So I'll apologize to you beforehand if I keep referring to it as Topaz instead of SMS 2003, but whenever we refer to Topaz, we now mean SMS 2003.

After that, we have only a couple more features left to cover in SMS 2003. This month's session is on the Remote Tools options in SMS 2003. What I want to cover today (slide 2) is first a review of what SMS 2.0 provides with its Remote Tools. The reason for covering this is because a lot of the information regarding SMS 2.0 is applicable for Remote Control and the Remote Tools functions in SMS 2003.

A quick review of the Remote Tools functions in SMS 2.0 will give you a great idea of what's still there in SMS 2003. Then what I'll do is jump into what's new for SMS 2003 in the area of the Remote Tools features. That will include new features as well as what's changed from the Remote Control you know in SMS 2.0 to the Remote Control function in SMS 2003.

Then I'll spend a minute talking about interoperability between different versions of SMS, that is, what level of interoperability exists between SMS 2003 and SMS 2.0, in regard to Remote Control and the Remote Tools.

Then we'll finish with questions and answers. This is going to be, most likely, a shorter session than what we've done in the past. We should have a lot of time for Q&A in this session.

Before we talk about what's new in SMS 2003 in regard to Remote Tools, let's give you a review of SMS 2.0 Remote Tools (slide 3). Again, a lot of this information, as we'll see later on, is directly applicable to SMS 2003.

So first off, SMS 2.0 provides a number of Remote Tool functions. It provides Remote Control - the ability to view a remote computer screen and perform mouse and keyboard actions from a remote console to that remote computer that you're viewing through the remote console screen. That's Remote Control, the ability to view as well as take control of a remote computer.

Remote Execute is the ability to launch a program remotely on a computer. You can do somewhat the same thing through Remote Control, however you don't have to establish all of the session overhead with Remote Execute that you do with Remote Control. Plus, in a Remote Control scenario, the SMS administrator, the person who's performing the Remote Control functions, runs under the context of the logged-on user at the remote computer. So if I'm logged on at the remote computer as a user-level person, and I'm coming across from Remote Control as an SMS administrator, I'm going to be a user, not an administrator, on the remote computer.

The Remote Execute function, however, runs under the context of the remote logged-on administrator. So if I'm sitting at my SMS Administrator console as an administrator, when I launch a program through Remote Execute, it runs in my administrative context at that remote computer. So I don't have to worry about logging off a remote user and logging on as myself to get an administrator context to be able to perform some necessary administrative control on that remote computer.

Remote Reboot is the ability to restart a computer remotely without having to access the keyboard and the computer interactively. So that's great for servers that are locked away in a server room, you make a configuration change through Remote Control, and that configuration change requires a restart of the computer. You can do so remotely.

File Transfer is the ability to view the remote computer files, your own local files and directory displays, and then transfer files between the two desktops, between the local administrator computer that you're sitting at as well as the remote computer you're accessing. So it's a great tool for you to transfer to files - updated .ini files, template files, or whatever is necessary. You can do that through the File Transfer function.

Next is the Chat function, the ability to interactively send text messages back and forth between the SMS administrator as well as the remote computer.

Last is the Ping Test. The Ping Test is a way for you to test your connection from the SMS Administrator console computer to the remote computer. It's not going to necessarily tell you how speedy or how reliable your session is, but when you perform the Ping Test, it gives you a thermometer scale. The higher on the thermometer scale your test evaluates your connection, the more reliable your connection should be maintained through Remote Control, or whatever functions are being used.

There are also a few other utilities that are available, but they're only available for Windows^® 95/Windows 98-based computers, or Windows 3.1 or Windows for Workgroups-based computers. They're not available on Windows NT^® and later platforms.

In addition, SMS 2.0 provides access to some common Microsoft Windows administrative tools, such as the Event Viewer, Windows Diagnostics, and Performance Monitor. You have the ability to access each of these programs remotely from the SMS Administrator console to the remote computer. Now certainly you could use those utilities individually, to a select computer, and access the information remotely. It just gives you a centralized console where you can perform all of these functions from a single node.

So that's a quick background of what the tools are, and now we have a few more slides on SMS 2.0 Remote Tools, again as background for Topaz or SMS 2003. So next we have a screen shot (slide 4) of an established Remote Tools session. We'll talk about how you establish this a little bit later on, but this is a Remote Tools session that has been established, and you see a dozen different toolbar buttons on the screen. The first five of those buttons as well as the very last button are available. The middle six buttons are unavailable. Those are the ones that are only available for the earlier-version or legacy platforms, such as Windows 3.1 through Windows 98.

The first five again are the normal tools that you would consider Remote Control functions. The first one is Remote Control itself. Then you have Remote Reboot. You have Chat, File Transfer, and Remote Execute. The very last button you see, with the two computers, that's the Ping Test. Ping Test is not a TCP/IP PING, it's purely blasting out as many packets as you can over a four-second time span, verifying the packets, and seeing what kind of response you get, to test the connectivity between those two systems.

There are other interesting things you would see on this screen. You could access all those commands or all those toolbar buttons from the Tools menu. So select Tools, then select Remote Control. You'd have Remote Reboot, and so on. At the very top of the window it tells you the computer name, that the client I'm connected to is TOPAZCLIENT, and it gives you the IP address and the socket number or port number we're connected to. So the IP address is 192.168.21.66 and the port we're using is 2701, which becomes important later on, in the interoperability scenarios we'll talk about.

Then at the very bottom of the window, on the status bar, you'll notice it states Remote Control Agent found using TCP. So it's telling you what connection protocol it used to find that client, whether it's TCP, whether it's NetBIOS, or whether it's IPX. So again, these tools are all available through the menu option or through the toolbar buttons, and they're also all available through the SMS 2003 functions as well.

If the session cannot be established to the client computer, in this case a Topaz client, a message box would appear in the middle of that screen, indicating that it could not find the Remote Control agent on that computer.

The next thing we want to talk about is SMS 2.0 Remote Tools security (slide 5). If you have the capability to access computers remotely to control them, reboot them, and run programs remotely, how can you secure who has access to what in your Remote Tools scenario? That's what this slide discusses.

Security is required for access to the remote client, and there are a few different layers of security that you have with SMS 2.0. First, you have to have the ability to launch the Remote Tools functions through SMS. There is a security right that you have to apply to the user account and to the collection that the client is a member of. That security right is called Use Remote Tools. So if the logged-on user who's at the SMS Administrator console does not have Use Remote Tools security rights to the collection, then they won't be able to start the Remote Tools functions. So you won't be able to launch Remote Tools. That last window we saw in the screen shot won't appear. You'll get a message that pops up, indicating you don't have rights to run Remote Control.

After you've gone past that, so after the logged-on user has rights to launch the Remote Control functions in SMS, then you have to be a member of the Permitted viewers list to access the remote computer. I'll show you this on the next slide, when we look at the screen shot coming up, it'll show you the Permitted viewers list. But this is the list of accounts, whether user accounts or group accounts, that are permitted to remotely control or remotely access the target computers. This is for Windows NT-based and later version client computers.

If you're not a member of the Permitted viewers list, when you try to access one of the remote functions on a target client that is Windows NT or later, you'll be presented with a dialog box asking you for credentials of someone who can take Remote Control or Remote Execute, or whatever function it is, to that client computer. Then you can specify user account and password with the appropriate domain name information of an account that has rights to access that computer, which means they're in the Permitted Viewers list.

Last, the logged-on user, that is the SMS Administrator, needs to be a local administrator as a remote client. The logged-on administrator has to be a local administrator on the remote computer. I need to be an admin to be able to connect across the wire to that computer.

So I have to pass all three tests. I have to have the ability to launch Remote Tools from the Administrator console, which is an SMS security right. I have to be on the Permitted viewers list to be able to access the remote computer. And I need to be a local administrator.

The security rights that we mentioned, the Use Remote Tools security right, can be set for users or groups and for all or individual collections. So you can create a class right or an instance right to the collection or collections that you're targeting to designate whether or not you have the ability to launch the Remote Tools rights.

Also for security, whenever a Remote Control session is established or any one of the tools is initiated, log file entries will be generated on the client computer, indicating that ABC administrator from this domain started a Remote Control session or launched Remote Execute or Remote Reboot, or whatever. So logging information will be generated in the client's Event Viewer log file, in the security log file, so that you can track what's being done on your computers remotely.

That also generates status messages for the SMS status system; that status message will be generated, so you can track who has done what through the status system. There are a series of built-in status message queries for the Remote Control functions in SMS 2.0.

Our next slide (slide 6) is a screen shot that will show you two of the different security scenarios that we just talked about. The screen shot on the left is for setting the Use Remote Tools security right. The security right for a collection, in this case you notice in the Instance box, it says <all instances>. So this is a class right for the collection class, for the logged-on user TOPAZDOM\Administrator to allow the ability to use Remote Control functions.

If the Use Remote Tools check box is not selected, I would not be able to launch the Start Remote Tools action task from the Action, All Tasks menu. That's how you can set your security rights. That could be, again, to a user account, or that could be to a local or global group account that could be used to designate your rights for the individual collection or all collections.

On the right portion of the slide is the Permitted viewers list. This is looking at the Remote Tools Client Agent, looking at its properties, and on the Security tab, you notice several different spellings or variations of the word "Administrator." These are localized versions of Administrators that are built in to the Permitted viewers list for SMS 2.0 by default. Actually, these screen shots I'm showing you are SMS 2003 screen shots, but they're exactly the same for SMS 2.0.

There is a "star" button that allows you to add additional accounts. When you add an additional account, you would make it a fully qualified account name. So you specify the domain_name\ and then either the group name or the user name that you want to allow to access the computer remotely.

Then the last thing we'll talk about for SMS 2.0 is, after you have the Administrator console, you have permissions, and you have security rights and so on, what kind of traffic is generated in a Remote Control scenario (slide 7)? For SMS 2.0 Remote Tools traffic, there are a number of different things we do.

First off, in SMS 2.0, you can use TCP, IPX, or NetBIOS to access the remote client. TCP is going to be the default option, and then you can configure it to use either IPX in a NetWare environment or NetBIOS if you want to use NetBIOS LANA numbers, as opposed to TCP sockets or IPX.

When you're using TCP ports, SMS 2.0 would use TCP ports 2701 through 2704. The range of those four ports is for some of the different tools. Each of the individual tools has a different port that they use. Ports 2701 through 2704 are the ports used for Remote Control functions. SMS 1.2, just for reference, used ports 1761-1764. Actually, SMS 2.0, in the initial release of the product as well as SMS 2.0 Service Pack 1, also used those same ports. It wasn't until SMS 2.0 Service Pack 2 that we migrated to the new ports, 2701 through 2704.

So when you got to SMS 2.0 Service Pack 2, which was using the new ports, when the administrator tried to connect to a client, it would first try the 2701 port. If that failed, then it would back down to the 1761 port, which is what SMS 1.2 used, as well as the first two releases of SMS 2.0. That was for interoperability scenarios, for earlier-version clients as well as older SMS 2.0 clients.

After the client has been found, here is what kind of traffic is generated when you try to perform a Remote Tools session start up. First off, the Administrator console computer is going to register a NetBIOS name. So it registers the computer name with an uppercase or capital D in the 16th character. So a hexadecimal 44 in the 16th character, that's to register the Remote Control Admin console.

Then we resolve the client's IP address. That would retrieve the computer name and the IP address from the SMS site database, and we resolve that to a MAC address. Then we try to connect to the client over port 2701 using TCP. We'd also try over LANA - whatever the appropriate LANA port designation is. We make a call on the wire to try and resolve the target client's computer name with an uppercase C in the 16th character, which is how we connect to them through NetBIOS, indicating that the Remote Control agent has been started in the client. If those fail, we try to connect over port 1761 at the IP address.

So we register the Administrator console, we resolve the computer name into an IP address, we blast out and try and find the client over all known options, which would be going over TCP, port 2701, and going through LANA. If those fail, then we try port 1761 with the IP address.

Just to establish a Remote Tools session, it's generally about 3 KB of traffic. About 3 KB of traffic is generated on the wire to establish a Remote Tools session. On the next slide (slide 8), I'll show you a screen shot of the Remote Tools window when it launches, showing you this actual traffic process.

You don't see the physical frame through Network Monitor or anything, but you can see that the first thing that's done is network names were added successfully. That's your Administrator console registering its computer name with the uppercase D in the 16th character; then it's resolving a client's address, 192.168.21.129, going to the computer name over lana 0. In this case I was going to TOPAZ2PDC. Then I'm going to the IP address over port 2701, and then you see at the very bottom, I'm trying the IP address over port 1761. In this case, I stopped Remote Control agent on the computer name TOPAZ2PDC. So if I would have scrolled all the way down, it would say Remote Control Agent Not Found.

So again, this is important, because this is very similar to the traffic you'll notice with SMS 2003.

Okay. So that's the information on SMS 2.0. The reason I covered this is because the same traffic and the same information is there for SMS 2003, as you have for SMS 2.0. So let's now talk about the SMS 2003 or Topaz Remote Control options (slide 9).

First off, Topaz inherently provides numerous, different options for Remote Tool functions. We still have the SMS Remote Control capability. It's essentially the same as SMS 2.0. There are a few changes we've made, and I have a slide coming up that will discuss the changes between the SMS 2.0 Remote Control functions and the Topaz or SMS 2003 Remote Control functions. But we also now include the ability to launch Remote Assistance from Windows XP or Windows .NET Server, as well as Windows Terminal Services.

Those have both been added to SMS 2003, and I'll cover those in more detail in later slides. So I'll give, in the rest of the presentation, a quick talk about SMS 2003 Remote Control, and then I'll talk about Remote Assistance, and then I'll talk about Terminal Services.

The important thing is that all three of these options, SMS Remote Control, Remote Assistance, and Terminal Services, are all integrated into the single SMS Administrator console. So you don't have to launch different administrative tools to perform your appropriate Remote Control functions. They're all built in to the single SMS Administrator console. So that makes it easy for you to access your different clients. You just stay in one administrative utility and then launch whatever the appropriate control function is to your client.

The appropriate options are available for the appropriate client platform. You don't have all three of these options available for every single client in your SMS 2003 site. SMS Remote Control is going to be available for all client platforms. So that includes Windows 98, Windows NT 4.0, Windows 2000, Windows XP, or Windows .NET Server. They're going to be able to run SMS Remote Control to that appropriate client computer platform.

Remote Assistance is only available for Windows XP and Windows .NET Server clients. So you can't perform Remote Assistance to a Windows 98 computer or to a Windows 2000 client. It has to be Windows XP or Windows .NET Server.

Terminal Services is only available for Windows NT 4.0, Windows 2000 Server (including Advanced Server), as well as Windows XP and Windows .NET Server. So again, the appropriate options are available for the appropriate client operating system.

For SMS 2003 specifically, and in comparison to standard clients and mobile clients that you've heard about in other WebCasts, there are no differences between the Remote Control functions between a standard client and a mobile client. The behavior is essentially the same. In other words, if it's enabled at the site, all standard clients will get Remote Control functions, and all mobile clients will get the Remote Control functions.

One difference would be, on a mobile client, all the Remote Control code is enabled or is not enabled, but it's included in the Client.msi file. In other words, the Windows Installer program used to install the mobile client, it's all included in that. So when you install a mobile client, if Remote Control is not enabled, or the Remote Tools Client Agent is not enabled, then the code will be on the hard drive of the client, but it won't be enabled. It won't be completely installed.

Then if you enable the Remote Tools Client Agent at your site, when the policy is retrieved and evaluated by the mobile client, it would complete the installation of the appropriate drivers for the SMS Remote Control function, complete the installation, and enable the Remote Tools Client Agent remotely on the client computer. Then you can also create a MOF file to provide local policy override of your site settings.

So if you have a site-wide setting that you want for all your sites, but on your mobile clients, or even a specific mobile client, you don't want that setting, such as Permission Required, you can create a MOF file, which is an ASCII text file that would override the SMS settings. Local policies would always override the site-wide settings.

Okay. Let's jump in to each of these three individual tools and discuss what capabilities SMS 2003 or Topaz has with the Remote Control functions for each tool. The first one we'll look at is Remote Control (slide 10). The nice thing is that if you know and like the SMS 2.0 Remote Control solution, it's still there in Topaz. So in SMS 2003, the standard SMS Remote Control function is still there. We've made a few enhancements to it that we'll talk about in the next slide, but in essence it's still there, and it functions the same way. We'll talk about any changes.

We provide all the same Remote Tools: you still have the same security configuration; you still have the same basic network traffic requirements. All that information is all the same as what you have in SMS 2.0, so that's why I went through the background on SMS 2.0. There are a couple of minor differences, again, that we'll talk about on the next slide.

The advantage of the SMS Remote Control option is that it gives you the capability to remotely control all client platforms: Windows 98, Windows NT 4.0, Windows 2000, Windows XP, as well as Windows .NET Server. The code installs in all the clients that are supported for Topaz or SMS 2003, and it will be there, and you can take remote control of any of those computers, provided that you have satisfied the appropriate security requirements, which we have already talked about.

That also includes any child site clients running windows. So if you have an SMS 2.0 child site and you have clients in there that are running Windows 3.1, Windows for Workgroups, or Windows 95, platforms that SMS 2003 doesn't support directly, you would still be able to remotely control those, because you have earlier-version support to the same clients that SMS 2.0 supported. So you do have that ability. That gives you the ability to remotely control all of your clients without having to add any additional functionality or any different utilities, outside of what SMS provides natively.

There are a couple of the changes to the Remote Control functions for SMS 2003 over what you saw in SMS 2.0 (slide 11). First, there are some performance improvements. The Remote Control functions in SMS 2.0 were never classified by people as being overly speedy, you might say. In some cases, they were not really usable over slower links and in some other scenarios.

Topaz is going to improve that area by requiring less CPU utilization for your graphics and screen rendering. There is going to be lower CPU utilization for your screen transfers. The compression that we perform on the client end, and the decompression on the Administrator console end, that has been reduced for SMS 2003. Now, we don't have numbers yet to tell you that it's improved by x percent, but we are seeing that it is noticeable. When I tested this on SMS 2003 versus SMS 2.0, it was significantly faster, notably faster than what I used to see for SMS 2.0.

The next change is that Topaz clients only listen on TCP. Your SMS 2003 clients, whether they're standard or mobile clients, don't listen on IPX or on NetBIOS, they only listen on TCP. The Administrator console still is going to blast out over TCP, it's going to blast out over LANA, and it may blast out over IPX for appropriate clients, because you may have some earlier-version clients that you're trying to get to. However, Topaz clients only listen over TCP anymore, they don't listen over NetBIOS or IPX. But we do still support those, for earlier-version clients.

The next change is kind of big one, which is that we no longer will use the SMS site database's IP address for client IP address resolution. So when we find the client, we don't go to the SMS site database to find its IP address that we want to try to communicate with across the wire. Instead, we'll use standard TCP host name resolution techniques, whether it's DNS server or whether it's a WINS server, or whatever you have configured to resolve that host name into an IP address.

The reason for that is, it's good for scenarios where you're using DHCP and you have a very short lease life in DHCP. So it's possible that an IP address that was registered by a client in the SMS site database may now have been given to a different computer. So if you go to the site database and say, "I want to connect to this client," it has an old address there, which may physically be a different computer on your wire. So now you attempt to connect to the wrong computer across the wire, because that computer happens to have your IP address.

The scenario there is you're not using the Logon Discovery, you're only using Heartbeat Discovery, so that only updates the discovery data every seven days, by default. And you may have changed your DHCP IP address more frequently than that, because you have a shorter lease life. So what we'll do now is go directly to your name resolution techniques and say, "The computer name is TOPAZCLIENT, what's the IP address for it?" In this case it may very well go to DNS first, whatever you have configured for your host name resolution techniques in order. We'll use that, as opposed to the site database.

There has also been some additional driver verification. What that means is the Remote Control drivers have gone through our Windows Hardware Quality Lab to verify that they work on more platforms. So that may ease the setup and configuration concerns that you might have had.

We have some additional logging available for the Administrator console, which is Remote.exe. So when you launch the Remote Tools function or Remote Control, that uses Remote.exe, or there's also a command-line program you can run. There is additional logging for that.

One additional change for SMS 2003 in the security scenario is that you don't have to be a local user to remotely control a client computer. You just have to have Use Remote Tools security rights as well as be on the Permitted viewers list to be able to remotely control a client computer in SMS 2003. You don't have to be a local administrator anymore.

Another change is that your local administrators don't have to be added to the Permitted viewers list. Administrators by default are given a kind of guest access to the Permitted viewers list. So if they're not administrative accounts, then they just have to be added to the Permitted viewers list, but they don't have to be a local administrator on the remote client to launch Remote Control and access the client computer.

Next we have a screen shot (slide 12), just a very simple one, and you've probably all seen this before. This is to a Windows 2000 Professional client, and I've gone to the Action menu, or in this case, I right-clicked, I selected All Tasks, and you see the different options available. The very bottom one is Start Remote Tools. That would launch your Remote Tools window, which we saw a couple of screen shots ago.

Then the three options above that, Start Windows Performance Monitor, Start Windows Diagnostics, and Start Windows Event Viewer, those are the administrative tools that I talked about before, which you can launch to the appropriate clients through your SMS Administrator console.

Now this client is just a Windows 2000 Professional client, so you don't see the options for Start Windows Terminal Services or Start Windows Remote Assistance, because Windows 2000 Professional doesn't have those capabilities. Later on you'll see a screen shot that shows that those other capabilities have been added to the computer. When I select TOPAZ2PDC as my client, I'll see some different menu options.

Okay, so that's the SMS 2003 Remote Control functions. In essence, they're the same as what you had in SMS 2.0. The next portion of the presentation will discuss the new things in SMS 2003, in regard to Remote Tools. One of the new options for Remote Tools for SMS 2003 is the ability to invoke Remote Assistance through the SMS Administrator console (slide 13).

Remote Assistance is new technology in Windows XP and Windows .NET Server. This is Microsoft's strategic direction, for SMS to use the remote support help capabilities that are in the operating system. If possible, we recommend that you use Remote Assistance, and I have a slide at the very end of the presentation that ties together all the Remote Control functions available for Topaz, and it outlines when you should use each of them. But that's just a teaser; we recommend that if Remote Assistance is available to your Windows XP clients, then use it.

Remote Assistance is built in to the operating system now, and it's available for Windows XP and Windows .NET Server computers. The SMS integration allows you to launch the Remote Assistance utilities, which is the Windows XP Help and Support Center option, from your SMS Administrator console.

So when you select a Windows XP or a Windows .NET Server client in your database, in a collection, and you select Action, All Tasks, you'll have an option there, Start Windows Remote Assistance to launch the Help and Support Center. That's not available on all client platforms, obviously. If you have Windows 2000 or earlier, you can't use Remote Assistance.

It also requires that your SMS Administrator console be running on either a Windows XP or Windows .NET Server system. You can only use Remote Assistance from one Remote Assistance-enabled computer to another - in other words, Windows XP to Windows XP, Windows .NET Server to Windows XP, Windows XP to Windows .NET Server, and so on. So you have to be running your SMS Administrator console on a Windows XP or Windows .NET Server-based computer to have the option to perform Remote Assistance. So there is an extra requirement on the SMS Administrator console end, that it has to be Remote Assistance enabled, which means Windows XP or Windows .NET Server.

Nothing additional is required on the client computer. Remote Assistance is already built in to the OS, so you don't have to install any additional drivers to be able to use Remote Assistance. If you've enabled the SMS Remote Control function - your Remote Tools Client Agent - that will be installed there, so you may have an option to perform either Remote Assistance or the SMS Remote Control functions to a Windows XP or Windows .NET Server-based computer. So you have that option. But Remote Assistance doesn't require anything extra on the client end, because it's all built in to the OS itself.

There are a couple of things that SMS can do, as far as configuration (slide 14) of Remote Assistance for integration with SMS 2003. For the configuration options, I'll show you a screen shot on the next slide that shows you how SMS can perform some configuration. The first thing is that the SMS Administrator console can configure Remote Assistance interaction. There are two different options there, which we'll see on the next slide. One is called Manage Remote Assistance settings and the other one is Override Remote Assistance user settings.

Basically those dictate how much control the SMS Administrator console has over using Remote Assistance or controlling the settings of Remote Assistance on a Windows XP or Windows .NET Server client. I'll discuss that more on the next slide, when I show you the screen shot.

The next thing is that we allow you set the level of permission or the level of access to a Windows XP or a Windows .NET Server system using Remote Assistance. There are three different options there: None, which means you don't have any capabilities; Full control, which means you can do anything you want to remotely; or Remote viewing only, the ability to just view the console, but not a Remote Control session - you can just view what's there, but you can't perform any control functions. That's one option that has been requested of SMS Remote Control for a long time now, but it's now there in the operating system.

One thing to be aware of is, if you're not familiar with Remote Assistance, user permission is always required for Remote Assistance sessions. As you know, in SMS, you can turn off the ability to require permissions on the client. So I can take remote control of a client without the user being there and stating, "Yes, this user administrator, 'Wally', is allowed to take Remote Control now."

With Remote Assistance, somebody does have to be there, because somebody has to answer the question, "Yes, I am allowing somebody else to remotely administer my computer." So that's built in to the operating system, and that's nothing that SMS has any control over. It's going to be there.

Also, if you're in a viewing session, and you decide to perform a Remote Control session, in other words take full control of the client, there is some additional prompting for the user stating "Do you really want to allow Remote Control to the client" as well. Those are, again, built in to the Windows XP environment and it's nothing SMS has any control over. So you can't disable that through SMS.

The SMS Permitted viewers list is used for unsolicited Remote Assistance access. There are two different modes of Remote Assistance in Windows XP and Windows .NET Server. One mode is unsolicited. Unsolicited Remote Assistance is where the administrator would make an attempt to connect to the computer, saying, "Hey, I would like to remotely control your client," or view it, or whatever your option is. That's the administrator stating "I want to help you out," without it being requested by the user. So that's the general scenario you would see with SMS, where I right-click on a client computer and select Start Remote Assistance, that's unsolicited. I am initiating the action from the Administrator console.

The other mode is solicited Remote Assistance. That's where the user himself, from his remote client computer, would state "I need help with performing some function," and the user would create what's called a ticket that would include the client computer's IP address and how long this ticket is valid for, something called a time to live. This has been sent to the admin computer by e-mail or Instant Message, or saved in a file, then the Administrator would double-click that either through e-mail or in the IM environment, or through a file. They double-click that request, and that would launch the Remote Assistance function. So that's the Help and Support Center.

Solicited remote assistance is not something that SMS performs. We perform unsolicited assistance because of the fact that the Administrator is initiating the action, which is unsolicited. When you perform unsolicited assistance, the client computer is going to use the Permitted viewers list from SMS to dictate who can launch an unsolicited Remote Assistance session to my client computer.

Now again, remember that the user at the remote client still has to say, "Yes I want to allow this to happen" and "Yes, I do want to allow a Remote Control session to happen." So even though the administrator is requesting the ability to help you, and they are looking at the Permitted viewers list, the remote logged-on user still has to say "yes" to allow that function to occur at the remote client computer itself.

At all times any Group Policy could be used either locally or through a domain Group Policy to override the SMS configuration. So SMS configuration in the hierarchy of policies is the lowest level. In other words, it will always be overridden by a local policy or by a domain Group Policy. So any kind of other policy that's generated outside of SMS would be able to override any settings that the SMS policy might have set on that client computer.

Okay, the next screen (slide 15) is a screen shot of the different areas of Remote Assistance configuration. On the left side is the General tab of the Remote Tools Client Agent properties. If you look down at the very bottom of the General tab, you'll see the Remote Assistance section. There are two options there, Manage Remote Assistance settings and Override Remote Assistance user settings. The Manage Remote Assistance settings is dictating whether or not SMS is going to touch Remote Assistance settings at all, on the client computer. In other words, can SMS affect the settings on a Remote Assistance-enabled computer at all?

The second option is Override Remote Assistance user settings. Can the SMS site-wide settings override any local settings that the logged-on user may have set locally for Remote Assistance? That would be in the Remote Control applet. If you enable something in the Remote Control applet on the client through Control Panel, would an SMS policy override what the user may have set locally? So in other words, does the user have the ability to change his settings locally through Remote Assistance?

So you have those two. Then if you look at the Policy tab, which is the right screen shot, at the very bottom is Remote Assistance again, and it has Level of access allowed. And you have three options there. Your three levels of access allowed are either None, no Remote Assistance capabilities at all; Remote Viewing, which is the ability to just view the screen remotely (watching the user perform his function, and then through a chat or something else telling them what they did wrong); as well as Full Control - the ability to take control of the keyboard and mouse and configure something or show the user how to run something remotely.

Also something new, if you look in the middle of that dialog box, it has nothing to do with Remote Assistance - but if you see in the middle of the dialog box it says, Display a Message to ask for permission. Then below that is Do not ask for permission. Those are standard, but in between those, for SMS 2003 or Topaz, we have a new check box, to ask permission Only on clients running Windows 98. The reason for that is you may not want to have permission on your Windows NT 4.0 and later clients, because they adhere to the Permitted viewers list. You can designate what users are allowed to remotely control a client through the Permitted viewers list.

However, Windows 98 doesn't use the Permitted viewers list and it's not as secure of an operating system. So you might want to say only provide the message box "Do you want to allow this user to remotely control your client, yes or no," on a Windows 98 computer, and not higher-end platforms. That's an option you have.

Then at the very bottom of the screen shot you see User permission is always required for Remote Assistance. So regardless of what you said above, for whether or not user permission is required, it's always going to be required for a Remote Assistance session.

Okay. So that's Remote Assistance, it's built in to the Windows XP and Windows .NET Server operating systems. The last option you have for SMS 2003 in Remote Tools is the Windows Terminal Services (slide 16). Windows Terminal Services can be used by SMS as well. So what this means is that the SMS 2003 Administrator console can launch a Terminal Server session to an appropriately configured client computer. This gives you integration to the SMS Administrator console if you're running on a Windows 2000-based computer. So if I'm running on Windows 2000, Windows XP, or Windows .NET Server, with my Administrator console I can use Terminal Services down to a client computer, provided it has the appropriate code enabled on the client computer. We'll talk about that in just a second.

So you select a client in the Administrator console, in a collection, right-click or click the Action menu, select All Tasks, and now you see an option for Start Windows Terminal Services. This is available for Windows NT 4.0 and later, provided they have Terminal Server code installed on the client computer. That's available for Windows NT 4.0, Windows 2000 Server and Windows 2000 Advanced Server, Windows XP (where they call it Remote Desktop), and Windows .NET Server.

Nothing additional is required in the Administrator console computer, because with the SMS capabilities we built in Terminal Services client code. So it's already there on your SMS Administrator console (the Terminal Services client), so you just have to have Terminal Services enabled on your client computer. Then you can launch a Terminal Server computer session. I'll show you that in a couple of screen shots as well.

For configuration, there are a few unique things that you might want to talk about in Terminal Services when accessing a Windows XP or Windows .NET Server computer (slide 17). First, in Windows XP they call it Remote Desktop instead of Terminal Services. Remote Desktop in Windows XP is the Terminal Services that you're aware of from earlier operating systems, such as Windows NT 4.0 or Windows 2000.

There are two different ways of launching a Remote Desktop session. If I'm logged on with the same user credentials at the Administrator console that's logged on at the remote client computer, then I would remote to their session. So I could see the exact same session that the remote user had left on that remote computer. Basically I'm just viewing their console, and I can do whatever I want to from that console, because I'm logged on as the same user that's logged on remotely.

However, when an administrator starts a Terminal Services session to an appropriately configured client, that will create a new session. What that means is it logs off the Remote User, and then logs on to the remote computer as an SMS administrator logged-on user, and then starts a new session. That would be starting a brand new session, as opposed to viewing a session that was already there from your last logged-on user, or the user who was previously logged on before I started my session as an admin user.

So if I use the same credentials, I get the same desktop I have. I just remote to the existing session. If I log on with an administrative account, in other words, not the same user account, then I would start a brand new session, remotely logging off the user who was logged on the Terminal Services computer.

For Windows .NET Server, that changes just a little bit, in that regardless of what your credentials are, you have the capabilities in Windows .NET Server to say "I want to remote to the session" or "I want to start a new session." If I say remote to the session, when I give them the option to start a new session, remote controlling the existing one, if I use Remote Control, I get the session that the logged-on user had left. If I say start a new session, then I start a new connection and a new session to the computer, logging off the logged-on user at that remote computer. So it's a little bit different in Windows .NET Server.

The screen shot on the next page (slide 18) shows a client where I have the capabilities of starting a Terminal Services session. So I'm selected on TOPAZ2PDC and I've selected Action, All Tasks, and now you see I have started Terminal Services client. That allows me to perform a Terminal Services session through the SMS admin program out to a computer. In this case it's a Windows 2000 Server computer that does have Terminal Services enabled. I can start a Terminal Services session.

You still see the four options above that, Start Windows Event Viewer, Start Windows Diagnostics, Start Windows Performance Monitor, and Start Remote Tools. So I still have those capabilities, as well as Terminal Services.

Remember when you looked at the previous computer, TOPAZCLIENT. TOPAZCLIENT didn't have the Start Terminal Services Client option because it was just a Windows 2000 Professional computer, and it wasn't a server computer that had Terminal Services enabled.

Those are our three Remote Control options for SMS 2003. Which one would you want to use? Before we get into which you want to use, here is quick recap, a matrix (slide 19) that shows you all of the different options and which operating systems they're supported on.

In the left column I have the client operating system from Windows 98 down through Windows .NET Server. In the next three columns I have the appropriate Remote Control function - whether it's SMS Remote Control, whether it's Windows Terminal Services, or Remote Assistance. In there I just have a yes or no listing for whether or not the OS in the left row supports Remote Control, Terminal Services, or Remote Assistance.

So you can see under the Remote Control option that all of the operating systems that are supported for Topaz, SMS 2003, do support Remote Control. Whereas if you look at Terminal Services - for Windows NT 4.0, it's only if you installed the optional Terminal Services, as well as Windows 2000 Server, Windows XP, and Windows .NET Server - they all support Terminal Services, but the client operating systems don't. Only Windows XP Professional and Windows .NET Server allow Remote Assistance.

So again, the appropriate tools are available for the appropriate operating system.

Now that you know which tools are available and for which operating systems, how do you decide which one to use (slide 20)? Let's say I have a client computer that is a Windows XP client. So it does have SMS Remote Control, it has Remote Assistance, and it has Terminal Services available. Which one of the three functions should I use?

So just as a recap, SMS Remote Control is built into the product. There is nothing extra that you have to buy, so it's a cost-effective solution. It works in all the client platforms that SMS 2003 supports, so it covers your entire client base. It's generally fairly reliable. It doesn't have great performance, but it has good enough performance that it is usable in a local area network scenario. However, over dial-up links, it's oftentimes not the best performing. But if you need to cover all your clients and you don't want to incur any additional licensing or expense, then you have the SMS Remote Control option, and it's there for you.

Remote Assistance, this is what we recommend for Windows XP clients. So if the client you're trying to access is a Windows XP client, then we highly recommend you use the Remote Assistance option. It has great performance and no extra drivers are required, so there is no issue with drivers or compatibility. It only requires that Remote Assistance is enabled and that you're sitting on a Windows XP Professional or Windows .NET Server Administrator console, to be able to launch the Remote Assistance capabilities to your client computer. And then again, that you're in the Permitted Viewers list. But that's our stated direction or strategic direction for you, is to use what's built into the operating system. So for Windows XP clients, use Remote Assistance.

For server computers, it's generally recommended to launch Terminal Services. Use Terminal Services from the SMS Administrator console when you want to perform some support work for your server computers across the wire. It has the capability for all your server-based client computers. Desktops don't have it, but the server computers do. It has very good performance, and it allows you to either log on with the same user context to remote the same session, or log on with a different user context as an administrator and grab a brand new session. Now again, when you grab a brand new session you want to be careful because it's going to log off the remote user. So you want to make sure that they didn't have a lot of applications running and data that wasn't saved.

So it has very good performance, and with .NET Server you can choose whether or not to remote the existing session or create a new session. So you have that new capability.

What we'd tell you to do is to use whatever meets your business needs and whatever solves the problems you have with your clients. So if it's a cost issue, then use the SMS Remote Control, because it's built in. If you have Windows XP Administrator console and Windows XP or Windows .NET Server clients, use Remote Assistance. For your server computers, if you have Terminal Services already in place, use Terminal Services. If not, then look at the SMS Remote Control function. So use what makes sense for your environment, so that you do have the capabilities to support all your users.

Last, let's talk about interoperability with SMS 2003 and earlier-version SMS sites (slide 21). What capabilities are there for a Topaz SMS Administrator console remotely controlling some of the older client bases? The SMS 2003 Administrator console can remotely control SMS 2.0 clients. We've already discussed that Topaz clients only listen on TCP, whereas SMS 2.0 clients listen on TCP, IPX if enabled, as well NetBIOS. So you have the capability to use any one of those three protocols to get to your clients.

Even though Topaz clients only listen on TCP, the Topaz Administrator console does support all three of those protocols. It can communicate over TCP, IPX, or NetBIOS to the appropriate client computer. You do have the ability to go into your earlier-version clients. We use that for you. You can use any of those methods that are necessary, and we blast those out automatically. So whatever is enabled your client, we will pick up one of those, whichever one responds.

SMS 2003 and SMS 2.0 use the same ports for Remote Control. So for the standard Remote Tools functions, we use the same ports, again as of SMS 2.0 SP2 and later, up to SMS 2003. Again 2701 through 2704. But if your client does not respond over port 2701, which is the SMS 2.0 SP2 and later port and the standard SMS 2003 port, we will back down to port 1761, which is the port that was used for SMS 1.2, as well as SMS 2.0 original code and Service Pack 1.

So that's interoperability. Let's do a quick summary (slide 22), and then we'll hand it over to Otto to kick off our Q&A session. So as a quick wrap up for you, SMS 2.0 provided Remote Tools support that allowed you to have Remote Control functionality, launch programs remotely, reboot computers remotely, transfer files between the two systems, and chat in an environment through text messages, as well as perform a Ping Test, and you have the standard Windows administrative tools Event Viewer, Diagnostics, and Performance Monitor. They all worked, but not necessarily with the best performance.

Topaz, or SMS 2003, includes the same Remote Tools support that SMS 2.0 included, but it has some performance improvements to make your CPU usage less so you get better performance, as well as it adds some new capabilities that we'll talk about on the next slide. So the Topaz version of Remote Control supports all the client platforms that are supported by SMS 2003, as well as your SMS 2.0 client base.

On the next slide (slide 23), the last slide for our summary, Topaz now adds a couple new capabilities. Besides some of the new enhancements for the standard Remote Control function of not looking at the client IP address in the SMS site database, but going straight to DNS for it, performance improvements, not having the requirement of being a local administrator but just in the Permitted viewers list, and using just TCP, we add some new capabilities for you. So for appropriately configured systems, you could use Remote Assistance or Terminal Services instead of the SMS Remote Control function.

Those two solutions generally offer better performance than what the SMS solutions provided, but they have platform limits, in that Remote Assistance again is only from an Windows XP or Windows .NET Server SMS Administrator console to a Windows XP Professional or Windows .NET Server platform. And Terminal Services requires the extra Terminal Services code to be installed on your client computer, which involves licensing issues as well. So you have to take that into consideration.

Topaz can successfully use the appropriate Remote Tools functions to its full client base, including the SMS 2003 clients and your SMS 2.0 clients that you would have at any of your SMS 2.0 child sites to your Topaz environment. So that again gives the ability to support your full SMS client base from a single SMS Administrator console, which is running under SMS 2003 or Topaz.

With that, I'll kick it over to Otto, and he'll get us going on our Q&A session.

Otto Cate: Great. Thanks for the presentation, Wally. Before we move on to the Q&A portion of the Support WebCast today, we have a couple of program notes we'd like to share with you: The Q&A portion of the Support WebCast is really intended to encourage further discussion of today's Support WebCast topic. One-on-one product support issues are outside the scope of what we're able to address. If you do find that you need some technical assistance that requires one-on-one support, feel free to submit an incident on the Web, or call Product Support Services and speak to a support professional.

Okay, it looks like we have a few questions here. The first of which is: It was quite a challenge to write a wrapper for Remote.exe and SMS 2.0 for our help desk users. Will the command-line switches for Remote.exe be better documented in SMS 2003?

Wally: Yes. Good question. There are a number of things that weren't documented very well in SMS 2.0. The Remote.exe command-line utility was one of those. So that is something that we are going to try to do a better job of, documenting the extra command-line utilities or capabilities that you had, which were hard to find information about in SMS 2.0. So yes, our goal is to try to better document all of the utilities for you, including Remote.exe. There are command-line switches for that if you don't want to use the Administrator console to kick them off, in a Remote Control scenario. So yes, we are going to try to do a better job of documenting that for you, so that you know what the switches are and how to use the product in an easier fashion.

Otto: Okay, great. In comparison to SMS 2.0 Service Pack 3, are there any improvements in the Remote Control tools? Or do we have to wait until SMS 2003? For example, is performance over dial-up better in SMS 2.0 Service Pack 3 versus SMS 2.0 Service Pack 2?

Wally: Another good question. For the most part, the only change in Remote Control from SMS 2.0 Service Pack 2 up to Service Pack 3 was that SMS 2.0 Service Pack 3 re-enabled accelerated video drivers for Windows 2000 clients. So in a Windows 2000 environment, your remote control functions got better performance, because of the fact that we now had accelerated video drivers again. Whereas in SMS 2.0 SP2, where we first supported Windows 2000 clients, we didn't have accelerated video drivers, so you didn't have great performance on Windows 2000 clients. Your performance was lower in Windows 2000 than you had for other client platforms. But SP3 re-enabled accelerated video drivers for Windows 2000 clients, so you got better performance. Outside of that, nothing else has been done for performance improvements in SP3, or to my knowledge in SP4, outside of standard bug fixes. But performance-wise, it's that one change in SP3. Other than that, you'll use the utilities in the operating system or in SMS 2003.

Otto: Okay. Just to verify, in SMS 2003, can a Remote Control session be launched via a command line? For instance, in SMS 2.0 Service Pack 2, you can use Remote 2 ipaddress \\smsdbservername\ to connect to the client PC.

Wally: Yes. This is an example of the earlier question, regarding the Remote.exe utility. So this allows you to specify from a command line, when not in the SMS Administrator console, to launch a Remote Control session to the specific IP address that you specify with the option of 2 for ipaddress, and then the \\smssitedatabaseserver name\ or \\smsdbservername\, as it was listed to Remote Control a client. So those are some of the command-line options that the earlier question was asking about.

Yes, you can still do that. Remote.exe is still there in SMS 2003, so anything that you've done, wrappers or your own utilities that might use Remote.exe, those will still work in SMS 2003, because the utility is still there, and in essence it didn't change. It will now hopefully be better documented for you, so it's easier for you to use that function.

Otto: Great. Is SMS 2003 going to be tied in with Active Directory^®?

Wally: SMS 2003 is not going to require Active Directory; however, it is going to integrate much better with the Active Directory environment if it is in place. So it will allow you to perform discovery of computers and users as well as groups from the Active Directory. It will also allow you to utilize Active Directory site names for SMS site boundaries in SMS 2003. As well as, if you have Active Directory in place, you can publish some information about some specific servers in your SMS 2003 environment in the Active Directory, which will help your clients locate resources better.

Last, if you want to make your SMS environment more secure, if you're in an Active Directory environment, you can use Active Directory and SMS, and then secure your environment through the Advanced Security mode, which will reduce the use of user accounts in your environment. So it makes your environment much more secure, and your services will be running under the Local System context as opposed to those separate user accounts that we create in SMS 2.0.

So it's not tied to it; however, if you have it, we will take advantage of Active Directory and we'll give you more capabilities. And it will be easier to administer if you do have Active Directory there, but it's not tied to it, and it doesn't require it.

Otto: Okay. The next question looks like we may have touched on it during the presentation. I wanted to throw it out here just in case though, just for clarification, really: Is Remote Assistance similar to Remote Desktop in Windows XP?

Wally: Remote Assistance is a different Remote Control technology than Remote Desktop. Remote Desktop is Terminal Services. They just renamed it in Windows XP. So Terminal Services is Remote Desktop.

Remote Assistance is another capability, but it's slightly different. You have some better performance in those than you do with the SMS utility, but one of the things that I noticed was different between the two was that Remote Assistance requires a user to be logged on remotely. So when I try to send Remote Assistance to the desktop, somebody has to be there to say "Yes, you are allowed to take remote control of my box," and you don't log off the user. Whereas with Remote Desktop, one of the options you would have, depending upon the credentials you're supplying, is if you're logged on with an Administrator account that's not sitting remotely with that client computer, with Remote Desktop you would log off that remote user and log on at the Administrator console with a new session. So you'd be starting a new session.

Also, in Remote Assistance, the user can initiate the action. So the user needing help can say, "Hey, I need help, help me out here" by creating this token for solicited Remote Assistance. So the user can request the help in Remote Assistance, whereas in a Terminal Server or Remote Desktop or SMS Remote Control environment, the Administrator is initiating the Remote Control action. Now, it may be prompted from a user who called up the Administrator or something else and said, "Hey, I need help." But it's the user at the administrator station who is initiating the Remote Control to the client, whereas in Remote Assistance, you have solicited Remote Assistance where the user, through his utility, is saying "I need help," and then the admin would respond.

Otto: That's great. Thank you very much for that clarification. Okay, next question here: How is the administrator made aware of a solicitation, and where would it appear? Does the SMS snap-in have to be running to receive that request?

Wally: Okay, so this is for solicited Remote Assistance. SMS itself does not interact with solicited Remote Assistance. What it does is the administrator is sitting at the Administrator console. You go to your collection, you find the client, you right-click on the client, point to All Tasks, and then you would select Start Remote Assistance. That's considered unsolicited Remote Assistance. In other words, the administrator is initiating the action to help the user, as opposed to the user.

In a solicited environment, the user would launch their Help and Support Center utility, and they would create a ticket to send to the administrator, saying "I need help. Here is my computer and here is how long I'll allow you to try to connect and help me out."

That would be sent to the administrator console as an icon in an e-mail message, an Instant Message, or just saved in a file format and sent to the administrator, who would then just double-click on that file, the icon in the e-mail, or the icon in the Instant Message session. That would launch the Remote Assistance function back down to that client computer. They would be prompted, "Do you want to allow Remote Assistance user to assist you?"

So again, it has nothing to do with SMS for the soliciting. If you tell SMS to manage that, we do have the ability to turn on solicited Remote Assistance or turn off Remote Assistance if you allow SMS to manage your scenario. So that's all that SMS does with solicited Remote Assistance, it turns it on or off if you've given the Administrator console or SMS the ability to manage and override your Remote Assistance settings. Otherwise, SMS itself only performs unsolicited Remote Assistance.

Otto: Great, thank you. Next question here: Are there any plans to provide support for Wake-on-LAN, or does it exist today? We have a lot of instances where the client is powered down and it delays us from getting the clients up to date.

Wally: Today there is no built-in Wake-on-LAN scenario or support in SMS 2.0 or SMS 2003. We don't have that. So right now we suggest you go to some of the third-party vendors such as 1E, they have a solution, and there are a few others that have solutions. So the solutions right now are through third parties.

One of the reasons that we haven't taken a more direct stance on that and done something on our own is that when we talk to our customers, we see that the vast majority of our customer base isn't ready for Wake-on-LAN, in that their entire client base is not configured for it or doesn't have the infrastructure to support Wake-on-LAN. They don't have the networking scenarios set up. Their cards aren't Wake-on-LAN cards, and so on. So it hasn't been requested enough for us to push that to the top of the stack, versus some other things. So when enough of the customer base is at the point where they have the infrastructure to support Wake-on-LAN, then we'll possibly look at our own solutions. As of right now, there's nothing built in to the SMS product, so it would be a third-party solution.

Otto: Okay. I'd like to take some time to solicit some feedback from our audience. If you happen to have any suggestions for future Support WebCast topics or some general comments about today's session, or perhaps even the WebCast program as a whole, we'd love to hear from you. We definitely value your feedback most.

Simply include the word "feedback" at the beginning of your comments or suggestions, and I'll be able to separate those out. Send feedback to our e-mail address supweb@microsoft.com.

Okay, next question: What kind of Remote Control abilities will there be for non-PC Windows-based devices, such as Windows CE devices and Pocket PC, in the new version of SMS 2003?

Wally: When SMS 2003 ships, we will still only support Windows-based devices - Windows 98, Windows NT 4.0, Windows 2000, Windows XP, and so on. So we do only support those types of devices. Later we're going to provide the ability to perform inventory for Windows CE devices. So that will be the next thing we do in a post-Topaz release. So it will be something that will be added to Topaz, or a utility you can use to integrate with Topaz, to get inventory from Windows CE devices.

Then after that we'll look at things like software distribution and maybe Remote Control functions. But in the shipping SMS 2003 product, there will be nothing as far as Remote Control capabilities, through SMS, for those types of devices. They would have to have something built in to them, like Remote Assistance or Terminal Services, something in their operating system that's outside of SMS. But with SMS, there won't be a full client on those type of devices for quite a while yet.

Otto: Okay. When mentioning NetBIOS as an access method, don't you mean NetBEUI?

Wally: NetBIOS and NetBEUI are two different things. NetBEUI is a specific protocol that most people haven't used for quite a while now. NetBIOS is a session layer that goes on top of your protocol, which could be NetBEUI, TCP/IP, or it could be IPX. So when I mentioned NetBIOS as an access method, it is NetBIOS on top of one of the other protocols, for example TCP/IP or IPX. So it's not using NetBEUI. In fact, in SMS, if you look at it, the site boundaries you have only support IPX, as well as TCP/IP. So TCP subnets or IP subnets. So technically, if you look at it that way, you could say we don't even support NetBEUI.

Now I know there is a utility in the Resource Kit called Site4c.exe that would allow you to assign a client to a site that wouldn't normally be assigned to the site, such as using NetBEUI. But no, this NetBIOS is a session layer on top of your existing protocol, and that's what I'm referring to when I say NetBIOS, not NetBEUI.

Otto: Okay, great. Thank you. When administrating a Windows XP system as a full domain/local administrator, how can you force immediate Remote Control without user acceptance?

Wally: If you're talking about using Remote Assistance, you can't. It doesn't matter who you're logged on as, Remote Assistance always requires a user to be logged on and the user to respond appropriately with a yes or no to whether or not the admin is allowed to perform Remote Assistance.

Now with a Remote Desktop, again that does allow you that capability, by performing Remote Desktop and starting a new session. That would log off that user. But Remote Assistance does require it. It's built in to the Windows XP operating system. There's nothing we can do to get around that. It is always going to be a requirement for Windows XP.

Otto: Okay. Will SMS 2003 be a "dot" release or a new version of SMS? There is also a question concerning additional fees or anything of that nature, if you could give us some kind of feedback. I'm not sure how much information we have that's publicly available there.

Wally: Okay. We've always stated that SMS 2003, or back when it was Topaz, when we didn't have an official name for it, was going to be a dot release. It was going to be a dot release, something like from a 2.0 to a 2.something. It's not a total rewrite, like from SMS 1.2 to SMS 2.0.

Now, it is a new version of SMS. So there is no doubt, it is going to be a new version, but it is a dot release, in that it's based primarily on SMS 2.0. So we've changed a number of things in it, but it's still largely the SMS 2.0 code base. So it is a dot release, but it is a new version, and it will upgrade in essence as a service pack would, going from SP3 to SP4 when it releases. So you have that kind of a capability for your upgrade, but you'll see some new things in it.

As far as an additional fee, it depends on the contract you have with Microsoft and how you bought it, whether it's through an Enterprise agreement, whether it would have an upgrade fee and so on. Marketing hasn't announced those, other than the fact that I think with some of your certain contracts, there is no upgrade fee. I think it's called Software Assurance. If you have a Software Assurance environment, then you get all products for the next two years after you purchase this, something to that effect. But I haven't seen anything from marketing that announces what the licensing fees will be when you upgrade to SMS 2003. So keep looking for that up on the SMS Web site, and see what the status is when we announce those.

Otto: Okay. It looks like we have a couple of users who are sending us some questions that are quite popular in all the Topaz WebCasts that you've done here. They're specifically looking for some idea on the release date. Do we have anything?

Wally: Things haven't changed from our last WebCast. So last month's WebCast was on upgrade, deployment, and interoperability, and the answer is still pretty much the same. At last week's Microsoft Management Summit in Las Vegas, we did hand out a preview CD to everybody who attended. So they had the option of taking home a build of SMS 2003. So it's available from that aspect.

Now as far as beta goes, we're still planning on beta later this summer. Then from beta to RTM, it depends upon the feedback that our early adopters as well as our beta testers give us, to tell us when it's ready to ship. We're not going to ship it before you guys say that it's feature complete, that it's stable enough, and that it scales well enough to allow you guys to deploy it. We don't want a product that you guys aren't going to deploy because it doesn't meet your needs. So until then, we won't release.

We're hoping that we can release by the end of the year, but there is never a guarantee. It depends on how well the beta goes, and what all you beta testers think about the product. So again, beta will appear later on in the summer. If you haven't signed up yet, your Microsoft field rep can sign you up for the beta. As we get closer to beta, then up on the SMS Web site, http://www.microsoft.com/smserver/default.asp, we'll have a link there for you to request a copy of the beta software. Then for RTM, that depends on what you all think about it.

Otto: Great, thank you very much. Well, with that, it appears that we've answered all of the questions that were submitted today. That's going to wrap up our session. I'd really like to thank Wally for coming out and giving us a great presentation, as always, and a great Q&A. We had a lot of really good questions here, and we really hope that this information was useful to you.

Feel free to send us feedback at any time at supweb@microsoft.com.

Hopefully you'll have the opportunity to tune again in the near future. Thanks much, and have a great day.