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

Microsoft Support WebCast

Microsoft Systems Management Server 2.0 Value Pack:
Introduction to New Tools and Functionalities

March 29, 2002

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

Bruce Jones: Welcome to this preview of the SMS 2.0 Value Pack. Although most of the tools and solutions aren't released yet, some of you may have obtained one or more of the beta forms of these tools through MCS, your designated Alliance Support Professional, or through Enterprise Support PSS. Today I am going to give you a preview of what to expect when these tools release.

First (slide 2) we're going to answer the question, what is the Value Pack? Then we're going to take a whirlwind tour of the tools and solutions in the Value Pack with some screen shots. I want to remind you that at this point most of these tools are beta, and some of the screens that you see today may be slightly different in the released version. Then we'll take a look at availability; how and when will you be able to get the Value Pack.

Let's start with what is the Value Pack (slide 3)? The Value Pack is a response to your needs. At many of the conferences like TechEd or the SMS Users Conference, which is now called the Microsoft Management Summit, or maybe through the Early Adopter Program and through your calls to support, you have let us know that there are some minor changes that could make a huge difference to your everyday experience with SMS. Things like if there were just a way to take the settings from one site and apply them to all my sites, or if there were just a way to change the password of my SMS service account for all my sites at the same time.

Many of the things that you have asked for can be done without re-architecting the whole product, and can be done with an add-on tool. In fact the SMS SDK makes much of this very scriptable. And there are a lot of scripts floating around now that do some of these things, but therein is also the problem for you. Many of you require that the tools that you use be supported by Microsoft. So the Value Pack provides this kind of benefit, minor improvements to administrative tools, some minor adjustments to features through add-on tools, and the tools are supported by Microsoft.

The Value Pack is more than just tools, however. How many of you started using SMS with a new urgency when Nimda or Code Red hit? Well, with a little work SMS is the perfect solution for these kinds of urgent problems that revolve around inventory and software distribution. So the Value Pack will also provide common solutions to urgent problems such as new patch management capabilities, as we're going to see later.

Finally, you have a need to manage and support new technologies such as Windows® CE devices. The Value Pack is a way to get some of those new technologies managed by SMS in a timely way. So the Value Pack is a response to your needs in these areas. Let's get more specific and look at the contents of the Value Pack.

The Value Pack consists of some new simple focused administrative tools (slide 4). Some of these are menu extensions, so you would right-click a collection, a site, or a query and the tool will be there. Some involve new MOFs, wrapper files, or DLLs that allow some slight change to functionality. Some are completely new solutions. An example that you might be familiar with is Web Reporting, which is a Value Pack tool. You might be thinking about Topaz. Well, most if not all of these tools should be compatible.

Let's address the problem of supportability (slide 5). What will Enterprise Support or PSS say if there's a problem with one of these tools? Are they supported? Well, these tools will be fully supported when we release them to the Web (RTW). We'll be able to file bugs against them if necessary. It will be covered by your SMS 2.0 license, and again they will be individually released to the Web just the way Web Reporting was.

Now before we look at the tools themselves, I want to restate that this is a preview of the tools. If you do have one of the unreleased beta copies, as with any other beta product, they are not supported in production, and we cannot escalate issues for you. You can, however, give feedback through your MCS contact, your Alliance Support Professional, or your Technical Account Manager. Support starts when they release to the Web.

Let's take a look at the categories of tools and solutions in the Value Pack (slide 6). There are over 20 tools currently, so I've divided them up into some categories: site administration tools; software distribution and installation tools; patch management solutions — wouldn't it be great if you can manage hotfixes automatically with SMS — we're going to look at that; and inventory extensions — this would be like adding Windows CE devices to inventory.

Let's take a look and see what the site administration tools are like (slide 7). Here's a list of the tools that we're going to look at today: Transfer Site Settings, Manage Site Accounts, Manage Site Distribution Points, Create/Update Site Address, Create Secondary Site, Show Query Count, the Repair Wizard, Granular Client Deployment, the Client Preload tool, Delete Clones, and of course Web Reporting.

Some of these are wizards, some have command-line capability. Let's start with something that many of you have requested, the Transfer Site Settings tool, which is on our next slide (slide 8).

The purpose of the Transfer Site Settings tool is to be able to take all or some of the settings from one site and transfer them through a tool to one, several, or all of your other sites. Recently a customer sent a question in to us in Enterprise Support. He said, "I have a huge number of sites and I want to have my Network Discovery settings all like my central site. How can I do that through a script or something? I don't want to have to go to each site and make those changes."

Well the answer is the Transfer Site Settings tool. This is a menu extension, that means we right-click on the site and a wizard pops up and walks you through the process. Or if you prefer, there's a command-line interface and an XML template file to store your settings. Status messages track the changes, and you have very flexible targeting. You can transfer all or some settings to all or some sites.

Now that we can manage site settings in a centralized manner, what about site accounts? Wouldn't it be great if we could manage the SMS service account or other accounts in a similar way? That is a great idea, and that's what the Manage Site Accounts tool is, on our next slide (slide 9).

The purpose of this tool is to centrally mange SMS accounts. The screen shot is from the wizard that pops up when you start this tool from the SMS Administrator console. Look at the slide for a minute. Notice that in my hierarchy I have two sites, CEN, which is my central site, and AME, which is my child site. Now this could easily be 20 sites or 50 sites, but they haven't given me that many machines yet, so it's 2.

I can multi-select the SMS service account for both my AME site and my CEN site. What this will do is allow me to manage an account shared by both of those sites at the same time. Now look at the command buttons on the right. I have some options now. I can create new accounts and passwords for both my CEN and AME sites at the same time, or I can set the passwords on existing ones. I can verify them; I can make sure they're all valid accounts. I can delete them; I can save the list to a text file.

I can also do all this from a command line if I want to use a script. I can add, set, delete, or verify the accounts and passwords from a script. Now you may be thinking to yourself at this point, what about these accounts and passwords going out over the network in clear text? My security people won't let me do that. Later on, there's a slide that shows you one of these tools running, and it shows you how it encrypts the account information.

Well, we've seen that we can use this tool to centrally manage site accounts. Let's move on to managing packages on distribution points (slide 10). Have you ever wished that you could add, delete, or update a package on a distribution point from a script? Maybe you have some time-sensitive packages. Maybe you want to update packages on your distribution points just a few at a time. With this tool you can update, add, or delete packages on specified distribution points.

Look at the syntax. You can specify a server or a share, the package, and the distribution point. Look at the first line of syntax. That would update one package at one site on one distribution point. You can also use wild cards. Look at the last line. What that would do is update all packages on all distribution points at this site and all child sites. You might get a phone call or two if you aren't careful. This tool gives you great flexibility to manage packages on distribution points.

Let's take a look at creating site addresses (slide 11). With this tool you can script the creation of site addresses and their accounts. This is the output from an address that I created on my site. Notice in the first line that the account and the password are typed in. Now I changed it on the slide so you're not going to be able to hack my computer, but what about that with these tools? Do they pass accounts and passwords over the network?

Look at the third line from the bottom. Notice it says "Encrypting Account Information." The site address tool will allow you to add or update site addresses and accounts in a secure manner from a command line. The same care for security was given to all the Value Pack tools. The next tool has a similar feel and is called Create Secondary Site (slide 12).

Have you ever wished you could create a secondary site completely from a command line? I'll give you just a few seconds to look at the slide, which shows this utility starting to create a secondary site in my hierarchy, and then we'll move on.

I heard a customer ask for the next tool (slide 13) at the SMS Users Conference, again which is now the Microsoft Management Summit, and it's called the Show Query Count. Let's take a look at that tool.

The customer stood up and said, "I need to have a way to have a count on a query without creating collections. If I create collections then I have to explain to everyone when they show up at all the child sites, plus it creates more overhead for Collection Evaluator." Well the answer to this customer's problem is the Show Query Count tool. Right-click on the query, select Show Count, and a dialog box appears with the count.

The next slide (slide 14) shows us a tool that you have all been anticipating, the Repair Wizard. I believe it was at the same users conference that a customer stood up and told a story. He said this: "I came in to work one Monday morning and one of my site servers was missing, not just from the admin console, but it was physically gone, the box wasn't on the rack. The Internet team, it seems, needed a new, hot Web server over the weekend and figured we wouldn't miss one SMS site server."

Well he went on with the story and he told about how he started to do a recovery on the site server and got to the point where he needed to connect to the Microsoft Web site for the SMS 2.0 Recovery Expert (http://www.microsoft.com/smserver/techinfo/administration/20/recovery/default.asp), so he could walk through the process of doing the restore. Then he realized he didn't have Internet access from that room.

Well, look at the screen shot. Notice now that you can right-click on the site and select the Site Repair option. This launches a wizard that is installed right on your machine —no more Internet access is required; and furthermore, many of the tasks that you had to do manually now are fully automated. For the sake of time we're not going to go over them, but I think this new Repair Wizard is really pretty exciting.

Let's move on to the Granular Client Deployment tool (slide 15). Have you ever wished that you could just right-click a machine discovery record and force a client installation? Well, now you can with the Granular Client Deployment tool. You can do this on just one machine or all machines in a collection. If you look at the screen shot, you can see that I'm installing the SMS client on my All Systems collection. You might want to be more granular.

When this runs, this Ccm.log shows that the client install is attempted no matter what. It will say this is a forced CCR; SMS will not check the CCIM state on the client before proceeding. Now it's not an instant install, there's a bit of a delay until the CCR processes. It can be a few minutes, but after the CCR processes, the client will install.

The de-install uses Windows Management Instrumentation (WMI); it makes a remote connect to the machine to start the de-installation. Now I could see how this would be really helpful for deploying the SMS client in stages, or to help your help desk fix an individual client.

Let's move on the Client Preload tool (slide 16). How many of you have tried to figure out how to preload the SMS client on your dial-in laptops, and even then you could only preload the core components? How many of you have struggled with making sure your images didn't generate duplicate GUIDs? Well, the purpose of this tool is to create an SMS client preload image of the core and the optional components using SMS installer.

How easy is this? Well, let's pretend for a moment that I'm going to walk you through it over the phone. Our conversation would go something like this. "Okay, open CliStage-v20.ipf file installer. Do you have it? Okay, good. Now map the drive to your SMS_site code share. Do you have that done? Okay. Now that you have it, go back to installer and look on the menu. Select Build and then select Compile. What do you see? Oh, you see the dialog, good. Now enter the path to your site server from the mapping that we just did. That will make sure we get those hotfixes that are already applied to your site. Okay, click Next. Now enter the service pack number you want, that's SP3 for you, right? Okay, click Next. Select 409 for English. Click Next. Okay, is it compiling? Great. That's it."

"Now you might want make sure you read the release notes. Do you see the command-line options that determine how you can install different optional components and so on? Good. Now figure out the syntax you want and just run that executable on your laptop and you have your preload. Okay, well to activate that client, you need to use just one of the normal installation methods, like running SMSman or SMS.bat or Windows NT® remote installation. Thank you for calling support."

Well, let's take a look at some of the other features of this tool. It's compatible with Remote Installation Services (RIS) or other images. It's distributable for dial-in computers. It includes the core and the specified optional components. No network connection is required; you can mail a CD to your people to have them install it on their laptops. You can include the service pack and QFE fixes. There's no GUID generated, and if there is one, you can select an option to remove the existing one.

Now when this preloads the client on to the machine, you still need to initialize it or make it an active client. In that first initialization, there's about 1.3 MB of traffic that occurs over the network, and that takes about 10 minutes on a 28.8-Kbps modem connection.

Well, what if someone imaged your SMS client in an unsupported way, what might you get? Duplicate GUIDs — and that brings us to our next tool (slide 17), which is the Delete Clones tool. It's an automated solution to handle duplicate GUIDs.

It works using a SQL Server™ stored procedure on the service side to detect clones. It automatically distributes NewUID. It automatically cleans duplicate GUIDs out of the database. Now if you aren't familiar with the duplicate GUID problem, I'll refer you to the white paper currently on the Web, "Managing Duplicate SMS Unique Identifiers" (http://www.microsoft.com/smserver/techinfo/administration/20/maintaining/newuid.asp). That solution requires a bit of manual work on your part. This solution is automated and goes beyond that white paper. I strongly encourage you to test this when it's released.

Our next tool is Web Reporting (slide 18). Web Reporting has been released for a while (http://www.microsoft.com/smserver/downloads/20/tools/webreport.asp), and many of you are using it and you know just how great this solution is. There's a WebCast on it from last May, so I'm just going to give you the link here to that WebCast (http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com/servicedesks/webcasts/wc051701/wcblurb051701.asp) and encourage you to try this out if you haven't.

Well, that's the last of the tools and solutions in the site administration category. I want to move on now to the tools and solutions that have to do with software distribution on our next slide (slide 19).

Currently there are three tools in the software distribution category, Check Available Programs, the Advertisement DLL, and the Elevated Rights Deployment Wrapper. Have you ever sent an advertisement out to a test machine and you know your offer file is sitting on the CAP, and you're just sitting there staring at your monitor waiting for the client to check the CAP for new offers? Well if you have done testing where you have to wait for your client to poll for offers, then this next slide is for you.

With Check Available Programs (slide 20), you can right-click a machine or right-click a collection, select Check Available Programs, and it will force the client to check for advertisements right away instead of having to wait for that polling cycle. This tool uses WMI, and as the dialog box in your screen shot shows, it may take a few minutes if you're selecting a collection with multiple machines.

Our next slide (slide 21) shows us the Advertisement DLL. Many of you have used the SMS SDK. With a little Visual Basic script, you can do some pretty powerful things. You can create collections and packages and advertisements and so on. You can do a complete software distribution all by script, but what if you aren't a programmer? The Advertisement DLL can give you much of the same ability as the SDK, but instead of writing code, all you have to do is edit an INI file. Think of this tool as a package definition file (PDF) on steroids. If you can create or modify a PDF, you can use this tool.

Well before we go to the next tool, let me ask you a question. What will happen if you use SMS to deploy software that requires a reboot, and after the reboot, it then requires administrative rights to continue installing? What will happen? Right, the part after the reboot will fail.

The next slide (slide 22) shows us the Value Pack solution to this problem, the Elevated Rights Deployment Wrapper. By wrapper, what we mean is a program that's wrapped around another program, like an executable that calls another executable. There's a mistake on this slide down in the middle, it is not a wizard, but let's take a look at it. {Editor's note: The slide has been updated.}

The purpose of this tool is to install software using SMS that requires a reboot and continued Administrative rights after the reboot. An example of this kind of installation would be Office XP to a locked-down Windows NT 4.0 computer. How does it work?

The RunOnce wrapper executes your command line. APM then runs the program specified in the command line. The wrapper removes any RunOnce keys added by the program to a special key in SMS\RunOnce registry key. SMS will then run those programs later after the reboot with administrative rights.

Now we've covered the site administration tools and the software distribution tools. Let's move on to our next category, patch management (slide 23).

I have a number of machines at my desk and I'm always reinstalling them for some testing. I need to make sure that they have the latest service packs and the latest security patches so they won't get viruses. Now in the past I've simply set up an advertisement for the service pack and some particular hotfixes. When a new machine came up, it would run those advertisements and I'd be set.

Patch management is a more organized way of doing this with SMS. There are four solutions currently in the Value Pack. The first solution is the Microsoft Security Toolkit Import. This has to do with Internet Information Services, IIS, and Internet Explorer Patch Status. Think Internet security with this tool.

The Security Update Inventory Tool — this has to do with operating system patch status. There's the Office Update Inventory Tool — this has to do again with office patch status. Then there's the Patch Wizard — using SMS to deploy the patches.

Let's start with the Microsoft Security Toolkit Import on the next slide (slide 24). This is not the Security Toolkit. This is an import utility to help deploy the Security Toolkit with SMS. Well, we need to back up and ask, what's the Security Toolkit? Well, think Code Red or Nimda. This toolkit is designed to help provide a baseline level of security against common and dangerous threats on the Internet. It has guides, fixes, and some tools in it.

For example, Windows 2000 SP2 and the IIS security rollup fixes are in it. It's already released, and it's available as you see on this slide. Some have pointed out that Windows XP is not listed on the slide, well this is because at the current time there are no applicable fixes for Windows XP.

So what is the Security Toolkit Import tool in the Value Pack? That's the automation piece. It automates distribution and installation of the Security Toolkit. It creates queries and collections and PDF files to support the Security Toolkit. So before we can run the import tool, what has to be installed first? Right, the Security Toolkit. Then we run this MSTImport tool and it imports the objects into SMS.

Let's take a look at some of those objects. On this slide (slide 25) we see the collections that it creates. Notice on the screen shot that applying the Security Toolkit involves a number of stages. For example, Stage 1 has to do with identifying all Windows NT 4.0 servers not running SP6a. Here the import tool has created the collections for you that support each of those stages. The stages are more fully explained in the documentation.

On the next slide (slide 26) we see that the import tool has loaded a bunch of package definition files. Now the import tool did not download the actual fixes; it downloaded the package definition files. The Security Toolkit includes the actual fixes. We need to use the PDF to create the packages.

Now to do that we go to the SMS Administrator console, right-click on our Packages node, select New, then Package from definition. The wizard starts, and the next screen of the wizard is what you see here in the screen shot, the package definitions. Later in this wizard, we'll select a Security Toolkit source directory for your particular fix or tool. Then you will advertise your new package to the appropriate collection. The advertisement runs on the client and we get some pretty interesting results, as we see here on the next slide (slide 27).

Take a look at the screen shot. This is Resource Explorer hardware inventory for one of my machines. Do you see the new class on the left called QFE Update? Now here's the data returned showing that a security tool ran or a fix was installed on my machine. Now look at the first item in the description column. Can you guess what this is?

Well one of the tools from the toolkit is called Iedetect. It detects the version of Internet Explorer; 6.0.2600.0000 means it detected that I have Internet Explorer 6 installed on this machine. Now the QFE update class in my SMS database will show me the tools and fix results related to the Security Toolkit for reporting and for targeting.

Well, we've looked at patch management from a Nimda or Code Red standpoint, or an Internet security standpoint. We can use the import tool to import queries, collections, and PDF files to support the Security Toolkit. Well, what about fixes that aren't related specifically to Internet security? What if we wanted to use SMS to manage other kinds of security fixes for the operating system?

That brings us to the Security Update Inventory Tool (slide 28). The Security Update Inventory Tool automates scanning and inventorying the systems listed on the slide. It scans for recommended security bulletin updates. Now notice on this slide Windows XP is included.

Double-click on this executable and a wizard starts. The wizard walks you through downloading the HFNetChk scan agent and the current list of Microsoft security bulletins from our Web site. Are you familiar with HFNetChk, that scan agent? I'll give you a KB article on it in a few minutes.

The wizard starts and it gives you some options for creating packages and collections and programs and advertisements. When the advertisement actually runs on the client, it runs the scan agent on your target machines, and that scan agent looks for the presence of hotfixes related to a specific security bulletin. You'll then get a new class in hardware inventory, the Software Patch States class, and it will include a type called Security, or the security bulletin scan results. You'll see this in a minute. Of course this is integrated with Web Reporting.

To help us understand this tool, let's take a look at the package and programs that the wizard helps you create (slide 29). Here is our new package on the left side of our screen shot. Notice I've selected the Programs, and we have three programs on the right. If you understand what the top and the bottom programs do, you'll understand this tool. If you understand what the Security Update Inventory Tool program is on the top and how it's different from the synchronization program on the bottom, you'll understand this tool.

Let's start with the bottom program, the synchronization tool. What is it that needs to be synchronized? When you first install this tool you download a list of the current security bulletins from our Web site. Now are we downloading the actual fixes or just the list of fixes? Right, just the list. Well, we're always adding new security bulletins, so a week or two goes by since you first downloaded the list; what needs to be synchronized? The answer is the list of security bulletins.

Well, does this need to happen on all machines or just in one place? It just needs to happen in one place, the package source. By default, this program runs once a week, on just one machine, to pull down a list of the latest security bulletins. Now you can configure some of that. So how many machines run the synchronization program? Right, just one.

Now let's move to the program at the top. This program is the one that runs on all your machines. This is the one that runs the scan agent. Now how does the scan agent know what to scan for? It uses the list of security bulletins that you downloaded from the synchronization package, and the information ends up in hardware inventory.

Well what is that expedited program in the middle? If you choose that option, it kicks in immediate hardware inventory, otherwise we wait for the next inventory cycle to push the information up.

So let's say that we're in our lab and we ran our scan agent on our machine using the program on the top. We waited and realized that we needed to have an inventory cycle, so we sent it again, only this time we used the expedited program to force an immediate inventory cycle. What will we see in inventory as a result? Let's take a look at the next slide (slide 30).

Look at the screen shot. On the left, we see the new hardware inventory class, Software Patch States. This was created by the program we just ran. On the right we see the information gathered by the scan tool for this machine. We have the Microsoft Security Bulletin ID, the KB article Q numbers, the title, the date posted, and so on. On the far right we have an interesting area for status. You see at the bottom, we find that the fix for Microsoft security bulletin MS00-077 has been installed on this machine. Above that we see that there are some other fixes that are applicable but haven't been installed yet. "Well, I'd better do something about those, I guess."

Where can I get those fixes? Look at the first column, BinPath shows me the source path on the Microsoft Web site for this patch. Now what if we could do this for other products? What if we could do this for Office? Let's take a look at the Office Update Inventory Tool (slide 31).

The Office Update Inventory Tool does the same thing only for Office. What hotfixes are installed for Office? What hotfixes are not applied but could be? The purpose of this tool is to automate scanning and inventorying for the latest Office security bulletin update information from the Microsoft Web site. It's a wizard like the previous one. It downloads the Office Update Inventory Tool; I've given you the Knowledge Base article there about that tool, and it creates the package, the collections, the programs, and the advertisements that support it. The result is that our software patch states and hardware inventory now include a new type, Office, for the Office security bulletin scan results, and again it is integrated with Web Reporting.

On the next slide (slide 32) we see the collections that the wizard creates. Look at this screen shot. Do you see a pattern? What I wanted you to notice is that we have the same three types of collections created; the Office Update Inventory Tool creates the same three types of collections as the Security Update tool; this is because it works pretty much the same way.

On the next slide (slide 33), we see the package and programs work pretty much the same way as well. Notice on the bottom right of the screen shot, we have our weekly synchronization program. The default for this program is to run once a week. It pulls down our list of security bulletins available for Office. It synchronizes your local copy and your package source with the latest copy on our Web site. Now how many machines does this program run on? Right, only one. It updates the package source with the latest list of security bulletins.

Now at the top right of our screen shot, we have the Office Update Inventory Tool program. This is the program that runs on all the clients. When it runs, it scans for the Office patch state on each machine. It uses that list that our synchronization program pulled down for us. Now the KB article on this slide gives you details as to how this scan agent works.

Let's take a look and see what we get for a result in the database (slide 34). Look in the upper left of the screen shot. We're looking at the hardware inventory for one of my machines, and we're looking at the Software Patch States class. Now look at the right side and we see the two top rows. Those are from the Security Update tool, the previous tool. Notice the type Security. Now look at the bottom two rows. These are of the type Office, for the Office Update Inventory Tool.

Here are some results from the Office Update Inventory Tool that can now be found in the Software Patch States class. The status on the right shows Installed or Applicable. Now there's one more type, admin applicable, and this is for administrative images only, not for normal installations. So the Office Update Inventory Tool allows you to inventory the machines in your SMS sites to see what their patch state is in reference to Office, and the Security Update Inventory Tool allows you to inventory your machines to see what their patch state is in reference to the operating system. You can then target those machines with appropriate hotfixes.

Now wouldn't it be great if there were a wizard that would bundle those hotfixes up together into a single package, or into a few packages and create your advertisement for you based on this information? Well, let's look at the next slide (slide 35), because that's what the patch wizard does.

The prerequisite of course is the Software Patch States inventory must exist. If we're going to target that, it has to be in the database. The purpose is to analyze and deploy missing software patches based on that information that we gathered. It's a wizard; you right-click a collection and select Distribute Packages. The wizard runs and finds the missing patches, and you select the patches that you want to include in this package, and it downloads the patches from our Microsoft.com Download Center. You can create a package, advertisement, program, or collection; you just keep clicking Next.

So for patch management we can identify the patches needed for Internet security, the operating system, and Office. We can automatically update the patch list. We can bundle the fixes, we can distribute them to your hierarchy. And most of this can be highly automated, or you can implement just the pieces you want in a flexible way. I think this is a great suite of patch management solutions for you.

I missed a slide here (slide 36); do you see the center option on the patch wizard, it says Create a multiple-patch distribution. You can create a multiple-patch distribution with that patch wizard as well.

Let's move on to our Windows CE devices (slide 37). Do you have any Windows CE devices that you'd like to inventory? The purpose of this tool is to add your Windows CE devices into your inventory when they dock with a machine that's already an SMS client. It works through a wizard installation. You run the wizard and it creates the collection, the package, the program, the advertisement, and so on, and the program installs an agent on the host PC. Now when the Windows CE device docks with that host PC, it scans the device for hardware inventory information and includes it as part of the host PC hardware inventory.

I didn't have a Windows CE device when I made these slides, so I don't have a screen shot for you, but basically the inventory information appears as part of the host PC's hardware inventory. Currently this is hardware inventory only.

Now we've seen about 20 tools, some solve your urgent problems for site administration. Some solve your urgent problems for software distribution. We saw the patch management solutions and we saw ActiveSync®, which extends inventory to include Windows CE devices. I'm sure you're wondering by now how can you get these tools, and what's their availability? Let's take a look now at availability (slide 38).

Some of these tools have already released to the Web. This includes Web Reporting and the Microsoft Security Toolkit Import tool, which is for Internet security. The rest of the tools are in a beta phase; they're either being tested a bit further, they're getting some final tweaks done, having documentation written, that kind of thing. At the current time, the plan is to release them individually to the Web when they're ready — so continue to watch our Web site, maybe they'll be available later this summer.

Now if you have an Alliance SMS support contract, then your designated Alliance Support Professional may have already given you beta copies of these tools. If you have an MCS representative, you can get a copy through them. If you don't have Alliance or MCS, the beta forms are available through your Technical Account Manager or through Enterprise Support — PSS. Now keep in mind that beta software should only be used in a lab and is not supported. Support begins when the tool has released to the Web.

Well I hope the WebCast today has made it clear to you that the Value Pack is a group of tools, simple, focused, supported, and a group of solutions that were created with you in mind in response to the urgent needs that you've communicated to us. They will release to the Web, as two of them already have, and I want to end this part of the session encouraging you to continue to watch for these tools as they do in fact release to the Web.

Now for the question-and-answer part of this WebCast, I've asked Rob Wickham to join us. Rob is the Program Manager with responsibility for the Value Pack. As the Value Pack is mostly in beta form, some of these tools may even now be changing slightly, and Rob can help us with some of these types of questions — questions on futures and so on. Wally Mead is also with us if we need to cover anything that relates to Topaz and the Value Pack.

Well thank you for your attention, and I'd like to turn the session over to our moderator now. Jason?

Jason Bennet: Okay. Thanks for the presentation, Bruce. Just a couple of quick notes before we move on to the Q&A portion of the Support WebCast: The Q&A portion of the Support WebCast is intended to encourage further discussion of the Support WebCast topic. One-on-one product support issues are outside the scope of the Support WebCast. If you need technical assistance, please submit an incident on the Web, or call Microsoft Product Support Services and speak to a support professional.

Okay, with those details aside, let's jump right in to the questions. First question, and I'm not sure which tool they're referring to here: Does the tool manage the Server Connection account? Does this include the Server Connection account without a site reset? Does that question make sense; do you understand which tool they're referring to?

Bruce: Yes, he's talking about the Manage Site Accounts tool.

Rob Wickham: The easy answer is that it just manages the accounts that you can manage through the regular MMC, and it just provides some additional functionality that spans sites. So if the Server Connection account is exposed in the MMC and you can change it there, then these tools apply to it. I'm getting a headshake from Wally that that's not the case. The Server Connection account would remain exposed only through that setup command-line functionality and that INI file functionality.

Jason: Okay. In Manage Site Accounts, does -verify equate to verifying the account against the domain for validity?

Bruce: It will verify a given account against a specified server for validity. Yes.

Jason: Does the Manage Site Accounts utility change the account, so in the domain, and also modify each of the services that use those accounts?

Bruce: It modifies each of the SMS services that uses the account, and yes, it does modify those in the domain.

Jason: Okay. Are account passwords changed in the domain or just in SMS?

Bruce: In the domain.

Jason: Can Create Secondary Site create secondaries via CD-ROM in the secondary site system?

Bruce: Yes, you can specify your installation directory, and there's a true or false setting to install from CD with for that tool.

Jason: Does Show Query Count display the number of records, or just those records that are unique by SMS ID?

Bruce: There shouldn't be multiple returns for a single machine. So the answer is if you're getting a machine back, you should only get one return per machine, unless you are querying on something…

Rob: This is completely dependent on the way that the customer has structured the query at hand. This tool just runs that query, and what it does is change the beginning part of the statement where you might select individual properties. What it's doing is parsing those properties out and replacing it with (count*), which is the query syntax for getting a number back, so it doesn't actually know anything about the query other than modifying the query to return the number of instances.

So if the query was reporting numbers that are distinct by a particular property, then the count would return that distinct number. So the answer is it depends on how the query was written.

Bruce: Thanks, Rob.

Jason: The next question concerns the SMS software distribution tool. Will this help us manage orphaned objects?

Bruce: If they mean orphaned objects such as locked packages and so on in child sites, that's not the purpose of the tool. The purpose of the tool is to create objects that support whichever patch that they're using or to create whichever tool that they're using. It's not an orphaned objects management tool. That can be done through the SDK, though, and they ought to look into that aspect of it.

Jason: Okay, great. This granular client tool, does this work only on Windows NT systems or also on Windows 95/Windows 98?

Bruce: It works on Windows NT systems through forced CCRs.

Jason: We've used the Capmanwrap.exe within the Value Pack to install clients within a site. Is there any documentation anywhere on this? We've not been able to find anything.

Bruce: I'm going to punt this one to Rob.

Rob: That's one of those tools that isn't in our initial schedule, and it does require a bit more work in terms of documentation, as well as the multi-site awareness that those of you who have used SMS 1.2 would have found in the Smsls.ini mapping file. So conceptually, we do need to enable this tool to affiliate itself to the right site, and find an appropriate CAP within that site.

Jason: The next question actually concerns SMS Service Pack 4. I know it's not really on topic. Can you guys give a lowdown on what's going on with SMS Service Pack 4?

Bruce: That's part of why we invited Wally along, so Wally, I'm going to punt that to you.

Wally Mead: We don't have a public date yet. As you know, Microsoft as a corporation went through a big security push with all the hacker virus issues that have come up recently. Because of that, dates have been pushed out. However, look for SMS 2.0 Service Pack 4 very, very soon. We can't give you a definite date on it, but it is going to be much sooner rather than later. So we're very close, which is all I can say.

Jason: Okay, thanks for that, Wally. Can I assume that the preload can be deployed via software distribution?

Bruce: Yes, the preload can be deployed as far as the executable could be installed down to the client, but I guess that begs the question, "Why would you be preloading the client if you already have a client on the machine?" So the purpose of the tool is really to look at machines that do not have a client on them, and to put the prestage Clicore and the optional components on the client, and then activate that client through one of the normal client installation processes without downloading the 12 to 15 MB of client bits that you normally would. So I don't know why you would want to do that, and if there's an additional aspect to that question, maybe you can send us a follow-up question and we can get that information to you.

Jason: Yes, if you want to just type in "follow-up" at the beginning of your message, we'd certainly be glad to take that during the WebCast.

Okay, the next question concerns the preload imager {Client Preload}: With this, can the client be added to a ghost mirror?

Bruce: Yes, that's part of the reason: the ability to give you a way to put the SMS client on an image without creating duplicate GUIDs in a supported manner. So that would be a good application for this tool.

Jason: Okay. Can you use the preload for non–dial-in computers?

Bruce: Yes, you could use it. There's no speed checking, there's no bandwidth checking; it just prestages the client on the machine.

Jason: Are there any updates at all to the Web Reporting tool for this release?

Bruce: This isn't a release per se, although it may come out as a suite. Each of these tools releases individually. So whatever is the current version of Web Reporting up on the Web, that is the released version, and as changes are made, they will be posted to the Web. So the question assumes that we're going to release all the tools at once, and that probably is not going to be the case — they'll be released individually to the Web.

Jason: Okay. Does the Check Available Programs tool allow for re-running the installation on the client without re-advertising the application?

Bruce: No. All it does is forces a check for advertisements now kind of functionality, so it doesn't re-run the advertisement. There are a variety of ways to do that; I believe there is a Knowledge Base article on that, and if you'll send a request in, we can get that information to you.

Wally: We also document that in the SMS 2.0 Service Pack 2 and Service Pack 3 Release Notes, how to re-run an advertisement. So we already do have it documented in the materials you guys have available to yourselves, so just look at those release notes for that, and just search on re-running advertisements.

If you happen to have attended or want to look back at the Topaz Software Distribution WebCast (http://support.microsoft.com/servicedesks/webcasts/wc121101/wcblurb121101.asp), that is something that is being added into Topaz, the ability to right-click on an advertisement and re-run that advertisement at your clients, given the appropriate parameters for that advertisement.

Jason: Okay. I think we've already answered this: Do these tools, such as Check Available Programs, Delete Clones, and remote client preload work on Windows 95/Windows 98 clients? I think you already answered that, you said they work on Window NT clients, correct?

Bruce: Well first off, there's the option to scrub the GUID when you run the Client Preload tool. It runs on Windows 95/Windows 98, it does run on Windows 95, Windows NT 4.0, and Windows 2000. Just something else, too, it also supports preloading WMI 1.5 if you have that need.

Jason: Okay. Is the SMSRunOnce key an HKEY_LOCAL_MACHINE or a HKEY_CURRENT USER key?

Bruce: It's parallel to the HKEY_LOCAL_MACHINE. I'm going to punt that to Rob.

Rob: It's absolutely machine specific because of security. We would not want to be reading anything from HKEY_CURRENT_USER and then giving it elevated rights. So we thought through the security design of that.

Jason: Okay, great. How does the Elevated Rights Deployment Wrapper get the admin rights? Do you have to code the account name and password into the wrapper, and if so, are these encrypted? If not, does it use the Local System account?

Bruce: It uses the same mechanisms within SMS, the SMS Client Token Account and so on, that the initial run does, so we're not exposing an account on the client.

Jason: Okay. With Capman, will it eliminate the need to use the SMS logon script since it uses SMSman too?

Bruce: Yes, it eliminates the need to have logon points. In that way you can still use your logon script to install the client, but you don't necessarily have to configure SMS to have logon points. If you remember from the SMS 1.2 days, it brings back a lot of the functionality of the RunSMS command where it allows you to install off a specific site server. Again, there's some work being done in that area to allow more selectivity along the line of the old Smsls.ini file that we had in the SMS 1.2 days.

Jason: Okay, excellent. Are there any changes to the SMS_def.mof file, and what about our current modified SMS_def.mof files?

Bruce: The way most of these tools work is, and I would think that you're particularly asking about the security patch tools, is that an individual MOF file is compiled on the client itself, and this is not incorporated into the SMS_def.mof, so those security tools do not modify the default MOF, they are compiled individually on the machine.

Jason: Okay. Where do you install the Microsoft Security Toolkit, your main site or on all sites?

Bruce: My follow-up question would be, there's the Security Toolkit and then there's the import tool. The import tool you would install in two ways. First, you would install it on your child sites without creating any objects, to make some modifications to the database so you don't get errors with having mismatched schema.

Then on the top-level site, where you want to do the distributions from, you would select the central site and that being the place where you would create those objects. So that is pretty well documented. If you look in the "Using SMS 2.0 to Deploy The Security Tool Kit Fixes," that document comes with the Security Toolkit. It explains a lot of that concern.

Jason: Okay. If the security toolkit contains the fixes or patches, how readily will it be updated with new fixes or patches?

Bruce: The Security Toolkit was designed to provide a baseline level of security for Internet type problems this past fall. Going forward, as far as synchronizing new fixes that you might want to put in the operating system or Office, you would want to use one of the other two solutions, the Security Update Inventory Tool or the Office Update Inventory Tool.

Jason: How does the security toolkit deal with fixes that need a reboot?

Bruce: I will have to get back with you on that particular question. I would imagine you would want to use the RunOnce wrapper that we have. There's nothing in the Security Toolkit itself that manages the reboot process at this point. You will have to manage that per the documentation, and the documentation is pretty explicit. It's about 100 pages between the Security Toolkit and using SMS to deploy the kit. So there are pretty thorough steps as far as what to do for each patch and for each stage that you are in, in providing your baseline security level.

{Follow-up answer: The Security Toolkit is not part of the Value Pack. The MSTImport tool does provide queries, collections, and PDFs to support the security toolkit. The Security Toolkit uses Qchain.exe to manage reboots. More information is available in the Security Toolkit documentation. Knowledge Base article Q296861, "Use QChain.exe to Install Multiple Hotfixes with One Reboot" (http://support.microsoft.com/support/misc/kblookup.asp?ID=296861) may be helpful, regarding how Qchain itself works.}

Jason: Okay. What are the requirements for most of these tools? Are the requirements any different than typical SMS? The customer is saying that many tools: Show Query Count, Transfer Site Settings, Repair Wizard and Delete Clones would "blow up" upon utilization. Beyond sending them to PSS, can you give a brief summary of some of the requirements for these tools?

Bruce: These tools will run on a properly sized and properly configured SMS site. If the customer has a beta form or an early beta form of the tool and is experiencing some problems, they might want to send us some feedback on that in the follow-up forum here, specifically the problem they're having. But my machines that I use and that I test on are not large machines, and I have experienced no problems of the sort that have been described.

Jason: Okay. I believe this next question was answered as well, but I want to make sure it gets asked: Just to confirm, will the Manage Site Accounts tool allow me to change the SMS service account name and/or password cross my entire hierarchy? Will it also allow me to update the account used by all my site addresses as well?

Bruce: It will allow you to reset the SMS service account and any account that is exposed in the admin console, so the address account would be one of those accounts as well. The purpose of the tool, again, is so that you don't have to go individually to each site and change each account. But you can multi-select. The list of accounts will show up in one screen of the wizard, and you can multi-select all those sites that share the same account, and then you can modify that account as you find necessary. So I think what the question is getting at or digging for is, is this true? Can I change a single account shared by many sites in one place? And the answer is yes.

Jason: Okay. In the Security Toolkit, does SMSAdmins have the ability to not automatically push a patch or a fix?

Bruce: Yes, that's very flexible, and you are given the option to create all these SMS objects, but you do not have to. And you have very granular control over what you do and don't want to do, which objects you do and don't want to create.

Jason: If we already have the NewUID package running for duplicate clients, I assume we should remove the stored procedure and package before installing the Value Pack. Is this correct?

Bruce: The Value Pack does not install like a service pack. Each tool is an individual installation, and so what you would want to do is evaluate that. I haven't tried running both side-by-side. I'll think about that for a minute. I think you could possibly cycle a GUID unnecessarily, but I don't think you're going to cause any serious problems, but any change management like that, any time you systemically change how you handle something as central and important as the GUID, you would want to manage that in a planned and organized fashion. If it were me, I would phase out the method used in the white paper as I phased in the method in the Delete Clones tool, and I would want to make sure I tested in my lab first, so that I understand how the hand-over would happen.

Jason: Okay. Does the user notice the hotfix installation?

Bruce: It depends on how you set up the command line. If the patch itself is silent, SMS can run it silently, so that there would be no need in most cases to have any user interaction or the user to notice the process at all. Of course again, that depends on how you set up the particular hotfix and what it requires to install successfully, but most hotfixes install silently and SMS can do that for you.

Jason: Okay, excellent. What is the recurrent schedule set to by default for the collections created by the security update tools?

Bruce: I think the question is, what is the Collection Evaluator refresh cycle on the collection on the Security Update tools. I do not know, and I'm going to ask Rob. It's probably 12 hours.

Rob: It's the system default, when you create a new collection and you don't specify an explicit schedule. I'm not sure what that number is; Wally tells me it's two hours. Thanks, Wally. But the key point here is that the installation process that's used for these tools are just initial defaults that are reasonable, and there is an expectation that based on your particular environment, that you might tune that setting or other settings to suit your needs. You're by no means locked in to particular settings when you go to use these items.

Bruce: Just a plug for the 12 hours, the reason that came out of my mouth initially is that if you don't have a need to update your collections at a more frequent interval, 12 hours is a good setting to keep the overhead of collection evaluator down on your site.

Rob: It's also worth mentioning that you probably want these tools to run on as many systems as possible, and keeping your query rule as simple as possible to something like an All Systems collection query, that would be a very efficient query to execute and refresh, or as Bruce mentioned, to really bump that schedule out to a fairly large number wouldn't be a bad idea.

Bruce: One of the things I was afraid of without a demo capability here is that people would walk away with the idea that these tools created these objects like collections and packages and so on without you having any control, and that is not so. You have a great deal of control through the wizard of what you're going to create and so on. So you have a lot of flexibility, and as you deploy it in your lab and look at it, you'll find that you'll be able to use the tool in a variety of ways that meet your needs.

Jason: I think this was answered in the presentation: The Capman tool will be included in the Value Pack. Is that correct?

Bruce: It wasn't on the list because of the reasons that Rob gave previously, that there is some additional work and documentation being done on it. It will likely come out in a later timeframe, but it is being worked on. It just might be one of the later tools that come out.

Jason: Will the Patch Wizard download through a password-protected firewall or proxy?

Bruce: The Patch Wizard simply depends on having Internet access wherever it runs, so we cannot do anything additional beyond what the availability to the Internet is from the box it runs on. So you need to make sure that when you run the download portion of the Patch Wizard, that you run it from a box where you have Internet access.

Rob: I'd like to add something. In the event that you don't actually have Internet access, or you have concerns about automatically pulling these bits into your network, the solution provides a mechanism for you to obtain patches out of band, so to speak, and participate at a more detailed level with the process of building the package as an integral part of using the wizard. So there's a lot of flexibility about how you can get patches, and there is intended to be support for proxy settings as well.

Jason: Excellent. We don't install anything pulled from the Internet directly into the production environment; it would be installed on the test boxes and validated first. How would these tools be used if the patches were already on a share on one of our file servers?

Bruce: I think Rob just answered that as well. You have flexibility; you don't have to do it that way. You can point your source directory somewhere locally.

Jason: Okay. Does the patch management tool query the WMI class QuickFixEngineering? If so, do our clients need Service Pack 3 for Windows 2000, or the hotfix Q279225 for when management hangs scanning that class?

Bruce: Rob, I know we do the patch states. Do we also do the QFE?

Rob: The QuickFixEngineering class isn't a necessary part of the patch management solution. It is an interesting aspect of providing additional reports, however, which is in scope but not a dependency for a patch management.

Jason: We are getting quite a few questions about how these all these tools are going to be made available, and I know you said you release them to Web. Are there other plans to release them on a CD or have them available for download in another form or fashion?

Bruce: If I understand the intent behind the question, I believe it is "How can I get the tool if it's not released to the Web yet?"

Jason: I think they're actually looking for another way to grab the tool other than off the Web.

Bruce: Rob will have to answer that.

Rob: Our initial plan is a Web release because we can keep this process as efficient and as low in cost as possible for everyone. We have been thinking about what other value proposition we have for the convenience of using a CD of some type, but we haven't concluded that we will use any CD media yet.

Jason: Okay. I guess kind of along those lines, people are asking about Topaz. Are there any plans to roll up some of this into the Topaz release, and while we're on the subject, maybe you can update us about the Topaz release.

Rob: A related concept to the Value Pack is that we're trying to prerelease specific functionality that we need to be more timely about to recognize changes in the market, changes in the security environment, for example. That's been a very powerful influence in our first Value Pack schedule, where we provide the patch management pieces, including the inventory and deployment reporting aspects, and site account management, RunOnce MSTImport, all of those are in our initial schedule, as well as the transfer settings tool is in our initial schedule. All the other tools stem out from there into the future.

The intent is that there will be some Value Pack content that makes perfect sense to become an integral part of future product releases, and on a case-by-case basis, we'll be doing that. But the Value Pack will also be a long-term mechanism for us to continue advancing the product for rapid cases where we need to respond sooner than the product cycle.

So you'll see the Value Pack with an ongoing insertion of new features, and some features will end up in the core product at some point in the future, but it's not 100 percent certain that everything that we put in the Value Pack will go into the core product.

Jason: Okay, excellent. You mentioned Windows CE devices during your presentation. What will you be able to do with those Windows CE devices? What's the usefulness of having them in inventory?

Bruce: The current functionality and on release, the tool will allow you to do asset tracking. You'll know which PCs your Windows CE devices are docking to and some basic hardware inventory information about them. Additional functionality will be pushed off into the future, regarding things like software distribution and that kind of thing. Maybe Rob can talk more about additional features.

Rob: Sure. Inventory really opens the door to a lot of possibilities, but this solution is limited to devices that have an ActiveSync host. So any follow-on functionality that inventory provides for you, such as software distribution, would have to go through the ActiveSync host using the normal SMS software distribution. It is an initial offering, so to speak, with far better things most likely in the future, and some pretty clear caveats with this initial tool.

Jason: Okay. Is the MOF available to start pulling the information you mentioned?

Bruce: There are a number of MOF files involved with a variety of the tools. With these tools you can't really separate the MOF — I was thinking about some of the patch management solutions where there's a scan agent that runs on the client and populates the result. This isn't the kind of thing where you can take the MOF and add it to your _def.mof and have it function correctly. The MOF is available with the tools, but you wouldn't want to split it out like that.

Jason: Excellent. Are there any updates or enhancements to the MIF status reporting?

Bruce: Not currently in the Value Pack. I think the question is, is there any way to increase the granularity of status message reporting, that kind of thing. There are ways within the current product to create additional status messages. You might look in the SDK, you might look at installer, but the Value Pack itself doesn't have a status message-specific solution at this time.

Jason: Okay. Will these tools not work on a domain that's not connected to the Internet? Is there a way to download the latest fix and import it to the SMS domain that is not on the Internet?

Bruce: Again, I wish I could have done a demo for you to make that more clear or taken a screen shot or something. But no, you do not need to be connected to the Internet. That's a convenient feature for you. You can be, but you have a lot of granularity and you have a lot of flexibility regarding how you set up lots of the pieces of this, including the way the files are sourced in your packages, and you can do that in a number of ways, including in a lockdown environment.

Jason: Okay. Any plans to demo the applications at the management conference in Las Vegas next month? Are you aware of any plans for that?

Bruce: Yes, they will be demonstrated. There will be a couple of sessions on the Value Pack at the Microsoft Management Summit in Las Vegas at the end of April 2002.

Jason: Okay. Will there be a wizard tool forthcoming to automate SMS_def.mof updates to pool registry settings?

Bruce: There are some third-party editors out there. I'm not sure that would be a Value Pack tool. Rob, do you want to address that?

Rob: Sure, we do have what we call a DCR, that someone at some point in the past has opened in our little database of tracking things, to enhance the support tool called MOFman.exe to enable a little bit of this type of functionality. We haven't done that work yet; we have a lot of things to juggle here. Using Notepad to edit that into the _def.mof is our current approach for some of those particular cases of needing to edit that MOF.

Jason: I know we don't typically talk about timeframes or set specific dates. Is there any general timeframe you can give about the patch management tool and its availability?

Bruce: I'm going to let Rob talk about availability and futures.

Rob: The patch management pieces are our top priority. We do expect those to be available some time this summer.

Jason: Is there security associated with the forced CCR? Can someone create CCRs whom we don't want to create CCRs?

Bruce: You have to have administrative rights to the console to be using those tools. So if you have your administrative console and you don't have it wide open, and you are not applying proper security on the front end, then you have that possibility. But if you're concerned about security and you've reviewed how the admin console is locked down and the objects within the admin console, then you won't have that problem.

Jason: Okay. Can you explain in more detail how the patch process works for an administrative install of Office 2000?

Bruce: There is an admin applicable status, and you would query for that. If you look on the screen shots, you'll see that for the Office Update Inventory Tool, one of the status types is admin applicable, and that will tell you whether or not that administrative image is something that you want to look at for applying patches to the administrative image. So basically that solution is there, and you can manage it.

Jason: What service pack level of SMS 2.0 must your site or clients be at before using the Value Pack tools?

Bruce: The Value Pack tools are not a suite necessarily, and individual tools will work differently. I'm going to punt to Rob on whether or not there are any that have an SP3 dependency.

Rob: We are probably going to be taking an SP2 dependency on everything as a minimum. My preference would be, based on our timeframe and so we can also expedite our own testing activities, to take an SP3 dependency, and that's just from an SMS standpoint. As far as client versions and so forth, the Patch Wizard and its companion that runs on the client will require Windows NT 4.0 SP6a minimum, and the patch management pieces will not be available for the Windows 95/Windows 98 platforms.

Jason: Okay. With the tools that install secondary sites, can the site be installed from a copy of the CD that's located on a local hard disk on the secondary?

Bruce: You can specify the source, so you have a lot of flexibility in that and how you want to place that source. You have that freedom.

Jason: On your secondary install option, will I be able to specify a subdirectory path on the server where the site will be installed? SMS 2.0 did not give this option in the past.

Bruce: I hesitate to say something I haven't tried. I don't see a reason why not, but Rob?

Rob: That's a research question. I don't know if it exposes that folder name in the command-line tool or not.

{Follow-up answer: If by this you mean specify a subdirectory from which to obtain the source files, the answer is no. You can specify to install from CD-ROM, true or false. If by this you mean, can you install the site itself to a second level directory, such as F:\backoffice\sms, I tried it, and it appears to work just fine.}

Jason: Is there a way to create a PDF from an SMS package?

Bruce: Not that I know of. PDF is pretty much from the package itself. You could use the SDK. We don't have a specific, discrete tool for that, do we? You could use the SDK to pull down the properties that are currently defined in a package and create a PDF out of it.

Jason: Okay. Will the Transfer Site Settings tool retain sort orders or reorder the sort order for the status filter rules?

Rob: We do have an active bug we're tracking on that. There are cases where the status filter rule order is affected, and we don't want that to happen. We also don't have a feature in place yet that will remove unwanted status filter rules. Currently it's an insert and update mode. So some of those subtleties we'll be addressing prior to the release of the tool.

Jason: Is there going to be a version of HFNetChk released for the Value Pack tools, and if so, what version?

Bruce: HFNetChk version 3.2 is the required version. It's not a Value Pack tool; it's a separate and discrete tool that the Value Pack leverages. So the minimal version is 3.2, and that tool is managed by somebody other than the Value Pack folks.

Jason: Okay.

Bruce: There's a Knowledge Base article in the slides (Q303215; http://support.microsoft.com/support/misc/kblookup.asp?ID=303215) that points you to more information about HFNetChk, and you can get more information also in the Security Toolkit documentation.

Jason: It looks like this user joined the WebCast late, I'm not sure if you covered this during the presentation: Do any of these tools allow the advertisement status to be available through Web Reporting?

Rob: You can get advertisement status today through Web Reporting. There is a particular Status Summary class that's exposed in the tree control for the custom report builder. There's also the AdvertView tool, which is a very effective way to view advertisement status, in case you haven't seen it. It's in the support tools package.

Jason: Did you say there was an update to Web Reporting coming soon? Any plans for an update?

Rob: We will be picking up some bug fixes and updating the Web Reporting tool at a timeframe that's in-line with providing the patch management pieces, because we'll be providing some canned reports for patch management.

Jason: Okay. Can I use the Granular Client Deployment tool to preload a client on a machine on a LAN and then ask the user to run this from a network drive in case the SMS client is corrupted on the user machine?

Bruce: The Granular Client Deployment tool basically generates CCRs, so it's not a pre-staged type of tool. You would want to use the client preload tool to do that. If you want to pre-stage somehow, you would have to find a mechanism to do that. If there is no SMS client and you don't want an SMS client on the machine through any of our normal installation modes, you would have to find another way to preload the client bits onto the machine, either through a WMI script that pushes it or something like that. Otherwise, to install software on an SMS client, you need the SMS client to exist on the machine.

Jason: Okay. Regarding new client deployment, there was information that the Value Pack would have a tool so that we could forgo the use of logon points. Is that the forced CCR tool that was shown?

Bruce: You could do that, as long as it's a Windows NT client or a Windows 2000 or Windows XP client, you could certainly use it for that. But I think the tool the customer is referring to is Capman, which we've discussed a couple of times here. Capman again is an SMSman with an extension that allows it to install directly from the CAP rather than from a logon points, so logon points are not necessary anymore. But if your systems are capable of installation through CCR, if they're Windows NT, Windows 2000, or Windows XP and meet the system requirements, you could certainly use the granular client deployment tool that way.

Jason: Okay. Can our MCS representative install the tools for us?

Bruce: They're not difficult to install, and I'm sure that if you talk to your MCS representative, he or she will be able to get the tools for you and help you test them in your lab.

Jason: Will we need to upgrade Web Reports for the security patch management add-ons for these new tools?

Bruce: If you're running the latest version of the Web Reporting, you will get the results that you see in the screen shots. Actually I didn't give you screen shots of Web Reporting, but they will show up fine with the current version. As Rob was saying, there are some planned additional reports with the next version of Web Reporting.

Jason: Does the granular client deployment have the ability to deploy to clients that are not currently in the database?

Bruce: No. It's a right-click on either the collection or the individual record, and it will send CCRs to the machines that currently have discovery records in the database. There are other methods and other tools that will allow you to either generate a CCR or a DDR for a machine that's not currently in the database. You might look in the support tools or contact your MCS Alliance professional or PSS to get those.

Jason: With the elevated rights wrapper, what if I use the software installation account? Does that get stored anywhere, or won't that work?

Bruce: I believe that we're using the client token account at that point. Rob?

Rob: The security context that is used is the same that the SMS client natively provides if you ask for administrative rights on the client. I do believe that that is the client token account on the client. The tool isn't doing anything magic to get elevated rights, other than how you configure SMS to provide those elevated rights during the pre-reboot phase and during the post-reboot phase of the setup.

Jason: This is a follow-up question: I'm going to be upgrading each of my current BDCs in the field to Windows 2000 in the very near future. How will this affect each of those secondary sites? Also, how do I move those sites from the existing Windows NT server to the new Windows 2000 server without orphaning clients or causing interruption on service?

Bruce: This question is really beyond the scope of the Value Pack. What they're basically talking about is swapping hardware and swapping domains, and there are a couple of white papers available for you up on our download site for SMS, and I'll refer you there. If that doesn't help, you can contact PSS.

Wally: Actually that Web site has changed. The public Web site is http://www.microsoft.com/smserver/. We changed that a few weeks ago. And if you go to the Maintenance and Recovery section (http://www.microsoft.com/smserver/techinfo/administration/20/recovery/default.asp), where we used to talk about the site recovery expert, there is a paper up there that Bruce mentioned on swapping server hardware (http://www.microsoft.com/smserver/techinfo/administration/20/recovery/SMS20hwswap.asp), so you do have a white paper available to tell you here's how you take your site server and replace it with upgraded hardware, so a new hardware platform.

There's also a white paper up there, not in the Maintenance and Recovery section, on integration with Windows 2000 (http://www.microsoft.com/smserver/techinfo/deployment/20/deployosapps/wincompat.asp). When you move or upgrade your OS from Windows NT 4.0 up to Windows 2000, it does discuss what the issues are with Windows 2000. Basically as of Service Pack 2 of SMS 2.0, we fully support Windows 2000 as your site server platform, so it's just a matter of upgrading your OS, making sure you have SMS 2.0 SP2 installed prior to doing so, and then it should work fine. There are a couple of little caveats, which that white paper discusses. As far as orphaning or not orphaning your clients, when you change your hardware, again that white paper in the Maintenance and Recovery section on swapping server hardware covers that in detail, so that you do not orphan your clients.

Jason: Okay. What's the recommended system to run the Security Update Inventory Tool sync on? Can it be run on a server other than the site server?

Bruce: Yes. There are two programs that run, and you can target a dedicated machine if you'd like to perform the synchronization task, which pulls down the latest security bulletin. So if you want to run that piece of it, I would run it on a separate machine that's dedicated to that task or is going to be available and has the proper Internet access if you want to go that way, and can manage the source for you for that tool.

Rob: Bruce, let me add something to that. The intention and security requirement that we have with the synchronization task is that the process that's running the task and that has read/write access to the package source folder also has package modify rights for the particular package, the SMS package. To get those, we run this through software distribution on a schedule sent to the machine that the SMS administrator, the human, commonly uses for their day-to-day functions. So the Available Programs Manager (APM) will pop up this recurring task, and it will run in the context of that SMS administrator that's logged in so that it will be ensured of having the necessary rights to perform this update.

It's also an interesting safety net so that this administrative person has confirmation that the synchronization task ran and succeeded or failed.

We will probably be looking at a future version or update that streamlines and automates this process to happen more like a background process running on the site server, much like the Distribution Manager and the other server components. But for this initial release of the functionality, there are some what I'll call inefficiencies, but we're opting on the side of security rather than the side of convenience, for the moment.

Jason: Okay, great. This is actually a follow-up question concerning HFNetChk. It asks: The Value Pack has a scan result tool it uses against HFNetChk. Does it matter what version you have to use the scan result tool in SMS?

Bruce: There is a requirement for HFNetChk version 3.2, and there's also a requirement for MSXML 3.x or later, for that tool.

Jason: Somewhere in the WebCast you mentioned an issue with orphaned or no longer existing packages, programs, and advertisements and secondary sites. Is there a KB article, white paper, or any documentation related to resolving this?

Bruce: That's really a PSS issue, and you need to call them, or I can follow-up offline with the customer on how to do that.

Wally: If you go up to the public Web site, go to the Maintenance and Recovery section (http://www.microsoft.com/smserver/techinfo/administration/20/recovery/default.asp), there is information up there in some of the documentation on removing orphaned objects. The Recovery Expert, if you run through it, will talk about it a little bit. There are specifically papers and links up there to the SQL commands or the commands you run through WMI to clean up or expose objects and delete objects from SQL and so on.

Jason: Okay. Does the download portion of the patch support PAC style proxy configuration? For example, "modern" Internet Explorer supports PAC autoproxy configuration, but the Microsoft media viewer plug-in does not support PAC.

Rob: Basically how this is going to work is if in your Web browser you can pull up the particular items that the patch solution needs to download, then the patch solution will be able to download them. So if you're using any particular proxy configuration, as long as you've set your browser to work, the patch solutions will be using those proxy settings to get its work done as well.

Jason: Okay. Are there any plans to support PDAs that use the Palm OS to show up as a resource in SMS?

Bruce: That's a futures question, and I'm going to punt that to Rob.

Rob: My understanding is that there aren't such plans, however that's very much a product marketing question, and you would probably want to go to your account team and speak with them about that, and pull in our product marketing arm.

Jason: Okay. The Capman tool, what are the default rights necessary to install a client on a Windows 2000 machine? It was not functioning properly as a default user, but worked flawlessly as an admin, and we'd like to be able to use this tool as a default user.

Bruce: I think that we'd have to look at that more specifically. The tool isn't polished, it isn't supported yet, and it depends on what is happening. It may be a question of rights back to the CAP, it may be a question of whether or not the remote installation piece, the CCR piece, has rights on the box to finish the installation. There could be a number of things. If the person is using Capman, it's likely they have PSS or they have an Alliance engineer or MCS involved in it, and I would encourage them to pursue it through them. But it is a beta tool and it's not finalized yet.

Jason: Okay. Are there any plans for an advertisement export and import tool and a package export tool?

Bruce: There are currently some support tools that will do some of that, including the manage site settings, which as I recall has package settings, doesn't it Rob?

Rob: Transfer Site Settings does allow for a — I won't call it an import/export of a package, because it's only certain properties of a package that it will replicate from a source package to another package. A good example is the collection refresh interval that you can copy from one collection to all the other collections if what you want to do is change the collection evaluation frequency on a site-wide or hierarchy-wide basis.

As far as a generic mechanism for importing and exporting the objects themselves, there is the current resource kit tool called SMSSPman, Sites Property Manager, for the SMS 2.0 product. I believe in our next product release we will be making that process a little bit easier in terms of not having to write fancy code to do it. We'll probably take advantage of some small tools in that space to make that process easier and allow us to move away from that old resource kit application also. But at the moment, no, we don't have generic tools for object import/export.

Jason: Okay. Before we end the WebCast I do want to take just a moment to solicit feedback from our audience. If you've been to one of these WebCasts before or if this is your first time coming in, we would like to see what you thought of today's presentation. Anything is fair game on this. If you want to comment on the presenter, if you want to comment on the topic, what you thought of the sound quality, whether your question was answered in the Q&A, all of that is fair game. You can even send in comments or suggestions for future WebCasts, anything.

You can send feedback to us trough the e-mail alias, supweb@microsoft.com. Just be sure to put the topic or the date of the WebCast in the subject line so we can cull it out. But we do really appreciate your feedback and we are using it to grow and evolve this program, so please send that on.

You might have talked about this with support for the Palm OS PDAs, but: Are there any plans at all to be able to deploy applications to the Windows CE devices at some point?

Bruce: The current plan is to support hardware inventory, and the software distribution is being looked at for the future.

Jason: Okay. This is a follow-up, and I'm not really certain what it's a follow-up to, but there was a question about reading registry from a MOF: Is Topaz planning to support reading a registry from a MOF?

Bruce: You can read the registry from a MOF now. There's a registry provider, and likely, the syntax is a little tricky depending on what level you're at down into the registry, and that's an appropriate call for MCS or PSS. PSS has some example MOFs that will show you how to pull those registry keys in. I believe that example is also in the SDK, I'd have to look again. But I do know that PSS has some examples on how to pull information using the registry provider with a MOF.

Jason: Okay. A little off-topic, but we have just a moment here: Will the new version of Topaz will be less dependent on WINS?

Wally: As a generic statement, right now our plan of record is that we're not rewriting Topaz to remove any NetBIOS requirements. However, most of the new functionality in Topaz was generally carefully written to not require NetBIOS and be able to pull information from DNS or Active Directory® or whatever. There is some work going on right now, some investigation to determine how successful you can be in a Topaz environment if you're not using WINS or any other type of NetBIOS name resolution.

So as of today, our public statement is we're still NetBIOS based for functionality that was ported over from SMS 2.0 to Topaz, but new functionality does not require NetBIOS generally, it's Active Directory or DNS. But we are looking to see if there are ways to easily make Topaz run effectively in a non-NetBIOS environment, as far as WINS type resolution.

Jason: Okay, thanks for that. That does answer all the questions that we had in the queue, so I think we're going to wrap up this session. I want to thank everybody for stopping in today and listening in to our WebCast. Thanks to Bruce, Rob, and Wally for coming in and dealing with all these questions. I hope this session was useful to you. Please let us know if it wasn't, we are very interested in your feedback regarding this program. Send us an e-mail to supweb@microsoft.com.

We hope to see you again in the near future. Thanks, and good-bye.


Last Reviewed: Sunday, April 14, 2002