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

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

Rob Wickham: We've been working on this initial version of the Value Pack for some time, and this WebCast gives us a very unique opportunity to walk the customers through the features at a high level, but also with some screen shots so they can become familiar with the look and feel, the experience that the SMS administrators will be going through if they use these tools. So let's go ahead and get started.

We have some brief objectives that we want to cover today (slide 2). Namely we want to make sure that you're aware of some of the key problems that are facing customers today in trying to manage software updates. Some of these things are things you're already aware of, but I want to convey the point that we've looked at what these problems are very carefully, and we've really tried to build a solution that addresses these key points for you.

Our next objective will be to go over the key features that the Value Pack has, to address some of these problems, and finally, we want to drive home the point that we want to validate our beta program, and we need to do this with some production deployments prior to our actual public release. Those of you familiar with the SMS product understand how important it is to validate, on a larger scale, certain functionality that you simply can't validate in a relatively small lab environment.

Let's move on to our agenda (slide 3). We'll be covering today's challenges. We'll be going into a design overview of the tools and the approach that we've taken with the software update management solution. We will then go into some additional detail of the specific features, some of the more interesting features that have been requested. Then we'll look into our actual schedule. I'm sure everyone is very interested in that. Then I have a call to action for you and hopefully some of the elements of that call to action will be realistic within the next 30 days or so.

Next slide (4), "Today's Challenges." Number one challenge is receiving information about the latest software updates and vulnerabilities. Just a couple of years ago Microsoft® started publishing an XML-based security bulletin database, MSSecure.xml. Over the years a few tools have cropped up that interpret that. Unfortunately that's not a pervasive solution for every software update. If you look at the Windows® Update Web site there is a far greater amount of software that is covered there. Unfortunately that's not easily deployed with SMS. For our SMS customers we recognize that it's their primary software distribution infrastructure, so we need to work on that challenge.

The next challenge, auditing your enterprise for the applicable software updates. This is a technology challenge. Conveniently, SMS has a very rich client agent infrastructure that allows us to run scripts and so forth on a recurring basis to audit your clients.

The next challenge, assessing and authorizing available software updates. This is a process that we improved by facilitating access to the types of information that you need, to look at a particular update and the vulnerability, and decide if it's appropriate for your environment.

The next challenge, deploying the authorized software updates within an enterprise in a timely, accurate, and efficient manner. We do a good job of working on that one. Next is tracking the update of these deployments across your enterprise. Another big challenge, but one that I think we've done a very good job with.

Let's move onto our "Design Overview" slide (5). Those familiar with SMS understand the real power of the client inventory and how you can do a number of flexible things with that client inventory. The Value Pack takes that as a base and expands on it by adding additional inventory data into the hardware inventory that describes the software updates that apply to that system, as well as the ones that are already installed on that system.

This bootstraps the approval process, because what you're able to see is effectively the number of clients that are requesting a particular update. So based on the pervasiveness of an update that's missing, you have the means to effectively prioritize which of these updates you're going to deploy first. Of course during deployment you have your own change control practices that you want to push this update through to make sure that it's consistent with your other baseline configurations that are in production.

The next things that are very interesting are the next two bullets in the "Design Overview" slide, where targeting is now very general purpose. Effectively the All Systems collection becomes an appropriate targeting group for software updates. The reason why is there in bullet number four: The applicability rules become evaluated at the client rather than at the collection level on the site server. This is very interesting.

The best analogy for those familiar with SMS is the supported platforms flag in program properties where you can specify a particular piece of software is only valid on Windows 2000 SP2 systems, but we have to have more granularity than that for individual updates. So we extend that into an applicability check that runs on the individual client, which further enhances the scalability of SMS-based collection targeting.

Next, we provide a really rich experience for the administrator that wants to track service levels, because within the hardware inventory data that we provide, we augment that with specific dates and times for various transactions that occur on the client. These then become available later in a Web Reporting tool.

The last point on the design overview is that all the various processes that occur are driven by SMS and their advertisement schedules, which can be customized in a wide variety of ways for your unique needs, based on how many clients you have, how many servers you have, the frequency of the updates themselves, basically how busy your system is. You can fine-tune a solution to fit within some reasonable operating parameters.

Let's move onto our "Feature Overview" slide (6). What we're going to do next is we're going to look at what the setup process looks like when you download the Value Pack and you go through and you do an installation, getting your SMS 2.0 site server prepped for using the Value Pack. Next we're going to look at the administration. This is the day-to-day work that the IT administrator will be doing to survey the updates that have been requested, investigate those updates, and approve them for SMS to deploy.

Next we'll be talking about the actual process of applying the updates and what the end-user desktop experience is while updates are being evaluated and installed, and we'll wrap up this section by looking at the reporting solution.

Let's look at setup now (slide 7). The approach that we've taken with the setups for the Value Pack tools are individual setups. We also have a modular design, which was one of the reasons why we took the approach of individual setups. For the first release of the Value Pack, we will have a tool that enhances the client inventory with security updates that are based on entries that are in the Microsoft Security Bulletins. In addition to that is a separate tool that describes Office updates. These are all the Office updates that are available on the Office Update Web site. These are separate tools. If you don't actually need Office updates, you don't need to use that tool.

Another approach that we thought was very important in running these setups is to reduce the number of manual procedures that are necessary to get a working configuration established. We have PDF files and SMS files that historically have described what an SMS package looks like, and there are some manual procedures that are needed to import that data. The approach we took with the Value Pack setups is to fully automate the process, but not just creating the package and all the programs, but to also create default collections and advertisements with best practice settings in place so that you have a significantly fewer number of manual procedures to go through in order to get your site server prepped and running the necessary audits for critical updates, as an example.

These setups establish an initial working configuration, but it's easy to modify that configuration afterwards by using the SMS Administrator console and going into the package, program, advertisement, and collection settings, and adjusting them to be more consistent with your corporate policies for these various deployment options. Then lastly, these solutions are localized and do have online tool help, which is a very important aspect for a global-ready product such as SMS. Historically the tools that we've published through the resource kit and the support tool, really don't have complete enough tool help and aren't localized. We wanted to make sure that with the Value Pack being a supported solution, that it had product-level quality in all respects.

This next slide describes the end-to-end simplicity of the setup process (slide 8). This is a screen shot that I took from one of my development systems. The setup wizard for the scan tools has a relatively small number of pages. This is the most interesting page because it establishes the great flexibility that you have to let the setup create the best practice deployment for you automatically, with sufficient means to customize some settings along the way. The idea, of course, is to take any SMS administrator, regardless of how experienced they are or how new they are to the product, and get them running the solution as quickly as possible.

Let's talk about administration (slide 9). Once the tools that I previously described have been deployed and have enhanced the SMS inventory for clients, the Distribute Software Updates Wizard, which installs as an integrated aspect of the SMS Administrator console, can be used to look at the updates that have been requested by these clients and prioritize them. This wizard also allows you to easily obtain these updates from the Microsoft Web site. And because the wizard itself represents an end-to-end deployment scenario, you can take the packages that are created and deploy those to your pilot or your test collection that you can create separately and then revise that to send these updates into your production environment very easily.

Because we're using SMS packages, we're also able to customize content within those packages. The best example of this is the support in this wizard that allows you to import rich text content, effectively branding the end-user experience with any of your corporate logos. For example, corporate security can include a specific message to users about the importance of applying these updates proactively before they become required. This is a very flexible feature.

The last bullet here on administration is we have a lot of very rich controls over the end-user experience and the different scenarios that you can encounter within the enterprise. We'll talk about those when we look at some of the screen shots on subsequent slides.

This next slide is one of those screen shots (slide 10). It's intended to familiarize you with the list of the applicable updates that have been described by the client inventory process. What's interesting here is notice the column on the right that indicates the number of clients that are requesting an update. We showed a QNumber right there as an easy reference for you to do any lookups. Many times updates are much more familiar to customers based on their QNumber. We also described the language of the client that has requested the update. This is important because individual updates are packaged separately for each language and can be managed separately for each language, using these tools.

Of course we have the name of the update listed there and the product that's affected by that update. Notice down at the bottom, there's an Information button. This Information button will automatically open your browser. For the particular update that you have clicked on with the mouse, the link to information on the security bulletin, for example, on that update, will open in the browser. You can very quickly assess the pervasiveness of the vulnerability and, based on the security bulletin, you can also assess their applicability to your production environment.

Next slide (11). Once you've made the decision about which updates are most interesting to your environment by putting check boxes in them, they will be automatically downloaded into the package source folder for the package that you're creating, and then this wizard page will appear. It describes these individual updates in terms of their readiness. This Ready column is an important concept because it's describing two things: if the update is present in the package and if the update has been given command-line parameters to govern its run-time behavior. These command-line parameters vary from update to update. What we've provided is the general-purpose solution that, in the future, we expect will be enhanced to support ad hoc updates.

For example, if you have custom updates that you've written in-house, the idea is that this solution, in the future, can be leveraged to allow you to deploy those, using your own command-line switches. In order to look at the properties of the individual updates, you just click the Properties button, and you can modify the command-line switches. An important concept here is that we ideally suppress the user interaction that the individual updates may be prompting end users for, and we also want the updates to suppress any attempt to try and restart the system. We'll talk a little bit more about the end-user experience in subsequent slides.

Let's take a look at the next slide (12), which is "Enforcement Options". Again, this is in the Distribute Software Updates Wizard. What this particular page allows you to do is decide how long the client agent will wait for the end user to make a decision about whether they want to install the updates or not, and after that time expires you have the means here to tell the client agent to go ahead and install the updates if the user doesn't do anything. For example, the user might be at lunch and you know that there's a critical update that needs to get installed because of vulnerability such as Nimda (virus) that's been reported as being active.

We also have the provision to make that default action after waiting to be a postponement, effectively enabling the scenario of end users being encouraged to install updates, but those updates don't become installed until they have actually reached their mandatory time.

Next on this screen is the ability for us to track updates, which may have hung for some reason, and we can terminate those updates and move on with any remaining updates that are applicable to the system. This effectively allows us some robustness, because we don't want one bad update to prevent other good updates from being attempted.

Next, we have three radio button (also called option button) controls that are very interesting features. We can effectively pre-expire updates so that they have to be installed as soon as they're detected as being missing from the system.

Next we have the option of updates being optional indefinitely. For example, some Office updates you may not want to require unless users have actually run into the issue that that update was intended to address. Another option that we have is to allow users to postpone the installation of updates for a certain period of time. After that time expires, those updates become required and the user can no longer postpone the installation. We allow up to a maximum of 40 days of postponement in this release, and that postponement can be based on the time that the corporate administrator has approved for the update. It can also be based on the time after the update was detected as missing from the client.

Then we have this other feature, down at the bottom, Force installation of required updates only. What this means is that when the end user clicks Install Now, to be a good citizen and apply the updates proactively, they have the means to install even the updates that haven't expired yet, effectively giving the IT administrator early feedback on certain updates before those updates have reached their mandatory date where every desktop will be applying the updates. This is a convenient way for the help desk to get some early feedback rather than being flooded by calls, because a particular update had a negative effect on a particular configuration.

The next slide (13) is "Installation Options." This is an additional page in the Distribute Software Updates Wizard that gives you some control over the status that comes back and system restarts. The first check box is intended to help manage the performance of using these tools in an existing SMS infrastructure where the inventory agents have been scheduled to run every week or every two weeks only. This gives the administrator the option of bypassing that scheduled inventory cycle and expediting the inventory changes that relate to software updates to come in ahead of time. Our default here is to defer to the scheduled inventory time, because we don't necessarily want the software updates inventory to become burdensome to the existing data processing for client inventory. But we expose the option for the administrator to fine-tune this.

Next, for individual updates that become installed, we generate SMS status messages for failures that occur and we also have the option to generate status messages for the success. By generating status messages for success, it allows you to defer the inventory data and provide a new real-time assessment of the status of the deployment of individual updates. Within those status messages, we include the product and update title that is for that particular update. So it's very easy to build queries and get near real-time status reports about the individual updates that are flowing and being installed.

Next we have a rather rich feature set for the management of system restarts that are required for individual updates. This particular list control, Detect and postpone systems restarts, has four entries in it. Those entries allow you to explicitly suppress system restarts for server roles, workstation roles, both roles, or none of the above, which means that if you use the same set of updates in an SMS package and deploy those to both servers and workstations, you have the means here to have your client agent initiate a restart for the workstations, but not the servers, which is very interesting. If you have a separate reboot schedule for servers, you can go ahead and patch these servers and restart them on their normal scheduled restart intervals.

We also have the means, with the check box at the bottom, to use a forceful system restart, which effectively bypasses the provision of end users saving any unsaved document changes before the system restarts. The default here is for the end users to be prompted to save their settings and their documents, but there are cases where urgent updates require an immediate application of the update and an immediate restart of the system. So we've enabled the corporate administrator to take a great deal of control over the application of particular updates.

Let's now move on to the end-user experience (slide 14), now that we're familiar with what the IT administrator looks at when approving an update. First of all, we've implemented notification area balloons that are used when available. These are available on Windows 2000 and above. On the Windows NT® 4.0 systems we have a traditional dialog message that appears on the user's desktop to inform them of what's going on. These dialogs also provide additional details when the end users are interested in knowing what the list of updates is and it also provides the means to expose any of the corporate branding that has been applied to help educate end users about the intent of the updates.

One of the things that we've built into this is the concept of unattended use. As described in the earlier slide about the administrative wizard, the Distribute Software Updates Wizard, there's a countdown time that appears where the user is reminded that updates are needed, and the user can choose to install those updates or postpone that installation, if those updates have not yet reached their mandatory time. Because of that countdown timer, we enable the scenario of deploying updates to systems that are unattended for whatever reason. They could be servers in a data center. They could be users that are not logged in. They could be users that are logged in, but their console has been locked while they're at lunch.

Then this next bullet is about no enforcement all the way to immediate enforcement variations. This goes back to the feature of pre-expiring updates, making them optional forever, or giving them a postponement period of up to 40 days. One of the most important aspects of our feature set is to make every effort to reduce the number of system restarts that are required. What we do is multiple updates exist within a single SMS package and our agent is able to chain those together and install them one at a time and assess the changes that have occurs to the system as a result of each update being applied and build a list of reasons to restart the system. If any one of those updates has done something to the system, we're able to automatically restart the system, subject to the settings that have been placed in the Distribute Software Updates Wizard for this package.

Now let's take a look at some of the end-user experience during the installation process. What we start with is the countdown phase (slide 15). As I mentioned, on Windows 2000 and above, we have notification area balloons that provide a very intuitive and non-intrusive notification to the end user that updates are required, when they become required by, and who is requiring them. Notice here corporate security recommends that you install the latest software updates now. If the user clicks on this notification area balloon or if they're running on an NT 4.0 system, they'll see the traditional looking dialog at the bottom of this slide.

It gives them the amount of time remaining before those updates will automatically install. It also gives them an explanation of who's requiring them to be installed and three simple buttons. They can install the updates now, they can postpone them, or they can look at additional details.

This is where they can look at the individual graphics and corporate branding that have been applied, and see the list of the updates themselves, and those updates will have links. The end users that actually have access to the Internet will be able to use those links and educate themselves about the issues that those updates are intended to address. This is an important aspect of end-user awareness and education, as we all strive to make the corporate environment more secure.

Next is the progress phase (slide 16). The progress phase also has a notification area balloon that will appear while updates are being installed. This is important, because the installation process of an update and usually consumes a fair amount of disk activity and CPU overhead while it's being installed. This is the effort of making sure that the end user doesn't think that their system is being hacked while this activity is going on. If the user clicks on this balloon or if they're running on an NT 4.0 desktop, the traditional dialog will appear, which shows the individual update progress as they're being installed.

If these updates are time-consuming and the grace period has not expired for the updates, the user can click the Postpone button, at which point they'll be prompted with a confirmation that they want to defer the installation of the updates, and these updates will be rescheduled and reapplied later. They can also look at details about the updates.

Finally, we have the completed phase (slide 17). This is a simple confirmation to the end user that updates have been installed and we're all done. In some cases, if a system restart is required and hasn't been explicitly suppressed by the corporate administrator, there will be an additional dialog that appears that looks similar to the "installation complete" dialog, but it will ask the end user to restart their system. In addition, if the grace period has become expired and restarts have not been suppressed explicitly, the system will automatically restart and the user will not be able to postpone that restart. This is where the "force applications closed" feature comes into play, which provides a high level of assurance that the system will restart when the corporate administrator has required it to be restarted.

We have seen some really interesting features, but they get even more interesting now when we look at reporting (slide 18). In this section, we're going to be talking about some fixes that we have included in the Web Reporting tool that many of you are already using. We've also added new reports and a specific add-in module for software updates.

We have more than 12 new sample reports for software updates that you can leverage to create custom reports or use as they are in the standard reports form that they're in. We've also included the license true-up report for Microsoft applications in this updated version of the Web Reporting tool.

The next slide here gives you a hint of some of the new reports that are being included that are specific to managing software updates (slide 19). You can get a list of installed software updates for a specific machine. You can count the installed software updates by their category. A category, for example, is either Office or security with this release of the Value Pack.

You can also look at the installation rate for specific updates. This installation rate is based on the inventory data that we enhanced to describe the date and time that individual updates were initially inventoried, as well as when they were initially detected as being installed. You can also look at the machines that have a specific software update installed or machines with any software update installed.

Then we have a series of related reports that don't talk about what is installed, but rather those things that are applicable or missing from the individual clients. Then down at the bottom we have two additional reports that provide some high-level enterprise-wide summaries for all updates and how many instances are installed and missing, which is a hugely valuable dashboard to refer to on a regular basis to understand the level of compliance for vulnerabilities within your enterprise.

On our next slide, we actually have an example of one of these reports (slide 20). This is Count of applicable software updates by type – "Security". These are all the critical updates that are missing at the enterprise level. My enterprise is slightly smaller than yours. In this particular case, I have three clients that are requesting the XMLHTTP update.

In this report I can see the QNumber and the bulletin ID, the product that's affected, and what's not visible on this screen that's off to the right-hand side, is all of the links for these updates that take you to the security bulletin itself. Right from this report you can look at your exposure, click a link, read about the vulnerability, and make a decision as to whether or not this is an interesting update for you to deploy.

Our next slide is an example of how we can report on service levels for updates (slide 21). We have service level reports available that cover the detection rate for updates, as well as the installation rate for updates. In this report you can see that at the initial hour 0 (zero) we had what appears to be 60 percent of these updates detected. You can see that number increase as the hours increase, ultimately reaching 100 percent detection. There is a related report that will address the installation rate for these items, which actually covers the deployment scenario so that you can track the success of the individual deployments of these updates.

You can, of course, customize these reports using the built-in Custom Reports feature of the Web Reporting tool. We're also documenting the schema. The schema will appear in the query picker tree control that's built into the Custom Reports feature, and we also have a detailed description of these properties available in the online help for the Web Reporting tool in this update.

Our next slide goes into a little bit of a review of what I just mentioned about the document schema (slide 22). It's important to keep in mind that the SMS product has a lot of other interesting inventory schema that can help you build compelling reports that leverage both the existing SMS inventory data, as well as the new software updates inventory data that we're adding.

To get access to the documented schema for the SMS product, MSDN documents this inventory schema. There will be a link to that schema available in the Web Reporting tool release notes.

Let's talk about our schedule (slide 23). We are in beta at present. We have been in beta for several months. Our most current beta release is build 95, and we do have numerous customers that are using this in a limited production environment. We're getting some good validation from them, but we need more. We need to see some larger numbers of deployments into production. This is a very important aspect of how we validate that we've done the right thing; that we've got the right features, the right performance, and the right stability for managing critical updates.

Our release plans call for a third quarter release. At present we are tracking to around the middle of September. We will be using the Microsoft Baseline Security Analyzer as the technology used for the discovery of the critical updates in your environment. The Microsoft Baseline Security Analyzer also has a lot of other very interesting functionality for you.

Let's talk about our call to action (slide 24). Now we have an internal nomination process to get customers on the beta program. If you've got a Microsoft account rep or someone you know in PSS, go ahead and request that they nominate you for the beta program. Once you're nominated, please, be as active in the beta program as you can be.

These are relatively small tools. We don't believe that they'll consume a significant portion of time during the evaluation. We have excellent documentation available, a deployment guide, and with our next update to our release candidate build, we'll also be providing a sample Microsoft Project template that will call out some of the interesting milestones and verification steps that you can use during the evaluation and production deployment of software update management.

Clearly we want to know what needs to be improved for your needs. We have various feedback mechanisms in place through the beta program, as well as e-mail aliases that you can mail. Those are all made available to you through the beta program. Using these tools, we believe that you can get more secure. Specifically using the reporting features and a lot of our service-level investment we think you can prove it, and that's what our initial goals were. We think we have the right feature set for those and we need your help to go ahead and validate that we've done the right thing.

That concludes the formal aspect of the presentation. We have a good amount of time available to us for Q&A and are very interested in any comments or feedback or questions that you have. I'll go ahead and give control back to Otto.

Otto Cate: Great. Thanks for the presentation, Rob. Before we move into the Q&A portion of the support WebCast today I just have a couple of quick program notes I'd like to share with our audience. If you'd like to have a copy of the PowerPoint® slides, they are available for download now on the Web site. The on-demand streaming media is also available from the Past Support WebCast page. To access all of this information, including details about upcoming Support WebCasts, an easy to remember URL is http://support.microsoft.com/webcasts/.

We'll go ahead and jump into the Q&A here. Just a reminder, the Q&A portion of the Support WebCast is really intended to encourage further discussion of the topic at hand today. If you need more complex technical assistance, feel free to submit an incident on the Web or contact PSS via phone and speak to a Support Professional.

First question here: How are rollbacks of updates handled?

Rob: In this release, we do not have a feature that allows for a managed uninstall or rollback, but we are considering adding some features that are in this area in a future release. We made a decision that there was enough pain out there in dealing with updates that we needed to provide a solution in a very timely manner. So there are a number of features that we needed to defer so we could at least provide a minimally acceptable level of management solution.

Otto: You may have covered some of this in the presentation concerning reboots, but I'll throw this out here just for clarification if nothing else. When a security update says that it needs to reboot to complete and it gives you that option of rebooting now or doing it later, is it possible to mess up the update by selecting later and then installing something else before doing that reboot?

Rob: As long as the updates are being installed through our client agent, we have a means to make sure that the files that are installed on the system are not downgraded or messed up by subsequent updates being installed. What we're doing is we're using the mechanism that is implemented by the tool known as QChain. Many of you who have applied the updates yourselves and tried to hook them together, you'll find QChain available in a Microsoft Knowledge Base article. We're doing the same thing as what QChain does.

Follow-up answer: Knowledge Base article, Q296861, "Use QChain.exe to Install Multiple Hotfixes with Only One Reboot" contains the information about the QChain tool.

Otto: Some patches that don't write to the system in Add/Remove or NT uninstall or the registry, something of that nature, how can we track those updates?

Rob: Updates that do not appear to register themselves in any explicit way in the system can actually be tracked using this solution. Because what we do at the client level is we record the existence of that update in a new WMI class known as Win32_patchstate. This is the WMI class that becomes consumed by the SMS Hardware Inventory agent. But what's really nice is that, in addition to SMS aggregating this data into, for example, these new reports that we've shown you, WMI is a queryable interface on the client itself. As recent as the system has been scanned for updates, you can query WMI using many means, Visual Basic® (VB) script, for example. You can get a list of those updates, even if they haven't properly registered themselves with Add/Remove Programs.

Otto: Are hotfixes considered custom updates and are they supported in this Value Pack?

Rob: There are a number of terms that describe updates that are floating around. There are hotfixes and QFEs, patches, updates, and let me just give you my perspective on that. A QFE and a hotfix are in fact very similar, if not the same thing. Those are updates, which are not publicly available. You can get those through Product Support on a per-request basis. What we currently manage through the Value Pack are Office Updates and Critical Updates, the Critical Updates having been described by security bulletins. Those updates are publicly released fixes, which have a high level of quality and localization available, which is not typically available for the average QFE fix that you obtain directly from PSS. Our current feature set does not include the updates that you get privately from PSS. It just covers publicly available Office Updates and publicly available Critical Updates.

Otto: Can you give us, maybe, a little more detail on how the inventory keeps track of the hotfixes and updates?

Rob: What happens on the client level is an SMS advertisement on a schedule runs once a week by default, and it audits the client using the Automated Security Bulletin tool. At present, HFNetChk will be migrating to MBSA in the very near future. Those tools interpret MSSecure.xml and provide results. You can run these tools yourself separately. What the Value Pack does is it takes those results and just converts them into a format that can be consumed by SMS. Once that's happened, they're made accessible through the site database as if they were normal SMS inventory.

Otto: Concerning the notification balloons, do you know if those will still show up if users have disabled balloons with XP PowerToys or something of that nature?

Rob: We have not actually done a deep level of investigation for cases like that, where balloons have been explicitly suppressed by some add-on tool. I suspect that our balloons would not appear if balloons have been suppressed, and that would be an important consideration in how these tools were being implemented, because these notification balloons are a bit important.

Otto: For these updates to successfully process, etc., the users must be logged in at the time. Is that correct? Does this include servers? I ask this because most of our servers are not necessarily always logged in.

Rob: That's an excellent question. Our user interface has been designed to assume that there may not be a user present, but architecturally there doesn't even need to be a user logged in. Because we're using the SMS software distribution infrastructure, it has the built-in capability to install software and run scripts on a system where there is no user logged in. This is one of the number-one reasons that we included the feature of an automatic countdown timer, so that in case there is no user present, we will do the right thing subject to the settings that the corporate administrator has put in place for the Value Pack tools. Having done the right thing, either install or postpone, our agent gets out of the way and allows any other software distribution activities that SMS was scheduled to perform to go ahead and take place.

Otto: Does SMS have the ability to disable antivirus programs before running the updates to minimize conflicts?

Rob: That's another area similar to the notification balloon disabling question that we have not dug into at a great level of depth. I can't answer your question explicitly one way or the other. The SMS product itself does not explicitly have a feature that allows the conditional disabling of antivirus programs. That's a particular challenge, because there are so many different antivirus programs that we would need to somehow account for, either in testing or in exposing a general-purpose mechanism for turning them off conditionally. It's an interesting point and I'll make a note of that, and do some additional research to see if there are some actual problems related to this that we can address in a future release.

Otto: That's good feedback. Software update services, or SUSs, use Group Policy to specify which server to query for updates. Are those Group Policy object settings for this tool, also? How do GPO settings that are applied using SUS affect clients that'll be using the SMS tool here instead?

Rob: First off, we have some positioning materials that are available on our public Web site that describe how SUS 1.0 and the SMS Value Pack for software update management are intended to be positioned. Our goal for a given customer is to not actually use both of these in the same environment. An SMS customer should be using the Value Pack to provide those features for managing critical updates and to not have to deploy Software Update Services as a redundant infrastructure. SMS does not have dependencies on Group Policy or Active Directory®, nor does the Value Pack.

So if you do have SUS deployed and are configuring it through Group Policy, and you deploy the SMS Value Pack onto the same managed clients, we don't expect that there'll be conflicts, but there are unnecessary administrative overheads that are involved in that scenario. You need to look at the feature set that each of these solutions provide you and it's best to pick one and go with it and not to have both. If there's some point of your question I didn't answer, because that was actually a fairly broad-reaching question, go ahead and submit a further clarification, if you don't mind.

Otto: Is it possible to get a list of installed updates and patches that were not necessarily deployed with SMS, but maybe done through software inventory?

Rob: We do have features available through the inventory schema that will allow you to answer that question. For example, when you go through the process of approving a software update through the Value Pack, we write into the hardware inventory data for that update, the name of the SMS package that was used to deploy that update. So if you haven't actually deployed an update using the Value Pack, that property will not be completed with the name of the package and you can use that combined with the status message feature to have a rather accurate way of discriminating updates that were and were not installed using the Value Pack. You can get more information about these properties by referring to the schema documentation that's available in the Web Reporting tool.

Otto: Just a further clarification on the SUS versus SMS: Are you saying that it's probably not a good idea to use SUS and SMS with Value Pack at the same time or in the same scenario?

Rob: It's not a good/bad type of scenario. Each of these offerings has different features. One of the most important things to keep in mind is that any time you deploy a solution there is some level of cost in overhead involved in doing that. Each customer needs to evaluate the features that are provided by these solutions and manage costs accordingly. We feel that the feature set that is available within the Value Pack for SMSm for customers who have already deployed SMS or it is a viable solution to other problems, that the Value Pack should be the exclusive answer to the question.

We do know that there are cases where SMS is perhaps too much for a particular customer environment. SMS is targeted at the larger customer environments because of some of its advanced scheduling and network utilization throttling features that are not necessarily available through other offerings. So it's important that you refer to the positioning document that's on the external Web. Go to http://www.microsoft.com/smserver/ and you should have a link available there that will take you to the actual positioning materials that will give you a better answer to the question of SUS versus SMS in the Value Pack. {Editor’s note: The specific link to that information is http://www.microsoft.com/smserver/evaluation/overview/secure.asp.}

Otto: The next question here: If we're not at SP3 yet for Windows 2000, do you know if there are any hotfix requirements that clients will need for QFE pulls?

Rob: Our current level of system requirement for the Value Pack is relatively independent of the service pack level or the individual QFE level of the clients in the operating system version that they're running. We do have a minimum requirement of NT 4.0 SP4 for the inventory components. We will apply certain updates, as they are available for the NT 4.0 SP4 and above platform. NT 4.0 SP6a is the latest service pack that you should be running for that version of the operating system. All of the other system requirements that we observe are the same as the SMS base product supports. However, we do require SMS 2.0 SP3 or above and we recommend SMS 2.0 SP4.

Otto: Will the installation of this Value Pack affect my existing Web reports? They're custom Web reports that I created using my own SQL stored procedures.

Rob: There should be no ill effects that I'm aware of when installing the Web Reporting tool, the current version that's available or the Value Pack version, as long as there are not naming convention conflicts with any of the view names or stored procedures or any of that sort that you have created on your own. But I do need to remind you that the creation of stored procedures and custom views within the SMS database may not be a supportable configuration. You would certainly want to consult with your Product Support folks to find out if the things that you have done to customize the objects in your SMS database are supportable or if they'll end up being a conflict with some future product release of SMS.

Let me add one more comment there. The Web Reporting tool that's available does have a custom report feature that's built into it. You may want to consider migrating your SQL-based reports over to the Web Reporting tool and its use of the views, because those same views will be consistently available when you go to update to SMS 2003, for example.

Otto: Concerning the Web Page Reporting tool: Stored procedures need to be manually modified to reflect the MS SQL 850 multilingual code page, which is case sensitive. All table names and column names need to reflect case. Is that an issue that you've seen or is there any kind of workaround?

Rob: It seems to be a rather general-purpose question around case sensitivity and SQL, and how the SMS core product is or is not sensitive to sort order and case sensitivity. My understanding is that we have written our solutions in a manner that's consistent with case-sensitive SQL settings, but certainly that would be a very valuable area that I would love to get your feedback on through the beta program, if there are some problems in that area.

Otto: When you mentioned that unattended use is built in, what happens to a client that's locked or unattended? Basically we're just looking at not only what happens, but is the countdown itself skipped?

Rob: The countdown feature and any of the policy settings that were put into place for what the default action is, either to install or to postpone after that countdown expires, all apply to all instances of the agent that is being run on a client. We don't distinguish between the situation of there being a user logged in, a user logged in with their console locked, or a user not being logged in whatsoever. All of those are treated the same way. That's primarily why we've exposed the countdown feature and the ability to automatically defer the installation until the updates have become required.

Otto: If you give a user access to the Internet and you're centralizing the updates with SMS, can you and should you prevent a user from downloading a security fix separately from the Internet?

Rob: What we've done with the Value Pack is we have created a situation where the managed nodes in the enterprise have no Internet access requirement whatsoever. SMS is used completely as the conduit to get an update from the Internet into the SMS infrastructure and down to individual client computers. If an end user does happen to install a critical update in what we call "out of band" meaning not using SMS (for example using the Windows Update site, the AutoUpdate client for Windows Update, or Software Update Services, if that's configured), that doesn't represent a problem. When the Value Pack comes along on its scheduled interval, it checks the client for missing and installed updates. Any updates that the user has installed on their own will simply become detected as installed updates. There should be no conflicts, depending on where those updates came from.

Otto: Does the modular design update work for all back-end products as well, like SQL 2000, Exchange, etc.? I'm not exactly sure what they're referencing there.

Rob: I think I understand this question. There are two things to mention here. The Microsoft Office product group publishes a tool, which inventories all Office updates on a system. Included in that tool are Office products such as SharePoint™, which do have a small version of SQL Server™ in it, known as MSDE. In fact there are security updates that apply to that, which are detectable and deployable through the Value Pack, because we're using this tool that the Office team has published. There is partial "yes" answer, depending on the specific supported products for the underlying technologies that we're using in the Value Pack.

The other underlying technology that we're using in the Value Pack is HFNetChk and/or Microsoft Baseline Security Analyzer. Our current beta builds are using HFNetChk and, prior to our RTM, we'll be converting to the Microsoft Baseline Security Analyzer. Both of those technologies use MSSecure.xml, which describes issues that have been published in security bulletins.

Sometimes there are bulletins that do relate to SQL Server or Exchange or other products. Our level of support for those other types of products like SQL Server and Exchange are subject to the degree of support provided by HFNetChk or MBSA. As I understand it, products such as those do have plans in place to become available through MBSA and/or HFNetChk. I can't comment specifically about those products in a time frame, but what you can do is download HFNetChk or MBSA from the Microsoft Download Center and check them out to see all the different products that they do support for reporting software updates. Those are the updates that the Value Pack will be providing support for as well.

Otto: I know we're still in beta here. Do you know if there is any public information available yet on licensing or pricing or anything of that nature for this Value Pack?

Rob: Absolutely. The Value Pack is intended to be free of charge to customers who currently have valid SMS licenses. This is effectively a free service to Microsoft SMS customers to manage their critical updates. Any SMS client that has a valid CAL can be managed by Value Pack.

Otto: Can this tool be used for other packages, other than updates and Security Updates and Office Updates?

Rob: This release is limited to Office Updates and Critical Updates that are described by Microsoft security bulletins. We are reviewing plans for enhancement. We don't have specifics available or commitments to those enhancements at this point. We haven't even released our first version yet, so we really want to get this first version out and look at future enhancements as a separate activity.

We do see great value, however, in being able to support what we call custom updates, which would literally be any type of update that can be described with various rules of file version or registry key identification mechanisms.

Otto: Can you give us an idea of how this Value Pack will be supported when SMS 2003 is released? Will it integrate? I'm not really sure if there is any public information about it.

Rob: We have a compelling need for our SMS 2003 early adopters that will be using SMS 2.0 and the Value Pack to manage critical updates in production so that they can continue to manage their critical updates when they deploy SMS 2003 Beta into their production environment. We will be making available beta versions of the necessary Value Pack tools to those SMS 2003 beta customers. Then when SMS 2003 publicly releases, we will provide the public release of any affected Value Pack items that became necessary to remain compatible and consistent with SMS 2003.

Otto: I wanted to verify the client operating systems that are supported with distribution Software Updates Services? That may be a little outside the scope. We're talking about SUS there.

Rob: I do know that Software Update Services does require Windows 2000 minimum. I don't have much more detail than that about if it requires any individual updates or service pack minimums.

Otto: Is there a Web site that you have off the top of your head there?

Rob: Not off the top of my head, but I'm sure we can do some follow up and get you a link to the answer.

Follow-up answer: The Knowledge Base article, Q322365, "Server Requirements and Recommendations for Installing Microsoft Software Update Services" contains the information you need about the installation requirements.

Otto: While we're on that subject, there are a few users that want to verify whether the Value Pack will support updates on Windows 9x clients.

Rob: As I mentioned, in terms of the HFNetChk or BMSA support for different products and operating systems, there are limitations there and those tools do not support Windows 98 type operating system versions. However, the Office Update solution does support that level of operating system, but in our initial version of the Value Pack we're not supporting that operating system version.

We are considering it for a future Value Pack release to enable the management of the Office Updates on the Windows 98 platform. We don't have a commitment that we're going to be able to do that, but it is under consideration for a future version. I wanted to provide a more specific link to folks out there who are interested in looking at SUS versus SMS positioning. It's http://www.microsoft.com/smserver/evaluation/overview/secure.asp. Down at the bottom of that page are some links to the positioning materials.

Otto: Do you know if there are any plans to include the features that you've talked about, like being able to defer and install into the basic functionality of SMS on a per-application distribution and not just for the security update side? I know you briefly touched on that. I'm not sure how much information is available.

Rob: Conceptually that question is very intriguing, very valuable. We would become enabled by our ability to offer the custom update functionality, because you would then have the ability to describe entire applications with applicability rules, in addition to the applicability rules for specific updates. As a concept, we see its value in how we provided certain features that are Value Pack-specific and we will be going through a process of reconciling the model of software distribution and the individual features of software distribution in the product version that we release that follows SMS 2003, which is some ways away.

In terms of looking at the features that the Value Pack provides today for SMS 2.0, those features will be rather consistent with Value Pack features for software updates when used in an SMS 2003 environment.

Otto: I'm interested in how a client determines what updates to request, specifically for the Office updates. Where does it get the information for what patches are available and does it use client patches or full file admin patches?

Rob: That is an excellent question. I'll answer the second part first. It uses client-side patches, although we are working on a white paper that will help you manage both client-side and server-image patches for Office products using SMS. This version of the Value Pack just handles the client-side patches. How it does that is specific to the Office tool that you can download from the Download Center as well, if you want to investigate the Office tool. You can search on "Office Update Inventory Tool" and that will take you to the appropriate links for that tool.

{Editor’s note: The Knowledge Base article Q312982, "OFF: Office Update Inventory Tool Version 1.5 Readme," contains the information about the Office Update Inventory tool and links to download it.}

That's what uses the Windows Installer interface for querying the installed versions of Office at the component level. It supports Office 2000 and above, on Windows 98 and above, I believe. That tool itself includes a catalog that is essentially a dictionary of updates and what they look like when they're installed and when they're missing. Through your download of that tool, you can look at the mechanisms in greater detail, the XML file that they use and so forth.

Otto: What is the procedure for an administrator to update an administrative installation point and can I distribute QFEs with this tool?

Rob: That sounds related to the first question about Office and updating the server images. At present, the Value Pack is only looking at the client patches. Managing server images is a more advanced scenario, which we don't have functionality built in for at present. The other question I believe we may have answered relating to distribution of QFEs. QFEs are privately available from PSS. They're not published in the security bulletins or the Office Updates, and as such, aren't yet supported by the Value Pack, but we are considering some functionality that would open the door to management of QFEs, hotfixes, and what have you.

Otto: How will new updates be handled after the initial installation? Will updates now include .sms and/or .pdf files?

Rob: This is a question about how updates published by Microsoft will carry with them built-in integration with SMS. We're looking into this area, but we don't have any committed plans for published updates to automatically integrate with SMS except through the way that we have currently implemented in the Value Pack, where updates are described in a dictionary. That dictionary allows us to inventory the system for what's missing and what's installed. That inventory will include the links to obtain that update.

As we extend that to include other types of updates, then we expect that that same dictionary data would become available, so that you can easily obtain the update, and consume it into an SMS package using the distribute software update features that already exist.

Otto: How does the Value Pack interact with corporate update server?

Rob: At present the Value Pack doesn't interact with the Windows catalog in any sense. It exclusively interacts with Office Update and with security bulletins described by MSSecure.xml. MSSecure.xml is independent from the Windows catalog; they are different technologies.

Otto: Is this another client agent that will have to be installed along with the SMS agent? How is that going to work?

Rob: We automatically do the right thing on clients, in terms of managing a client agent. Our client agent for installation of updates actually runs from within an SMS package. It does not have an installation requirement or prerequisite in the terms of the existing SMS client agents that you're familiar with. This is a very pure software distribution scenario that runs from an SMS package.

We do take an extra step with the inventory tool, and have the ability to lend that from a cache on the individual client to manage network utilization much more efficiently, but that process is automatic and doesn't carry with it any additional steps in terms of installing or configuring.

Otto: You may have already touched on this as far as reboots are concerned. I'm going to go ahead and throw this out just in case, though. Can any amount of SMS updates and upgrades be installed within one boot cycle or is there a limit?

Rob: At present we have no limits on the number of updates that you can incorporate into an SMS package. At present we do have a limitation that Office Updates and Critical Updates will not be commingled in the same SMS package. Any of the updates that you obtain through the Office Update Inventory tool would be limited to being together, so to speak. Updates that are described by MSSecure.xml and instrumented by MBSA or HFNetChk would need to be contained in their own SMS package, but within that there are no limits in terms of the numbers of updates. Those updates become installed. We evaluate the system using QChain logic and fix up any needed registry settings so that after the system restarts, only the latest version of all files is left behind on the system.

Otto: Touching on the linked packages, etc., there. Is it possible to specify one package as being basically dependent on another package running?

Rob: That's a very interesting question. I would need to think about it a bit more to give you a more categorical answer, but at present we much prefer that updates be kept within the same SMS package if at all possible, because after you start spanning multiple packages together, you lose the ability to better manage the number of required system restarts, because what happens when our installation agent runs and applies the updates is that it attempts to do this optimization and do a single restart of the system, if necessary, for that instance of program execution. That carries with it the requirement that it be a single package execution model.

If you chain two packages together, there's a necessary side effect that you may have to reboot the system two times instead of one time, depending on what those updates in those other packages did to the system.

Otto: Can you force the inventory process after applying a patch or upgrade?

Rob: Absolutely. In the Distribute Software Updates Wizard there is a check box that does exactly that. How that works is if it's enabled to bypass the normal scheduled inventory, we keep track of changes that occur to the individual updates. If, for example, the installation agent runs and it decides that there are no changes to the updates, but you still have that check box disabled so that the scheduled inventory interval will be bypassed, because there have been no changes to the updates, we won't run the inventory agent, which is important from a performance standpoint that you only trigger the inventory agent to run, if there have actually been changes to the software updates.

In addition to that, the inventory component that we're providing has a mechanism in it where you can trigger that hardware inventory agent independently of the installation process that occurs. To answer your question, there's great flexibility.

Otto: This question might be a little outside the scope as well. It appears that we're possibly talking about scripting here: Is there a new WMI class available without installing software?

Rob: What is required to get the Win32_patchstate WMI class on the client and populated with software updates, is that you do have to run one of our update inventory tools, either for Office or Security Updates, on that client. If that doesn't answer your question, go ahead and submit a further clarifying question.

Otto: What security context is required for both agent and security updates?

Rob: We do require local administrative rights; however, conveniently, SMS provides those.

Otto: If I have an update for my CRM program, can I use Distribute Software Update Wizard to deploy that or is the update wizard only for Microsoft products and not for third-party ones?

Rob: This version of the Value Pack explicitly supports Office Updates and Critical Updates for Microsoft security bulletins. We are considering opening a broader level of support for other updates, including non-Microsoft updates, in a future version, but we don't have a committed plan at present. But we do understand the compelling value of being able to manage updates of all forms, using the same management infrastructure, SMS.

Otto: We have a user here that says they've downloaded the Value Pack and they're wondering if the Software Update Management tool is available within the Value Pack or something of that nature. I'll read the question: I've downloaded SMS Value Pack. Is this software update management tool, a new tool that will be added to the Value Pack?

Rob: They may have obtained a preview version of the Value Pack, but if they're on the beta program and they go to http://www.betaplace.com/ and log in with their Beta ID, they will see about nine individual tools that are in the Value Pack. The Distribute Software Updates Wizard and the related Update Inventory tools are prominently listed at the top of the list of downloads.

Otto: You may have touched on this a little bit. How does this product determine which updates should go to an NT 4.0 machine versus an XP machine? If this is done by how the machine reports to SMS, then can you limit a patch that works on multi-OS platforms to just a particular platform?

Rob: This is an aspect of the technology that we delegate applicability checks to. The best way to answer this question, I think, would be to refer you to the current HFNetChk or MBSA downloads, and for you to go ahead and run those on the systems that you have in mind. I think what you'll find is that when run on an NT 4.0-based system, that there will be certain updates that it describes as being available. On a Windows 2000 system there'll be a different set of updates and on Windows XP there'll be a different set of updates.

Now one example that comes to mind is an update to the XML Parser for the XML HTTP vulnerability for XML Parser versions 2.0, 3.0, and 4.0. Each of those versions would potentially be applicable on any or all of those operating system versions. How it becomes applicable is based on how those tools interpret the need. So it will not describe the need for the XML 4.0 patch unless the XML 4.0 parser was already detected to be present on that system. These are very granular checks. I think I understand the nature of your question and the best answer is that it is not a conflict, that there are not problems with that kind of overlap scenario.

Otto: Just a further clarification on how the tool checks to see if an update is installed: Does it just check the registry or does it check all files?

Rob: For the Office updates, it's using the Windows Installer interface to query the system, which is a rather robust level of checking. The HFNetChk and the MBSA tools use specific rules that are encoded in the MSSecure.xml file. Those rules include file-level versions, CRC checks, file names, and file existence. It supports specific folder conventions for looking at files in addition to registry-specific checks as well.

I do not believe that any of them are exclusive to a registry check. I believe the vast majority of them are based on file version and CRC types of applicability rules. So it's a rather robust level of checking.

Otto: A couple of questions, going back to the balloon question that we had earlier: Is there a way to force standard notification dialog boxes instead of using the balloons if you're on Windows 2000?

Rob: We have a design change that's registered in our bug database for that, and we are not providing that in this version of the Value Pack, but we do remain open to suggestion. I'm very much interested in understanding your requirement better so we can prioritize that if necessary. Feel free to post a message on the newsgroups or a suggestion in the bug reporting database that the beta program provides for you, and we can do some follow-up offline to assess the priority of that request.

Otto: Related to balloon messages: Would there be a way to precede an update with another update that would re-enable the balloon message feature?

Rob: This sounds a lot more like the tool that turns off the notification balloons and wanting to conditionally turn that on and off. If you know how to turn that on and off, because this is just an SMS package, you certainly have the means to customize the scenario to run something first that would handle this or to place our installation agent within a script of your own creation that can manage that. Because we're using SMS for this, there are a tremendous number of customizations that are available to you.

Otto: Can I update remote users who are working from home, for instance, using this tool?

Rob: Our ability to update a client is specifically based on the SMS client agents being installed and active on that system. If your corporate policy is that desktop systems that are in a home office environment are to be managed by the SMS infrastructure, then the answer to that question is "yes".

Otto: Another question related to notification: Is it possible to disable the notification on the client end altogether?

Rob: A fully silent model. Just recently we did implement a design change, which allows no notification balloons, and no traditional dialog to appear. The only manifestation of a system being updated is if a request for a system restart was permitted and initiated by our agent that the standard (there's a built-in system restart UI component that is an option when doing a remote system restart call through one of the system services) that UI will appear and its countdown will be consistent with the countdown that was in place already for the client agent. So there is a way to suppress, effectively, all UI, except very minimal UI, only when restarts are in progress.

Otto: If an update can be set to deploy at a certain time to, say, 100 machines, does it do the update 1 machine at a time or does it do them all in parallel?

Rob: They're handled in parallel, consistent with the targeting group, the SMS collection that you advertised to. The individual clients activate nearly at the same time, and will start applying the updates. We also have a control that allows you to apply the schedule on a universal coordinated time basis. It will bypass any time zone implications and globally, you can have all clients activate and install updates at the same time. Our default is to observe the time zone setting for the advertisement and the grace period for the individual updates, though.

Otto: Another question related to SUS versus SMS: I feel that the SMS package will better integrate in my environment. If I'm currently using SUS, would it be recommended to remove the Group Policy object templates before upgrading to SMS, etc.?

Rob: It's probably best to first to make sure that you have SMS and the Value Pack deployed to your satisfaction and then execute a cutover at that point, because in the meantime you're still getting value from having the Software Update Services operating in your environment, keeping systems current.

Otto: What general number would you consider as a "large" environment?

Rob: I believe that there is a number that begins in the 3,000 to 5,000 range and goes up from there. Some of our largest SMS customers have 100,000 to 200,000 clients that are being managed. There's a tremendous range in diversity, but I do believe that it begins in the 3,000 to 5,000 range.

Otto: Does the Value Pack require Active Directory?

Rob: The Value Pack and SMS 2.0 do not require the Active Directory.

Otto: If I was to download the Value Pack, would I be able to only use the Web Reporting tool?

Rob: We do not have a requirement that you use other Value Pack tools in order to get the Web Reporting component. However, there's tremendous value in managing your updates using the Value Pack independently from that Web Reporting tool.

Otto: This is a good question: If a machine is taken off the network and then a new machine is brought back up with the same machine name, do the updates still get deployed?

Rob: This is a general SMS-specific scenario. The Value Pack, in its ability to send updates to a client, is very agnostic about that particular scenario of a machine being re-imaged or its machine name being changed, its SMS unique identifier being changed. As long as that system becomes evaluated to be a part of the targeting group, the collection that the updates have been advertised to, that client will get updated or re-updated as soon as software distribution executes the SMS package for that client.

Otto: If an end user installs an update that is not approved by the administrator, is there a way to keep truly standardized desktops? This is kind of a general SMS question.

Rob: It is and it's interesting from a Value Pack standpoint, because Value Pack has the means to at least report to you that an update has been installed that is not a part of an approved list of updates. So you can detect it. However, with the current feature set, there isn't the means for you to proactively prevent it or even retroactively prevent it, but at least you'll know the pervasiveness of that situation.

Otto: Can SMS 2.0 and the Value Pack be loaded on RC1 of .NET server?

Rob: That is subject to the support available for SMS 2.0 on .NET Server. We have been doing internal tests and have remedied all of the currently known issues that relate to .NET Server, but again, we have the requirement that the SMS 2.0 product be available with .NET Server support before the Value Pack would actually be supportable in that configuration.

Otto: Another licensing question: Is the Value Pack available for evaluation for those who are using the evaluation version of SMS from their TechNet subscriptions or is it final release code license only?

Rob: I'm not aware of any restrictions to the beta program, so you should be able to become nominated and a part of the beta program and use the Value Pack beta on your evaluation version of SMS. The requirement of having a validly licensed SMS product will exist at the public release of the Value Pack, however.

Otto: If I install the beta version here on my production site, will I be able to easily update to the final release and would it require any uninstall or reinstall?

Rob: We do support what we call build-to-build upgrade. As you move from one beta release to the next and then to the final release, we will be testing and supporting that any persistent data is appropriately upgraded. We do, however, have a process during the upgrade that may require some components to be uninstalled and then reinstalled with new file versions. There is an item to mention with respect to the packages themselves that contain software updates. Inside those packages, we have an installation agent and essentially a dictionary that describes the approved updates.

The way that those items become upgraded is by opening those packages in the Distribute Software Updates Wizard, the most current version of that wizard, and by stepping through the wizard with the Next buttons until you reach the Finish page. So you've effectively changed no settings. When you reach the Finish page, the wizard will upgrade the dictionary that's in that SMS package and it will upgrade the installation agent that's inside that SMS package. You would need to then upgrade individual packages on a case-by-case basis. There is a caveat there.

Otto: Can the user identify that the agent is installed on their client machine?

Rob: We don't actually install the agent on the machine. The user only has an awareness of software updates when, for example, the notification balloons would appear, indicating that there is some pending action necessary or in progress. That's a result of our use of the SMS software distribution feature for assignment schedules.

A good example is you can schedule our installation agent to run twice a day, once in the morning and once in the afternoon for example. The end user will have those two opportunities to apply updates that are optional and then after a certain number of days, the expiration date will arrive, where those updates become required. Then the user will not be able to postpone. Those updates will become installed. Then to conclude this scenario, a few days later, the next scheduled run of the agent occurs and it finds that there are no updates that are missing from the system that have been approved. In that situation there are no notification balloons. There's no work to do. So our agent will run, do its checks, and then silently terminate. However, it will be recording success and failure in the background, so the IT administrator can do follow up, even if the end user doesn't see any manifestation of the need for individual updates.

Otto: Final question that we have here: I want to be able to give a Web interface for the users, when user selects a piece of software from the Web page, like to be able to trigger SMS for that software deployment. Is that something that can theoretically be set up?

Rob: It is, but it's not in the scope of the Value Pack or managing software updates. What you'd want to do is check the platform SDK for Systems Management Server 2.0 and in there, there should be some sample scripts that allow you to add and remove systems from collections using scripts. So you can build some VBScript into an Active Server Page. The user can click on it and it will add their computer into a collection. By the next time that collection is evaluated, that particular package will become advertised to that system. I think you'll find some better detail and examples in the next update of the platform SDK that we do for SMS 2003.

Otto: With that, we've answered all the questions that were submitted today. I'm going to go ahead and wrap up the session here. I want to thank everyone for joining us and hope that the information was useful, and that everyone has the opportunity to tune in again in the near future. Feel free to go ahead and e-mail us any suggestions, comments about the show, or the WebCast program as a whole at supweb@microsoft.com. Thanks, everyone, and have a great day.