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

Heidi Moeller: Hello, welcome to the Microsoft Support WebCast. We'd like to thank all of you for joining us today. Our topic will be "Microsoft^® Systems Management Server 2.0: Common Problems and Resolutions." Our presenter will be Wally Mead. I'm Heidi Moeller, and I'll be your host for today's session.

We'll start this session with Wally's presentation, and follow that up with a question-and-answer period when the presentation is finished.

Okay, I'd like to take a brief moment to introduce Wally to all of you. Wally Mead joined Microsoft as a trainer in April of 1992. He's been involved with SMS training since the SMS 1.0 beta, and has focused on SMS 2.0 for more than two years. Wally currently works for Product Support Services, generating and delivering SMS 2.0 training to Microsoft support professionals. It's great to have you here with us today. Thanks so much, Wally.

Wally Mead: Good morning, or afternoon for some of you. I'd like to welcome you to our session. This session is going to concentrate on common product misconceptions. Go to the second slide, "Why the need for this session?"

The reason we came up with this session is that not all Systems Management Server 2.0 deployments are as successful as they could be. There are various reasons for that. The most common reasons for deployments that aren't as successful as the customer would like them to be are, first off, misconceptions about the product functionality. The customer or the solution provider or the consultant doesn't understand the product fully, or specific aspects of it, in specific detail.

And because of that, the desired result is not going to be achieved through SMS. Something's not going to happen that they're expecting to happen. So, product misconceptions are one of the common problems for unsuccessful deployments.

The next most common problem is improper site designs: SMS site designs that were not looked at closely enough, or because of some product misconceptions or misunderstandings, did not lend itself well to SMS 2.0.

And the third area is product issues: problems with the product that are addressed through hotfixes or service packs.

Those deployments where the customers had good training, went through mock training courses or self-paced training courses, had good product knowledge, and had reviewed their designs very carefully with Microsoft consultants or their solution provider consultants, were the most successful. They had a much higher success ratio and more customer satisfaction in their SMS 2.0 deployment.

So what we're trying to do in this session is cover some of the issues that people had, as far as common product misconceptions. We'll give you some of the information about the product itself, and we'll go over some of the areas where people were misinformed about the product, or that they didn't understand fully, and that caused some of these unsuccessful deployments. This session will cover just the product misconceptions itself.

The second area we talked about, improper site designs, will be covered in our next session, on April 13. Heidi will go over that at the end of the session.

To gather this information, the SMS product group talked with different sources. They talked to some of our customers, they talked to some of our consultants, and they talked to some of our solution providers. They talked to those sources and asked them what were the most common problems they had in their SMS 2.0 deployment.

We gathered all that data and came up with this session. So I've taken all the topic information that was developed from these resources, gathered it together, and come up with the presentation we'll go through.

By giving this presentation, we're hoping that, for those of you who have not encountered these issues, we'll answer some of your questions before you have a problem in these areas.

Go on to the next slide, which is the session agenda: the different topics we'll cover in this session. What are the common product misconceptions that people have run into?

The first one is SMS 2.0 administration requirements. What we'll discuss in this topic is how many SMS administrators you need to have, what their roles should be, etc. Well give you some information about SMS 2.0 administration requirements.

Then we'll talk about SMS 2.0 security. I know we've discussed that in the last couple of Support WebCasts, security and SMS accounts, but we'll hit it again briefly for new people, and just recap.

Then we'll talk about query and collection interaction. How do queries and collections interact, and what are some of the areas that cause difficulties for people in using queries and collections?

The next big area will be Network Discovery. People love Network Discovery — what it's there for, what it's designed to do — but they get frustrated when it doesn't discover everything they expect it to. So we'll go through the requirements of how to do a proper Network Discovery, and look at how Network Discovery works.

Next, we'll talk about creating custom queries. The 2.0 Query Builder engine is extremely powerful, and yet it's a little bit hard to work with, and to generate custom queries. So we'll go through that process quickly, and I'll point you to a couple of resources that can help you out in developing your own queries.

Next, we'll talk about software distribution functions within a site. Software distribution is one of the most commonly used and requested features of the product, but there are a couple of areas that people are confused about, and that cause them some concern. So we'll go through a couple different areas of software distribution that, hopefully, will help clear up some misconceptions.

Finally, as far as problems go, we'll talk about the process of removing SMS 2.0 client software from a client computer. And we'll go through the reasons why, when you remove a client, SMS does not do a complete removal of all client functions. We'll talk about why things are left, and what you can clean up, if you want to, manually.

The last topic is not a problem; it's where you can go to find additional resources. Whether you need a hard copy of the admin guide, whether you should get the SMS 2.0 Resource Guide, or if you want to get some support through newsgroups, we'll talk about the different resources that are available.

Let's jump into it. The first topic will be SMS 2.0 administration requirements. What we found from talking to some of our customers, consultants, and solution partners is that a lot of sites aren't staffed properly for performing effective SMS 2.0 administration.

What we found in some cases is that just a single person is performing SMS administration for a large site. That single person might not even be dedicated to SMS. In one case, we found an environment where they had a part-time person coming in two days a week to do SMS administration, and only for three or four hours on those two days, and trying to administer the entire SMS site. And they were struggling with their administration, getting SMS rolled out properly, and accomplishing some of the tasks they wanted SMS to perform.

That's not going to work very well. The reason is that desktop management systems, change configuration management systems, computer management systems — whatever category you want to put SMS 2.0 in — are very complex products. They're not easy to pick up on and to administer easily. SMS administration requires training and experience in order to have a good handle on the product, and to be effective in using it.

SMS 2.0 is powerful and complex, partly because it touches so much of your network. Basically, it can touch all of your servers, and it can touch all of your clients in your environment. With some of the other discovery methods, it may touch your entire infrastructure, going out over routers, and talk to other subnets and other physical sites that you have.

It touches much of your network, and because of that, it has the potential for being difficult. All the different features that SMS 2.0 has, the fact that it can do so many different things, and it can accomplish so many different tasks for you, again, leads to complexity.

Just as a guideline, we're telling our customers that they should treat SMS 2.0 at the same level of complexity as Microsoft Exchange. So if you look at your Microsoft Exchange environment, and look at how many administrators you have for your Microsoft Exchange environment, you want to have the same number of administrators for SMS.

Now some people have complained, "Well, I read that SMS 2.0 was going to cut down my administration requirements, and it's going to make some things a whole lot easier." And the product was designed to accomplish that — to give you the ease of administration, and to make things simpler for you throughout your environment.

But it takes a while to learn the product. It takes a while to get a handle on what your administration requirements are. It takes a while to learn the procedures you need to go through and learn to accomplish some of the tasks and functions within SMS 2.0.

So, to start out, you want to look at having a larger number of administrators. Concentrate on getting a handle on the functionality of the product, how it's implemented, the way it's used, and what you need to do on your end to accomplish these tasks. Then, once you've got everything scoped and mapped out, and you're very familiar with the product, if you need to, you can cut back on the administrative staff. You can then move them to other functions, or put them on other products.

But what we've been finding, from visiting some of our customers, is that they might have one person doing SMS administration, and they might have four, five, six, or eight administrators for Exchange. And SMS is at least as complex as Exchange.

So to get good benefit from SMS, especially when starting out and learning the product, you should have more people, so that you can spread the load. They can do more testing, and focus more resources on specific areas. Then you can accumulate and possibly combine functionality to different people, different levels of administration, and then possibly get into reducing your staff.

The next area we want to target is SMS 2.0 security. Again, we did touch on this in the last couple of Support WebCasts that we had in January and last month as well, but it's such an important topic that we wanted to cover it again, very briefly. SMS security is extremely important. One of the major reasons for that is the number of accounts that are created for SMS 2.0. And again, last month we went through the accounts and the number of accounts, and how to control the ones that you can control, etc.

When SMS creates accounts, sometimes they're created with administrative privileges. Generally, SMS will create accounts in one of two locations: either in the domain that SMS is installed in, so the SMS resource domain; or in the domain specified during setup, which oftentimes would be the user accounts domain. So be careful where those accounts are created, because you do need to control those accounts, and you do need to do some administration of some of the accounts.

Along with general security, you have to be very familiar with Windows NT security. SMS relies on Windows NT authentication, whether it's in a master resource domain environment, whether it's in a single domain, or whether you're relying on pass-through authentication, because you have no fresh relationships set up.

SMS needs to be able to integrate with all those different environments, because different customers are using different levels of administration. So you have to have a very good handle on Windows NT administration to be effective in your SMS 2.0 environment for administration, as well as security.

Just as a review for those of you that weren't here the past couple of times. SMS 2.0 security involves, again, many domains; and there are different domains that we're working with. So you need to be very familiar, again, with NT domain structures, and how the account information is authenticated between domains, as well as pass-through authentication.

Then you have to look at physical security. If you have an SMS server out in the workplace, where users can gain access to it, your security is compromised. Anybody could walk up to that computer, reboot it, install a new OS on it, and delete part of your SAM information after rebooting or installing a new OS. So you need to make sure that your SMS servers, as much as possible, are in a server room, locked away, so that users can't gain access to them. Any time you have physical access to a server, the security is compromised on it.

After physical security, then the SMS layers go to Windows NT security, appropriately for NTFS. SMS relies on NTFS to provide security on the SMS file structure. On your site server, your client access points, your logon points, your distribution points, and so on, on those specific site systems, SMS relies on NTFS to protect the SMS files. It protects them from malicious attack from users, or accidental file corruption from users, or other SMS systems.

So we do a pretty good job of locking down the site server, the distribution points, the client access points, and the logon points from possible file corruption and malicious attacks. We give users access, only to the areas they need to have access to, by giving read permissions only where needed, and by giving no permissions where they don't need any access. And then, appropriately, we give write permissions to CAPS and logon points, so you can go ahead and write out your inventory files or discovery records, whatever.

From NTFS security, we go to the SMS Provider. The SMS Provider is the security layer sitting between Windows Management and the SMS site database, which is sitting in SQL Server. The SMS Provider will be installed on either your site server or on your SQL Server computer, if SQL and SMS are separated. The Provider provides that security layer to the SMS site database.

In order to access the SMS site database through the SMS Admin console, or other WBEM utilities, or through Windows Management utilities, you need to have permissions to the SMS Provider.

By default, the only person who has permission to the SMS Provider is the user that was logged on when the SMS site server was installed. And in Service Pack 1, all members of the administrators group have permissions to the SMS Provider.

As Doug discussed in the January session on security, to grant somebody permission to the SMS Provider, all you have to do is take their user account, or a global group that they're a member of, and add it to the SMSAdmins local group on the site server and/or on the remote SQL Server computer. That would allow that user to start the SMS Admin console and physically connect up to the SMS site database, into SQL Server.

However, what they can do inside SQL Server (what SMS objects they can administer, or perform functions on) is controlled specifically by SMS security rights. So, a last layer of the security there is the actual SMS security rights that are created within the SMS Admin console.

Just by giving somebody permissions to connect to the SMS Provider, by giving them access to the SMSAdmins local group, does not necessarily mean they can do anything inside the SMS Admin console. They need to have specific security rights. Which means you need to go in, as the administrator, and create a security right for that user, for whatever class of object you want to give them access to, such as collections or packages or advertisements, etc. And then you need to specify what rights they have, whether it's rights to administer, rights to delete, rights to read — whatever the rights may be.

So you're going to have pretty good control over who can do what inside the SMS Admin console. That's done by giving them access to the provider, as well as controlling what they can access through the SMS security rights themselves.

And the last layer you might want to put on there is for users who are performing administration from a remote Windows NT workstation. You may want to create a custom MMC snap-in for SMS, so that if you have users who are only doing software distribution, you can create a custom MMC console that will only show them queries, collections, packages, and advertisements, and nothing else. So they wouldn't see status messages, they wouldn't see tools, they wouldn't see site hierarchies and site settings, and so on. They wouldn't see things they didn't have access to.

At the bottom of your PowerPoint^® slide, I referenced something called the "SMS 2.0 Security Essentials" white paper. That's a white paper that is coming out, in fact there's a beta version of it out right now on your SMS 2.0 SP2 CD. So, if you have the Service Pack 2 CD for SMS 2.0, in the \SMS\Docs directory, I believe they have it in PDF format.

And the PDF format there is not Microsoft package definition file format, but it's Adobe Acrobat format. Basically, they have a postscript version of that file, the beta version. It will also be published on the Web sites and other locations as it comes out.

That's something you definitely want to get a hold of and go through, and see how your security system and your security needs map to what SMS does by default, and how you can change SMS to accommodate what security requirements you have.

You also want to make sure that you've gone through the SMS 2.0 SP1 or SP2 Release Notes to see any security references in there. For example, you want to make sure you don't orphan your SMS clients by a site reinstallation. We talk about how to create additional client network connection accounts in there.

So security is something that causes problems for people, primarily when they're not really familiar with Windows NT security, different domain structures, and pass-through authentication.

Next, we'll move on to query and collection interaction. Collections are something new for SMS 2.0. Collections are very powerful in what they do. The general theory behind it is that a collection is based on a query. So you would take an existing query that you created, create the query syntax to find the appropriate resources you want, such as "all Windows 95 computers," or "all Windows NT computers with Service Pack 4 installed," or whatever the case is.

You create a query to find the resources you're interested in targeting. You make sure that query works properly. You take that query and use it as a membership rule for a collection, and then you have a collection that is based off of a query membership rule.

It'd be somewhat similar to a machine group in SMS 1.2, which is basically a grouping of resources. Only in SMS 1.2, you primarily got there by creating a query, running the query, then cutting and pasting, or dragging and dropping, the query results directly into the machine group. In 2.0, you take your query rule and you assign it directly to the collection to create a membership rule.

When you do that, it gives you great power. SMS will automatically refresh all collections periodically. Our built-in collections will refresh hourly, and by default any collections that you create as administrator will refresh every two hours.

Let's say you have a collections set up for all Windows NT computers. You go ahead and advertise the Windows NT 4.0 Service Pack 5, so a service pack upgrade to that collection of Windows NT computers. And you do that today. Tomorrow you go ahead and install a brand new Windows NT computer.

With the way SMS processes collections, when SMS detects that that new Windows NT computer is now an SMS client, and has been discovered within your site, it will go ahead and evaluate the collection rules, find that the new Windows NT client is now a member of the appropriate collection for Windows NT clients, and it will automatically advertise the Service Pack 5 upgrade to that new client computer.

You won't have to do anything as an administrator, you just have to discover the client to get it to install this SMS client computer. And SMS will take care of the process of adding it to the collection, creating an advertisement for that client, and making that advertisement available to the client.

It gives you great power. You've got automatic updates of your targets for software distribution, which is really where collections are used most effectively.

However, the area that causes confusion for some administrators is that, once you've taken a query, and added that query as a membership rule to a collection, and once a collection's been created, there is no longer a link between the query and the collection. In other words, when you create the query membership rule for the collection, we take the query syntax, and we imbed it directly into the collection.

Now, if you go back out to your Queries node in the SMS Administrator console, you modify the query syntax, you modify the existing query, and you process it and make sure it works properly, you may have a different set of results by running the query than you have by running the collection that's based in the query.

And the reason, again, is that just updating the query rule does not update the collection. Because of the time of adding the query as a membership rule, we would take the query syntax and imbed it or import it directly into the collection membership rule, and there is no link at all between the query and the collection.

So what you would have to do, if you modified your query manually, is to modify your collection manually as well. You could delete and then re-add the new query as a membership rule. That would embed or import the newly updated or the modified query syntax. Or you could go into the collection and manually update the SQL syntax to be the same as the manual query that you have.

So again, just as a recap there, once you've taken a query and added it to a collection as a membership rule, any modification to the query from the Queries node would not be reflected into your collection automatically. You have to go out and manually update the collections, basically by deleting the membership rule and re-adding it. And that will again import the new query. There is no link between the two, once they're created. Once you understand that one time, then it's a fairly simple process: any time you modify the query, go update your collection manually as well.

The next area that we want to talk about and spend a few minutes on is Network Discovery. People just absolutely love the theory behind Network Discovery, the fact that it has the ability to go out across their entire intranet and discover any IP resource on the wire, whether that IP resource is a physical client computer that they would expect to discover, or if it's a server computer, or a router, or a wiring concentrator, or a UNIX workstation.

Basically, Network Discovery has the capability of discovering any IP resource on your wire, whether they're running a Microsoft operating system or not. That's totally immaterial. So it has a lot of power.

However, people sometimes don't understand the requirements for Network Discovery in order to really do discovery, and to report back that it did discover a resource. Sometimes they get confused with this: if you were to look at the Network Discovery properties, go to the Discovery Methods and Network Discovery, and go to its Properties, there is a series of tabs in the Network Discovery properties pages. There is a series of property pages there. The majority of those property pages are simply seed mechanisms. They allow you to specify a method for Network Discovery to find a list of IP addresses or computer names.

Just because you supply a resource in there (a router, a subnet ID, or a domain to browse, etc.) doesn't necessarily mean that that's going to provide Network Discovery with all the information it needs to report that resource as a discovered resource.

What's really required to report a resource through Network Discovery is the resource's IP address, as well as the subnet mask of the resource.

In order for Network Discovery to create a discovery record for a resource that it finds in the Network, it needs to have both the IP address and the subnet mask. It doesn't have to have a host name or a computer name, as it can report it with the IP address. But it needs to have an IP address and a subnet mask.

There are only three ways that Network Discovery will acquire a subnet mask during the discovery process. The first method is through a trusted router ARP cache. A couple things on ARP caches. If you're familiar with ARP caches, you know that most ARP caches have a fairly short life, as far as their entries go. Most ARP caches will age out entries after anywhere from 1 minute up to 10 minutes of entry into the ARP cache.

I might have gone across a router that puts my MAC address and my IP address in the ARP cache. It might last there for only 1 minute, it might last there for 10 minutes. And each router that you have implemented will have a different configuration parameter for ARP cache life and for the aging factor.

With that in mind, putting in a subnet and querying a router may not provide the information you want, because the clients may not be active across the network, and they may not be included in your ARP cache at the time of discovery.

Now the part about the trusted router APR cache is if your router has multiple IP addresses on a single interface. For example, if the interface that the SMS Site Server is accessing the router upon has multiple IP addresses, we can't trust the subnet mask for that interface, because the two different addresses may have two different subnet masks. And in that case, we won't use the router's subnet mask as a trusted subnet mask.

We will, however, go off to the ARP cache, we'll take the list of IP addresses from the ARP cache, and we'll go ahead and try to access each of those devices independently. However, we would require a different method to acquire the subnet mask for that resource, either directly from that resource, or through a DHCP server, which we'll talk about later on.

A trusted router ARP cache means that the IP interface that you have, the physical interface in your router, has a single IP address. In that case, when we retrieve the list of resources from the ARP cache, we can use the router's subnet mask as a subnet mask for all those resources. And then we can go ahead and report that resource as a discovered resource.

The second method to acquire a subnet mask is by querying a Microsoft DHCP server, and having the clients be Microsoft DHCP clients. We can only interface with Microsoft DHCP servers currently, as the DHCP does not provide an industry standard method of acquiring data from the DHCP server. Each DHCP server's implementation may have a different method of acquiring the database information. So, obviously, we know how to read from our own database.

If you specify in your DHCP tab the IP address or computer name, the NetBIOS computer name of a DHCP server, then when Network Discovery runs, it will query that DHCP server, and it will retrieve the scope information from the DHCP server, as well as the list of active addresses — a list of active leases in the database for each of those scopes. The scopes become subnets that will appear on your Subnets tab after discovery, and each of the active leases will be reported as a valid discovered resource.

We'll take the list of database entries, the active leases, and Network Discovery will query each of those resources independently. However, because we have a subnet mask from the DHCP server, which you have to supply in your scope, we know the IP address and we know the subnet mask. Even if that client computer is not turned on, is not active on the network, we can still create a discovery record for that resource because we have everything we need directly from the Microsoft DHCP server.

The third way to acquire a subnet mask from a resource is by querying the resource directly by the site server in Network Discovery. You access the resource through SNMP with a valid community name, and then pull the subnet mask of the resource from the resource, using SNMP. That requires, on the SNMP tab, that you have specified a valid community name for accessing each of your Windows NT clients on your network, or other clients on the network.

Again, the only three ways we can acquire a subnet mask through Network Discovery are through a router ARP cache, provided the router has a single IP address on its interface; using a Microsoft DHCP server, and having Microsoft DHCP clients; or having an SNMP agent running on the local computer with a community name specified in Network Discovery that the Network Discovery component of the site server can use to query that resource independently.

The other methods, like the Subnets tab and the Domains tab, those again are just seeding mechanisms. They provide Network Discovery with a list of potential resources. For example, the Subnets tab would give us the ability of contacting a router. From the router, we'd look at their ARP cache.

Once we pull the resources from the APR cache, we'll ping each of those IP addresses independently to see if they're alive on the Network. If they're alive and they respond, then we'll try to query that resource through SNMP. If we get a response back from SNMP, then we'll pull the subnet mask out, and we'll have the IP address and the subnet mask we need to do discovery.

The Domains tab — it just gives us a domain to browse. Network Discovery would then contact a master browser for that domain, and when we do our browse queries, we'd get a list of resources by computer name. We would then resolve the computer name into an IP address and go through the same process: pinging it to see if it's alive on the Network, then querying it through SNMP. We would then query it to find its operating system name and version, provided you turned that on for Network Discovery.

If one of those three methods is not available to provide a subnet mask for us, then Network Discovery may have found that resource in the wire, it may have talked to it, but it won't have discovered the subnet mask, so it will not report that as a discovered resource. If you look at the Netdisc.log file, you may find cases where you find an IP address, you talk to that host, you resolve it to a host name. But you never find the subnet mask.

Network Discovery, down at the very bottom section of the Netdisc.log file where it exports, will list the resource, but it will not say "DDR written." If it does not say DDR written, that means Network Discovery did not have the subnet mask, so it could not write a DDR.

If no discovery record is created, then the resource is not added to your appropriate collections through Network Discovery. Which means, if you have Windows NT Remote Client Installation Method enabled, we have no way of determining whether or not that was a Windows NT client, and pushing out the SMS client software through Windows NT Remote Client Installation.

You just have to be careful when you're running Network Discovery to make sure that you have some way for Network Discovery to acquire the subnet mask. Either through an ARP cache, with a single address on the interface, or through a Microsoft DHCP environment, or through SNMP. Those are the only three methods we can use, currently.

Moving on to the next topic, which is creating custom queries. There is a set of built-in queries in SMS 2.0, and they're based on specific types of queries. There's a set of built-in queries for querying specific resource types, such as all Windows 98 computers, or all user groups, or all Windows NT Workstation systems, etc. So they rely on having discovery information generated.

The next set of built-in queries are those that rely on hardware inventory being generated. For example, all Windows NT computers with more than 32 MB of RAM, or with Service Pack 3 installed. Or all server computers with 64 MB of RAM. Those all require hardware inventory being generated.

Then you have the queries that require software inventory being generated. For example, all computers with Microsoft Word installed, or Office 97, or any of those queries that are built in. I believe there's one built in for Word 97.

The last category is year 2000 compliance queries. There are two different cases here. There are the queries that start with Y2K: all the queries that start with the first three characters "Y2K." Those all require software inventory to have been generated and collected, as well as the Product Compliance Database to have been installed during setup. Then you can run the queries that start with Y2K, and there are six of those.

The other set of queries are those that start with PC Analyzer. The queries that begin with PC Analyzer all require that the Microsoft Year 2000 Product Analyzer has been run, generating data that is written in an .mif format. Then you run hardware inventory to collect that no ID .mif (.nmf) file into your hardware inventory data. Then you can run the PC Analyzer queries.

That's the set of queries that are built in. There are approximately two and half dozen queries built in to the SMS Admin console. Microsoft recommends that you use those queries as samples only; we don't recommend you run those on your production sites. The reason for that is if you have a lot of resources in your site, specifically a lot of resources with common attributes.

For example, if you have many routers in your environment. Routers commonly have multiple IP addresses, multiple subnets that they're a member of. And it takes a lot of resources in SQL to process a query and display all the results of that query, when you have a single resource with multiple addresses or IP subnets in their array.

In that case, it takes quite a while to process the query and generate the data. And in fact, if you run those on large sites, your test DB space will grow dramatically when running those queries, and they will take a long time to process.

We recommend that you use our sample queries in your test environment to see how they operate, to see what queries are valid, and then create your own custom queries.

The other reason, besides the number of resources you have, that our queries may take a while to process, is that each of our queries display all attributes for this specific resource class. For example, on a discovered resource, like the All Systems query, it displays all your discovery data, which includes IP addresses and IP subnets. If that's being displayed in environments, we have a lot of routers in your discovery data, then it takes a while to process that data.

We recommend you take our built-in queries, use them as templates for your own queries, find out which display attributes are important to you, and then create your own custom queries, showing only the attributes that you really care about.

Maybe you don't care about IP address or IP subnet. Maybe you don't care about resource type or resource ID. Maybe you don't care about some of the other attributes. Create your own queries; you can use ours as samples if you want to. You can import one of our queries into your own query, and then specify what display attributes you want on the General tab when you're editing your query statement.

Then, when you're creating your own queries, you have to go through the Query Builder. The Query Builder is fairly complex in 2.0. It's a lot different in the way it looks and how it's interfaced than what you saw in SMS 1.2. People are trying to compare it to 1.2, and the process of building a query is entirely different. There is a lot of power to the 2.0 Query Builder, but it takes a little while to get used to the interface.

When you're building your own queries, one of the things you have to do is specify what resource class, what attribute class you want to go to, as well as what attributes or properties you want to query and display, or set criteria on. And there are a lot of different criteria properties for the different attribute classes that you can query on.

Those are documented fairly well in Appendixes B and C of the SMS 2.0 Resource Guide. So if you want to create your own queries and you don't know which classes and attributes to query on, you might want to get the SMS 2.0 Resource Guide and look at Appendices B and C. They go through all the different attribute classes and properties, so you'll know what you want to query on.

They're also specified in Appendix E of the SMS Administrators Guide. If you get the Administrator's Guide, either online or a hardbound copy, Appendix E lists the resource classes as well.

And then you can also search for them on the online help system. Inside the SMS Admin console, go to online Help, and you can search for WBEM classes and attributes. You'll be able to find that information as well.

Now, a couple things to help you out here. For SMS 2.0 Service Pack 1, we just recently came out with a server QFE bundle. It's a set of hotfixes that you may want to apply to any large sites: when you have a lot of sites in your hierarchy, or you've got a three-tier hierarchy or an upgrade, and so on. They are a set of hotfixes that have been bundled up into one patch.

In that server QFE bundle, we have come up with a fix for some of these queries. We have rewritten the query statements to SQL statements to make them process faster. If you get the server QFE bundle — not the client QFE bundle, but the server QFE bundle — and you apply that to your site, that will recreate your queries with new syntax that should process faster. In Service Pack 2, that will be built in. If you have Service Pack 2 or one of the later releases, you'll have faster-processing queries, because they rewrote those queries.

Again, we recommend that you use those as samples and build your own queries, targeting what you really want, and create your own criteria, and so on. But that will help you out a bit.

The last topic here on creating custom queries, the last bullet on your slide, is the ability to export and import custom queries. When you create your own admin queries, through the admin console, we don't automatically push those queries down to child sites. So if you're at the central site and you create a pretty cool query, let's say you're looking for all computers that don't have a specific piece of software installed, we don't push that down to your child sites automatically, like we do in collections and packages and advertisements.

Your child sites may want to have that same query syntax. So there are a couple of different ways you can take that query that you created, export it, and then import it down to the child site.

One method is by using a resource kit utility called Qryedit.exe. For the Qryedit.exe utility, when you run it from a command line, you would do something such as qryedit /export , and then specify a file name in quotes. It would take all of the custom queries that you created and dump them down to a text file. You can then take that text file and either edit it manually, or just take it as it stands, and send that down to a child site, or some other site, and have them import it.

When it dumps the queries out into a text file, it dumps three different lines that are appropriate for you. The first line would be the name of your query, then there's a blank line, then the next line is something like a 3 0 0, another blank line, then the actual syntax of the query.

If you're editing the text file that's been created, and you want to delete any of those queries or do a cut and paste, make sure you get all those lines: the line that has the query name, the blank line, the line with the 3 0 0 on it, the next blank line, and the entire SQL statement. Then you can copy that into another text file or delete everything else out.

Then just take that text file and give it to another SMS site. They can import that data into their site database by doing a qryedit /import with the name of the file. That will take a text file and import it into your site database.

Qryedit /export will take your admin-created queries and dump them to a text file, and then qryedit /import will import admin-created queries into your site database. So it's very, very cool, whether it's a matter of pushing between sites, or when you create queries, you want to keep those queries, and you reinstall your SMS site, trying different designs. Or if you're just testing different things, you can re-import those queries for all the new sites you create.

The next way of importing and exporting queries is again through another SMS 2.0 Resource Guide utility, the SMS Site Properties Manager. The SMS Site Properties Manager is a graphical interface that allows you to collect information, such as collections and queries, and propagate it down to child sites. So it allows you to take site information, site settings, dump it into a specific text file, and then import that text file at another site. You can use that to cache your queries back and forth, as well.

Again, we want you to create your own queries; use ours as a sample. It's going to take a while to get familiar with the Query Builder engine, because it is very powerful and it's quite a bit different in 2.0, but we have some information on creating queries in training materials, as well as in the Admin Guide.

Then you have to find what resource classes you want to go to: what object classes, whether it's hardware inventory. And discovery data, whether it's software inventory data, and so on. Then create your query. If you need to, you can export and import those queries to other SMS sites.

Next, we'll talk about software distribution. What are some of the software distribution issues or misconceptions that cause difficulties for people? The most commonly reported problem for SMS, in regards to software distribution, is that a specific package didn't install properly. The majority of issues with software distribution are because of the way the software was installed. Not SMS, but the advertised program.

The problem is that SMS does not do software installations. SMS is truly a delivery system and a status reporting system. SMS itself does not install software on computers. SMS delivers packages to distribution points. It delivers programs to client computers. It can kick off a program at a client computer, in other words initiate Setup.exe. But SMS does not control how that package is installed, that piece of software.

SMS is truly the deliverer of the files to the distribution points, and then the appropriate files from there to the client access point. Then, when a user launches an advertised program, either manually through the wizard, or automatically through the advertisement code being mandatory, SMS will launch a program for that user, but SMS is then out of the game.

SMS doesn't control how the program is installed, it doesn't do anything else. It kicks off the setup program or whatever the advertised program is, and then that program runs on its own. If you want to control how that program installs its application, then you may need command-line switches on Setup.exe. You may need to have .ini files or .iss files, or you may want to use Windows Installer and create MSI scripts, and use MST files or other MSI files to control the installation.

SMS itself does not install applications. We deliver the bits, we launch off the program, and then we report status. We'll tell you that the program was received. We'll tell you that the program was launched successfully. We'll tell you that it exited successfully.

But again, we don't do the installation. Other systems do the installation. For example, the SMS Installer. The SMS Installer is an add-on utility for SMS 2.0, and it can do a repackage process. It can create an installation script to be used with a product installation to control the installation of that product. And you can use SMS to deploy SMS Installer packages, as well as Windows Installer Packages, WINInstall, or InstallShield, or any number of installation technologies. SMS itself just does not do installations, it just does delivery and status.

The other area that causes some confusion for customers and consultants is the actual context of who is running that advertised program? And there are three different contexts that software distribution or advertised programs can run under.

The first context is the context of the logged on user. So I'm logged on as Wally, I run an advertised program. If it's going to run under my context, it has all the same permissions that Wally would have. If Wally's an admin, your advertised program would run under admin context. That's not available as often, anymore, because many more programs require administrative access, or administrative rights, before they can install. So running under user context is not as viable as it used to be.

The next method is running in an administrative context. When you create an advertised program for SMS, you can specify for the advertised program, that it must run with administrative rights. When you tell an advertised program to run with administrative rights, SMS does not check the logged-on users rights at all. We don't look to see, "Well, does Wally have admin rights or not?"

We will immediately go ahead and run that program in the context of a different account. By default, that account would be the SMSCliToknAcct&. That's a user account that's created in the local SAM of a Windows NT Workstation computer.

If you look at the properties of that account, it is not a local administrator by default. When we run a program that requires admin rights, we'll take the SMSCliToknAcct&, we'll add it to the local administrators group, we'll launch that advertised program, and as soon as that advertised program completes or exits, we'll remove the SMSCliToknAcct& from the local administrators group.

That may sound to you like a security hack or a breach, but it's not because the SMSCliToknAcct& has a randomly generated password, and no user would know what the password is for the SMSCliToknAcct&. They couldn't go out there and do anything else using that SMSCliToknAcct& when it was a member of the local administrators group. We control that pretty closely.

That works in a lot of cases, when you need to have administrative rights. However, there is one specific case where that process won't work. And that is if you need access to a third file server on your network. Your client computer will already have a connection to the client access point, where it's reading the advertisement data that it copies data from. It'll have a connection to the distribution point, where the physical package files are located.

But let's say the program you're advertising is a network application, and your installation script points to a third server on the network. In the network setup, it does a \\Server2\Apps\, and then some other application. In that case, the SMSCliToknAcct& will not be successful in accessing that third server.

The SMSCliToknAcct& is not a local user. It doesn't have local user or domain user privileges. It wouldn't be able to access the network. In that case, you would want to use the Windows NT Client Software Installation Account. That account requires preparation before you can use it.

First you would have to create the account as a domain user. You'd create the account in your accounts domain as a domain user. It doesn't need to be an admin, just make it a domain user. Then, inside the SMS Admin console, you tell SMS what the name of that account is. You do that under Site Hierarchy, your <site code>, Site Settings, and then Component Configurations. Under Site Settings, go to Component Configuration. And then look at the properties for the software distribution components.

The last option on the General tab of the Software Distribution Component Configuration properties page is Windows NT Client Software Installation Account. Just click the Set button and type in the domain name and user account name of your Windows NT Client Software Installation Account, as well as the password.

The next time the client does its standard 23-hour maintenance cycle, it will download that new account information and place it, encrypted, into the registry of that client computer. It won't be resident in the local SAM, it'll just be in the registry. To tell SMS to use that account, specify that your advertised program run with administrative rights. Then, right below that radio button is a check box that says Use Windows NT Client Software Installation Account. That's all you have to do.

When you select that option, when the advertised program runs on the client, the software distribution code for that regular client, Smsapm32, will go ahead and detect that it's supposed to use that account. It'll go to the appropriate registry location, decrypt that account information, add it to the local administrators group in the SAM of the workstation, and run that advertised program. As soon as it's completed, it will remove that account from the local SAM. And it will be in the registry again, in an encrypted mode.

We don't expect to have to use this third method, in other words the Windows NT Client Software Installation Account, too frequently. Most programs should be successful with either the local user context, or by writing under admin context with the SMSCliToknAcct& itself. The third option, the NT Client Software Installation Account, is only if you need another server to complete that installation or to run that advertised program.

With those things in mind, your software distribution should go a little better.

Okay, the last area to look at for common product misconceptions is the process of removing SMS client software. If you've tried this, you've noticed this already, that no matter which client uninstall method you use, it doesn't remove every single reference or aspect of SMS client software on the client computer.

Whether you're running SMSman, the Systems Management Installation Wizard, and you go to the first page, the last option is Remove Systems Management Components. You can use that method. You can use the Resource Guide utility 20Clicln.bat, the batch file there. You can manually add a registry entry called SMS Client Deinstall, and set it to true in your client registry structure, and then stop and start the SMS client service. Or you can remove your clients by removing their subnet boundary, and just letting the client deinstall automatically.

Whichever one of those methods you use, none of them will remove the entire reference to SMS from that client computer. SMS client removal usually leaves a number of different things, and there are very good reasons why we leave those resources.

First off, it leaves the Windir\Ms\Sms directory structure. It leaves that for two reasons. There are often DLLs that are in use that we can't remove until the next reboot. So, because the DLLs were used and were running when SMS was installed and running, we can't yank those out, because they're active DLLs. So we just mark them for deletion.

Also, in that directory structure, under Ms\Sms\Core\Data\, we leave the Smsuid.dat file. The Smsuid.dat file lists your SMS unique identifier for that client. The reason we leave that is, if you've just deinstalled your client, and now you decide to re-install the client again, we would re-install with the same user unique identifier that you had in the first installation. That way, when you are re-installed, you would attach back into the SMS site database to your old discovery data, and your old hardware/software inventory. If you don't do that, you'd have to re-create the hardware/software inventory.

We also generally leave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Sms, primarily because that again has a registry key for your previous unique identifier. And, if the SMS remote control agent was installed, it has security permissions set at one of its registry keys that we couldn't blow away anyway. You'd have to reset security permissions on the SMS client directory structure.

We also leave Windows Management Instrumentation. That's installed as a service on all of your 32-bit clients. We don't remove that when you uninstall SMS, primarily because Windows Management is now part of the OS. If you have Windows NT 4.0 Service Pack 4, it's on the Service Pack 4 CD. It's also on Windows 98. It's installed automatically, and it is very integral to Windows 2000. Because it's part of the OS, and other applications and utilities might be using Windows Management, we don't remove it automatically.

We also leave your Windir\Smscfg.ini file. Again, that's because it has your SMS unique ID in there. If you re-install, we give you the same ID, so that you can attach to your old data.

We also don't always remove the Windir\Profiles\; there's a set of profiles in there that all begin with SMS. We can't remove those, because some of those profiles are in use as well, so they're left around.

And lastly, we don't generally remove the SMS_Local_Dir environment variable. Again, the reason being that it points to the path to where your SMS client software was installed. So, next installation, you would re-install at the same location, have access to all of the same files, and appropriate the SMS unique identifier.

If you decide that you really want to wipe everything of SMS off of this client, you can manually remove all these things that I just talked about. You can remove your Ms\Sms\ directory structure. It would require a reboot to unhook the DLLs. You can remove that registry structure. You can manually remove Windows Management, but we don't recommend that at all, because there may be other things using at the time. You can remove the Windir\Smscfg.ini file. You can reboot and remove your profiles, all the ones that begin with SMS. And you can remove the SMS_Local_Dir environment variable.

General client uninstallation does not remove everything. And the reasons generally are we want to leave information so that if you do re-install your client computer, then you can have access to your old hardware and software inventory data in the database, and not have to start over from scratch. And some things were in use, so we couldn't get rid of them automatically.

That will help you out in deployment and with testing the removal and re-installation process. If you do re-install, we'd go ahead and give the client the same information, the same resource ID it had last time, the same SMS unique identifier, and attach you back to your old database information.

That's the end of the common product misconceptions. Now, if you want to find more information out about SMS, we've got a number of different resources here for you. First off is the SMS 2.0 Admin Guides. It depends upon how you got SMS 2.0; you may or may not have a hard copy of the Admin Guide. If you do require a hard copy of the Admin Guide, it can be ordered. And I listed the part number for you (part no. 271-00617). There are a couple different 1-800 numbers you can call, which depend on how you got SMS 2.0, the CD itself.

One note of caution is that the hard copy of the SMS 2.0 Admin Guide has not been updated since RTM code. Your online version, on the SMS 2.0 SP1 CD, or the Service Pack 2 CD, will be more up-to-date than the hard copy. But some people still want to have a hard copy. So I would just go to Start, Programs, then Systems Management Server, and go to SMS 2.0 Administrators Guide. That will be the most up to date, along with the Release Notes, for whatever version you're running. Because there may be a couple addendums in there.

I mentioned a couple of utilities that were in the SMS 2.0 Resource Guide. If you want that, the ISBN number is 0-7356-0928-4. And you should be able to find that in all the larger bookstores; Barnes and Noble and a lot of other ones have that.

The SMS 2.0 Resource Guide is available separately, through that ISBN, or it's also part of the Microsoft BackOffice^® 4.5 Resource Kit. So if you get the BackOffice 4.5 Resource Kit , you'll get the SMS 2.0 Resource Guide with it. The BackOffice 4.5 Resource Kit ISBN is 0-7356-0583-1.

Then, if you want to look at the official Microsoft Systems Management Web Site, go to http://www.microsoft.com/smsmgmt/. You'll be able to find information about new product releases coming out, such as Service Pack 2 information. That's where you can go to sign up for the Service Pack 2 beta, if you want to become a member. There is product information, downloads, white papers, etc.

It's highly advantageous for you, if you haven't already taken training, to look at the official Microsoft Curriculum, some of the MOC courseware that can be obtained through any of your CTECs, Certified Technical Education Centers. There is also a self-paced version that was published through Microsoft Press.

If you need support, and you wanted some self or peer support, you can go to the Microsoft product newsgroups. They're at msnews.microsoft.com, and on that server, go to microsoft.public.sms. That's where you'd find the SMS newsgroups. They're not monitored directly by Microsoft. You may find a Microsoft employee that will go up there and answer questions occasionally, but there's no official Microsoft support at that area.

However, it's peer support, and you will see different areas there, different newsgroups for specific aspects of SMS, such as installation, setup, hardware inventory, software distribution, or whatever. It's a great way to see what others are encountering with SMS, and to ask a question; hopefully, they'll have an answer for you. And if you have contacts at PSS through your Premier Support Contract, that's an avenue to go through as well.

Hopefully that information will help you out. I gave you some information about the common problems people have with SMS, and I discussed what some of those issues are. In the session next month, we'll go to the next level, which is site design issues: some of the issues that people encounter when designing their SMS sites that caused less than successful deployments.

Thanks, and now we'll look at questions.

Heidi: Okay, thank you so much, Wally. Just a couple of notes here. The SMS session that Wally was referring to next month is on April 13. Also, Wally made a couple of references to past sessions, and the two that we have available at this point are from January 25 and February 3. The January 25 session was on SMS security. The February 3 session was on SMS accounts. And all of that information is on the Support Online site with the Past Support WebCasts information.

A couple of additional notes. We are very interested in your feedback regarding the Support WebCast program. You can submit your feedback to the feedback@microsoft.com alias. We really encourage you to send us any feedback you have regarding the program overall, past sessions you've seen, sessions you'd like to see in the future, and just comments; let us know what you think, so we know the direction we should be taking this program. It's still a pretty new program, and we want to make sure we're hitting the mark with what we're doing.

The Q&A portion of the Support WebCast is intended to encourage further discussion of the Support WebCast topic at a conceptual level. One-on-one product support issues are outside of the scope of the Support WebCast. If you do need technical assistance, please submit an instance on the Web, or call Microsoft Product Support Services to speak with a support professional.

Okay, now that we have all those notes aside, let's go ahead and get into the Q&A session. We have had several questions submitted.

The first question, and I'm sure it's on everybody's mind, is: When is Service Pack 2 going to be available? Is that something we have publicly announced?

Wally: We have not announced an RTM date for Service Pack 2. Service Pack 2 is in beta; it shipped out a couple of weeks ago, I don't know what the exact date was. I've been traveling too much, so I don't remember the exact date, but it was some time in mid to late February that Service Pack 2 beta was made available.

Service Pack 2 RTM — that will depend on many things: the feedback from our beta sites, how well the Service Pack 2 beta has solved the issues that they've seen, how well it has prevented any new issues from occurring, and verification of no degradation in performance, or any other systems, and just how well it's going. So, there's no specific timeline on that. It'll be whenever the customer feedback says it's ready.

Heidi: The next question is: This morning I advertised the latest McAfee Superdats to start at 7:00 A.M. At 7:32, the distribution point refresh kicked off and failed because the resource was open. All the clients after that point failed to find the package on one, which was the busiest site server. Is this a known issue? I had to go to the Server Manager for this server and kill the process that had the file locked to be able to refresh the site after that. I'm planning to change the refresh time to be the middle of the night, but did not know this was a requirement.

Wally: The one issue that there could be here is when you create a package on the Data Source tab, of the package itself, the package properties. There's a check box down at the bottom, and when you're doing a package update or refresh of your distribution points, by default you may have users connected there, if they're trying to actively run that package at the concurrent time.

If there's a user connected to that resource, then there's a check box down at the bottom (I believe it's the Data Source tab in your package properties) that specifies to disconnect your users from the resource. So that may be all you would have to do, is select that check box to force the disconnect of your NT clients from that resource. And then they won't be accessing it, and you can successfully update your distribution point.

If that was already selected, or that wasn't the case, then I've not heard of that issue before. It may just be an issue with your McAfee product, that somebody had a hook open to it and it would have to be refreshed later on.

It's always advantageous to refresh after hours, when you have less chance of users accessing your distribution point. If that didn't help, then we'll have to get to PSS on that. But that would be the first thing I would check, is to see if you're selecting to force users off the share point.

Heidi: Excellent. Thanks, Wally. The next question is: Queries is an excellent feature, but we need a way to save and print the results. Is this capability coming? Crystal Reports is not a good substitute for us.

Wally: Queries, within MMC 1.1, which is what version of MMC we install on Windows NT 4.0, do not have printing or exporting capabilities. However, to accommodate or work around that, go to the support bundle on your SMS 2.0 CD (so if you go to your SMS 2.0 CD in RTM, all the files were expanded out for you automatically). In SP1 and SP2, it's an executable you have to run.

If you run your Support.exe bundle, and unbundle all the support files (the support files are basically a preview of the SMS 2.0 Resource Guide), there are a couple utilities that can help you out. There is an SMS extract worksheet for Excel. Basically, that allows you to start up Excel with this worksheet. Connect up through your SMS Provider into your site server, and then using that, it will display a list of all your SMS queries inside your SMS 2.0 database.

You can then select what query you want and run that query from within Excel, and then it will display all the results within Excel. And certainly within Excel, you can print and export. So you have the ability of doing that from Excel. On the official SMS 2.0 Resource Guide CD, there's another set of utilities just like that for Microsoft Access. You can take your resource, your query into Microsoft Access, and run the query from there, and print.

The last option would be, once you get Service Pack 2, you can install on top of Windows 2000. And with Windows 2000, it automatically installs a later release of MMC, MMC 1.2. MMC 1.2 does not have direct printing capabilities, but MMC 1.2 does have the ability to export data. So you can run a query within the SMS Admin console, then export the results of that to a different file format. Then take that into Notepad or some other utility and print it out.

So there are different options; it just depends upon what version you have. Look primarily at the Resource Kit CD or your Resource Kit files on your SMS 2.0 CD, and look for the SMS query extract utilities. That's to start with, and then MMC 1.2 will help out as well, in the future.

Heidi: The next question is with regards to Network Discovery, and it is: Why is a subnet mask required for DDR creations?

Wally: The subnet mask is required because of Windows NT Remote Client Installation. And Windows NT Remote Client Installation is an installation method used to install client computers automatically. If Network Discovery finds a Windows NT client computer, and you have this installation method enabled, it has to know whether or not your discovered resource is a member of the appropriate site boundaries, in order to push out the client software or not.

If we don't put the subnet mask in there, we'd have no idea whether that resource was assigned to this site or not. And then we may not push out the site, the SMS client software, when you wanted us to. Or you might push it out when you didn't want us to. We need to have the subnet mask so we can determine what subnet you're a member of, and determine whether or not you're part of the site boundaries.

Heidi: The next question is also on Network Discovery, and I think part of it was covered in this past question, but I'll go ahead and ask it. Is a subnet mask required to perform Network Discovery, or only to report resources found? In other words, does lack of an appropriate subnet mask effectively stop Network Discovery from performing discovery?

Wally: No, Network Discovery itself has no concept of a subnet mask. It will go out and query your subnets, your routers, your DHCP servers, your domain enumerations, or domain browsing regardless of subnet mask. It will go out, generate all that traffic, and discover all those resources.

However, Network Discovery, once it's found a resource through whatever method of discovery, browsing, pinging, or whatever, and before it can export that resource as a DDR, it does require the subnet mask as well as the IP address. By not having a way of finding a subnet mask, Network Discovery won't know that until it tries it. It will try to do the discovery, to discover as much as it can. And then it will report what it was successfully able to find a subnet mask for.

Heidi: Okay, the next question is on database maintenance and deleting aged tasks. And the question is: The default setting on several tasks, such as delete aged DDR, delete aged inventory, is set to 90 days. I spoke with an SMS support professional a few days ago about parent to its child/parent database consistency. It was suggested to decrease my delete aged tasks, which I have already done. It's now set to 15 days.

So the two questions: with that background, are: Does aged mean that the system has not answered heartbeat, etc? System is not on the network anymore. That's question one.

Wally: Aging is the process of refreshing or updating the Discovery data. So if the resource has not received or generated an updated discovery record for, in your case 15 days, then it's considered aged, and it would be removed.

Heidi: So the follow-on to that is: What do I get out of keeping even 15 days of aged data, besides a bigger database?

Wally: Suppose you were to drop your aging factor down to one day. Let's say your clients don't log on every day. Let's say your user goes on vacation for a week. If you had your aging factor set at a day or a week, and a computer had not been updated or refreshed within a week, that computer would be automatically deleted from your site database.

When that happens, we remove not only the discovery record, but also all the hardware inventory data and the software inventory data. So now, when your user comes back from vacation, and they start up their computer, it generates a new discovery record, and SMS will think it's a brand new client computer.

And so the next time you try to generate inventory, it's going to be a full complete inventory. Actually it would try to send it out across a delta, and SMS would say you can't send me a delta because I don't have full inventory for you. So it'd send you a resync and make you do a re-think inventory the next time. So you lose all your existing hardware software inventory data when you delete your resource. That's why you don't necessarily want to have your aging factor set too low.

Heidi: Okay, terrific. Moving on to the next question, it's with regard to custom queries. Could you clarify the server QFE bundle number? I applied Q246527, which I believe is the client hotfix bundle. Also, are both of these included in Service Pack 2?

Wally: The client hotfix bundle is the one you listed: Q246527; that is the client hotfix bundle. The server hotfix bundle is Q250850. So Q250850 is the server hotfix bundle. And both these bundles will have all the appropriate fixes already made in Service Pack 2. So when you install Service Pack 2, you will not need either of these hotfix bundles.

Heidi: The next question is: How do I redistribute a package? When a package is distributed and installed, showing completed in the advertised programs monitor on the client, and the installation is broken by a user, I can't reapply the advertisement. Do I have to create a new program for the package?

Wally: This is discussed fairly well and in good detail in your Service Pack 1 Release Notes. In the Service Pack 1 Release Notes, if you search on "software distribution" or go to the software distribution section, there is an entire section in there on how to redeploy advertised programs.

One of the things I'll first say is that, if you ran the program, and it's marked as complete in your Advertised Programs Monitor from the client, you can always rerun a completed program. Even though the advertised programs wizard on the client might say it's already been run, it's not bold faced anymore and it says it's been completed. You can just select that program, that advertisement, and run it again, and it will go ahead and run. You can run the same advertised program over and over again as many times as you want to on the client.

On the server end, if it's a process of certain number of clients failed, and you want to redeploy your advertisement, there are a couple different things you have to do. SMS does track by program names as you suggested, so if you just wanted to deploy the same program, it would not work, because it would say, "Oh, I've already run that program."

So you'd either have to create a new program, or you could, if it was something like a mandatory assignment, go ahead and add an additional schedule to your assignment. So if you kicked it off Monday at 8:00 A.M., just add another schedule to say, "Run Tuesday at noon." And it will treat it as a recurring advertisement, and it will run again. But look in the SP1 Release Notes for full details on that.

Heidi: Okay. The next question is about uninstalling. And that is: When removing the 2.0 client, are there any problems with also removing HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Nal\?

Wally: When you remove the client computer, then you would want to remove NAL. Generally our client in the installation process does remove NAL automatically. So if it's still sitting there, then it would indicate to me that the client installation did not complete properly. Or your computer is not just a computer, but it's a site server or some other site system that has server code on it, so it needs the NAL key as well.

However, if you're removing all SMS references from that computer, you can certainly delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Nal\, because that's only used by SMS.

Heidi: I'm not sure if we're going to be able to field the next question, but we might be able to check into it, and that is: Is the SP2 beta available on the TechNet collection along with the beta software?

Wally: I don't know. My guess would be no, because I know it was a fairly closed and limited beta. But I don't know if they've opened it up so that everybody can get it, only without technical support. So I honestly can't answer that question for you. I have no idea whether it's in a TechNet beta or not.

Heidi: The next question is with regard to value sorting in criteria properties, and the question is: In the Criteria properties area on the query, when you click on the Values button, is there a way to sort the values alphabetically inside the window?

Wally: Not currently. That's a known issue right now. It's not sorted, or rather it's sorted in a specific manner that you don't have any control over. So currently, there is no method that I'm aware of to sort those values. That is something that they're aware of, and I haven't heard of any updates for SP2 on that. But it is something that the product group is aware of.

Heidi: The next question is about SP2 once again, and I do want to emphasize to everybody on the call, that we are limited in the amount of information we are able to divulge about SP2 at this point, because it is still in beta. But the question is: Will there be a GUI interface for the site backup and recovery in SP2?

Wally: There already is a GUI interface in RTM and SP1 for backup. There is the database maintenance task to kick off the SMS site server backup process. So that's a GUI interface.

However, for Service Pack 2, there is no additional functionality or utilities for performing a site recovery. There will be a couple utilities for doing a restore that will come out outside of SP2. These are fine for you to know about.

One of those is the Site Recovery Expert. The Site Recovery Expert you'll find up on our Web site, which I pointed you to earlier: http://www.microsoft.com/smsmgmt/. It should be there by the end of March. That's going to be an interactive Web application, so you'll run this utility from our Web site, and then it'll prompt you and ask you, interactively, for information about your site.

So you give it all the information about your site: what agents you had installed, whether you're recovering the site server, or what box you're recovering. Where was your SQL Server, where was the SMS Provider? What security are you using? There are many different questions we'll ask you.

Once you supply all the information, we will generate a list for you of all the tasks that you would have to complete to do a site recovery, such as reinstalling NT, if NT's blown up. Or reinstalling SQL, reinstalling SMS, restoring your database, and so on. We'll give you a list of all the paths that have to be completed manually. There's not an automated method for doing this right now.

And then, if you weren't familiar with what some of those tasks were, such as if it said, "increment your replication manager transaction ID," you could click on that task and it would take you to a procedure list for the exact procedures: open up Registry Editor, go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS components\SMS executive\ and so on. It would tell you exactly how to do so. So that will give you a list of tasks that you have to perform manually.

And again, that one should be up on our Web site by the end of March The other utility is going to be coming out sometime after SP2, hopefully before Service Pack 3, the next release, but they're not positive on the exact date it's going to be available. That's the Site Recovery Wizard.

The Site Recovery Wizard is a wizard application that you will run on your site server, and it will help you — not with restoring your site server locally, you still have to do that manually, there's no automated process for doing that — with reinserting your site into a hierarchy. It will put you back in the site if you had a parent site when your site failed, and it will connect to your child sites and recover any data from your child sites that belongs to you.

So it's a pretty neat utility that will help you reinsert yourself properly back into a hierarchy, which is the biggest problem our customers have had with restoring sites, is hierarchy-related issues, and serial numbers and transaction IDs, and so on. Those two utilities will be out and available at some point. The expert on the Web site soon; the wizard will be downloadable, probably from the Web site, or it will be a future release. We're not sure, and it will be a while yet.

Heidi: Okay. The next question is: Is there some way to get the SMS site information supplied in SMS Trace into another program, like Visio or PowerPoint?

Wally: SMS Trace is just a utility that was written by one of the engineers to look at SMS log files. So it's just a utility to look at SMS log files, it doesn't do anything other than process log files. Personally, I use Notepad to look at our log files. I find it much easier to work with than SMS Trace.

However, to answer the question: no, there is no automated procedure for taking any information from an SMS Trace or an SMS log file and pushing it into Visio. Now that I think about it, you may not be referring to the SMS Trace utility, you may be referring to the SMS function called Network Trace, which makes more sense for Visio.

Network Trace is an SMS Admin console process for creating a Network map of your SMS site, and the paths to the site systems, and that's probably what you're talking about, instead of the SMS Trace utility for the log files.

Currently, there's no method that I'm aware of for exporting that data into any other format. However, you have heard that we have acquired Visio, so they're now a Microsoft product. You may look for something to happen in the future. I've not heard of anything like that, but you may look forward to that function, now that it's one of our products.

Heidi: The next question is: Is there a difference between Crystal Reports and Crystal Info with regards to SMS? If we buy Crystal Reports 8.0, can this be added to SMS Reporting Tools, and if so, does it work well?

Wally: I can't comment on how well Crystal Reports the full product works, because it's not a Microsoft product, and I've never used it. You are certainly allowed to upgrade to the full product. The Crystal Info we supply with SMS is basically kind of like a run-time version of Crystal, just to run a report. You are allowed to generate your own reports, but it's fairly limited, and you're missing some features.

But you can purchase the full product from Seagate and install that. If you do so, I honestly do not know whether that launches by kicking off Crystal Reports, Crystal Info, and our Admin tool. Probably not, but I honestly don't know, because again that's their product. They would have to have it interface with our SMS Admin console.

But you certainly are welcome to use it. A lot of people do upgrade to the full product, as opposed to using the limited version we have built in. And then people have varying degrees of success, just because of their familiarity and what they need to get out of Crystal.

Heidi: The next question sounds like it actually is leaning into a support question, so we're going to need to limit our answer to this, if Wally knows the answer to whether it is a known issue or if it's something that the individual should be contacting product support about.

The question is: When I run the SMS Extract to Excel utility, I get a message stating that my query has prompted information and the extract is halted. My query does not have prompted information. Is this something that is a known issue?

Wally: I've never heard of that before, so I can't tell you whether it's a known issue or not. It may be known, and just not by me. But I'm on the internal aliases, and I've never heard of that issue.

One thing to look for is to make sure you run the most updated version of the SMS Extract utility, because of different service packs and so on. That utility has gone through a couple different releases, and you want to make sure that you're running the latest version of it. But if your query itself is not a prompted query, and the SMS Extract utility is prompting or stating that it's a prompted query, I've not heard of that, so you'd have to contact PSS.

First off, verify you've got the latest version and look at the version on the SMS 2.0 Resource Guide, versus your SP1 CD. Determine which one's the later version, and use that one. I believe there was also an update to that utility that you can get through PSS. I know there was a problem with it, I'm just not aware of what the problem was. Other than that, you'd have to go to PSS, because I've not heard of that at all, and I've never seen that happen.

Heidi: The next question is on Network Discovery, and it's a follow-up to the question about the subnet mask requiring DDR creation. And that is: When the site boundaries are specified, the IP address alone would suffice, wouldn't it? Otherwise, it seems that there would be other more serious problems in the network if that weren't enough.

Wally: When you're specifying site boundaries, if you look at the bottom of the Site Boundaries property page, you're correct. You do just enter an IP address; that's all you enter for your site boundary, is an IP subnet. You don't specify what the subnet mask is.

However, if you look at the bottom of that page, there's a note there. It's got the yellow warning sign that says client subnet mask will be used for site assignment. What that means is that the site server itself, when it's processing discovery records, doesn't care what the subnet mask is. It just looks at the IP subnet. And in all DDRs that are created, you list the IP subnet, whether the client's creating the DDR, or Network Discovery's creating the DDR. You specify the IP subnet; that's what SMS is looking at. The site server doesn't know what you r subnet mask is.

So when you do a client discovery, it looks at its IP address, its subnet mask. It determines what IP subnet it gets located on, and it specifies that in the DDR. It does the exact same thing that Network Discovery's trying to do, specify what the IP subnet is. To do that it needs to have the IP address and the subnet mask. Then it can tell us in this DDR what the subnet is. Without it, it doesn't do us any good. We have to have the subnet mask for Network Discovery to report a resource.

Heidi: The next question is about threshold settings. We are continually getting component status warning messages, and SMS documentation says not to change thresholds until you are familiar with what they do. However, we haven't found a good resource for what these thresholds should be. Is there a good resource on threshold settings, with a lot more in-depth information in the documentation?

Wally: The most up-to-date and in-depth information on the status system is in the Admin Guide, I believe it's Chapter 25. And the SMS 2.0 Resource Guide; there is some information on the status system in there as well.

As far as what your threshold settings should be, I don't think you're ever going to find Microsoft telling you what you should set those to, because each customer is going to have a unique configuration. You're saying you get a lot of component status messages and you want to change your thresholds. Well, other people with the exact same settings may not be getting warning messages, because of their component status.

If we went out and told everybody, "Okay, change your settings to 10,000 for warnings and 20,000 for errors," that might cause problems for some customers. We're not going to tell you how you should set them, it's going to be a unique configuration for each individual site.

What you need to do is analyze the error messages you're getting. Determine whether they're valid or not. If it's just purely because you have a lot of status messages in your console, in your database, and it's generating warning or critical messages because of the number of informational messages, you can set that threshold, as you were talking about, in your Component Status Summarizer configuration properties. So you can set that.

So it could be a matter of, in your site, looking at how long you're keeping messages for. How often SMS, the database maintenance task, is removing aged status messages. And then how many messages are being generated to your site, and whether you can live with or without them. And then set the appropriate status summarization up to whatever value you want.

We warn you not to modify the status system until you're sure of what you're doing. We don't want people going in there and changing status configuration until they're familiar with it, to see what information they have, what information is being provided, and how important that information is to them. Then, once you've determined all that information and you're comfortable with what information we provide, then you can change those to whatever values you deem necessary to your site, so that you're getting out of the status system what you deem necessary, what is important to you.

So, that's not a good answer for you, but that's the answer that you'll get from anybody. There's no answer that tells you to always set this to a specific value, because your site's going to be different than somebody else's site.

Heidi: Okay, thanks Wally. If I create an SMS test site in a different domain on the production network, could this cause problems in the production SMS site?

Wally: If you put two SMS sites in the same production site, that means you're going to be sharing subnet boundaries, most likely. The problem would occur if either of those two sites ever reference the other domain, or the other site. So, for example, you set up your test site, and your test site is in domain A. Your production site is in domain B. If your test site ever did a discovery of any resource in domain A, such as a Network Discovery, there's certainly potential for SMS discovery resources in your production site.

If that were the case, because subnet boundaries would probably be the same, and because you're on a single site, you're probably sharing the boundaries, SMS could determine that the resource belongs to the test site as well. Now your SMS client could be a member of both sites, the production site and the test site. That can cause difficulties with scheduling components; it might have one component enabled and one site that's not enabled on the other site. Remote control will act a little bit differently; we'd go with whichever setting is the most restrictive or most secure for the client. So it could cause difficulties.

If you do that, you just have to be very careful that you never have either site reference the other site's domain. And that's not just in Network Discovery, but in any other discovery method as well. If you keep those two totally isolated, as far as discovery methods, then you should be fine.

In the worst case, your clients would be a member of both sites. They would generally work with their primary site, which would be their production site, as long as they were existing clients. And any new clients might pick the test site over the production site, and have the wrong settings.

Heidi: Okay, excellent. Thanks, Wally. We have answered all the questions that were submitted during today's session.

I want to thank all of you for joining us today, and I do hope this information was useful for you. Once again, we are very interested in your feedback regarding the Support WebCast program. You can always send your feedback to feedback@microsoft.com. Be sure to include "Support WebCast" in the subject line, if you send us any feedback.

We do hope that you join us again in the near future. Have a great day. Thank you, and good-bye.