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

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

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

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

I'd like to take a brief moment now to introduce Wally. Wally joins us just about every month to give SMS sessions. He's been a Microsoft trainer since April of 1992 and has been involved with SMS training since the SMS 1.0 beta. He 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 for our Microsoft Support Professionals. Thank you so much for joining us today, Wally.

Wally Mead: Thank you and welcome to our Common Site Design Issues session. I won't spend any time introducing myself beyond what Heidi said. So just welcome.

As we go to the next slide, let's first start off with "Why the Need for This Session." And if you were in last month's session, I covered this as well. But I'll do it again for any new people.

The reason for this session is that not all of our SMS 2.0 deployments are as successful as they could be. And in an effort to benefit other customers who are close to deploying, have just deployed, or are designing their SMS 2.0 sites, and get them as much product information as possible, we came up with this series of sessions.

To generate the data for these sessions, the SMS product group talked with many different resources. They talked to some of our large customer sites (our early adopter customers), they talked to some consultants (internal and external to Microsoft), and they talked to some solution providers. And while talking to those three different resources — again, multiple people in each of those resources — they came up with a common set of issues for why the sites were not as successful as they thought they should be. There were three main reasons for the unsuccessful deployments; and when I say unsuccessful, I mean they were not as successful as they could have been.

The three reasons are first, misconceptions about the product functionality. The customer, the consultant, or the solution provider didn't have all the information they needed about SMS 2.0 to get it properly implemented or to have it function they way they expected it to. The next most common reason was improper site designs. So whoever had designed and implemented the site did not do so in the way Microsoft recommends designing SMS 2.0 sites. And that caused some issues. And the third area is product design issues: there are actually flaws or bugs in the product that caused problems in the deployment.

What we found was those deployments that had good training, good product knowledge, and good designs were the most successful in their deployments of SMS 2.0. So again, we're creating this series of sessions to try to improve the product knowledge and to get some of these issues out in the open so that other people won't encounter them.

This session is going to cover the site design issues: areas in the design of the site for a specific company that were not as efficient as possible, and which led to the site being not as efficient or responsive as the company expected it to be. In the March 14 2000 session (http://support.microsoft.com/servicedesks/webcasts/wc031400/wcblurb031400.asp), we covered the product misconceptions — the areas of the product where people were confused about what the product was supposed to do or not supposed to do.

Let's jump in. Go to the next slide, "Session Agenda" (slide 3). The areas we want to cover in this session are, first off, performing a phased roll out. It's very important for you to do a phased roll out when you start implementing the product. When you don't do a phased roll out, you may cause some problems. And we'll discuss that.

The next issue will be many SMS sites sharing a single domain. There are issues with having multiple SMS sites sharing a single domain, and those issues might involve network traffic or unresponsive sites, etc. We'll cover those for you.

The third area is sites spanning WAN links. So having client computers disconnected from their client access points or distribution points, or having distribution points or client access points over remote WAN links from the site server itself. We'll talk about some of those issues.

Next is account lockouts and orphaned clients. Account lockouts is one of the areas where we will focus on product design issues, where there actually was a design flaw in the product, because it is an important area for you to think about and to be able to recover from. Then we'll also talk about orphaned clients. What happens if you have an SMS client that's orphaned? In other words, it can't talk to its client access point anymore. What causes that, and how you recover from that?

The next area is custom MIFs and site hierarchies. There are specific problems that can arise if you have custom MIFs in a site hierarchy. We'll discuss that for you.

Next is client assignment and installation. This confuses a lot of people, as to how SMS does its assignment, and what are the requirements for assignment and installation. We'll go through that from the design phase.

Then the next area is performing health checks on a site. This is not necessarily a design issue, but it's something that's very important to understand — as you're going through the process of troubleshooting or maintaining your site — to perform health checks on your site. And we'll discuss how you do health checks on your site, looking at file directories and comparing that to a status system that's built into SMS 2.0.

Then lastly, again, there will be a slide on additional resources, and where to get more information about the product itself.

Our first area is performing a phased roll out (slide 4). I'm sure you all are very aware of the proper way to design and implement an SMS site. First you would go through a planning phase, where you would decide what you want the SMS implementation to accomplish for you. Then you would design your implementation. So you design where you want the systems to be, what type of systems you're going to have, and so on.

Once you've done that, you test it out in a lab environment. Ensure that you're testing it in a private network, not in your corporate networks, so that you're not affecting any corporate resources or any users.

Once you've done your test, you do a redesign, because I'm sure most people discover things in their test that were not indicated in their design. So you have to go back and redesign to figure out how you really want to design your site implementation, now that you see how the product's working.

Then you do another test phase. Then you do a pilot phase, where you start testing it out on a very small subset of production users. Then you go to the roll out, where you're rolling out to your entire corporate-wide base.

That's the proper way of going through an implementation. What we find, in some cases, is that when customers get to the roll-out phase, they enable every single subnet that they have in their corporate environment. So let's say they have 30,000 users on 10,000 subnets or 5,000 subnets, or however many subnets you have. Assume they have a lot of subnets and a lot of users.

So they enable every single subnet they have, and turn on logon scripts, and most often they do this over a weekend. So people come in Monday morning, they turn on their computers, and they log on. They're going to have users from all x number of those subnets, when they log in and get validated, who are going to go out there and start kicking off the SMS discovery process, the assignment process, and the installation process.

They've implemented that for all of the corporate users. If they encounter some problem with their design or their implementation, that problem is now going to affect every single user they have who has kicked off his logon script and started the installation and discovery process.

Also, you have network traffic that's uncontrolled. Every single one of your users that's running the logon script is going to go out there and start kicking off that process, and they're going to be downloading the software and installing their clients. That'll be a lot of network traffic all at one time. Again, the biggest issue is, if you had a design flaw, then it's affecting everybody. So now, if you find a problem that you didn't uncover during the test or the pilot phases, you have to roll that back from all those users. So if you had 30,000 users that were affected, you have to reverse that, or fix whatever the problem is, on all 30,000 users.

The most effective way to do a roll out is by doing a phased roll out. In this environment, you just enable a single subnet at a time. So if you have 100 subnets, you enable a single subnet and turn on logon scripts. Now for those people who are not assigned to the site, their subnet was not added, they'll kick off the logon script. They'll do discovery. Then they'll find out they're not assigned to the site, and they'll just bail out gracefully; they won't know anything happened. For those people who are assigned to your site — in other words their client subnet ID matches the site boundaries for your site — they will kick off the installation process, so they'll proceed further.

Now if you encounter some sort of a problem or difficulty, it's much easier to recover from that, because you have a small number of people who have been affected, as opposed to thousands or hundreds of thousands of clients that you might have. Not only does it give you better recoverability if you need to redesign something or make some quick implementation change, but you can also control your network traffic, because you're allowing only a single subnet to install at a time. So you install a single subnet. Once that works properly, and you've verified the results, now you can add another subnet. Then you can add another subnet, and just phase in the different subnets.

You can also control your network traffic through a couple of different methods. You can use Smsman instead of logon scripts. So if you don't want to use Windows Networking Logon Discovery or installation without logon scripts, you can use Smsman. Smsman is the Systems Management Installation Wizard. And that's the utility you would run manually, either from a logon point or from an e-mail message, or you post it on a Web site.

It can be command-line scripted so users don't have to have any interaction at all, other than launching this program. So that way you're e-mailing this out or posting to a Web site for specific people, so you're controlling who has access to the program. In other words, you're controlling who has access to installation and testing the network traffic.

Also, in the Microsoft^® BackOffice^® 4.5 Resource Kit in the SMS 2.0 Resource Guide, there is a utility called Random Login, Mdlogin.exe. Random Login will let you specify, through logon scripts, the criteria that controls who logs on. You could specify computers or users whose names start with an "A," or a range of characters: "A" through "M." There are a lot of different variables there. So you can specify, through randomizing the logon process, who will actually kick off and perform the rest of the logon script, and kick off the discovery and installation process.

Once you've kicked off this process, you verify that your results are correct. Verify that things were installed as you expected them to be installed. Verify that the client is installed as you want it to be installed and that it's behaving properly.

To do that you could create your own collections and queries based on your subnet IDs. So, create queries to search for all clients that haven't been successfully installed in your subnets, and then create collections from those queries so that they're dynamically updated. You can also use some of the built-in status message queries. We have built-in status message queries for clients that installed the basic SMS client services, and one for clients that failed to install the basic SMS client services.

We have other status message queries for clients that were assigned or unassigned from a specific site: client configuration requests, or CCRs, that were processed unsuccessfully, if you have issues with Windows NT^® clients not having a local user who's an admin.

For your implementation, it is very important to do a phased roll out so you're controlling your traffic. If you do encounter some issue, it's much easier to recover from that. So that will be a good way of controlling your network implementation, your network traffic, as well as controlling who has access, and recovering from any problems.

The next issue we want to talk about is environments that have multiple SMS sites sharing a single domain (slide 5). This is a very common scenario, where we have customers who have many domain controllers, backup domain controllers, spread throughout the United States or throughout the world. They put a backup domain controller at each remote location to allow or to at least give the local users a chance of hitting a local domain controller, as opposed to going over some wide area link connection, back up to some other domain controller. That's perfectly acceptable, and we do expect that.

There are a lot of customers in that same environment, where they have the domain controllers spread throughout the United States (or whatever the area is), who also install SMS sites on each of those domain controllers. And they've heard the stories and the recommendations saying that any time you have a WAN link and are separating SMS servers, you should set up a remote site. We'll talk about that on the next slide.

In these environments, where they have customers with hundreds of domain controllers spread throughout the United States, they might also set up hundreds of SMS sites — one SMS site on each of the domain controllers. That too is perfectly acceptable; so far we've not had a problem.

The problem in that environment comes when you have multiple SMS sites sharing a single domain, because you have a single domain structure; in those environments you should not enable Windows Networking Logon Discovery. The problem that is generated by enabling Windows Networking Logon Discovery is the fact that when any user kicks off the discovery process, they create a discovery record. So they create this DDR, and the client computer will take that DDR and write it back to the logon point.

If that logon point is being used by multiple SMS sites, what happens is that the SMS NT Logon Discovery Agent — which is a service we install on the domain controllers for Windows Networking Logon Discovery — takes the DDR from the client and sends it to every single site that is sharing that single domain controller. So if you have 100 SMS sites all sharing a single domain, when a client logs on, that client DDR is going to be sent to all 100 SMS sites. That will generate a lot of network traffic throughout your WAN environment by copying that DDR over.

If you're using logon scripts and you have an environment where users are logging off daily, then every day you're going to have that same DDR being generated and copied to every one of those 100 sites. So it's going to generate a lot of traffic, not only because of the sites it's going to, but also the frequency of the logon process. The more logons you do, the more network traffic you generate.

In those environments where you do have multiple SMS sites sharing a single domain, we recommend not enabling Windows Networking Logon Discovery, and instead enabling Windows Networking Logon Client Installation. When you don't enable Logon Discovery, but you do enable Windows Networking Logon Client Installation, that domain controller will still be shared by all 100 of those sites. So nothing changes from that aspect.

But what does change is that without logon discovery enabled, you don't install the SMS NT Logon Discovery Agent on the domain controller. So that's a service that's not installed. And when the client computer does discovery, it will not send that discovery record back to the domain controller. Because the discovery record's not sent back to the domain controller, that domain controller doesn't even try to propagate that discovery record out to those 100 sites, or however many sites you have.

In that environment, to get the discovery record created and sent into the site, you have to make sure that you have Heartbeat Discovery enabled. Heartbeat Discovery is a separate discovery method that is enabled by default, and runs by default every seven days. Every seven days the normal client maintenance process runs through the Client Component Installation Manager, CCIM, which runs daily. It checks to see if it's time to do Heartbeat Discovery. If it's been more than seven days, or whatever your Heartbeat Discovery process interval is, it will take that DDR that's created and copy it — not to a logon point, but instead to the client access point.

And because client access points are never shared between SMS sites, that client access point will only be a member of one site. So when it receives the DDR from the client, it copies it directly to the site server for its one site, so you don't have DDRs flooding your entire WAN link going over to all 100 sites. The DDR would just go to the single site. Plus, it's doing it on an interval basis, a scheduled basis — again, by default, weekly — as opposed to logon discovery, in which a user might log on multiple times a day or multiple times a week.

That's one big area of concern for site design. And that problem of enabling logon discovery does generate excess traffic through your WAN links. Plus, it also causes Discovery Data Manager on the site server to become bogged down. If you have 100,000 clients in those 100 sites, each logging on daily at 8:00 A.M., then you're going to have up to 100,000 DDRs sitting in a Discovery Data Manager's inbox, waiting to be processed. And that can cause some slow downs.

There are a couple of other issues with SMS sites sharing a single domain. There are senior site issues. When you have multiple sites sharing a domain, one site has to be designated as what we call the senior site. The senior site is responsible for replicating SMS information from the primary domain controller of that domain out to all the backup domain controllers in all the remote SMS sites.

The senior site, by default, is selected as the site with the highest site code. And in senior site designation, a Z is greater than an A, an A is greater than a 9, and a 9 is greater than a 1. So if you had a site code that was ZZZ, that would become your senior site. And that site would be the site that is responsible for replicating all SMS site information from the PDC out to all the BDCs.

That site may not be your central site. It may not be the site that you want to be your senior site. So in Service Pack 1, we implemented a procedure for you to be able to designate what your senior site is. And that's documented fairly well in a KB article (Q235726). It's a file you create called Senior.lst, and you place it in the Sitescfg directory on the logon \server\smslogon\Sitescfg point. Inside that file, you just list the site code of the site you want to be the senior site.

Also, just as a heads up, Service Pack 2 will have some changes in this area. We'll talk about Service Pack 2 changes in a couple of months. I believe in the June 1, 2000session we're doing Service Pack 2 (http://support.microsoft.com/servicedesks/webcasts/wc060100/wcblurb060100.asp), but it will have a couple of changes to help give you better performance. One of those is Multithreaded NT Logon Server Manager. Sites are automatically kept active.

There's a problem right now with multiple sites sharing a domain. If the site server can't access the PDC for a specific period of time, then the site is turned inactive, and it automatically deinstalls the logon points. And then clients may start deinstalling.

Then there's a problem with how often a site would check the PDC and update the site information. In RTM code and SP1, it happens much more frequently than we want it to, and there's actually a hotfix for that right now. That's included in the SMS QFE bundle. So if you have that environment, you might want to get the SMS QFE bundle and apply it to reduce the number of times the site server for a site updates your primary domain controller; it cuts down the network traffic.

The next slide is "SMS Sites Spanning WAN Links" (slide 6). The problem here is that SMS assumes high-speed connectivity between the site server and other SMS site systems — between the site server and the client access points, between the site server and distribution points, and so on. Between the site server and all the other servers, SMS is assuming there's high-speed connectivity.

Now we understand that domain controllers are going to be in remote locations. So they may not necessarily have high-speed connectivity back at the site server. That is understood, and we try to accommodate that.

We also assume that there's high-speed connectivity between the SMS client and its client access point and distribution point. So we're assuming the client has very high-speed connectivity and reliable connectivity to its local resources.

Because of that, SMS does very little throttling of intrasite network traffic. Between the site server and the site systems, there's very little traffic that you can control. SMS will place the traffic on the wire out to those remote site systems whenever it needs to: whenever it's scheduled to do so, or whenever it needs to block the traffic out because of a new package being created.

There are very few things you can control on an intrasite basis between SMS servers. You can control your Site Status Summarizer. You can schedule when it checks all your site systems for disk space and up and/or down status and so on. You can configure status messages to not be replicated between sites, or you can configure status messages not to be sent to the site server at all, in some cases. You can configure the logon point update interval — how frequently do you want your site server to talk to the domain controllers to make sure that they're set up properly as SMS logon points.

On the client end, you do have a little more control. You can schedule when hardware inventory takes place. You can schedule when software inventory runs. You can schedule how often your ODPs wake up and look for advertised programs. So you can schedule when your client is going to interact with the server a little better than you can between SMS servers.

However, you can't control everything, and that causes some problems. One of the big things that customers want to do, in the environment of controlling the network traffic, is that when they create a package and assign that package to a distribution point, people like to schedule when that package will be deployed to that distribution point. And in SMS 2.0, you don't have that ability, in that as soon as you assign that distribution point to the package, the distribution manager on the site server begins the process of sending that package out to that distribution point. And generally, when SMS sends traffic out over the wire on an intrasite basis (the servers within the SMS site), the traffic is uncompressed and unthrottled. We just throw it out over the wires, assuming again it's high-speed connectivity.

So if you have a remote CAP, a remote distribution point (and remote in this case means over a WAN link), then whenever SMS decides to send files off to the CAP or send out your Office 2000 package to your distribution point, it's going to be uncompressed traffic. And it's going to be unscheduled traffic, as far as you're concerned. SMS may do it in the middle of the day. It may do it 8:00 A.M. It just depends on what it's interval is internally.

The last area, again on clients: by default SMS clients are going to randomly select a client access point and a distribution point when they need access to one. If you have an environment where you have 10 CAPs, there might actually be a CAP local to the client. And then the other 9 are remote subnets. However, by default, when the client looks for a client access point, it's going to randomly select one of those 10 CAPs from that CAP list, which may very well be over a wide area link. So any time the client reports inventory data, it reports status messages, it looks for advertised programs, it looks for configuration information, it's going to go off to that client access point, which might be over a remote link.

For most things the client's going to report, like inventory data, that's generally going to be fairly small, so it's not going to be that big of an issue. However, whenever the client goes up to verify the SMS installed components, that's going to generate quite a bit of traffic. The same thing with the distribution point. When I randomly select a distribution point to install Office 2000, which is 500+ MB, if that distribution point happens to not be local to the client, it's going to pull that 500+ MB over the wide area link.

To help you out in that area, there are a couple utilities in the BackOffice 4.5 Resource Kit in the SMS 2.0 Resource Guide: Prefserv and Localsvr. Those utilities will help you designate preferred client access points and local distribution points. So whenever your client looks for a CAP or DP, it would look at the list of preferred servers, as opposed to randomly selecting one. What you would do is designate one of your local servers to be a preferred server , one local to the client, as opposed to being over the wide area link. However, you have to run those individually on each client, or maybe you'd make an SMS installer script that would update the registry properly, with the proper configurations, and send it out to clients on a subnet-by-subnet basis.

The last thing we'll talk about here with clients and CAPs is there's a problem with SMS 2.0 RTM and Service Pack 1, in that every 30 days your client computers do a verification process. They run this verification process to verify that the client is properly installed. Currently, the way the code is written, it actually does a reinstall of your client components. And if we're randomly selecting a client access point, that random CAP may be over a wide area link, so that every 30 days you're pulling down anywhere from 6-12 MB of traffic for each client, every 30 days, which may be over a wide area link because of a random client access point.

There's a utility called Cliverify.exe that you can use to turn that off, if you don't want that to happen. You turn off the 30-day verify cycle for Service Pack 1 and RTM code. That will not be applicable for SP2, because in SP2 that problem's been solved.

So just be aware of those things, which will benefit your clients in gaining access to the servers, as well as control your network traffic as you're implementing your sites.

The next area to talk about is account lockouts and orphaned clients (slide 7). The most common account that gets locked out in an SMS environment is the SMSCliToknAcct& . You probably have heard of and maybe even experienced SMSCliToknAcct& lockouts. The reason for this is that the SMSCliToknAcct& is used for many client processes.

One of the purposes of the SMSCliToknAcct& is to generate tokens to impersonate or separate SMS client processes. Because most of the client code runs in the context of the SMS client service — so the SMS client service and its service account — that'd be one account, and you don't want these processes stepping on each other or interacting with each other. So we use the SMSCliToknAcct& to impersonate or create new tokens for each process.

The area that causes the problem is that the SMSCliToknAcct& is local in the SAM of a Windows NT client computer. If you look at the local SAM, the Windows NT client, you see the SMSCliToknAcct&. If your SMS logon points or domain controllers, if those domain controllers are set up as SMS clients, they too have an SMSCliToknAcct&. However, domain controllers don't have a local SAM. They have a domain SAM, the shared SAM.

Every single client has a unique password for the SMSCliToknAcct&. So the problem arises when a client computer tries to validate the SMSCliToknAcct&, and it goes across the wire to the domain controller to get validated. The password for the SMSCliToknAcct& on the client computer is definitely going to be unique and different from the password of the SMSCliToknAcct& that's in the domain SAM.

If you have account lockout enabled, your account is going to get locked out. So that's why the problem arises: because there are two different accounts, that have different passwords, and that SMS client processes incorrectly go out across the network under the context of the SMSCliToknAcct&.

There have been a couple of hotfixes created to fix the SMSCliToknAcct& lockout issues. One of those is Q244410. That hotfix is also part of the SMS Client QFE bundle, which you'd probably want to get, instead of just that one single hotfix.

Again, this is a product design issue, so it's a problem in the product. And we weren't technically discussing those in this session. This was going to be site design issues. But this is such an important issue, and it causes a lot of problems for people in their sites, that I wanted to talk about it here.

The bigger area, as far as site design, is the last bullet on your slide, which is avoiding orphaned clients. An orphaned client is an SMS client that can no longer talk to a client access point. Generally the reason for that happening is that the account that the client normally uses to talk to the client access point is the SMS Client Connection account. By default that account is SMSClient_sitecode.

Generally, when the client computer needs to talk to the client access point, transferring inventory data or checking configuration or whatever, it does so under the context of that account, SMSClient_sitecode. If the password for that account is changed, and the client computer is not notified of that password change, then when the client tried to connect up to the CAP, the CAP is going to say, "No. That's not the password. The password is something else," and it's not going to allow a connection to the CAP. The client will not be able to download any additional configuration information, or check for advertised programs, and it won't be able to report data, inventory data, and so on. So the client has, in essence, been orphaned.

A very common way this happens is if you have an SMS site installed, and then you decide to deinstall your SMS site and reinstall it with the same site code, but you don't deinstall your SMS client computers. The client's going to remember the SMS client account with one password. When you reinstall your site, it's going to create the same account, but the account will have a new password, because it's randomly generated every time you install the service, or you install the site. So the site's going to have a new password for the SMS Client Connection account. The client computer's going to have an old password for the SMS Client Connection account and the client's not going to be able to talk to the client access point.

If that happens, all you need to do to recover is run an installation method. So either run your Windows Networking Logon Client Installation method using the logon script Smsls.bat, or manually run Smsman.exe. Smsman.exe is located in your client computer in the \MS\SMS\Core\Bin\00000409 directory. You can launch it from there, and then run an installation process that will pull that new client account information down from the logon point and update the local client registry. You'd probably need to restart the client, or at least stop and start the client service to get the client to use the new account information.

The best way to keep this problem from ever happening is to manually create an additional SMS Client Connection account. The Service Pack 1 Release Notes document this very clearly. It goes through a procedure. I think it actually has you creating three additional accounts, and then you go through a process of retiring one of those accounts, before your password expires, and creating a new one.

You're always keeping one account that was admin created, so that you know what the password is, and it's active on the client. That way, if you ever need to reinstall your SMS site, just make sure you create that exact same account inside the SMS Admin Console under Site Settings, Connection Accounts, Client, then under SMS Client, create another SMS Client Connection account. Use the same account name and password, and the client will have the appropriate account and password to talk to the client access points.

You definitely need to make sure that you have at least one administrator-created and controlled SMS Client Connection account. If not, it's likely — it's possible anyway — that your clients may be orphaned. And that's not a good thing for your client computers.

The next area is custom MIFs in site hierarchies (slide 8). This is one that most people haven't encountered before, but it's possible to encounter it. So we'll bring it up to hopefully help you prevent it from ever occurring.

The scenario is that a child site has created the custom MIF. So I'm in an SMS site. I've got a custom MIF that I've created to generate a new architecture to the SMS database. That updates the child site's SMS database, and child sites always forward their inventory data up to the parent site. When you forward inventory data, you also forward any custom architectures, so the parent site would also know about that custom architecture.

Now the problem comes in if the parent site decides to create a collection that is based off of that custom architecture. So if the parent site creates a collection that queries on that custom architecture, that could cause a problem. The problem comes in the fact that parent sites automatically replicate all collections down to all child sites. So once the parent site has created the collection that's based on or utilizes data from this custom architecture, it's going to pass that collection down to all child sites.

Any child site that knows about that custom architecture — in other words, that was using that custom MIF — will be fine, because they'll have that data in their database, and the SMS collection evaluator will be able to process that collection properly. However, if I had another child site that was not using that custom architecture — in other words it wasn't using that same ID MIF for that architecture — their database, the SMS site database, would not be updated with that custom architecture. So when the collection evaluator at this other child site tried to process that collection, it would fail to do so. And it would report errors in its Colleval.log indicating that I can't process this collection because it has Microsoft SQL Server™ data that I'm not aware of.

What happens is it tries to process that collection every minute. So it's going to generate a lot of error messages, and generate a lot of processing utilization, because the collection evaluator is processing that collection every minute.

The best thing to do is either not create collections based on custom architectures, or if you do create one and create collections based on custom architectures, ensure that every child site knows about that custom architecture. The way to ensure that every child site knows about the custom architecture is just to take the ID MIF that was created on one child site and send it down to the lowest child site in your hierarchy — the lowest child site in all your branches of your hierarchy.

Remember that when the child site generates inventory, it's going to pass that inventory up to its parent. So if you get it down to all the bottom leaves of the tree, then they'll automatically flow up and get all the other sites. So eventually all your sites will know about it. Just be aware of that, so it doesn't generate problems for you as you're processing collections and creating collections and passing down your hierarchy.

The last site design issue we want to talk about is the process of client assignment and installation (slide 9). This confuses people and causes some issues with the design because of not understanding exactly how SMS does assignment.

SMS 2.0 bases assignment on assignment rules. The assignment rules in SMS 2.0 are physical network boundaries. We use either IP subnets, or if you're in a NetWare environment, we use IPX networks.

When you're creating your site assignment rules, you go to the Site Properties for your site code. Go to the Boundaries tab, and you just click the New button to create a new boundary. You specify whether it's an IP subnet or an IPX network. Then you specify the appropriate numeric value. So either it's an IPX network or it's an IP subnet.

Let's go to the example of an IP subnet. When you enter an IP subnet, you notice that there's no area for you to enter a subnet mask. All you do is enter an IP subnet. The site server doesn't care what the subnet mask is. The site server just cares about the IP subnet ID itself. You're not allowed to do any wild cards — no "192.168 Startup *". You're not allowed to do any supernetting. You're not allowed to assign individual IP addresses.

Some customers have tried to put individual client IP addresses in there to say I want this client assigned to this site. And that's not the way SMS 2.0 does assignment. Assignment is based on subnets in an IP environment, or IPX networks in an IPX environment.

If you're not sure what your subnet is, all you have to do is kick off the discovery process on an SMS client computer, either through Smsls.bat or Smsman.exe. It will do discovery. It will discover what its IP subnet is. Discovery does that by going to the client's registry and looking at its IP address. It looks at its subnet mask for that IP configuration, and it ANDs the two together.

What it comes up with by ANDing the subnet mask to the IP address is the IP subnet itself. So it might come up with a 192.168.20.0. That is the value that you need to add to your site boundaries: 192.168.20.0. Again, that's just an example. Don't add 192.168.20.0 to your subnets.

You can find that listed in your Wn_logon.log or Wnmanual.log on your client computer. So do an SMS discovery process (for example, Smsman.exe). And then in the log file, it'll list the IP subnet.

If you don't have Windows Networking Logon Discovery enabled, then how do you tell? You can just look at your discovery data. So when the client has created a discovery record, it will send it up to the site server, and it will be in your collections. You just go to your All Systems collection, find a client computer that didn't install because it wasn't part of your boundaries, look at its properties, and look at IP subnets. It will show you what the IP subnet is that the client is a member of.

Take that value, add it to your site boundaries, let that information propagate down to your client access points and log on points, then either log the client on again or run Smsman again, and that will kick off the discovery process, and then the assignment process.

Once your client has been successfully assigned to a site, in order to be installed it has to talk to a client access point. One of the most common problems people run into is that in their site designs they have users in the accounts domain. Then they have SMS client access points in a resource domain. When SMS assigns file security to a client access point, it assigns permissions in security on the domain that the CAP is a member of.

So if my CAP is in a resource domain, it assigns permission for users and admins and guests from the resource domain, not the accounts domain. So when your user tries to access that client access point, most likely it's not going to be able to access the files on the CAP because of security.

So when you're designing this implementation with your CAPs in one domain and your user accounts in another domain, it is important to ensure that the account domain's Domain Users group has been granted permissions to the CAP (if in a different domain than the user accounts). We talked about this in the SMS Security Support WebCast (http://support.microsoft.com/servicedesks/webcasts/wc020300/wcblurb020300.asp).

But you need to make sure that the accounts domain domain users group has been added to the file security on the CAP_sitecode directory structure. It needs read permissions for the entire CAP_sitecode directory. And then it needs read, write, and execute permissions to the five specific directories where clients are going to write back configuration files.

Those five directories would be Ccr.box, Ddr.box, Inventory.box, Sinv.box, and Statusmsg.box. On those five directories the clients need to have read, write, and execute permissions. The other five directories just need read permissions. That's the most common design area for getting clients installed: getting your site boundaries set up properly and then making sure that your users have access to your client access points.

An alternative would be to enable the Guests account on your client access points. But most people don't like to enable the guest accounts, so you may not want to do that. You need to make sure that your CAPs have appropriate security permissions. That's the end of the site design.

Now one of the important things we want to talk about is how to perform health checks on your SMS site (slide 10). Performing health checks is the process that you use to go through manually checking to see what the status of your SMS site is. There are a couple ways of doing this.

One of the ways is by monitoring your SMS status system. What you would monitor there is the status of your components: the SMS components running on the site server and all your remote site systems. You can do that through Systems Status and then your Site Status, your Site Code, and then Component Status. You're looking for components that don't have a green check mark by them — so the yellow warning sign or the red circle with the white "X" in the middle of it.

You're looking for components that have error or warning conditions on them, and also you're looking at site system status. That is an area where we check what the status of your site system is, looking at disk space, and can we access the specific server itself. That's one way to perform a health check.

However, the status system should not be the sole way you do your health checks. The reason for that is the status system may be unreliable. And I don't mean unreliable from a product aspect in the way it was designed. I mean unreliable because the administrator has a lot of control over how the status system operates.

For example, the administrator can change the schedules for the Site System Status Summarizer. By default, the Site System Status Summarizer is going to go out there across the network and query each of your SMS site systems hourly. Every hour it's going to go out there and talk to your CAPs, your DPs and your logon points, your software metering server and your SQL server, and so on.

Make sure that they're up and running. Make sure that they contact them. Check to see what the disk space considerations are, and the drive SMS is using.

Even with the schedule set for hourly, the data still might be old. You might be looking at the site system status summary right now, but the data might be 50 minutes old. Plus there's the fact that you can change that schedule; you might only have that running daily, so that you might be getting a false reading on the status of your server by looking at the Site System Status Summarizer, because of the fact that it's only running daily, weekly, or whatever you might have configured it for.

The administrator can change the thresholds. So on each component, you can state what number of errors or warning messages or informational messages constitutes the next level of message, whether it goes from an informational type to a warning type message to an error or critical type message. You can change that. And it's very easy to do. Because of that, again, you might be getting a false reading.

You might have your value set way too low, so that you might say any time I get five informational messages on a component, that becomes a warning message. That's not necessarily a warning, because there's nothing wrong with the component. It just happens to have generated five informational messages. I think the default is 2,000. But you can change that.

You can reset your status system so that you can go out to your component status and do an Action, Reset Counts, and that will change the state of the component. The states are the green check mark, the yellow warning, or the red/white critical error. You can change that visual indicator. It also resets the counts of your messages. You can do that, and that might be giving you a false indication again. You might have just reset it, but you really have a problem out there, even though your reset values appear to be fine.

You can actually delete status messages. It might indicate an error, but you go look at your individual status messages and you can delete them. So they may not be there anymore.

If you have a child site, you may have replication delays in sending your status summaries or status messages from the child site up to your parent site. You can even turn off the forwarding of status messages or summaries from a child site to a parent site. So the parent may have an incorrect reading for the child itself.

Then lastly there's the display interval. The display interval is how you're looking at the status system — what period of time you are checking your state, as well as looking at the number of messages. You can change it to say all messages from 8:00 A.M. today; or all messages from noon; all messages from Monday, Tuesday, Wednesday; all messages from the beginning of the month; or all messages from site installation.

You can change that display interval. Again, that will adjust how the view of the status system appears. Because of all those things, the status system gives you a lot of information, but it may not be exact, because of the fact that you have a lot of administrative control, and things do age out after a period of time.

The best way of checking health on your SMS site is to monitor some of the inboxes on your site server, your client access point, and your logon point. So you're looking at inboxes on those three different types of site systems to see if there's any backlog of files.

As you see in the PowerPoint^® slide (slide 10), there are 24 different inboxes on the site server that you should really monitor. What we mean by these inboxes is not every single inbox on the server or the CAP, or the logon point. It's the inboxes that have moving data: data from clients, data from other sites, or data from other SMS components — areas where there are files that are flowing around that need to be processed, and those reflect your SMS site.

For example, Ddm.box on the site server: that's where all the discovery data records wind up from child sites, from local clients, from site system discovery, Windows NT Server Discovery agent, and so on. They all end up in Ddm.box. Then from there, the Discovery Data Manager adds them to the site database.

If you have a backlog of DDRs in your Ddm.box directory, that may indicate a number of things. It could indicate that the SMS Executive is not running on your site server, because the DDM is a thread of the SMS Executive. It may be that you used SMS Service Manager and you stopped the SMS Discovery Data Manager thread. So the individual thread of the SMS Executive is not running. It could be that the server that you have for the site server is not powerful enough to keep up with the processing that you have at your site. So you may need to upgrade some hardware to get better performance. It may be that there's a bug in the SMS code that's causing a backlog.

It may be that you have an environment (which we talked about before) where you have 100 SMS sites all sharing a single domain. And all the sites have Windows Networking Logon Discovery enabled, and your clients are logging off and logging on multiple times a week or multiple times a day. Because of that, you're flooding your sites with these DDRs, and the Discovery Data Manager just can't keep up with them. So it's all the different inboxes on your site server that client data or data from other sites or data from other SMS components might flow through.

There are 24 of those on the site server. There's only one on a logon point. That would be Ddr.box on the logon point. And Ddr.box on the logon point will only appear if you have Windows Networking Logon Discovery enabled. If you don't have logon discovery enabled, you don't have to worry about logon points.

On the client access point, there are five inboxes to monitor: Ccr.box, Ddr.box, Inventory.box, Sinv.box, and Statusmsg.box. That's where client computers would write those types of messages or files to the client access point. If you have a backlog in any of those inboxes on your CAP, that might mean a security issue, in that maybe your SMS Server Network Connection account password has changed, and the account doesn't have the new password. Or maybe the Inbox Manager Assistant running on the CAP is not running, or the SMS Executive on the CAP is not running, because that's what transfers those files over from the CAP to the site server. So it's very important for you to go through and monitor the appropriate inboxes on your site server, your CAP, and your logon point, looking for backlogs.

If you have backlogs, then you need to figure out why. Is it because of a design issue, like Windows Networking Logon Discovery is enabled? Is it because too many files are generated in too short of a period of time, and there's some threshold you can change? Is it because the server is not powerful enough? Is it because a thread or a service is not running?

Check the Knowledge Base articles to see if there's a problem that's been reported in that area and if there's a fix available. There are a couple of articles for scheduler that were in the SMS QFE bundle. So you want to go through and make sure you perform health checks on your site.

At some point there'll be a document created that will list all 30 of those inboxes for you. But you'll be able to figure them out pretty easily, and go through and look at your site.

The last slide we have is additional resources (slide 11). Again, if you were in last month's session, you saw this information as well, but here it is again for new people. If you need more information about SMS, you can order a hard copy of the SMS 2.0 Administrator's Guide. I listed the part number (part no. 271-00617) for you there. You can order it from either the Open Select program or Microsoft Supplemental Parts [(800) 360-7561].

Make sure that you read the release notes for whatever release of SMS you're running. The release notes are very important for you in making sure that you have the latest information about SMS. It contains information that is important for the specific version: RTM, SP1, or SP2, when it comes out. This is information regarding that specific version that didn't make it in the admin guide or anyplace else in the product documentation.

You'd probably want to get a copy of the SMS 2.0 Resource Guide. The resource guide is the single manual that contains all the advanced information about SMS 2.0, as well as the appropriate utilities. Some of those I've talked about in the session. That resource guide is also part of the BackOffice 4.5 Resource Kit. So you can either go to a store and get the BackOffice 4.5 Resource Kit (ISBN 0-7356-0583-1) or you can get the SMS 2.0 Resource Guide (ISBN 0-7356-0928-4).

You should go to the official Microsoft Systems Management Web site, which is at http://www.microsoft.com/SMSMgmt/. You can find information about the product there. You can find out what's new, you can find out when the new releases come out. You can find white papers on NetWare integration, or upgrade interoperability from SMS 1.2 to 2.0.

You can find downloads. We had a couple of free training courses you could download, like deploying Office 2000 or doing Y2K analysis with SMS. You can order updates for Service Pack 1 and Service Pack 2, when they are available. So that's the first resource you want to go to for product information.

You might want to consider official Microsoft Official Curriculum training, the official MOC training that you can find at any of our CTECs, Certified Technical Education Centers. We have three different instructor-led classes available on SMS 2.0.

Then, if you need public support, check the Microsoft product newsgroups. That's msnews.microsoft.com, and there are a series of SMS newsgroups under microsoft.public.sms. After the ".sms," there'll be another newsgroup specific for areas such as inventory, setup, administration, and so on.

Of course you have your standard contracts with Microsoft Product Support Services, and you can go to the http://support.microsoft.com/ Web site as well.

Those are all places you can go to get additional help on SMS 2.0.

That's ends the presentation; and now Heidi will start the Q&A session.

Heidi: Excellent. Thank you, Wally. It is time to start the Q&A portion of this session.

We only take questions during the live event. Also, one-on-one support issues are outside the scope of the Support WebCast. If you need technical assistance, please submit an incident on the Web, or contact Microsoft Product Support Services. The goal of the Support WebCast Q&A is to look at the topic at a conceptual level.

With that said, let's jump right into the Q&A. The first question is a little bit long.

Wally: A couple of observations off the top. It's pretty open ended, so I can't give you a specific answer. However, you mentioned Windows 2000. As of today, unless you have Service Pack 2 beta for SMS 2.0, we don't support Windows 2000. So you need to wait for Service Pack 2 before you can set up your Windows 2000 site server, which it sounds like you wanted to do.

Unless you're planning on doing that for SMS 1.2 — and in SMS 1.2 we're not going to support a Windows 2000 site server at all. So a site server running Windows 2000 is going to have to be on SMS 2.0, and we don't have that support yet. Even if you had SP2 beta, SP2 beta is not supported in a production environment, because it is a beta product. We want you only running it in a test environment, not in a live environment. So there's that.

You mentioned upgrading from 1.2 to 2.0 running the Deinstall.bat. My question would be why do you want to deinstall SMS 1.2 instead of just letting the SMS 2.0 process upgrade the SMS 1.2 client to an SMS 2.0 client? That is generally what our recommendation is, unless you want to change your domain structures or you want to change how your client installed, or something else. Generally we do recommend that you just let SMS 2.0 perform an upgrade of your client, as opposed to deinstalling and then reinstalling SMS 2.0.

You can do that if you wish, if you just want to start over with a clean slate. In that case, you don't need to worry about migration. It's just a matter of installing your Windows 2000 site server when SP2 ships, and then setting up your client access points, your logon points, your distribution points, and so on. Then log on your clients and get them upgraded.

As far as setting up your BDCs in remote locations as secondary sites, that is fine. That is something we talked about in the presentation. So, that all sounds fine.

I can't give you a definitive answer. You had some things in there that sounded very good. You mentioned rolling this out in phases, which is very good as well. But there's not enough information to give you a complete and absolutely correct answer.

Heidi: Thanks, Wally. The next question: Please address the use of a reference primary server staged at each level of the hierarchy to be used as a source of data used to restore a failed parent.

Wally: We normally wouldn't recommend having a reference server at each site to restore a parent. That's not something that you need to do. What we would rather have you do is use a new Web utility that will be available very shortly on http://www.microsoft.com/SMSMgmt/. And that Web utility is called the Site Recovery Expert. The Site Recovery Expert will give you all the documentation you need for creating a backup process, as well as a recovery process, in the event that you have a site failure.

So what we want you to do is use the task that's already built into SMS 2.0, one of the database maintenance tasks, called Backup SMS Site Server. Use that task specifically in SP1 — not RTM — the SP1 version backs up everything. But the SP1 or SP2 version does a great job of backing up your site server. The registry, file structure, the SQL database stuff — it backs up a lot of other information about your computer itself, in case you need to re-create the computer. So use that to generate the backup of your server. Then use the Site Recovery Expert to tell you how to go through the process of doing a recovery.

You run the recovery expert off the http://www.microsoft.com/SMSMgmt/ Web site. That utility is an interactive utility. It'll ask you questions about your site: "Is this is a primary site, a secondary site; Windows NT 4.0 on a domain controller or member server, or Windows 2000; what agents are installed; are you sharing your logon points with different sites?" — a lot of questions about your site.

Then, when you're all finished, it will present a list of tasks you have to go through to recover the site and get back on the hierarchy. If you're not sure what all those tasks are, you can just click on any of those links, and it will present individual procedures for those tasks.

Then, lastly, some time after SP2, we'll have the Site Recovery Wizard. The wizard will do what you're talking about specifically to recover a failed site. So if you have a failed site hierarchy and you had to restore a site, you'll run the Site Recovery Wizard, and it will recover that site, as far as placing you back on your site hierarchy and recovering any orphaned data from your child sites. Or if you are a child site, it will download a site control file from your parent site and make sure that the two can communicate again.

That would be the procedure we'd recommend you go through, as opposed to setting up reference sites of parents at each remote SMS location.

Heidi: Thank you. The next question is: We have SMS 2.0 as a central primary site at City1 with 1,000 clients. It's from here that our administration of SMS will take place. We want to install another site at City2, which has 100 clients and a 32 Kbps data connection to the central site. There will be no administration from Ankara. Should the City2 site be a secondary site or a primary site?

Wally: If you don't want that child site to do any SMS administration at all, you would set it up as a secondary site. One of the big advantages of the secondary site is that it doesn't have an SMS Administrator console installed, so it has no ability to perform SMS administration. So if that's what your goal is, you would set it up as a secondary site.

Plus, a secondary site generally requires fewer hardware resources than a primary site does, so you can get by with a little bit slower speed or less RAM in your box than you would with a primary site. You can set it up as a primary site, but then you do have the SMS Administrator Console. And if they had access to it, they could perform some administration, depending upon how you set up your security rights. But from what you said there, I would recommend a secondary site.

Heidi: Terrific. The next question is: Are there any problems deinstalling the SMS 2.0 client by using a logon script such as the Deinstall.bat and then installing the SMS 2.0 client by logon script?

Wally: Deinstall.bat: we only had one, and that was for SMS 1.2. And I didn't hear 1.2 for the first part.

Heidi: No. It all refers to 2.0.

Wally: For 2.0, if you want to deinstall or reinstall your SMS 2.0 client, you can certainly do that. How you do so, there are different methods. I don't recall a batch file that Microsoft provides called Deinstall.bat for 2.0. There could be one, but I don't recall it.

Generally, if you want all of your clients to deinstall, the best way is to remove your site boundaries. So go to your site server, remove your site boundaries, but you actually can't have an empty site boundary list. You'd have to put in a dummy site boundary. But remove all the boundaries that the clients are on, wait for 24 hours, and the clients will automatically deinstall themselves, because they check every 23 hours for site configuration information. And when they do that, they check to make sure that they're still assigned to the site. And if they're no longer assigned, they'll deinstall automatically.

There are other ways. In the resource kit or the resource guide there's a utility called 20clicln.bat. You can run that utility. That will deinstall the client. There's also your Systems Management Installation Wizard, Smsman. If you run Smsman, it has an option on the first page for Remove SMS Components. You can do that. Any of those methods would deinstall the SMS client.

Now, as we talked about in last month's session, when we deinstall a client, we don't deinstall everything. We leave some traces of SMS on that client computer. The primary reason for that is if you want to reinstall your client. When you reinstall your client, it assigns the exact same SMS unique identifier that it had prior to deinstallation. So that way your old client information in the database will be associated with your new client installation. You have all your history information, your hardware inventory and software inventory, status messages, and so on.

Other than that, no, there's no problem with deinstalling and reinstalling a client, unless you wipe them out manually. You would just become the same client again.

Heidi: Thank you, Wally. Moving right along. The next question is: Could you please address the risk inherent in a flat hierarchy where all children, both primary and secondary, report to a single parent central site in the event of failure of the central parent. Does that make sense?

Wally: Yes. The advantage of a flat hierarchy is information flow. It takes much less time to get a package, a collection, or an advertisement that's created at the central site down to all the child sites, because it just has to go through one level. So that's a big advantage.

Plus it's very good if you want to have centralized administration. The SMS administrator at the central site has a one-level hierarchy to go through to get to all the child sites. So it's very good for administration as well.

The downside is that you have many more sites directly reporting to that parent site. So if you want to distribute something like Office 2000 to all x number of child sites you have, it's a point-to-point process from the central site down to each of your child sites. So it's going to take longer to get that information down to your child sites, or more processing on the central side, anyway.

Then, from the aspect of a recovery, if that central site goes down, then yes, all of your child sites will all be reporting status errors saying "I can't find my parent site." So the scheduler and the sender and so on, they're going to report errors in being able to get to the parent site.

Now if you've actually done a recovery of that, got your parent site back up and running, then provided that the server name, computer name, domain name, drive, and site code and everything is the same, and your SMS site address account is the same, your SMS child sites will automatically connect back up to the parent within 24 hours. They'll send their site control file back up. So it should be a fairly simple process. The biggest thing you'd have to look for is ID numbers.

And there are some ID numbers that you'd have to be aware of to make sure that they have been incremented properly, so you didn't wipe things out at your child site. That is documented again in the Site Recovery Expert and in your Site Recovery Wizard, when that ships, again some time post SP2. That will help you recover that parent site and make it much, much easier.

Heidi: The next question might be a little bit too detailed for this session, but we'll give it a go and see if we can get a broad answer for you.

Wally: That size of the hierarchy is fine for SMS. I'm personally not aware of anybody who's gone that far yet with SMS 2.0. I know a 1.2 customer who's working on 1,500 secondary sites on 1.2, and they haven't fully migrated over to 2.0 yet. I believe their central site is now 2.0, and they're working on their child sites.

Generally our recommendation is, once a site has around 50 children on a single site, you want to look at implementing another layer. That's going to depend on a lot of things on your end, such as how powerful your hardware is at the site server, how much administration do you want to do from that one site server — just how much work do you want to do on your end?

SMS certainly does not have a limit. This one customer I just mentioned, they have almost 700 secondary sites off of a single primary, in some cases. So you can certainly do that. That's not an issue. It's more a matter of do you have the hardware that can support that, and how much administration do you want to do from your one, not central site, but from your child primary, which is going to become a parent of a lot of different secondary sites. How much information flow do you want going to that one site directly? And how much information do you want flowing from that one site down. It's kind of wide open there.

What you might want to look at is the SMS 2.0 Resource Guide. Chapter 2 is the planning chapter. It talk a little bit about hierarchies, as well as gives you some sizes of servers, depending on how much information flow you're going to have within the site, and also the child sites. So you might want to look at that as a resource to get you some more ideas.

Heidi: Thank you, Wally. The next question looks like it's referring to slide 5. And it is: On slide 5, if a client is authenticated over a WAN on another site's BDC, then how can you use Windows Networking Logon Client Installation? The client would be assigned to the SMS site over the WAN. And that is said as a statement, rather than a question.

Wally: SMS clients are not assigned to remote sites. Clients will only ever be assigned to sites if their subnet is a member of that site's site boundaries. So in your case, if my client was sitting in Seattle, and I logged on to a single domain, and I happened to hit a domain controller in let's say Los Angeles, because it was a single domain. I would do discovery as part of that logon process.

However, my assignment rules should be set so that my client in Seattle would not become a client to Los Angeles, and it would never install into the Los Angeles site. The Los Angeles site should not have site boundaries that encompass the Seattle site. Because they'd be separate physical subnets, my client would never be assigned to that remote location. It might be discovered there, but it would never be assigned. If that were the case, then all you would do is manually run Smsman for that client, and have it hit a local domain controller, and then you'd be assigned locally.

But generally, with the way Windows NT operates, it tries to give you a local domain controller for validation. And I believe in Service Pack 5 of Windows NT 4.0 you can even specify a preferred domain controller for a logon validation, but I haven't tried it myself. And if so, you can again specify that preferred domain controller, which would be a local domain controller, and then you would get logon validated there.

And again, when you're querying for domain controllers, you send out your broadcast through Windows NT to all domain controllers, and whichever one responds back first is the one you access. Theoretically, if you have slow links, your local domain controller would be the one that would respond back; so you would be hitting a local domain controller, which should be in your local SMS site, and everything would be fine.

Heidi: Moving right along, the next question is: We have a single site server environment. We have BDCs on every remote site connecting through a slow link: 125 Kbps , back to the head office. What are the best practices for SMS \Logon share? Should we leave it on every DC? How often does the content in each logon point get replicated? And how much traffic are we talking about?

Wally: First off, you can't control which domain controllers SMS uses for logon points. So you mentioned something there about should we leave it on all of them? You don't have a choice. With SMS 2.0, it's all or nothing. When you enable a domain for a logon client installation or logon discovery, all domain controllers in that domain are set up as logon points for that site. You don't have control over that, other than not adding that domain name. If you want to have logon points, all the domain controllers in that domain are going to be logon points.

As far as how often SMS replicates data between those log on points, that's an administrative configuration value. You get to control when you want that to occur, or how frequently. Look at Windows Networking Logon Discovery or Windows Networking Logon Client Installation. You go to the Properties for one of those two different methods. Then you go to the Logon Settings tab. Toward the bottom of the Logon Settings tab, you have Logon Point Update Interval. So you're setting how frequently you want SMS, the site server, to access your domain controller and replicate information out to all your other domain controllers, from the PDC.

The default value there is daily, and that's probably too short an interval, too soon to be replicating. So you'd probably want to set that to weekly, or maybe something longer. It just depends on your environment.

How much information? We generally only replicate things that change, so it may not be that much information. It may only be a small set of files that are under a couple kilobytes each. However, if it was a full logon point installation and with all the files, a full logon point installation is going to be about 15 MB of data across the wire. That's if you're doing Windows Networking Logon Discovery, so it's got the service and the agent that has to be installed. Other than that, replicating should be up to 30 KB, or something like that, at every one of your intervals.

Heidi: Next question: Can you address the minimum accounts required in domain B to install primary site in domain B, where the proposed parent is in domain A? Essentially domain B trusts domain A only.

Wally: I don't think I'm following him correctly, because there's nothing that you have to do for domain B to install a site in domain B, regardless of whether it's any other SMS sites. In domain B, you're going to create something called an SMS Service account. And that account needs to be a domain administrator for installation to complete. And SMS Setup will get that account those rights. If the SMS Setup creates that account, we'll give it domain admin rights, we'll give it log on to the service right, we'll give it act as part of the operating system rights. And then we'll install your SMS site.

Now once you have your site installed in domain B, and all the accounts are created in domain B, if you want to set up a parent/child relationship with the site in domain A, you need to create an account that has permissions to write files between those two sites.

You have to look at the SMS_site share name, and that points to \SMS\Inboxes\Despooler.box\Receive. And in that directory, you need to give the accounts change permissions that you want to use for your site address account. So it needs change permissions at that location.

You assign that account by creating the account manually in your domains, and then when you create your address for your other site through the Site Settings, Addresses, New Address, for whatever sender you're using, go to the bottom of that dialog box. There's a Set button. You click the Set button, and that will allow you to specify your account name and password. So those are the only accounts you have to worry about in the interdomain environment. When you have two different domains, you're working with the two different sites. Other than that, all the accounts are created within the domain that SMS is installed in.

Heidi: Moving right along. The next question is: If you have a location site with one server acting as distribution CAP, what happens to the clients if the server goes down? For example, no overlapping boundaries on clients.

Wally: If you have a client access point or distribution point that's unavailable when a client needs to access one of those two resources, and if you have multiple CAPs or multiple distribution points, the client's going to go back to its registry. It's going to find a different client access point or the NAL file and find a different distribution point that it can connect to. That might be over a wide area link, if you're in that environment.

If there are no distribution points or no CAPs available, then if a client wants to send inventory data to a CAP, it will just hold that data for up to eight days. And if it isn't able to find a client access point in eight days, then it deletes the data, assuming it's too old. So it just holds the data, and it will periodically retry to send that data to a client access point.

If it's the case of a distribution point, because you want to do an advertised program, then you'll try the distribution point. If it's unavailable, you'll try another one in your list, and go through all the distribution points available. If none of them are currently accessible, your program won't be able to run, and you have to try to run the program later on.

Heidi: Next question: Can you share CAPs between sites? And if a CAP is down, do the clients find another CAP using the SMS \Logon shares?

Wally: You cannot share CAPs between sites. The only site systems you can share between SMS sites are logon points or domain controllers. Technically, you can share a SQL Server computer between multiple SMS implementations, not the database or devices, but the actual physical SQL Server installation. So CAPs cannot be shared between sites.

As far as the second question, we just addressed that. But if a client tries to access a CAP, and a CAP is not available, it will go to its CAP list, which is in the registry it downloaded from the client access point or from the logon point. It will go back to its registry to find another CAP that's available. It will go through the entire CAP list from the registry. If none of them are available, then the client will just fail that operation. It will try again at whatever its interval is, depending upon the operation itself.

Heidi: Next question. Will SMS support Dfs shares at any point?

Wally: At any point, yes. Currently no. SMS 2.0 does not support DFS. It's on the drawing board. Something they're looking at for a future release of SMS.

Heidi: The next question: Can you hard code force clients to a site? We want to manage our servers separately from desktop clients, and they are both in the same subnet. We were told at the SMS conference this was possible, but we cannot find any tools or utilities to get this done.

Wally: First off, even if you do force your clients to a site, unless you're planning on having a site for your servers and then a site for all your clients, you manage everything within a site the same way. So whatever client agent settings you set up, enable, or whatever, that's for every client within your site, whether it's a server or a client computer. So maybe you're trying to have one site for servers and one SMS site for clients. And they're sharing boundaries. If that's the case, there is a utility in the resource kit or in the SMS 2.0 Resource Guide called Site4c.exe. That utility will let you force a client to a specific SMS site.

However, if that client was ever discovered by another site, or if it hit a logon point for another site, which had overlapping site boundaries, it would also become a client of that site as well. So generally that utility is for clients that would not normally be assigned to a site, and you want to assign them to a site.

For example, if you're not using TCP/IP, and you're only using NetBEUI, you could use Site4c.exe to force that NetBEUI client to become part of the site, because we don't do NetBEUI assignment. We only do IP and IPX assignment. But that utility is in the resource guide.

Heidi: Excellent. The next question looks like it's more along the lines of a support question, but I'll ask it on behalf of the customer, in case we have a general answer to the question.

Wally: There are a couple of things to look at. It depends on whether you're talking about component status summaries or the actual component messages themselves. You can configure whether or not you want any site to replicate status summaries, as well as configure whether or not you want a site to replicate status messages up to a parent site. Those are individual configuration settings that you can set on a per-site basis. So you go to Site Settings, Component Configuration, and Status Reporting, and you can verify that you do have those enabled for replication to your parent site.

Also, those may be replicated at different priorities. Generally summaries are a higher priority than the individual status messages. So you may be getting summary messages up to your parent site, but not the individual status messages, because it's a lower priority.

The schedule that you have between your two sites may be different for when medium- versus normal-priority jobs or low-priority jobs are being sent. You may have a backlog of files, if status messages are going at low priority. You may already have a backlog of low-priority jobs to be processed and sent up to the parent site, so it can't be sent. Your schedule may say no low-priority jobs are being sent up.

If you're not getting any date from your secondary site up to your parent site, then you would look at connectivity issues, the physical connection. You would look at your SMS site address account, whatever account you're using from the child site up to the parent site to make sure it has permissions to the SMS_site share. Which again is \SMS\Inboxes\Despooler.box\Receive. So you'd have to look at that as well.

On your child site, I'd go to \SMS\Inboxes\Schedule.box, and then \ToSend, and look to see if you have a backlog of files there. If so, that's indicating you may have replication problems in getting your data up to your parent site. Then you'll need to work with someone at PSS to figure out why you're having that backlog of files to be sent. Also, look at Replmgr, then Ready, or Process, and see if you have a backlog of files there.

Heidi: Moving right along. You mentioned why logon discovery is a problem with multiple sites sharing a single domain. Do you have any suggestions for a discovery method for our sites with many Windows^® 95/Windows^® 98 clients? They do not have an SNMP agent loaded and do not have file print sharing enabled.

Wally: Sure. Heartbeat Discovery. Heartbeat Discovery is enabled by default, and it's going to create a discovery record and report it to your client access point for your SMS client. So if these Windows 95 and 98 clients are actual SMS clients now, they've already been installed, then you can use Heartbeat Discovery to send a discovery record up to your client access point and into your site. Then weekly, or whatever interval you have it set for, it will update that or refresh it.

If these clients are not installed yet, you still don't need logon discovery. Just have Windows Networking Logon Client Installation enabled, and Heartbeat Discovery, and then that will install the client, discover it, and send the discovery record across to the CAP to the one local site.

If you're talking about not doing installation and you want to find out about the clients, and just doing a discovery process and not installing client computers, then the only other method would be Network Discovery. If you don't have SNMP enabled, and if you don't have file print sharing enabled, then I'm afraid we wouldn't be able to figure out much about those clients, because we need file print sharing enabled to be able to determine the operating system. And you would have to have SNMP to query some of the other information about the client, like the subnet mask.

Other than that, you can still have logon discovery enabled. You'll just pass those DDRs around for your clients to the other sites. You may want to enable that. Do your discovery process. Have everybody log on, be discovered, then turn off logon discovery again. You'll have your discovery, and then you're just turning off discovery once you've used it once.

Heidi: Excellent. Thanks, Wally. The next question is: What tools or monitors are available to automate the monitoring of all the various inboxes that you talked about?

Wally: The school of hard knocks. There aren't any tools directly available to monitor your inboxes. It's a manual process; you have to go through and look at those inboxes. Again, you do have the status system, and the status system may work fine for you. I'm just stating that you shouldn't rely solely on it. You should go through every once in a while and look at those inboxes. But there are no tools available, that I'm aware of, that will go out there and do that monitoring for you.

I'm sure some of you have some programming skills. You could write a little VB app to look at those inboxes and tell you if you have more than a few hundred files sitting there, and displays a little alert for you. But I don't have that ability, not being a programmer. But I'm sure you could find somebody who could do that.

Otherwise, it's just a process. It's a very simple thing to do. You're just manually scanning those 24 different inboxes on the sites looking for a backlog of files. So it's not difficult. I'm just not aware of any automated processes that do that for you right now.

Heidi: Next question: How do you find duplicate SMS IDs, and how can you fix the problem?

Wally: The way to fix the problem is to not clone, because cloning is the only way you get duplicate IDs in SMS 2.0. If you take a client computer and you make an image of it, and that image has SMS client software on it, it's going to have an SMS unique identifier in that client image. If you clone that, and then duplicate that cloned image out to another client computer, you don't have a duplicate ID.

The only way around that, as far as preventing it, is to not clone SMS clients. If you want to clone, clone the operating system, but not the SMS client itself. Or if you do clone the SMS clients, you need to make sure you get rid of all references of the unique ID from the client before you do the cloned image; which again, we don't necessarily support doing.

How you find them: there's a KB article that was just written, Q254735 "How to Clean Up Duplicate Computer IDs." It describes creating a query to search for duplicate IDs. Basically what you do is search through hardware inventory history to find any instance where the computer name is not the same for two inventory events. So if you did inventory yesterday under one name, and you did inventory today under a different name, that would be reported as a cloned computer. It wouldn't necessarily be a clone.

You may physically have changed the computer name. But that's one way of telling when a computer's been cloned: when you do inventory and it has two different names for the inventory. So that's the query that's shown in the KB article. That's how you find them, by querying for changes to your computer name and your hardware inventory.

Heidi: Moving right along, we have five questions left in the queue at this point. The next question is: Does Microsoft support SMS clients running or being members of multiple SMS sites?

Wally: Yes we do. Our client software does support a single client being a member of multiple SMS sites. There's only one area where that might be of difficulty for you, it's not a difficulty for SMS, but for you. Let's use your primary site that your clients are a member of. Let's say you have hardware inventory enabled to run weekly. And now, at another SMS site, hardware inventory is scheduled to run monthly. What's going to happen is that client, when it becomes a member of both sites, has to figure which schedule it uses for hardware inventory. And for one of those two sites, it's going to get hardware inventory, but not on the schedule it expects.

The schedule we're going to use is the site that's listed first in the Sites list on the client. So if you go to your client, you go to Control Panel and then double-click on Systems Management, and you go to the Sites tab, you'll have a list of the two sites or multiple sites. Whichever site is listed first in that list of sites is what's called the home site. That's the site that the client's going to use schedules for when there are conflicting schedules.

The other time where it might be a difficulty is when Site 1 doesn't have software inventory enabled at all, but Site 2 does have software inventory enabled. Well, because the client's a member of both sites, the client is going to install software inventory, and it's going to generate software inventory. So you may not be expecting software inventory to be installed in this client, but in actuality it is going to be installed, because it's a member of multiple sites.

The last area of difficulty is with remote control. With remote control, your client is going to take the settings from all the different sites it's a member of and it's going to combine those settings together to come up with the most secure settings for that client. So if one site says "never ask permission to do remote control," but another site says "yes, ask permission for remote control," the most secure setting for that client is to ask for permission for remote control. So when any site tries to remotely control that client, it's going to be asking permission. It's going to be required to ask permission, which may not be what you want.

So yes you can, but you have those few little problems with schedules, what agents are installed, and how those agents operate, which may be confusing, and not act the way you expect them to, because you're a member of multiple sites.

Heidi: The next question is: We have an issue with SMS 2.0 remote control that Microsoft has probably tackled a million times for other customers. This sounds like it might be a support question. We need to disable the ask for permission from select SMS 2.0 clients, primarily servers in locked closets. I have been forwarded a registry edit, but this reg edit is removed from the SMS 2.0 client during the client update cycle. I have looked on TechNet, on the Premier Online Support site, newsgroups, and have had no luck as of yet. Are you able to help with this?

Wally: You have the registry key. It's Update_Enabled. If you want more documentation about it, it's in Chapter 9 of the resource guide. Chapter 9 of the resource guide is "Remote Tools for the Advanced User," and it talks about how you implement that registry parameter so that you can have permission required turned off for servers but have it turned on for client computers, which is advantageous.

The reason you're losing it is not because your client's being updated. It should be because your client is being reinstalled every 30 days. We talked about that during the session, that currently with SMS 2.0, every 30 days we go through a verification process of the client components, when in actuality, what we're doing right now is reinstalling the client components. So when we reinstall, we wipe out that registry key, so that you're back to the point of going with your site settings.

You can work around that right now with the Cliverify.exe utility. It's documented in Q246040. With Cliverify.exe we can turn off that 30-day cycle right now. In Service Pack 2, that's going to work properly, and it will just do a verify and not reinstall, unless your component needs to be reinstalled. It's actually the reinstallation process that wipes out that key, as opposed to an update process. So when you don't reinstall, you won't have that key being wiped out.

Heidi: Excellent. The next question is: What do you suggest is the best method of inventorying software where the only unique file is a DLL? Currently we are collecting several DLLs for inventory purposes. This, however, requires large amounts of disk space. Is it better to collect the files, because we only need the info about three DLLs, or is it better to inventory for all DLLs? I'm afraid the second option will increase my database excessively without cause.

Wally: You have two choices there. You either are going to collect the individual files, which is going to take disk space on your server, and then you're just doing a query off the file that's been collected. Or you're inventorying for all DLLs, which will increase your database information store in SQL. Those are your two options. It depends on how many DLLs you have and how big your inventory is right now, as to how much that's going to increase your inventory process.

I can tell you from one of the training courses I wrote, that we did a standard inventory process for software inventory, we traced it with network monitor, and then we turned on DLL inventory, the inventorying of DLL files, and traced it as well. And it did significantly increase the size of the inventory files that we sent across.

I don't remember the numbers off the top of my head. But it something like doubled the size of the file, as well as doubled to tripled the amount of time it took to perform the inventory process, because you're going through all the DLLs and opening it up like it's a resource header, and so on. So that is a negative result on that aspect.

On the collected file end, the process of collecting the three DLLs, by default we'll only re-collect that DLL if the file changes. And the DLL shouldn't be changing. So you should only have to collect those files once per client, unless the file is changing. If the file changes, then we'll collect it again in the next inventory cycle. Other than that, we just collect it one time. We do collect it the one time and then store it in the site server. It's either taking up site server disk space or SQL Server disk space.

And if you only need three of those files, it might be better for you to do the file collection process, because again, the DLL shouldn't be changing. So it's a collecting process, one time for each client.

Heidi: The next question is: In regards to SMS sites sharing a single domain, I will be installing a central primary site with about 600 clients and 18 secondary sites throughout the United States with WAN links of 56 Kbps T1 lines. The PDC is located in the central site with four BDCs, and all of the remote sites have a BDC. Will I suffer from the traffic problem of having all the DDRs going to all BDCs?

Wally: If you enable Windows Networking Logon Discovery, yes, you will. So the recommendation there would be not to enable Windows Networking Logon Discovery. Instead, just enable Windows Networking Logon Client Installation, so that you set up all those domain controllers as logon points for SMS, and clients can be installed successfully.

Then use Heartbeat Discovery as a way of doing your discovery records. With Heartbeat Discovery, the DDR only goes to the CAP, which CAPs are not shared between sites. It only goes to a single site, and you won't be flowing your DDRs around your intranet causing traffic issues. So that environment is fine. Just do not enable Windows Networking Logon Discovery. Enable Windows Networking Logon Client Installation instead.

Heidi: The last question we have at the moment is: Can a site server, primary or secondary, be configured locally, and then backed up and shipped to remote sites for a local administrator to attach to the network? Push/Pull WINS is enabled throughout our network.

Wally: Yes, you can. Customers do that quite frequently, where they'll stage their secondary site servers at their primary site or their central site, and then they'll ship them out to the appropriate remote location. To do that, just ensure you install it into the proper domain at the time you do the installation. Then ensure you set your site boundaries properly, because when you're installing it at your central site, it's probably on your central site's network, so it's got a shared boundary there.

Make sure that you add your site boundary for the actual secondary site before you ship it out. Otherwise, if you don't do that, when it gets off to the secondary site, it requires an IP address remotely for the secondary site. The SMS client software on the secondary site server may deinstall because it'll find out that it's no longer assigned to the site. So just install into the correct domain with the correct settings, because you can't change your domain name once SMS is installed. And then ensure you set your site boundaries properly for the destination before you ship it out. Then you should be fine.

Heidi: Excellent. Thank you, Wally. It looks like we have not received any last-minute questions into the queue, so we're going to wrap up our Support WebCast for today.

I want to thank all of you for joining us, and I hope the content was beneficial. If you have any comments or suggestions regarding the Support WebCast program, any comments about today's subject, or any suggestions for future topics, we really encourage you to send us feedback. You can send that to feedback@microsoft.com. Be sure to include "Support WebCasts" in the subject line. We are very interested in your feedback.

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