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

Microsoft Systems Management Server 2003: Troubleshooting Advanced Clients

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

Wally Mead: We've been talking about Microsoft® SMS 2003 for a little over a year now and really concentrating on it all this year. We've talked about one of the big improvements in SMS 2003 in a number of those sessions, and that being the SMS 2003 Advanced Client.

While what we've called the new client platform may have changed from the new client, the Remote Client, the Mobile Client, and now the Advanced Client, as well as some of its features may have changed, initially we weren't sure whether we were going to have remote control or software metering. We've never really talked about troubleshooting the Advanced Client. This process, the process of troubleshooting the Advanced Client, is quite a bit different than that of the SMS 2.0 client or the SMS 2003 standard client, which is based on the 2.0 client platform.

This presentation will discuss the Advanced Client and how to troubleshoot it (slide 2). What we'll start off with is a review of the Advanced Client. Just to make sure that you're all on the same page and you all have a common understanding of what the Advanced Client is, we'll spend a little bit of time going through a review of what the client is. We'll talk about what the Advanced Client looks like and what the requirements of the Advanced Client are as far as the client itself, as well as site systems that are required to support the Advanced Client. Then we'll go through the installation of the Advanced Client, different ways of going through the installation.

Those three topics — the review, the requirements, and the installation — are things we've talked about before, but I feel it's very important for us to go through that information again. I'll try to go through it quickly so we have more time on the troubleshooting end. What I've seen in monitoring the beta forums and talking with Early Adopters and so on, is that a lot of the common problems people have had, their initial problems with the Advanced Client have oftentimes been either misunderstanding the way the client functions or misunderstanding the client itself or not properly having the requirements in place to support the Advanced Client platform. Therefore, we'll spend some time discussing those. In that discussion on the review, the requirements, and the installation, I'll talk about some of the common issues or pitfalls that people have run into during the beta program.

Then we'll change the focus of the presentation into troubleshooting the Advanced Client. What are the most common problems that have been experienced in the beta? The beta has been going on for a few months now. What are the common problems that people have been running into with the Advanced Client?

Then we'll look at how you troubleshoot installation, configuration, communications, and software distribution. We'll look at some of the common issues for each of these different types of areas, as well as what log files you should be viewing to help you analyze and troubleshoot your configuration, installation, communications, and software distribution.

Then we'll look at troubleshooting tools. What are some of the new tools that are available for you specifically in the area of the Advanced Client and its troubleshooting, as well as looking at a couple of old tools that are available that can help you out with your SMS 2003 environment. Then last will be a Q&A session.

Let's start off and spend a few minutes on reviewing exactly what the SMS 2003 Advanced Client is before we talk about troubleshooting the client (slide 3). Let's go through the review of the client quickly.

The SMS 2003 Advanced Client is new client code specifically designed for mobile users. It was originally created for roaming users; in other words, users that would take their computer and move from one location to another location, possibly moving between SMS sites.

As you know from working with SMS 2.0, SMS 2.0 doesn't handle that scenario very well at all. In certain scenarios it can actually go through a deinstallation of the SMS client process, followed by, sometimes, an immediate reinstallation of the process, from the way the internal code is architected, with one process looking at, "Are you still assigned to the site? No. Okay. I need to deinstall you." Then another process looking at, "Are you assigned to any new sites? Yes. You are. Oops! You're not installed now. Let me go ahead and install you as a client."

That caused problems for people because it caused inventory to be resent, full inventory sequences as opposed to delta inventory cycles. You also lost history of your advertisements that you'd run before and network traffic associated with the reinstallation of your code.

This code is designed specifically for those people who do move around. It's also designed in mind of slow, inconsistent, or short connections to the SMS site. It assumes that you don't have a continuous high-speed connection to the SMS environment, like SMS 2.0 does. SMS 2.0 assumes that there is a high-speed continuous connection from the client to its CAP or distribution point, whatever's necessary, as well as between the site server and its site systems.

Even though this client platform is designed for roaming users and laptop computers, per se, it's great for desktops too. We do recommend that you use the Advanced Client in all situations where it is possible. In other words, use it on all of your platforms, as long as they're Windows® 2000, Windows XP, or above. You'll get great benefits, not just for your laptop computers and roaming scenarios, but also for your desktops as well.

The client is not bound to the site through IP subnet boundaries or Active Directory® sites. Unlike the SMS 2.0 client or the SMS 2003 standard client, which do rely on and require that the client is within your site boundaries, the Advanced Client can manually be assigned to a site, regardless of whether or not it physically falls within the boundaries for that site. We'll talk about that a little bit later on when we talk about boundaries and roaming.

You can run an automated discovery process if you want to, which is based on site boundaries. If you're not sure what site to assign your client to, there is a process you can run which is called automatic discovery or you can have the client go through and figure out, on its own, what site it belongs to. There are a couple of different ways that it works and what it uses for its assignment. We'll talk about that later on in the presentation. You can manually assign the client to whatever site you want it to be assigned to during installation or post-installation. Again, we'll show you how to do that a little bit later on.

One thing that has caught people a number of times in this scenario in running the beta product is that you cannot assign Advanced Clients to secondary sites. Advanced Clients can only be assigned to primary sites. They can physically reside at a secondary site location, but for the assignment process they must be assigned to a primary site. That has bitten people a number of times in the beta, so you want to be aware of that. We'll talk about that again later on and we'll get into more details.

All SMS client agents are fully supported. Initially we weren't sure if we were going to provide support for remote control or software metering on the Advanced Clients. However, your feedback that was given to us told us that we needed to have feature parity between these two client platforms, so we've done our best to provide feature parity. In essence, anything you can do on the standard client or the SMS 2.0 client, you can also perform those same functions on the Advanced Client. The Advanced Client still has benefits beyond that.

What about Advanced Client communications with the SMS site (slide 4)? The primary controlling aspect of the communication process, which I'll show you a little diagram of later on, is HTTP. The vast majority of the communications between the Advanced Client and its site systems, primarily the management point, are over HTTP.

We also use BITS to give us very good management of network connectivity. BITS is Background Intelligent Transfer Service. It's part of the operating system. It's not SMS code. What it does is it allows us bandwidth sensitivity. In other words, if the Advanced Client is performing some sort of function that requires network access and the user decides to launch some program that requires access of the network, Internet Explorer or Outlook or some other application that requires network access, BITS will back off, allow the other user application, the foreground application, to take priority, utilize the wire, and then BITS will monitor the wire for idle times. When it finds an idle period, it will start its communication process again.

It has byte-level checkpoint restarts. If we are transferring a file from the client up to the management point or from the management point down to the client, and the user launches off Internet Explorer, BITS will back off. It will remember where it left off and pick up the transfer of that file where it left off when it can resume, even if that happens to be over another connection period later on, maybe even days or weeks later on.

It also has a download-and-execute model for software distribution. Instead of requiring the user at the Advanced Client to run the program directly off the distribution point, which happens for SMS 2.0 clients, we allow the client to download that program into a local cache on the hard drive, which may take, again, multiple connection periods using BITS. Then once the program has been fully downloaded, you can disconnect from the network and run that program from the local cache and have that program run or install, whatever is necessary.

Now BITS is used for downloads of policies so whenever you download policies you use BITS. You can use it for content downloads, in other words, advertised programs or the packages, and that depends on the scenario you're in with your distribution points, which we'll talk about later on, as well as for data uploads. So whenever the Advanced Client has generated data and has to push it up to its management point, it uses BITS to do so.

Again, the communications to the SMS site systems, primarily the management point, analogous to a CAP, which we'll talk about, uses HTTP and oftentimes BITS. For local distribution point access we prefer SMBs to BITS. We'll talk about that a little bit later on as well.

The primary transfer method or file format is through XML. When we download policies from the management point, we do so through XML. When we transfer data, inventory data, discovery data, software metering usage data, and so on, it's in XML format, and that data is sent back up to the management point. One of the nice features there is that with XML we get automatic data compression or we're doing data compression of our data files. Therefore, the impact on the network is greatly reduced with the XML files and our automatic compression that we go through.

One fairly common problem beta testers have had with installation of the Advanced Client has been not meeting the prerequisites for an Advanced Client install. Let's spend a couple of minutes talking about what the requirements are of the SMS 2003 Advanced Client (slide 5).

First off, this client only works on Windows 2000 and Windows XP or later .NET Server–type platforms. If your platform is still running Windows 98 or Windows NT® 4.0, you have to run the standard client. There's not a problem with you intermixing the Advanced Client and the standard client in the same site. That's totally supported, and we've told you before that one of the neat things is you don't have to administer your Advanced Clients differently than you administer your standards clients, but we do only support the Advanced Client on Windows 2000 and XP and above.

One of the bigger "gotchas" we've encountered with our beta testers has been the requirement for Message Queuing, MSMQ. A number of people have had issues with installing the client or installing the management point. The vast majority of the times that I've seen, it's been because MSMQ has not been preinstalled or during the installation we're trying to install MSMQ automatically, but we can't find the Windows source files so we can't install the Microsoft Message Queuing process.

Just as a reference when you're running the beta product, it's highly recommended that you go through a manual installation of MSMQ on both your management point as well as your Advanced Client. Go through the installation of MSMQ, and then go through the SMS installation, either the SMS installation of the Advanced Client or the installation of the management point, and things will look a lot better for you and work a lot better for you.

One of the neat things is we are removing the MSMQ requirement post-beta. Therefore, the MSMQ is only required for the beta code. After that when you guys get your next drop of code from us and certainly by RTM, MSMQ will no longer be a requirement. That will be one pitfall that people have run into that we're removing for you.

Another area that's hit a few people is that BITS, in the beta version, requires a restart. What that means is if your client doesn't already have BITS installed, which it's not installed by default in the OS, if it's not installed already in Windows 2000 and we require it to be installed and we push the install out, BITS does not become active until you do a system restart. Again, BITS is required for downloading policies, so your client, in essence, is not fully functional until you've done a system restart. That, again, is only a beta issue. After beta, one of our developers has written a wrapper program around the BITS install that allows it to start and become functional without requiring a system reboot. That will be in the release of the product as well.

Those are two of the big things that people have been bitten by in the beta time frame with the Advanced Client: the MSMQ requirement, as well as BITS requiring a restart. We're taking care of both of those after beta, so it will just be an issue for you during the beta; post-beta it won't be a problem.

The Advanced Client does require a new SMS site system, and that's called the management point. The Advanced Client communicates with the SMS site through the management point. It also does communicate with the distribution point, but primarily its communications are with a management point. We'll talk about this in a little more detail on the next couple of slides.

Another very common installation issue that people have had with the Advanced Client in the beta time frame has been that the client could be installed, but it was not reporting in to the SMS site. It wasn't reporting as being discovered or as installed to the client. Oftentimes, from the work I've done with people, it's been because the management point hasn't been fully installed, and that, most likely, has been because MSMQ has not been preinstalled. Then we tried to push it out and we couldn't find the source files again. Again, getting MSMQ installed in your clients and your management point systems prior to using them for SMS will save you a lot of grief in the beta time frame.

In upcoming slides, we'll talk about the various installation methods there are for the Advanced Client. We do have numerous different ways of deploying the Advanced Client platform.

If you do want to use Advanced Client in your environment, you have to have at least one management point created in your hierarchy (slide 6). This is a requirement for the Advanced Client. The management point is a new site system role for SMS 2003. Basically, it's a CAP for Advanced Clients. You all know what a CAP is for SMS 2.0, where the client goes to finish off its installation, where it goes to look to see what agents need to be installed or deinstalled, what settings there are for inventory, what configuration there is for software distribution, are there any advertisements. It's also where the client reports its data files, inventory data, and so on. The management point in SMS 2003 provides those same functions for the Advanced Client. There is a requirement for at least one management point in your hierarchy.

All client-to-site communications go through the management point, except content access off of distribution points. Whenever the client creates any discovery data, inventory data, software metering usage data, status messages, policy retrieval or downloads, including advertisements or advertised programs, that all goes through the management point. Data is reported up in XML format and policy retrieval is done through XML as well.

Clients retrieve client site setting configuration in policies from the management point. If you remember how standard client works in a CAP, it goes through static files in the CAP and looks at the configuration of the site. That could cause problems because the CAP could be offline when the site has been updated so the client may receive outdated information. The management point doesn't store anything local. It goes directly to SQL Server™ to retrieve the data, and I'll show you that a little bit later on.

Clients receive advertisements as policies from the management point. They don't look at the CAP like standard clients do. This means that client settings are usually more up to date, as management points pull policies directly from SQL, where CAPs relied on the static file transfers, as we mentioned before.

How do management points fit within the SMS hierarchy and what are their requirements? Typically, you'll find there will be one management point per primary site (slide 7). It's not a requirement to have one at every primary site, but you probably will like it to be that way. Clients can only be assigned to sites with management points, so clients can only be assigned to primary sites with management points. You can have a single management point per a hierarchy if you want to, but then all of your Advanced Clients will be assigned to that one site with the management point.

You can have multiple management points per primary site using Windows Network Load Balancing. However, if you have multiple management points that are outside of an NLB cluster, then the clients will only ever use one management point, even if you have two or three or four. They'll use the one designated in WINS or designated in Active Directory as the default management point. That's the one all the clients will use. The other ones would just be there for standby. If you do want to have multiple management points for redundancy, load balancing, fault tolerance, etc., then you would set up an NLB cluster and publish the virtual IP address to SMS as the default management point. This is not required at each primary site, but again, any site that you want to have Advanced Clients physically assigned to, does require a management point.

Clients can access a remote management point, if necessary. When roaming, they can access the assigned site's management point for content access. In other words, where is the distribution point that has this program I want to install, or if they can't find a local management point, they can fall back to their assigned site's management point and see if they can help out in certain scenarios.

Management points are supported at secondary sites, but they're proxy access. In other words, clients can't be assigned to that secondary site's management point. They'll be assigned to the parent site's management point, and then the parent site's MP will redirect or proxy the client down to the secondary site's management point. Then the client will just interact with the secondary site as if it were directly assigned to the secondary site. It's just that the secondary site's management point will go directly to SQL Server for retrieving policies and policy assignments for the client, but the client data that's being generated will be sent to the secondary site's management point, which will then forward that to the secondary site's server itself, improving your WAN connectivity and requirements.

A management point requires Windows 2000 Server Service Pack 2 or later and IIS (Internet Information Server). It also requires MSMQ in the beta, as we talked about before, which has been a fairly common stumbling block. Again, we're removing that for you, so for beta, when you're playing around and testing things out, just make sure you preinstall MSMQ and you'll be in pretty good shape. HTTP and BITS, which are included in IIS, are the main communication methods between the Advanced Client and the management point itself.

As already mentioned, the Advanced Client does require access to the SQL Server, which is either the SMS site database directly, or if you want to reduce the requirements of the site database in interaction with management points, you can set up SQL replication for management point processing, and the management point can go to a SQL replica instead of the site database to remove that load off the site's SQL Server.

Now that we've talked about the requirements of the Advanced Client, let's talk about the different installation methods (slide 8). There are numerous different ways of installing the Advanced Client, and you'll have to pick and choose which way fits best with your environment and your networking structure that you have.

There is no automatic discovery and installation method. What you knew in SMS 2.0 at the Windows Networking Logon Discovery and Windows Networking Logon Client Installation methods no longer exist in SMS 2003. Now, that doesn't mean that you can't install the SMS 2003 Advanced Client through logon scripts. I do it all the time whenever I do demonstrations. I create my own little logon script and have it run a very small little program, it's like 72 kilobytes (KB), to kick off the installation process. I do that through my logon script. That works fine.

The difference is that none of this is automated for you with your logon points or with domain controllers as it was in SMS 2.0. You guys very clearly told us you didn't want us touching domain controllers. You didn't want us requiring domain controllers, so we've removed that for you. If you do want to use domain controllers in your SMS environment, you have to go through and configure that the way you want it done.

If you want to copy a couple of files over to the Netlogon share on your PDC and have it replicated out to the BDCs and create a logon script, perfectly fine with us. We'll give you some samples on how to do that. It's very, very simple to kick off and run that processing. It's very easy, but it is management you have to do on your own. It's not self-managed like SMS 2.0 was.

The different methods of installing your client include SMS package delivery advertised to a standard client. You've upgraded from SMS 2.0 to SMS 2003. During the upgrade we maintained your clients as standard clients. Now you want to deploy the Advanced Client. You can use SMS software distribution to target SMS 2.0 clients or SMS 2003 standard clients that have the appropriate platform, Windows 2000 and above, with the Advanced Client. We'll de-install the standard client and reinstall with the Advanced Client; very simple and easy to do. In fact, I'll show you a screen shot later on that will show you a computer that was upgraded.

You can use Group Policy or IntelliMirror®. You just deploy the Client.msi file. The one downside you have with Group Policies is that you can't use any command-line switches. You're pretty well stuck with a default installation and have to do modification later on. Now one advantage you do have there is that you can deploy an administrative share. You can set up an administrative share of the Advanced Client installation. You can configure your administrative share with the parameters that you want the client to be installed on, whether it's a new cache size, new cache location, an install directory, whatever the case is, and then you can deploy through Group Policies using the administrative share of the Advanced Client.

You can preload your client image in the operating system image. You can take the Client.msi file, which is a Windows Installer file; you can install that into your OS image. Even without having a management point or SMS installed at all, you can install the Advanced Client and just have it configured for automatic discovery. When you deploy that client image out to a new desktop, when he boots up he'll try to start the client service, and it will try to see if it can find a management point to communicate with, so find out what SMS site it's assigned to. You can do that, and you don't have to worry about duplicate GUIDs we talked about before, how the client now maintains that and detects if this was a clone scenario and changes its GUID.

You can do a manual installation. You can just launch off Client.msi from the command prompt or through Explorer, and it will do an installation of your Advanced Client. That works fairly well as well.

Also included in the beta, although it's fairly hard to configure because there's no user interface for this, is the Advanced Client push installation method. The Advanced Client push installation method allows you to do a discovery, such as Active Directory system discovery, and then push out the Advanced Client platform to those appropriate desktops and laptops that meet the operating system requirements, Windows 2000 or Windows XP. It can be done in beta; it's just a little bit hard to configure right now. After beta we'll have user interface so that you can configure the installation method and you configure the platforms and so on.

Once the Advanced Client is installed on a computer, the standard client cannot be installed over the top of the Advanced Client. What we do is we update the registry to prevent the Advanced Client from being overwritten by the standard client.

Now that we've installed the Advanced Client, what does it look like (slide 9)? I think I showed you this slide before, back in December possibly of last year, talking about the Advanced Client or maybe it was early this year. The Advanced Client's service is called the SMS Agent Host service. This is basically what you know as the SMS Client service for SMS 2.0. It runs a single executable called CCMExec. That process requires approximately 13 megabytes (MB) of RAM for the base services; in other words, the Advanced Client itself. Then if you enable hardware inventory, software inventory, software distribution, software metering, and remote control, it adds a couple more megabytes to the RAM requirements so it's about 14.8 MB is what I usually see on my systems of memory requirements for a fully configured Advanced Client.

One of the really cool things is that the Advanced Client does not use user accounts. The service itself runs under the LocalSystem context. It's a much more secure environment, and you do have the ability of using computer accounts across the wire or you can use your logged on user account, or there's actually an optional account you can create in certain scenarios that you may need to use.

It requires BITS for policy retrievals, data uploads, and download-and-execute software distribution from remote distribution points. You can use SMBs in that scenario, but for policy retrieval and data uploads, we do use BITS; so we do require that. It also is what gives us all the bandwidth awareness utilities that we talked about before, all those functions.

We do prefer SMBs for local distribution point access. In other words, if the client is on the same subnet as a distribution point, we'll use SMBs instead of BITS or HTTP to download the content. If that's not available, we can use BITS or if a remote distribution point, which normally would use BITS, is not configured for BITS, we'll use SMBs as well.

By default the client installs to the %systemroot%\System32\CCM folder. No longer does it go to the MS\SMS folder, but System32\CCM. It's about 6 MB of disk space and then your space for your log files as well. You can configure the installation directory if you wish to.

Here's a screen shot (slide 10) of the SMS Systems Management program and the Components tab being selected. You just see the different components that are installed. If you look down at the bottom, the bottom four components would be all the optional components that you're used to, Remote Tools, Inventory, Software Distribution, and Software Metering. You can see that they all say "Installed." All agents install automatically with the Advanced Client. That's why the MSI file is fairly large, almost 7 MB, because all the agents are installed in there. They just don't operate until you enable the client agent within the site. Here you see that all the client agents are enabled. Right now Software Metering still says "Installed" even though it is enabled, but they will change from "Installed" to "Enabled" when the agent has been enabled in the site and the policy has been downloaded, retrieved, and implemented to activate those agents. You'll see that the status will change from "Installed" to "Enabled."

Just how do you assign an Advanced Client to a site if it doesn't care about site boundaries (slide 11)? I mentioned before that the Advanced Client doesn't care about site boundaries for the most part. Assignment can be manual or automated. Automatic assignment can be performed during installation using a server locator point, which is a new site system role for SMS 2003, or if you're in an Active Directory environment and you have extended your schema for SMS, we can do assignment from Active Directory schema and data publish there.

If you do a Capinst install, the new utility we have for installation, if you run a Capinst install it does default your client to an automatic assignment scenario. In other words, as soon as the client is installed, when the CCMExec or SMS Agent Host service starts up, it goes out and tries to find a server locator point or it finds a management point to figure out what site it's assigned to. It will persist that in WMI. Then it will go to Active Directory or WINS to try to find the default management point for the site it has been assigned to.

You can also perform automatic assignment after installation using the Systems Management Control Panel program. I'll show you a screen shot of that a little bit later, where you can see the Automatic Discover button. If you do automatic discovery, we do utilize the site boundaries for the Advanced Client, but they're only utilized to figure out whether or not you're assigned to the site or whether you should be assigned to the site in an automatic assignment scenario.

If you want to go through a manual assignment, that can be done by an administrator, using the Systems Management Control Panel program during installation or after installation. During installation you can do your assignment using the SMS Advanced Client Installation Wizard. It will prompt you for your site code and you can specify the three-character site code there. Then it will assign you directly to that site, regardless of whether or not you're physically within the boundaries of that site.

A manual assignment is not based on site boundaries. It doesn't care about the site boundaries at all. Automatic discovery does care about site boundaries; that's what it looks at to see if you should be assigned to that site or not.

Client must be assigned to a site to retrieve policies. If the client is not assigned to a site, it's not going to receive any policies. It also has to be able to find the management point for its assigned site to be able to download policies. I'll show you that communication process in a minute.

As stated before, Advanced Clients can be assigned only to primary sites. They can physically reside in the secondary site, but they are assigned to the primary site. It's the direct parent of the secondary site where they need to be assigned to. Then the management point will proxy them down to the secondary site's management point for all communications from the Advanced Client to the management point.

Let's take a quick look at the communications in an Advanced Client environment (slide 12). Here, you see policy retrieval. The scenario would be that, first off, the client is running. He wants to request policies. The client goes to the management point and requests policy assignments. Are any policies assigned to me? The management point goes to the SQL Server directly, either the site database or SQL replica, and reads the policy assignments table from SQL and passes any assignments for that client down to the client computer itself.

The client then analyzes the policy assignments to see if there are any new policies or any policies that have been updated. If so, it goes back to the management point and requests a download of specific policies by policy ID. The management point then goes back to the SQL database, either the site database or the SQL replica, retrieves the policies from the policies table in SQL, caches them locally at the management point, in case another client is going to ask for the same policy, and then forwards them down to the client through BITS in XML format.

The client then retrieves the data through BITS, persists it in WMI, and then applies the policy through something called the policy evaluator. The communications from the client to the management point are over HTTP initially for policy assignments and policy requests. Then the download is through BITS. That's to retrieve policies.

Now the client has retrieved policies, has generated data. How does it report data up to the site (slide 13)? The client will generate its data, discovery data initially, and it will pass that back up to the management point in XML format. The data will be formatted and passed up in XML through BITS up to the management point. At the management point, the data is converted from XML format into the standard data format that the site server is looking for. The site server doesn't understand XML format for most of its components because we didn't rewrite all the components on the site server to support XML. They're still looking for DDRs, hardware inventory files, software inventory files, status messages, and so on in the standard format, NHM, MIF, SIC, SID, SVF files, and so on. It's still looking for that type of format so the management point will convert the data from XML into standard site server format, and then use SMBs to push that data from the management point over to the site server. Then the appropriate component will process that data and place it into the database.

What are considerations for the Advanced Client software distribution (slide 14), some things to be aware of? The Advanced Client has the same basic software distribution functionality as the standard client. Everything you can do in regards to software distribution on the standard client you can perform as well on the Advanced Client. The Advanced Client just has some extra features involving BITS and download-and-execute model.

We pretty well talked about BITS and how it operates. BITS is preferred for access of remote distribution points. We'll talk about remote distribution points in the next couple of slides. Local distribution point access is preferred using SMBs; so SMBs for local DP access and BITS for remote DP access, by default.

The Advanced Client has a local cache for downloading programs, which you can configure the size and location. You can do program downloads during connection periods, including spanning multiple connection periods using the byte-level checkpoint restart, either a BITS or SMBs. We also have that as well in the Advanced Client is byte-level checkpoint restarts.

Bandwidth sensitive to user requests across the network, we talked about that before with BITS.

If you are doing a download-and-execute, after the entire program has been downloaded to cache, the client can execute that program, even if you've disconnected from the network.

Distribution points must be configured to support BITS, if you want the client to access the DPs through BITS. If you don't, then we still access the distribution points through SMBs. In order to have a distribution point supports BITS, it requires Windows 2000 Server Service Pack 2 as well as IIS, because the access through BITS is over HTTP, so it needs to be an IIS server.

How do you determine whether a distribution point is local or remote (slide 15)? That goes through a process called roaming. Roaming is defined as anytime that the Advanced Client leaves the boundaries of its assigned site. Anytime the client moves from its assigned site, outside of its roaming boundaries or its site boundaries, it becomes a roaming client.

The Advanced Client can find a management point for the local site from Active Directory or WINS. When I'm assigned to a site, I go to Active Directory or WINS and find my management point. Then I utilize that management point for policies, content location, and so on. Again, it only works through Active Directory if your Active Directory schema has been extended.

When I move from my assigned site to some other location, then I'm in a roaming scenario. There are two different types of roaming that we'll talk about — regional roaming and global roaming.

Regional roaming is where you roam or move to a child site of the assigned site. In other words, I've gone to a child site, I've gone to a grandchild site, I've gone to some other site in my hierarchy underneath the assigned site for that client.

That works with Active Directory schema extensions or through WINS. We do support regional roaming with WINS or Active Directory schema extensions. The assigned site knows about all the resources of the roamed site so we can just use WINS, if necessary, and our assigned site information.

The other type of roaming is called global roaming. That's where you roam to a site that's outside the assigned site's hierarchy. In other words, you don't go from the assigned site down to a child site. You might go to a parent site. You might go to a sibling site. You might go to some other foreign site we don't know anything about. Because of the fact that the assigned site knows nothing about this other site you've roamed to (because it's not underneath its hierarchy), we can't utilize the assigned site for any kind of resource access to the roamed site. You have to go and utilize resources at that roamed site.

This does require Active Directory and schema extensions. It will not work with WINS. WINS does not provide the data necessary for global roaming. You do have to have Active Directory enabled, and the Active Directory has been schema extended for SMS. If you haven't done that, you're not allowed to do any global roaming.

When roaming to other sites, we use Active Directory to find the management point local to that site. That allows you to determine if there are any local distribution points we can access for content when we try to run an advertised program. What we allow you to do is retrieve your policies from your assigned site, but then access content from the local site, whatever the site you happen to be sitting at. To do that, you find a local management point, if possible, in that site you've roamed to, to see if there are any distribution points that can satisfy your request, in other words, that have the content that you're looking for.

Site properties dictate which boundaries are considered local versus remote. That's the Roaming Boundaries tab, and we'll see that in a couple more slides.

If there is no local management point, we can use the management point for the assigned site for content location requests, but that may not give you what you want in a global roaming scenario. You may have to fall back to your distribution points at your assigned site, if you're in a global roaming scenario and we can't find any management points at the site that you've roamed to. If you have no management point, you can't access the management or you can't resolve the computer name, then you fall back to the management point from your assigned site.

What else is there about roaming that needs to be known? This is a confusing topic for a number of people. Roaming is a little bit harder to understand in some scenarios.

Roaming allows you to retrieve policies from your assigned site but content from a local site (slide 16); that's basically what it is. Let me get policies from my assigned site, wherever I'm assigned to, but whenever I want to run an advertised program, let me find a distribution point locally that can satisfy that content request. Let me pull content, advertisements, and programs from the local site, but let me get my policies, which would be the actual advertisement itself from my assigned site. That's the general rule.

The exception would be at a secondary site. At a secondary site you will utilize the management point of the secondary site for all client-to-management point functions, once you've been redirected down there by your assigned management point. Once you've been given that secondary site's MP as a proxy, you'll utilize it for your management point access.

We always use BITS for policy downloads. The client will find a management point in the roamed site, if it can, to find distribution points for content, if available. If not, then it goes back to its assigned site MP; it falls back there. Each advertisement you create configures whether or not you want to let the program be accessed from a local or remote client to the distribution point, and if so, how. I'll show you that, again, in a couple of slides on how you as the admin control the access to your content by local and remote clients. The management point will tell the client if the distribution point supports BITS, so we know whether we can download the programs through BITS or whether we have to use SMBs. After the full program has been downloaded, you can execute from cache, even after disconnecting from the network itself.

Here's a look at the Roaming Boundaries tab (slide 17). This is where you designate what boundaries are considered local versus remote. First off, if you see the check box that says, Enable roaming for all site boundaries for this site. What that means is that all boundaries that you have on your Site Boundaries tab also are considered as local roaming boundaries. Local roaming boundaries means that if a client accesses the site through a local boundary, in other words through a site boundary, the distribution points are considered local to the client, so it gets to use those distribution points as local DPs, as opposed to remote DPs; or you can specify roaming boundaries.

You can see I have two boundaries specified in my site. I have an IP address range. I don't have IP subnet listed, but an IP address range. You can see 192.168.21.110 to 192.168.21.119. Those 10 addresses, if a client accesses the site through one of those 10 addresses, you can see in the far right, under Distribution Point, it says Remote. If a client accesses the SMS site through one of those 10 IP addresses it's considered to be a remote client, and it treats my site's distribution points as being remote to the client. What that means depends upon how your advertisements are created, which we'll see on the next slide.

Then I also have an Active Directory site called Building7, and that's configured for local access. Because that's a building on my campus, I can specify that the client connects to my site through that Active Directory site name, then it's considered local, and it can use my distribution points as local distribution points as opposed to remote.

You can also specify IP subnets in here as well. I have not done so because you guys are familiar with that from SMS 2.0.

Roaming boundaries have no effect on standard clients. They're only used for Advanced Clients. Standard clients only use site boundaries.

We just talked about how you figure out whether your client is remote or local to the site. Now that ties into advertisements (slide 18). Here's a screen shot of an advertisement and how you can configure for your advertisement whether or not you want access to the distribution point from local or remote clients, and if so, how.

If you look, these are default values that I have here. When a local distribution point is available, run the content from the distribution point. In other words, if the locality of the distribution point to the client is considered local, then you run the content directly from the DP, just like you do in SMS 2.0 or it can specify Download before running.

If the locality of the DP to the client is considered to be remote, in my case it would have been the IP address range in the previous slide on my Roaming Boundaries tab, then the default configuration is don't access the distribution point. Don't access that program on that distribution point. Or you can configure it to download from a remote DP before running, so download-and-execute. Or you can say, run directly from the distribution point, if you want to. You get to configure this on an advertisement-per-advertisement basis for your local clients or remote clients, so that clients who roam to your site in a local scenario or a remote scenario you get to control that.

This tab, the Advanced Client tab, has no configuration or no impact on standard clients again. It's only for the Advanced Clients.

I know that took longer than I was hoping, but there was still some information there on troubleshooting. Now I actually want to get into the part of troubleshooting the Advanced Client (slide 19). Again, a lot of the problems that we'll talk about in this slide are things that we talked about already in going through the review. What are the most common problems that people have experienced in working with our beta product?

First off, not having MSMQ or Message Queuing preinstalled. We talked about that enough. If you're using the beta product, manually preinstall MSMQ on your clients you want to be Advanced Clients and on your computers you want to be management points. That will alleviate a lot of issues, so that's the number one thing.

Secondly, Advanced Clients are not active until after system restart. Again, that's taken care of with the new BITS installation wrapper that we'll have available after beta. However for beta, if your client doesn't already have BITS installed, when you install the client we push the BITS out, and that does require a reboot. After you set up your Advanced Clients, if BITS was not already preinstalled, you will have to reboot your Advanced Client before the Advanced Client becomes fully functional. Again, that's just a beta thing. Those first two "gotchas" we have right there, we're going to take care of post-beta.

Your management point is not completely configured. Normally, again, that's because of a lack of MSMQ being preinstalled. The big thing to do is, after you think you've set up your management points, look at the computer you think is a management point, and verify that CCMExec is running. If CCMExec is not running or SMS Agent Host as a service, your management point is not functional, and your Advanced Clients can't access that management point. That's the thing you'd look for there, just look for the service, SMS Agent Host, on your management point.

Clients cannot retrieve policies. There are a lot of different issues there. Most often, it's because the management point has not been fully configured, so it hasn't had MSMQ installed. Possibly it didn't get registered in Active Directory properly, or you didn't have Active Directory schema extensions, so we couldn't register it. WINS, it was not published in WINS. You didn't designate your default management point. You have to designate the management point you want to be the default, and if you have multiple management points, you do have to designate one. I believe in an express setup, I want to say in beta, if you do an express setup, we don't designate the default management point, and you have to go in there and do that manually.

The client can't resolve the computer name that's designated as the default management point, or it can't access it through physical communications. You've deinstalled and reinstalled with new management points. We have an issue right now where we don't remove things from Active Directory. Once we've published a management point in Active Directory, if you deinstalled your site and reinstall with a different management point, your client may select the default management point that was previously published by the previous site that's not a management point anymore. It's going to look at an invalid computer. That you can just get around by deleting your information from the Active Directory schema, the SMS publish information, and then just letting SMS repopulate that information, which we'll do automatically for you.

Clients are assigned to a secondary site — not allowed at all. Your clients have to be assigned to a primary site, the parent of the secondary site. Then things will work fine, but if you assign your clients to a secondary site they will not operate because they won't find any management points, and they won't be able to download any policies. The client will be in an orphan state, just waiting for a management point.

Clients cannot access content from remote distribution points. Your roaming boundaries are not configured properly or if they are configured properly, you may have not configured your advertisement to allow access to a remote distribution point. Remember the default we saw in the previous slide was that you cannot access content from a remote distribution point by default. You have to modify that configuration.

If you did a CAP install, we do create an installation file for you for the Advanced Client. If your batch file was running Capinst, we do create a log file that shows you the actual installation process of your Advanced Client. That will be a good log file to look at. If you did a manual install, there is no log file created by default for the actual installation of the Advanced Client, but we'll talk about how you can do that. For a management point, it's important for you to look at your log file for the management point installation, which is Mpmsi.log. You want to look there to see if your management point got fully configured or if not, you look in there to find out why. Again, most commonly, it's because MSMQ was not installed. Those are the most common issues that we've found.

Let's talk about a few more specifics. The first thing we want to do is just go through the process of Advanced Client logging (slide 20). Unfortunately or fortunately (it depends on your feelings), a lot of the troubleshooting you'll do on Advanced Client is done through logging. If you're familiar with logging from SMS 2.0 and reviewing the log files there, I don't want to say you're going to be fairly comfortable with the logging from the Advanced Client, because it has been completely changed. There are new log file names and new log file formats for the Advanced Client. However, if you're comfortable with reading log files, then this would be a good way for you to do your troubleshooting of the client. There's a new service, the SMS Agent Host, the new executable CCMExec, total new code, and new logging process.

We do have a modified or updated SMS Trace that comes with SMS 2003 that works for the Advanced Client logs. The version that you have today from SMS 2.0 Service Pack 2 or downloaded off the Web site doesn't properly format the Advanced Client log files very well. You do want to use the new version that comes with SMS 2003 beta, and I'll talk about that a little bit later on.

Logging is enabled by default as part of the client installation. Generally, if you just do a manual installation of your client, just running the Windows Installer file, your log files will be configured to 1 MB in size, so you have log files that can grow up to 1 MB in size. Once that file maximum has been reached, we create one new log file. We keep one history log file, kind of like the LL_ and LOG files that you have with SMS 2.0. This one, however, we don't rename the file to LL_. What we do is we take the file name, such as Policyagent.log, and we append to the file name the date and time stamp of when the file maximum size was reached. It might say something like Policyagent-20021126-0900 as the time for that log file. Then when we fill up the next PolicyAgent log file, we get rid of the old history and create the new history file, so we keep one by default.

You can configure both the log file size and number of logs as installation parameters. I've given you the two parameters on the screen there, CCMLOGMAXSIZE, which defaults to 1 million bytes, it's in bytes, it defaults to 1 MB, and CCMLOGMAXHISTORY, the number of history files to keep, and the default there is 1. You can change the default log file size as well as the number of logs to keep.

Again, there is not an installation log file by default unless you do Capinst. If you do Capinst, we do create an installation log file. It actually goes into the client's Temp folder, so it would go in the Documents and Settings\<user name>\Local Settings\Temp, and then you'll find Capinst.log, and if you open that up, it will tell you exactly what log file we're writing to, but it will be something like Cli3.tmp. Then you open up that file, which will be like 1.25 MB for the actual installation of the Advanced Client, and you can see the Advanced Client installation process in there. When you run a Capinst install, at least in beta, the default log file size is set to 100 KB as opposed to 1 MB.

Now these next three slides (21, 22, 23), I'm not going to go into any detail at all. I'm just listing for you the different log files that you'll see in an Advanced Client in different scenarios. Then on the subsequent slides (24, 25, 26), if I can get through them, we'll talk about what log files you use for different scenarios. I'm going to have to cruise through this fairly quickly to get done with the content or I may have to redirect this content to a later WebCast if I don't get there. Again, this is not going to be any detail; it's just going to be, "Here are the names of the log files on these three slides."

CAS is for content access. Whenever you have to access content from distribution points you'll see CAS.

CCMExec. That's your SMS Agent Host. That would be similar to the CCIM32.log on an SMS 2.0 client.

CerificateMaintenance. This is where the client retrieves certificates for the management point from Active Directory or from the MP itself. That's how we validate, gives it some extra security by the client validating messages from the management point by verifying or validating with a certificate. You'll see the client downloading certificates from Active Directory.

ClientLocation. This is where we go through the process of determining what SMS site the client is assigned to.

ContentTransferManager. This is where we manage the local cache for the download-and-execute programs. If you're doing download-and-execute, the ContentTransferManager is what manages that cache.

DataTransferService is download of policies from management point through BITS. When you do a download through BITS, you see data references in DataTransferService.

Execmgr. This is where you run your advertised programs, so that would be similar to the SMSapm32.log for a standard client.

FileBITS is for SMB access for download-and-execute content retrieval from distribution points.

Fsinvprovider. This is your software inventory log, very similar to the SM32.log from the standard client.

InventoryAgent is you inventory hardware and software inventory log file, similar to what you might see in CCIM32.log for discovery or HM32 or SM32 for hardware and software inventory respectively. The Fsinvprovider log file just gives you a little more detail for software inventory.

LocationServices. That's where we determine which management point and distribution point to use. When you find your management point, that's where you can tell whether or not you did find your management point properly. It will tell you the computer name for the management point. If you make a request for a distribution point, it will tell you what distribution points are available.

Mtrmgr. That's your Software Metering Client Agent. That's where you'll see processes that have been initialized and whether or not they have resolved to any software metering rules.

PolicyAgent is where you'll find the client requesting policies and downloading policies. There, if your client is not performing the way you think it should be performing, you want to open up PolicyAgent, and you'll find a request that says "Request machine policies." Then later on you should see "Download," and it should tell you the policy ID. You'll want to specify that, verify there whether or not you've downloaded your policies.

Once policies have been downloaded they're persisted in WMI. Then a couple of minutes later PolicyEvaluator will evaluate that policy. Basically, evaluating the policy it is activating or implementing it locally.

RemCtrl is the Remote Tools Client Agent. You'll see installation of the Remote Tools Client Agent itself.

Scheduler launches scheduled tasks such as the time for the PolicyAgent to go up there and download policies.

SMSCliUi. That's the log file whenever you use the Systems Management program in Control Panel.

StatusAgent is the creation of status messages.

SWMTRReportGen. That's the creation of software metering usage reports. After I've run processes that you've seen in Mtrmgr, once you've seen processes matching usage rules, we cache that information in WMI. Then at our timing interval, whatever the schedule is, the default is weekly, and we take that information from WMI. We create an XML file out of that and SWMTRReportGen goes ahead and forwards that information up to your management point, which is your software metering usage data.

Now that we've looked at a quick overview of the logs on those last three slides, let's look at the log files that are pertinent for specific areas: installation, configuration, and software distribution.

Installation log files (slide 24), first you would have the installation log file of the client agent itself. That, again, would be either in the user's Temp folder, if you ran a Capinst install, or you would have had to designate it manually if you wanted to do a manual installation. By default, if you just launch off the Client.msi file, we don't create a log file, but you can, when you run the Client.msi, specify a command-line parameter. That parameter would be /l*d <filename> (filename is the file name that you want to use for your log file).

Then we'll create a log file. It will be over a megabyte in size, around 1.25 MB, of all the details of installation of the client. If your client's not installing properly, you do want to look in there. You might want to search for message queuing. You'll probably find that message queuing is not installed.

Once you've gone past that CCMExec, you'll see where you access certificates from the management point and start the client services. You want to look for errors there in getting things started.

CertificateMaintenance, which I don't have on here, I mentioned it on one of the previous slides, is where you want to access the certificates from the Active Directory or the management point to give you your validation of certificates so that you can validate your messages from the management point.

LocationServices. You want to verify that your Active Directory site has been detected properly, verify that you're a member of the correct SMS site, and that you've found your appropriate management point.

ClientLocation. You're verifying that the SMS site has been detected automatically, especially if you've done a user-configured automatic discovery.

DataTransferService. You'll see requests for downloading and completing download of policies from the management point.

PolicyAgent. You want to verify that you can see sections that say "Download," and it will give you a policy ID. Until you see that your client is not really doing much until it can download its policies.

PolicyEvaluator. That's where the policies will be evaluated.

InventoryAgent. Automatically after installation we're going to generate some discovery data. You want to go in there and verify that you can see your attributes that were queried. You won't see the values for them, but you will see the attributes.

The most common issues for installation — can't get a certificate from a management point. That could be from Active Directory replication latency or management point certificate issues could cause delays in publishing those certificates into Active Directory or your schema hasn't been extended. Therefore, you have to go directly to the management point to retrieve the certificates.

Can't find your management point. Either LocationServices or ClientLocation logs, you want to look in there. Again, it could be Active Directory replication issues. It could be that your management point is not installed properly because of MSMQ or other issues, not published in WINS, if you're trying to fall back down to WINS.

Can't download from management point. Bad certificates can cause a long delay in downloads of your policies.

Next let's talk about configuration log files (slide 25). Once your client has been installed some of these log files will look fairly similar, but you can look at LocationServices to verify your client has been able to find the site it's a member of, the SMS site and find its management point. Scheduler, you'll see it will kick off the launching of the PolicyAgent to download policies. PolicyAgent, again, you'll want to look in there to verify that it did download policies from your management point.

DataTransferService. You'll see references to the downloading of those policies again. PolicyEvaluator. It's going to implement those policies and make them become active. Then your individual component log files for feature usage and processing. InventoryAgent. You look for your end points, HM endpoint, SM endpoint, or DDR endpoint; that will tell you what type of inventory processing is being done. A single agent does everything for DDR for discovery, hardware and software inventory in SMS 2003 on the Advanced Client. It will give you the ability of looking to see what's going on. Mtrmgr is for running processes and validating whether or not they match any rules that have been created at your site. Software meter report generating (SWMTRReportGen) is for taking your data from WMI and pushing it up to the management point at the appropriate reporting interval. RemCtrl, or for Remote Control you'll see it installing NT 5.0 devices, the start of the WUSER32 service, the SMS Remote Control Agent.

Common issues for configuration, most likely it's because your client is not connected to the network, it can't access the management point, or there's no management point available. You've configured your site settings, but the management point is not available. The client can't access the management point. Or maybe the management point can't access SQL Server, so maybe the management point's computer name is not inside your SMS site system to SQL connection site code group, so it's not there. Maybe you can't authenticate your policy because the certificate is invalid, or you can't validate the certificate. Those are a couple of issues there.

Software distribution (slide 26) is one of the more complex areas of the client, only because there are some new features to it. There are some new things there that we need to look at, and that makes it a little more complex because it's not quite the same as you're used to from the standard client or SMS 2.0.

First off, you look at the same log files as retrieving any policy because an advertisement is just another policy. Whatever log files you would look at (such as PolicyAgent, LocationServices, DataTransferService, PolicyEvaluator), you would look at those same log files when you're doing software distribution to verify the client has downloaded the policy for the advertisement.

One nice thing is that the policies for advertised software are named differently than standard policies. You actually see your advertisement number, so it will tell you your site code and then five random digits for your advertisement. You'll be able to identify advertisements, as opposed to other policies, very, very easily.

Then once you've looked at those, LocationServices, that's where you'll determine which distribution points are available and whether or not those distribution points support local or remote access and whether or not you're going to use SMBs or HTTP or BITS to download data.

CAS, the Content Access Service log, will specify which distribution points you're using, if there are multiple distribution points.

Execmgr. You'll actually see the command lines that are being run. It will say, "Preparing to run" this command line, msiexec/i office.msi. You'll see the execution of the command line, the exit code that's returned as well as status messages saying, "I'm raising a status message for" receiving the advertisement, for starting the program, and for successfully completing the program.

ContentTransferManager manages local cache for download-and-execute programs. It will show you the download requests.

DataTransferService will show you your BITS and SMB downloads from your management points as well.

Common issues for software distribution include no access to remote distribution points. Either your roaming boundaries are set incorrectly or the advertisement configuration does not allow access to remote distribution points. No distribution points are available for the package. Again, you're in a remote scenario, and there are no remote DPs, or you're in a local scenario, and there are no local DPs. There is no cache space available. That one we generally do a fairly good job of warning you about, however.

Beside log files, there are a few tools that you want to look at (slide 27). We can breeze through these tools fairly quickly. Some of these tools come with the Advanced Client, some come with SMS 2003. Let's talk about those for you and give you a quick picture of those. Then we'll get you over to the Q&A stuff.

Tools that come with the Advanced Client include the Systems Management Control Panel program. That's to start the Systems Management program application, and we'll show you that. Program Download Monitor is used for software distribution and download-and-execute applications. Those two come with the Advanced Client.

Some other tools that come with SMS 2003 but are not installed automatically, those come in something called the CCMTools bundle. CCMTools is a Windows Installer bundle that contains a set of tools. I've got a few of them listed for you on the slide. This is available on your SMS 2003 CD in the SMS\Setup\Tools folder. You should deploy this bundle out to your Advanced Clients. It gives you a lot of tools that are available and fairly good tools, and I'll go through them here.

First off is SMS Trace. This is the updated SMS Trace that does support the Advanced Client logging. You want to use this version of SMS Trace when you want to view log files for the Advanced Client. First off is SMS Trace. This is the updated SMS Trace that does support the Advanced Client logging. You want to use this version of SMS Trace when you want to view log files for the Advanced Client.

Policy Spy is a good way to initiate downloads of policies as well as to view the policy data itself. I'll show you a screen shot of that.

BITSAdmin can be used to view BITS downloads.

Software Distribution Troubleshooting Tool allows you to view history of software distribution processing as well as view your cache configuration. I'll show you screen shots of these last few tools.

First off, let's take a quick look at the Systems Management Control Panel program (slide 28). This is probably the basic tool that's available. We're going to use this utility. On the General tab, you'll be able to see discovery data. On the Components tab, I showed you that one in a previous slide; that shows you what components are installed and what their status is. On the Actions tab, you can initiate download of all your policies. You can do a machine policy retrieval and evaluation cycles, in other words, force the client to download policies instead of waiting for its scheduled cycle, which is hourly by default.

Then you have the Advanced tab, which is the one that's highlighted here on the slide. This is where you can see what your current site code is, which in my case is called SMS. You can manually find a new site code there, if you're an admin, or you can click the Discover button. The Discover button will do automatic discovery, and that will go out there and look at a server locator point or Active Directory schema extensions to find out what site you should be assigned to, based on site boundaries. Then down below that is your Temporary Program Download Folder, which is your cache location. It specifies the location and the default size. You can configure those if you want to. You can change the location. You can change the size. You can also delete any files that are there, if you need the space for other programs to be downloaded.

Another tool that comes with the Advanced Client install is the Program Download Monitor (slide 29). This is in Control Panel as well. On the screen here I show you two different dialogs. The top dialog is for a program that you try to run that says, "I have to download this content. It's been configured for download before running." It pops up and it tells you, "In this case it's Microsoft Office XP Professional." It tells you that it's 623.3 MB, and if you happen to be connected up to 28.8, it's going to take about 50 hours to download. Luckily, I was not connected at 28.8, but was on the local LAN, so it didn't take that long. There's a check box that says, "Run the program automatically when the download completes." You can select that if you wish.

Just click Download and then the Program Download Monitor becomes available. The Program Download Monitor displays the status of advertised programs that are configured for download-and-execute during the process of downloading. It doesn't show anything until the code is being downloaded. In this case, you can see I clicked Download, and I captured the screen shot here when it says "Download in progress - 5% complete." This is good to show you your process or status of your downloads, if you have programs that are being in a download process and they seem to be going slow. You can load the Program Download Monitor to see what the status is. A few more slides then we're done.

Another tool that's useful for monitoring downloading of data is BITSAdmin. This is a command-line tool, no GUI interface, so you have to go to the command prompt for CCMTools, and it will give you a list of all the BITS jobs that are in download process. It will let you know what the status is of those jobs, whether they're suspended, whether they're currently transferring, whether there's an error, whether they're retrying, whatever the case is. If you're having problems with downloading data, run BITSAdmin with the command prompt switches I have down below, bitsadmin /list /allusers where list is the list of your jobs and allusers is for everybody. You can even add a verbose switch on there to get more information and that will let you see what the status is. That's good if your downloads seem to be going slower as well.

Now if you want to look at your policies, for example, you've created a site setting configuration on your site and you want to download that to the client, you can use the Systems Management Program, if you want to, to download, but you can also have more capabilities by using another utility and that's called Policy Spy (slide 31). Policy Spy comes in the CCMTools bundle, as does BITSAdmin that we just talked about. This is a good utility for seeing what policies have been downloaded currently. You can see the policy IDs because you have multiple. You can also see the policy data itself so you can look at the policy and see what the policy dictates should be implemented. You can see what events have been processed locally on the Events tab, and I'll show you a screen shot on the next slide.

It's useful to initiate policy retrieval. On the Tools menu you can say, "Request policies." You can initiate policy evaluation; by default, we evaluate policies two minutes after download. You can force that to occur quicker if you want to. View your policy data, such as your SMS Def.mof, it gets converted to a policy for the Advanced Client. You can see the policy that shows you that data. Also, you can determine your management point. Are you using the assigned management point? Are you using a local management point for content retrieval, content location or a proxy management point? You can run this locally or from another computer remotely.

Here's a screen shot of that utility (slide 32). This is a screen shot of Policy Spy. I've got the Requested tab selected. You can see some policies, but you can't see them very well obviously, but you can see there have been a dozen policies downloaded. I've got one selected, and if you can see in the bottom half of that screen, in the gray area, that's the policy content. You can see the first line, it says, "Install from local distribution point options." It says, "Run from cache." This is the download-and-execute, even as a local program. It says, "Install from remote DP options," and it says "No," so we're not allowing any access to remote DPs. Then the sixth line down tells you the name of the program "Microsoft Office XP Professional with FrontPage." That's the data from the policy itself. Then down at the bottom, it shows you your assigned management point. If I was using a Local MP, which we call a Resident MP, I've roamed to a site, it's a primary site, I'm going to use this management point just for content and location, it will tell you that, or if I'm at a secondary site and I've been proxied down to the secondary site's MP, it will show you that as Proxy MP.

Then our last tool we'll look at is Software Distribution Troubleshooting Tool or SWSpy (slide 33). SWSpy comes in the CCMTools bundle as well. This lets you get a status of advertised programs that have been run on your client, similar to the Advertised Programs Wizard that you had or Advertised Programs Monitor from SMS 2.0. It lets you see the program name, the execution status, the last run time, and whether it was successful or not. It will also let you look at your cache status, size, location, and if there are any programs in cache currently residing there.

It's useful for checking the status of advertised programs that you've already run as well as looking at your cache configuration. This utility, again, can be run local or you can connect remotely to a client using the utility.

Here's a screen shot (slide 34). You can see I've run two programs on this client. The first one is CCM Framework Tools. That's the package that you would create for the CCMTools bundle. If you just create a new package from definition and point it to CCMTools, that's the package that gets created. I did a "Per-system unattended." It tells you the date and time it ran and it was successful. Then you also see I ran a package called SMS Advanced Client. This was a client that was a standard client, on which I used software distribution to upgrade it to the Advanced Client. It tells you it ran the SMS Advanced Client Install. It was successful. It tells you the date and time as well.

There's also the Cache Information tab. On the Cache Information tab you could view that and you could see what your status is for your cache. It will show you any programs that are currently in cache, and the size and location of your cache as well.

As a quick summary (slide 35), let's go ahead and do a quickie on that, and then we'll kick you off to a special guest speaker for a moment, and then some Q&A through Otto.

The Advanced Clients are the preferred client platform for SMS 2003. We spent a lot of time and effort and dev focus in talking to customers to find out what you guys really wanted for SMS 2003. One of the big things was a new client platform that was able to roam through different sites as well as being able to download content from local distribution points without having to go across WANs. We did a lot of great work there, and we're very excited about the Advanced Client platform. We do recommend that you use this instead of the standard client in every case that you can, which would be all cases other than Windows 98 and NT 4.0.

Troubleshooting the Advanced Client is quite a bit different than that of the SMS 2.0 client or the standard client. You have new log files, new names, and a new format. The services are different, SMS Agent Host service, CCMExec is a component, single agent for hardware/software inventory as well as discovery data. File structure is different. You go to Winntroot\System32\CCM. You use different tools for troubleshooting, Policy Spy, the Software Spy, BITSAdmin, and so on.

It's a little bit different. It's not going to be much more complicated. It should take you a while to learn the new processing. It took you a while to learn 2.0. It will take you a little while to get familiar with this process of troubleshooting this client platform versus the 2.0 client as well.

Systems Management Control Panel program and Policy Spy are two key tools you want to use. The Systems Management Control Panel program is default with the product. Policy Spy comes with SMS 2003. You just have to install it manually through the CCMTools bundle.

Viewing of log files is necessary frequently to get some good data for troubleshooting. It's also a great practice to learn how the services operate and how they do function.

Now before we go hit the Q&A section we have a quest speaker on the line. He's going to give us an update on SMS 2003 (slide 36). This is Bill Anderson, Lead Product Manager for Windows Management.

Bill Anderson: I appreciate the time to come in and chat about some things. I know we hadn't planned on discussing with this particular audience, but it's definitely a great opportunity for us to speak to a broad audience and keep you up to date on what things are going on. What I want to do is take a couple of minutes, and I'll give you guys some of the early feedback we're getting from the Early Adopter Program customers. Now again, I know Wally is going to be spending 90 minutes detailing some of the findings from the Early Adopter customers in the next few weeks, so you'll definitely all want to tune in for that particular WebCast, but I just want to give you guys a quick high level of what we've found out and how that's impacting the product that you're going to be using over the course of the next nine months or so.

The first thing we've found is that the core competencies, as we finished up with these EAP customers, and there are about seven of them or so that we're in production with live right now; all of them at over 1,000 seats in production of SMS 2003, we've seen some great successes on core competencies like software distribution. It's not uncommon for us, in all of their software distribution matrices and testing, to see success rates at the 95 to 100 percent success first try. That was definitely one of the things we were focusing on with SMS 2003, to continue to be successful at delivering the things that our customers are expecting, so asset discovery and inventory and enterprise software distribution.

We're also finding the product quality is incredibly high based on some of the feedback we've gotten from our Early Adopters. In the slide I've put in a couple of quotes there, you can see, of different EAPs, as well as many of you who are beta testers out there who have submitted through beta place, things like "Testing is suggesting that it works wonders for our setting," things that we're seeing that "it's better than SMS 2.0 SP2," and this is in a beta quality code. We're seeing some great things from our customers. We're seeing that they're moving really well through these early issues. We're seeing that they're being very successful in what they're doing.

We added a couple of stumbles we wanted to call to your attention. Again, Wally will make a lot of detailed notes about that as we go forward. One of those was using Microsoft Message Queuing service or MSMQ. As many of you know SMS as a product historically has always been a first best consumer of any infrastructure within Windows, whether it's Windows Management Instrumentation (WMI), whether it's Windows Installer service or even with SMS 2003, the BITS technology to do client-to-server communication that's bandwidth aware, always using infrastructure that ships in Windows because it makes Windows more manageable and hopefully removes deployment blockers for customers.

However, what we found out with MSMQ was that it's incredibly difficult for a lot of our customers to deploy, whether you're an SMS 2.0 customer or an SMS 2003 customer starting from scratch. It's become difficult to deploy, and one of the key deliverables that we promised customers was, this one's going to be easy; we're going to make sure we spend the time and the investment to make sure that your upgrade scenarios are covered as easily as possible.

We also found some minor upgrades that we needed to make as far as the database migration. With each of the seven EAP customers we had some different database upgrade issues that we were able to target and check in fixes for. Some of them are as simple as procedural fixes, such as tempdb grew too large during installation. Some of them are due to the fact that we've put a few more constraints in the configuration in the database, and so just testing those as part of the deployment process. We actually think the constraints are good because it allows the product to be much more consistent and function the way that customers expect it to, but it's something you're going to want to test out in your early testing.

We were able to work with our EAP customers, get their databases into test and make these changes before they went in production. I think only one of our EAP customers had migration issues in production. We've checked all the fixes in, and we'll check all the rest in supporting documentation as well. Again, we're trying to make sure we're doing everything we can so that if you're a 2.0 customer, the migration works and it works really well with a high degree of competence and a high degree of predictability.

Based on some of these stumbles, I wanted to give all of you a quick update on what that means to the product. The first thing we did, after visiting with our customers, specifically our Early Adopters, visiting with our Microsoft field, our consultants in the field who are helping customers deploy, we had to make a hard decision, but I think in the end it's a really good decision for our customer base, which is, as you will see, in a release candidate time frame, removing MSMQ from the client side. That will be a significant improvement to the client as far as deployability. We wanted to make sure we continued to focus on using Windows infrastructure wherever possible, but this was one that we thought the deployment costs and deployment barriers were too large for customers to overcome.

In the release candidate time frame you'll see us removing the MSMQ components from the Advanced Client. That means on Windows 2000 and Windows XP you no longer have or need MSMQ service on your machines. In fact, we won't use it. We'll be writing our own separate transacted way to make sure that the SMS client can capture system information and capture status information, transact that up to a server in a consistent, predictable way.

Some other things you're going to see, some minor changes to the upgrade process. Those are pretty small. A lot of those are procedural and documentation oriented, as well as trying to work with an assortment of tools that allow you to be more predictive on your migration. We'll be spending some time and effort on those particular pieces.

We've also done some things as software distribution has been incredibly successful. We've been doing some more things on the granularity of software distribution status. As opposed to success and failure being very binary, we've really tried to be more granular on the failure returns, so that it could tell you, "I'm sorry this advertisement failed because this client hasn't communicated with the management point yet in 48 hours to get its instructions," so giving you a lot more granularity so when you do have that 5 to 10 percent failure that you're going to see typically on a first deploy, you've got all the information at your fingertips to better troubleshoot that stuff. You'll be able to see a lot more information from Wally in the next few weeks as far as that feedback, and maybe some more detail on what those changes are that we're checking in the system.

However, those aren't without tradeoffs. Those are the right things for the customer base, we believe. Unfortunately, what that's going to do, that's going to be pushing out the release to manufacturing date approximately two to three months. We were hopefully going to see this in the summer of 2003, seeing it hopefully in that June time frame, so we'll be able to make these particular changes, to remove MSMQ and rewrite a transactive (transaction oriented) component, is not without tradeoff. We wanted to update our customer base, as soon as we knew this; that the new release to manufacturing or estimated ship date is in the September ballpark of 2003. I wanted to take a few minutes with this captive audience to let that message be heard, keep you guys as abreast and posted on these issues as humanly possible.

That's all I really wanted to cover. I really agree with Wally. I want to spend more time on your questions and answers and see how between Wally and myself, and predominantly Wally, we can get a lot of these answered for you.

Otto Cate: Thank you very much for the presentation. Before we jump into the Q&A I just have a couple of quick program notes. If you'd like to have a copy of the PowerPoint® slides for your reference, they are available for download from the Web site. The on-demand streaming media is also available there. To access all of that information, including details about upcoming events, the URL is support.microsoft.com/webcasts.

The Q&A portion of the Support WebCast is really intended to encourage further discussion of the topic today. Additionally, one-on-one product support issues are outside the scope of what we're able to address. If you do need some more complex technical assistance, you might want to search for information on the Web, or because we're still in beta, perhaps the newsgroups would be a better alternative for you.

Moving on to the first question here: If there's not any loss of functionality between the Advanced and standard clients, then why would we have two clients? Why not simply the Advanced Client as the only one?

Wally: The reason for that is, and this is probably something before we talked about it, but basically you have to use the standard client if you still are running Windows 98 and Windows NT 4.0 platforms. If you still have client platforms in your environment that are Windows 98 or support NT 4.0 legacy systems, you would have to run the standard client. If your environment is all current platforms, as far as OS goes, Windows 2000, Windows XP and so on, then we highly recommend that you do only utilize the Advanced Client. However, not all of our customers are there yet. Customers are moving there, but they're not all there yet, so we need to make sure we have capabilities of allowing them to support their lower-end platforms, their legacy systems. That's why we still have the standard client, but we do prefer that you use the Advanced Client whenever possible.

Otto: Do we know what plans are for Pocket PCs? Is it just inventory?

Wally: At some point, after the release of SMS 2003 we will have a Feature Pack that will provide some functionality for Windows CE devices. It's going to be more than just inventory from what I understand. If Bill wants to throw any more information in there, that's fine, but from what I know it's going to be more than just inventory, and it will be at some point after the RTM of SMS 2003.

Bill: Yes. Wally, that's a really accurate point. It will be hardware/software inventory, software distribution, which are the typical components that our customers expect of software distribution. So you'll have the ability to do scheduling, the ability to do some basic level targeting on device ID or device components, like what OS it's running, as well as the status system to make sure that once the software install is kicked off that it passes status back, as well as what we're calling Configuration Management.

The interesting thing about Pocket PC or, of course, CE as an operating system is that pretty much any device configuration change is just a simple script or a .cab file. What we'll be doing is working on putting together some kind of a script library or as many samples as we possibly can, so that if you want to do specific configuration changes around Pocket PC, CE, or even XP Embedded, you have the ability to send those particular changes out using SMS. Simple things we get asked all the time are, "I want to be able to turn on the Power On Password," and "I want to be able to enable some of the other components that are typical configurations in the system." Those bits and pieces will be out, as Wally indicated, after SMS 2003 ships.

Otto: Are there any changes on the way for SMS Installer?

Wally: SMS Installer will not be shipping with SMS 2003. It is going to be a separate product. It will still be a free download from the Web site so you can just go up to the Web site and download a later version of it, that's fine. The things that I'm aware of that are new, there are obviously bug fixes, making it easier to do some work, but the biggest thing that people are excited about is that, with the new SMS Installer, it can natively generate Windows Installer files.

In today's environment, you have SMS Installer that creates self-extracting executables. Then we have an add-on utility, or a separate utility, called the Installer Step-up Utility. That allows you to take your SMS Installer programs and convert them into Windows Installer files. The new version of SMS Installer will allow you to natively compile into either Windows Installer format or as SMS Installer executables, so that's the cool thing. You'll be able to generate Windows Installer files natively.

It's not an MSI Editor, so you can't take an existing MSI file and edit it using the SMS Installer, but you can generate scripts, programs, repackage, and so on, with the SMS Installer like you normally do, you can just compile them into Windows Installer format. But that, again, will be a separate product. It will be available free from the Web site. It will not be included with SMS 2003.

Otto: I've got a follow up on the previous Pocket PC question: Will that support be cradled only or direct wireless as well?

Wally: I believe it is wireless. Isn't that correct, Bill?

Bill: Yes, and if you can connect it, we'll support it. If your Pocket PC supports a dial-in modem or if you've got some GSN connectivity you've got it configured with, if you're on an Ethernet LAN, if you're on a wireless LAN, or if you're connected across ActiveSync® via a cradle, basically any kind of networking connectivity supported by the device, we will support. It's a 150 KB client code that is being jointly developed by the core CE team and the SMS team. It will be something that your OEMs can either prestage in your device for you when they're building it, or many OEMs will take this as part of what we call the OEM platform builder process, and they'll build this native manageability client right into the Pocket PC operating system.

If you get a Pocket PC 2003 device, depending on the manufacturer you get it from, you may very well have this manageability client already in there. Then all you do is you point it to a management point and it handles the rest. Any network connectivity that it can detect and that it can use for a transport from a Pocket PC device, it can connect back up to its management point, get its instruction sets, and do its software management.

Otto: This question came in early on in the presentation regarding MSMQ. The question is: We added MSMQ to our current standard image to prepare for SMS 2003. Will it be usable if it exists, or shall we remove it from our image as an unnecessary overhead on our new systems?

Wally: SMS 2003, once you get to the release product and the release candidate mode, will not use MSMQ at all. It's not required at all for SMS. We actually don't use it now, even across the wire, with the beta code. We just use it internally for our internal component communications within each system, but no, you won't need it at all for SMS. Therefore, if you want to remove it as unnecessary overhead from your images, that's fine. Again, it is not in the beta, but will be when you get the next release of code.

Bill: We apologize. I know there were a lot of people who were going out updating their image processes to get these pieces checked in. We wanted to make sure we did all of our due diligence on this one, work with the EAP customers as they did the rollouts, get all the data, and make a decision.

If we would have done this six months ago, we could have pulled the trigger on it and then started with EAP customers and may have found some ways to do this very successfully, because we think that, again, using any infrastructure in Windows to solve these problems is a great thing for our customer base. It minimizes the complexity of the solution, but we just found that there was no way for us to get the MSMQ components deployed on new machines that didn't already have them for customers. That just became a huge barrier.

We apologize for the late notice, but I agree with what Wally said. It's not anything that we're going to require. If you've got other applications that use it, by all means leave it in your image, but SMS will have no dependencies and no requirements on MSMQ. If you don't need it, yes, go ahead and feel free to yank it out of your images.

Otto: SMS 2.0 is heavily dependent on WINS. WINS is pretty slow to update to changes in client names, IPs and such. Has this changed in the 2003 version, that reliance?

Wally: We still can use WINS as one of the methods of resolving computers for remote controls, what the reference is here for, you still can use that as one of the methods. However, we have multiple different methods of resolving computer names and IP addresses. We can use DNS. We can use any name resolution method you have.

There are also a couple different technologies that may be available to you in SMS 2003 that may be better for you than our remote control technology. One of those would be if your client is Terminal Server–enabled, you can launch off Terminal services from the SMS Admin Console to your client. Another one would be if your console and your remote client support Remote Assistance, you could launch off Remote Assistance as another technology to use in place of our remote control technology.

The remote control technology for SMS itself has been improved in SMS 2003, performance-wise and a little bit of reliability-wise, again, just the different resolution methods. If you're having that issue now, and if it's not resolved in any of the later Service Packs, I don't know if it was something that's specifically been taken care of in 2003. I've not heard of any update in that area. My guess is that we're using the same resolution methods we were before. We've just made it better performing and more reliable, and then added the two new methods of remote control activity, being Terminal services as well as Remote Assistance.

Otto: How can you determine that the Advanced Client has been updated? There's not a Sites tab where you can, essentially, determine when the client was last updated.

Wally: There's not a tab like you're used to from the SMS 2.0 client, where you could look at the Sites tab and see the last time you updated your client. That's because of the design of the Advanced Client. The Advanced Client is designed for scenarios where you may not be connected to the network for a long period of time. It's not going to time out and possibly automatically uninstall like the 2.0 client will if it can't connect to a CAP for 60 days. Because of that we don't expose that information to you.

The best way to find out whether or not you are communicating with your site is going to be either through the log files and looking at your PolicyAgent log file to see if it is downloading policies, that will be the best way, or using the tool like Policy Spy that I showed you. You can use the Policy Spy tool, and you can see the information; you can see the policies that have been downloaded. You can see the version of those policies. There's another spot in there where I believe you can see the cookie information, which shows you the date and time that they were last accessed, and you can see what the policies are. Policy Spy or your log files are, right now, the ways to look to see if your clients are being updated.

Then obviously, the other way would be in the SMS admin console. Your client is going to do discovery data on a continual basis, and it's going to use your Heartbeat Discovery interval, which by default is weekly. If your client is communicating with the management point on a weekly basis, the discovery data should be updated in your SMS site database. If you run one of the Web reports for discovered computers and then look at the number of days since last discovery, it should be fairly small, within a week, if you are communicating online.

Again, there are times when we expect you to be offline and not connected to your site. The design goals of the Advanced Client make it a little more challenging because we do assume you're going to have times when you're not on the network, so we're not going to report as many errors as you would with the standard client, but look at the log files, PolicyAgent in particular, to make sure that you are downloading policies, if you expect there should be some, and then use the Policy Spy tool to launch off and look at the policies that you have on the Requested tab.

Otto: I'm not exactly sure which slide we were on when this question came in, but the question is as follows: Doesn't the management point sitting in a secondary site do all the communication with the primary site? Why would it talk to the secondary site server at all?

Wally: The management point sitting at a secondary site, what its purpose is, is to be the proxy MP of the client. All client-to-management point communications will go from the Advanced Client to the secondary site's MP, which is when I need to retrieve policies, I need to check for assignments, I need to report data, I go to my secondary site's MP.

Now the secondary site MP will only go to the primary site to go up to SQL Server. It will go up to SQL Server to check on policy assignments. It will go to the SQL Server to check on policies, to retrieve policies, and also content location requests. It will go to the primary site's SQL Server to perform those functions.

However, the data reporting functions, which are going to be largest amount of data that you're going to be generating or transfer of data across the wire from the client, will go from the secondary site MP to the secondary site's server. That way the data can be batched and accumulated with all other client data, whether it's Advanced Clients or standard clients, and then passed from the secondary site server, through your sender, which have their bandwidth controls, scheduling, compression, throttling and so on, up to the primary site server for processing and addition into the SMS site database.

The secondary site there is really to remove the secondary site MP from having to talk to the primary site for everything or the Advanced Client to talk to the primary site for everything. It's only for policy assignments, policy requests, and content location. Everything else goes to the secondary site server, which then utilizes standard bandwidth control mechanisms for great bandwidth control of SMS and that data.

Otto: It looks like we've got quite a number of questions. Hopefully, we'll be able to address them all within the next 20 minutes. Can the SMS 2003 management points work properly when the IIS Lockdown utility has been used to secure an IIS Server?

Wally: We utilize the IIS Lockdown utility internally. We do our testing with the IIS Lockdown utility. I have not heard of any issues with it at all. We are utilizing it. If there are any issues, we'll obviously work through them to make sure that you can lock down your IIS Servers, because we know that we're placing a good deal of reliance on IIS in SMS 2003. We want to make sure that you can have a secure environment. Yes, we are working with that internally and it does work.

Otto: Is there a URL you can point us to where we can get samples of these logon scripts for the Advanced Client?

Wally: No. There isn't. We haven't published anything that I've seen so far. I can tell you exactly what my logon script is on my server because I have my server with me. It's a very, very simple logon script. It's not difficult at all. I'm just launching off Capinst.

What you have to do is, you have to take the Capinst utility, Client.msi, and if you want to install standard clients, SMSMan as well. You can pull those from your site server installation or your management point installation, pull those off and put them in the Netlogon share. Then I created a batch file, which my batch file is simply a single command. I'll give you the syntax: %0\..\capinst.exe. If you just run Capinst.exe from your Netlogon share, that will kick off finding a server locator point and then kicking off your installation of your client.

By default, right now in the beta, Capinst installs the standard client. If you wanted to install the Advanced Client, you need to throw a command-line switch on there. The command-line switch is /mobile. If you remember from previous WebCasts, Mobile Client was the former name of the Advanced Client. If you run %0\..\capinst.exe /mobile, that will kick off the installation of the Advanced Client using a logon script. You can also, in your logon script, just put in msiexec /i client.msi, whatever your path is, and run it that way, if you wish, but this is more of an automated method. It does an automated discovery process, assigns me the site code, and then installs the client.

For the release of the product we will document how to install the client, and we'll give you sample scripts in there. If you want to use another option, instead of mobile, you can use /autodetect. If you put /autodetect: in the script name, we'll look at the results of your script and if the script results of the exit code return code is a 0, we'll deploy the standard client. If the exit code is a 1, we'll deploy the Advanced Client. The script could be calling for the operating system or it could be calling for chassis or determining that you have a laptop. We'll have some sample scripts in there for you, but that would be an example of a logon script, the one I use whenever I do demonstrations of the Advanced Client installation.

Otto: Can you briefly discuss what BITS are? What that stands for?

Wally: That was back on one of slides, I don't remember which one, one of the first few slides, Background Intelligent Transfer Service. It's part of the operating system. It was slide 4. Background Intelligent Transfer Service comes as part of the operating system. It's a function of the OS that allows you to manage your bandwidth connectivity requirements. We happen to use that for the Advanced Client to give you the capabilities of doing checkpoint restarts, connecting up over multiple connection periods, being bandwidth sensitive and backing off when BITS is using the wire and now the user wants to use the wire for something else. Basically, that's what it is, but it's part of the OS. We just happen to require it, so you can download and get those great bandwidth management capabilities with the Advanced Client.

Bill: The cool thing about BITS is that it's based 100 percent on HTTP standards. It's really just based on a series of ACKs and the ability to hand off small components of acknowledgement packets using HTTP. It's a technology we've been using at windowsupdate.com for quite a long time now that allows us to handle, let's see, August I think we had 160 million downloads in the month of August from windowsupdate.com, all with an average connection speed of about 56 Kbps or less.

It's really optimized to that HTTP-based communication and, as Wally said, it's not only just HTTP standard, but it's an API set that we then wrapped around it in the Windows XP operating system to allow a client like SMS to have more control over that particular infrastructure. Now what we've done is, we've back-ported it back to Windows 2000 as well, so all the behavior in the Advanced Client is leveraging these "best of breed" HTTP standards for their communication protocols. Then we wrapped an API set that's defined in XP, so that we can do more with the controlling mechanisms, so that the SMS client can be aware of that particular process as it goes on.

Otto: In the SMS 2.0 Value Pack, there was a tool named Capman to install an SMS client without having SMS login points. In the latest Feature Packs, it doesn't seem to be there any more. Why is this, and how should I install an SMS 2.0 client in an enterprise environment without the possibility to access every DC? I'm wondering how we can relate this to the new version I suppose.

Wally: We'll just answer it the way it is. The SMS 2.0 Value Pack you're talking about was a prerelease version to give you some exposure to the tools. That was not a guarantee that every tool was going to be in the initial Feature Packs when they were released.

When you saw Capman, it was a prerelease version of the tool. That's something that we are planning on releasing. We're still working on coming up to the release vehicle for that, but it was not intended, and it was never scheduled to be in the initial release of the Value Pack, which turned into the Feature Packs.

It's not in the initial Feature Packs; that is correct. Why? It's because it wasn't intended to be in the first release. There are a lot tools in there. There were, I don't know, 25 or 30 tools in the initial release, and you see in the two Value Packs that were released there are fewer than 10 tools total between the two.

What we did is, we wanted to get out the tools that were going to be the biggest help in the shortest time frame to solve the biggest needs of our customers, which the biggest thing was "I need to manage patches, so I need to have some way of managing my patches in my environment because there are too many. I've got SUS and I've got Windows Update, but I also have SMS here as well. What do I do?" We came out with this SUS Feature Pack to give you that ability of using SMS to give you great capabilities of managing your patch deployment and analysis using the Web reporting tool that's been updated and the add-in Web reports, as well as the Patch Distribution Wizard, and the scan tools. We wanted to get that out as soon as possible to solve an immediate need.

We understand that logon points are something you don't want. That's why we got rid of them in SMS 2003, but currently you still do have to have logon points to install your clients, unless you happen to be in an environment where you have NT 4.0 and higher boxes. If so, then you can use what we call NT Push or the SMS 2.0 client installation method, the standard client push installation method. You can use that to push out to your clients, and there are utilities you'll find in the Resource Kit, and PSS has written some to let you automatically generate CCRs, which is the ticket we use to push out the client installs, so there is that.

Capman is something that will be released at some point in time, we're hoping. Right now, we're going through analysis of what we're going to do with all the rest of the tools, what type of time frame we can get them out, what kind of release vehicle we're going to have to get them out, but for today it is still logon points or the push installation method.

Otto: Regarding the repair option in SMS 2003, in version 2.0 it was hard to fix hardware inventory agents. The only good way I was able to figure out was uninstalling and reinstalling the client. Does the repair option in 2003 fix this kind of problem without having to uninstall and reinstall clients, etc.?

Wally: If you're talking about for standard clients, the code is essentially the same. The SMS 2003 standard client code is essentially the same as the SMS 2.0 client. There are bug fixes and the CCIM interval has changed and a couple of things in software distribution, but for the most part, it's the same code. If there was a problem there, if it was filed as a bug, then that would be something that would have a possibility of being fixed. If there was an issue there that we weren't aware of, if it wasn't filed as a bug, then no, it wouldn't have been fixed. That would be for standard clients.

For Advanced Client, it is totally new code, total new technology, and there is a repair option on the Systems Management program. My understanding is that repair option, which is on the Components tab, does do a very good job of repairing, primarily because this is Windows Installer–based. You're installing through Windows Installer, so you have the capabilities of Windows Installer doing repairs. It's not the same type of repair, but you have the capability, because it is Windows Installer files. My understanding is that does work well.

You also have fewer components in the Advanced Client. For example, there is a single agent that does everything for hardware inventory, software inventory, and discovery. The new agent has been rewritten, and it's much more effective than it used to be in the 2.0 time frame.

Otto: Any preliminary estimates on the number of clients a management point could handle? How would we decide whether a management point should be installed on a primary site server or if it should be split to a separate one?

Wally: I have not heard any updates yet. I know we're going through scalability testing, but it's really hard to get good valid data because in beta time frame the code hasn't been optimized yet. It hasn't been performance tweaked yet. We're still adding in pieces to the code and so on, so it's really hard to get valid numbers that are going to be good for you for RTM. We are doing scalability testing. I've just not heard any numbers there. I've heard rumor numbers, but nothing I'm going to say here because I'm being taped. I won't subject myself to that, but it looks like there are really good capabilities for the number of clients being assigned to a management point, so that you can have larger sites than you may have had the capabilities of in SMS 2.0.

As far as segmenting your management point for your primary site server, that would be a recommendation in all cases. Unless you have a really beefy box, you always want to segment as many processes as possible, so that every component has maximum capability for effective processing. In most cases, we would recommend that you do separate your management point function from the site server itself as well, as well as server locator point, as well as distribution point, as well as client access point, and so on.

Otto: Can you specify specific hours when advertisements can run, for example, in the off hours?

Wally: No. That is not currently a part of SMS 2003. It has gone back and forth a few times, but as of today, last I heard, it is not part of the product.

Otto: Is local cache for program downloads a site-wide setting or can each client or advertisement requirement change that size?

Wally: The size is a client-by-client configuration. Each client can have a different cache size on it, so that you can configure cache size on individual clients. It's not a site-wide setting. There's a default setting, but you can change that default on the command line on any single client that you install. If you go through the Windows Installer administrative share, you can set it there as a new default value.

One of the nice things is, if you're deploying a package, let's say Office XP, that's 623 MB as we saw before, and your default cache size, if you remember, is only 250 MB, we'll pop up with a message saying, "Your cache is too small. I can't deploy your application." You can directly go to the Systems Management properties in the Advanced tab and change your cache size, provided you're an admin, and change that and then just rerun that program, and it will kick off the download.

If you're not an admin, we will have scripting capabilities for you so that you can send that out as a script using SMS software distribution or using WMI remotely, if you wish to, to modify that parameter on an individual basis or as a site-wide basis, but again, it's not a site-wide configuration parameter. It's an individual client parameter. There just happens to be a default of 250 MB.

Otto: For package distribution over a 56 Kbps connection, what would you recommend as the maximum size or limitation?

Wally: You certainly want to be using the Advanced Client. You don't really want to do a software distribution over a 56 Kbps connection with the standard client because it does not have checkpoint restart. It doesn't have the BITS availability for controlling your bandwidth and managing it. In an Advanced Client scenario where you would be using BITS as your download-and-execute model, then there is not really a limit. It's just how long you want to wait for the bits to be downloaded and bits being the bits of the package, not the bits being the piece of code, the portions of that package being downloaded down to your local cache before it kicks off.

We have no problem, where it could be weeks to download over multiple periods, and we will manage that for you, so that's certainly a possibility. I've not seen anything where there's a recommended maximum size or a limitation at all. It is purely how long do you want to wait? How long are you going to be connected at any point in time? How many connection periods is it going to take to get that downloaded to your cache, so that the package is available to the client to be executed?

Otto: Will the Advanced Client be able to communicate securely with a management point across the Internet if the client is not on the company network and the assigned management point is placed in a DMZ, or is this not possible because Active Directory is not accessible via the Internet?

Wally: We do require either Active Directory with the schema extensions or WINS to be available for us to initially find the management point. We do need that to be able to find our management point. Every time the client starts up it's going to go out there and try to find that management point through one of those two methods, either through WINS or through Active Directory with the schema extensions for SMS. You would have to have one of those two to find your management point.

Once we found your management point, then we can communicate through the management point through HTTP. For BITS downloads it does use port 80. For just standard policy assignment requests, I believe it's a random port. I don't believe it is port 80; but through policy downloads and data uploads it is through BITS, which is port 80 that we're using. You can just open up that port through your firewall and you would be able to communicate with your management point.

The key, as you state there, would be the ability of finding your management point initially to be able to then communicate with it, but the communications would be through BITS primarily and HTTP. As long as you have those ports available, then you should be able to communicate fine once you've found what the management point is.

Otto: When moving to a very remote site in the hierarchy that's still within the hierarchy, are you regional roaming there or are you global roaming?

Wally: If you're moving to a child site of the assigned site, no matter if it's a grandchild, a great-grandchild, a great-great-grandchild, as long you're underneath or in the same hierarchy as the assigned site, it's considered regional roaming. Once you go outside the assigned site's hierarchy to a parent site, to a parallel site, a sibling site, or someplace totally outside the current SMS hierarchy, then it's considered global roaming. Regional roaming, any time you're underneath the assigned site it is considered regional roaming.

Otto: Under the Systems Management applet, are you still able to "refresh" and "start component" as you did in version 2.0?

Wally: On the Advanced Client Systems Management program refresh being the refresh in the display, there is not a refresh option in the display. Let's say you're looking at the Components tab and you see that a component says it's installed. You force policy download. You would have to exit the Systems Management Control Panel applet and then open it back up, to be able to see the component change from "Installed" to "Enabled."

As far as start component, there is an Actions tab, where on the Actions tab you can force discovery cycle, hardware inventory cycle, software inventory cycle, file collection for software inventory, machine policy downloads, and user policy downloads. We're also going to be adding actions for software metering to force download of rules as well as upload data. There is an Actions tab, which is the equivalent to the start component that you're talking about from SMS 2.0.

Otto: Is there going to be extended troubleshooting available in the SMS 2003 Resource Kit?

Wally: There is going to be a troubleshooting guide in the documentation that will come with SMS 2003 or will be made available on the Web site. The user assistance group and user education group is doing great work on the documentation. The stuff you have in beta is a preview of it. It's not complete, but there is a lot of work being done there.

One of the documents they are planning on creating is a troubleshooting document. There will be a troubleshooting document that will give you great information on troubleshooting your SMS 2003 environment, whether it's the Advanced Client or just the site server itself. If you look at the beta, there is a troubleshooting guide in there right now. I don't know how complete it is or if it's been updated, but it's there in the online library with the SMS 2003 beta.

Otto: Currently it looks like we only have a couple of minutes open here for the live event. Unfortunately, we're not going to be able to get to all of the questions that were submitted today. Hopefully, we'll be able to get some information offline. The final question I'm going to bring up today here: Is the SMS 2003 version of SMS Trace backwards compatible with the 2.0 log files?

Wally: Yes. You can use the updated SMS Trace with the SMS 2.0 log files or the log files and the standard client. You can also use the log files on the site server. Yes, it is backward compatible. It's just been modified to support the Advanced Client features on its log files.

It looks like Wally talked too long during the presentation. I apologize. It looks like Wally has a lot of work to do on follow-up questions. You may not get your answers today, but you'll get them.

Otto: Yes. With that, I'm going to go ahead and wrap up the session here. I definitely wanted to thank everyone for joining us. I hope that the information was helpful to you. I certainly wanted to thank Wally and Bill for coming out, giving us a great presentation, and helping out with the Q&A here.

If you'd like to give us any kind of feedback at all about the shows, about today's event, about upcoming events, stuff you'd like to see, you can always send e-mail to us as well at supweb@microsoft.com.

I hope that everyone has the opportunity to tune in again soon. Thank you and have a great day.

Question: Can we preload client today on our images to use as a vehicle for deploying RTM client (especially on our dial-up systems)? This assumes we also have MSMQ enabled on the same image.

Answer: You can, but you'll still need to upgrade the client to the RTM version of the Advanced Client. It is likely that all client components will be updated for RTM, certainly the build number will change, which would most likely necessitate the reinstallation of all components. So, I'm not sure how much traffic that would save you.

Question: Will the 7 MB client MSI file be configured to allow an initial BITS download for installation on dialed up remote systems?

Answer: The Advanced Client bootstrap program does not use BITS, but does use checkpoint restart. So, if you are not able to download the entire Client.msi file in a single session, you won't have to restart the download from the beginning, but rather from where you left off in the previous attempt. We're investigating possibilities here to improve the download process.

Question: Can you manually assign a client to a site in a login script (using a command-line interface)?

Answer: If you are referring to an Advanced Client, yes. Use the SMSSITECODE=xxx parameter on the msiexec /i client.msi command line.

Question: When an Advanced client registers its DDR with the primary site database while on the LAN, how do you (or can you) distribute software to this client when it is connected thru dial up? Will it still use the information from the original DDR (for example, an IP address) as it does when you try to establish a remote control session? (Must use terminal services or remote assistant for remote control at this point.)

Answer: The IP address information is immaterial to software distribution. We target advertisements to computer names, or user accounts, not IP addresses. So, we'd advertise to a computer, for example, SMSClient, and that computer would pull down the content from a distribution point, regardless of its IP address.

Question: Where in the SMS Console are Advanced Client policies defined?

Answer: You don’t define them separately from any other SMS site settings. Whenever you configure anything in SMS 2003 that affects clients, such as client agents, schedules, advertisements, that process automatically generates the policy data in the SMS site database for Advanced Clients. We worked hard to ensure you don't have to do anything special for administration of Advanced Clients, but does allow you to do so, if you want to (for example, by using the Advanced Client tab of an advertisement, and the Roaming Boundaries tab for site properties).

Question: Is software metering in 2.0 going to be removed during the upgrade process?

Answer: No, you need to remove your software metering servers and disable the Software Metering Client Agent prior to attempting to upgrade. The Readiness Analyzer should report that as a failure (SMS 2.0 still configured for software metering) and prevent upgrade.

Question: Where can SMS obtain certificates? Do I have to have PKI integrated with Active Directory? External source? Something else?

Answer: SMS 2003 places the required certificates in Active Directory, if the schema has been extended for SMS. If not, the certificates are retrieved directly from the resource. In this case, the Advanced Client would retrieve the management point certificate directly from the MP. No special code is required, though we do recommend the Active Directory schema extensions for greater security.

Question: Will the features of the recent Feature Packs for SMS2.0 be duplicated in SMS2003?

Answer: There will be equivalent functionality in SMS 2003 for all the features of the SMS Feature Packs, either integrated into SMS 2003, or in Feature Packs for SMS 2003.

Question: Has there been any thought to supporting Remote WakeUp for various NICS? For example, to wake up clients to complete updates.

Answer: I believe that is something that we're investigating to see if we can provide a solution. In the past, the issue had been not enough enterprises were ready for the solution. More are able to support it now. There are a few third-party solutions now. I'm not sure if we'll provide something, and if so, when that will be.

Question: Has there been any thought to opening up SMS to OEM products like Dell Open Manage to support/report hardware failures or alerts?

Answer: SMS has always been open to that. We have an SDK that some vendors do use to add value to the SMS product. We are always encouraging others to extend the product to allow customers to achieve greater benefit from what we do within the core product.

Question: If a client is already remote and will not be on the network except by Remote Connection, what is recommended for getting them installed? Can the client agents be installed using BITS?

Answer: How do you go about sending them software today to install? For example, if a service pack comes out for the OS, how do you update the remote clients? Or when a new version of Office is available, how are the clients updated now? You could send them a CD with the Client.msi file, and have a script on it that would run when they insert the CD. Or any other method you use today for other applications. The Advanced Client Push Installation method will allow the pulling down of the Client.msi file over multiple connection attempts (checkpoint restart), but it does not use BITS, so there are no bandwidth controls with it.

Question: Regarding the Temporary Download Cache folder — will source files automatically be removed after successful installation?

Answer: Not immediately. We leave them for a period of time (30 days by default) if they are needed again. If the space is required before they are automatically removed, we can remove them if they are not in use, or you can force them to be deleted using the Systems Management Program (Advanced tab).

Question: Are there any scalability numbers for management points and/or site server? We have over 100,000 clients and we need some general estimate to work towards.

Answer: Not yet, but we are working on it. It's very hard to produce numbers that will be valid for RTM code when we're still in a beta release, and the code is not yet complete (features and functions are still being added) or had any performance optimizations implemented. We do expect to be able to support much larger sites (in terms of the number of clients) than you could with SMS 2.0. Look for more scalability data as we get closer to the release candidate cycle.

Question: How can you use Policy Spy to apply a policy remotely?

Answer: You can use Policy Spy to connect to a remote computer and view the policies that have been implemented locally. However, Policy Spy does not allow you to force the download or evaluation of policies remotely. You could do so through scripting however. We will have an SDK available for the Advanced Client with sample scripts.

Question: Is MSMQ removed as a requirement for the Management Point?

Answer: For beta — yes, for later builds — no. Certainly not for RTM.

Question: I'm curious to see what processor load the Advanced Clients put on a pc. Any ideas?

Answer: My clients are Pentium II 366-MHz systems with 256 MB of RAM. I have not noticed any performance issues with the client installed. We are still in the beta stage, so there is always potential for performance issues. Certainly very low-end CPU and RAM systems would be affected, but any current hardware platforms should not be greatly affected.

Question: Is there any way to troubleshoot whether or not an SLP is published in Active Directory? When I check my ClientLocation.log file, it reports "LSGetAssignedSiteFromSLP: Unable to get the list of SLPs."

Answer: If you start Active Directory Users and Computers, and enable Advanced Features (on the View menu), you can see it. Expand the domain, expand System, and then click System Management. In the details pane, you should see a registration record that would be something like SMS-SLP-sitecode-computername. That is your SLP registration in Active Directory. This does require the SMS Active Directory schema extensions. You can also check the Sitecomp.log file to see if Site Component Manager was able to publish the SLP in Active Directory after installation. We do not automatically publish the SLP in WINS; you would have to do that manually.

Question: Will we have to uninstall SMS 2.0 first to install SMS 2003?

Answer: No, you don't have to remove it. There will be an option to upgrade from SMS 2.0 to SMS 2003. I did a WebCast on that back in April of this year (April 16, 2002) that discussed deployment of SMS 2003, and included a section on upgrading SMS 2.0 to SMS 2003. You might want to view the archive for additional information.

Question: Do we have to uninstall the standard client to install the Advanced Client or does the Advanced Client just install over the standard client?

Answer: The Advanced Client will automatically force a deinstall of the standard client prior to the installation of the Advanced Client. You don't need to manually deinstall it.

Question: Is it possible to install SMS 2003 beta separate from SMS 2.0?

Answer: Certainly. Just install it with a unique SMS site code, and we'll take care of the rest. You can also make the SMS 2.0 site a child site of the SMS 2003 site if you wish. Of course, you should be doing all your testing in a test lab, as putting the beta product in a production environment is only supported for the members of the Early Adopter Program.

Question: You mentioned the availability of the CCMTools. Where can they be found? Are they available with the downloaded version of the beta?

Answer: The CCMTool.msi program is in the SMSSetup\Tools folder of the SMS 2003 beta CD. I assume that is also available in the downloaded version, but I've not downloaded it from the Web site, just from local servers.

Question: Is there an automated way to install MSMQ? Do I need to install it as a Dependent client or Independent client or doesn't it matter?

Answer: You can do so in your OS installation, but not necessarily with SMS 2003. If we find MSMQ is not installed, we will try to install it. But that requires the availability of the Windows source files. We do require independent mode, but it doesn't matter whether or not you are Active Directory integrated.

Question: With the increased functionality offered by other Microsoft products (for example, Full Outlook 11 access over HTTPS), our mobile users will tend to connect only using this means (and not through our VPN). Is there any development being done to offer similar management for SMS clients via a "front-end" that uses HTTPS?

Answer: That is something that we are investigating for the future.

Question: Any updated information concerning process changes to the introduction of SMS 2003 into the production SMS 2.0 environment?

Answer: I'm not sure what information you have now, so I can't state what would be considered updated. The general rules are: SMS 2003 can interoperate with SMS 2.0, provided that SMS 2.0 is a child site to SMS 2003 (never a parent of SMS 2003), the SMS 2.0 site is SP4 or later for interoperability, the SMS 2003 admin console can administer the SMS 2.0 child site settings, except for software metering and Crystal Reports, and can't admin any SMS 1.2 child sites. That's about all I can think of.

Question: Can the download of a package, where it is set to download before install, be mandatory so that the user cannot cancel?

Answer: Sure. Just make the advertisement mandatory (or assigned) as you normally would. And then configure the Advanced Client tab as appropriate. If it is not an advertisement that the user has any interaction with, it will download and then run automatically at the assigned time.

Question: If clients are using HTTP to communicate to the site server or MP, does it use the temp Internet file folder? If it does, what if the client clears the temp internet folders; so that means the client pending distribution is gone.

Answer: Program downloads go directly to the cache folder, which defaults to Winnt\System32\Ccm\Cache (but can be moved). So, any clearing of Internet Explorer temporary folders would not have any affect on the programs that are in process of being downloaded.

Question: Currently in SMS 2.0, I throttle bandwidth and schedule site-to-site communications. Did I understand Wally correctly, in that SMS 2003 removes the ability to schedule activity?

Answer: No, that is not the case at all. I hope I didn't say that, or that what I said didn't come across that way. The sender bandwidth throttling features you know from SMS 2.0 are still there in SMS 2003. I'm guessing I was talking about other traffic that does not use senders, and that traffic is not bandwidth throttled, scheduled, compressed, and so on. The address schedules and throttling features are still part of SMS 2003.