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 WebCast program. We'd like to thank all of you for joining us today. Our topic will be "SMS 2.0 Software Distribution Details and Advanced Information," and 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. We only answer questions submitted for the Support WebCast during the live event. Also, the Q&A portion of the Support WebCast is intended to encourage further discussion of the Support WebCast topic. However, one-on-one product support issues are outside of the scope of what we can address during the Support WebCast. If you do need technical assistance, please submit an incident on the Web, or contact Microsoft Product Support Services and speak to a support professional.

With all those details aside, let me introduce Wally. Wally Mead joined Microsoft over eight and a half years ago. He now works for the product group as an SMS Program Manager. He focuses on developing and delivering training for early-adopter JDP programs, and more training for our support professionals. During this time, Wally has developed training materials for all versions of SMS. Thank you so much for joining us today, Wally. Let's get started.

Wally Mead: Thank you, Heidi. I, as well as Heidi, welcome you to the presentation and hope you find something worthwhile and beneficial for you here.

What we want to do today is go a little more into detail on the software distribution process of SMS 2.0. I am assuming in this session that you all are familiar with the basic operation of software distribution, that is, how to create a package, how to create a program, collections and advertisements, and so on. In this presentation I'm going to quickly cover an overview of the software distribution process itself. And I'm going to concentrate throughout the presentation on the flow — how information flows from the site server to CAPs, site server to distribution points, down to clients, and so on.

What we're going to concentrate on in this presentation is the flow of the processes internally, as well as how you can do some tracing of the operation of any one of the different processes. For example, if a client is not successfully receiving an advertisement, how can you trace it and see what that advertisement status is on that client computer?

So, the agenda for today (slide 2) will be an overview of the software distribution process. Then we'll go to each of the different flows, such as package distribution flow. And we'll talk a little bit about package location selection, and so on; collection creation and update flow;

advertisement creation flow; how you run advertised programs on a client computer, including detecting the advertisements, the flow for that, and running an advertised program; tracing package and advertisement status; and then troubleshooting software distribution.

Really, the troubleshooting information will be presented pretty much throughout the entire presentation, so you won't find a section called "Troubleshooting Software Distribution." But you will find, throughout the entire presentation, troubleshooting information in each of the different sections.

In each of the different sections I have a slide titled, "Tidbits." This is just additional information that not everybody is aware of, but that can be important for you as you are functioning with software distribution throughout your environment. So with that said, let's jump on in.

The first thing I'm going to talk about is software distribution as a generic concept (slide 3). If you listen to the presentations we did earlier this year on SMS 2.0 common product misconceptions and site design issues, one of the things we mentioned there was the most common complaint about software distribution is that SMS did not install the program properly. That, again, as we mentioned in those sessions, is something that is really outside of the job of SMS.

SMS is not an installation technology. It doesn't technically install programs. SMS is a delivery system or distribution system. SMS will take the package that you create, and it will distribute that or deliver those bits to your distribution point, being your staging server. Then SMS can create additional files that are necessary for client interaction, such as advertisements. And it will deliver that information to client access points.

From there, once the client has detected that advertised program, and it has launched that advertised program, SMS will start the command line that you referenced in your program (and we'll talk about that a little bit later on in the presentation), but SMS does not control the actual program installation. We don't control how the program installs. That is done by your command line that SMS is distributing to your client and launching for the user itself. But we don't do installation. SMS is not an installation technology. SMS is a distribution technology.

One of the things that SMS does do for you is generate status messages. It will tell you which clients have received the advertisement, which clients have successfully started the program, which clients have successfully completed the program, or which clients have failed to complete the program. So we do delivery and status only.

As a side benefit, we also can launch a program for you. However, other utilities, such as the Windows Installer, the SMS Installer, and other third-party utilities, are the actual installation programs. They're installation technologies. They control how the program is installed on a desktop.

SMS might be the delivery mechanism to push out that Windows Installer package, or WinInstall package, or an SMS Installer script. SMS might be the means to distribute it to staging servers, and to get that information to your desktops, and SMS may kick off your Msiexec with your .msi file name, but SMS itself does not control how that program installs. So that's the biggest misconception about software distribution: people think that it is the installation technology, and that's not the case.

Now, with that said, software distribution is the most commonly used and requested feature of SMS. People absolutely love some of the new technologies and new administrative controls we've built into SMS 2.0. We'll talk about some of those as we go through the presentation.

The next slide you have is titled "The Software Distribution Process." It's a graphic that depicts the process flow. I won't spend a lot of time on this, because you should be fairly familiar with it already. However, just as a recap, and to make sure everybody is on a common base, the generic software distribution process is an administrator, at some SMS Administrator Console, or running some WMI utility, creates a package for the SMS site.

That package will be generated at the site server. The package contents will then be assigned to a distribution point. At that point, SMS will push those package contents, basically your source files, out to something called the distribution point. It's essentially a staging area for software distribution.

The packaged information itself — the description about the package, what distribution points contain the package, and so on — is pushed out to a client access point (CAP). Then, when the administrator creates an advertisement, which is the key to get the program from the package available to members of specific collections, when you create that advertisement, the advertisement information, or the offer, is generated at the site server again, and then it's pushed down to the client access point.

So, at this point, you have information about the package — the package descriptions, the location of where all the packages are and the distribution points, as well as the appropriate advertisement files that we'll talk about later on — all residing on client access points throughout your site. The physical package files themselves are residing on distribution points throughout your site.

Then, on the client end, when the client computer wakes up and runs its software distribution client agent portion (that we'll talk about later on), it goes up to the client access point, looks for any advertisements that are available for it's specific client (the computer, the user, or user group that the logged on user is a member of), and it would retrieve that advertisement. If the user determines to run that advertised program, one of those additional files on the client access point will direct the client over to a list of distribution points that contain this advertised program, or the package for the advertised program. The client would then randomly select one of those distribution points, unless there are preferences set, and then launch off whatever the command line is.

So, that's basically the distribution flow, with the exception that any time the client is involved, status messages will also be generated. The client, when it receives the advertisement and it passes the checks that it performs, will create a status message saying, "I received the advertisement."

Then, when the user attempts to launch that command line, a status message will be generated indicating that it launched the command line. When the advertised program exits or is completed, another status message will be generated, indicating that the program has completed, whether successfully or unsuccessfully.

There will also be status messages generated as the administrator creates packages, creates programs for packages, generates advertisements themselves — collection evaluator and the other pieces of the puzzle here — as they do their work, other status messages will be generated as well.

That's the basic process flow. Now what we'll do is get into a few tidbits and a little more additional information on that process. So we'll talk about some package tidbits (slide 5). Again, I'm not going to go through the process of creating a package and all the different package properties that you can assign. I'm assuming that you're familiar enough with those. What I want to talk about are some of the more obscure things, or more advanced things that not everybody is aware of, and that can be useful for you.

On the "Package Tidbits" slide, the first thing we'll talk about is, when you create a package, you have the ability to designate whether or not the package contains source files. Sometimes it might be beneficial for you to designate that your package does not contain any source files, and that's generally useful for programs that you want to run on the client computer, where the program is already installed in the client computer. For standard utilities, such as virus scanners or disk maintenance utilities, and so on — things that the client already has resident, installed locally, and that you don't have to push down to the client — you can create an advertisement that will tell the client to run the program, even though the program is already local. For the monthly process virus scanning, or a weekly defragmentor, or whatever type of utilities you want to run on a continual basis, you just have to create the program, the package, the advertisement, and so on, to make that computer, the client computer, run the program that's installed locally, multiple times.

You have another option, if you do have files for your package, and that is whether or not you want to create a compressed version of your source files. The options are either you don't have any files at all, which we just discussed, or you do have files, and you always want to go back to your source directory for the source files, or you want to create a compressed version. Generally, you only need to administratively tell SMS to create a compressed version if your source files are not going to be permanent.

In other words, when you're creating your initial package, you're creating those source files or retrieving those source files from a compact disc. And that CD may not be in the site server's CD caddy all the time. Or it's a network share, and the network share is going to be updating frequently with additional or updated files. In the case of the CD not being there, then you would want to create a compressed version, so that in the future, if you decide to distribute that package out to a new distribution point, it will be successful. Because if the source files are not originally there, not there where you originally pointed to, and you're not using a compressed version, then that distribution out to the new distribution point will fail.

On the other hand, if the source files will always be present, if it's a network share and it's not going to change (or even if it does change, and the share will be there, or if the source files are loaded on the site server's hard drive) then you can select Always use the source files from the source location. Then you do not have to worry about creating the compressed version. Really, the compressed version option is there for you for sources that are not going to be permanently installed. So, in other words, the CD-type method.

What will happen in that case is, SMS, when it creates the package, will take the CD contents, or whatever your source files are, compress them into a single file, and then use that file to decompress and distribute out to the distribution points. So, if in the future you decide to add the new distribution points, you don't have to go back out and remember to take that original CD and pop it back into your CD drive. Instead, with a compressed version, SMS will just go back to the compressed version, decompress it at the site server, and then push the files out to the distribution points.

Now, the other time you need a compressed version of your files is if you're distributing your package down to child sites. However, you don't need to worry about that as an administrator. Even if you tell SMS to always use the source files, if you do send this package down to a child site, then SMS will automatically compress that package for you, and then push it down to the child site as a compressed package. That will be taken care of, regardless of whether or not you told SMS to compress those files, because we're always compressing the data down to child sites.

The next thing we want to talk about is the distribution location, which is where SMS places these files on the distribution point. We'll talk about the physical location later on. However, you can, if you wish to, control where SMS places those files on a distribution point. The way you do that is by precreating a share name on your distribution point, and for the package that you create, you just target that package to that share name. And then SMS will take those source files and drop them on the distribution point, under the share name that you created.

However, if you do that, you can only put one single package at that share location, if you just designate the share name. Instead, you might want to have a share location called \\Apps, and inside the \\Apps share, you might want to stage multiple different applications — Application1, Application2, and Application3. In that case, what you do when you're creating your package, when you're targeting the distribution settings, is you designate that the source location, the data access location, on the share \folder.

For example, Apps is your share, so you might put \\Apps\App1. Then you create another package, and you would use the syntax of \\Apps\App2. Then we'll create the folder underneath that app share name for each individual application or package to be resident for under.

If you don't do that, then what will happen is, when you try and designate a second package to that share location, SMS will actually indicate to you, in a message box, that that share name is already in use for another program. And if you tried to use it, it would actually overwrite the other programs. So, that's set on a package-by-package basis. We'll talk later on, when we talk about package locations, how you can designate it on a distribution point-by-distribution point basis.

The last thing for the package tidbits is the notion of priority. And when you're creating your package, you can designate a priority. However, some people think that priority is how quickly, in comparison to other packages, will this package install on my clients. And that's not the case at all. You set the priority for your distribution only for distribution to child sites.

In other words, if I'm creating three packages and targeting all three packages down to a child site, is there a preference in the order in which the packages are delivered down to that child site? And the default is, I'll go with normal or medium priority, so it'd be first come, first serve, whoever was created first, and assigned to the child site first, and go in that order. However, if you don't want to do that, then you designate a priority that's higher for one package, and then the other packages, and they will go in that order. So those are a few packet tidbits for you.

The next thing you do after you create a package is you create a program, and the program essentially is a command line that you want to execute at your client computers. So, here are a couple of program tidbits (slide 6): you have an option to have SMS or your program restart your computer. If the program you're running requires a restart of your computer, you have the choice of either having either SMS doing the restart, or your program doing the restart.

If your program requires a reboot, we recommend that you have SMS restart the computer, instead of the program. If you have your program restart the computer, it's likely that you may experience unreliable success status messages for that program, when a client tries to run the program. In this case you may get multiple success messages saying "I successfully installed this program" or "successfully launched the program" for every single computer that launches that program.

The reason for that is if you have your program restart the computer, SMS may not have completed its process of detecting that the program has completed successfully, and had its status message generated, so the client may not have written down the fact that it ran this program. So, you restart the computer, you detect this advertisement again, and the client will say, "Oh, I haven't successfully completed this. I better try it again." And it will try the program again. And you may get into a loop where your program launches every time the ODPs wake up and that advertisement is available.

However, if you have SMS control the rebooting, then SMS will do the rebooting after it has done all the status work it needs to do, and your client will have recorded locally that it has successfully run this program, and it won't necessarily be run again, unless it's advertised to run an additional time. So, that's something you may want to watch for. If you're having a problem with one program, which has been advertised, and which is being run multiple times on client computers, that's one thing you might want to check — on the General tab of Program Properties dialog box, see who is doing the restarting, if necessary. The best option is to have SMS control the restart.

The next thing that's in the program context is who does the program run under? In other words, what user context is used to execute this program? And this is the most confusing aspect of software distribution itself — whether it's the user that's running the program, or if it's not the user, then who, from the SMS aspect, is running that program; and we'll talk about that on the next couple slides. But I wanted to put it here as a "gotcha," something that you need to be aware of: who is going to be able to run that program locally on the client computers, on the target clients? And we'll talk about that again on the next few slides.

With SMS 2.0, you have the ability to chain programs together. This is useful, for example, where you have a program that has some sort of prerequisite. Let's say it's a new Microsoft^® Internet Explorer, and the new Internet Explorer requires a specific service pack on Windows NT^® 4.0. Well, what you might do then is create an advertised program, an advertisement for Internet Explorer, and on the Advanced tab of the program properties for Internet Explorer, you specify that another program is required to run before this program runs. And that other program would be whatever the appropriate service pack is from the service pack package. For example, the service pack program Update.exe for Service Pack 6a, or the Service Pack 6a package itself. So, you can chain programs together.

Now the chained program, in our example the service pack program, does not have to be advertised to the client. It just has to be a package and a program that's been created. And then the client computer, when it detects this advertisement, will see the dependency on the service pack packaging program, and it will check to see if it's already run that package or not. If it hasn't already run the program from that package, it will launch that off first, complete it, and then it will go back and work on the original package — in this case, the Internet Explorer package.

Also, there is no limit on the number of programs that you can chain. So Program A could require Program B. Program B could require Program C. Program C could require Program D. And these could all be from different packages, if necessary, or programs from the same package. There is no limit to that. However, obviously, the more chaining operations you have, the longer it's going to take for this process to complete.

The next thing we'll talk about is when a program is assigned — when you're creating an assignment for a program, which means making it mandatory. When you do that, you can designate whether or not the assignment is for each user who logs on to the computer, or for the computer itself. If you designate that the assignment is for each user, then, if you have a shared computer scenario, where multiple users share a single computer, for each user who logs on to that computer, and that user is a member of the target for that advertisement, then each user would run that same program on that computer. And that's often useful if you install a program that has a computer portion as well as a user configuration portion.

You might create the computer portion as a chained program, and then create the user portion as a program that's assigned for each individual user. Each user logs on; they detect the advertisement; they run the user portion. "Oh, by the way, has the system portion been installed yet? If not, run it," and that should only be run one time.

Then lastly, something that some people want to do is disable an advertisement. They've created a package — a program — and they've advertised that program to members of a collection. Then "Oops," something went wrong. They advertised it too soon, or they weren't ready, or they found some sort of a problem that they hadn't encountered earlier, and they want to cancel that advertisement immediately.

One of the easiest ways of doing that is by going to the Advanced tab of the program properties, and down at the very bottom of your Advanced tab is a check box that says, Disable this program on computers where it is being advertised. You select that check box and click OK, and that will cancel that advertisement. It keeps the advertisement that was created. The advertisement is still there. However, it puts a special flag in the properties of that program and advertisement that states, "Do not run this advertisement right now." So, all computers will be prohibited from running that advertised program for that time period.

Then, when you've got your problems solved, you're ready to run the program, and you have your licenses set up or whatever the case is, just go ahead and clear the check box, hit OK again, and SMS will remove that flag, and now your client computers can run that advertised program as necessary. So, that may be the quickest way for you to cancel an advertisement or suspend an advertisement without physically deleting the advertisement itself, then re-creating it when you want it.

In the next couple of slides (slide 7), we want to talk about the different contexts that programs can run under. So, when an advertised program is running at a client computer, under which user context is it being run? By default, programs will run under the context of a logged on user. Generally, when we're talking about these types of user context, we're referring to Windows NT computers, Windows^® for Workgroups, Windows^® 3.1, Windows^® 95, Windows^® 98, and so on — those operating systems don't have concepts of users versus administrators, or multiple security contexts. Everything there runs under the context of the logged on user.

On Windows NT, however, you have multiple user accounts. You have tokens that can be used for impersonation, and so on. So, you do have different contexts that you can work with. In a Windows NT scenario, you have to determine whether or not your advertised program can run with user rights at the client computer, the Windows NT client, or whether it requires administrative rights at that client computer.

If you know your advertised program requires administrative rights, then you have to determine are your users at all your Windows NT client computers local administrators, or not? In other words, if I say run with administrator rights, can all my users successfully install that program, if we use the logged on user context? If the answer to either of those two questions is no, you can't guarantee that all your users are logged on as administrators, and you know the program does require administrative rights, then, most likely what you're going to have to do is tell SMS to run with administrator rights.

When you tell SMS to use administrator rights, which you must configure for the appropriate program, then SMS will use an internal account as the administrator account. We will only use the logged on user as an administrator if you don't tell SMS that the program requires administrative rights. However, if you do tell SMS that the advertised program requires administrative rights, then we will not even check to see if the logged on user is an administrator or not.

Instead, we will use one of the two possible SMS accounts as an administrator account. By default, when you say that the program runs with administrative rights, we're going to use the SMSCliToknAcct& as the account that we run the program under. If you look at that account, and we'll talk about it more in the next slide, you'll see that account is not, by default, an admin. However, we will make it an admin for that program.

The other option you have is to use the Windows NT client software installation account. So, when you tell SMS that a program requires admin rights, you can also designate for SMS the use of the Windows NT Client software installation account. This is an account that you have total control over. You have to create the account and tell SMS about the account, and then tell your advertised program to use that account, and we will discuss that on the next slide (slide 8).

If you tell SMS that the program runs with administrative rights, then we don't even look at your logged on user. We don't test to see if that logged on user is an admin or not. We just immediately kick over. We ignore the logged on user. We immediately kick over, and use one of our accounts.

The default account would be the SMSCliToknAcct&, and again, if you look at your local SAM on the Windows NT client, you will see that that account is not a local administrator. It's a local account in the Windows NT accounts database. However, it's not a member of the administrator's local group. It's a member of the SMS internal client group, which is a special SMS group that we create to assign permission to this account.

However, what happens is when SMS detects that the program being advertised requires administrative rights, and you haven't told us to use the Windows NT Client software installation account, then SMSAPM32 takes the SMSCliToknAcct&, adds it to the local Administrators group, kicks off your advertised program (whatever that command line is), and as soon as that advertised program exits, SMSAPM32 takes the SMSCliToknAcct& and removes it from the local administrator's group again.

It doesn't remove the account from a local SAM. It's required to be there. However, we just remove it from the administrator's group and make it a member of SMS internal client group. So, it's made an administrative account solely for the context of this one program's execution, and as soon as that program executes or completes, then we remove it from the administrative rights.

That's how we use a local Administrators account internally within SMS. And this account is secure, because each instance of a Windows NT computer has the same account, but each instance has a unique password for this account, and you don't control that password. It's randomly selected internally by SMS. So, it's a unique password, and you have no security breach there at all.

The alternative is to use the Windows NT Client software installation account. This account is an account that you have to create yourself. So you would go to your local domain or to your Active Directory™, and you would create an account as a domain user. You create some account name, make it a domain user; you would tell SMS about this account, in the software distribution component configuration. You would tell SMS about the account. And then, on your advertised program, you would designate Program requires admin rights, and then select the check box that says Use the Windows NT Client software installation account.

Then what will happen is, when the client has been updated and it knows about this account information, that will be encrypted in the client's registry. My slide says encrypted in a client SAM. That is incorrect. It's encrypted in the client's registry [Editor's note: The slide deck will be updated with this correction.]. So, this account is encrypted in the registry, and when you run the advertised program that requires this account, SMSAPM32, again, will decrypt that account from the registry, add it as a local account in your SAM, in the local administrator's group, and it will run your advertised program. And when the advertised program is completed, then it will remove the account from the SAM entirely, so it's not present in the local security accounts manager database on the Windows NT client.

We place it in the local administrator's group for the program execution. Then we will remove it from the local SAM entirely, when the program has been completed, and it's just encrypted in the registry again. So it's only there for the period of time while that program is being run.

Now, this account should only be used if your advertised program requires access to remote resources; in other words, a server other than where the program is being run from. For example, your advertising and network application needs to access another server on the network. In that case, the SMSCliToknAcct& would work, because the SMSCliToknAcct& is not supposed to have network access. It's a local account, not a network account. So that account doesn't have network access.

That wouldn't work to connect up to the other server. So what you do is create this Windows NT Client software installation account, create it as a domain user, give this account the appropriate rights that you need to, to your other server, and then tell SMS to use the account, and we'll use that context.

So, your choices, again, as a quick recap, you can use the logged on user. However, that probably won't work in today's environment, because a lot of programs require administrative rights — for example, Office 2000. If you have a program that requires administrative rights, you either have to make all of your Windows NT users local administrators, which most people will not want to do, or you have to use an internal account — either the SMSCliToknAcct& or the Windows NT Client software installation account. And one of those could then be used as your administrator account. But you don't just use the Windows NT Client software installation account as a matter of habit. You only want to use it when necessary, and that's when you need that additional server context.

The next slide shows you the flow for package distribution (slide 9). A user sitting at an administrator console creates a package in the SMS Administrator Console. That updates the SQL Server database itself. From there, there's an extended stored procedure in SQL Server™ that detects a change to the Packages table.

It notifies SMS SQL Monitor through a named pipe. SQL Monitor then will notify Distribution Manager, at the site server, through a special wakeup file. This is a file that's written to the Distribution Manager's Inbox, which is Distmgr.box on the site server, and that will wake it up to go look at the Packages table in the SQL database.

Distribution Manager will then kick in. Distribution Manager is a thread in the SMS Executive. So, in this presentation, and other presentations, whenever you see the little puzzle piece in the corner by Distribution Manager or Replication Manager, or Inbox Manager, and so on, that indicates it's a component or it's a thread of an existing service. In this case, it's the SMS Executive.

Distribution Manager will compress the package files, if necessary. So, if you told the package that it required a compressed version, Distribution Manager will find those source files and compress them. Also, if you do target this down to a child site, Distribution Manager will compress the files.

It finds the distribution points you targeted, and finds the drive with the most free disk space that's NTFS format, on the distribution point, to distribute the files, or the share point, if you gave it an existing share name. It creates the appropriate package files and the NAL files. It will then hand those files off to Inbox Manager, which copies the package file and the NAL file down to the client access point. Distribution Manager itself copies the package files to the distribution point.

If I'm a parent site, and I have child sites, then automatically, the package file, the description of that package that you created, is automatically sent down to all your child sites. The actual .pkg file will be sent down to your child site. Distribution Manager will make a request of Replication Manager, which will then bundle up some files, and hand it off to scheduler. Scheduler will create a package and instruction file, a send request file, and give that to a sender to send down to your child site. And the child site would receive those and then process them.

And in the SMS Administrator Console at the child site, you would actually see that package appear in the admin console, but it would have a locked icon on it. The package icon would have a little gold lock on it indicating that the package is owned by a parent site, and you can't modify the package itself. However, you could assign local distribution points to that package.

So, that's the actual flow for package distribution itself. Now, let's talk for a minute about the location of distributed packages on distribution points (slide 10).

By default, packages are going to go to the distribution point that's assigned, on a package-by-package basis, to the drive with the most free disk space. So, we're going to look for the NTFS drive with the most free disk space. We do require NTFS on our Windows NT or Windows^® 2000 distribution points. We'll find the NTFS driver with the most free disk space, and we'll create a share name out there. The share name will be titled, Smspkgx$. The dollar sign just makes it hidden, so when the users are browsing that server through a browse list, they won't see the share name.

Because of the fact that SMS chooses the NTFS drive with the most free disk space, and because we do this on every single package we distribute, you may send out three consecutive packages, and it's possible for each package to wind up on a different drive on your distribution point. Because when you send your first package, we find the NTFS drive with the most free disk space, and supply the package there. Now, that drive no longer has the most free space in NTFS. The next package comes out, and it takes the next drive with the most free disk space, and so on. So, it is possible for three packages to wind up on three different drives on your distribution point.

If you want to control that, you could specify your target directory. And I mentioned that earlier, on one of the previous slides. For individual packages, when you create the package itself, you just specify the share name for that package, and we'll use that existing share name on the distribution point. Now, if that share name is not pre-existing, then we'll again find the NTFS drive with the most free disk space, create the share name, and dump the files there.

If you want to create a share for all your packages and have all your packages go to the same share point, so you're controlling which drive, then what you do is you create your distribution point as a Windows NT share, instead of a Windows NT server. When you're creating a site system on a Windows NT environment, you can designate that it's going to be created as a share or a server. Server means we control the drive. Share means you control the drive.

So, you would pre-create the share name on the NTFS drive you want to use, and then add that site system with the syntax of \\Server\Share name. Make sure you designate it as a Windows NT share, instead of a Windows NT server, and it will use that for that specific distribution point. So, that's a good way for you to control locations of individual distribution points, not necessarily on a package-by-package basis.

Tracing package creation (slide 11) — I went through the flow quickly. How can you trace it on your own? If you're having a problem where a package is not arriving at a distribution point, or it's not being sent down to a child site, how do you trace this? There are actually three ways. I'll talk about two of them now.

The first way is through the SMS Status system. You would look for SMS Distribution Manager. Go to the system status, go to site status, go to the local site, go to component status, and then select SMS Distribution Manager. You should see the status messages that I have designated on your slide — 2300, 2301, and 2311 — for creating packages themselves, or if you modify the package contents or modify a program or any properties of a package. Then for actual replication of that package to a distribution point, you would see 2343, 2349, and 2330. Those are status messages you would look at.

If there's a failure, no NTFS drive or not enough disk space on the NTFS drive, or no administrative rights to the distribution point itself, then you would see an error message on one of those, and it would give you a possible solution. It would say rights, or disk space, or server not found, or whatever the case is.

Now, for distribution down to a child site, you would look at the status messages for the SMS Replication Manager, the SMS Scheduler, the SMS LAN Sender, or whatever the appropriate sender was that you were using to push data down to a child site. So, you would look at those status messages for those components to find out whether or not there were issues with transmitting those packages, that package's description, down to your child site.

Now again, package contents don't go down to a child site automatically. It's only the package definition. The package contents only go when the administrative child site doesn't work. We'll talk about that later on.

Log files are the other way of tracking your package creation process. So, you'd look at Smsdbmon.log. That's the SMS SQL Monitor log file, and that's where you would see where it says it created the .pkn file. That may be an indication that if that doesn't happen or doesn't appear, maybe your named pipes have been turned off for SQL Server, and that's how we notify SQL Monitor. If you don't have named pipes, then SQL Monitor is not notified. So, it's not going to know to create the .pkn file until it wakes up on its hourly cycle.

Distmgr.log is where you'd see the creation of the package, the distribution of the distribution points, and the request to send data down to a child site. Inboxmgr.log is for replication of the package and NAL files to your caps; Replmgr.log, Sched.log, and Sender.log for sending files to child sites themselves. So you'd have to look at all three of those to see if there are any issues.

At the receiving side or the child site, look at the Despool.log, Replmgr.log, and Distmgr.log for any issues involved around sending, receiving, or decompressing those files. So, there are lots of different ways of looking, and I don't have time to go show you all the different log files, but those would be what you'd want to look at as far as troubleshooting. Make sure that you have logging turned on, or that you're at least working with the status system and tracing that way.

When you're doing software distribution, it targets your advertised program to members of a collection. Let's talk about collections, quickly. Updating a collection (slide 12): in the graphic, we go through four different steps of updating a collection.

In the first step, where number 1 is, you're adding a brand new Windows NT computer — in this case, this computer name is Computer 22 — to your SMS site. So that's step 1.

When the site server detects that new computer through the discovery record that will be generated, it's going to add it to the SMS database. That's where you see step 2, and Computer 22 is in bold. Computer 22 has now been received at the database. Collection Evaluator, at its next scheduled interval, will go through and process all discovered resources to find out which ones belong in which collections. So, Collection Evaluator will determine that Computer 22 is now a member of the All Windows NT collection.

When that happens, Offer Manager will state, "Hey, we have new collection members," and Offer Manager will then go out and do its processing of its membership list, and it will find that Computer 22 has not been targeted with the advertisement for Service Pack 6a, which has been advertised with the all Windows NT collection. So, what will happen is, Offer Manager will automatically create an advertisement, an instruction file, and modify the appropriate lookup file for Computer 22. The next time Computer 22 runs its client portion of software distribution, it will automatically receive the Service Pack 6a advertisement.

So you, as the administrator, have not had to do anything at all. SMS took care of adding the new computer to your site, and pushing Service Pack 6a out to that Windows NT client computer. So, that's pretty cool. Whereas in previous releases of SMS, you had to go out and create a new job to target that new computer, it's now all handled automatically for you.

How collections are updated is the next topic (slide 13). SMS SQL Monitor will notify Collection Evaluator when it's time to update collections, and it does so by schedules, and we'll talk about schedules on the next slide. Or it could also be administrator controlled. So SQL Monitor will notify Collection Evaluator with a special wakeup file, saying it's time to wake up and run collection membership. It's going to run new queries that are targeted or assigned to those collections as membership rules, and then update the membership itself.

If there are any child sites, Collection Evaluator will automatically send the collection membership rules down to child sites. Just like with packages, we sent that information down to your child site, and it will appear in your child site's administrator console. If you view your collections, you'll see the collection will now have a lock on it. Again, that lock is indicating that a collection is owned by another site, and you can't modify the contents. However, local Collection Evaluator will determine which members of the local SMS site database are members of the collection locally.

We do run the membership rules for the secondary site, and push the assigned resources down to that secondary site itself.

A couple of tidbits on collections (slide 14): collection definitions are automatically sent to child sites, as we just designated. That happens as soon as a new collection is created. As soon as you create a new collection in your SMS Administrator Console, that collection is sent down to all your child sites. So, if you have 100 child sites, that single collection is sent down to all 100 child sites.

We also send down all collections that you have whenever a new child site attaches to your local site. So a new child site has attached, you created the secondary site, or an additional primary site is attached to you as a parent, then you send all your existing collections down to that one new child site.

Then lastly, on a scheduled basis, which is weekly by default, all collections are sent down to all child sites. Let's say you have 100 collections that you created, or that were default collections, and you have 100 child sites; every seven days, by default, SMS will send all 100 collections and their membership rules down to all 100 child sites. This is called the refresh of your collection membership rules.

That happens by default; in Service Pack 2, this is a process that you can control — you can disable or change the timing if you want to, through the registry, but it's only available through Service Pack 2, and not prior releases.

Collections are updated on a schedule, not when a new resource is discovered. So, a couple slides ago, when we had a Computer 22 that was joining your site, Collection Evaluator didn't immediately wake up and say, "Oh, a new resource has been assigned to my site. Let me see if it belongs to any of my collections." No, Collection Evaluator wakes up on a scheduled basis, and by default, for the built-in collections, it's every hour. Every hour, Collection Evaluator wakes up and runs all of the different membership rules for all the built-in collections. In this case, the All Windows NT or All Windows NT Systems collection. For any collections that you create, you could just set the schedule on when Windows Collections are updated.

If you do designate that the collection is to be updated on a schedule, by default, this happens every two hours; although, again, you can change that schedule. Then, any time an administrator wants to, the administrator can force a collection to be updated by selecting the collection in the admin console, going to the Action menu, selecting All Tasks, and updating collection membership, and that will force the collection to be updated at that point in time.

Lastly, you need to be careful with collections using custom data. We talked about this in the common problems and misconceptions session, but the case here is that if you create a custom architecture in your database (in other words, you created an IDMIF that created a new architecture), that's going to update a new architecture outside of hardware inventory or your system architecture.

If you do that, and you create a collection based on that custom architecture, then, as we just discussed, all collections are sent down to all child sites automatically. When this collection that's targeted to this custom architecture is sent down to a child site, if that child site does not have that custom architecture, Collection Evaluator is going to generate numerous errors stating that it cannot process that collection because it's pointing to invalid data. So you either need to not create collections based on custom architecture data, or you need to make sure that all of your child sites have that same custom architecture. Just make sure all child sites have that same ID MIF so that they'll have updated the local database, so the collection will be able to process successfully.

Tracing collection processing (slide 15) is done the same two ways, using the status system and the log files. With this status system, you're just looking at the SMS Collection Evaluator instead of the Distribution Manager, and you're looking for messages 2513 and 2516 for collection creation and membership updates, and then the same components: Replmgr.log, Sched.log, and whatever sender you're using, if you're replicating down to child sites.

Log files: again, SMSdbmon.log, which is the SMS SQL Monitor log file. There you're going to find the creation of .adc, .udc, and .dc files. The .adc file is an add collection. The .udc file is an update collection (you change the membership rule, etc.). And .dc is a delete collection. So those would be the appropriate files that would wake up Collection Evaluator when you're adding, updating, or deleting a collection.

Colleval.log is the log file for the Collection Evaluator itself. That's where you'll see collections being created, collections being updated, and replication of collection membership rules on the child sites. Again, the Replmgr.log, Sched.log, and Sender.log files for transmitting down to child sites, and the Despool.log, Replmgr.log and Colleval.log, at the child site, for receiving those replicated collections.

Implementing advertisements (slide 16): the process here is that you create an advertisement in the SMS Administrator Console that updates the database. The extended stored procedure updates SQL Monitor through a named pipe. SQL Monitor updates the Offer Manager, which is a thread of the SMS Executive on the site server, which then creates the lookup files, instruction files, and the offer files that are required for the local advertisements.

Inbox Manager will replicate the offer file, the lookup files, and the instruction files from the site server down to the client access points. That's what the clients will look at. We'll talk about that in a few more slides.

If you have child sites, then again, just like in packages and collections, the definitions are automatically replicated. Your offer definitions, the advertisement itself, is automatically replicated down to child sites. But it's just the offer file only, it's not the lookup files or the instruction files, because those are built on a site-by-site basis, and we'll talk about that coming up.

So, that's again, a quick flow. SQL Monitor wakes up Offer Manager, which creates the files locally. Inbox Manager replicates them to CAPs, and then, if there are child sites, the offer file is replicated down to the child sites, so they know that you created an advertisement at the parent site.

The advertisement lookup files (slide 17): with SMS 2.0, you can target software distribution or advertised programs to computers, users, or user groups. That's very powerful, for SMS 2.0 to allow you to do that, to be able to target to not only computers, which most people do, but all members of a specific user group, or "Wally," no matter what computer Wally is logged on to on the network.

Each target class, whether a computer, a user, or a user group, receives a special or a unique lookup file, as created by Offer Manager. For computers or systems, the lookup file is — if you look at the slide, I have three question marks. Those three question marks are symbolizing your site code. It's going to be your three-character site code (???), in this example, ???Systm.lkp. That's the local site code's system lookup file — lookup file for systems or computers in the local site.

Users is ???Usr.lkp, and user groups is ???Usrgp.lkp. As you create an advertisement for each of those different types of systems or targets, Offer Manager will create or update the appropriate lookup file. By default, you don't have any of those files created, and you won't have, until you create your first advertisement.

Offer Manager creates each of these as necessary. When you target an advertised program to a collection, it will create the appropriate type of lookup file — the Systm.lkp file, the User.lkp file, and the Usrgp.lkp file — provided that there are members in the local site that evaluate to that collection. It won't create a lookup file for systems if there are no computers in the collection.

It also will not create the lookup files until the package has been distributed to a local distribution point. So the package has to reside on a distribution point in the local site before those files can be created as well.

These are the files that the Offer Data Providers, or the ODPs, on the client use to look for the advertisements. There are a couple different ODPs in the client computer that will wake up periodically and look in the CAP for these lookup files. If it finds a lookup file, it'll look to see, "Hey, am I targeted in that lookup file?" And we'll talk about that more in the last section, running advertisements at client computers.

A couple of tidbits on advertisements (slide 18). Again, advertisements are automatically sent to child sites, regardless of the targeted systems. So, even if you just target a collection, which only includes local users, or local computers, or user group members, the advertisement definition is still going to go down to the child site.

Offer Manager at the child site would create local lookup files and instruction files if there are members of that collection locally assigned, and the package has already been distributed to a local distribution point. Those two things have to be true in order for Offer Manager to create files locally at a child site, even though the offer file has been replicated down.

Another thing that's fairly confusing for users is they create an advertisement that's an assignment. They create an assigned advertisement that says run this program at this date and time, or with some condition. That advertisement may fail for some computers, and you want to force that advertisement to run again.

There are a couple different ways to make that happen. The first case is if this is an advertisement that's not assigned — in other words, an advertisement that users have control over when it runs — then, the user just has to go back to the Advertised Programs Wizard. So go to Control Panel, double-click Advertised Programs, run the wizard, and that same advertised program will still appear there.

We don't remove that until you remove the advertisement itself, or until the user is no longer assigned, the computer is not assigned, or the user group members are no longer assigned to that advertised program. Then it's removed. But you can always re-run an advertised program multiple times just by re-running the wizard, and selecting that program to run. That's provided it is available for the user to run.

If it's an assigned program, then what you need to do is create a recurring schedule for that assignment. In other words, this can't be set as an "as soon as possible" advertisement. An "as soon as possible" advertisement doesn't have a specific date and time assigned to it. So, you need to have a specific date and time assigned to your advertisement.

Say, when you initially created it, it was set to run on Tuesday, 10:50 A.M. If you have a specific date and time assigned to that, all you have to do to make the computers run that advertised program again is to add a new, assigned time to that existing advertisement. We don't create a new advertisement. We just go into the schedule for that advertisement and create an additional schedule. Where it might have been Tuesday at 10:50 A.M., now make it Tuesday at 3:00 P.M., or Wednesday at whatever time. Any time you have multiple schedules on a single advertisement, SMS treats that as a recurring advertisement. In other words, run this again; and then all those computers would pick that program back up and run it again.

If you didn't do that, if you did create it as an "As soon as possible," or "On log on" or "On log off" type of advertisement, then you actually have to create a new program, because SMS tracks advertisements by programs. So, just creating a new advertisement won't do anything for you, because you're still advertising the same program, and SMS will say, "Oh, I already ran this program. I don't need to run it again." It has to be a different program name in your package, and then you can create a new advertisement.

The other way is a way that we don't really want you doing, but sometimes product support will have you do this, and that's blow away some of the local files in the client computer, so that the client doesn't realize it ran that program before. And then you kick off your ODP, and it will say, "Oh, I haven't run this advertisement before," even though it has, and it will force that advertisement to run again. And that is documented in the release notes for Service Pack 1 as well as Service Pack 2, on how to force an advertisement to run again. So, if you didn't get what I said, or didn't understand it, just look at the release notes for Service Pack 1 or 2.

"Tracing Advertisement Creation" (slide 19): again, you can use the status system if you're looking for Offer Manager, and it's message ID 3900 for advertisement creation, then the same components for replication, on down to your child sites. A couple log files you'd look at, again, are SMSdbmon.log for the creation of the .ofn files, and that's the offer notification file. That's what's going to wake up Offer Manager to say, "I've got an advertisement I have to work on."

Offermgr.log is for verification that the package is ready, enumerating members of the membership list, presenting offers to members, so you'll see exactly what systems or users are targeted with that advertisement, and replication of your offer down to child sites. Inboxmgr.log is for replication of the offer files, instruction files, lookup files to CAPs. And then there are the standard files for replicating down to the child site, or Replmgr.log, Sched.log, and Sender.log. And then on the receiving side, Despool.log, Replmgr.log, and Offermgr.log. Again, for an Offer Manager at the child site, you would look to see whether or not it has assigned resources locally and that the packages have already been targeted locally.

Now I mentioned before, for troubleshooting or tracing, there were three different ways, and we covered two, status system and log files. The third way is by looking for the file system. Look at software distribution files sitting in the appropriate locations. If you're not seeing advertisements run properly, or you're not seeing packages being distributed, you want to look at these three different systems (slide 20) for specific files.

On the site server, you're looking at SMS\Inboxes\Pkginfo.box, and you're looking for package and NAL files. Package files would be .pkg and NAL files would be .nal. On SMS\Inboxes\Offerinf.box on the site server, you're looking for lookup files (the .lkp files), the offer files (.ofr files ), and instruction files (with the extension .ins).

If you create a compressed package, you're looking for the Smspkgs folder, and that will generally be on your site server drive, unless you target it to a different drive, which you can do when you configure a software distribution.

On the CAP, you should find in the CAPs folders Pkginfo.box, the package and NAL files. On the Offerinf.box, you'll find the lookup, offer, and instruction files. Then, obviously, on the distribution point, whatever share point you designated, or the default share name, you're looking for SMSpkgdrive$\ (or your own share name you designated) PackageID, and then you look to see the package source files there.

So with Office 2000, or Windows 2000, or whatever the packages are that you happen to be targeting down to your client computers, you're looking for the package files there. Again, remember, we talked about this earlier, some packages don't have source files. There may not be files there.

That's getting everything ready at the site level. Now let's quickly go through what a client does to run an advertised program (slide 21). Once you've got the site level all set up, to run the advertised programs the client needs access to the lookup files, instruction files, and offer files on the client access point. So, the first thing you have is your client is not running an advertisement when you think it should.

Well, the client is going to run its advertised programs when it detects that advertisement is available. It isn't continually polling the CAP to ask, any new advertised programs? It wakes up on a cycle to check and see if there are any advertisements. We just continue to do polling, but it's, by default, on an hourly schedule.

If you don't want to wait that hour, and you want it to happen right now, you can use the Advertised Programs Monitor utility. This is in the Control Panel of your client. So just go to Control Panel, Advertised Programs Monitor.

You can launch Advertised Programs Monitor, and that will show all programs that have either already been run at your client computer, or that are scheduled to run on your client computer. What you won't see are programs that are available but that have not been run yet; you will see only things that have already been run, or are scheduled to run at a specific date and time. If it's an assigned program with a specific date and time, you'd see when it's going to run, but if it's just a standard advertisement that's not assigned, you won't see them there.

However, you can force a refresh of your advertisements, which then forces the client agents, the ODPs, to wake up and check the CAP for advertised programs. Again, you won't see them in here, unless they're scheduled, but you will wake up your ODPs instead of waiting for whatever your configuration polling interval is. So the Advertised Programs Monitor utility is one that you might to want to use to force your ODPs to wake up and search for new advertisements.

This how you do that (slide 22): the way the client operates is there's a process called Launch32 that's responsible for launching user-based programs. So by default, every hour, Launch32 is going to kick off your ODPs. And there are two offer data providers. There's one that looks for advertisements to the computer, and one that looks for advertisements to the logged on user, or the user groups that the logged on user is a member of.

Those two ODPs wake up. They connect to the client access point, and they look at the Offerinf.box on the CAP for any lookup files. When they find the lookup file, they then open up the lookup file, look to see, "Is my computer assigned in the system lookup file?" And that's done by the GUID of the computer. Or for the users, "Is my user account name, or are the user groups that I'm a member of, in the user lookup or user group lookup file?" If so, then it reads the appropriate offer's information instruction file, which points it to the offer file, and it reads that information; and it presents it to the user, either in the Advertised Programs Wizard, or just to the utilities internally, SMSAPM32, to run the program.

The Advertised Programs Manager, which is SMSAPM32, is what runs the advertised programs. Once an advertised program has been detected, it will either appear in the Advertised Programs Wizard (the user mode of software distribution), or the system mode, the executable itself, will launch and run that advertised program, if it's time. So, it will connect to the distribution point, find the appropriate files on the DP, and launch the command line that's designated for that program.

If necessary, it will take the SMSCliToknAcct& as a local admin, and then run the program. It will also generate status messages, indicating it received the advertisement, it started the advertised program, and it successfully or unsuccessfully completed the advertised program.

A couple of tidbits for advertisements (slide 23): All clients detect advertised programs at the scheduled interval. Again, there's no such thing as a "right now" deployment. You might get the files on the CAP in a very quick process, but the advertised program won't run on the client until the client ODPs wake up and detect that advertisement is available. And again, by default, that's hourly, although you can configure that in your site level. You would do so at the Advertised Programs client agent; or on the client level, in the Advertised Program Monitor utility, where you can configure what your refresh interval is. Or you can force the ODPs to run right now, using the with advertised programs monitor, using the Refresh option on the View menu. You could even use the client utilities, or the set event utilities from the resource kit. People use those to kick off the ODPs.

If multiple advertisements are available for a single program — in other words, my client might be a member of multiple collections, and each collection is targeted with the same advertised program, so I'm going to receive the same advertised program multiple times. What the client agent does (SMSAPM32 in the client), is it merges the offers into a single offer file. It gives the earliest start time and the latest expiration time, if there is one, for that program. So, basically, it makes that program available for the widest amount of time as possible by merging those offers together.

You might want to, within administrative mode, create multiple advertisements of a single program to multiple collections. So, by creating separate advertisements targeted at separate collections, you could balance your load. In other words, you distribute the load on Windows recipients that are going to run that advertised program. So, you're controlling the network traffic, you're controlling the use of distribution points, maybe controlling just when the users are running their program, by doing so. Those are a couple of things you can do for targeting and more control.

A couple things on status (slide 24), and then we're about done. SMS does a very good job, in the status system, of tracking your package status. We can tell you when your package was created, when programs were created, when distribution points were assigned, when programs or packages were placed on distribution points. We can tell you when advertisements were created. Basically, all the information about a package itself, as well as advertisements, can be tracked, either through Distribution Manager itself, its component, or by looking at the appropriate package under the package status in the status system.

For advertisements, we even give you a little bit more data. You can see when an advertisement was created, when it was processed by Offer Manager, internally. You can see when client computers received that advertisement or rejected it. You can see when the program was launched by the client. You can see when the program completed successfully, or whether it was unsuccessful. Those are all tracked in the advertisement status portion of the SMS Administrator Console.

If you want even more information on your advertisement status, you can use the utility AdvertView. AdvertView is in the support bundle of your SMS CD. In the Service Pack 2 CD, go to the Support directory, expand the Support.exe bundle, and then under the Software Distribution Tools, you have AdvertView. You can use AdvertView to view advertisements and status messages by collection. You can say, "What are all the advertisements and status messages for this one collection?" Or you can view messages by specific advertisements: "Show me all the messages for this one single advertisement."

It also allows you to generate some statistics. How many computers received it? How many messages indicate a failure? How many rejected it, and so on. It's a pretty good utility to work with to get additional information on your advertisement status.

There are a few site hierarchy issues (slide 25) that we'll finish up with. These three things automatically flow down the child sites: package definitions (not necessarily package contents, but package definitions), collection definitions or membership rules, and advertisement definitions. Those three things flow down to your child sites automatically. Now, package data only goes down to a child site if it's required to, and that can be done by either the parent site targeting a child's distribution point, or a child, when it receives that package definition, takes that package and distributes it to its own local distribution point. In that case, the child will send a request up to the parents saying, "Hey, I need that package that you told me about," and we'd compress the files, if they're not already compressed, and send them down to the child site, who would then decompress and place them on its distribution point.

Status flows up the hierarchy automatically. So your package status, your advertisement status, is going to go from your child site on up to the parent sites. All site-to-site communications are compressed and scheduled, and the bandwidth can be throttled. You have pretty good control over when SMS uses your WAN links between sites, as well as how much that WAN link uses. We compress the data automatically. You can schedule when we use the WAN links, and how much of the WAN link we use.

If you have a very slow site scenario, you can use the Courier Sender. The Courier Sender is very useful in slow-link environments. In that environment, you can use a tape, burn a CD, or use floppy diskettes to send your source data down to your child site, instead of using whatever your link is, like maybe a 19.2 or remote RAS link. You can burn a CD and send it down, and SMS will pull the data off the CD automatically, using a special utility at the child site called Courier Sender Manager.

And then package routing could help control link usage. Here's what package routing is. Suppose I'm a central site, and I want to target down to grandchild sites. I can have my immediate child sites forward the package for me. I could send the package from my site down to my child sites, and then they can forward that down to their child sites, or my grandchild sites. That only works if the central site does not have an address to the grandchild site, or the address is unavailable; then we'll use routing. But if you do have a point-to-point address from central site down to grandchild or great grandchild, and the schedule is available, we'll use the point-to-point link and address.

Additional resources (slide 27): you've seen these from previous presentations. The Systems Management Server 2.0 Administrator's Guide is very good for giving you basic information about software distribution. Again, remember that the online version is the best version, because it's updated, whereas the hard copy has not been updated since the RTM version. The System Management Server 2.0 Resource Guide, which is available separately, or as part of the Microsoft^® BackOffice^® 4.0 Resource Kit, has some good information for process flows. The "SMS Security Essentials" white paper, which is on the SP2 CD, or on the Microsoft Systems Management Web site, gives you detailed information on security, and part of it does cover software distribution. And then there are the public newsgroups for support.

A quick summary, before we hit the Q&A section: software distribution is the most used feature of SMS. SMS 2.0 adds many new and improved features to software distribution. You have a lot of administrative controls on package creation, program creation, chaining programs, automatically uninstalling programs, and if you're not assigned any more, running under an admin context, and so on. There are a lot of new administrative controls that are very powerful.

You have the ability to target computers, users, or user groups as recipients, and SMS will automatically add new recipients to your collections on a scheduled basis, and then send out any advertised programs to those new recipients automatically. Tracing the distribution process can be done through flow charts, like in the res kit. Log files can be enabled at your site server. Status messages are automatically enabled. And you can track the file status, where the files are, and determine if they are resident on the site server, the CAP, or on the distribution point.

With that, I'll turn it back over to Heidi.

Heidi: Excellent, thank you, Wally. It is time to move on to the Q&A portion of this Support WebCast. We only take questions during a live event. And once again, the Q&A portion of the Support WebCast is intended to encourage further discussion of the topic at hand. However, one-on-one product support is outside of the scope of what we are able to cover with the Support WebCasts. If you do need technical assistance, please either submit an incident on the Web, or call in to Microsoft Product Support Services and speak with a support professional.

A couple of additional notes here: November 7, 2000 is our next SMS session. Wally will be back to present "The SMS 2.0 Security Model." Okay, let's jump right into the Q&A. We have had several questions that have already been submitted, the first of which is: Windows Installer, on Windows NT 4.0 — where can I find a download for the Windows Installer?

Wally: http://www.microsoft.com/downloads/release.asp?ReleaseID=17343.

Heidi: The next question is: Did you say that you don't need a package to do a no source-type of advertisement?

Wally: No, you do need to have a package, because SMS only can do advertisements from programs from packages. But what I did say is that you don't need to have source files for a package. So, you can create a package, let's call it Virus Scan, and a program called Virus.exe, and you can create that when you create your package, and you can designate that no source files are required for the package. That way you're assuming that Virus.exe, or whatever the command line is that you're running, is already resident on the client computers. But you have to have a package, and you have to have a program, because that's all you can advertise, is programs from packages. So you have to create those, but the package can have no source files associated with it.

Heidi: Next in line: Can you tell me why you would want to create a directory rather than just using whatever SMS 2.0 creates?

Wally: This would a reference to controlling where SMS puts the distribution files in the distribution point. A number of customers like to control the drive that SMS is going to be using on a distribution point. And by default, if you let SMS control that distribution out to the distribution point, you don't have that control. You can't control which drive SMS picks. For the first package, it might pick Drive D. For the next package you send out, it might pick Drive F. For the third package you send, it might use Drive D again. Or it might go to Drive E.

So, there's no control. It's selecting the drive with the most free disk space. Some customers like to control that. So, giving you that control, on a package-by-package basis, or on a distribution point-by-distribution point basis, gives those customers the flexibility of putting all SMS packages on a single drive, as opposed to working with multiple drives, which SMS might choose.

Heidi: Great. I do want to encourage everybody to take a few moments to let us know what you think about the program. You can use the feedback@microsoft.com alias. Be sure to include "Support WebCasts" in the subject line. We're very interested in your feedback regarding the Support WebCast program overall, if you have any comments about the topic you participated in today, or any suggestions for topics you'd like to see us present in the future. Once again, that's feedback@microsoft.com.

Okay, moving to the next question: With regard to platform dependencies, at what point during an advertisement does the offer check the client platform, and what does it check for? Are there known issues regarding platform checking?

Wally: After the ODPs have checked the CAP and found a look-up file, they read the offer file. SMSAPM32 is a component that's going to do that platform checking. When SMSAPM32 reads the offer file that the ODPs have discovered, it will look at the flags in that offer for the appropriate platform dependencies. That's when it's going to read those platform dependencies, is at the time when APM detects a reads that offer initially. It does it at the initial time.

What does it check for? It checks for the operating systems that have been designated. When you create your program, you designate what platforms it can run on — either all platforms, or specific platforms. It will then check the operating system of the client computer to see if the operating system of the client computer fits within the supported platforms of your client computer.

I have not heard of any problems with that, other than maybe some new operating systems that haven't been updated in our list of supported platforms. There could be some issues with that, because you can't go in there and add your own operating systems. It relies on an update from us. And we did an update in Service Pack 2 for Windows 2000 clients, and so on. So, we have been trying to keep that up to date, and I'm sure Service Pack 3 will include additional ones, if necessary.

Heidi: Thanks, Wally. Next in line: Are there any plans to allow us to run programs multiple times on a client without changing anything, as we were able to with SMS 1.2?

Wally: As I stated, you can always run a program multiple times on a client. You just go to the Advertised Programs Wizard, and all of your advertisements that are available for the user to run will appear in there, and you can run those.

Now, if it's an assignment, not just an advertisement, but it's an assigned advertisement, and you have not allowed the user to run that assignment independently of the advertisement itself, or the assignment, then you can still do that, and we did discuss that in the presentation — creating an additional schedule for your program, or, if necessary, creating a new program. And as I mentioned, we documented that in the release notes for Service Pack 1 and Service Pack 2, how to force an existing assigned advertisement to run again. So yes, there are ways of making it do that, right now.

Heidi: Moving on to the next question: What would cause the SMSCliToknAcct& to be locked out?

Wally: This account can be locked out for different reasons. Most of those are fixed in Service Pack 2. So, if you've upgraded to Service Pack 2 and you're still seeing that, then talk to Product Support Services, because there may be an additional issue that was not solved in Service Pack 2. However, Service Pack 2 did solve the majority of those issues.

The only issue I'm aware of, in a post-Service Pack 2 environment, is with some third-party audio drivers. They will go out across the network to look for .wav files, if I remember correctly, and they hook the SMSCliToknAcct& for some reason. And the SMSCliToknAcct& is going to lock out, in that case, if you have account lockout policies enabled, because the account that you have on your local Windows NT client has a different password than the account that you have on any other client, including your domain controllers in their SAM. So, if you have account lockout policies enabled when this account goes across the wire, then it is going to lock out.

It could also lock out purely through software distribution, if you've told it to run with administrative rights, and your advertised program needs access to another server, other than where the program is running. That's where you need to use the Windows NT Client software installation account. The SMSCliToknAcct& should not be accessing the wire, and if you try to make it do that, and you have lockout enabled, it will lock out. But outside that, contact Product Support, if it's not one of those issues, because it should be fixed if you're running Service Pack 2.

Heidi: The next question looks like it's a little bit difficult to follow, and I'm thinking it might be leaning to support. If I'm running a batch file that kicks off an .exe, and the batch is complete, but the .exe continues to run, then if a client-install account is removed from the local admin, will the .exe install correctly, at that point?

Wally: Most likely no, because what SMS is going to track, generally, is the advertised program itself. And if you're advertising a batch file, and that batch file kicks off some other executable, in this case, and the batch file then closes, SMS is going to be treating the batch file as an advertised program. Say the batch file ran successfully and didn't get any errors back, it will remove either the SMSCliToknAcct& or your Client software installation account from the local admin group.

I honestly don't know if that would be a Windows NT internal thing, whether that program is still going to be running under that context or not, and whether or not it would have the permissions. At that point, it may already have the token created, and if the token has been created, which it probably has been, then it probably still has those rights, and we wouldn't yank them out from under that executable.

So, to be honest with you, I really don't know. That's getting beyond SMS, and that's really getting into Windows NT internals, as to whether or not the executable will still keep the token that it had initially assigned. As far as SMS is concerned, in that case, you'd want to put a delay in your batch file until your executable was completed, and then close your batch file. That would be the way to work around it in SMS.

Heidi: Moving right along, the subject of the next question is distribution point as server versus share. What would be the advantage to setting the distribution point as server versus share? It seems that it would be better to choose share so you have consistency. Is it possible to change the state of the distribution point later, from server to share or vice versa, if the drive fills up, or would you from that point forward have to specify the location for each package?

Wally: Okay, the first question we already answered. The advantage of making it a share versus a server is that if you make it a share, you can control the drive that SMS uses. If you make it a server, unless you want to control on a package-by-package basis, SMS will automatically find the drive with the most free disk space. Now, if you only have one drive on your distribution point that's NTFS, then it's basically a moot point, because you only have one drive to choose from, so SMS will always use that same drive anyway.

The other advantage to creating a share is that you might want to have the share name available for other users to access. And telling users to access some share name by the name of SmspkgC$ may not necessarily be as easy for them, or they may not know how to do that, outside of a browser, and if the $ makes that share hidden, they wouldn't be able to see it. So, that would be the advantage of creating a share.

It's not possible to move that site system from a share to a server, or from a server to a share, without removing the role and re-adding the role. So, you can remove the role and re-add the role. Now if you just remove the role, I don't believe SMS will go out there and move the packages from the role. I have not tried doing it that way, so I'd have to try that, but I don't think we're going to remove the packages. So, the packages would all still remain there, on whatever drive you had. Now, when you go back and assign the new distribution point, and assign the package to that distribution point again, then it's going to be redoing everything all over from scratch.

So, realistically, if you're going to try to move that from one mode to another mode, it's going to be a recreation of all those packages, and will be distributing them back down to the distribution point again anyway over the wire, so you're not really going to gain anything. So, there isn't a way of officially moving between one and the other, right now.

Heidi: The next question is: What if a package arrives but does not install? Our logs indicate it does not decompress, but no error is generated. This only happens in some destinations.

Wally: What I would look for is, again, the decompression portion is going to be in the Distmgr.log. So you look at the Distmgr.log, and if it says it didn't decompress, it will normally give some sort of a Win32^® error. So it'll say Win32 =, and it might say 5; and Win32 = 5 is access denied. In other words, your SMS service account is not an admin on the distribution point. Or maybe it might say error = 2, which is file not found, or some other error indicating out of disk space. Those would be the most common reasons why it wouldn't decompress on a distribution point, is it's out of disk space or out of admin rights, or it couldn't find an NTFS drive.

Now, if you mean the package got down to a child site, but it didn't decompress, then you may not have assigned any distribution points at that child site for that package. And if not, then it's not going to decompress that package. You shouldn't have even received that package file, the compressed package, unless you had a distribution point assigned. So, that would be something else. But that's what I'd look for.

Heidi: Next in line: Does the SMS documentation have a listing of all message numbers, and where, when, and how they are used?

Wally: I was going to say yes, until you said "all." I don't think you're going to find any piece of documentation anywhere in the world that lists every single thing that's available. However, the vast majority of your status messages will be documented in the Systems Management Server 2.0 Resource Guide. I believe Chapter 26 of the SMS 2.0 Resource Guide is your guide to status messages. And they group them by function, like distribution messages, or Distribution Manager messages, and they'll list all the different status messages, the number, and what the message contents are, in that guide. So, that would be the place you'd go to, the SMS 2.0 Resource Guide, and I believe it's Chapter 25.

Heidi: Okay, terrific. The next question is: Could you tell us a bit more about Windows Installer and SMS Installer? Things like which installer you should use on what client operating system, etc.

Wally: Windows Installer and SMS Installer are both installation technologies. They allow you to script an installation, basically, for a client computer, so that all clients would install that application exactly the same way. As you know, most programs today kick off Setup.exe, and they rely on the user to be there to answer some prompts. These installation technologies (Windows Installer and SMS Installer) allow you to force the install without having any user interaction.

Windows Installer is the Microsoft-recommended method of doing installations. It's built into Windows 2000, and it can be installed separately on Windows 9x platforms — Windows 95, Windows 98, Windows^® Millennium Edition, as well as Windows NT 4.0, as in the first question we had. So, you can download that and install it on your local platforms, and then use Windows Installer as your installation technology. You create an MSI package, then you can distribute that with SMS.

SMS Installer just happened to be something that's built into SMS. It comes with the SMS CD. It can be installed automatically. You just build your packages inside the SMS Installer. But it's not a Windows Installer technology, where you put the icon on the desktop, and if it's not installed, you launch from the icon, and then the application automatically installs. Or, if a file is corrupted or is missing, it can automatically repair that. SMS Installer won't do that. But it is a built-in process, as opposed to having to have Windows 2000.

Again, you can run Windows Installer on lower-end platforms, down to Windows 95. SMS Installer can get all the way down to 16-bit Windows versions and run there. And you'll still have it, regardless whether or not you have any other installation technology, because you have it as part of SMS. Which one you use is going to depend on your own comfort level. If you've already used SMS Installer, and you have an investment in it, and you have packages already created, that's fine. The recommendation for future modes of distribution and installation is the Windows Installer.

Heidi: Okay, I'm also thinking this customer might benefit from looking at the archives from the last session that you did. I think it was "Windows Management Instrumentation: What Is It and How Does SMS Use It." That is available from http://support.microsoft.com/servicedesks/webcasts/wc092600/wcblurb092600.asp. The session was broadcast a couple weeks ago, on September 26, 2000, and the PowerPoint^® slides and the on-demand streaming media are already there. I'm not sure if the transcript is there quite yet, but if not, it will be there fairly soon.

Next in line is: When you advertise a program to a user group, why does the advertisement reporting show PCs where the program was installed on, and not which user IDs?

Wally: I'd have to talk to a developer and find out the exact reason. My guess would be because that's how you track things in advertisements. You want to know which computers have things installed. Normally you have a user assigned to a single computer. So, when you see that the computer Wally installed this package, you know that Wally installed it. Whereas if you have a user that's floating around to all the different computers, and every time they log on, this program gets installed, you don't want to see that Wally installed the program 10 times. You want to see that this program was installed 10 times, and these are the 10 different computers that it was installed on.

So, I'm sure it's just a tracking issue, and what they felt was better, as far as tracking, and what people want to know, because you can go to multiple, different computers as the same user, and because you just don't want to see that same user did it 10 times. You want to see that 10 different computers installed that program, so the program is installed there.

AdvertView might give you that additional data by tracking by user groups. It may be a way of doing your advertisement status and looking at user group, and who ran it, because you can go by collections there. You can go to the user collection and say which collections, and what messages are available for the collection, as far as advertisements. So, that might be better for you, in your case, if that's what you want.

Heidi: The next question is: What is the expected time frame for any given SMS package to be delivered to a workstation, user, or user group; something like 15 minutes, 1 hour, 8 hours, etc.?

Wally: There are too many variables there to give you an answer. The biggest variable is going to be how big the package is, the source files, that you're generating. Let's say something like Windows 2000 or Office 2000 — that's 500+ megabytes. That advertisement's not going to be available to the user until that program itself, the package, has been placed in the distribution points. That may take a long time, if you happen to be distributing to a distribution point over a wide-area link. So, that can delay it. The smaller the programs are, as far as the source files, the quicker those files are staged.

Then, when you create your advertisements, and when you target them, you can schedule a specific starting time for your advertisement. You can state that this advertisement, even though I'm creating it today at noon, is not available until tomorrow at 3 P.M. Well obviously, that's going to delay when the advertised program is available on your client. Then you have to look at, when are your client ODPs waking up to look for advertised programs? So, the default is hourly, but you can set that all the way up to every 24 hours, or 1,440 minutes.

There are just so many different factors, there is no one answer I can tell you. What I can tell you is, if you just distribute something that's fairly small, like under 100 megabytes, and you go to your client and you force the lookup of those ODPs, you could actually see that advertised program on your client computer within a matter of minutes, and possibly under that 15 minutes you were talking about.

When I do demonstrations at Tech Eds or other events, I'll demonstrate with some small product, like HealthMon Agent, which might be 450 KB or something like that, and I'll have that down to my client computer in a matter of two or three minutes. It really depends on what your timing is set to; how big your package is; where your distribution points are; how frequently is your collection updated to force the membership updates, and so on. There are a lot of different variables there, so I can't give you a one single answer or one formula that will work.

Heidi: Next in line: Is it possible to make sure that a new client in a site will receive the mandatory packages in a certain order?

Wally: Unfortunately, no. SMS makes no guarantee which order advertised programs are run under. Whatever the client happens to receive, and what order it receives them or detects them, that's probably the order it's going to run under. The only way you could guarantee that is if you did program chaining, where you said the last program you want to be installed is the one you advertise, and then each one would successfully chain the prerequisite program.

So, if you did program chaining, you could obviously control that. But outside that, no. There's no way of controlling the order, other than just modifying the advertisements, the order in which they need to be, and so on. But if you already have those set up, and it's a new computer being added to the network, or new user, then there's not going to be any control over that at all.

Heidi: Terrific. Are there any plans on giving SMS the ability to broadcast notification of advertisements to all clients, so that the server does not have to wait on the client to poll?

Wally: Well, that's getting into the futures, and I'm not allowed to talk too much about the futures, but that has been under discussion, as to whether to do a push of the advertisement notifications, or to let the clients continue to poll. All I can tell you is that's something that has been looked at, and probably will continue to be looked at.

Heidi: Is it now possible with SP2 to delete expired advertisements without fear of SMS reusing identifiers?

Wally: I've not heard of any problem with this, so as far as I know, it's safe to do so. I've not heard any problem with that prior to Service Pack 2, either. The only time I'd ever heard of a problem with that is when people did a site recovery at a site hierarchy, and they didn't reset or set all the appropriate transaction IDs. I've seen that problem, but not just by deleting an advertisement on its own, and then re-creating one and using an old advertisement ID. I've not seen that at all. To me like that sounds like your SQL database got messed up, as far as what the next Offer ID is. Because that's what gets updated, and that's what SMS polls from.

Heidi: So it sounds like they should calling Product Support for assistance.

Wally: Yes, if you are experiencing that, then I would contact PSS and explain that to them. It sounds like something in the SQL database is not being updated properly, because there's a table that keeps track of the next IDs we use for all those things, and one of those is Offer ID.

Heidi: How do you get a list of collection members who have not received an advertisement? For example, they have no status messages.

Wally: Good question. That really is something outside the current SMS Administrator Console. Yes, the current SMS Administrator Console doesn't have the built-in ability of giving the exception list: "Who was supposed to receive this, but didn't?" You could create a query, and your query criteria would be something on the line of status message of 10008 or 10002, whatever you're looking for — either the receiving or the running of the program, for the specific advertisements you want, and then turn that into a not query. So, you can do that yourself manually, but nothing is built into the SMS Administrator Console, at this time. It's something we know we need to do.

I believe AdvertView can do that for you, though. I believe AdvertView can show you everybody who has not received the advertisement, or who has not run the advertisement successfully. But within the admin console, it's not there. You would have to work with queries to get it created, though.

Heidi: Can you repeat for me where the AdvertView tool is located?

Wally: The AdvertView tool is in the Support.exe bundle that is part of your SMS 2.0 CD. If you go to your SMS 2.0 CD, go to the Support directory, and there is a bundle of files that's 13 megabytes in size, called Support.exe. If you run Support.exe and expand that out, in other words, install the Support Tools on your site server, or admin console, or wherever you're installing it, then by default that installs in Program Files\SMS 2.0\Support Tools\Bini386\Software Distribution Tools. If you go there, you'll find AdvertView.

Heidi: What features does SMS 2.0 have that support Citrix MetaFrame or Windows 2000 NT Terminal Services?

Wally: I can't comment on Citrix at all. And software distribution is not one of the things we support for our Windows NT Terminal Server. Thinking about Windows NT Terminal Server support, I don't think we have anything. So for Windows NT Terminal Server, I don't think we support anything for an SMS client or SMS server.

For Windows 2000, up on the Systems Management Web site, which is http://www.microsoft.com/smsmgmt/, there's a white paper about Windows 2000 compatibility with SMS 2.0. Up on that Web site, we do talk about all the different compatibility features of Windows 2000 and SMS 2.0. We also did a WebCast in May (http://support.microsoft.com/servicedesks/webcasts/wc050900/wcblurb050900.asp ) on that same topic, and I covered it there.

For Windows 2000, for a Terminal Server client, we do support hardware/software inventory, as well as software distribution in the background. In other words, advertising programs to the computer, not a logged on user, that runs in the system context, and does not require any user intervention. We do support that much for Terminal Server on Windows 2000; but for Windows NT 4.0 Terminal Server, I don't believe we have anything. You can look at that white paper. It'll give you the full details, but that's basically it. Very little software distribution will work.

Heidi: For 500 nodes, will there be any performance decrease or increase if the SQL services are on the separate server? All SMS services would be located on a different server.

Wally: We're taking advantage of asking non-software distribution-related questions here. That's fine. For 500 users, it's not really a big deal. It doesn't matter how many users, really. It's more what type of link do you have between your site server and your targeted SQL server. What Microsoft recommends is, if your site server has enough horsepower — CPU, RAM, processor , enough disk space, and so on — to put the SQL server and SMS site server on the same physical box, you'll get the absolute best performance if you can do that, again, provided that your site server has enough horsepower to handle both of them.

If not, and you do want to separate the two, then you need to make sure you have a very, very fast link between the site server and the SQL server, because there's a ton of data that SMS will push and pull from the site server to the SQL server, and from the SQL server to the site server.

So, it's not necessarily the number of clients. Yes, the more clients you have, the more inventory you have, the more discovery records you have, and so on. But we're always going to recommend that it's better for you to put more resources, more money, into the site server hardware itself, and put it on the same box, as opposed to having two different boxes.

Heidi: During SMS install, how can we force CAPs and DPs to install to shares or drives we want instead of the default that SMS chooses?

Wally: If you mean SMS, then what you would do is go to the appropriate computer that you want to use for an SMS CAP or distribution point, and create a share name that you want SMS to use on an NTFS drive. Then, inside the SMS Administrator Console, you go to the site code, Site Settings, and Site Systems. Then you do an Action, New, and then you say Windows NT Share. So you'd add a new Windows NT share, and give it the role of a CAP or distribution point, and when you create that share, you give it the syntax of \\Server\Sharename. And then SMS will pick up the share name that you designated and put the appropriate files out there.

Heidi: The next question is: How do you set available bandwidth during a deployment? I have all WAN links, and would like to have more control over the link usage.

Wally: Well, it depends on if these links are intrasite or intersite. If it's a distribution point over a WAN link that's part of a single SMS site, you have no control over it. That's why we always tell you, in SMS environments, to never have site systems or clients separated from the site systems over a WAN link. You always need to be working with local LANs.

If it's intersite — in other words, two separate SMS sites that you want to transmit data between — then when you create your address to that child site, you select the Rate Limits tab. The Rate Limits tab allows you to designate what your bandwidth throttling is, and the Schedule tab allows you to set the schedule for your links. But again, for intrasite — in other words, this server over WAN link as part of an existing SMS site — you have no rate limits or ability to bandwidth throttle that at all. It's only intersite.

Heidi: Is there any way to determine if the client cancels the advertisement, or does an install later date change?

Wally: That would be solely dependent on the program that's being run, and what it's return codes are. SMS does not dictate those return codes. Those are controlled by your advertised program itself. So if your advertised program, the program that's being launched, can tell whether or not the failure was because of a user canceling, or running out of disk space, or lack of permissions, or whatever, then SMS can report that for you. However, SMS doesn't control what those exit codes are. So, it's purely dependent on the program that's being advertised, and what its return codes are.

Heidi: Regarding advertisement status, under the Program Errors column, will SMS attempt to resend the package to the users that fall under this column?

Wally: Generally, no. There are a couple of cases where it's an operating system-type of issue, where there are things that we will retry automatically. So, if it's sent to the computer, and there are certain conditions, then we will retry certain advertisements. But as a general rule, if you advertise a program to a client and the program fails, no. Generally, we do not force that to run again.

Heidi: We have secondary sites at certain locations. We have two CAPs at each of these locations, one on the BDC, and one on the SMS server. Should there only be one CAP at each secondary site location to minimize package distribution confusion and client confusion?

Wally: No. Unless you have a very small number of clients, we'd never recommend having a single CAP, because then you have a single point of failure. And because the CAP is still very important for client interaction, as far as looking for advertisements, and reporting inventory, and discovery data, and status, and so on, you may want to have a couple available. That would be the recommendation. The files that software distribution places on a CAP are very, very small in size. As far as reducing confusion or limiting the flow, that's really a distribution point, because that's where you have the package files, the 500 megabytes for Windows 2000 or Office 2000. But no, generally we'd recommend having multiple CAPs in a site.

Heidi: When is SMS going to become cluster-server aware?

Wally: I can't tell you today, because we haven't announced anything, but stay tuned to the System Management Server Web site, and you'll see an announcement in the future as to when we'll be cluster aware, and what the limitations on that cluster support will be.

Heidi: I have seen a few comments and suggestions for topics that have been submitted, and I want to thank all of you who have done that for us. It definitely helps, and we are very appreciative of those comments. The next question: We're seeing old .ins and .ofr files on our CAPs for advertisements that have been deleted. What is the mechanism that updates or deletes these files, and can I force this to occur by stopping and starting some service?

Wally: Well, everything on a CAP is pushed down to the CAP from the site server by Inbox Manager. So it's Inbox Manager that does that processing. However, Inbox Manager just pushes down what is on the site server. So, if you have old files left over on your CAPs, if it's a single CAP and not the others, then it may be some sort of a permission issue or connectivity issue. If it's all your CAPs, then it's most likely that those files are just left over on the site server.

So, if you wanted to get rid of those, you could certainly go out to the site server, Offerinf.box on the site server, and blow away whatever files you don't want, and then SMS will replicate that down to the client access point. So, it'll remove files that are no longer applicable for the site. And generally, SMS will recreate any files that it needs to have.

Just as a general rule, you don't delete files off a site server, so you need to be very careful with what files you're deleting. I'd suggest that you contact PSS and verify what your problem is, and see if their solution is just go to the site server and manually delete those files. We normally do a fairly decent job of cleaning up, but in some cases we don't.

Heidi: Can a collection be created that uses user group and hardware criteria, together? Can there be a join there?

Wally: A collection can probably be created to do that. However, you cannot target software distribution based on users or user group membership and specific computers. We know that's one of the needed areas in our current implementation, and we are working to address that in a future release. So, if the goal is to do software distribution based on this user at this computer, then no. There is no ability to do that directly within SMS.

Heidi: What is the expected release date for SP3?

Wally: SP3 has not been announced yet, but our goal was every six months. And since SP2 came out in June, you can expect one by the end of the year, if everything goes well.

Heidi: Why, when a package is made available with a later mandatory date/time, why can't the user see the advertisement until the mandatory date/time mandatory 5-minute countdown? Does that question make sense?

Wally: That's something you can set. When you create an advertisement, you have that option. If it's an assigned advertisement, if you create an assignment on the Schedule tab for that advertisement, there's a check box there that says, Allow user to run the program independently of assignments. Selecting that check box lets the user go to Advertised Programs Wizard and run that advertised program any time you want them to.

But if you just create an advertisement, you assign it for a specific point in time, unless you select that check box, Allow users to run the program independently of assignments — they cannot see it prior to whatever the countdown is.

Heidi: I tried to create a package for distribution of McAfee antivirus, but my distribution failed. Do you have any experience with the distributing this software? And if so, any do you have any hints or tricks?

Wally: I have no personal experience with McAfee and their antivirus software. I do know people do distribute it with SMS, so I know it can be done. But as far as any hints or tips or anything like that, I cannot offer any at all. You'd have to look at your log files and see why it failed, and then go from there. But no, I have no experience with McAfee and distributing it through SMS, personally.

Heidi: Our advertisements are not assigned, so they can be run by the user immediately, or scheduled for a more convenient time. However, if the user just closes the wizard, not running the program or scheduling it, the user is never reminded that there is a package waiting to be run. Is there a way to remind the user? In SMS 1.2, PCM popped up at every log on if a package was still pending.

Wally: Well, there's always a way. You can script anything you want to, but you would have to write your own script or utility. Once your client has used the Advertised Programs Wizard and they've seen the advertisement, then we don't bother notifying them about that advertisement again, because we know the user has seen it, because it has been marked.

So to do that, you could go blow away a couple of files in the client. If you deleted a couple files in the client, then that would make it an unseen advertisement again; but normally, we don't recommend that. So, no. Directly within the console, there's nothing. You'd have to write your own utility to do that, or hack some files, but there's nothing built in, within the code.

Heidi: Why would some clients within the same collection receive advertisements several days later, while others received them at the mandatory or scheduled time?

Wally: Again, that would be the client code itself. So, you'd be looking at when do the client ODPs wake up? Are there any connectivity issues, so that the client is not able to connect up to a CAP where it finds its advertisements? Maybe those advertisements have not been replicated after the CAP, because there was a connectivity or a security issue pushing the data down, from the site server down to the CAP. Or maybe the client code had security issues talking to the CAP. Maybe one of the client processes died, and it required a reboot of the computer, or something else by the user, to get that client process starting again.

There are a lot of different things, but there's nothing that you would normally expect to have happen, though. Normally, if all your clients are configured the same way, maybe one of the users changed their local polling cycle to daily, as opposed to hourly, which everybody else had, because users can change that if you allow them to. There are a lot of different issues that could appear. You'd have to look and see what the configuration is, and why they're different, and what their log files say, as to why one sees it and why one doesn't see it.

Heidi: As discussed during this past presentation, there will be tools and FAQ information made available on the Microsoft Web site. Do you know when we can expect this information and tools released?

Wally: I assume you're referring to the backup and recovery stuff. The code is all done. The Web site is all done. It's just waiting for the final sign-off and editing pass by the Legal and User Ed people. Once the developers and program managers do their work, it has to go to editors and other people to make sure the content is clean enough to put on a Web site, and that the legal issues are handled, so that nobody has any problems. And that's where we're at now. They expect to have it posted fairly soon, but I know you've heard me say that before. I apologize. I'm not in control of that. But I talked to them last week, and they were very close to having all the legal and editing issues resolved. So it should happen fairly soon.

Heidi: If you use the start /w wait to run the .exe in the batch file mentioned earlier, the batch would exit only when the .exe had finished. Is this correct?

Wally: Sounds right. I'm not a expert on batch files, but if the start /w for wait does that, then you'd do start with executable, and then a /w switch. If that waits until whatever program you've launched returns, before the batch file completes, then yes. That would be a way to get around the earlier scenario, where the batch file kicked off an executable and maybe lost context of the program. Yes, that sounds like it would work.

Heidi: Why does a package sometimes force the processor to go to 100 percent, and the package does not finish?

Wally: This sounds like the client code, because I've never seen the server code go to 100 percent utilization, whereas client code sometimes does. There were a couple of issues with releases prior to Service Pack 2, where some of the client components, and the way they're designed, and some of the interaction with other client components, SMSAPM32.exe, pegged the processor at 100 percent.

If you're still seeing that with Service Pack 2, you should contact Product Support. Other things like hardware/software, inventory, whatever — they're very hard disk intense, or very CPU intense, so you may see that for other things. But for software distribution, to my knowledge, that was supposed to be fixed with Service Pack 2, or the Client QFE bundle for Service Pack 1.

Heidi: When advertising a package to clients, how many clients will pick up the package from the DP at once? For example, 1,000 clients? Would they all hit the DP at once? Also, when sending packages to DPs, if we have 60 DPs, will it send to them all at once, or use throttling?

Wally: For the first question, that entirely depends. As soon as the client ODPs wake up, go to the CAP, and find the advertised program, if it's an assignment, and it's assigned for right now, or it's past the assigned time, then each of those computers will go find a distribution point in the NAL file and kick off the installation. So, that totally depends on when the client was last rebooted, to know what the hourly cycle is, or if they changed that hourly cycle, the polling intervals for the ODPs. So that will control when.

As far as how many can, that's a Windows NT networking issue, and you'd have to figure out what your network can support, as well as whether your distribution point — the physical Windows NT server — could support 1,000 users or not. SMS is not going to care. SMS is not going to do any throttling of that. It's when the ODPs detect the advertisement. If it's supposed to be run now, they'll kick off, and go to that. By default, they randomly sweep the distribution point. So if you have 1,000 users, and you had 10 distribution points, you wouldn't expect to see all 1,000 people hitting one distribution point. You'd expect that to be randomized at process distribution points.

As far as the second one, when you're sending packages to distribution points and you have 60 of them, there is no throttling, because again, you don't do any throttling with any site. However, Distribution Manager does, I believe, do that serially. It will hit one distribution point, and then go to the next distribution point, and so on. I believe that's the way it operates, unless something was changed in Service Pack 2. I can verify that, but I think it does it serially, as opposed to simultaneously.

Heidi: The directory Smspkg exists on SMS primarily in secondary sites that are not distribution points. They take up space, just as if they were a distribution point. Is there any way to not duplicate or keep these files from residing on non-distribution points?

Wally: Well, the Smspkg folder itself, that's for compressed packages. That will be on your site server for every parent site and child site where you do distribution between those two sites. That's your compressed file. When you look in there, you shouldn't see your normal source files, like all of your Office 2000 files, or HealthMon Agent, or whatever else you might be distributing. What you'd be seeing there would be .pck files or .pkg files that are actual package files that are compressed. So, a single file per package, that's what you're seeing. That does have to remain on the site server for each site.

You can delete the package from the admin console, or you can manually delete that compressed version, and then force SMS to send it again later on, if it's not there and it needs it. But that's what those are. Not necessarily distribution files.

Heidi: Next is a tip from a customer. Don't forget to mention that the Installer Step-up Utility, the ISU, will provide the Windows Installer technology for SMS Installer.

Wally: Well, the Installer Step-up Utility is the utility that can take SMS Installer packages and convert them to MSI packages. It hasn't been released as an official product yet. It's still in one of the beta phases. But yes, if you have an existing investment in SMS Installer packages and you want to move to Windows Installer, that's the Microsoft recommendation. You can get the Installer Step-up Utility and migrate your existing installer packages over to Windows Installer. In some future release, SMS Installer will write native MSI packages.

Heidi: Why can't you drag clients into collections?

Wally: Why can't you do that? Because the user interface was not written to allow that. That's purely it. There's no technical limitation, and MMC does allow drag and drop. It's just that it's a very hard thing to instrument successfully, and it was deemed that it wasn't worth the development time to try and get the drag and drop functionality to work properly. So, whereas in SMS 1.2 you could drag a computer into a machine group, you cannot do that in SMS 2.0, unfortunately.

Heidi: And the last question we're going to answer today is: One of the offices in which we have an SMS 2.0 SP2 primary child site recently turned on a third-party security package on the Windows NT server. It's been brought to my attention that this utility is claiming that the SMSCliToknAcct& is failing on logon in a Windows NT file server, which is an SMS 2.0 client. Do you know if this is normal?

Wally: Well, your SMSCliToknAcct& on every single Windows NT client computer is going to be used for many different processes. A lot of different processes on the client are going to use the SMSCliToknAcct&. That account should be able to log on locally, because the SMS client service is going to spawn off some other process, and it's going to use the SMSCliToknAcct& to do that. That account should be able to log on locally.

Now, logging on remotely? No, it should not be able to log on remotely to anything other than your local computer, because of the fact that the password for that account is unique on each individual Windows NT client computer, or server computer that's an SMS client.

So, if it's a local error, then that would not be normal. The SMSCliToknAcct& should be able to log on locally and do its work. And if you're seeing that locally, then I'm guessing that a lot of your SMS client processes are not working properly, because most of them use the SMSCliToknAcct& as the account they run under. If it's remote, then that is to be expected, and it should not be going across the wire anyway, to do any validation.

Heidi: Okay, thanks, Wally. With that question answered, we've cleared the queue of all the questions that were submitted he questions that were submitted. I do want to thank all of you for joining us today. I hope you found this content useful. Again, if you have just a few moments and can send us some feedback, we sincerely appreciate your comments. You can use the feedback@microsoft.com alias. If you do use that alias, be sure to include "Support WebCasts" in the subject line.

We hope that you did find this content valuable and have an opportunity to join us again in the near future. Thanks so much for attending today, and have a great afternoon. Good-bye.