Do you find the Support WebCast transcripts helpful?
Let us know!

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

Wally Mead: One of my tasks as a Program Manager in the SMS Product Group is to monitor the various newsgroups, forums, and aliases for SMS-related topics. When monitoring these customer resource areas, one of the most common requests I see is the request for assistance with installing Microsoft® Systems Management Server (SMS) client.

Oftentimes this is simply a request for how to; in other words, information. I don't understand how to do this; I don't understand what the procedure is. Other times, however, it is a request to figure out exactly why a client cannot be installed properly. You know the procedure, you know how to install a client, you attempt to install a client, and for whatever reason the client does not install properly, so there are some questions from the user about how to figure out what's wrong with the client.

This session is a response to these requests, so what we're going to do is we're going to discuss the process of installing an SMS 2.0 client computer. Then we'll discuss various problems that we've encountered with customers talking to Product Support, monitoring the newsgroups, talking to people at conventions and shows, like the Microsoft Management Summit last week, just talking to people and finding out what problems they are experiencing. We'll talk about some of those issues in this session.

What we're going to cover in today's session is first off we'll look at the process, a quick overview of the discovery, assignment, and client installation process (slide 2). We'll just do a quick recap of what that process entails. Then we'll branch off and talk for a couple more minutes on the discovery methods that SMS 2.0 has that allow you to discover potential client computers. We'll then spend some time talking about the SMS assignment process and how important that is to the process of getting clients installed and how you can assign client to an SMS site. Then we'll send a little bit of time going through the SMS installation process, so how exactly does SMS install its client software on a client computer? What is the process that it goes through?

Once we've got all that background information handled, then we'll branch off into specific troubleshooting things. We'll look at the different problems that customers have reported, that people have run into that I've heard about, whatever, just some of the most common scenarios or areas that customers have problems with getting SMS installed.

Now you might think the first half of the presentation is going to be worthless, just talking about process, but in actuality, like I said, a lot of the questions we see on the newsgroups, alias, and forums are related to how to get this installation of SMS Client accomplished properly.

Part of the troubleshooting process in any different scenario, is understanding the flow of how the process is going to be started, how it's going to proceed, and then how it has to go through to the completion phase. You'll actually learn a lot of troubleshooting information just by going through the first part of the presentation on discovery, assignment, and then client installation. We will end up the presentation with talking about some specific areas of difficulty that people run into.

The last thing we'll talk about are a couple of slides where we'll discuss client deinstallation (removal). If you've got a client installed, and for whatever reason you decide you don't want it to be an SMS 2.0 client anymore, how do you deinstall that client? More appropriately and importantly is when you have deinstalled the client, how do you go about cleaning up the residuals that are left on the computer after the deinstallation process?

Let's start off with the discovery, assignment, and client installation process (slide 3). One of the reasons people have had difficulties in installing SMS clients is they don't completely understand the entire process of client installation. We'll start off with a real quick overview of the discovery, assignment, and client installation process. If you can just look at the slide, and you see a logon point, you see a CAP, you see a client, and a few other things.

Initially, just look at the client and this is assuming Windows® Networking Logon Discovery is enabled and Windows Networking Logon Client Installation are enabled and I'll discuss those a little bit later on throughout the presentation.

The scenario is the user logs on and as part of the logon process they get validated by a domain controller. That domain controller has to be configured as an SMS 2.0 logon point. In this scenario, we're using the SMS logon script so the user logs on, gets validated, and from the logon point the Smsls.bat file is run. That process runs on the client computer and during that process we perform another function called discovery. The discovery process runs internally at the client computer. The major reason for that discovery process or what we really need to get out of that discovery process is the IT subnet that the client is a member of.

In this case, it shows an IP subnet of 192.168.30.0 right below the client. If Windows Networking Logon Discovery is enabled, which in our case it is, the client will do its discovery process and it will send a DDR (discovery data record) over to the logon point. That's the little box with the DDR on it over by the logon point on the left side of the arrow. That reports to the SMS site that this client has been discovered and also reports some basic discovery information about this client: computer name, IP address, IP subnet, operating system, domain that the computer is a member of, and so on. That DDR is then sent from the logon point to the site server for the appropriate site and then processed in the site database and now the site knows about this computer, so that's the discovery process.

Again, as part of that discovery process, if you want to do a client installation you have to go through a process called assignment. Assignment is validating that the client belongs to an SMS site. During the discovery process, we find the client's IP subnet, in this case 192.168.30.0. The client will then validate that assignment list with the list of subnets for its site on the logon point. Clear on the left-hand side of the slide you see an assignment list and it lists three different subnets. In this case, 192.168.30.0 happens to be within that assignment list, so the client has been assigned to this SMS site.

The next step in the process, after validating is you're assigned to the site, the actual installation process. At this point in the process, the client will find a client access point or CAP (which is sitting right next to the logon point in our picture) to install from. It will pick a CAP; it will start downloading and installing the SMS client software. We'll go through a number of different iterations there to get the complete client installed from the logon point and the CAP, but eventually your client will become installed as an SMS client.

Really quickly, again, the basics of the process are, we're starting with the Smsls.bat file, which is just one of the methods of starting, but we'll talk about other methods. We perform discovery; we generate a DDR. Then we do assignment to verify we are assigned to the site boundaries. If so, then we go through the installation process of the client computer.

Why are there three separate tasks in the process of installing an SMS client? Discovery, assignment, and client installation are three separate processes and each performs a unique task (slide 4).

Discovery is there to find potential resources. It doesn't mean everything discovered can or will become an SMS client. For example, we have discovery methods we'll talk about later on that can discover user accounts, user group accounts, or routers on your network and, certainly, they can't become SMS clients. In this context, what we're talking about discovery is to find resources that could be installed as SMS client although there are discovery methods to find additional resources.

Assignment is the process that validates that the resource that has been discovered really should become part of that SMS site. So it looks for system resources that are within the site boundaries; if it is a system resource and it is within the site boundaries, and a valid operating system, then we can attempt to install the SMS client software.

The last step in the process is client installation. This is the process that installs the SMS client software or infrastructure on assigned system resources. When you've determined that the resource is a system resource, a computer-type resource, and it is within your site boundaries, you can then attempt the client installation process. I say attempt because you may not be successful, as we'll talk about during this WebCast.

Again, the example in a previous slide was using Windows Networking Logon Discovery, and Windows Networking Logon Client Installation. The Windows Networking Logon Discovery is what caused the DDR to be generated and sent from the client over to the logon point itself, and then passed on to the site server and processed into the database. Windows Networking Logon Client Installation is the process that did the assignment of the client, as well as attempting to install the SMS client software.

Discovery is not required for client installation, so you can install client computers without having to use Windows Networking Logon Discovery as a discovery method or any other discovery method to be enabled when you initially install your client. You just go through a process of finding the client, picking out the installation somehow, whether it's a manual process, whether it's a logon script process, or whether it's a site-initiated installation.

Even if you have not enabled Windows Networking Logon Discovery, technically, we do perform a discovery process that's run internally. We have to figure out what subnet the client is a member of in order to determine whether or not it is within the site boundaries of the site. Internally, we do a discovery process regardless of whether or not you've initiated a discovery process per se at your site.

If discovery, in this case Windows Networking Logon Discovery, is not enabled it will still run the discovery process on the client. But it just won't generate a DDR and send that DDR across the wire from the client to the logon point, from the logon point to the site server, and process into the database. We have to run the discovery process, however, to see whether or not we have data that we can use for assignment to determine whether or not the client belongs to the site.

Each discovery process or discovery method and installation method for clients can be enabled or disabled as appropriate. You can pick and choose what's appropriate for your environment, whether or not you want to use Windows Networking Logon Discovery, whether or not you want to use Windows Networking Logon Client Installation, and that's a process that you can control on your own.

The first of these three phases we'll talk about in a little more detail in discovery assignment installation is discovery (slide 6). Let's go through and talk about some of the various SMS discovery methods. I'm not going to go into great details on some of these methods, I'm just going to introduce a few of them to you to give you ideas that there are a lot of different discovery methods available for SMS. Again, were talking about SMS 2.0, because SMS 2003 has different methods.

I've broken the different discovery methods into two different categories. The first category is discovery methods used that are available for client computers. What are the methods available to discover potential SMS clients? That would be Windows Networking Logon Discovery, it would be Network Discovery, and it would be Heartbeat Discovery. I've got slides about each of those coming up in the next three slides.

Then we have methods that are used to discover other types of resources. In other words, non-potential clients, and those would be Windows NT® Server Discovery. Windows NT Server Discovery is used to find your SMS servers and make sure that your SMS servers have been discovered and are maintained in your database. This information is important for you, so that you can generate a process called a network trace.

SMS has a process in the Admin Console where you can draw a map of your SMS servers, what roles those servers play for you or perform in the SMS environment, and where they sit within your infrastructure. In order to perform those functions, we need to have discovery information, so the Windows NT Server Discovery Agent is used to discover your SMS server computers and keep them updated in the database.

The next discovery method, actually is two discovery methods, is Windows NT User Discovery and Windows NT User Group Discovery. These two discovery methods are used to generate discovery data for user accounts and user group accounts from a domain environment, which could also be an Active Directory® environment, just using Windows NT domain calls as opposed to Active Directory LDAP calls to find user account and user group resources.

This is good information for software distribution. When you've got the users or user groups discovered, you can target advertisements to collections that are based off of User Discovery data or User Group Discovery data.

The last discovery method is actually one that fits in both different categories and that's Network Discovery. Network Discovery has the potential for being the widest ranging or the most consuming of your discovery methods. It can find potential SMS clients, as well as additional resources that can't be SMS clients on your network. I'll talk about Network Discovery in a slide coming up a little bit later on.

Now I have not listed on this slide (or in this presentation at all) the fact that there are compatible NetWare discovery methods, NetWare client installation methods, as well as the Windows Networking. So as a general rule, not always the case, but as a general rule whenever you see in a slide or here we talk about Windows Networking something, Windows Networking Logon Discovery, Windows Networking Logon Client Installation, there's generally a NetWare-compatible method and NetWare Bindery, NetWare NDS, which we do support in SMS 2.0. I'm not going to talk about those in the presentation. If you do have a NetWare environment you need to integrate with, we do have methods for you to discover NetWare resources, as well as to install your network clients.

Let's go through quickly the three different discovery methods we talked about for discovering client (slide 7). The one most commonly used is Windows Networking Logon Discovery. In this environment (at your site server) you enable Windows Networking Logon Discovery, which generates SMS site systems called logon points. Logon points are basically your domain controllers that we set up for a special purpose in SMS.

You can choose whether or not you want logon scripts to be modified. If you do choose to do so, when the user logs on to the client computer, they run the Smsls.bat file, a discovery process runs in the client computer internally, the client generates a discovery record, passes that discovery record over to the logon point, the logon point then passes that discovery record over to the site server, which then processes that into your site database.

You do need to be careful about using this method when you have a large number of clients, as well as a large number of sites in the hierarchy. What this method does is every single time a user logs on it's going to generate a discovery record for that client that the user logged on as.

If you have an environment where users log on, log off a couple of different times a day, maybe in the morning they log on, at lunch time they log off, and log back on after lunch, and then at the end of the day they log off, you might be generating two DDRs for every single client. That may not sound like a lot, but when you have tens of thousands of clients and you're generating that amount of discovery traffic on a daily basis there is a lot of traffic that's going to be generated. Remember that your discovery records get forwarded up to the site server and, if you are a child site, your discovery data is forwarded to your parent SMS site.

So think about a scenario where you might have an environment where you have 100 SMS sites all running Windows Networking Logon Discovery and each one of those hundreds of sites has, let's say, 10,000 clients, that's going to be a lot of discovery records that need to be processed by the central site server every single time users log on and log off. Basically it's a logon process, because all of those discovery records are going to be forwarded up to the parent site, which will eventually get to the central site, you've got to process the discovery data for every single site in the hierarchy. That's a lot of traffic, so oftentimes you'll see that people will not enable Windows Networking Logon Discovery or they may have it on for a period of time just to find SMS clients or computers that could be SMS clients, and then they'll turn off discovery when they get their clients installed. That's something you may want to do if you choose to use this method for a period of time, you may want to turn it off later on.

The next discovery process we'll talk about is Network Discovery (slide 8). As I mentioned, this has the potential for finding the largest quantity of resource on the network, as it includes not only client computers, but also any other IP resource such as routers, hubs, network printers, and IP subnets, which aren't physically a resource, but we do discover that as well.

With that said, Network Discovery also has some requirements in how it operates and what it needs to discover about a resource in order to create discovery records. What we need to have accomplished is, we need to discover for each potential resource, not only their IP address, but also their subnet mask. We need the IP address and subnet mask to be able to create a discovery record for that resource.

We only discover these subnet masks through one of three methods. The first method is through a router ARP (Address Resolution Protocol) cache. If you're an infrastructure guy, you may very well know a little bit about routers. If you do, you understand that, in a lot of cases, router ARP caches don't hang around for very long. The information is aged out of router ARP caches fairly quickly. You may only have the information available for Network Discovery for maybe anywhere from 10 minutes up to 30 minutes, maybe an hour, unless you've done some configuration with larger routers, with more memory to cache information longer. So that may not be an option for you or at least not a reliable one.

Your next choice is by using Microsoft DHCP environment. If you're using a Microsoft DHCP environment, we can discover resources from the DHCP address list. We can query the DHCP server, provided we have access to do so, and we'll pull out the IP address and the subnet mask from the DHCP database, because we get the scope information and that includes the subnet mask. That gives us all we need to find the resources on the wire.

Lastly, if you're not using Microsoft DHCP, you're using somebody else's DHCP environment, or you using static addressing, then that won't help you out so your last option then would be SNMP. If you have an SNMP agent installed locally on your client and you configure Network Discovery with the appropriate community name that can be used to access that agent remotely, then you can query that SNMP remotely, asking it for its IP address subnet mask, as well as a bunch of other information. That's the third way you get subnet mask information.

We need either trusted router ARP caches, which age out fairly quickly in a lot of environments; Microsoft DHCP environment, which not everybody is using; or an SNMP agent installed locally, which again not everybody has SNMP agents installed on their resources, so you may not be able to discover them that way. Those are a couple of the idiosyncrasies that Network Discovery has.

We actually did a WebCast dedicated to Network Discovery two to two and a half years ago; I want to say it was like December 2000 off the top of my head. You might want to look at that in the archives if you want more information on it.

The last discovery method that we'll mention is one called Heartbeat Discovery (slide 9). Heartbeat Discovery is one that doesn't really go out and discover your clients initially. What Heartbeat Discovery does for you is it will go out and refresh the discovery data on your clients periodically. You've already got the SMS client software installed, and then Heartbeat Discovery will ensure that those SMS clients update their discovery data to the SMS site on a periodic basis.

The default parameter or default schedule of interval for the Heartbeat Discovery method is weekly. Every seven days the client computer would generate a discovery record and send it from the client up to the client access point directly to its site, which would then forward that discovery record over to the site server to process into the database.

Because this is already an existing client and its data should appear in the database already, it is purely a matter of updating the discovery record in the database with current information, such as the last discovery time. Basically, you're refreshing your discovery data. The purpose for this is that SMS also includes a database maintenance task called the Delete Aged Discovery Data.

That task is used to remove resources from your database that haven't been discovered, updated, or refreshed in a certain period of time. That period of time by default is 90 days. If you haven't updated your discovery data within 90 days, we'll assume that your client or that resource is no long valid and will delete it from your database for you. You want to make sure that it doesn't delete your clients out of the database, because that deletes all the inventory history information for that client as well.

That's where the Heartbeat Discovery method comes into play. It's enabled by default to your site, and again by default it's going to work on a weekly basis. What happens is every 23 hours your client goes through something called a CCIM maintenance cycle. That's done internally at the client. During the CCIM maintenance cycle, the client performs discovery.

After CCIM has accomplished the discovery process, it looks in the registry to see if it's time to generate a Heartbeat Discovery record. If so, it will generate one and forward it to the client access point. If not, it will just state in its log file, Ccim32.log, that it's not time for Heartbeat Discovery and it will just update its local data, but not forward the CCR across the network.

Again, this is really there to keep your resources updated or refreshed in the database so they don't aged out by the automated task. This schedule for Heartbeat Discovery is also used by the Windows NT Server Discovery method as to how often it will go out there and update discovery data for existing SMS servers, logon points, client access points, distribution points, the site server itself, your SQL server, and so on. It's important that you do keep Heartbeat Discovery enabled.

This is one discovery method that every single SMS site should have an enabled and keep enabled. Now you may want to adjust your frequency as to how often you want discovery data generated, but you do want to have this discovery method enabled, because it will only discover from existing clients and it will only discover on that weekly basis whatever schedule you have implemented.

Now that we've discovered discovery in detail, let's spend a minute on assignment (slide 10). This is an absolutely necessary process that must occur before the client will attempt to install the SMS client software. In SMS 2.0, resources are only assigned to SMS sites by IP subnet membership or IPX networks if you're in a Novell environment. The resource must be in the boundaries of the site before it can become assigned to the site and then attempt to install the SMS client software.

One of the difficult things here in handling this process is that, when you go into add a new boundary to your SMS site, you're allowed to add an IP subnet, and you list the IP subnet that you want the client to be signed on. For example, on the slide you see 192.168.20.0, 192.168.30.0, and 192.168.40.0. So those would be three separate IP subnets, however, you're not allowed to enter the client's IP subnet mask. You can only list the IP subnet itself.

The subnet mask is used by the client when the client does its discovery process, it acquires its IP address from the registry, it acquires its subnet mask from the registry, it goes through a TCP/IP process called "ANDing" to "AND" those two together to determine what the IP subnet that the client is a member of. It uses that to compare with the assignment list, which is the Netcomp.ncf file on your logon point during logon processing or off the client access point for the CCIM processing. In that case, it compares the two.

One of the difficult things in processing here is that you don't always know what the client subnet mask is. Oftentimes the administrator will just guess on what he thinks the subnets are, but you may not really be able to tell because you don't know what subnet mask the clients are using, so you really have to specify the IP subnet that the client is using, not what you think is being used.

If you're not sure what to use, then you can just use Windows Networking Logon Discovery, have the clients generate discovery data, part of that discovery data will include their IP subnet, they will forward that across to the site, and then you add those subnets when you get the discovery data into your boundaries or you can just put in whatever subnet you think it is, then when the clients attempt to install, if they fail then it will just generate discovery data, you can look in the client log file and it will tell you what the subnet is. Then you add that subnet to your boundaries for your site.

You add clients to new sites during your installation process or your logon process. When you run Smsls.bat or Smsman, that's when you have the potential for adding clients to new SMS sites. To verify that you are still assigned to your existing SMS site, that's done through the CCIM maintenance process, which occurs every 23 hours by default, every time you restart your computer or every time you click Update Configuration on the Sites tab of the Systems Management Program in Control Panel.

If you do have an environment where you need to force clients or manually assign them to a specific site, there's a resource kit utility called Site4c.exe. This is a utility that you can use. What it does is you run Site4c, specify the site code, and that basically brands that client's assigned site into the registry, and then that client will never deviate from that site. It will always be assigned to that site.

It's really designed for environments where you don't have IP resources that you can assign by, such as NetBEUI environments, but that is something that is a potential as well. It's not something that we normally recommend that you use, but in some circumstances you may have to use that utility.

After the client has been assigned to the site via Smsls.bat or Smsman, it can be installed as an SMS client (slide 11). In this section of the presentation, we'll talk about the various methods of installing SMS clients. We'll introduce the SMS client components. There are different types of components that perform different functions and need to be installed at different times. Then we'll detail the SMS client installation process, how a client computer completes the process of installing the SMS client software.

Then we'll discuss the three different client installation methods. First is Windows Networking Logon client installation, which is the most common client installation method. Next is manual installation, which really is Windows Networking Logon Client Installation, just without the logon script. And then third is the Windows NT Remote Client Installation method, which is where the end user has no interaction at all or they don't initiate the process, the site initiates the process of installing the client. We'll discuss those three different installation methods in upcoming slides.

Before we talk about the process of installing a client computer, let's discuss the various components as they play a part in the installation process. We have the SMS client components broken up into three different categories (slide 12).

The first components are called the base installation and configuration components. Basically, this is the core set of files that are necessary to perform discovery and the basic installation of an SMS client. The biggest file that you'll be aware of, and that you guys are probably all seeing, is Clicore.exe (the Client Core component installation). This is a file that's about 3.5 megabytes (MB) in size; it resides on your logon point. When your client runs the SMS logon script or runs Smsman and they go to the logon point, one of the first things we do is we download Clicore.exe (which is an SMS installer bundle or script) and start running the client installation through the Clicore.exe program. We run Clicore with the series of switches at various points in the installation process to unbundle or install certain components out of Clicore. This includes a bunch of DLLs, discovery files, CCIM32 (which is a client component installation that we discussed a little bit earlier and we'll talk about again), the SMS Client service itself, and then Launch32. We'll discuss some of those files a little bit later on.

The next components that need to be installed are called standard components, and are components that are pretty well installed on each SMS client computer. These two involve Windows Management Instrumentation (WMI), if it's not already installed on the client computer, and the Available Programs Manager or APM. APM is really the core component for software distribution, and the reason we install it as a standard component is that we use APM as the method to install the optional SMS components, which is the last category. This includes hardware and software inventory, software distribution, NT events, SNMP trap translation, remote control, and software metering. These are all enabled through the SMS Administrator console and then installed on your clients, if they have been enabled at your console. You can enable whichever one of those components you want, and then as part of the installation process we will install those optional components.

For either a logon script or manual installation, the installation process proceeds in the following order (slide 13). We'll go through the flow of a client installation now. The first thing we'll kick off is something called the mini bootstrap program. The mini bootstrap program is called Smsboot1, and basically it is used to detect the operating system of the client and your network operating system (NOS). We're trying to find out, is it a Windows-based computer, is it a NetWare-based computer, is it running Microsoft networking, or is it running Novell networking, so looking at the operating system and network operating system of the client.

The next file that we look at is Boot32WN. The file name itself will be dependent on the results that Smsboot1 has generated. In this case we're going to talk about Boot32WN, which is the main bootstrap program, so that's the boot portion, 32 means it's 32 bit, as opposed to 16 bit, and WN is for Windows Networking. In other words, Smsboot1 determined that this was a 32-bit Windows Networking client, so maybe it's a Windows NT 4.0 client, maybe it's a Windows 2000 client, or a Windows XP client, but it determined it was a client running Microsoft networking components and Microsoft Windows and it was 32-bit version of the operating system.

Boot32WN (and there's a compatible version for NetWare and also 16-bit clients), the main bootstrap program will initiate the SMS client discovery, assignment, and installation processes. It will download Clicore, if it needs to, and unbundle it, which is where it will install the client discovery, assignment, and installation components.

It goes ahead and downloads Clicore from the logon point and then unbundles it with the /disk switch, and later on it will be the /full switch, and then the /inst switch. There are different switches that we use at different portions of the installation process to install the various components, depending upon what point in the process you are at.

Basically, Boot32WN or the main bootstrap program will download Clicore, unbundle it, and then it will kick off the discovery process. If installation is enabled, then we'll do assignment and then go through the installation itself.

Again, Clicore is the SMS installer bundle that installs the discovery components, as well as the rest of the core components, such as the client servers and CCIM 32 that are used for installation of the rest of the client itself.

The next slide we have is actually a pictorial format for this installation process (slide 14). Here we'll look at it in a graphical type format. The user is running Smsls.bat, so we're assuming Windows Networking Logon Client Installation, maybe client discovery (but that's immaterial here), and the client installation with logon scripts enabled. I run Smsls.bat, it runs the mini bootstrap program, which is Smsboot1. We determine the OS and the NOS (the operating system and the network operating system). We determine those and we launch off (start) or copy the main bootstrap program.

In this case, we're assuming it's a 32-bit Windows client so we launch off Boot32WN. When it runs, it goes ahead and checks the Clicore version, in other words it checks to see if there's Clicore already downloaded on the client and whether it's a current version or not. If it's not or the logon point has an updated version, it will copy that down and then it goes ahead and kicks off Clicore with one of the appropriate switches, in this case it would be /disc for discovery.

Clicore will then run. If you're looking at Task Manager, you'll see a temp file being enabled, so you might see Clicore, and then you'll see something like Clnnn.tmp file. That's Clicore unbundling running as an installation process.

This we'll install the discovery files as well as some other files. It will install the discovery files and two of those files are Cliex32 and SMSDiscv.dll. Those are the files that handle the discovery process itself. One of them does the actual discovery and the other one processes the discovery data.

This will generate a discovery record, possibly through Logon Discovery or through Heartbeat Discovery, but it will generate discovery data. If you have discovery that needs to be sent to the client access point, that will be called Heartbeat Discovery (that is part of your initial installation) and we'll generate that, but at this point in time this would be Logon Discovery.

If we have client installation enabled so Windows Networking Logon Client Installation has been enabled at the site, after we do discovery we'll go through the process for assignment. Cliex32 will also perform the client assignment process, so it will go back to the logon point and look at the Netconf.ncf file which is the assignment list on the logon point to validate whether or not the client's IP subnet that was just discovered through its discovery process, is assigned to the SMS site. If so, it will proceed with the installation.

If the client is not within the assignment list or the Netcomp.ncf file on the logon point, it will abort the process at this point in time and will mark in its log file (in this case it would be WN_logon.log for Windows Networking Logon) that the client is not assigned and the process is aborted.

If the client is assigned, then we'll run Clicore again, this time unbundling more of the client components for an installation. We'll install the base files, which include the SMS Client service. Once the SMS Client service is installed, we'll install CCIM as part of the Client service, so it will go ahead and launch CCIM.

CCIM then is responsible for validating discovery, so it will perform a discovery process, it will verify that you're assigned to the site, it will generate Heartbeat Discovery and send in your initial discovery record, because you won't have performed Heartbeat Discovery yet. Then it will look at the client access point for other components to install. It will read the .cfg files on the CAP to determine what components need to be installed. It will kick off the installation of WMI, if WMI has not already been installed. It will kick off the installation of the Available Programs Manager. It will then kick off the installation of any of the optional SMS client components that may have been enabled at your site.

CCIM will install WMI, if it hasn't already been installed with a current or later version. It will install the Available Programs Manager, which is called Apasetup. When it has APM installed, it will then detect what optional components are installed, it will detect those that need to be installed, it will hand off those installation routines to APM, and have APM do the actual installation of the optional components. We're doing this portion of the installation with the client access point itself. At that point, once you've been able to contact the CAP and started installing your client components, you should be able to complete the installation process successfully.

Now let's look at the three different installation processes, and then we'll talk about some troubleshooting information (slide 15). The most common of the client installation methods is the Windows Networking Logon Client Installation Method. In this method, the administrator gets to specify which domains to use for client installation. This takes the domain controllers in those domains that have been enabled and sets them up as SMS logon points.

SMS will automatically set up all domain controllers in their specified domains as logon points. You don't get to pick and choose which domain controllers you want to use for SMS logon points in the Windows Networking Logon Client Installation or Logon Discovery method, and we take them all. In the discovery methods, you do have a little more control over that for NetWare. The NetWare methods do give you a little more control over which servers to use as logon points, but not Windows Networking, in which you take all the domain controllers.

You get to specify whether or not you want to modify logon scripts. If you do specify to modify logon scripts then what we'll do is we'll modify the existing user logon script if there is one, and have it call the SMS logon script, which is Smsls.bat. If there isn't already a logon script, we'll specify Smsls.bat as your logon script to kick of the logon installation process.

This is not a requirement; you can install clients without using the logon script, although a lot of people do use our logon script. An additional note, and we'll talk about this in more detail in upcoming slides, is that Windows NT and later clients may require the Client Configuration Manager, which is a site server component, to help with the installation.

SMS requires administrative rights on the client to perform the installation. If the logged on user is not a local administrator, which is oftentimes the case, then SMS can't install natively. We'll need the assistance of the site server to push out the SMS client installation to that client computer with administrative rights, and that's called NT Push. It's kind of like the nickname for this method and we'll talk about this method in a couple more slides, it's called the Windows NT Remote Client Installation Method. The key is that we do require logon points and we require administrative rights to install through Windows Networking Logon Client Installation.

Another method that's very similar to Windows Networking Logon Client Installation method is the manual installation process (slide 16). This really is Windows Networking Logon Client Installation; it's just without using the Smsls batch file. In order to perform a manual installation with SMS 2.0, you do have to enable Windows Networking Logon Client Installation. You just don't need to specify that you want SMS to modify the logon scripts. We do need to have logon points for SMS, and essentially what the user would do is connect to a logon point and then run the installation program, the SMS Wizard, manually.

Now I say connect to a logon point; you could run this from any other media you want to. You could e-mail the Smsman program for 32-bit clients out to the users; it's about 450 KB, somewhere in there, maybe it's 470 KB. You could post the utility on a Web site and just have them go to the Web site and click the link. You could put it in your own logon script if you want to, but whatever the method is, Windows 2000 includes it on the Windows 2000 media itself, so the Smsman program is on its compact disc.

Whatever the method of finding the program, the user just launches off the utility (Smsman16 for 16-bit clients or Smsman for 32-bit clients), and it will proceed as if you're running the logon script. Smsman or the manual installation process runs almost identically to the Smsls.bat file method. One of the differences between Smsls.bat and Smsman for installation is that Smsls.bat will check and see if you're running Terminal Services. If you are, it will abort the installation, because the batch file will not let you install through the batch file if you have Terminal Services enabled, because you may have different sessions running.

The batch file will also perform a slow link check. It will check to see if your connection from your client to your logon point is at least 40 Kbps. If so, it will proceed with the installation. If it's not, it will abort saying it's a slow link and you can modify the speed that's considered to be a slow link inside the Smsls.bat file. We do document that in the release notes on how to modify the Smsls.bat to change the slow link speed detection for logon processing.

Outside of that, Smsman does essentially the same process as Smsls.bat. It basically runs a mini bootstrap program. It determines your operating system and your network operating system. It goes ahead and launches off the main bootstrap program, Boot32WN, in our case, and then goes ahead and unbundles Clicore and runs discovery. If you're assigned and if client installation is turned on, it will do an assignment. If you're assigned, it will kick off the installation from the Clicore, then from the CAP, just like you would through the log scripts. In essence, the only two differences are no slow link speed detection and no Terminal Services detection.

The last client installation method is the Windows NT Remote Client Installation or what we call the NT Push Method (slide 17). This is used in a couple of different cases. The first case is the one I just talked about, where you are trying to install your client either through a logon script or through Smsman, your logged on user is not a local administrator, and the SMS site server needs to be involved with installation.

The second method is where you don't enable Windows Networking Logon Client Installation, but rather you enable Windows NT Remote Client Installation itself, configure an appropriate account to use to connect to the clients, and then perform a discovery method. After discovery, the site server will scan the discovery data that was gathered by any discovery method, whether it's Windows Networking Logon Discovery or Network Discovery, and it looks for discovery data for system resources that either we don't know the operating system or the reported operating system is Windows NT 4.0 and later, and that they're newly assigned to the site. In other words, it is a new system resource that either we don't know the OS at all or the OS is reported as NT 4.0 or later, and it is assigned to your site. Then we'll generate something called a CCR (Client Configuration Request), and this is done by the DDM (Discovery Data Manager). It will generate the CCR, hand it off to the Client Configuration Manager, which will then attempt to push out the SMS client installation to the client computers.

This process requires an administrative account for connection to the target computer. We're trying to connect to Admin$ on the client computer, so we need to have an administrative account. By default, if you don't change anything, you would attempt to use your SMS service account. Your SMS service account is a domain administrator account by default, so as a domain administrator you would, by default, be a local administrator on your Windows NT and later clients because domain admin is a member of local administrators by default on Windows NT and later clients.

If that's been modified, you may have to do some changing in how this process works. Basically, again, we connect to the clients, so it would require an admin account and what that means is that your client computers are required to have file sharing enabled. In other words the Server service must be running on these computers in order for us to connect to the Admin$ share, connect to the registry and be able to push out the installation process. Not only do we need an administrative account to use to connect to the client to push out the install, we also have to have the Client Server service running in order to complete this process.

What we do is we connect to Admin$ and then we install a Bootstrap service, which creates a special account, and it will install Clicore from the client access point, the SMS Client service, and then kick off CCIM to complete the rest of the process. We do need admin rights, as well as the Server service running.

Whether you're enabling this method and using it as your installation method, or whether you've used the manual or logon script installation method and your logged on users aren't local administrators, we use this method.

Again, by default it's the SMS Service Account, if you don't want to use your SMS Service Account, then you can go to your Site properties in 2.0. In SMS 2.0, you go to the Site properties and go to the Accounts tab and you can specify SMS remote and NT remote client installation accounts, and you can specify a list of accounts that you can use to push the client installation down to your clients when you're using this method.

Let's quickly run through the various SMS client components and what they do before we turn our attention to troubleshooting (slide 18). The SMS Client service is the main process of the SMS client itself. It runs under the user context of the SMS CliSvc (Client service) account, so it runs under that user context. It's a core component of the SMS client. It runs all the administrative mode SMS client processes, such as checking for software distribution targets to the client computer, running hardware inventory, running software inventory, and so on.

It has a couple of other components; one of them is Launch32. Launch32 runs the user-mode client processes, such as software metering or looking for advertised programs that are targeted to the logged on user or user groups that the logged on user is a member of.

The SMS Client service also includes the Client Component Installation Manger or CCIM. This process wakes up on a 23-hour cycle or whenever you click the Update Configuration button on the Sites tab of the Systems Management program in Control Panel or when you restart the SMS Client service (such as when you restart the computer).

It checks for optional SMS client components to install, deinstall (remove), or upgrade from SP4 to SP5 when it becomes available to configure, such as changing the interval of hardware/software inventory and to verify. Every 30 days, plus a little randomized offset, we verify the components to make sure that they're installed properly, so that's the verify process. It performs Heartbeat Discovery, so every cycle that it does a discovery process, it verifies whether or not it's time to do a Heartbeat Discovery. If so, it reports the Heartbeat Discovery data.

If verifies that you're assigned to the current site. So CCIM does not assign you to any new sites, it just verifies you're assigned to the existing site. If you're not assigned to the existing site, it will deinstall you from the existing site. If you're not assigned to any SMS site, it will deinstall the SMS client components automatically.

If your client cannot find a client access point in any SMS site for a period of 60 days, it will automatically deinstall the SMS client as well. It assumes it's orphaned if it can't find any CAPs for any of its assigned sites; so as an orphan, it will hang around for 60 days looking for access to a CAP in one of its installed sites. If not, then it goes ahead and deinstalls automatically. These are the core and base installation configuration components we talked about before.

Then for your standard components, you have Windows Management Instrumentation, which SMS 2.0 requires to be installed in all 32-bit clients (slide 19). It's required primarily for hardware inventory, because we use WMI to gather the inventory data with hardware inventory. It's installed with SMS unless you already have the same version or a later version installed on your client computer. We don't reinstall an old version on top of a later version.

The version of WMI the SMS installs is version 1.1. You can't tell SMS 2.0 to install a later version of WMI as part of its installation process. You can install the client then use SMS to push out a later version of WMI, just like you would any other program. The installation itself is going to install WMI 1.1. Then as far as the standard components go, it will install the Available Programs Manager. This is the core piece of software distribution that is used to install the optional SMS client components (we'll talk about them in the next slide), and then it's also used to verify and upgrade components on your 30-day verify cycle.

Finally, we have the optional SMS client components (slide 20). This is hardware inventory on Windows NT and later. It runs as the Hardware Inventory Agent service using the Local System account, not the SMS Client Token Account anymore; software inventory for scanning files in your hard drive; software distribution, which is an add-on to APM; this allows clients to receive advertised programs, not specifically SMS client components; remote control, which installs a new agent or a new service, the SMS Remote Control Agent service, which runs under local system; software metering, which really not too many people use in SMS 2.0, but it runs under the user context; and then the Event SNMP Trap Translator, which doesn't really have any executables, it just has registry hooks to perform event logging to take NT events and turn them into SNMP traps.

We've already discussed a lot of troubleshooting steps and information just by covering the process of client discovery, assignment, and installation. I'm sure you found some things in there that helped you in your troubleshooting of client installation (slide 21). If by knowing the process, by knowing what the different methods do, by knowing what the different rights and requirements are, that will help you in your work with SMS clients and their installation.

Now for these next four slides, let's talk about troubleshooting client installation, so we'll focus on specific areas of problems that users have reported or that we've seen internally or on newsgroups and so on.

The first one is no client installation method is enabled. This one is not as common anymore as it used to be when SMS 2.0 first came out. But when SMS 2.0 first came out what we found is that a lot of times people would enable Windows Networking Logon Discovery, but not enable Windows Networking Logon Client Installation. It really came from SMS 1.2, where there was only a single process. After you found a computer, it became a client.

Here finding clients (discovery) and installing them as clients (client installation), are two different processes. But every once in awhile we still find somebody that fails to enable Windows Networking Logon Client Installation and just did discovery, but you need some method to initiate installation of your client, either Windows Networking Logon Client Installation or the Windows NT Remote Client Installation method; you need one of those two.

If you have Windows 98 or earlier clients then you need to have Windows Networking Logon Client Installation, because NT Push or Windows NT Remote Client Installation does not work for any clients earlier than Windows NT 4.0.

Another thing that's still fairly common is that your client computer is not assigned to your site. You won't install the client components unless you're installed to the site itself. This involves setting your boundaries for your site, so going to your Site properties, clicking the Boundaries tab, and ensuring that you have valid site boundaries listed.

Again, the most common scenario here is that, by default, SMS only adds the site server's IP subnet to the list of site boundaries. Oftentimes, especially in large sites, your site server will not be on the same subnet with your clients.

Now in a remote location, such as a secondary site, where you only have a single server and a handful of clients, you may very well be on the same subnet, but in a lot of locations you won't be. You need to ensure that you add the subnets, whether they are IP subnets or IPX networks, that your clients reside on your site boundaries in order for the client to become assigned to a site.

This is still a fairly common process of failing to do so, and even if you do add boundaries, failing to put in proper boundaries, in other words not putting in the boundaries that the clients are really on, because again you're not aware what the subnet mask the client is using. Just really again the client's IP subnet as it discovers it, not what you think the IP subnet is. Having incorrect site boundaries is still a fairly common scenario.

Insufficient disk space in your client computer can be the problem. In order for Clicore to unbundle, it needs 6 MB of free space. After you're past Clicore, the actual installation process itself (of running Smsls.bat or Smsman), requires 25 MB of free disk space; it will check for that. If we don't have the much disk space, we'll abort the installation process and report not enough disk space. If you're using the NT Push method, either you wanted to use it or that the logged on user didn't have administrative rights, CCM when it connects up the client checks for 30 MB of free disk space, so that's the Windows NT Remote Client Installation method or NT Push.

Now client disk space is not that big of an issue in today's environment because most computers you get now you have 20, 40, you have 100 gigabytes (GB) of disk space in your client computer, but a lot of environments still have older client computers sitting around running Windows 95 or Windows 98, and their hard drives may be getting filled because they traditionally might have had fairly small hard drives, so that's something that's fairly common that you need to check on.

The next thing to look at and another set of things to look for is administrative access to Windows NT and later clients (slide 22). As we talked about before, Windows NT and later clients require administrative rights to install the SMS client computer. Window 98 and lower, there is no context of an administrator versus a user, so you don't have to worry about it.

SMS needs one of three different contexts as an administrator in order to install on a Windows NT 4.0 and later client. That would be the logged on user, so either the logged on user needs to be a local administrator (which oftentimes is not the case) or your SMS NT Remote Client Installation account. Note that this could be one of two accounts. It could be an optional account that you would create in your domain, making sure that it is a local administrator on your clients. You also need to designate this as your account to use in the SMS Admin console. It could be your SMS service account (by default, it is a domain admin), which as a domain admin should be local admin on NT and later clients.

Regardless, one of those three accounts has got to be the administrative account, so we connect to the client computers. We also again require the Server service to be running on your client computers. We're finding more and more cases where administrators are turning off the Server service on their computers to try and prevent security vulnerabilities. When you turn off the Server service that prevents SMS from installing the client components, if you have to push it out from the site server. I believe we do require as a support statement the Server service to running in SMS clients, however we specifically do require it and utilize it during client installation. Make sure that you have some administrative account that we can use to install the client, either logged on user or an account that the SMS site server can use to push out to your client computers.

Another source of problems that we've run into is you've implemented some sort of policies that have locked down the client computers to such a degree that SMS cannot do its work. You've implemented some sort of a domain policy in a Windows 2000 environment, or they were older utilities that you could use to lock down your clients. In other words, restricting the ability to log on as a service, restricting the ability to create the user account, restricting the ability to access the Windows directory. By default, the SMS client tries to install wherever your system root or your Windir path is, so you've lock that out so we can't install files there. By default, we go to Winnt or Windows, then go to MS\SMS and create directories there. You've locked down the file system, the directory structure, or the registry. You've set permission there where we can't create the things we need to, to install the client computer. You've just restricted our access to the directory or the files or the registry itself. This includes any kind of operating system policies or NT lockdowns.

Another thing to look at is the TEMP environment variable. We need to have a temporary location where we can unbundle Clicor.exe to install the appropriate discovery or base installation components. We go to the TEMP environment variables to unbundle that. If that path is set to an invalid path or there's no disk space available to unbundle Clicore in that location, we'll fail. You'll see that in your log file for installation, either WN_logon.log, or WNmanual.log, if you're running the Smsman program.

On the next page (slide 23), we'll talk about another very common installation issue, and that is that your client computer does not have appropriate access to your client access point. We start the installation process from a logon point by downloading Clicore and unbundling Clicore from there. However, from there we do the rest of the installation process (after you've done assignment) from your client access point.

We'll download Clicore. We'll perform the assignment process from your logon point. We'll download a list of CAPs from your logon point, but when we've done that, the rest of the client installation process is completed from your client access point itself.

Initially we use your logged on user account, so whatever user account was logged on when the client installation process is run, either through Smsman or through Smsls.bat. What you need to do is ensure that Domain Users for the domain that your logged on user is a member of, is a member of the CAP's Users group.

If your CAP is in a different domain than your user accounts are, by default, your user probably won't have access to the CAP because the CAP's permissions are set to the Users group, which includes domain users for the domain the CAP is a member of. If your CAP is in a resource domain, your accounts are in an accounts domain, your logged on user is not going to have access to that CAP, so you're going to need to make sure that your logged on user is a member of the CAP's Users group. The easy way to do that is to take the Accounts Domain Users and add it to the Users group in the domain that the cap is a member of.

After we've started our installation process in the CAP, we then later switch over to use the SMS Client Connection account. The SMS Client Connection account by default is Smsclient_ and then your three-character site code. We'll use that account, which is an account that we create automatically for you. You can, in certain circumstances, specify what the account name and the password are by using a command-line switch during setup or through a special .ini file called Smsaccountsetup.ini. We switch over to that account and use it to access the CAP.

This account could be locked out in environments where you've reinstalled your SMS site with the same site code, but not deinstalled your clients after you've deinstalled your site. You have your SMS site up and running. You deinstalled your site server, left all your clients alone. You reinstalled your site server with the same site code. In this environment, your clients know the SMS Client Connection account with the original password. Where you reinstalled your site, we created the SMS client account again, so we created a new password for that account. Your clients have an old password, your CAP knows the new password; when your client tries to use that account to access the CAP it's going to eventually lock out that account which will lock out all your clients.

You need to prevent your account from being locked out. The best way to do that is to ensure that you have manually created an administrative SMS Client Connection account. In the Admin console, go to Site settings, go to Connection Accounts, go to Clients, and create a new Windows NT Client Connection Account. You're specifying the account name, you're specifying the password, you have to create this account in your domain, making it a domain user, and then you designate the account in SMS under Connection Accounts Client.

Then if you ever have to reinstall your site, just add that same administrator-created Client Connection account to the new site. Using the same password you had before, your clients will use that account to access your CAP and then from the CAP, you can download the new or original SMS Client Connection account (the default one with the new password) and they can proceed on as if nothing had ever gone on, that you hadn't reinstalled your site.

If your clients do become orphaned because you did reinstall your site with the same service site code, and that caused the account to be re-created with the new password, to unlock your accounts, in other words, "unorphan" your clients, you'd have to unlock the account in the domain and then have your clients run either Smsls.bat or Smsman; that will have them go to the logon point. From the logon point using the logon user account they'll download the appropriate account context and download the new account.

For access account, make sure the account is not locked out; make sure that you haven't changed your CAP permissions. We've had users who have changed their permissions in the CAP, and then just have to make sure that you can connect up. We've also seen where users have run out of server licenses, Windows NT licenses on the server so that you don't have any more licenses available and your client can't connect up.

We're on the last page for troubleshooting (slide 24). A couple more things are shared domain environments, where you have different SMS client versions. In an environment where you have a single domain with multiple SMS sites in the environment, there have been issues with clients being able to install properly.

What happens is that let's say, for example, all your sites are running SP3. Let's say you've got 10 SMS sites in a single domain, all sharing your logon points, and all those sites are running Service Pack 3 of SMS 2.0. One site now decides to upgrade to Service Pack 4. What happens in that environment is that we upgrade your logon points to Service Pack 4. That one site that upgraded to Service Pack 4 obviously is running SP4. That one site that is running Service Pack 4, if they try and install new clients they'll go up to the logon points, which are now upgraded to the Service Pack 4, they'll download SP4 bundles, and they'll install, they'll connect up with the CAP which is SP4, and everybody is happy, client installation completes.

However, on all your other 9 SMS sites which are still running Service Pack 3, the client is going to download Service Pack 4 Clicore from the logon point, try to unbundle it, and then it's going to connect up to the CAP, which is still running Service Pack 3. You can get a mismatched version of SMS client components so your client is not going to be able to install properly and not function properly. You won't be able to install new clients at sites that are down level from the logon point version until you've got your local site upgraded with the same service pack as your logon points.

That's been the problem in the past. What we're doing now with Service Pack 5, is as of Service Pack 5 we don't upgrade your domain controllers, your logon points to the most recent service pack, we keep your logon points at the current service pack level, the lower release, but you upgrade your local sites to let's say Service Pack 5. In this environment, your logon points are still SP4. Then your clients will download SP4 Clicore bundle from the logon point, and that's fine; it installs it. It now connects up to its CAP, which happens to be SP5, for example, and now we'll upgrade the client to SP5 from the client access point.

As we talked about in the WebCast we did in January talking about SP5, there was a hotfix that you may want to install in your environments where you're sharing logon points with different level sites, and that was 811378. So 811378 is a hotfix you may want to install when you're upgrading to Service Pack 5 and when you're in environment where all of your sites are not going to be upgrading to Service Pack 5 at the same time. This will help prevent some of those problems with clients downloading wrong bundles and upgrading logon points and so on.

Another issue again is the Server service needs to be running in the clients that do installation. Those are the most common issues that we've seen from newsgroups, from talking to customers from conferences, and from Product Support. Now we've got two more slides left and those are on deinstallation of a client, then we'll kick it over to Q&A.

Sorry I'm running late, I talk a lot. For our last couple of slides let's talk about removing SMS from a client computer (slide 25). There are many different methods that can be used to initiate a client deinstallation. You can use the Systems Management Installation wizard, which is Smsman. You can run it and then choose the option to remove Systems Management components from the client, and that will kick off the deinstallation process.

You can modify the registry and set a specific client deinstallation registry key on the client computer, then stop and restart the SMS Client service, and that will kick off the deinstallation as well. This is actually what the Systems Management program will do for you: run Smsman and chose the option to remove Systems Management components, and that will actually set that registry key and toggle the Client service.

You can run from the support bundle from the SMS Web site 20CliClean; 20CliClean.bat is in the support bundle and it does a pretty decent job of cleaning your client computer. It just runs a bunch of uninstaller applications for each of the different components that were installed and does some cleaning up. There's also a /scrub switch you can add to that to have it delete your Smscfg.ini file.

Lastly, you can remove the site boundaries that the clients are members of. So if you remove the boundaries that the clients are members of, the next time CCIM does its maintenance cycle it will verify assignment, it will detect that it's no longer assigned to the site, and will deinstall the client components if that's the last site.

No matter which method you use to try and deinstall your client, we don't remove all traces of the SMS Client from the client computer (slide 26). Most of the time, we leave specific traces for specific purposes. The reason for that is that we want to leave traces in case you decide to reinstall your client so that you can attach back to the discovery data still in your database, discovery and inventory data, so you don't have to re-create everything. However, if you're in an environment where you do want to fully clean up your client, there's some deinstallation cleanup you have to go through.

Again, the residue we leave generally is because we want to leave traces of your client so when you reinstall you can attach back to the same records in the database and now have to re-create everything. But if you do want to deinstall everything and remove all traces of SMS, to get rid of the entire footprint, you need to remove some registry keys. You need to remove HKEY_LOCAL_MACHINE\Software\Microsoft\SMS, make sure HKEY_LOCAL_MACHINE\Software\Microsoft\NAL has been removed, check HKEY_LOCAL_MACHINE \Software\Microsoft\Windows\CurrentVersion\Run, and make sure the SMS application launcher is not listed anymore.

You'd want to delete your systemroot or Windir, whatever variable you want to look at, Smscfg.ini file, you'd want to remove the Winnt folder, again systemroot or Windir\Ms\Sms folder, and then remove any profiles that are left around that are related to SMS. You might see SMS CliSvc account, SMS CliTok accounts, or various versions of those. You can delete any of those profiles and that will clean up your client for you.

As a quick summary (slide 27), and then we'll let Otto do some Q&A with the time we have left, computers can be discovered, assigned, and installed as separate and unique processes that are there to perform specific functions. Each process is not necessarily required. You can enable and not enable whatever method you want, as appropriate for your environment. If you want to discover clients you may want to use Windows Networking Logon Discovery. If you don't want that discovery process or that discovery traffic generated, then you may just want to enable Windows Networking Logon Client Installation. If you have solely Windows NT and later clients, you may just want to use the Windows NT Remote Client Installation method and not use domain controllers or SMS logon points at all.

There are numerous different installation methods, as we've discussed, logon script, manual installation, and the NT Push method. The most common installation issues we've encountered are either network related, in other words it can't find a CAP on the network, you haven't been able to resolve your access to a logon point or to a client access point; or they are security related, accounts been locked out, or you've changed your permissions to the CAP or the logon point, or you've locked down your client, so you've set security on your client so we can't update the registry, we can't update the file system, we can't create a new user to logon to the service and so on.

Lastly really has been permissions issues or administrative configuration errors, such as you haven't turned on client installation or you haven't set an administrative account we can use to connect to the client. You haven't set your boundaries correctly on your sites so the clients are assigned to your site. Those are the most common buckets of areas where we've seen installation errors.

At that, I'll kick it over to Otto and let him kick off our Q&A portion.

Otto Cate: Thank you very much, Wally. Before we jump into the Q&A, I just want to share a couple of quick program notes with our listeners. If you would like to have a copy of the PowerPoint® slides, they are available for download now from the Web site, http://support.microsoft.com/webcasts/. Simply click the Past WebCasts link and then click the date of this WebCast. That's also the area where you'll find the on-demand streaming media.

The Q&A portion of the Support WebCast is intended to encourage further discussion of the topic that we address today. In addition, one-on-one product support issues are really outside the scope of what we're able to address, so if you do find that you need some more complex technical assistance, feel free to contact Product Support Services directly and speak to a Support Professional.

The first question: What's the best way to check for client health and integrity, and is there a way to check when hardware inventory last ran successfully?

Wally: Sure. You can check when hardware inventory last ran; you can create a query to do so. If you look at Resource Explorer, which is how you view inventory for a client computer in Workstation Status under Hardware Inventory or I believe that Last Software Scan is how we have it listed in Software Inventory. We report the last date and time the client reported inventory, so that may be one method.

Another method, if you install the Web Reporting Utility from one of the feature packs, it has a dashboard in it. In the dashboard I want to say there's one of the reports in the dashboard that shows you how long it has been since a client has been discovered. Maybe more appropriately is looking at the last time your client was discovered, because it should be reporting discovery data at the outset or at the longest interval according to your Heartbeat Discovery interval, which should be no longer than seven days in most cases. Where hardware inventory or software inventory oftentimes customers have those set to every few weeks or maybe monthly. Discovery data will be a better picture for you for looking at your client's health.

You could also look at the status system. There are a number of status message queries in your SMS site that deal with clients that reported hardware inventory files, clients that reported software inventory files, clients that successfully ran an advertised program. I'd look at some of the built-in status message queries in your status system, because there's a large set of those that are targeted around clients themselves, so looking at that.

In the SMS resource kit, I believe there are some additional tools for looking at the health of clients, but primarily, looking at status and looking at the discovery data, so the Web Reporting Utility will help you out a lot.

Otto: Can the software on a client's computer, with the use of discovery, import software license information into a report to track software licenses?

Wally: No. The discovery data does not report any software that's installed on your client. Discovery is purely, here's the client computer's name, here's its IP address, here's its IP subnet or MAC address, IPX information, operating system, resource domain or workgroup, that type of information.

Now inventory can be used to tell you what applications are installed. We have a couple different methods of doing inventory. If you've installed the latest version of the Web Reporting Utility from one of the feature packs, we have the ability of integrating Add/Remove Programs information for you, so inventorying through hardware inventory of Add/Remove Programs data. That's a very effective way of looking at what applications have been installed.

Software inventory will scan your file system for specific file types and then read the resource headers for those file types. Neither of those reports any kind of licensing information. However, there is a report in the Web Reporting Utility called the EA True-Up Report. The EA True-Up Report is a report that takes all of your software that's been inventoried through Add/Remove Programs and generates in a report that you can then use for licensing. It will tell you how many copies of each of your applications that are installed that are registered with Add/Remove Programs have been installed.

As far as really tracking licenses, that's what software metering does, outside the reporting that the EA True-Up Report gives you with the Add/Remove Programs inventory information.

Otto: In multiple SMS sites, single master NT domain models, what is Microsoft's preferred or supported method of configuring discovery logon and network settings? For instance, is all that discovery done at primary site and not at secondaries?

Wally: Each of your sites will want to do some sort of discovery. Whether it's a primary site or secondary site, that's immaterial. You're probably going to have client computers or other resources installed at that site or at least residing in that location, so you'll want to have some sort of discovery method there.

As to using Logon Discovery, it really depends on how many clients you have and how many sites you have that are sharing that domain. As of Service Pack 2 of SMS 2.0, it got a lot better. Prior to that, every single domain controller that got any DDR forwarded to every single site that was sharing that domain controller, regardless of whether the client really belonged to that site or not. That got to be a lot of extra traffic, but as of SP2 we put some intelligence in that process of forwarding DDRs, so primarily we're only forwarding it to the local site. Then it gets forwarded automatically up to parent sites and so on.

If you're a small enough environment, you don't have that many clients or users don't log off and then log back on that frequently, logon discovery is fine, because you won't have that much DDR traffic, but when you can have hundreds of sites sharing a domain and you have tens of thousands if not larger number of clients then that's a lot of discovery records that are generated on a daily basis that have to be processed by your central site. You probably don't want to use Logon Discovery for that point.

You may want to have it initially to find your clients, then once you've done a pretty good job of finding what resources you have, turn Logon Discovery back off and just rely on client installation and Heartbeat Discovery to maintain your existing resources in the database. That will be your best bet.

As for the use of Network Discovery, which you mentioned, Network Discovery can certainly be used. Again you have those caveats to look at, the Network Discovery requires the subnet mask and we only acquire the subnet mask through router ARP caches, which again don't last very long, they age out fairly quickly. Microsoft DHCP environments, which not everybody is using or you may be using static addressing, or local SNMP agents, which may not be applicable for you. Network Discovery may not get you what you want all the time, so really you want to have Heartbeat Discovery as your key thing after you get your clients installed, rely on Heartbeat Discovery to keep you where you need to be.

Otto: If I'm running Network Discovery and I'm using a small window, will it restart the discovery where it left off?

Wally: Unfortunately, no. Network Discovery does not keep track of where it left off last time, so if it takes an hour to do Network Discovery and you give it a 30-minute window, it's going to abort after 30 minutes, it does not report what it discovered in those 30 minutes, because all DDR creates at the very end of the discovery process, so it will start back up at the beginning at your next scheduled interval, so you need to make sure you give it a wide enough time window to be able to complete the discovery process.

You probably need to run it a couple of times and get kind of a baseline that is taking an hour to an hour and 15 minutes for discovery to complete. Then make sure you give it a window of maybe an hour and 30 minutes to complete. You do want to have a fairly decent time window there, not too long because if the process gets stuck you don't have to just keep looking through and generating excess traffic, but it will not pick up where it left off at the next scheduled time.

Otto: Are there any issues that I should be aware of when moving from NT 4.0 to Active Directory about two months after the rollout of SMS?

Wally: If you are already in a Windows 2000 environment, so after you've already upgraded to Windows 2000 then simply switching from an NT 4.0 domain to an Active Directory environment, no, SMS 2.0 will treat your Active Directory like an NT domain, so it will make the same calls to the Active Directory that it made to the NT 4.0 domain. We won't treat it any differently at all.

Generally, the biggest issues people have are when they're migrating from NT 4.0 up to Windows 2000. There is a series of KB articles, two to three of them anyway, that deal specifically with issues of upgrading to Windows 2000 like the pre-compatible permissions group, differences with DCOM or what default protocol it uses whether it is TCP/IP or named pipes or whatever between NT 4.0 and Windows 2000. There are a few KB articles related to that. Purely going from an NT 4.0 domain to an Active Directory environment, I'm not aware of any issues there. You certainly want to search the Knowledge Base just to see if anything has been reported that I haven't heard of. But I have not heard of anything with that.

Otto: Regarding SMS Trace, currently it's not very useful due to the lack of managing the results of a trace. We're wondering if this is going to change in SMS 2003 so it can be used as a true LAN admin tool rather than just simply something nice to show people. We're wondering also if there's a method available to change, configure, or upgrade this feature currently, before 2003?

Wally: It didn't sound like you're an SMS neophyte if you're in that environment, but actually I didn't mention SMS Trace, which you probably meant to say was Network Trace. Network Trace and SMS Trace are two different things, SMS Trace is a tool used to view log files and Network Trace is the utility built into the Admin Console which is what you're talking about to allow you to draw basically a map of your SMS environment.

In a current time frame that I can talk about, there's nothing that's going to change in the Network Trace environment. It's going to stay with the pretty little picture that you draw of your SMS servers, maybe some routers that are separating your SMS servers, if you've done Network Discovery and discovered some routers. There may be some things in the future to generate some additional information.

I believe there's a version of Visio® that has a Network Discovery feature that has some pretty neat capabilities from what I understand. I've never used it, but that might be something to look at. Visio Network Equipment or something like that, I forget what it's called, but there is a version of Visio that has some pretty decent Network Discovery components, so you might want to look at that as a method now of getting more information out in your discovery process and that SMS Trace you're talking about, which is Network Trace.

Otto: A new DDR even if the workstation is already a client?

Wally: That could be a couple of different things. Logon Discovery, if you're using Windows Networking Logon Discovery and you're using logon scripts, anytime the user logs on it's going to create a new discovery record, a new DDR, regardless of whether or not that computer is already a client, so it is going to create a discovery record. It should report that it is a client if it's already there.

If you're not talking about Logon Discovery, in other words, you're talking about Heartbeat Discovery, Heartbeat Discovery is there, yes, to keep your SMS client information updated in the database so it doesn't get aged out. Again, we have that Delete Aged Discovery Data maintenance task that's going to remove all discovery records that have not been updated in a certain period of time and, again, that default is 90 days. And you don't want your existing SMS clients to be aged out just because they hadn't reported discovery. So, yes, we will create new discovery data even for existing clients and we do so for the specific purpose of keeping your database updated.

Otto: Can I dispose of my RIS server and use SMS to install my software?

Wally: You can use SMS to install application software, upgrade operating systems, but as of today SMS does not provide a method for you to deploy operating systems. Now I've heard that we announced something very recently. I believe it was with PowerQuest and some sort of an ability with PowerQuest to use SMS to deploy PowerQuest images out to clients, so there may be some capability there. I'm not familiar with what all that process is, so I can't say a big yea or nay, but traditionally with SMS it's not going to do the same thing as RIS because RIS is going to deploy an operating system and then applications with that OS.

SMS is for upgrading existing operating systems and deploying applications, not deploying fresh operating systems, because you don't have an SMS client there. You can look at that new announcement, and we probably have it up on the SMS Web site, http://www.microsoft.com/smserver/. There may be something up there talking about the PowerQuest announcement because we announced that fairly recently and I don't remember all the details on it.

Otto: Does the network Logon Discovery cause duplicate DDRs for a resource if a user logs on more than once a day?

Wally: Yes. Logon Discovery will create a discovery record for every single instance that the user logs on to that client computer. It doesn't track, I already created one today; I won't create another one until the next day. Every single time you log on, you get an additional DDR. Again, if you have environments where users are logging off and logging on multiple times a day, you have a lot of clients and a lot of sites in your domain sharing information in your hierarchy, you probably don't want to use Logon Discovery.

Otto: We have servers that seem to suffer from a large resource usage with SMS Apm32.exe, around the 85 percent range, and this happens indefinitely. There have been general articles on this, usually being a problem with the software, conflict with other applications, but we're curious if you've seen this specifically and maybe you have some pointers how to resolve it?

Wally: Outside of the Knowledge Base articles that you mentioned, the only other issues I've heard about with this are issues in the code that we've released updated service packs or hotfixes for the Smsapm32 code.

I want to say there were hotfixes in the SP4 Hotfix Rollup Package that were related to this. I don't recall if there was anything in SP5 that's related to Smsapm32 and CPU processing. If you've already got HRP, which the Hotfix Rollup Package for Service Pack 4 installed, and you're still having issues, then what I would suggest is that you open up a case of PSS and track it through them. We can look and see if there is something in Service Pack 5, which again has not been released yet, but will be very soon, and that fix may be there. I don't have a list of everything for SP5 and I don't remember from the research I did whether there was anything related to APM, other than traffic has been reduced. I don't remember the CPU issue being addressed; it probably has been. I just didn't look at all the bugs for it. That's about all I can offer right now.

Otto: What happens if a client is not online when Heartbeat Discovery is active?

Wally: Heartbeat Discovery runs from the client. It's not a discovery method that you run from the site; it's run on the client itself. What will happen is all you do with Heartbeat Discovery is you say run Heartbeat Discovery every week. So if a client is not running, it's powered off or not on the network or whatever, the next time CCIM boots up it will do its discovery data. It will look at its registry to see the last time it reported Heartbeat Discovery. It will say, "I'm supposed to do this weekly; I haven't done this for three weeks," so it will generate a Heartbeat Discovery record at that point in time and forward it to the client access point.

Heartbeat Discovery, you enable it at your site, but it's performed by the client. It's not a discovery method like Network Discovery where the site server initiates the discovery. It is just configuration that the client does itself, and it runs the discovery process and does the reporting of the discovery data.

Otto: When I enable Network Logon Discovery, a directory called Smsnetlogsvc, which is about 160 MB, that folder is created on the BDC's C drive. I need actually to tell it to install onto another drive. Is that possible?

Wally: You're saying the SMS logon folder is taking too much space. 160 MB is awfully large, so what that tells me is that you have an awful lot of sites that are sharing that domain to get your logon point folder up to 160 MB. I want to say on a single site it's only like 15 MB, so you must have a very large number of sites there or you've got a lot of old files sitting in that drive.

Anyway, to change that there is a procedure. We will document it in Service Pack 5, and the information comes out in Service Pack 5 as to how you can pre-create the SMS logon share. Then SMS will install the code in that SMSLogon share (that is created by default), but you could pre-create that share manually, and then change the comment to the appropriate share.

I don't know that we have a supported procedure for you today outside of Service Pack 5. You would have to contact PSS because anything involved with that, because you're modifying the default of how we access, I'm sure you'd have to contact PSS and they could step you through the procedure of pre-creating the SMS logon folder and share on a different drive, moving all the files over and changing the comment, which all those things have to be done.

Outside of that, the thing that could be done is if you remove that server from the browse list, SMS no longer treats it as a logon point, and then after SMS has said, "this server is no longer a logon point," it will remove it from its list. Then after we've done that, you could delete the files manually, if you didn't have us delete everything.

Then create your NTFS drive with the most free disk space to be a drive other than drive C. Then when you add it back to the browse list, when the next logon point update cycle runs and says, "This is a new domain controller on your site, we need to set him up." You can have SMS re-create all that data for you over on the drive, other than drive C, provided it has more free space in an NTFS partition.

Otto: Why is it that SMS will install itself on a computer connected to the network via a 56-Kbps modem?

Wally: The reason it will do that is our default net speed check is 40 Kbps, so as long as you are something like 40 Kbps and faster, we will install because we set that as what we determine to be the minimum speed that we could effectively install a client and support it over a dial-up link like that. If you don't want your clients to be set up and installed on links that are slower than say 56 Kbps or slower, you can modify your Smsls.bat file and put in a different net speed.

It's documented in the release notes. I don't remember if it's still in SP4's release notes, but it was in SP2 and I believe SP3 release notes. Search on network speed; you could also search on slow net. If I remember correctly the line in the log on script is slow net and there are like four different places in that logon script you have to change that value to be the speed you want it to do for logon script processing.

Otto: Moving on here: Site4c.exe, is that in the resource kit?

Wally: It's Site4c.exe so it's not spelled "site force" and it is in the SMS 2.0 resource kit, yes.

Again, don't get in the habit of using that as a replacement for setting up proper boundaries. If you remember, the SP5 WebCast I did a couple of months ago, there was an issue where we found it was secondary sites clients that were using Site4c, they were assigned to the site to use Site4c, and were not receiving advertisements from the SMS 2003 site, so you never can be sure when you're trying to work around things any future things that may break because of it.

It's not something we want you to get in the habit of using, but if there are cases where you have to because of site boundary-type issues, then you can use that.

Otto: In a multiple SMS site environment, we have 116 sites. Some resources or workstations have more than one assigned site in the SMS database. There's no overlap of IP subnets at any site boundaries, so we're wondering how we clean this up?

Wally: The only way we do assigned resources to sites is through IP subnets or IPX networks, so that would probably indicate that at one point in time you did have a shared boundary. After a period of time on the clients, CCIM should update and do its maintenance cycle every 23 hours. It's going to verify the assignment list for all the sites it's installed to, and it's going to report that information appropriately in the database and its DDR up to the database, and we should clean that up.

If you have an environment where you have records that are not being cleaned up properly, what you could always do is manually delete one of those records to test it out, and then have the client generate Heartbeat Discovery again and verify that it is assigned appropriately.

Now oftentimes people will see that like at a central site because they may have boundaries that are shared from their central site to some other down-level child sites, so you'll see in the central sites database that the resource is assigned to multiple different sites because when I got the DDR from my grandchild site (where it was assigned and installed) that same client is assigned to my local site, just because of the boundaries.

That doesn't necessarily mean it's installed in that site, so being assigned to multiple sites simultaneously is not the big deal, the thing you don't really want to do is have your client installed to multiple sites simultaneously. Because then you get into which schedules from what site do I use for which components, and how do I merge things together, and what agents do I use and not use and so on; so it gets to be a little more difficult.

There is no other cleanup processes than an automated cleanup process that the client should go through other than manually deleting records and letting them get re-created. I've heard no other cleanup process from that, but again I've only heard of clients being assigned to multiple sites simultaneously when there is an overlap of the site boundaries. It tells me there probably was an overlap at one time and should have been cleaned up automatically. If not, you could try the delete method, but again you lose inventory history information when you do that.

Otto: SP5 implements local accounts for managing SMS logon points. We're wondering if this makes it possible to put SMS logon shares on non-DC computers, assuming the admin is willing to take on the additional required tasks. If so, how do we do that?

Wally: No, that is not a supported scenario. Even with SP5, and the fact that you can now manually specify or manually control your logon points, as far as the locations being used and so on, it still does require domain controllers, so we're not supporting anything outside of a domain controller to be set up as an SMS logon share.

Otto: What are the SMS Cli Service Account (SMSCliSvcAcct&) and SMS Cli Token Account (SMSCliToknAcct&), and what are those that are installed on the local accounts?

Wally: The SMS Cli Service Account, SMSCliSvcAcct&, is the service that's used by SMS clients that are non-domain controllers to run the SMS Client service itself. If you go to Services under Control Panel or Administrative Tools, look at the SMS Client service and look at the Logged On As field, you'll see that it's the SMS Cli Service Account. It's the admin account that's created locally on the client that's unique on each client computer, the same account name, but different password; that's then used to run the SMS Client service.

The SMS Cli Token Account, SMSCliToknAcct&, is the account that's used by the SMS Client service when it has to launch off another process. So when you want to launch off another process we use the Client Token Account, which is the special account that we use for isolation of SMS processes to keep the security context more secure and preventing processes from overlapping on each other, because there are numerous different threads and processes with the SMS client. So use that account as the account that's used to run some of these other processes.

This is also the account that's used when you create an advertised program at your site, and you advertise and state that it requires administrative rights, so when you go to the Environment tab and click Runs with Administrative Rights, but don't click Use Windows NT Software Client Installation Account, we use the SMSCliToknAcct& as the admin account. If you look at your client database, this account is resident on all your SMS clients, but again with a unique password at each client.

This account is not a local administrator like the SMS Cli Service Account is, but when you run that program with administrative rights, Smsapm, the Available Programs Manager, will take that account, make it a local admin, and run the program. When the program exists, it will remove that account from the Local Admins group again, so it's no longer an administrative account. So it's used for a couple of things, one is just for process isolation and security and another is as an administrative account that we use for installing software when you designate we need software to be installed with admin rights.

Otto: What's the best method, other than manually going to the PC to identify and repair an SMS client load which is damaged or corrupted and is unable to function normally or reload itself via running SMS LS?

Wally: To identify or determine which client is in that state, that could be some of the status message queries we mentioned before. It could be the SMS Web Reporting Utility and you see that you haven't reported hardware inventory or discovery data in a certain period of time. Now to actually fix that process, what may be the easiest for you is to delete the resource from the database. So go to a collection where that corrupted client is, delete it from the database, and then force the site server to push out the client installation to that computer, if it's Windows NT or later.

You can do that with the Windows NT Remote Client Installation method. So you could delete the client from the database, run the discovery process, find the client, and then that would then force us to create a CCR if it, again, was a newly assigned system resourced within your site, and the OS was NT or later, or there is no OS. We'd push out the client installation process, and we don't look to see if the client is already installed.

If you don't delete the client from the database first, when you do discovery, Discovery Data Manager will look at the database and say, "It's already installed on the site. I don't need to push out the client installation process."

There's also a set of utilities that you use to create the CCRs manually, if you don't want to do the discovery process. In the SMS 2.0 resource kit, I believe there's a utility called CCRgen. You can use that utility to manually create a CCR designating the computer name that you want to create a CCR for. Place that CCR that's generated on the site server in the Ccrretry.box or just the Ccr.box, and we'll try to push out the client bits out to that client computer itself.

Other than that, you may need to go through some sort of a process like running a utility like Psexec or something like that to remotely connect to the client. Then manually kicking off the 20Cliclean utility to clean up the client and then forcing a reinstall after you've cleaned up all the residue, other than maybe you want to leave the Smscfg.ini file to use the same GUID. Those are a couple different options that you have available, to help in that environment.

Otto: If the client is not assigned on install because the subnet is not defined in the site, and then the site is later updated with the subnet for the client, will the client then pick up where it failed and complete the client install or do you have to actually launch the install again?

Wally: You would have to launch the discovery, at least the installation process again, so launch of Smsls.bat again or Smsman, because the client only checks when it runs Smsls.bat or Smsman. It doesn't check periodically, and doesn't say, "I was not assigned this time. Let me wake up on a daily basis and see if I'm now assigned." No, you would have to initiate the logon process again, either through the logon script or the Smsman process, and then during one of those two processes we will check on the logon point to see if the site boundaries have changed and whether the client is now assigned to the site.

Otto: What causes SMS to install the client on a computer that has an IP address that falls outside of the site boundaries?

Wally: There is nothing that I know of because all the different installation methods are going to check for assignment, so if you do any Smsls.bat or an Smsman, they're going to verify on the logon point before they'll kick off the installation of the CAP.

If you do the Windows NT Remote Client Installation, we do a verification process as well to verify, so we connect it with the client. We run a discovery process, and that should do an assignment process as well. The only thing I can think of is if you ran Site4c, to force that client to be a member of a site, regardless of the site boundaries; that would be the only reason I could think of that you could install a client that was not within the site boundaries. Other than that, 2.0 clients must be members of site boundaries still within the appropriate sites. You've got to be within the site boundaries in SMS 2.0 or use the Site4c utility. I know of nothing else that could accomplish that for you.

Otto: When setting up the network logon client installation, what happens if there are BDCs in the domain that are non-Windows servers; for instance, Open VMS systems? If the non-Windows BDCs never validate user logons, can SMS simply ignore them?

Wally: If those domain controllers appear to us as Windows-type boxes, we're going to try to install on them. If we fail, we'll generate errors in the NT_logon.log file. We'll also create status messages indicating that we had problems talking to certain BDCs, so we will do that.

There was an issue with another product, some SMB server, I don't remember what it was called now, that looked like NT. We had some issues with trying to install domain controllers on those guys. I thought we had resolved that issue way back in Service Pack 1 or Service Pack 2, somewhere in there.

If we find a computer in the browse list, we do the NetServerEnum API call. If it is listed in the browse list, we then try and push out the logon point installation to that computer. If it will support that installation, then we'll proceed. If not, then we'll generate log messages as well as status messages saying we couldn't do so.

Otto: What prevents SMS from modifying the logon script even when it's enabled?

Wally: If you've enabled the check box to say modify user logon scripts, the only things I would know that would prevent us from being able to modify the logon script is if the SMS Service Account or the optional SMS Site System Connection Account didn't have administrators in the domain to be able to do that, or if your logon script is not a logon script that we could modify; there's a couple of extensions, if they're listed like .exe, if you put in Smsls.exe as your logon script that a user already has. We won't try and modify it. It has to be like a .bat file or a .cmd file, something that we know we could modify, as well as if your logon script does not include an extension, so if you just put in Smsls, then we won't modify it.

That's why, when we do modify the logon script and if the user doesn't already have a logon script in their profile, we set Smsls as their logon script. What I meant was that we don't add the .bat extension to our batch file when we modify the user logon scripts. If we did add .bat to Smsls.bat, then the next time we'd modify our own batch file (Smsls.bat) to call itself (Smsls.bat). So, basically, we are setting the user's batch file to Smsls (without the .bat extension), and not modifying it from there on (so we are not adding the "call Smsls.bat" statement to our own batch file).

Otto: Does the Smsman.exe need admin rights as well?

Wally: Yes. Client installation always requires admin rights. It doesn't matter which one of the three installation methods you use.

Otto: If Smsls.bat aborts on a Windows Terminal server, what's the best way to get the SMS client installed?

Wally: On the Terminal server computer, you would run Smsman because Smsman does not check for Terminal Services and we do support you using the manual installation process on a Terminal server computer, not the automated logon process.

Otto: Actually, this may have been a follow-up to that last question: NT Remote Client Installation is dependent upon discovery data. Is that correct? How do you force or correct discovery? I have DHCP discovery and WAN/DHCP clients who are not being discovered, thus cannot install via NT Remote Client install. Can I use Logon Discovery or client install?

Wally: The NT Remote Client Installation method is dependent upon discovery data, unless you want to use the utility that I mentioned earlier in the resource kit called CCRgen. You can manually create CCRs and drop them on the site server. However, the easier and automated method is to use discovery, so you'd want to use discovery method to generate your data.

Primarily, that could be Network Discovery, and that's what most commonly we would expect you to use would be Network Discovery as the method to discover your resources and then have the WinNT Remote Client Installation method push out the installation to your clients.

If you have DHCP discovery and clients that are available across the WAN that are not being discovered, one thing you need to look at is in the Network Discovery properties, there's a Subnets tab. The Subnets tab is where you list what subnets you want to do a discovery of. Kind of good, kind of bad, but Network Discovery ignores the Subnets tab, for all discovery methods except for DHCP.

If you have clients in a DHCP scope that are not listed as subnets that you want to do discovery from, on your Subnets tab, that we won't discover them and we won't try and create DDR s for them, because we won't have discovered them. You would have had to have added the scope from those clients on the Subnets tab of your Network Discovery properties and enabled that searching of that subnet before we would create DDRs for clients on that subnet.

That could very well be what the case is. Domain Discovery, SNMP Discovery, and Router Discovery and so on, they kind of ignore the Subnets tab. It's really just DHCP that does follow it. That would be my guess on what's happening is that you have different scopes that you're finding from the DHCP Discovery that are not listed as enabled subnets on your Subnets tab.

Otto: Support recommends that you only use Heartbeat for Network Discovery, and you use Logon Discovery to get the clients. Is that the case with SMS 2003? I heard that we were supposed to use Network Discovery for the new version?

Wally: I don't understand what the statement is about the support only recommends Heartbeat Discovery for Network Discovery because those are two totally different things. Heartbeat Discovery is only for existing clients, so if you already have an SMS client installed, Heartbeat Discovery can update that discovery record in the database on a periodic basis. Network Discovery could do the same thing potentially, but it can also find additional resources that aren't SMS clients, so they're tackling two different things, so that doesn't make sense to me.

As far as the new version being SMS 2003, SMS 2003 does not have Logon Discovery, so that's a moot issue for SMS 2003. Discovery methods that you would use in SMS 2003 would either be Network Discovery, which is going to function basically the same as it does in SMS 2.0, Heartbeat Discovery for updating existing discovery records for existing SMS clients, but primarily to find new client computers, you would use Active Directory discovery. So if you're in an AD environment we'd expect you to use Active Directory System Discovery to find computers from the Active Directory, generate discovery data for them, and then allow you to either push out the client install or whatever method. We'll actually talk about installing SMS 2003 clients in next month's session, coming up in a couple of weeks.

Otto: Will SMS 2003 have a newer install of WMI as part of the client loader and/or have the ability to update the WMI as new versions become available, as a manual customization or an update in an SP?

Wally: Yes. SMS 2003 will be using WMI 1.5 now instead of WMI 1.1, so we will automatically push out WMI 1.5. We still do not give you the ability of modifying the WMI bundle that is installed with the client components when you install a client. However, you can still use SMS even today to push out a newer release of WMI to your client computers using SMS software distribution; we've had numerous customers do that.

But, yes, SMS 2003 requires WMI 1.5 and that's what the bundle will be for your standard clients. Your advanced clients will already have it because advanced clients require Windows 2000 and later, so it would already have WMI installed, so it would just be for your Windows 98 and Windows NT 4.0 standard clients that you install with SMS 2003. They will be upgraded to WMI 1.5.

Otto: Is there a way to refresh the advertised program's manager in the Control Panel applet remotely? For example, we sometimes refresh the hardware inventory by starting the HW Inventory service remotely using Manage My Computer?

Wally: There is a resource kit utility called Cliutils. It might be in the support bundle, but it's definitely in the resource kit. There's a utility called Cliutils. You could run Cliutils with a /start, and then in quotes I believe it is "system offer data provider", so you would type

and that will kick off the APM code to look for new advertised programs.

Again, you have to get to the client to remotely do that. Otherwise you could advertise it with SMS, but you're advertising the thing that you're trying to do, which is to force the client to wake up and look at new advertisements. We're working on a utility, some of you actually may have seen it in a pre-release of the value pack long ago that was an Admin console extension that you could right mouse click and force the client (through WMI), to wake up an check for new advertisements immediately. We have that utility that we're working on, and hopefully we'll be able to make that available at some point in the future.

Otto: Have you seen an issue in which the remote control component is installed, but no RC agent shows in the services?

Wally: Remote Control agent is installed, but no component in services. No. I would look at the Remctrl.log file in your client computer and Windows\Ms\Smslogs. Look at Remctrl.log and see if it indicates to the client that I've completed this installation. I know it could be an issue with the actual creation of the service itself, so again lack of admin rights. Could be lack of rights, if it thinks it's installed you probably found it from the CAP, but you could check to make sure you have CAP permissions.

I would look at that log file. If you don't see it there, that means we didn't even try and install it on a client. So then you would look at Ccim32.log and see if we detected that it was an optional component to be installed and see if we pass it off to Smsapm32. Look at its log file to see if it tried to run the installer, which is Remctrl.exe.

Otto: How can subnet masks be specified in the SMS 2.0 site boundaries?

Wally: They can't. You basically just have to figure it out on your own what the IP subnet should be and then list the IP subnet. Most companies are fairly consistent in the subnet masks they're using, but I've seen companies where the different clients have different subnet masks or different subnets are using different subnet masks. So it's an issue there, but for the most part you would go to the client; look at the subnet mask it's using, maybe from DHCP, and then just manually figure out what IP subnet that requires you to be entering. If you take like a 192.168.30.10 as an IP address to the subnet mask at 255.255.0.0, then your IP subnet will be 192.168.0.0. It's a process you have to go through, but you cannot enter the subnet mask along with the site boundaries.

For Network Discovery, you can enter the IP subnet and subnet mask. That's so we can access the router, but not for site boundaries; you've just got to list the IP subnet because it doesn't matter what the server thinks the mask is. It's what the client thinks the mask is, and the client needs to know what its subnet is, and it compares that to the list off the server so you need to have the client determining what the subnets are and that's what you list there. You can find that in the client discovery data or in its Wnlogon.log file, Wnmanual.log file or Ccim32.log file; you'll find what the client subnet is.

Otto: We had a few questions related to whether SP5 is available yet.

Wally: SP5 is not available yet. We're sitting at March 26. Unless a catastrophe happens very soon, you guys should be finding SP5 very, very soon. I can't tell you the exact date because I could be wrong, because something may happen, but we're waiting for final Customer Verification Program feedback. We need our customers in the CVP program for SP5 to sign off on it, but we're expecting that to be very, very soon. I can't give you any more than that. We were targeting March and we're still targeting March.

Otto: I'll address one last question here, and then we'll get the rest of these answered for you folks offline. If you enable Windows Network logon client installation and remote network logon client installation methods, and the user does not actually have local admin privileges, does SMS go through two cycles to install the SMS software?

Wally: If you're doing logon client installation and the logon user is not a local admin, he will try and initiate an installation process locally, he'll find that he hasn't sufficient rights to update the registry and start services, what will happen is that client will generate a CCR locally. It will send that CCR back to the SMS site, and then SMS will complete the installation from the SMS site end. We don't go through this exact same process the client already went though. We connect to Admin$ on the client. We push out the CCM bootstrap program, which is CCMbootloader; if you're looking at processes, you'll see it there. We push it out and we then download a different Clicore bundle, CCM Clicore. We download it, unbundle it, and then complete the installation from that method of getting the Client service installed and the CCIM.

It's very, very similar, but it's not that you have to go through another logon process or anything like that. The client just determines it doesn't have admin rights, it creates a CCR, gives it to the site, and then we push out the client install from there.

Otto: Great. Thank you. With that, we've answered all the questions that we were able to get to in the time allowed. We've simply run out of time here today, but I certainly wanted to thank everyone for joining the session and hope that the information was useful. I definitely want to thank Wally for coming out and giving us a great presentation as well.

Your feedback is absolutely valuable to us as we continue to grow the program for you and to meet your needs. You can send it to us at supweb@microsoft.com. Again, we hope that everyone has the opportunity to tune in again soon. Thanks and have a great day.