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

Heidi: Hello, welcome to the Microsoft Support WebCast program. We'd like to thank all of you for joining us today. Our topic will be "Systems Management Server 2.0 Client Infrastructure." Our presenter will be Wally Mead.

I'm Heidi Moeller, and I'll be your host for today's session. We'll start this session with Wally's presentation, and follow that up with a question and answer period when the presentation is finished. I expect today's presentation to last about an hour. We only answer questions submitted during the live broadcast.

The Q&A portion of the Support WebCast is intended to encourage further discussion of the Support WebCast topic. However, one-on-one product support issues are outside the scope of what we're able to address during the Support WebCast. If you need technical assistance, please submit an incident on the Web, or call Microsoft Product Support Services and speak to a support professional.

I'd like to take just a brief moment now to introduce Wally. Wally Mead has been with Microsoft for the past eight and one-half years. He started in the training organization, where he delivered training on LAN Manager. He began working with SMS back in 1994, and has been involved in the product development and delivery of all SMS training courses for Microsoft. He now works for the SMS Product group, in the Early Adopters Program, and provides training for the Early Adopters Program members.

Thanks so much for joining us, Wally. Let's go ahead and get started.

Wally: Thank you, Heidi, and I'd like to extend my welcome, as well as Heidi's. Hopefully you'll find something interesting and worthwhile for yourself in this presentation. Today's agenda is going to cover how SMS interacts with client computers. What we're going to look at are the discovery, assignment, and client installation processes. We'll talk about how we go through the process of discovering clients, assigning them to an SMS site, and installing the SMS client components on that client computer. We'll talk specifically about the specific SMS discovery methods, those methods that can be used to discover client computers in your environment. We'll also briefly talk about the other methods that don't discover client computers. Then we'll talk about how resources are assigned to a site, that is, After you've discovered a resource, how do you get that resource assigned to your SMS site?

Then we'll go through the installation process. How does SMS accomplish the process of installing the SMS client components on an assigned resource? We'll go through a few examples of that, and discuss that in detail. Then we'll talk about some of the common issues people have with getting SMS installed on their client computers.

After we've talked about troubleshooting client installation, we'll go ahead and talk about the SMS client components and their functions. We'll talk about the core components that you have installed, the optional components, and basically what each of those functions perform for you, as far as an SMS client is concerned.

Lastly, we'll talk about how you remove SMS from a client computer if you no longer need that client installed as an SMS client.

Alright. Slide 3 is a guide of the discovery, assignment, and client installation processes. This is a slide that covers numerous, different topics, but we'll go ahead and run through the process, outlining the procedure for you in a bulleted list. We'll give you more detail later on.

Now, this slide is assuming that we're going to use Logon Discovery and Logon Client Installation, so those are the methods we'll introduce in this slide. First off, you've told your SMS site to go ahead and perform Logon Discovery and Logon Client Installation for a domain. SMS has gone through the process of configuring the domain controllers as SMS logon points.

Now a user has logged on to the network, he hits the domain controller, his logon script executes. That logon script can either be the user-specific logon script that the administrator has implemented, which calls the SMS logon script, or, if the user did not have a logon script, the logon script may be the SMS logon script now. So either your own logon script runs, and eventually it has a call statement to the Smsls.bat file, or the logon script itself is Smsls.bat. So that logon script executes.

SMS is going to download some files down to the client computer, and execute those files. After the execution of those files, discovery takes place. So on the right-hand side of your slide, you see a client computer with a Discover Agent icon on it. Discovery takes place at that client computer. The client then writes that discovery data back to the logon point in the form of a discovery data record, a DDR.

The client then verifies whether or not installation is enabled for these sites that the client has connected to (that logon point). If so, then the client will go ahead and perform the assignment process. The assignment process is where the client checks the assignment rules on the logon point with the discovered subnet that the client has generated. If the client is not assigned, in other words, if the client subnet is not listed in the assignment list on the logon point, the process aborts. That will be noted in your log files that we'll talk about later on.

If the client is assigned to the site, then the client will go ahead and download a list of client access points from the logon point, it will cache that list in the registry of the client, it'll randomly select one of those CAPs from the list, and then it'll go ahead and begin the client installation process. So the SMS software will be downloaded from the CAP down to the client computer. It will get installed along with any of the optional components that we'll talk about later on.

That's the basic process: you kick off a discovery process, you verify your assignment process if you're assigned to the site, then you go ahead and begin the client installation process. So now we'll talk about some specifics of those processes for you.

The next thing we want to talk about, on slide 4, is comparing and contrasting discovery versus assignment and client installation processes. These are three unique processes that accomplish different functions. Discovery is the process to find potential resources. That's all discovery does. It goes out across your network, or a single computer, or domain controller, or whatever discovery method you're running, and it looks for resources that might have some place in SMS.

Assignment is the process of validating that that resource should become a member of the current SMS site, verifying that the client is sitting on an IP subnet that is assigned to the SMS site. If the client is assigned to the site, then the client installation process will begin installing the client infrastructure on those assigned resources. It's very important to note that discovery is not required for assignment or client installation. So you can have an entire SMS environment without performing any Logon Discovery or other types of discovery methods.

Discovery, per se, is not a requirement to become a member of an SMS site. Technically, discovery is run locally at a client computer. However, if Logon Discovery, for example, is not enabled, that discovery data will not be reported back to the logon point, as our previous slide had indicated. You'd need to use a different discovery method then, to ensure that your client has been discovered and is in the site database, but it doesn't have to be Logon Discovery. We'll talk about the different discovery methods coming up.

Client discovery and client installation, are, again, unique functions. They're separate methods that you can enable or disable as appropriate. If you just want to go around your network and discover resources, you can have Logon Discovery enabled, but you don't need to have Logon Client Installation enabled. If you just want to install, but not create discovery records, you can go ahead and have Logon Client Installation enabled, but not have Logon Discovery enabled. So that's an option that the administrators of your site have regarding how much traffic they want to generate, when they want their discovery data to be created, and whether or not they want clients to be installed.

There is another installation method we'll talk about later on, called the Microsoftâ Windows NTâ Remote Client Installation method. This is an installation method that is not initiated at the client, but rather is initiated at the site server. So we'll talk about that when we get into installation methods a little bit later on in the presentation.

Now, let's look at the different SMS discovery methods. As you look at slide 5, you'll notice I have two different categories there. The top category of discovery methods is methods that can be used to discover SMS clients. The bottom few discovery methods are ones that will not discover client computers, but discover other resources. In this presentation, we'll look at those first five discovery methods in a little more detail. We'll look at Windows Networking Logon Discovery, NetWare Logon Discovery, the Manual Discovery process, Network Discovery, and Heartbeat Discovery.

I'm not going to talk about the last few discovery methods at all. I'll just mention the names here. Windows NT Server Discovery, that's basically just used to find Windows NT Servers that are performing some SMS role, like site servers, client access points, distribution points, or logon points, and make sure they have discovery data in your site database. The NetWare Bindery Server Discovery method works exactly like the Windows NT Server Discovery method, it is used to find NetWare Bindery servers that have some role in the SMS environment, such as CAP, logon point, or distribution point. The last two, the Windows NT User Discovery and Windows NT User Group Discovery methods, are there to find appropriate user counts or user group accounts from a domain controller and add them to your site, to be used for software distribution.

Let's go ahead and start looking at the first five discovery methods, those that can find client computers. The first one is the Windows Networking Logon Discovery method, on slide 6. This is the one that we introduced on that first slide. In this environment, you tell SMS to configure your logon points by adding a domain for Logon Discovery. SMS goes about the process of configuring those domain controllers as SMS logon points. You then determine whether or not you want to use logon scripts as the means for kicking off Logon Discovery. For this example, let's assume you are using logon scripts.

In this process, the user logs on and hits the domain controller that's configured as an SMS logon point. It's told to run the Smsls.bat file. Some files have downloaded from the logon point down to the client computer. The client computer then performs the discovery process locally. If Logon Discovery is enabled, as this slide is indicating, then the discovery date is reported back to the logon point as the discovery date of record or DDR.

At the point, the logon point itself will go ahead and take that DDR and forward it to a site server. There are cases where it may forward it to more than one site server. In previous releases of SMS 2.0, the logon point would just copy the DDR to every single site server that was sharing that domain as a logon point. With Service Pack 2 and later, we have intelligence built into the logon point, so it selectively copies that DDR to the appropriate site server so that you're not replicating throughout your entire WAN infrastructure. That will help reduce network traffic requirements on the environment, and leave traffic available for user interaction. So that's Network Logon Discovery.

The next slide talks about NetWare Logon Discovery. We have two different NetWare Logon Discovery methods: NetWare Bindery Logon Discovery and NetWare NDS Logon Discovery. They both function very similarly to the Windows Networking Logon Discovery method, in that the administrator tells the site server to go ahead and configure an OU for NDS or a specific bindery server as a logon point. SMS will configure the appropriate resource as a logon point. It will modify the container logon script or the system logon script. The user logs on, runs the logon script, downloads the discovery files necessary, creates a DDR, and writes it back to the logon point. Very similar to what we just talked about.

The main difference here is that with the NetWare Logon Discovery methods, there are no SMS services running on a NetWare Logon Server, or an NDS environment. Instead, the DDR will remain on the logon point, and the SMS site server will occasionally poll that logon point, looking for any DDRs. We have no code running on the NetWare environment to automatically push that DDR up to the site server, as we do in the Windows NT case. So the site server just polls the NetWare component, the logon point, looking for DDRs, and we bring them up to the site.

What this means to you is that there may be a delay from the time the client technically has been discovered, until that client becomes a resource that appears in any of your collections, such as the All Systems collection. If I remember correctly, the default polling interval is daily, every 24 hours. That's something that the administrator can schedule and configure how frequently he wants the site server to poll the logon points looking for DDRs. Other than that, the NetWare Logon Discovery methods function very similarly to the Windows Networking Logon Discovery method.

The next method we'll look at is Manual Discovery, on slide 8. Manual Discovery isn't a method, per se, as the previous three were. You actually go to the SMS Administrator console and you enable Windows Networking Logon Discovery, or you enable NetWare Bindery Logon Discovery. You don't go to the SMS Administrator console and enable Manual Discovery. Instead, what Manual Discovery does, is it feeds off of Windows Networking Logon Discovery, or one of the NetWare Logon Discovery methods. In other words, it's basically Logon Discovery; however, you generally don't use the logon scripts. You enable Windows Networking Logon Discovery, get all your domain controllers enabled as logon points. Just don't tell SMS to modify any logon scripts.

Now what you do to perform discovery, is the client computer itself either connects up to a logon point and runs the Manual Discovery program from the logon point, or the administrator e-mails the utility to all the appropriate people that we wants to run the utility, or he posts it on a Web page. It's also included in all your Windows 2000 CDs. So on your Windows 2000 source CDs, you already have the Smsman program, which is the Manual Discovery program.

Basically, what the user does, is he finds that program either off the logon point directly, through an e-mail message, on a Web page, or on a Windows 2000 CD, and he just launches off the appropriate utility. There are three different utilities that you can run: Smsman, which is for 32-bit clients (Windows 95 and higher clients); Smsman16, which is for 16-bit Windows clients (Windows 3.1 and Windows for Workgroups type clients); and then Manboot. Manboot is a utility that you can use to create a discovery record for an MS-DOS^®-only client. Now SMS 2.0 does not support MS-DOS-only clients at all. We require some sort of Windows-based operating system on top of that MS-DOS. But what Manboot will do for you, is it will create a DDR that you can then have processed into your site database. SMS will do nothing with that other than display your database for you. You can run a query that says "show me all the computers that have MS-DOS," and then you can manually go out and upgrade all those computers to a Windows 3.1 or later operating system. Basically, you're just running a utility, and it's feeding off the information that's provided by Windows Networking Logon Discovery or the NetWare Discovery methods.

The next discovery method is Network Discovery, on slide 9. Network Discovery was actually the topic of last month's session, so I won't go into a lot of detail on it. If you need more detail, you can go back to the archives and find last month's session. Basically, Network Discovery is a process that runs from the site server, not the individual client computer. The site server goes out across your network, looking for resources that are configured for TCP/IP addresses. If the site server can discover enough information about that resource, that resource will have a DDR created for it by the site server, which will then be added to the site server's database, to the SMS site database.

The downside to the Network Discovery method is that Network Discovery does not do anything on the client computer itself. Because the client is not generating this discovery data (some remote process is discovering the data), it's not as comprehensive as some of the other discovery methods. For example, Network Discovery does not know whether or not the SMS client software is installed on a computer. So Network Discovery will always report nothing back for SMS client, or, in actuality, the SMS client may fully be installed in that resource. So you need to have some other discovery method discovering your data for you, some more specific data.

The Network Discovery method also cannot report back your SMS unique identifier, or the GUID for your client, because, again, it does not run on the client, it just remotely asks some things of the client, using some 32-bit API calls, or SNMP discovery. It's very good at finding a lot of resources on your network, a lot of resources that won't be SMS clients, such as routers, wiring concentrators, printers, and so on. It can discover Windows-based clients as well, but it just will not be as complete of a discovery method as some of the other discovery methods.

What you really want to do, if you're using Network Discovery to find your client computers, is you want to make sure you're using the next discovery method, which is Heartbeat Discovery, on slide 10. Heartbeat Discovery is very useful to update your client data, the specific SMS client data, as well as some of the optional data that Heartbeat Discovery collects.

For example, let's say you ran Network Discovery and Network Discovery found a client computer. But Network Discovery can't tell you whether or not the SMS client software is installed on it, so it doesn't report back that it is an SMS client. What you would then do is have Heartbeat Discovery running. Heartbeat Discovery would go ahead and create a discovery record, and it would state that, yes, this client is an SMS client, or this resource is an SMS client. Here is the SMS unique identifier or the GUID for this SMS client computer.

This process, Heartbeat Discovery, only runs on existing SMS clients. It's very useful for refreshing the discovery data in the SMS site database. It's good for updating data that Network Discovery does not generate. It's useful when you're using Logon Discovery, but your users don't log on very frequently (they might log on once a month as opposed to daily), so you're not getting refreshed data. It's useful when you don't want to use logon scripts; you want Logon Discovery there, but you're not using logon scripts at all, so you're not getting that daily logon update of data.

What happens here is every single time CCIM, the Client Component Installation Manager that we'll talk about later on (it's one of the core client components), whenever it performs its maintenance cycle (and I'll talk about when that is), it does discovery. Every time CCIM runs a maintenance cycle, it runs its discovery process. It then updates the local discovery file on the client computer. If the Heartbeat Discovery interval indicates it's time to perform Heartbeat Discovery, then CCIM will create a DDR and pass that back to your client access point. Your client access point will then forward that up to your site server, and your site server will go ahead and process it in the site database, updating any data for the client computer itself.

Heartbeat Discovery is enabled by default, and the default interval for Heartbeat Discovery is every seven days. That's a pretty good interval for most clients. If you do choose to modify the interval for Heartbeat Discovery, you just need to make sure that you have it occur more frequently than does the Delete Age Discovery Data maintenance task.

There's an automated database maintenance task called Delete Aged Discovery Data. What that task will do, is go through your site database, look for all discovery data that has not been updated in 90 days, and remove it from the database. It's assuming that if it hasn't been updated in 90 days, it's a resource that is no longer on the network, either the computer died, it was taken out of service, got donated to some organization, whatever; it's not part of your infrastructure anymore, so it's going to remove that data. When it removes the discovery data, it also removes any inventory data. So if you don't want your discovery data and inventory data removed, you need to ensure that Heartbeat Discovery is performed more frequently than the Delete Aged Discovery Data task, the database maintenance task.

All right, so those are the different discovery methods that we're going to discuss. Next, on slide 11, we'll talk about how resources are assigned to sites. I mentioned earlier that when a client begins a discovery and installation process, it's going to go ahead and perform a process called assignment. The assignment process is where the client is verifying that it is or is not assigned to the SMS site, so that it knows whether or not to perform installation or possibly deinstallation.

In SMS 2.0, the only method we use to assign resources to sites is by physical network boundaries. In other words, we look at IP subnets or IPX networks. We don't go by computer names, we don't go by domain names, we don't go by any other method. Those other things may be ways of discovering clients, but, again, the assignment process is purely by physical network boundaries: IP subnets or IPX networks.

By default, when you install your SMS site, the only subnet that's added to your site is your site server's IP subnet. It gets that from its registry. If you want to add more, you just go to your Site Properties dialog box, go to the Boundaries tab, and you add new IP subnets or IPX networks. Notice that when you add new IP subnets, you don't specify a subnet mask. The site server doesn't care what the subnet mask is. The client cares what the subnet mask is. So when the client performs its internal discovery process, it's going to determine what its subnet is. It does that by looking at its IP address, its assigned subnet mask, and it comes up with an IP subnet. It then compares that IP subnet to the assignment list that resides on your logon point or your client access point, depending on where this assignment process is occurring. If the client is assigned to the site, then it goes ahead and proceeds with the installation process. If the client is not assigned during the logon installation and discovery process, it bails out of that process.

Let's say your client is already installed as an SMS client. Then what's going to happen is everytime CCIM performs its maintenance cycle, it's going to again validate that assignment process. But now, CCIM only goes to CAPs, so it's going to go to the client access point and look at the discovery data that it generated from the IP subnet, compare that with the assignment list that resides on the client access point, and determine whether or not the client is assigned. If it's assigned, it will go ahead and look to see any new components to install, etc. We'll talk about CCIM a little bit later on in the presentation.

However, if the client is no longer assigned to that site, in other words, the client's IP subnet is no longer in the site boundaries for that site, so that client is going to automatically deinstall the SMS client processes. This is one of the things that happens fairly frequently if you have mobile clients, such as laptops that move from one physical subnet boundary to another physical subnet. They can get a new IP address, and that new IP address and subnet might indicate they're no longer assigned to the SMS site. At that point, the SMS client software may be deinstalled.

In today's presentation, I'm not going to focus on the remote or mobile clients at all. That's going to be the topic of next month's WebCast. So next month we'll devote an entire WebCast to mobile clients and the issues related to mobile clients. I just wanted to bring that up at this point.

There are a couple utilities that might be worthwhile for you when you're looking at assigning a resource into sites. One of them, in the resource kit, is called site boundary (Sitebndy.exe). This tool is used to take a text file of IP subnets and import then into your site control file. So how you update, manually, is you go to the Admin Console, go to the Site Properties dialog box, go to the Boundaries tab, and just type in your IP subnets. Well, if you have a lot of IP subnets to add, it can be very cumbersome to add them through the Administrator console. So this utility, launched as a text file with the appropriate formatting on it, will just import that directly into your site control file for you. That's a way that you can use to update your site control file with a lot of IP subnets at one time, or IPX networks.

The other utility that you might find useful is actually on your SMS 2.0 Service Pack 2 CD in the Support.exe bundle. That's a utility called Site4c.exe. This is a utility that you can use to assign a client to a site, when normally the client wouldn't be assigned to the site. So let's say the client is a NetBEUI client; the NetBEUI obviously can't be assigned to the site because we only assign through IP subnets or IPX networks. So you could use Site4c to force that client to a site, irregardless of whether or not its IP addressing or IPX addressing would normally put it in that site. So that's a manual utility you can run to force a client to a specific site, if you need to. After a client has been assigned to a site, you can go into the process of installing the SMS client software on that client computer itself.

Slide 12 is just an intro slide with a few different topics that we'll go through in the next section of the presentation. First, we'll look at the SMS client components themselves. What are the different client components that need to be installed, and that can be installed? Then, we'll look at the SMS client installation process itself. We'll talk about the procedure a client goes through to become installed as an SMS client. Then we'll focus in on the four different client installation methods: Windows Networking Logon Client Installation, NetWare Logon Installation, Manual Installation, and Windows NT Remote Client Installation. We'll focus on those independently.

Slide 13 talks about the SMS client components themselves. I have this broken down into three different categories. The first category is installation and configuration components. These are components that will be installed as soon as you run the Smsls.bat file. Generally, whenever you run Smsls.bat, if these files are not downloaded to your client, some version of them or some portion of them is going to be downloaded to your client computer. These all come from a file called Clicore.exe. We'll talk about this a little more in the next slide.

These are some of the DLLs that are required for the SMS client infrastructure, the files that are necessary to perform the client discovery process. Also included are the discovery files; CCIM32, which is CCIM that we talked about earlier, and we'll talk about more shortly; and CLISVC, which is the actual SMS client service, provided you've become installed. So if you've actually installed your client, you'll have all those different files installed that are installation and configuration components.

The next set of components is called standard components. These are components that get installed on just about every single SMS client. For example, Windows Management Instrumentation (WMI). This is required on all 32-bit clients, if it's not already installed. Now SMS 2.0 still supplies WMI version 1.1, but if you have a client that already has WMI 1.1 or later installed, such as WMI 1.5, SMS will not overwrite that later version of WMI. Another standard component is the Advertised Programs Manager, or APM. That's the core piece of software distribution that's required for installing other components.

These two components, Windows Management and the Advertised Programs Manager (APM), are installed by CCIM. So after you've gotten through the process of installing the core infrastructure, then CCIM will kick off the process of installing Windows Management, if necessary, and installing APM.

Then you have what are called the optional components. These are components that are not enabled by default, unless you've done an express installation. You can pick and choose which of these components you want enabled at your site. However, they are site-wide configuration settings, so if you enable Software Inventory, all clients in the site are going to have Software Inventory.

These optional components are installed by APM. So CCIM will detect that Hardware Inventory is supposed to be installed, and it will request APM to install Hardware Inventory. So the optional components are Hardware Inventory, Software Inventory, Complete Software Distribution, which allows you to perform user-based software distribution, the NT Event SNMP Trap Translator client agent, Remote Tools client agent (or the Remote Control functionality), and Software Metering. Those are all the different client components that can be installed and we'll talk about what the individual executables are, as well as some of the functions for those components, a little later on.

Now, on slide 14, we'll talk in more detail about some of the client installation components, the things that are used to install an SMS client. First, you have a function called Smsboot1. This is called the mini bootstrap. Basically, all it does is it detects your operating system (whether it's Windows, Window 95, Windows NT 4.0, Windows 2000) and your network operating system (whether it's Windows-based, network bindery-based, network NDS-based). It detects your OS and your network operating system, and then it copies the main bootstrap program down to the client.

This process runs off your logon server. You connect to your logon server, you run Smsboot1, it detects your OS, your NOS, and it copies the main bootstrap program to your client. The main bootstrap program is Boot32WN, or, there are similar methods for NetWare, such as Boot32NW for NetWare, if Smsboot1 has detected your NetWare operating system.

One of the first things that Boot32WN is going to do, is it's going to verify your logon point version, to make sure that your logon point is not an up-level logon point. This is as of Service Pack 2. We discussed this in a little more detail at our Service Pack 2 talk back in May or June. Basically, as of Service Pack 2, when Boot32WN runs, it's going to look at your logon point and determine what version that logon point is. If the logon point happens to be a version of SMS that is later than the client computer, then Boot32WN just bails out and doesn't do anything else off the logon point because we don't want to get in the scenario where my client might be Service Pack 1, and the logon point might be Service Pack 2, and get our client in a mixed client scenario.

However, if it's a brand new client, a computer that doesn't have any SMS client software installed already, it will verify logon point version, verify client version, and when it notices there is no client version, it will go ahead and kick off the process. So it verifies that the logon point is not up-level from the client.

It will also check for an existing SMS unique identifier. So it looks to see if the client has been installed as an SMS client before. If so, it will go ahead and reuse the old SMS unique identifier or GUID, so that you can associate the new installation with the previous installation of the database. It downloads Clicore.exe down to your client computer, and then goes ahead and initiates the client discovery, assignment, and installation processes, whatever is appropriate for your site. If you've enabled discovery, it will do discovery; it will go ahead and process whatever has been enabled appropriately at your site. So that's the main bootstrap program. It does the vast majority of the work.

Now Boot32WN kicks off Clicore. Clicore is an SMS installer bundle, and if you just have discovery enabled, Clicore is downloaded and we unbundle the discovery components from Clicore.exe. Clicore is a very large file, a little over three megabytes in size. We download that file, and then expand it out to whatever is necessary for that client. If you've got Logon Discovery enabled, we'll expand off the discovery components. If you've got client installation enabled, we'll expand it out to install all the core client components. We run command line switches when we run Clicore, that detect or determine what functions or what components to extract from the Clicore bundle. Clicore itself will install CCIM and the SMS client service if the client is assigned to the site, and installation has been enabled. From that point, CCIM kicks off the installation of WMI, if necessary, and APM, as we talked about on the previous slide. It gets those from the client access point.

Let's look at this graphically on slide 15. This slide looks at a process flow for the SMS client installation process. Again, we're assuming we're using a Logon Discovery and Logon Client Installation, and we're using logon scripts for our Logon Discovery. The first thing that happens is our batch file runs, that is Smsls.bat. It checks for unsupported or unknown operating systems. If it detects an unknown or unsupported operating system, it bails out. It also checks to see if you're a terminal server client; if you have terminal services installed, it will bail out of the installation. You have to do a manual installation or a remote client installation for terminal services.

After you have passed the operating system check, then we go ahead and do a slow net check. We check to see what the connectivity is between your client computer and your logon point. We check to see how fast of a link you have. If the link is determined to be too slow, which is 40 Kbps by default, then it will not download the core infrastructure and perform a client installation. So if you're dialing in over a 33.2 modem or a 28.8, or something like that, you should be detected as being too slow. Now, you will download some files at some point, but you'll bail out of most of your stuff.

Provided you pass the slow net check, you will go ahead and start the Smsboot1 process. Smsboot1 is going to check to see if you've been a previously installed client by checking for an environment variable called SMS_LOCAL_DIR. If it finds an SMS_LOCAL_DIR variable, that's where it's going to point the SMS client installation to take place. By default, that variable is not there, so we used your system root, or Windir, environment variables. However, if you want to determine where the SMS client software is installed, you can create the SMS_LOCAL_DIR environment variable, and point it to whatever directory structure you want SMS installed to. It will detect that and install the SMS client infrastructure into that path.

So Smsboot1 checks for that, it checks your operating system, it checks your network operating system. It copies Boot32WN down to your client. Boot32WN then kicks off. It's going to again verify your logon point version. If your logon point is up-level from your existing SMS client version, it aborts the process. If it's a down-level version, it doesn't copy any files from that logon point either. If you're not an existing SMS client computer, it will go ahead and proceed with the process.

So it's going to go ahead and copy down Clicore; its going to copy Clicore from the logon point down to your client computer, provided it's not an older version or a much later version than the client computer itself. It will expand out Clicore with a /disc switch to extract off the discovery components. One of those discovery files is Cliex32.dll, as you see in the upper-right corner of your slide, that DLL will go through and perform discovery on the local client computer.

If Logon Discovery is enabled, then the DDR that is created will be copied back to the logon point. If Logon Discovery is not enabled, then the data is just written locally and nothing else happens with that discovery data. Cliex32.dll will then check to see if installation is enabled for your site. If Windows Networking Logon Client Installation or the appropriate NetWare method is enabled, it will then validate you site boundaries by asking "Is this client assigned to the SMS site?" If it is, it will proceed; if not, it aborts the process.

If the client is assigned, then Clicore will run again. This time it will install the base or core files. So it will do a Clicore /Full to do an installation of all the base core files. Boot32WN will also copy down Smsboot1.exe, Slownet.exe, and again, Clicore, to the client computer so you have all those files locally on your client, and you don't have to copy them from the logon point again, unless they get updated.

After Clicore has done its full installation, CCIM will then get registered and started. It will go ahead and check your appropriate CAP for any other components to install. So it will kick off WMI, or Wbemsdk, as our code is; it will kick off the Apasetup; and if necessary, it will kick off installation for any of the optional components. It will go back to your client access point and look to see what components are enabled at your site to see what's supposed to be installed on your client computer.

So that's the basic process for a client. You run the logon script, and the logon script verifies that you can be installed as a client; in other words, you have a supported OS, and you have a network speed that's not too slow. It will go ahead and copy down and launch off Smsboot1. Smsboot1 validates your OS and network operating system, so it knows what main bootstrap program to run. It copies down the main bootstrap program. The main bootstrap program runs. It copies down Clicore, does discovery (if necessary), does assignment, and then installation, if necessary. When Clicore does its full installation, CCIM is installed, registered, and enabled. CCIM then takes care of the rest of the installation process, which we'll talk about in a couple more minutes.

The first client installation method we're going to look at is Windows Networking Logon Client Installation, on slide 16. This is used in a Microsoft Windows environment when you want to do Logon Client Installation. In this environment, the administrator goes into the Administrator console and enables this client installation method; it's not enabled by default, unless you've done an Express Setup. The administrator enables it, and specifies which domains he wants to use to set up the domain controllers as SMS logon points.

When you do enable a domain for Logon Client Installation, all domain controllers in that domain are set up as SMS logon points, provided you have the appropriate security rights and disk considerations. You can choose whether or not you want to use logon scripts. From what I've seen, about half our customers use logon scripts with SMS, and about half of them don't. So choose whichever one you want to use. If you have an existing logon script that you're using, you can tell SMS not to modify logon script or, again, you can have SMS modify the logon script, which will then make a call to our logon script (Smsls.bat). That's an administrator option.

If you're on a Windows NT or a Windows 2000 client, and the logged-on user is not a local administrator, then the site server will need to interact with that client to get that client's components completely installed. The Client Configuration Manager on the site server will have to jump in and take part in the client installation process. So when Cliex32.dll runs now (this is as of Service Pack 2), it's going to try and access some client registry keys. If it can't access the registry keys, it's going to assume the logged-on user is not a local administrator, so he's a low rights user. If he's a low rights user, he's going to create a CCR, a client configuration request.

The CCR is then copied to the client access point. It's moved to the site server from the CAP, and the site server's CCM, or Client Configuration Manager, is going to recognize that CCR and say, "I have to help install a client computer." In order for this to occur, the site server needs to have an administrator account on that local computer. That can be either the SMS Client Remote Installation account, which is not created by default, so it's an administrator-assigned account; or the SMS service account. By default, the SMS service account should work, because the way SMS is installed, the SMS service account is actually the Domain Administrators global group, and by default, Domain Administrators global groups are added to Local Administrators groups for all Window NT and Windows 2000 clients in the domain.

By default, the SMS service account should work. However, if you've changed your security infrastructure and removed that, or if you're working with clients in different domains, you're going to have to supply an account that will be a local administrator on that computer, so that you can have the site server push down the SMS client software. Another option is to make sure the logged-on user is a local administrator.

The Windows Networking Logon Client Installation method is required for all client platforms other than Windows NT and Windows 2000. So if you've got Windows for Workgroups, Window 3.1, Windows 95, or Windows 98 clients, you have to have Logon Client Installation enabled. You don't have to use logon scripts, but you do need to have Logon Client Installation enabled. We'll talk about the other two platforms, Windows NT and Windows 2000, after we discuss a few more methods.

You also have the exact same methods for NetWare. The NetWare Logon Client Installation method functions the exact same way as the Window Networking Logon Client Installation method. So there are just a couple of methods there for the appropriate NetWare interoperability.

Slide 17 talks about Manual Installation. Manual Installation feeds, again, off of the Window Networking Logon Client Installation. What happens with Manual Installation, is you enable your Logon Client Installation method, then the user again runs that same utility we talked about for Manual Discovery; it's the exact same program–Smsman for 32-bit clients, Smsman16 for 16-bit clients, and then there is no Manboot for installation because we don't install SMS clients on MS-DOS-only clients in SMS 2.0; so you either run Smsman or Smsman16.

The user will run that program, wherever he's going to find that program, either directly from the logon point, from an e-mail message from the admin, from a Web page that's been posted with that file, or on the Windows 2000 CD. You run the appropriate utility again, and that will go ahead and kick off the discovery process, if Logon Discovery is enabled, or the Client Installation process if Client Installation is enabled. So it just runs and performs whatever functions are enabled for Logon Discovery or Logon Client Installation, whatever you have set up for your site.

If you want to have your client installed into multiple SMS sites, the first thing you have to verify is that the client will be assigned both sites. That would mean its IP subnet is a member of site boundary for multiple sites. You can either run Smsman from two different logon servers in two different sites; or just run Smsman and you will have the option of having SMS automatically find a logon server for you, or you can point it to a specific domain or logon server to use for the client installation. Basically, this does whatever you have enabled at your site for Logon Discovery and/or Logon Client Installation. So if you don't want to use logon scripts, this is the method most people use to install their clients, and this utility can be scripted, so it can be totally hands off for the users.

The next method of installation is the Windows NT Remote Client Installation method, on slide 18. Again, this is not enabled by default, but it's very popular for getting SMS installed on unattended servers that are locked away in server rooms. When you enable Windows NT Remote Client Installation, this method will cause the Discovery Data Manager, or DDM, on your site server, to scan all the discovery data records in your database, looking for any Windows NT or Windows 2000 operating system clients that are newly assigned system resources. In other words, it has to be a system resource, which means it's a computer; it's has to be Windows NT or Windows 2000; it has to be new, that is, not an already existing SMS client as detected in the database; and it has to be assigned to your local site.

If all these four things are true, then the Discovery Data Manager, which is running the function for the Windows NT Remote Client Installation method, will go ahead and create a CCR for that client computer. They'll pass the CCR off to CCM, the Client Configuration Manager, which will then push out the SMS client software. This is very similar to what we talked about a couple slides ago for Windows NT and Windows 2000 clients, where the logged-on user is not an administrator. Again, this does require an administrative account that the site server can use to connect up as an administrator on that remote client, either the SMS service account or the SMS client Remote Installation account.

If you're using this installation method, let's say you want to prevent SMS from pushing out the client software to a specific computer. For example, some customers don't want SMS client software to be installed on their domain controllers, so their internal IT guys have a policy where they consider it foreign and nothing foreign can be installed on their domain controllers. If that's the case, then there is a registry key you can use with SMS to specify the names of those Windows NT or Windows 2000 domain controllers, to prevent the CPM process from pushing SMS client software out to those domain controllers. However, if any user were to log onto that computer and run the logon script Smsls.bat, or Smsman, there's nothing to prevent them from installing that computer as a remote client. So this registry key is only for the Windows NT Remote Client Installation or push method, not a user-initiated method like the logon script or Smsman.

Generally what happens here is you enable this method, and then you perform a network discovery session. The network discovery session would go out and find your Windows NT and Windows 2000 computers, hopefully it finds a subnet mask, then creates the DDR for it, and processes it in the database. Then the Discovery Data Manager would say, "This is an NT or 2000 client, it's brand new, it's a system resource, it's assigned to my site. I want to make it an SMS client." It would then create the CCR to get that pushed out to the clients.

There's also a rescue utility called Add System, that will allow you to manually create a DDR to begin this process. So if you want to enable the Windows NT Remote Client Installation method, but you don't want to run network discovery, you can enable it and then use Add System to create a DDR that will then be detected and force a CCR to be created.

Those are your different client installation methods. Next, on slide 19, we'll talk a little bit about troubleshooting client installation. So what are the most common problems people encounter when trying to install SMS client computers? The first one is the client installation method has not been enabled. That is, you don't have Windows Networking Logon Client Installation, Windows NT Remote Client Installation, or either of the two NetWare client installation methods enabled; you have no method enabled. This is not as common anymore, but when SMS 2.0 first came out, it was very common for people to enable discovery, but not enable the appropriate client installation method. So we would find all their computers when the users logged on to the network, but there was no configuration to tell SMS to install SMS client software there; so we just discovered them and perform no installation.

The next one is client computers not assigned to the site. So, by default, the only site boundary you have is your SMS site server's site boundary. Generally, site servers are not on subnets where client computers are, so most of your clients are on separate subnets because the site server is going to be locked away in a server room. So when the client goes through the discovery and assignment process, its going look at the assignment list, realize that it's not on that subnet, and bail out.

A very common process is for people to not enable additional subnets or to enter the wrong subnet ID. You need to make sure that you enter the proper subnet ID, and that's not what the site server needs to know; it's what the client needs to know. You need to enter the subnet ID that the client's going to evaluate it when it looks at the IP address and subnet mask. If you're not sure what to put there, let the client get discovered; it will create the DDR, and you can look in the site database to see what the client IP subnet is.

Next is not enough disk space in your client. The SMS client installation process looks for 30 MB of free disk space on your client computer, and whatever path you want SMS to install on; the default path is the system route or Windir environment path. It doesn't take 30 MB, but we look for 30 MB just to make sure we have enough disk space.

The next point on the list is no administrative access to your Windows NT or Windows 2000 clients. If the logged-on user on an NT or 2000 client is not a local administrator, you need to have an account that the SMS site server can use to push out the client installation processes and components down to the client. This is either the logged-on user, or the SMS service account, or you have to manually create an SMS NT client Remote Installation account. We've talked about how to create that in other WebCasts. Basically, on your Site Properties tab, go to Accounts, and go to the bottom for Client Installation Accounts.

The next one is your operating system is locked down too far. So, using either policies or NTFS permissions, you set it so secure that the SMS client processes don't have access to create directories, create files, and register the things it needs to do. So if you've locked down your OS too far, you can prevent the SMS client infrastructure from installing. Again, you need administrative permission to be able to create directories, install files, execute utilities, and update the registry.

The last one listed is the TEMP environment variable is invalid. When Clicore runs, Clicore expands out into your TEMP environment variable. So if the TEMP environment variable is invalid, or there's not enough disk space for that, then Clicore doesn't expand, and the client infrastructure can't be installed.

Those are most common problems that I see from talking to customers on getting their clients installed.

Now that your client is installed, let's go through the last couple slides (starting with slide 20), which outline the specific SMS client components. What are the components, and what to they do for you? The SMS Client Service is going to be your core SMS client component. Again, if you look at Task Manager, what you'd see for the process is Clisvcl.exe (that's the SMS client service). It runs under the context of the SMS client service account, which is, by default on most clients, the Smsclisvc account. Now in domain controllers that are SMS clients, we create a separate account for each domain controller for security purposes. Basically, this is the controlling service for the SMS client infrastructure. It runs all the system utilities for the SMS client processes; so when it's time to do Hardware Inventory, it's kicked off; when it's time to check for advertised programs, again the client service is going to initiate all that processing.

The component that controls the installation and configuration of your client is the Client Component Installation Manager, or CCIM. It does the vast majority of the work on the day-to-day operations and configuration of your client. Every time you reboot your client, or you stop and restart the SMS client service, or you do an update configuration from the Sites tab of the Systems Management Control Panel application, it's going to go through a process called the maintenance cycle.

In this maintenance cycle, it's going to check for what components should be installed at your client. If there are any new components that have been enabled that aren't installed locally, it's going to kick off the installation for that through APM. It will deinstall any components that aren't supposed to be installed any longer; so if you used to have Remote Control installed, and you disabled it through site, it's going to force the deinstallation of Remote Control. CCIM will also upgrade any components that need upgrading, such as your Service Pack 2 (or Service Pack 3, which will be released shortly). It's going to configure any settings for any of those components. If you changed your inventory schedule from weekly to monthly, CCIM detect that and have that configured. It will also do a client verify process every 30 days, plus your offset, which we talked about in the Service Pack 2 talk. This also occurs every 23 hours, so if you have your client up and running and you don't shut it down on a daily basis, every 23 hours CCIM kicks in and does its maintenance process. CCIM makes sure that your client is installed and configured appropriately. It also checks to see whether or not you're still assigned to the site, and if you're not, it will kick off the deinstallation of all your SMS client processes.

Windows Management Instrumentation is a core feature for Hardware Inventory. On a client computer, the primary reason for WMI is for Hardware Inventory. We poll all the data from WMI using the providers for that. We install that directly with SMS, unless you have a current or later version of WMI already installed, in which case, we don't overwrite that.

Advertised Programs Manager (in the Task List that would be Smsapm32.exe) is your software distribution component. That's a core piece of software distribution that CCIM talks to. When Smsapm needs to install the SNMP Trap Translator, or Hardware Inventory, it will pass that offer file off to APM, which then does the installation. So APM is used to install optional SMS client components.

A couple of other things before we go to the next slide; you'll see Launch32 on your Task Manager List. Launch32 is responsible for making sure all user-based SMS clients run at specific intervals, including software metering and software distribution (to be advertised to users or user group membership). So if you kill your software metering client agent, within two hours SMS is going to restart it because Launch32 will detect that it's not running, and it's supposed to be running, so it will restart it.

Smsapm32 is going to kick off a couple of ODPs, looking for advertised programs on an hourly basis, by default, for the system. Then you'll find Smsmon32. That's a user portion of software distribution for advertisements that have been advertised to the client, but the clients reschedule them to run at a specific date and time.

Okay, we'll discuss the optional components on slide 21, and then we're just about done. Hardware Inventory, on Windows NT and Windows 2000 clients, now runs as a service called the SMS Hardware Inventory Agent Service, Hinv32.exe. Prior to Service Pack 2, it runs under the context of the Smscli token account, which, as we've discussed in other WebCasts, has caused problems with account lockouts. So as of Service Pack 2, on NT and 2000, that now runs on the local system context. On down-level clients, like Windows 95, 98, and so on, it runs under the context of a logged-on user, if you don't have different security context there.

Software Inventory Agent is Sinv32.exe; that runs under the context of the Smscli token account. You generally won't see all of these components in your Task List, except when they've been started. So when the client utilities or client service kicks off a component, you will see it in the Task List, and when it's done, it will be removed from the Task List.

Software Distribution. The user portion of software distribution is the ODPs: ODPSys32.exe and ODPUsr32.exe. Those look for advertisements to your computer or your logged-on user, and they'll run under the context of the logged-on user or the SMS client token account if you're in an offline mode for a Windows NT client.

Remote Control. Its executable is Wuser32.exe. It runs under the context of the local system account. Software metering is LiccliNT.exe, and that runs under the context of the logged-on user. The Event to Trap Translator utility has no executable, so you won't find it running anywhere in a Task List; it just creates a registry hooks to the event logging service, so when a specific event is received, it generates a trap message automatically, but there's no executable that you would see running in the Task Manager at any point in time.

Okay, so we've talked about how you discover clients and how you install clients and their components. What do you do if you want to remove SMS from a client computer? There are a couple different ways you can remove SMS from a client computer.

If you want to deinstall a single client computer, you can go ahead and use your Systems Management Installation Wizard. This is Smsman or Smsman16. Go ahead and run Smsman, and on the first page you have an option at the very bottom that says to remove all systems management components from this computer. As long as you're an administrator, logged on to the local administrator computer at the computer, it will go ahead and kick off the deinstallation of all the client components.

There's also a registry key you can set; that's the Client Deinstall Registry key. This is actually what the Smsman program does. It sets the registry key, then it stops and restarts the SMS client service to detect that registry key has been changed.

On your resource kit, in the support bundle, there's an SMS 20CliCln.bat file. It will kick off the deinstall of all your client components. You can remove the site boundaries that the client is a member of, so if you want to remove all clients in the specific subnet, just remove the site boundaries, and the next time CCIM runs its maintenance cycle, it will deinstall the clients. Now, as we've talked about before, when you deinstall a client, none of these methods remove the entire SMS client footprint. Some registry keys are left for reinstalling later on or for security from Remote Control, so you have to remove those if you want to do a complete client removal. We don't remove the Smscfg.ini file because that contains the last SMS unique identifier, or GUID; we want to keep that in case you reinstall, so we can reassociate the new install with the previous install in the database. We don't always remove the MS SMS directory structure, because processes generally have those files hooked, so we can't remove them, and there are a couple files in there that are used for reinstallation of the client. We also don't remove the profiles in your client computer. So a little bit of clean up is required if you want to do a total deinstallation of your client.

In summary, before we get in to the Q&A session, we talked about how you discover clients, how you go through the assignment process, and go through the client installation process. We mentioned that each of those is a separate process, and you don't have to have all of them enabled. Now you don't enable assignment because assignment gets enabled by default when you enable client installation; but you can go with just discovery, if you want, and not installation, or you can go with installation, but no discovery. Again, if you don't have Logon Discovery, you need to make sure that you have Heartbeat Discovery enabled, otherwise you'll wind up getting your clients removed from the database frequently.

We talked about five different discovery methods for discovering clients. We talked about four different installation methods. The vast majority of the installation problems people encounter are security related, or administrative configuration errors; for example, you didn't enable the appropriate subnets, you didn't enable the client installation method; you locked down your client too far; or you don't have an administrative account.

We haven't really talked about the last bullet regarding how mobile clients have special needs. That will be the subject of next month's WebCast, which I believe is on February 23, but Heidi will confirm that. So, with that, I'll kick it back over to Heidi.

Heidi: Excellent. Thank you so much for that presentation, Wally. You are correct, it is February 23 that we have our next SMS session on mobile clients. So now we'll go ahead and get right into the Q&A portion of this Support WebCast. We have had several questions submitted, so I just want to give you a couple notes before we do jump right into that.

First of all, you would like to have a hard copy of the PowerPoint^® slides, be sure to download them from our Web site, at http://support.microsoft.com/webcasts/. From that location you can see all of the upcoming Support WebCasts, and if you scroll down to the bottom and select Past WebCasts, you'll be taken to a list of all of the archives.

In addition to the PowerPoint slides, we also post a full session transcript within about three weeks of the live session. So there are lots of different types of content for you, if you'd like to leverage any of that.

I would like to remind you that the Q&A portion of the Support WebCasts is intended to encourage further discussion of the Support WebCasts topic; however, one-on-one product support issues are outside the scope of what we're able to address during the Support WebCast program. If you do have a support question, I would encourage you to either phone in to Product Support Services and speak with a support professional directly, or submit an incident on the Web.

Let's go ahead and jump right into our Q&A. The first question is, Is there a way to install optional components such as Hardware Inventory, Software Inventory, and Remote Tools on a per computer basis?

Wally: No. All those components are site-wide based, so if you enable the client agent within the site, all clients that are assigned in that site are going to be getting that appropriate client agent. Now, there's nothing to prevent you from going to your CAP and running the specific executable that SMS would run, and installing those components manually. However, what would happen is, the next time CCIM ran its maintenance cycle, it would say, "Wait a minute. I have Hardware Inventory installed, I'm not supposed to. I'm going to deinstall it." So, no, currently with SMS 2.0, everything is site-based, not collection-based or individual client-based.

Heidi: We have about ten packages that are made available to all machines that are part of SMS. We've noticed that the packages are adding in clumps of four or five with 15 minute breaks. Can the packages be dropped down all at once?

Wally: If you have a bunch of different packages that have been advertised to a client computer, and they're all set to run basically at the same time, SMS is going to go ahead and install those in an order which it chooses. There's no set order in which SMS installs those packages of advertised programs, unless you've done program chaining, and you have a Requires this package first, in which case it will go ahead and kick them off in that order. Other than that, no, there's not any other order you can specify.

Now, you mentioned packages adding in clumps of four or five with a 15 minute break. I'm not aware of that all, so I have no suggestion to give you regarding whether or not you could change that interval. I've always heard that they just kick off and they just flow through. Unless there's some other reason that SMS is delaying the process in those, I cannot give you a suggestion there. I've never heard of that before. I would call that in to PSS and ask them if there's some way, but I don't know of any.

Heidi: Okay. Next in line, How do you force a certain CAP to a local group of machines for use in remote offices, when one doesn't want a workstation assigned across a CAP, across the WAN?

Wally: Well, first off, this is violating the SMS architecture because you should never have clients separated from their site systems over a WAN link. In this environment, it sounds like you do have a CAP that's local to your client, but you should never have a site spanning WAN links like this so that you need to force clients to use specific CAPs. SMS, again, assumes high-speed connectivity; we want everything to be within the local context. If that's not the case for you, then we want you to have a remote site across that WAN link. In some cases that's not feasible, but that is the recommended scenario.

There is a resource kit utility called Prefserv.exe. The Prefserv utility, from the SMS 2.0 Resource Guide or the Microsoft^® BackOffice^® 4.5 Resource Kit, can be used to designate for a set of clients. This is the client access point I want to use. However, if you designate your CAP on the local subnet, then when that CAP becomes unavailable, your client is going to randomly select any of those CAPs in the site, which may be across a WAN link or two WAN links, to do its installation, its configuration, or whatever the process is. So you can set it for one or multiple, but after it gets past all those, it's going to randomly select again.

Heidi: Terrific. SP2 made substantial changes to Logon Discovery. Can you discuss some of these SP2 changes, specifically, use of Diskpref.lst as a means to control DDR flooding?

Wally: Diskpref.lst can help you fine tune where your DDRs are being reported to; however, with Service Pack 2, you should not have flooding at all anymore because the Logon Discovery Agent is now intelligent. What happens is, every time a logon server manager says, "My site is using this domain for Logon Discovery," it registers that on the primary domain controller, and that gets replicated out to all the different domain controllers.

When those discovery agents start up, it creates what's called "site groups". It logically looks at: where are the secondary sites, what secondary sites, where are their parents' site, what are all the primary sites, do they have discovery enabled. Then it goes ahead and logically copes that DDR to appropriate sites in a site group. There's not a hard, fast rule for where it's going to go; it never copies down below the site where's it was created, so if you've got a multiple tier hierarchy, and the DDRs created a middle site, it's not going to get replicated down to a child site. It will get replicated at the middle site or above.

If your logon server happens to be a site server, it's going to send the DDR to that local logon point slash site server, so you don't have any traffic. Now, Diskpref.lst can be used to state, "I never want this site to receive a DDR," or "I always want this site to receive a DDR." So you can customize that a little bit with the Diskpref.lst, but you shouldn't be having DDR flooding at all with Service Pack 2 now.

Heidi: Can you provide a brief outline of the preferred means to remove the 1.x client cleanly and completely? This is important to ensure a clean installation of the new 2.x client system going into a completely new 2.x site server with no upgrade of the existing site.

Wally: First off, you don't have to remove the 1.x client as long as the 1. x client is 1.2. If it's a 1.2 Service Pack 4 client, SMS does support an upgrade from SMS 1.2 Service Pack 4 up to 2.0, without doing a removal of the prior code. However, if you do want to remove your SMS 1.2 client, then the preferred method is to run the Deinstal.bat file from your logon point.

So you go to your logon server, the Sms_shr share name, and run Deinstal.bat (there's only one "l" in deinstall because of the eight-character limit). It will tell your client in the Sms.ini file that it needs to be deinstalled, and then you go ahead and run Smsls.bat, or run Sms.bat. The client process will detect that it's supposed to deinstall, and then it will kick off the deinstallation process of your client component at that point. That will remove the vast majority of the 1. x client files. The rest can be upgraded automatically when you log in to a 2.0 site and get assigned to that site. Outside that, there was no CliCln-type utility that was ever supplied in the resource kit to clean that, so it's a manual process. We do document all the client components in the old BackOffice Resource Kit or SMS Resource Kit for 1.2. We had documented all that in Appendix B, but I am not sure.

Heidi: Okay, next in line. I'm actually going to combine a couple of questions that are very similar. Is there any publicly available information on SP3 yet? Is there any information about when we can expect the release?

Wally: Service Pack 3 is primarily just the QFE roll up. What that means is hotfixes that were generated after SP2 was shipped are being combined into a service pack, and then being produced as an official service pack. The reason for that is some customers don't install hotfixes because they're not tested very well. Hotfixes are quick fixes that we test very quickly and on a very small scale—the customer verifies it, says it worked, and then we make it available for other customers. However, it doesn't go through full stress testing and interoperability testing and so on, as service packs do. So we're taking all these QFEs and we're rolling them up into Service Pack 3. The only new functionality that Service Pack 3 is going to provide to you is the ability to perform at accelerated video during Remote Control sessions on Windows 2000 clients. It also provides very limited support for Whistler Beta 1, and possibly Beta 2 as well.

With regard to an expected release date, I can tell you it's coming very, very soon, but I can't tell you the exact date. I'll get shot if I do. Publicly, we're stating it will be released first quarter this year.

Heidi: Okay. The next question is also about SP3. I understand that DDR sending is broken in SP2. Is it fixed in SP3?

Wally: To my knowledge, it's not broken in SP2, so I can't tell you if it's fixed in SP3 because I'm not aware that there's a problem.

Heidi: Excellent. Next in line, If the SMS client is installed and reporting Hardware and Software Inventory, do I still need discovery?

Wally: Yes, you do, and the discovery method you'd want is Heartbeat Discovery. The reason you still want discovery is that when you generate Hardware and Software Inventory, if the client that generated the inventory is not already in the database, then your appropriate Hardware or Software Inventory processing functions will create a discovery record for that resource. However, the inventory data loader and the Software Inventory processor do lousy jobs of creating discovery data. So your client does not look right when you look at your discovery data. It's trying to pull some data from the appropriate inventory file, but it's guessing at some of the stuff and it's not correct. You still want Heartbeat Discovery there to generate a proper DDR prior to having inventory reported.

Heidi: The next question refers to slide 10. What is the difference between CAP and the site server?

Wally: The difference is that SMS clients never talk to site servers. SMS clients always talk to a client access point, a logon point, a software metering server, or a distribution point; they don't talk directly to site servers. Now in some environments, your site server is your only client access point. However, for Heartbeat Discovery, when CCIM creates the discovery record (the DDR), it directs it to the client access point. So it's looking at the CAP share, that is CAP_<whatever your site code is>, and then to the DDR box directory, and that's where it's writing that DDR (that's why I have client access point there on slide 10, as opposed to site server). The CAP then forwards that DDR up the site server, which then processes it into the SMS site database.

Heidi: Excellent. Moving on to the next question. Are DDRs still being sent to all logon points in SP2?

Wally: No. We've already talked about this a couple times, and it's not logon points, it's site servers. With SP2, there is intelligence in the Logon Discovery agents that are running on your domain controllers. So it determines one site server per site group that may receive a DDR, but not more than one site server per site group, and not necessarily all site groups are going to receive the DDR. So, no, in Service Pack 2 we don't copy DDRs to all site servers; and we've never copied them to all logon points in any version.

Heidi: Before we go on to the next question, I want to encourage all of you to take a few moments to submit some system feedback before the end of the broadcast. We're very interested in your feedback regarding the Support WebCast over all. If you have any feedback on the session you've listened to today, or any suggestions for topics you'd like to see in the future, you can use the alias: feedback@microsoft.com. If you do use that alias, be sure to include "Support WebCast" in the subject line.

Moving on to the next question. When viewing the Software Inventory for a given client, multiple occurrences of an application appear, for example, WinWord, although only one instance of Word is installed. Is there a way to filter and retrieve only one occurrence of an installed application?

Wally: Directly within SMS, no. What SMS does, is it looks at all the appropriate file types that you've enabled, which are by default, executables, and it reads the resource header from those executables. So if you have Microsoft Word being reported as an application multiple times, the reason is that there are multiple files that our Software Inventory program found, and those files report Microsoft Word with different build numbers, or different version numbers. We always report (unless all the attributes are the same) every single file we find with the appropriate version number. So you see a lot of Windows NT, Windows 2000, Internet Explorer, SQL Server, or whatever, listed multiple times, even though you know you only have one instance of them running. It's just because of the way inventory works; it checks all your files, and for any file that reports, "I'm Microsoft Word," it's going to report that with the appropriate version number. If the version is different than the previous files, then it's going to be shown as a different version of Microsoft Word, or whatever the application is.

I haven't tried it, but I've heard that Computing Edge has an add-on to our Software Inventory process that gives you more flexibility than we provide in SMS 2.0.

Heidi: Okay. Could you please repeat the name of the tool that you mentioned before—the site for CE? It allows you to set up the boundaries for sites from a text file.

Wally: The name of the site boundary is Sitebndy.exe. It's in the resource kit or the resource guide. It's not in your support bundle. It allows you to take a text file of IP subnets and add them as site boundaries.

Heidi: Next in line, How can I tell when Network Discovery is finished running, and what records will show, if any?

Wally: There are numerous different ways. One way, is you could be monitoring your network traffic and see where your network traffic dies. Network Discovery is going to generate a lot of traffic. One preferred method is to use the Service Manager. Go to your tools group in the admin UI, go to SMS Service Manager, and then look at your components for your site server. It will tell you what components are actively running. Those that are actively running will have a green triangle by them, and those that are stopped will have a red square. So when Network Discovery has a red square by it, you know it's done its processing and no longer running.

Another preferred method is to go to your status system. In your SMS status system, look at component status for Network Discovery; there will be a series of status messages generated. I mentioned those; I had them all listed for you in last month's session, which I don't have with me, so I can't tell you what the exact message ID is. But there will be a message there stating that Network Discovery is done. Okay, I'm looking at my status messages right now so I can tell you what the status message ID would be. It would be 1308, "Network discovery has stopped," or 1307, which says, "I've found resources. I'm exporting them." So when you look at the status system under SMS Network Discovery, the messages you want are in the 1300s.

Another way you could tell is by looking at your discovery database. You could look at each of your collections, like the All Systems collection, and see if you have any new resources that weren't there before. You could look to see if it says one of the discovery methods was Network Discovery. Or you could look at an existing resource. If you look at an existing resource, you would see SMS Network Discovery as the method that was used to install and discover that resource.

So the main ways to tell if Network Discovery is finished, is to either use Service Manager or look for the appropriate status messages.

Heidi: Terrific. Just a reminder, we do one SMS broadcast each month, or at least we attempt to, and we have all of the archives available. We've had several sessions so far, most of which have been done by Wally. That is available from our Support WebCast site, which is http://support.microsoft.com/webcasts/. Scroll down to the bottom of that page and select Past WebCasts. You'll see the Technology option for Systems Management, and you'll see a full list of all the sessions we have done, including last month's. This one will be in that category within eight hours of the live session.

The next question refers to slide 15. I didn't clearly understand what comes before Smsboot1. Can you clarify?

Wally: What I was relaying in this slide was the SMS logon script. Smsls.bat is what created the MS-DOS prompt you see there, and on the graphic it shows Smsboot1. So in this specific slide, the SMS logon script is what's kicking off Smsboot1. But if you weren't using logon scripts, it could be Smsman. Smsman does the exact same thing that the logon script does, with the exception that Smsman does not filter operating systems, like Terminal Server. It also does not do the slow net checking, but it does everything else.

Heidi: Terrific. What is the best way to start the discovery installation process on clients if you are starting a new site with clients that were once part of a previous site that failed? Will Boot32WN bail if the previous version is detected?

Wally: Boot32WN would bail if it looked at the existing client, let's say it's a Service Pack 1 client, and then it hit a logon server and the logon point is Service Pack 2. It would bail at that point so we didn't have a mix of client processing. However, if they were both Service Pack 2, but the Service Pack 2 installation was not working, or your clients were not completely installed, then the next time you try to run the installation method, it should pick up right where it left off and just finish off the installation.

So Boot32WN would only bail if it were a newer version than what the local client was itself, in which case you would actually do the pick up from the client access point itself. So you'd complete the installation from the CAP after you got everything registered.

Heidi: With regard to SMS service accounts, what is the name called in the user manager?

Wally: When you install SMS, you designate the service account you want to use. The default name is Smsservice, and you designate the password. However, you can change that to whatever you want it to be.

Heidi: Excellent. At this point we still have a handful of questions in the queue, and it's just about time to wrap up. So we're going to ask that no more questions be submitted at this time, but we will get to all the questions that have already been submitted.

The next question is, We have staging areas for PCs. After the PCs are staged, they are then deployed to various locations, all on different subnets. If we manually pre-install the SMS client, assuming that our PC staging areas are in a different SMS site than the deployed PCs, how long will it take for the deployed PCs to register appropriately under each appropriate site? What is the effect on network bandwidth in adopting this staging and deployment model?

Wally: Okay, there are a couple scenarios here. First off, if you're pre-installing the SMS client software, I need to know whether you mean you're just putting executables on the hard disk and expecting SMS to run it from there, or if you're doing a complete client installation and then you're cloning that client someplace else?

As you know, we don't support cloning at all. So you have to take very careful measures to make sure that you remove all references of a specific SMS unique identifier, or the GUID, from that client; otherwise your cloned image might put duplicate IDs in your database. Then you would have to go back to, I believe it was the August WebCast, that talked about duplicate IDs in your database.

If you're manually installing the client fully, so that each client gets installed separately (so they are unique clients), and now you move them from one subnet to another subnet, the process is, basically, to drop that client in the subnet where you want it to be. When the client boots up, it requires an IP address of the subnet. The SMS client boots up (let's say you do a logon script), it checks and says, "I'm now assigned to this new site," and then it would go ahead and install that client directly in that new site as soon as it detects that it's supposed to be a member of that site. That would happen instantaneously, as soon as you ran your next SMS installation process, either Smsls.bat or Smsman.

If you don't run one of those, and you have your client installed and you just boot up your client with no procedure or method for SMS to find out about your new site, then your client would look at it's current IP subnet, look at it's current site, and realize that it's not assigned to that site anymore. It would then deinstall the SMS client software from that computer and you would not have any SMS client software installed until you ran some installation method pointing it to that new site again.

So it depends on how you're doing your staging, it depends on how you're kicking off the installation (if you are kicking off an installation on your new location), to determine what's going to happen now.

With regard to the effect on network bandwidth of adopting this staging deployment model, if you run an installation method, like Smsls.bat or Smsman, prior to the client becoming deinstalled from the old site, then there won't be much network traffic implication at all. When you get assigned to the new site, you've already got your client components installed, so it will just assign you to the new site and install you to the new site, but there is very little code going across the wire.

However, if you allow the client to become deinstalled first, and then you run your installation method to get installed or assigned to the second site, then it's going to completely remove your software and do the complete reinstall of your code over the wire, which, depending on what components you have enabled, can be anywhere from 6 MB up to 13-14 MB in network traffic. We'll talk about this a little bit more in next month's session when we talk about mobile clients. We'll talk about moving a client from one site and subnet to another site and subnet.

Heidi: What is the name of the registry key used to prevent Remote Control?

Wally: I know of no registry key that can be modified, added, or whatever, to prevent Remote Control. Remote Control is on a site-wide basis, so every client in your site is going to have the same agents installed there, enabled at your site. So if your site has Remote Tools Client Agent enabled, all clients are going to have it enabled. Now there is a registry key to update parameters for that client, such as giving users a choice in whether or not the admin can take control of them, but you don't want that for servers because nobody is logged-on. So there's a registry key for that, but not one to prevent Remote Control, not that I've ever heard of.

Heidi: The next question is, Does using the Exclude Server key to bypass the Remote Installation method work equally well on servers as on workstations?

Wally: Sure. The Exclude Server key for DDM will work for any Windows NT– or Windows 2000–based box; however, it's only for the Windows NT Remote Client Installation method. If a user goes to that workstation and runs the logon script, or finds Smsman on their Windows 2000 CD or somewhere else, then connects up to the logon point and runs it, they will find that the registry key is going to do absolutely nothing to prevent that from being installed. It's solely for DDM creating a CCR to push out the client software from the Windows NT Remote Client Installation method; but, yes, any Windows NT or Windows 2000 box.

Heidi: Do you know if the beta for SP3 has happened yet, and if not, how can one participate?

Wally: The beta has already happened. In fact, somebody just e-mailed me today on the internal Microsoft network saying, "I have a customer that wants to get in the beta." The beta coordinator said, "Absolutely no way, because we're very, very close to shipping. We're not going to take any time to get anybody else in the beta program." So, yes, it did happen.

The appropriate field locations had to nominate the customers that they wanted to be in the SP3 beta program. It is very, very near complete, so from what I understand, there's no way of getting SP3 beta code if you don't already have it.

Heidi: Next in line. I'd like to set up SMS to discover a single room within a large subnet on our domain, but don't want to include machines outside this room, even if on the same subnet. Is Manual Discovery my only option in this case?

Wally: Manual Discovery would be an option. The other option you might have is a utility in the SMS 2.0 Resource Kit called Random Login. Rndlogin.exe allows you to put in controls so you can specify which computers can run the SMS logon script. You can do it by throttling x percent of the people that log on. You can do it by computer name, or domain name, or something to that effect. So you might look at that. Other than that, yes, because we do assignment and things based off of a subnet, everybody on that subnet would be included. Again, discovery is not subnet based. Really, we only care about the subnets from an installation aspect, not a discovery aspect.

So you could use manual installation, or you could manually set up logon scripts on the users in that computer room that you want to discover, or e-mail them the Smsman program and then have them run it, which, again, you can command-line script, so it's totally oblivious to the user. They don't see anything happening. They don't have to have any interaction at all. So there are a lot of different options there for you.

Heidi: Excellent. When uninstalling SMS from a client, on occasion I notice that some of the registry keys have restricted security permissions set, even for the local admin. When attempting to delete these keys, the permissions prevent me from doing so. Do you know of this problem? Is it something that I'm experiencing or is it a known problem?

Wally: Well, it's not a problem; it's the way the SMS client infrastructure works. The only key I've ever seen have restrictions on it so an admin can't delete it is because of Remote Control. Local users have the ability to set their own Remote Control permissions, so because of that, admins aren't allowed to modify the registry key that allows users to set their Remote Control permissions. Now users don't go to the registry to set these permissions, they use the Remote Control program from Control Panel to set those, but they do have a special key for their locally designated parameters, and that is why admins have restricted permission to that.

So all you have to do to remove that is go to the permissions for the SMS client key, and say "Administrator has full control." Then replicate that through all the different subkeys and you'll be able to delete just fine.

Heidi: Can you step through a client upgrade after SP installation?

Wally: Basically, you would update your site and that would upgrade all of your site systems appropriately. It will upgrade your CAPs and your logon points. You don't have to do anything at all on your client. Then the next time CCIM runs its maintenance cycle, it will look at the CAP, it will look at the components that should be installed, and see that they're a later version than what the local client already is. Then CCIM will kick off an upgrade of all those components automatically. So you won't have to do a thing. You upgrade your site, let all your site components get upgraded, in this case your CAPs, and then just let the clients stay running. Within the day, all your clients should be upgraded to Service Pack 3, in this case.

If you want to do logon processing, then you won't kick off an upgrade from logon. We talked about that in the SP2 WebCast. It will kick off an upgrade from the logon process, and then it'll bail out, so it'll find out the logon point is SP3 and the client is SP2, and it will know they shouldn't mix. It'll then wait and let the client perform its normal CCI maintenance cycle off the CAP, which should be upgraded to SP3, and then it'll let the CAP do the upgrade.

Heidi: Next in line. We have software distribution agents configured to check for packages every 60 minutes. Is there any possibility that a client would take more than 60 minutes to pick up the advertisement and package, for example 120 minutes?

Wally: Sure. It could be. By default users have the ability to change that parameter locally, so even though you may have set that to 60 minutes at the site end, unless you've restricted users from changing that parameter, they can go to their local SMS monitor and Control Panel monitor programs and change that parameter to whatever they want. So they may change it to 120.

It's also possible that some of the other client components got stopped, and so you need to wait until the SMS client components get restarted, and then detect that they should be checking software distribution now. It could be that the CAP was not available when they tried to connect; so maybe there's a security issue at the CAP, or the CAP hit its number of NT sessions, or Net BIOS sessions. Maybe there was a connectivity issue between the client and the client access point itself.

There are a lot of different issues that could prevent a client from picking up that advertisement right at 60 minutes. It's also 60 minutes from the last time it checked. So you may have just enabled or created the new advertise program. Maybe a client just had its 60 minute cycle, so its going to be another 59 minutes before it checks. But if it's taking longer than that, then I would look at connectivity issues, security issues, and check to see if the client has changed any of its local parameters for that process.

Heidi: In the SMS Administrator's Guide, I've seen a few somewhat vague comments stating that various client configuration choices should be set prior to enabling discovery and installation methods, because they can't be easily changed afterwards. Are you familiar with this, and can you clarify further? For example, which settings is this true for? Why can't they be changed later?

Wally: The only one I can think of off the top of my head is Remote Control. On your Remote Tools Client Agent, the last tab is called the Advanced tab. The Advanced tab deals with your hardware. The Admin Guide, and also the client agent itself in the Administrator console, tells you to make sure you set the Advanced tab before you enable the agent, which means before you get this agent installed in your client. The reason for that, is after the client agent is installed, we don't go back through this process, which is called hardware munging, after that installation.

Now you can force that to occur. So if you go back and say, "I didn't have acceleration enabled. I want acceleration enabled," which is done on the Advanced tab, you could change that and you could then force your clients to go through this hardware munging process. It's a command-line utility and you could run that.

That's the only one I can think of. Everything else you change, and CCIM will pick up those changes at its next interval.

Heidi: Okay, next in line. I find that when I create a sub-collection for distributing software, after sending the package, if I remove a client from the sub-collection, that client is removed from the All-Systems collection, and doesn't seem to return until SMS does a new inventory. Is there a way around this?

Wally: If you delete a resource from any collection, you're deleting it from the entire SMS database. So it's working exactly the way we expect it to. If you go into any one of your sub-collections or an existing parent collection, and you delete a resource, the resource is deleted from the database. You just wiped out all the discovery data, you wiped out all the inventory data, all the data associated with that client, from the SMS database. Now you did nothing to the client itself. SMS, the site end, just doesn't know about it anymore.

I don't like that you said the next time you do inventory it reappears, because that means that you have the inventory process creating DDRs, which is not what you want. You want to have Heartbeat Discovery or Logon Discovery create your DDRs. But the next time you have a DDR created, whether it's from inventory or from some other method, it reappears. That's the way it works. So don't delete clients from collections because you are going to delete them from all collections. I don't know how you're getting those clients in your collection, but if you delete a resource from a collection, you're deleting it from the SMS site database.

Heidi: If we're using NDS logon points, why do I see bindery connection in the SMS section of my registry?

Wally: You see that in all sites. If I go look at my site, I probably have bindery, as well as NDS paths there. When you enable the appropriate methods, SMS writes that information to the registry, just so it knows about it. You're probably referring to the Now key. If you go to Now, and then go to Providers, you'll see it. I see it in mine and I don't have any NetWare methods enabled at all. I see NWNDS, I see NWBIND, as well as MSNWNET for Microsoft Windows Networking. You see those in the Now key so that SMS knows how to address those if you enable those methods.

Heidi: Next in line, What is DDR flooding?

Wally: DDR flooding is the process of a user logging on to the network, creating a discovery record, and that discovery record being replicated throughout your entire infrastructure. It occurred quite a bit in RTM code in SP1. SP2 still has DDR forwarding, but you shouldn't be flooding because we're not randomly passing that DDR everywhere as we were in prior releases. So we're much more intelligent now. We're picking and choosing what sites to send the DDR to, so it's not flooding anymore, but we still do replicate that to maybe more than one site.

Heidi: Is there any way to keep the Logon Point Installation from being installed on a specific DC when you turn on Logon Discovery?

Wally: Not internally within the code itself, because when you enable Logon Discovery or Logon Client Installation for a domain, SMS 2.0 takes all the domain controllers it can find and sets them up as logon points. Now, if you know what the requirements are for a logon point, then if one of those requirements is not satisfied, obviously we can't install SMS on that because the domain controller was not set up as a logon point. However, you'd be getting error messages in your log files, you'd be getting status messages indicating it couldn't be set up. So realistically, no. Unless you want to do some sort of a workaround, where you're moving security permissions, or you're moving drives, or you're chewing up disk space, then no. SMS is going to take all the DCs. If it can't access one, it's going to report that in log files and status messages.

Heidi: The last question of the day is, What is your recommendation regarding allowing or disallowing SMS client installation on a PDC and BDC?

Wally: Most people think it's fine and there are many advantages to that. The advantage of making or allowing your domain controllers to become SMS clients is, if you want to take Hardware Inventory so you can bond it to your disk space, Hardware Inventory can do that for you. If you want to use Remote Control to modify a registry key, or to troubleshoot some problem, you can do that. You have software distribution installed, so you can push out service pack updates without having to go to the box and physically launching the install program. So there are a lot of advantages to having all of your servers, whether they're SMS related or not, become SMS clients. Because you have the ability to do the inventory, you can do the Remote Controls, you can do the software distribution, run utilities, kick off virus scanners, whatever you want.

Now in some environments, I mentioned that the IT people don't like anything outside their control touching their DCs. So in that environment, they either don't use the domain controllers for Logon Discovery or Logon Client Installation, they set up a resource domain and use those for the clients, or they use that registry key we mentioned earlier to prevent SMS from pushing out the client software. You're missing out on those other features, but you do have that ability if you want.

Heidi: With that question answered, we have cleared the queue of all the questions that were submitted during today's broadcast. I want to thank all of you again for joining us today. I hope you found the content valuable, and have an opportunity to join us again in the near future. Thanks so much and have a great day. Goodbye.