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: Welcome to our presentation, and let's jump right into it (slide 2).

First off, we're going to be discussing some of the problems that arise when Systems Management Server (SMS) attempts to manage mobile or remote clients. We'll define what we consider a mobile and a remote client, so you can understand throughout the presentation the differences between those two, and how SMS will interact with those two type of clients. We will review from last month's session how clients are assigned to new sites. That's very important when we're looking at mobile client scenarios.

We'll go through a review of the process for clients being assigned to a site. Then we'll talk about the process of SMS deassigning a client from a site. Then we'll talk about some of the other specific issues that Microsoft SMS 2.0 has in dealing with mobile and remote clients. We'll talk a little about software distribution issues with mobile and remote clients. We'll talk about network traffic considerations, and some of the traffic problems that are generated when managing those type of clients in your SMS environment. Lastly, we'll talk about some strategies for supporting mobile and remote clients in your SMS 2.0 sites.

That's what we're going to talk about today, so let's get going. First off, problems (slide 3): What are some of the problems that SMS has, or that companies have, when they try to integrate and interoperate mobile and remote clients in an SMS 2.0 environment? First is that mobile clients may be reinstalled during a new site visit. The scenario here is I'm a laptop user who primarily uses my laptop plugged into my LAN at my office, then I go to visit a remote location. At that remote location, I get an IP address that's appropriate for that remote site. From that point on, it's possible that my client might actually be reinstalled, as I'm visiting that remote office, and that may not be what you want to have happen. Most likely that's not going to be the case, but that's one of the problems we have to work around when we're looking at mobile and remote clients in an SMS 2.0 environment — clients being reinstalled when they visit new SMS sites.

Another problem is that if the client retains the old site, in other words, it does not move to the new site, then all connectivity, as far as SMS is concerned, for that existing client is going to be to their remote site. It's going to be going to the remote path, the remote logon points, the remote distribution points, the remote software metering servers — whatever sites this and that client needs access to, they're going to be remote to that client's original or home site, or the principal site. So all that connectivity will be over whatever wide area network (WAN) links you have from the existing location, back to the location where the client's real site systems happen to reside, whether that's over WAN link, or whether it happens to a local area network (LAN), or some sort of remote link. So that's something you need to take into consideration.

The network traffic, as a result, may be local or remote. Obviously, if you have local traffic, the traffic's going to be much faster, because you're going over 10 megabyte (MB) or 100 MB LAN cabling. But if you do that, the settings for the SMS environment at that local site may not be the settings that are appropriate for your client computer. They may have different settings for hardware/software inventory, they may have different settings for remote control, their schedules may be set differently, and so on. However, if you maintain that client in its original site, which is remote from its current location, you'll have the proper configuration, but you're going over WAN links, so your communications are going to be slower. You may have delays, or you may have a link down scenario, so you may have no communication at all from the client to its appropriate SMS site systems.

Another problem is that when you're working in this type of environment, and the client is moving from one location to another location, users may or may not have any control over whether or not the client computer moves, deinstalls, reinstalls, or doesn't do anything, between those two SMS sites. If you do allow the user to have some control, then the user is going to be interrupted with prompts that appear on the desktop, saying, "Hey, I want to deassign you from this site. Is that okay?" Or, "Hey, I'm going to add you to this new SMS site. Is that okay?" So users will possibly be see dialog boxes or message boxes appear on their desktop, prompting them with questions that they may not know how to answer, that they may not want to answer, or that they may not have the appropriate knowledge to answer correctly, and that will affect how their SMS client operates during that SMS session.

Last, which site does software distribution occur from? Does software distribution occur from the site where the computer is currently residing, so I have fast connectivity to CAPs and distribution points? Or do I want to maintain my existing CAPs and distribution points and have the client go into those, even though they're over wide area links? If you choose the option of maintaining your existing site structure and the client accessing its original CAPs and distribution points, then you're going over WAN links, and any downloads or other things we'll talk about later on are going to be over those slower WAN links. If you choose to use the local resources, then you'll have faster access to the data; however, the advertised programs may not be appropriate for your client, or the agent settings may not be appropriate for your client. There are a lot of different issues there to consider. Those are some of the problems that people encounter when they're using mobile or remote clients in a SMS 2.0 environment.

Now let's do a quick definition of what mobile versus remote client really means (slide 4). As far as we're concerned, mobile clients are clients that do not normally reside in one SMS site, but that they may move to another SMS site, whether that's simply moving from one subnet to another subnet (and those subnets are in separate SMS sites), or the scenario I mentioned earlier, where you reside in a physical location as your primary location, and you go on a trip to another location, and hit another SMS site.

I think I've mentioned this before, but last summer I did a little tour of Europe and I was hitting a couple of the SMS sites, and I took my SMS site server with me. It had addressing and everything for my local SMS environment at my office here in Redmond, Washington, but then I went to Munich, Germany, and I encountered this scenario where, because I moved and got a new address, things changed in my SMS environment, just because of addressing. Then I went from Munich, Germany to our office in the UK, and when I got to the UK, I remembered that I was going to get a new address, and that was going to affect how SMS was going to operate. So I configured SMS to support that new address before I plugged in, and got that new address, and turned on my SMS site server. So that can happen.

That's what a mobile client is; one that is predominantly in one location, but occasionally may visit another location, going from Subnet 1 to Subnet 2. If they're local subnets, then you may very well be maintaining that single SMS site, not looking at moving from one SMS site to another. However, if you're going from one office to another office, you may very well be hitting a different SMS site, and that may affect how SMS is going to operate. That may affect your SMS site membership. You may have users that are interrupted with a prompt to change site membership or remove the client from specific sites. So that's a mobile client.

A remote client, on the other hand, is just a client that predominantly connects to the SMS site over slow link. So you're a home office user and you're dialing in, you dial in on a daily basis, and you're dialing several times a day, but you're always doing the same thing. You're always dialing in from your home office to the SMS site. There are different scenarios there. That client may not become a SMS client at all; it may have a slow enough network speed so that SMS will not install properly. You may have other checks in there that we'll talk about later on, to prevent that client from being discovered and/or installed. There are a lot of different scenarios there that we'll talk about, as we go on through the presentation.

If your link is fast enough so that SMS says, "Hey, I can support this client," it is going to download the appropriate software the client computer. Initially, that's going to be a little more than 3 MB of files that it has to download to the client computer, just to expand and perform discovery to even see if that client's subnet is part of the SMS site. So you're going to have some software downloaded, regardless of whether or not the client's subnet that is going to be on the dial-in client is assigned to your SMS site or not.

These types of clients, remote clients, don't change their SMS sites, because they're always dialing into the same location. If you're dialing into a single SMS site, there's no need to change from one SMS site to another, like a mobile client may do. You may experience traffic issues with remote clients; because you're dialing in over a slower link, it's going to take a while to bring down the appropriate software packages and other components to that client.

You may want to think about setting up a separate SMS site to configure agents appropriately, with the appropriate schedules, and enable months of agents, that are appropriate for the remote users. So you may want a separate SMS site that houses nothing or contains nothing other than the dial-in clients, so they can have agents that are appropriate for the remote clients. Such as, you might not want remote control, because you may not want to do a remote control session over your dial-in link down to that client, and support the client. If that's the case, then there's no sense in enabling remote control and downloading that 1.5 MB, or whatever it is, that Remote Control Agent, to the client.

You will probably want to set your schedules for your agents, like inventory, to not run on a daily basis. Maybe run them on a weekly basis or maybe on a monthly basis. So you're going to set your schedules to longer intervals, or less frequency, than you would have for locally connected clients. So those are mobile and remote clients and how we're going to define them and use that terminology throughout this presentation.

Now we want to talk about how resources are assigned to SMS sites (slide 5), and we did talk about this a little in last month's session. We talked about the client infrastructure and installation. So this a review, because it's fairly important for this discussion. Resources are assigned to a site by running either the manual installation wizard, which is Smsman.exe, or the SMS logon script batch file, Smsls.bat, and comparing the local IP subnet of the client against the assignment list that is maintained on the logon point.

What's going to happen is when you either run your logon script, Smsls.bat, or you run Smsman.exe, we're going to download 3.5 MB of files to your client computer, expand those files out, and then run a process called Discovery that we talked about last month. The Discovery process is required to determine what IP subnet that client is a member of. So we take the client's IP address and subnet mask from the registry, add them together, and come up with an IP subnet. That value then is compared to a file on the logon point called Netconf.ncf as your network configuration file, which is basically your assignment list.

If the client's IP subnet is listed in the Netconf.ncf file, then the client is assigned, and we'll proceed with the installation process. If the client's subnet is not listed, the client is not assigned, and we abort the process at that point. However, we still will have dropped down that 3.5 MB file, which is primarily Clicore.exe, which we talked about last month. So that's a big chunk of network traffic that could be generated to pull down to the client computer, which may be over one of your own links. Now, again, we don't do this if the link is detected as being too slow for SMS. And we'll talk about that a little bit later on, how you configure that.

Another scenario you have to look at here: is it in an environment where you have multiple SMS sites sharing a single domain for logon discovery and logon client installation. If your domain controller is shared among multiple SMS sites, then the client is going to check all sites that have Windows Networking Logon Client Installation enabled. So if you have five different SMS sites sharing a single domain, when this client runs a discovery process and then checks the assignment process, it's going to check the assignment rules for each of those five sites that have installation enabled.

The client may actually be assigned to multiple SMS sites. So if you have multiple sites sharing a single IP subnet, in other words a single IP subnet is added as part of the site boundaries, then that client is going to be assigned to those multiple SMS sites, and it'll become installed in each of those multiple sites. We'll talk about that a little more as we go on.

One of the issues you have in a remote dial-in scenario is that with Windows^® 2000, if you're familiar with Windows 2000 and its dial-in technology or the RAS technology, the subnet mask that the RAS server assigns to the dial-in client is all ones. In other words, the subnet mask is 255.255.255.255, and that doesn't work very well for IP assignment. So for SMS 2.0, we technically don't support you installing Windows 2000 clients over a dial-in connection. You need to install them on a LAN connection, then you can move them to a remote location. If you don't do that, they won't be assigned to the logon process.

There is a utility, I believe I mentioned it in last month's session, called Site4c.exe. That's a resource kit utility that you can use to force a client to be assigned to a specific SMS site. That can be used for when you have a client, such as a Windows 2000 client, that according to the assignment rules, would not be assigned to the site, but you really want that client to be assigned to that SMS site. You can use Site4c.exe from the resource kit and assign it to a specific site. Then we'll use that site assignment automatically for you. So that's something you might consider in that scenario.

To recap, resources are assigned an SMS site through the logon process, by Smsls.bat or by running the SMS manual installation wizard, which is Smsman.exe — those are the only ways that clients are assigned to a site, which are initiated by the client.

The next topic to discuss is how clients are deassigned from a specific SMS site (slide 6). Resources are deassigned from a site every time CCIM runs; CCIM performs a maintenance cycle. So when CCIM runs a maintenance cycle, it compares the local IP subnet against the assignment list that's located on the client access point. This differs from the assignment process we just talked about. Assignment always occurs during logon or when manually running Smsman.exe. So one of those two processes is used to assign resources to sites. Neither of those two processes will remove a client from a site.

The deassignment process is always handled and controlled by CCIM. That means the clients are reinstalled as an SMS client, and the client is running a CCIM maintenance cycle, which CCIM can run in many different intervals. If you do nothing and just let the client run by itself, it's going to run every 23 hours. But if you stop and start the SMS client service, if you log off and log back on, if you run the update configuration option from the Systems Management program in Control Panel, those can all be used to force CCIM to kick in. There's also a resource kit utility called Cliutils.exe or Setevnt.exe; those can be used to kick CCIM into a maintenance cycle.

When that occurs, CCIM performs a discovery process; it's going to go off and discover the current IP subnet. Again, just like the logon process did, it's going to use the same Discovery process, discover the IP address and subnet mask of the registry, add those two together, and come up with an IP subnet. The client will then take that discovered IP subnet, and compare it to the assignment list that's maintained on the client access point. So the client must connect to the client access point to perform this verification process.

If the client cannot connect to the CAP, no deassignment is processed. It will only deassign you if we do discovery. To get an IP subnet from the local computer, we can then connect up to the client access point, find its assignment rule file (which is the same file that's on your logon point, Netconf.ncf) and then determine that the client's IP subnet is not listed in the CAP's Netconf.ncf file. If that's the case, then we'll kick off a deassignment process for that client.

So this has nothing to do with the logon script processing or Smsman; it's purely how CCIM kicks in and when it kicks in. Either it's done through the automated function, or by you forcing it, via logging off, logging on, rebooting, restarting the client service, etc.

If you use Site4c.exe to hard code a site assignment to that client, then CCIM ignores that site. So it won't do any assignment or deassignment from that site. That site is always assigned.

I mentioned that the client has to connect to the CAP to be able to verify this assignment process. In a scenario where my client cannot connect to the client access point, we obviously don't deassign. However, CCIM will maintain a list of each site it's a member of and the last time it successfully connected to a client access point in that site. If it has been more than 60 days since that client has connected to a CAP in that SMS site, the client will automatically deinstall or deassign that client from that SMS site. So basically, it'll consider that client as being orphaned, such as if the SMS site has been deinstalled, but we didn't deinstall the clients. They didn't remove the site boundaries to deinstall clients, so this client has been orphaned.

So after 60 days of not being able to talk to a CAP in an SMS site, it will deassign that client from that site. If that happens to be the last site that that client is assigned to, then we'll automatically kick off a deinstall process. So if we have no assigned SMS sites, either from our new IP subnet not being assigned to any of my SMS sites, or I haven't been able to talk to any SMS sites for 60 days, then the client will be deinstalled. All SMS client software will be deinstalled. I believe we talked about that a little bit last month, as far as there are a few things that do get left, but we do kick off a deinstallation process.

So, we talked about how clients are assigned to sites. We talked about how clients are deassigned from sites. Now why is this a problem (slide 7)? This is a problem, depending on the SMS processing and the way the logon process may work, when you're moving clients from one location to another. You need to recall that assignment occurs from the logon point as part of Smsls.bat (your logon script), or when you run Smsman. Either one of those two, or both those, require access to an SMS logon point.

At that point, we'll verify the current IP subnet with the assignment list from the logon point. If we're assigned to a new site, we do our assignment. Then remember that deassignment occurs from the CAP during the CCIM maintenance cycles process. It doesn't happen as part of the logon process, like the assignment process does. It only happens by CCIM running, performing a maintenance cycle, and determining that it's not assigned to any SMS site, or a single SMS site.

Why this is a problem for you is this scenario: it's not uncommon when you physically move one computer from one subnet to another subnet, and let's just say that new subnet is a different SMS site. What often occurs is that the deassignment process, occurs prior to the assignment process being completed. So the scenario here is you've moved the computer from one subnet to another subnet, and in this case, let's assume it's two different SMS sites. You boot up your computer, but before you get done with the CTRL+ALT+DELELE and logon process and running your logon script and kicking in the Smsls.bat file, before you've accomplished that process, CCIM has kicked off automatically, because CCIM is part of the SMS client service, which is going to be kicked off automatically when you boot your computer.

So when you boot your computer, that service starts, CCIM kicks in, it runs its maintenance cycle and, "Oh, I've got a new IP address, which means I'm am a new IP subnet. I'll look at my old CAP that I'm connected to, I'm not assigned anymore. I'm not assigned to any SMS site, so I should perform a deinstall." At the same time it's performing the deinstall process, you go up to the keyboard and you do a CTRL+ALT+DELELE, you log on, and you go through the logon process. You kick off your SMS batch file, or you manually connect and run Smsman, and you say, "Hey, I'm assigned to this new site I'm sitting at." Well, what's happened is that we've already kicked off the deinstall process prior to you kicking off the assignment to a new site process. So what that means is the SMS client is going to be deinstalled from the existing computer as part of the CCIM process, saying I'm not assigned to any site. Upon being assigned to a new site, it knows "Oh, I need to be installed to this site." So it installs the SMS client software.

So what you've now just done is deinstalled your existing client infrastructure in that client computer from the entire client. Now you've been assigned to a new site. Now you reinstall your existing client software.

That causes a number of different problems that you need to look at. The first problem is just the process that you deinstalled and reinstalled, and that means extra time, extra processing load, extra network traffic. Deinstalling is no network traffic at all; however, the reinstalling process is network traffic. So you're going to chew up a few megabytes, maybe a dozen megabytes or so, to reinstall your client computer. So that's a big load on your network.

Also, because of the fact that you deinstalled and reinstalled your client, that means that when inventory takes place (hardware inventory and/or software inventory, whatever the appropriate for your site), you're going to perform complete or full inventory. You're not going to do deltas anymore. Because you deinstalled your client, you've wiped out any history that client had. You reinstalled your agent, it has to perform a full inventory cycle. So now you're going to have those 100 KB MIF files or 1 MB MIF files, or whatever is appropriate for your computers and the inventory agents and configuration that you have. So you can generate a lot of network traffic by performing full inventory cycles.

Also, any advertised programs that had been run on that computer from the old site that are appropriate for the new site this client is now assigned to, they're going to re-run on that client computer. Because when you deinstalled your SMS client software, your client lost track of which advertised programs it has already run. So it says, "Hey, I'm a brand new client. Oh, I haven't installed Windows 2000 Service Pack 2, so let me install it." It's going to kick off the installation or the upgrade for Windows 2000 Service Pack 2, or any other advertised programs that are applicable for the current client at the current site. So that can cause re-running advertisements, which could download big programs, could interrupt work, etc.

One other problem that you would have is if you had any custom MIF files that you had created, those MIF files would be lost when you reinstall. Because when you deinstall, we blow away most of the client tree. When you reinstall, we don't replace those custom MIF files. You have to re-create those custom MIF files to get your inventory set up the way you wanted it. Those are a few of the big problems that need to be managed when you're moving clients from one site to another site.

The biggest problem again is that the deassignment process oftentimes occurs before the assignment process, which means you may actually deinstall your SMS client before you get assigned to the new site.

Let's talk about SMS clients visiting other sites (slide 8). You may want a visiting client, in other words a client that is just temporarily going to a new SMS site, to become assigned and installed to the local site if the enabled agent at both sites is the same. So, if at my normal site and the site I'm visiting, all the agents are configured the same, the same number of agents, the same agents are enabled or disabled at both sites, the settings for each of those agents are the same, that may be okay to have the client become assigned to the new site, if all of your advertised programs are similar, so that you'd see, "Hey, I've already run this program."

If your client will not return home within a short period of time, you may want to have the client assigned to the new site. Now, when we say assigned to the new site, again, we mean you don't want your client to be deinstalled first. You want to make sure that your client gets assigned to the new site before it becomes deassigned from the old site. I'll talk about how to do that in another slide or two.

One of the issues you have is the bullet that says "The client will not return home soon." If you leave your existing client in its original site and don't have it be assigned to the new site, or don't have it join the new SMS site that it's visiting, then you need to make sure that client has the ability of uploading any client data files for SMS to the old site. You need to make sure that you have connectivity to the old site. Because of the way SMS operates, by default, an SMS client will only maintain data for eight days. So if I've generated inventory, or status messages, or new discovery records, whatever, I'm going to try and forward that to my client access point to my assigned site.

If I can't do that for a period of eight days, the client is going to remove those files. It's just going to assume, "Hey, these files are no longer valid anymore, because it's been more than eight days." Now that's something that you can modify in the registry if you want that time-out value to be longer, or the lifetime value to be longer; but the default is eight days. That's something to take into consideration. So if you're going to have people that are out of their office for a period of time and cannot connect to the old site, either data may be lost, or you may want that client to be able to assign and install into a new site, so it can report the data there. And maybe with the parent/child relationship, the data will be forwarded to the parent site anyway.

You may not want your visiting client to become assigned to the new site or the local site, wherever the client is residing, in other words, stay in its original home site, if the enabled agents are not the same. You don't want to have to install new agents while you're sitting there, then deinstall those agents when you go back to your home office, if the configuration of those agents is not the same. In other words, one agent at one location is looking for executables, .dlls and COM files, and whatever else for software inventory scanning, but your primary site is not interested in those files, it's just looking at VBX files, or whatever. Or, if your SMS SMS_def.mof files are different between the two sites, you may not want your client to change sites because you're going to be modifying all those settings again.

If your advertised programs are not similar, you're going to get programs that you wouldn't normally expect to get, or you're not getting advertised programs that you would expect to get at the new location, that you would normally get at the old location; you may not want your clients to join the new site.

If the clients will return home soon, they'll be able to get back to either report their data directly to the old site, or they'll be able to store that data for a long enough period of time that they can upload that data to their existing site's CAP when they return home. So if they can live with no other access to the SMS resources or slower access, and they can be able to get their inventory data, their status messages, DDRs, whatever else transmitted to an SMS site, so that they're not lost, then you may not need to have your client report to that new site that it's visiting.

One point to consider is that any time you add a client to a new site (so let's say you maintain the client in its original site and now you just add that client to a new site, so it's now a member of multiple sites), the next time inventory kicks in, it's going to perform a full inventory cycle. It's not going to do a delta cycle, because the new site doesn't have the old data for that client. So it wouldn't be able to process the delta inventory. We automatically force inventory to do a complete inventory, in other words, a resync inventory. That resync inventory will be the complete inventory, and it'll be shipped to both SMS sites. Not just the new one, but also the original one. So again, if that's going over a wide area link, that's going to be a larger data file that you're transmitting, and it may take a little while to transmit across that, because it's going to be a little larger in size.

We just mentioned that you may want to have your clients become members of multiple SMS sites simultaneously. If you do that, there are a few things to consider (slide 9). First off is that the client is installed in multiple SMS sites simultaneously. In other words, my client is on Site A and it's on Site B at the same time, so I'm assigned to both — the client is going to install agents that are enabled at either SMS site. So if Site A just has hardware and software inventory enabled, but Site B has software distribution or Advertised Programs Client Agent and a remote control, that client is going to have all four of those client agents installed. It doesn't just do what both sites want, it does what either site wants. So it's a concatenation of what both sites have for enabled agents.

We just mentioned this, but again, whenever you join a new SMS site and inventory enables that new SMS site, it's going to force a resync inventory the next time inventory takes place. That new inventory file is going to be sent to both your SMS sites. If the one site has inventory enabled and the other site does not have inventory enabled, then as far as inventory is concerned, it's not joining a new site, so it's not an issue.

When you do report inventory, one site may not get inventory at the desired intervals or the desired schedule that the other site is getting. So if I'm a member of Site A and my site says take inventory weekly, and now I join Site B, and Site B says take inventory monthly, guess what, Site B is going to receive inventory from that client on a weekly basis, because it's going to go with the inventory cycle of the principle site, or the home site. The principal site, by default, is the one it's installed to first. If I installed into Site A first, and that's my normal membership, and now I join Site B, I'm going to use my principal site schedules, which is going to be weekly. So inventory is going to be sent to both sites on a weekly basis, even though Site B is not expecting inventory for another three weeks, or another two weeks, or one week, whatever is appropriate; it depends on where you are on that monthly cycle. So you have to look at what site is being used as the principal site.

You can control what site is the principal site. All you have to do is go to your Systems Management program in Control Panel, and go to the Sites tab. As you look at the sites that are in your Sites tab, whatever site is at the top of the list is the principal site or the home site, and that's the site whose schedules are being used for the agents. If you want to change that, there are up and down arrow buttons to take an existing site, a lower site, and move it up higher on the list. So you can make it the new principal site.

In the case of remote control, we don't use the settings from just the principal site, however. For remote control, we use the settings that are the most secure for the client. So basically we combine all remote control settings from all sites the client's installed to, figure out what's the most secure for the client, and enforce those settings for all SMS sites. What that means is, let's say Site A does not require permission to be granted by the end user, but Site B does require permission to be granted by the end user. What's going to happen is that when remote control takes place from either SMS site, permissions are going to be required. So even from Site A, which doesn't have that option enabled, it says no permission required, and the client's going to say, "Hey, I'm going to make you ask me." And the administrator at Site A will get the prompt, saying, "Hey, I'm checking with the user to see if it's okay to have permission required." If the user is not there, or doesn't respond in time, then there's no remote control. So it will take the most secure settings for the client itself, and enforce those for all sites.

Lastly, we check each site during each CCIM maintenance cycle. So every 23 hours, or every time you force CCIM to run from Update Configuration, Systems Management program properties, or Setevnt.exe, or Cliutils.exe from the Reskit/Resguide, Restart the client service, etc., any time CCIM kicks in, it's going to perform a maintenance cycle on each of the SMS sites the client is installed to. So it's going to add any new components that are enabled at any of those sites, it's going to remove any components that are not enabled at any of the sites, it's going to update configuration settings from the principal site — like remote control settings and other settings sites are going to download to the client. But it's going to use the ones we've talked about already, the principal site or most secure for remote control, and it's going to configure those agents appropriately.

So it's going to perform a lot of work on each CCIM maintenance cycle to go to each account for each site and then download appropriate agents, download some deinstall agents as appropriate, download configuration settings for those agents, and so on. There's a lot of work that's going to be performed when a client is a member of multiple sites simultaneously.

So we discussed the problem with you moving a client from one site to another, and we actually deinstall the SMS client software prior to you becoming assigned to the new site. How you can control that is by using the SMS travel mode (slide 10). SMS travel mode is a method that allows you to control whether or not the client is deinstalled from a site or installed into a new site. You can enable travel mode for the computers that are going to change subnets and SMS sites. So if you have clients that are going to be predominantly moving from one SMS to another site, people that do a lot of visiting to other locations in your company or different companies, then you may want to enable travel mode.

If you enable travel mode, then by default, whenever your client is going to affect its site membership, whether it is assigning to a new site or deassigning from an existing site, a message box will pop up on the user's desktops, saying, "Hey, I'm about to deinstall from an existing site," and it will tell you what the site code is, or, "assign and install into a new site," and it'll tell you what the site code is. It'll prompt the user, "Do you want to complete the requested action? Yes or no?" The user will have the option of saying, "Yes, I do want to do that," or "No, I don't really want to do that."

When you answer that for a site combination, we actually mark that in the registry. If you ever hit that same site combination again, being "I should be assigned to a new site," or "I shouldn't be assigned to that site any longer," SMS will not prompt you with that same message box for a period of 30 days. So it will remember what answer you gave on a per-site basis, and not prompt you with that same data for a 30-day time period. After 30 days, it'll let you respond yes or no again to the appropriate question.

Travel mode is configured on a client-by-client basis. So you go to the client computer, you go to Control Panel, you kick off the Systems Management program, on the General tab, at the very bottom, it's called Travel Mode. This client connects to the network from different locations. So you just select that check box that says, "Yes, this client does do that," and that enables travel mode.

This is something that only a local administrator can perform. Local users can see what the setting is, but the option is unavailable to a non-administrative user at the client. They're not allowed to change the settings of the travel mode function. When you do enable this through the Systems Management program, we present a message box to the user any time the site assignment process is going to change, adding you to a new site, or removing you from an existing site. Then the user can respond appropriately to the question to assign or deassign.

Well, this is kind of a pain, having to go to each individual computer and configure the Control Panel program to set whether or not you want travel mode on or not. So there are a couple different ways you can do this on a site-wide basis.

One way is you could create an advertised program and send out a registry script that would make a configuration change to the registry to enable travel mode settings. So you can do that, and I don't have that listed on the slide, because that's not something we really want you to do. Travel mode is a special registry key that is shared with other processes on your computer. Oftentimes what's happened is clients have gone out there and they've changed the travel mode setting, but if they set the first or high-level bits incorrectly, the travel mode only uses the bottom five bits or the lower five bits of the eight bits. If you incorrectly set the first three bits, then you're affecting, in this case, the Terminal Services. One customer manually set the travel mode options through the registry, and it forced a reset of Terminal Server, which caused the SMS client to deinstall and reinstall numerous times. So we prefer you do not use the registry hack method.

Instead, use the utility I've listed at the bottom of the slide. That's the CliTravl utility that's included with SMS 2.0 Service Pack 2. In the Support.exe bundle of SP2, we've added CliTravl. CliTravl is a batch file and executable that you would run. So CliTravl is a utility that you could advertise to your clients as an SMS advertised program. You could command-line script it so that users don't see a thing, and you run it in the background in your hidden mode so that there's no user interface at all. You can assign it so it's forced on all computers, or at least the appropriate ones, and then you run the utility. That will set the appropriate registry keys properly, and not monkey with the other bits. So we have a utility that will set that for you automatically. You don't have to worry about what the registry settings are, you just need to worry about whether travel mode is enabled or not, and do you not want the prompt to appear to the user.

So with CliTravl, there are a couple of different switches. One switch is the /travel switch, and you can set that to on or off. So you go to Clitrvl.exe /travel =on or off as appropriate. If you turn travel mode on, then there's another switch called /prompt. The /prompt switch can be set to on or off. If it's set to on, then a message box appears to the user, asking, "Do you want me to assign or deassign," as appropriate. If you set the prompt to off, then we don't present the message box to the user, and we perform the appropriate actions. So you're basically telling SMS to complete the operation or to not complete the operation, as you deem necessary. That will help you get this mode set for all your users at one time.

Another thing you can do with CliTravl is, if you're not sure whether or not clients have travel mode enabled, you can run CliTravl with no parameters. It will return a 0 or a 1 — 0 if travel mode is not enabled, 1 if travel mode is enabled. So you can use it as a means of checking if computers that should have travel mode enabled do have it enabled.

Now that you have travel mode, if you have computers that are going to be moving from one SMS site to another, we recommend you turn on travel mode and actually leave the prompt on. So when I take my laptop from my office here in Redmond and I go to Germany next time, I would turn on travel mode. In travel mode, when I get an IP address and appropriate addressing information from my local site, I boot up and I see I'm on a different IP subnet now. Travel mode will be detected, and I would be presented with a message box, saying, "Hey, you're sitting at a new site now. Do you want me to assign you to this new site?" And I can say yes or no, appropriately. It would also come back and say, "Hey, you're no longer assigned to the old site. Do you want me to deinstall you or deassign you from the existing site?" So I get these message boxes that would appear. What we would want you to do is to enable travel mode, and then when the prompt to deinstall from your existing site occurs, our recommendation would be to say no. Don't deinstall from the existing site. Because, again, most likely that's going to appear before your logon process is completed, and you become assigned to the new site. So tell SMS not to deassign you from the old SMS site.

Then when the next message box appears, "Hey, you're now assigned to Site ABC, do you want me to install you to Site ABC," you say yes. So now your client is going to go ahead and be installed into both SMS sites. It will maintain you in your existing site, and add you to the new site you're visiting.

After you have that taken care of, you can either disable travel mode, or just leave it on and wait for the 30 days to expire, and then it will prompt you again, and you say, "Yes, deassign me from my old site," if it's going to be more of a permanent change location. If it's going to be a short trip there, you'd probably still want to say, "No, don't deassign me from the old one, but do assign me to the new one." That's the choice you'd make appropriately for each instance. But the key thing here is to turn on travel mode so that when you're prompted to deinstall, if that happens before the prompt to assign and install, you say no to the deinstall, so you're not deinstalling your SMS client software. Then you get assigned to the new client; now you're assigned to both sites. So now, if you get prompted to deinstall from your old site again, you can say yes, because it won't deinstall your client software, because you're already assigned to a new SMS site. So the key here is to not become deassigned from your last site before you get assigned to a new site. And travel mode can help you do that.

Okay, let's hit some of the issues that you have when you're in a traveling scenario. The first one we have is software distribution (slide 11). Here are some of the problems that you have with software distribution in a remote client scenario or a mobile client scenario.

First off, does the advertisement support slow links? When you create an advertisement, and you create an assignment for that advertisement, you can specify whether or not this assignment is mandatory over a slow link. If you specify that the assignment is not mandatory over a slow link, that can be very advantageous; you're not pushing down large packages like Office 2000 or Office XP or an upgrade to Windows^® XP, when it becomes available, or whatever the case is. You cannot force those down on the client over a remote scenario link.

By default, the slow link testing here is the same as the logon script testing, which is 40 Kbps. So during the processing of Smsls.bat, we look to see if your network speed faster than 40 Kbps. If it's not, we bail out of the logon script. If it is, we proceed, saying, "You've got a fast enough link, you can support an SMS client."

Well, the setting is the same for software distribution. However, it is configured differently, and we test differently. For the logon script process, the test is performed to your logon point. It tests to your logon point during your logon processing. And again, as I mentioned before, if you run Smsman.exe, it doesn't do the slow link test at all, it's only the logon script processing that does it.

If you want to change that 40 Kbps for the logon script process, you modify the logon script. The release notes for SP1 and SP2 (and I don't remember if it's in SP3, I believe it is) tell you how to modify your Smsls.bat file threshold for slow link testing. However, for software distribution, we don't use that answer, because that answer is going to go to your logon point, which is irrelevant for software distribution.

So as of SMS 2.0 SP3, which has just been released, the slow link test for software distribution is now going to your distribution point and not to the client access point. In SP2 and earlier, we did the test to your client access point, because that's where you were going to get your advertisements, was to the CAP. So we performed the slow link test to your CAP. However, there may be a scenario where you have a remote CAP but you have a local distribution point, and you may have selected that local distribution point in your random selection.

Now, as of SP3, we're selecting to do this slow link test against your DP, as opposed to your CAP, or your logon point, as the logon process goes. Also, the only way to change the 40 Kbps is through a site control file modification. It's not something that you change on a client-by-client basis, or even change on a logon script, or anything else. It's only changeable or configurable by a change or modification to your site control file. For that, you have to get PSS involved, because we don't support customers manually changing the site control file; it has to be a PSS-driven process. So you can contact PSS if you want to change that 40 Kbps setting for software distribution.

The next problem is that downloading large packages over a slower link can be time consuming and resource intensive. Either I'm a remote client, so I'm always dialing in on this 40 Kbps link, or I'm a mobile client, and I'm sitting at a remote location, but I didn't assign myself to the remote site. In other words, I kept myself in my principal site. So I'm doing all my checking and downloading of software from my original site, which is over some LAN link.

If you're downloading something like Office 2000, or Office XP, or service packs, or whatever, that can be a big hit on the wire. It can be very time consuming and resource constraining over that slow link. And the other problem is if the download fails, we don't currently have checkpoint restarting in our client software, so when the link becomes available again, you have to restart the whole process from the beginning, which is kind of a problem.

Then again, we already mentioned this, but if a client becomes deinstalled from all SMS sites, in other words you deinstall your SMS client software, and then you reinstall the client because you become assigned to the new SMS site, then you lose all knowledge of any previous advertised programs that had been run. So you'll re-run all your same advertised programs again. Any advertisements that are still valid are going to be re-run, even though you've already run them before; but you've lost all that history data, because you blew away your SMS client software, because you were deassigned and deinstalled before you got assigned to a new site.

So the example I gave earlier was Windows 2000 SP2; you ran it once, but then you moved to a new location. You deinstalled your client unintentionally, and then got it reinstalled unintentionally. Well we don't know that we already ran the Windows 2000 SP2 upgrade program, so we're going to run it again if that's a proper advertisement for your current site. That, again, is a little bit of network traffic to upgrade Windows 2000 to SP2.

There are some network traffic issues (slide 12) that you need to be aware of. If you are forcing your reinstall of your SMS client software, you have to remember that that can be anywhere from 10 to 15 MB of network traffic, depending on what agents are enabled at the appropriate site that you're installing from. So that's a hefty chunk of traffic. Also, this can only occur over links that are 40 Kbps by default. So if you get a slower link, it's not going to be reinstalled if you did do a deinstall. Again, as I mentioned, you can modify the master Smsls.bat file, which resides on the site server. Not the one on your PDC, but you modify the one on the site server, and you can change that threshold if you want. Or, you can use a manual installation, Smsman, which skips the slow net checks entirely.

You don't want your SMS client software to be deinstalled and reinstalled just because you're moving from one location to another location. That's where travel mode can be very important for you. Enable travel mode, say "no, I don't want to be deinstalled," say "yes, I do want to be assigned to the new site," if you do, and then we won't deinstall and reinstall your software, and that will save you that 10 to 15 MB of network traffic.

Plus, again, when you reinstall, you've already hit all the issues. You forced full inventory cycle, you rerun all your advertised programs, you lose all your custom MIF files, so there's a lot of downside to being deinstalled and then reinstalled.

I have listed on the slide the SMS client components and how much network traffic I've seen them generate at appropriate cycles. So a CCIM maintenance cycle is 90 KB per cycle per site. If I'm assigned to 10 different SMS sites, I'm going to perform that 90 KB traffic cycle on each SMS site. So I've got to go check what the assignment rules are, I've got to verify I'm still assigned, I've got to verify what agents are supposed to be installed, and what the configuration settings are for those agents, etc.

CCIM verification means that 30-day verifies process. So every 30 days, we verify each of your client components, and I have listed 3.5-6 MB. Obviously, that's going to change, depending on what components you have enabled, and this 3.5-6 MB would be if you were checking your entire client, verifying all client components, which we talked in the SP2 session a number of months ago — we don't do that anymore. We randomize each client component and have an offset on when we're going to validate or verify that client. So mostly likely, each 30 days is going to be 30 some plus days and hours, and you're going to be verifying a single client agent on each cycle. So it might be 500 KB, or it might be a 1 MB in size. It won't be 3.5-6 MB, unless your client is turned off for a long period of time.

With hardware and software inventory, again, you're going to have large initial files, predominantly, then smaller deltas after the fact. However, if you have to reinstall your client, it's a full cycle again. Or if you add the client to a new site that's requesting that hardware/software inventory, it's a full inventory cycle again. So those are going to vary in size, depending upon how you have your agents configured, and what software is installed in your client, etc.

Software distribution is 100 KB per cycle. So it's 100+ KB per cycle, as you kick in each of the ODPs. There are a couple of different ODPs to check for: advertisements to the computer, advertisements to the logon user, and advertisements to the logon user group. Those were over 100 KB of traffic every single time I checked, which by default is hourly, that we check against the client access point for any advertisements for the user, the user group that I'm a member of, or the client computer itself.

Software metering is 5 KB per program cycle per program checked. Every time you start a program or every time you stop a program, you're checking, unless they are excluded.

In remote control, on a Windows 2000 box, there's no network traffic to start your Remote Control Agent; so, nothing at all. On a Windows NT^® 4.0 box, where the Remote Control Agent starts as a service, there actually is some network traffic to start the Remote Control Agent. It's about 100 KB to go out there and validate all the members of your permitted viewers list. So if you have the default permitted viewers list, which if I remember correctly is nine different names or spellings or languages, or localized versions of administrators, it takes about 100 KB to go to a DC and validate all those names. On Windows 2000, that traffic is not generated at all. So if you reduce your permitted viewers list on a Windows NT 4.0 platform, you can reduce that startup traffic there as well.

So just remember, all this traffic that occurs, depending on where your client currently resides, and how it's set up, and how your SMS processes are going, this may be over remote links, so you want to be aware of what traffic is being generated, how much traffic, and what is taking place in those traffic patterns.

Lastly, let's talk about some strategies for supporting your mobile and remote client scenarios (slide 13). The first one is make sure you configure an appropriate slow network threshold speed. In your Smsls.bat file, the master one in the Data directory of your site server, you want to set an appropriate threshold speed. The default, again, is 40 Kbps. You may deem that you want something larger than that, so maybe you want 56 Kbps instead of 40 Kbps. Configure that appropriately so you're not even bothering with the slower clients.

Another thing you can use is a utility called CheckRas. CheckRas is an SMS 2.0 support executable bundled utility, and you can put CheckRas at the beginning of your logon script. When you process the script, CheckRas looks to see if dial-up networking is active. If dial-up networking is active, it bails out of the rest of the logon script, or you can have it do an IF THEN and skip the appropriate portions of your logon script, such as the SMS processing. So you can use that as well. Because even if you have a faster link, maybe a 56 Kbps link that's faster than your default 40 Kbps, you still may not want to make that client an SMS client, because of the amount of traffic that's going to be generated over the link.

One important thing that you probably want to implement is the SMS travel mode. So implement the travel mode settings, whether it's done locally on a client, whether you do so through the registry hack, which we really don't like, or preferably using the CliTravl utility. Implement that so that you can have control over what SMS does do or does not do, when you're moving clients around between sites for the mobile client scenario.

Make sure you set appropriate settings for your advertisements. Designate whether or not those assignments are mandatory over slow links or not, and that's done on a per advertisement basis. Again, if you want to change that threshold again, you have to contact PSS to have them help you modify your site control file.

If you are going to do remote control over the remote links to these mobile clients, make sure you're doing accelerated screen transfers, if you can. Accelerated screen transfers will compress the data going across the wires so it'll make them smaller and make it more efficient across the wire.

One note there is that Service Pack 3 has now been released, and Service Pack 3 now enables accelerated video transfers on Windows 2000 clients. That's a key feature of Service Pack 3.

Look at using or implementing the client upgrade tools; there are a couple of different ways you can do this. There's an actual executable called CliUpgrade.exe, and you can use that to disable the client from upgrading to service packs. Service Pack 3 has just been released. What you might want to do is, on all your clients that are not LAN-based clients, you might want to use the CliUpgrade utility or the registry scripts, called DisableClientUpgrade.reg. You might want to implement one of those two utilities, so that the clients don't automatically upgrade to Service Pack 3 when the CAP has been upgraded to Service Pack 3.

You can use the executable program, and say cliupgrade /disable, which will prevent the client from being upgraded, or run the registry script, if you're already running SP2. To run the registry script, you have to be an SP2 client. If you're on SP1, the registry scripts do not work at all. They're not designed for that; they're designed for SP2 clients. But the CliUpgrade utility will work on a SP1 client. You can run these utilities and disable the upgrade of the client components.

Now one thing to be aware of is that when you disable the client components from upgrading, this disables all CCIM functions, for the most part. So it disables verification, it disables downloading of new components, it disables removing components that shouldn't be enabled anymore; so basically, it disables everything, except for discovery. On an SP2 client, you still would have discovery, but on an SP1 client, you only have discovery, because it disables CCIM entirely. So this could be useful to help you stage the deployment of your service packs, now that Service Pack 3 is out. Our service packs can be a little bit large in size, because basically, most of the clients are updated, so you're essentially reinstalling all the client components. You might want to disable the upgrade automatically on remote clients, and then when they can connect to the office through a fast link, whether it's a LAN locally, or some faster speed link, then you send a package to re-enable client upgrades, either in an appropriate registry script, EnableClientUpgrade.reg, or run the client upgrade utility with the /enable switch, and then CCIM will kick back in and do the appropriate upgrade. So that can help you with processing your SMS upgrades.

Some additional things you might want to consider doing: setting up a separate SMS site just for your dial-in clients. So you create a separate site, and the only site boundary you would have in that site is the site boundary that you're going to have from your RAS pool — so, whatever your RAS server is going to dish out for addresses to your remote users. I know you cofigure that through DHCP or specifically through RAS. But if you have a separate scope for your dial-in clients, you can make that scope your site boundary for this separate site, and not include this same scope in your site boundaries for your locally connected site. That way you can have separate sites with separate settings for your clients. You can have different agents enabled. You can have different settings for those agents, such as longer intervals for inventory, and so on.

You might want to use PrefServe to configure preferred CAPs and distribution points. We talked about this in an earlier session, but by default, your client is going to randomly select a CAP from the registry when it needs to have a client access point. And that random selection may pick a CAP over a remote link. Then when you decide you want to run this advertised program, you can randomly select a distribution point from the NAL list for the package, and then from the registry of the client.

PrefServe is a utility in the resource kit that can allow you to manually configure a preferred client access point and a preferred distribution point, and that can help you maintain a lot of your SMS traffic locally to the subnet of the client, as opposed to possibly going over the remote links.

I know PrefServe isn't the easiest tool to configure. There are a few issues with PrefServe. So a lot of people use another resource kit utility called Setsmsvr.exe. Setsmsvr.exe is very, very similar to PrefServe, in that it modifies your registry to set what your preferred servers are. However, PrefServe is a command-line script utility to specify what your servers are, what the appropriate NAL path is, and so on. Setsmsvr.exe uses another utility called Localsvr.exe Localsvr.exe, so you run Localsvr.exe. That generates a list of all your CAPs and distribution points on your site, and then you modify the appropriate NAL paths to remove whatever CAPs and distribution points you don't want for your client. Then you can run Setsmsvr.exe with the .ini file that's generated by Localsvr.exe that has been modified for the appropriate CAP and distribution points. That gives you a little more flexibility, in that it automatically discovers the appropriate servers and it gives you the NAL paths and everything properly. One of the biggest problems with PrefServe is that people do not implement or submit the NAL paths properly.

Another thing you might want to do is make sure you perform all your installations of your SMS clients and upgrades to new service packs while the client's on the LAN, kind of like we just talked about with the client upgrade utility and the registry script to disable client upgrades. As much as possible, perform your installations and upgrades while you're on the local LAN, when you have 10 MB or 100 MB connectivity, as opposed to a 40 Kbps dial-up line.

When you're doing software distribution, as much as possible, you want to stage your software distribution into multiple phases. One phase might be to download the program to the client. One good utility to use for doing that is a Windows 2000 resource utility called Robocopy. Robocopy is a very good utility for downloading programs over a slower links, because it does implement checkpoint restarting. So if you do have a failure, it can recover from the point it failed, and manage that link a little bit better. So that's something you might want to use when you're looking at advertised programs.

And again, for advertised programs, don't force them to run on clients over slow links, if you can get away with it. If you can, stage them, so that you're downloading software to the local computer, then send another program that runs the executable from that local program, from the local computer itself. Or have all your programs staged on computers when they're at the local office in a separate partition, and then just send out advertisements that run those programs from a local staged hard drive area. A lot of companies will do that. They'll set up a separate partition just for staged software, and then send SMS advertisements out to those clients that kick in the advertised program from the local computer, not from the distribution point over the Net. That can help you out quite a bit as well. So those are some strategies that can help you out.

Just a quick summary for you (slide 15). Mobile clients have special needs. All through the presentation, I've talked about a lot of the issues with mobile clients. Again, mobile clients are the clients that are moving from one SMS site to another — maybe visiting, maybe it's a permanent change. So you probably want to implement travel mode as a means of controlling whether or not the client becomes deinstalled or installed in the new site or from the old site. Travel mode is a very good thing to use there, and look at using the SP2 support bundle utility, CliTravl. That will help you out a lot.

You have to determine whether or not you want to be able to visit a site without joining the site, or whether you want to join the site and maintain your membership in the old site, or remove the old site membership and just have the new site membership. But travel mode will help you out there.

As we've talked about, reinstallation of your SMS client software is very expensive, in terms of the time of the client, and the network load over whatever link you have, and the local client load, because you're reinstalling the client, you're re-enabling all the agents, you're redoing full inventory cycles, you're re-running all the advertised programs, you're losing your custom MIF files, and so on. It's a lot of expensive processing that has to take place on your client if you reinstall.

Your remote clients have some special needs as well. You may need to modify your Smsls.bat file and maybe the site control file to control, whether or not your client actually does become a client for SMS, depending on your network speed or whether programs are assigned and have to be run locally when you're doing software distribution. You may want to set up a separate SMS site so you can control the agents and control the settings for those agents individually for the remote clients, as opposed to just the mobile clients and your standard, everyday, other clients.

Now one other thing I don't have on the slide is that there's a white paper that just came out very, very recently. It's published on our Web site. The white paper is called "Managing SMS Mobile and Slow-Link Clients" (http://www.microsoft.com/smsmgmt/techdetails/mblslw.asp) You'll find this is fairly similar to this presentation. Not because I wrote the white paper, but because I helped review the white paper, and I had a little input into it, as to what's covered. So there is a white paper on managing SMS clients. There's also a white paper for deploying Service Pack 3 (http://www.microsoft.com/smsmgmt/deployment/servicepacks.asp), because Service Pack 3 has just come out. So you might want to go up to the http://www.microsoft.com/smsmgmt/ Web site and look for those two white papers, "Managing SMS Mobile Slow-Link Clients" and then "Deploying SMS Service Packs."

There are also a few third parties that have utilities that can help you with SMS 2.0. I've not given you a lot of real good solutions, other than a few strategies to work around how we operate, but there are some third parties that offer solutions. Callisto Software has a product called Orbiter, which integrates very well with SMS, and manages slow link clients very well. Mobile Automation has a product called Mobile Automation 2000, which also includes management of Palm Pilots and Windows^® CE devices, to some extent. Alteris has a software delivery solution that works with SMS. And NetDeploy has some software distribution strategies as well.

At that, I'll turn it over to Jim and let him get started with the Q&A session.

Jim Coll: Thanks so much for that presentation, Wally. A lot of good information in there. I want to mention that Wally's going to join us again next month, March 27, at 10:00 A.M. Pacific time, and that session will be on Microsoft Operations Manager.

Let's jump into the Q&A. We've had some questions submitted already. Our first one is: Does the mobile computer flag override the deinstall process?

Wally: If you enable the SMS travel mode, then we will prompt you for each instance to deinstall the client or not deinstall the client. I wouldn't say one overrides the other; however, if you do have travel mode enabled, it will ask you whether or not you want to deinstall the client or install into a new site. If you say yes, then that's just going to deinstall the client. If you don't have travel mode enabled, then when CCIM detects that you're not assigned to any sites, it's going to deinstall the client computer. So hopefully that's the answer that you're looking for. If not, send another question, and we'll clear it up with another one.

Jim: Okay. The next question is: In previous WebCasts, you mentioned that the SMS team was working on a tool to allow the SMS 2.0 client installation, via CD, to avoid having to download the entire client over dial-up. Do you have a status update on this tool?

Wally: Yes, we do have that tool we're working on. It is not ready for prime-time yet, so it's still being developed. They're finalizing a few things on it, and they are expecting to release that fairly soon (and I know you've heard fairly soon from us before, but not in reference to this tool). But they are working on the ability to install your clients from CD. They're looking at the Windows NT and Windows 2000 portions, which from what I understand are done. They're trying to get it to support Windows 9x clients as well, which has never been supported in the past. That's where they are with that. The last I heard is that they were looking at releasing that with the next SMS resource kit. Maybe on the Web, but definitely in the next SMS resource kit.

Jim: Most of my laptop users have docking stations with a second NIC card. They regularly connect both in their home office with a docking station and in remote offices with a second NIC card. What kind of problems am I going to see, and what can I do about it?

Wally: Just from your client having two NICs, that's not necessarily a problem, depending on what version of SMS you're using. In the first release of SMS 2.0, and I believe in Service Pack 1, we did have some issues with only looking at one NIC card. If that NIC card happened to have an address of all zeros, because you're not in the docking station, and the card's not there or something, then we would say, "You're not assigned to any site," and then you would be deinstalled.

If I remember correctly, Service Pack 2 has resolved the issue with not just looking at one NIC card, and looking at all of them, to see if you're assigned to any client sites themselves. So that would be the biggest thing, to make sure that you're at Service Pack 2. Everybody should be at least at Service Pack 2 and probably Service Pack 3 now; if you're not, you definitely want to be there. Other than that, as long as your client is still assigned to the site, regardless of whether it's through the docking station or through your remote NIC, then in a remote office, that's fine.

However, if your second card is giving an address that is not assigned to your local site, then you're going to have the same issue with the travel mode, where when you go to new offices, and you stay in a remote office with a second NIC card, if it's a new SMS site, then you're going to see, "Hey, I got a new address. I'm not assigned to the site," and I would deinstall, or install to a new site. If you're not at an SMS site at all, then you would have an issue; you'd just have to look at whether or not your current IP address and subnet is assigned to your existing site. So just make sure that the addresses you have for your local card and your remote card are assigned to the SMS site, and then make sure you at Service Pack 2 or later.

Jim: Okay. Which is more secure, allowing clients to change their remote control settings, or not allowing them to do this?

Wally: Well, that has nothing to do with security, that's just a matter of personal preference, whether or not you want people to be able to have that control. If I had to say one was more secure than the other, then I'd obviously say not allowing clients to make changes, because clients can make changes, and you never know what they're changing to. But it's not something that you're going to take my word for; you have to look at what is appropriate for your environment, what your users' needs are, what your needs are, as an administrator, and how you want to control things, and determine whether or not you want users to make their changes to their remote control settings.

In some environments, you absolutely want to have users to be able to say yes or no, I do want or I don't want permissions, or yes, I do not want to allow whole remote control, but limited remote control, like they can control my keyboard or mouse, but they can't run diagnostics. So that's just going to be a personal preference that you have, or something you're going to have to set according to what your corporate policies are. I can't tell you what you're going to do there. But forcing settings on clients is going to be more secure, because of the fact that they can't make their own changes, and maybe that lessens the security that you've implemented.

On the other hand, if you don't make them as secure, maybe the local user would make it more secure. So again, it's going to be give and take, and it's your scenario, and dependant on your own preferences.

Jim: What impact, if any, will SMS 2.0 Service Pack 3 have with regard to mobile SMS clients?

Wally: Service Pack 3 does not have any impact at all on how we manage mobile clients. So there's going to be no impact at all from that aspect. The impact on mobile clients, however, is that it's now a new service pack, and if you do upgrade your site to Service Pack 3, we're going to upgrade all your clients to Service Pack 3. If you have remote clients, or if you have clients that are currently mobile off their local site, then you may not want them to upgrade to Service Pack 3 while they're either connected remotely or dialing in. So again, you may want to control when that service pack gets applied.

But specifically, for managing mobile clients, Service Pack 3 doesn't do anything for you, as far as any improvements. Topaz that will make improvements to managing remote clients.

Jim: The next question is: What if your laptop users are not quite technically inclined to answer the remote travel message? What can we do to exclude the message and default to keep the original site to be assigned to?

Wally: If your users are not technically astute enough to be able to make the appropriate choice, yes or no, to assign or deassign your sites, then you do want to implement the travel mode and use the CliTravl utility and turn the prompt off. You can use CliTravl and turn the prompt off, and that will not present the dialog box to the user, and will make the appropriate choice for you.

Now the choice, obviously, if you don't have the prompt there, is going to be answering no to the questions in the selection of the yes or no process. Because if you don't even have travel mode enabled, it's going to be a yes. If you don't have travel mode enabled, we're going to automatically deassign you and automatically assign you. So enabling travel mode and not allowing the prompt is going to answer no to those questions. So that is what you would do. You would use the CliTravl utility, turn travel mode on, so clitravel /travel=on /prompt=no, and that should help control what you need.

Jim: Okay. The next question is: Is there a way to disable the message that appears every 30 days to the users who have travel mode enabled?

Wally: I think that's the same thing; you turn the prompt off. So if you turn the prompt off, then we're not going to present the message to you, and we're going to answer the no question. So the answer to the question will be no if you turn that prompt off. So that should be the same answer as the last question.

Jim: How do you keep the clients from deinstalling on clients that are away from their network for more than 30 days? I have clients that do not connect to my network for 90 to 180 days, and find that the client is deinstalled. I have turned CliTravl on. However, I still get clients that will deinstall the client code. Any suggestions?

Wally: Yes. First off, it's not 30 days; it's 60 days. So if the CCIM component on your client can't connect to a CAP in the site for 60 days, it's going to deinstall the client components. So if you have clients that are not connecting to the network at all for 90 to 180 days, then you can do a couple of different things.

One is use the Site4c.exe utility that we talked about earlier, from the resource kit. If you use Site4c.exe in the SMS 2.0 resource guide, or part of the BackOffice^® 4.5 Resource Kit, then you're forcing that client to the site, and it won't deinstall just because you haven't hit the CAP, because you're basically saying, "Hey, I'm assigned to that site."

The other thing you could probably do is, and I'd verify this, but I would think it would still work, is use the CliUpgrade utility, which is not part of the Service Pack 2 support bundle that comes on the SP2 CD. However, it is on the Web site. So if you go up to the http://microsoft.com/smsmgmt/ Web site, go to downloads, there's an updated support bundle utility there. If you download that one, that's got CliUpgrade.exe in it. You can do a cliupgrade /disable, and that would disable your CCIM components and the assignment and deassignment process from your computer. It's going to disable all your CCIM functionality, except for heartbeat DDRs, but that would be a way to keep your clients from be deinstalled.

Jim: Okay. The next question is about separate sites for remote clients, and it's asking: Do you need a separate server for a separate site? Can you put a secondary site on a primary site server?

Wally: No, a single computer can only run as a single site server. So you would have to have two separate boxes to be your two separate SMS sites. You can't put multiple SMS installations on the same box. You would have to have separate boxes.

Jim: Okay. The next one is travel mode and assigned clients: We've seen that after a client leaves the boundaries of a site, it shows in SMS that it's no longer assigned for the site, even though it is still installed to the site. This causes SMS travel sites to truncate the inventory for that PC, as well as ignore new collection memberships for that PC. Is this by design?

Wally: Well, what you're probably seeing is your current site is going to have no idea that you're not currently assigned to that site, unless you're receiving a DDR from someplace. Either you're seeing that a DDR is being generated at the new site, either through a logon script or whatever process, and that DDR is being forwarded back up to this current site.

So probably one of two scenarios is that you're sharing domains between multiple SMS sites, so that when you move from Site A to Site B, you're no longer assigned to Site A. You're getting a DDR created at site B. However, by sharing domains, you're forwarding that DDR to all the site servers, unless you're running SP2, and you have that intelligence built in to the discovery agent. Then your local site has received the DDR that's showing what the client's IP subnets are, and that's going to automatically set that to say you're not assigned to that site anymore. Because looking at the IP subnets, you're not assigned anymore. So that is the case, and that is by design.

The other thing that could be happening is that you're in a parent-child relationship, so your parent site is where you originally were installed and assigned, and now you're connected to a child site, and you're getting installed at that site. You're creating a DDR at that site while the child automatically forwards that DDR to the parent site. So the parent site is seeing that you're assigned to that bottom site, your IP subnet is no longer a part of my site, which is correct. So if you're not assigned to the site, then you're not going to be in an appropriate membership class, you're not going to have appropriate membership rules, or software distribution advertisements for your original site, because you're not assigned to the site. We work off the assigned sites that we're looking at.

So that is by design. I've never heard of a child site truncating inventory. I've never heard of that at all. We always forward all inventory up from a child site to the parent site. I'm not aware of any kind of inventory truncation, just because you're not assigned to a site anymore. I get inventory on my site from a child site, even though that client is not assigned to the parent site. So I don't know what you mean there, but the rest of it is by design, yes.

Jim: Can the SMS client be installed on a PC when it is offline? For example, distributing the client config files via CD, with the appropriate configuration defined?

Wally: Today, no. We don't have a utility. But we will have a solution for you in the future, where you will be able to install some SMS components via local CD. But as of today, as of SMS 2.0 Service Pack 3, we don't have a supported solution for you to install your full client offline. But we're working on it.

Jim: Okay. Well, before we go on to the rest of the questions, I want to take a moment to ask for some feedback. If you have any suggestions for topics for future WebCasts, any comments about this WebCast, or any comments about WebCasts you've listened to in the past, please send them to us using the e-mail alias feedback@microsoft.com, and please include "Support WebCast" in the subject line.

Our next question is touching on futures, and I'm not sure how much we can answer on this, Wally. Will SMS support mobile devices, such as Palms and mobile phones?

Wally: Today, no. As of SMS 2.0, as a piece of software, no. We have no ability ourselves to manage any kind of mobile devices, like Palm devices or Windows CE devices, and so on. I mentioned as Mobile Automation. Mobile Automation had stated they have some ability of managing Palm devices and Windows CE devices, but we don't today. That is something we want to get to in the future. I can't tell you whether it's going to be in Topaz or not. We haven't announced that, and I don't know if they've determined exactly whether or not they're going to be able to do that in Topaz. So I can't tell you that.

But as of today, as of SMS 2.0, no, we don't have any ability to do that ourselves.

Jim: When will checkpoint restart capabilities be in SMS for application delivery?

Wally: Checkpoint restart will be in Topaz. You're starting to hear things about Topaz. There was a seminar online that was done by one of the product marketing managers last month. If you go into the users conference in a week and a half, you'll hear more about Topaz. We're starting to disseminate some information about Topaz. In fact, one of our future WebCasts will be on Topaz, when we get more information that we can share with you.

But one of the big things we're doing in Topaz is making SMS's management of mobile and remote clients better. We know we don't have a good story for you today. We can give you some workarounds, but we don't have a great story. Topaz is going to have the ability to give you much better management of your mobile and remote clients. One of the key things they're doing is checkpoint restarts for software distributions. So something like the Robocopy, where if your link fails, it'll pick up in the middle, wherever it broke off, and start over from that point, instead of the beginning. So that will be in Topaz.

Jim: The next question is: PrefServ versus the SMS server tools —briefly go over the correct use of these tools to specify a CAP and/or distribution point.

Wally: OK. There are basically two utilities in the SMS 2.0 Resource Guide or the BackOffice 4.5 Resource Kit. The first one, and the one most people talk about, is PrefServ. PrefServ is a utility that you can use. It's command line driven. So, from a command line, you'd run PrefServ, and then give it the appropriate syntax to specify which CAP and/or distribution point you want to use as your preferred CAP and distribution point for a specific client. So, it's run on a client-by-client basis to specify preferred CAPs and distribution points.

You can specify multiple CAPs, multiple distribution points, and we'll go through the list from top to bottom, in your preference list. So, you have that ability of doing that. But, it's command line driven. You have to be able to supply the correct syntax, and that's where a lot of people have issues with PrefServ.

Setsmsvr.exe is another utility in the resource kit. It allows you to basically do the same thing as PrefServ, but the advantage that Setsmsvr.exe uses a third utility called LocalServ to enumerate the appropriate CAPs and distribution points are for your site. It creates an .ini file of those CAPs and distribution points, which then you can modify; you can take that .ini file and basically give it to Setsmsvr.exe as part of its command-line parameter, and it would automatically incorporate all those CAPs and distribution points from your .ini file into the registry. So, it's a little bit easier to update the registry using Setsmsvr.exe with Localsvr.exe than it is with PrefServ, because you don't have to do as much command-line scripting.

Jim: What benefit do the international client packs provide, and what is the latest available client pack?

Wally: What international client packs provide to you is just localized versions of the SMS client software. So, you get an SMS client software in one of the available ICPs, and that gives you the ability to have your SMS messages and download boxes localized with specific client, whatever version of language you have on your client computer itself. So, that's what international client packs are. They don't give you any extra functionality than what our standard SMS client package does. They are just localized versions of the software.

As far as what are the latest available one, I know for Service Pack 3, we've shipped English, German, and Japanese (I believe). I honestly can't tell you what the latest ICP number is, if it's 1, 4, or 5. I know we've cut down the number of ICPs as of Service Pack 2, and I just haven't kept up on it. I know we've released some of the languages, but I honestly can't tell you if just ICP 1 that's been released, or of it's something else.

Jim: The next question is: For us, more and more clients will be working at home under DSL, with arbitrary/temporary IPAs. Will SMS still work for us in this environment of increasingly isolated, rather than subnetted clients?

Wally: SMS, primarily, is looking for IP subnets. Currently, IP subnets are our means of assignment to a site. If you have IP addresses that may change frequently because of your Internet service providers, or whatever, then you may not want to go with the default SMS scenarios. If you do want to have your users working at home, and you still want them to be maintaining an SMS site, regardless of what their subnetting may work out to be because of whatever connectivity mechanism you have, then you may want to use the forced site utility that we talked about before— Site4c.exe. Use that, and you can force that client to a site, regardless of whatever IP subnet it may acquire or be changed to in the future. So, that may be something you want to look at doing.

Jim: Where can I find more information regarding the Callisto Orbiter?

Wally: From their Web site, http://www.callisto.com/, and then they have a special SMS data sheet, at http://www.callisto.com/sms_datasheet.shtml, about their Orbiter, their SMS connector product. That's what they call it. So you can go there and get more information on that.

I've heard some very good things about that product. I've never used it, so I can only tell you what I've heard.

Jim: Are there compelling reasons to use SMS 2.0 Service Pack 3? I've heard it's mostly hot fixes and patches.

Wally: From now on, our service packs for SMS are only going to be true service packs, like in the sense of Windows NT or other products. It just happens that we had a couple of service packs come out in the SMS 2.0 time frame, Service Pack 1 and Service Pack 2, that had enough major changes to them. They weren't just what we call "QFE roll-ups."

SMS 2.0 Service Pack 2 made the product stable enough that it's very viable for you to install and use and work and be effective with, that now all we're doing for service packs is just providing what they call QFE roll-ups, or as you state here, "hot fixes and patches."

So, primarily, that's all Service Pack 3 is, and that's all our future service packs are going to be. However, other than maybe a specific bug fix that is in Service Pack 3, there are a couple of other reasons you might want it, outside of QFEs. One is that Service Pack 3 does provide video acceleration for remote control on Windows 2000 clients. So, if you're in a Windows 2000 environment and you use our remote control technology, then you might want to look at getting Service Pack 3, because it does give you that remote control video acceleration for Windows 2000 clients. So, it greatly improves the speed of Windows 2000 remote control.

And the second thing is if you're looking to move to Whistler beta phases (I know we're calling it Windows XP right now, but the beta code you have right now is still going to Whistler), and you need to have Whistler client support, then Service Pack 3 does provide for you some Whistler client support that SMS 2.0 Service Pack 2 does not provide. So, you do need Service Pack 3 if you want to have any Whistler support.

Jim: The next question is regarding remote control settings: When assigned to several sites, the client uses the most secure settings from either site, as you said. If one site says to allow clients to change settings, and the other says not to, which gets chosen? The primary site or the most secure site?

Wally: For remote control, it's always going to be the most secure setting for the client. What's going to be most secure for the client is going to be to allow the end user to make his own configuration changes. So, if one site says "Don't allow changes," and another site does allow changes, then that should evaluate out to allowing the client to make changes for the Remote Control Agent locally, because that would be most secure for him. One site may not require permission, whereas the client may want to have permission required, so it's going to be more secure. So, it's not going to be the principal or primary site, it's going to be whatever is most secure for the client, which would be to allow the client to make changes.

Jim: What type of features is Topaz going to have for the client that resides at a low bandwidth location?

Wally: Well, the biggest thing that Topaz is going to do for you for remote client scenarios is the one that I've already mentioned — the checkpoint restarting. That's going to be the key feature, in that when you're downloading, whether it is SMS components, or whether it's downloading software distribution, we're going to have the ability of doing checkpoint restart. So, if my link breaks, I can pick up the links the next time. The next time the link comes up, I can pick up where I dropped off last time.

Another thing it's going to allow you to do is to support multiple sessions in downloading software, whether it's client components or software distribution. So, let's say I dial into my network, and I'm only connected for one minute to my SMS site. Well, that minute may not be enough time to download new SMS client components or a big software distribution package. So it lets you download what you can during that one-minute session, mark it, and the next time you connect, you download the next minute's worth, or however long you're connected. It's been called "drizzle technology." You're drizzling the bytes down to the desktop. When the bytes are all assembled on the desktop, then you execute the program. So, those would be the two biggest things that we're doing in the Topaz release, as far as lower bandwidth clients.

Jim: Can I distribute software to a DSL or cable modem user who never comes into the office?

Wally: Provided that user has access to the SMS site components, your CAP and your distribution points, and he's got an IP subnet that lets him be assigned to the site, then sure. He can become an SMS client, and you can send down your software.

Or, if you don't have appropriate addressing technology, again, you can use the Site4c.exe utility and then use Smsman to manually install the client. As long as it's a client in the SMS site, it's assigned to the site, and it has connectivity to your site components (the CAP and the distribution point) then, yes, you can distribute software to him.

Jim: Is there a beta program for the remote offline setup program you referred to earlier, that is, the application to be included in the next SMS resource kit?

Wally: To my knowledge, no. I've not heard of any beta program for the remote CD setup program.

If it is just going in the resource kit, we normally don't have much for betas for the resource kits. So, I'm not aware of any beta for it.

Jim: We often have consultants who join our domain. When they run Smsls.bat, the client will load on their machine and they will become inventoried assets. Do you have any suggestions on how we can avoid inventorying visiting machines? We wanted to avoid checking a flag file for SMS client load.

Wally: If the consultants are coming in, they're joining your domain and getting an address in your domain, then they're obviously going to get assigned. And if you have inventory enabled and they become an SMS client, they're going to be inventoried and you're going to have that data in your site.

You could remove the client from the site manually. So, when you get the inventory, you can delete them from the site. Otherwise, you'd have to have some sort of utility to say "This is a visiting client. I don't want him joining my SMS site." So, whether that's a flag file you look at in your Smsls.bat, or a batch file prior to calling Smsls.bat, or some other registry script you're looking at, or something else — there is a resource kit utility we talked about once before, called Rndlogin.exe. You can put some parameters on there, specifying wildcards you might want for computers to join in. But if it's just purely on a random basis, as far as once the consultants are jumping on your network, they're joining your domain or not; if you allow them to join the domain, then they're going to become a member of your site, and they're going to get all your site settings. So, there has to be some sort of a flag file to look at to tell SMS not to install SMS client software on that computer for the appropriate SMS site.

Now, if they're already installed, then you can use travel mode and have them not join your site, have it be a "no" operation to deinstall from the old site, and "no" to install to the new site. That's all I can think of, off the top of my head.

Jim: Are there any techniques to install the SMS client on a Windows NT workstation that is a member of a workgroup and not a domain? Smsman cannot find a CAP, even if drives are mapped to the CAP and logon point.

Wally: Sure. We support workgroups as well as domains. You don't have to be a domain member for a computer to become an SMS client. The thing is your logged-on user has to have an account on the domain. So, if your logged-on user is not a domain member, then he's not going to be in the domain's users group, which is all we have CAP permission set up on.

You can certainly go to a computer that's in a workgroup and run Smsman — Smsman goes to logon point; it doesn't go to a CAP. And it doesn't matter whether or not you have a mapped drive to that logon point or CAP anyway. That's immaterial. When we talk about looking for existing connections, we mean existing connections for the SMS client process itself, not something that you've mapped.

Smsman, when you run it manually, is going to go to a logon point, so you have to be able to find a logon point. You can put that in the command-line switch. Or, when you run Smsman, instead of taking the default option of Automatically detect logon server, you can go to the next option, which is Manually specify server. You can manually specify the server. As long as you have rights to that server, then you should be able to run Smsman and get your clients installed.

Jim: Is there a spot on the SMS client's registry that identifies your parent site by UNC path?

Wally: I think you mean "primary," not "parent" site, or your home site.

There is a registry location where you can go to see what your principal site is; you can find out what your principal site is, if you're assigned to multiple site. And that's just by going to HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\Client, and then go to \Sites. At the Sites key, you have two different subkeys called Shared and System. There's a value called Site list as the site key itself, and that lists all the sites that you're a member of. You can look at that to find out what your principal site is.

If you just want to find a UNC path for your site, it's not going tell you whether it's primary, principal, or not. You can go to NAL in the registry (HKEY_LOCAL_MACHINE\Software\Microsoft\NAL) and then go to \Client. Go to AbExprtDb, and then go to the CAP list for the site, and that will give you the appropriate NAL path for your CAPs on your current site. It shows you MSWNET and then it says SMS site and tells you what the site code is. Then, it gives you the path, which is \\servername\, and then your CAP share. So, that may be what you're looking for. I'm not exactly sure what you're asking. That would be my guess.

Jim: Wally, you mentioned a couple of white papers at the end of your presentation. This question is asking: Are those white papers available right now?

Wally: Yes, both the white papers I mentioned are available right now. The one is called "Managing SMS Mobile and Slow-Link Clients" (http://www.microsoft.com/smsmgmt/techdetails/mblslw.asp).

Normally, off of http://www.microsoft.com/smsmgmt/, they will announce new white papers at the top of the page. If you scroll through that first page, they often announce new white papers.

So, the "Managing Mobile and Slow Link Clients" paper has been published, as well as the other one I mentioned, "Deploying SMS Service Packs". (http://www.microsoft.com/smsmgmt/deployment/servicepacks.asp) And the "Deploying SMS Service Packs" white paper was updated for Service Pack 3. They did put some Service Pack 3 references in there.

Jim: This question is about SMS support software. Will it support software metering for clients over slow link, and how does SP3 improve this function?

Wally: SMS does support software metering. It can go over slow link, but the problem with that is, you're obviously going to the software metering server over that link, and every single time you launch an application, it's going to talk to that software metering server and ask, "Is it okay for me to run this program or not?" unless you exclude the program from the list. Then, it will download. It also goes up to the software metering server every so often to download lists of programs it's supposed to exclude. So, you can do that over slow links; it's not recommended by any means. We don't recommend doing any SMS functions over a slow link. You're disconnected from your site systems.

Obviously, if you have a dial-in person at home, or on the road, or something like that, you don't have a choice.

SP3, may have some bug fixes in there for software metering, but there are no real upgrades to software metering as of SP3. In fact, I'm looking at the list of fixes for SP3, and I see at least one if not more for software metering. So, there are some things that are fixed or some hot fixes or QFEs for software metering in Service Pack 3, but it has not been rewritten, it has not been enhanced by any means at all in Service Pack 3.

Jim: And we have a question about Service Pack 3: Does SP3 have a self-contained installer like Windows NT service packs, or does it require slipstreaming like SMS 2.0 SP1 and SP2?

Wally: Service Pack 3 is not going to be slipstreamed. Service Pack 3 is an update program, basically an Update.exe, like you would have with your Windows NT service packs. It does require that your site is already running Service Pack 2. You cannot apply Service Pack 3 to an SMS site that's running RTM code or Service Pack 1. It can only be applied to Service Pack 2 sites.

Now, if you have a Service Pack 1 client, the client can upgrade to Service Pack 3 directly; it doesn't have to go to Service Pack 2. But your site server, your CAP, and your logon points, and all your other site systems, have to upgraded to Service Pack 3, which requires Service Pack 2 to be applied first. It's not a slipstream; you just apply the service pack as an upgrade program. It updates your binaries on the site server, pushes it out to your logon points, your CAPs and so on, and then the next time your client connects to the CAP, it says "Oh, Service Pack 3," and it downloads, unless you disable that function.

Jim: I imaged a laptop that will be delivered to another site or subnet. Is there a utility like AddSystem.exe that I can run from the site server after the laptop logs on to its home site to install the SMS client, and then set travel mode at that time?

Wally: Well, to install the SMS client, you run Smsman or Smsls.bat. Some of the other questions were about the ability to install the client without having access to the SMS site. That's coming in the future; but for today, you have to have access to a logon point to start with, for all computers, except for Windows NT and Windows 2000, and then it goes to a client access point to do the install. You can do the install the way it is.

As far as setting travel mode, you can use the CliTravl utility in the SMS 2.0 Service Pack 2 support bundle to advertise that out to your clients and get that sent out.

Jim: With that, we have answered all the questions that were submitted today. That will wrap up our session. Again, Wally's going to join us again next month, March 27, at 10:00 A.M. Pacific time, and that session will be on Microsoft Operations Manager.

I want to thank all of you for joining us and all your excellent questions. I hope this information was useful to you. Thank you, and good-bye.