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

Heidi Moeller: Hello, and welcome to the Microsoft^® Support WebCast program. We'd like to thank all of you for joining us today. Our topic will be "What's New in Microsoft Systems Management Server 2.0, Service Pack 2," and our presenter will be Wally Mead. I'm Heidi Moeller and I'll be your host for today's session. We'll start this session with Wally's presentation and follow it up with a question and answer period when the presentation is finished.

We only answer questions submitted for the Support WebCast during the live event and you can submit your questions at any time during this live broadcast; however, we will hold off on answering those questions until the presentation is finished.

I'd now like to take a brief moment to introduce Wally. Wally joined Microsoft over eight years ago in the Training group. He now works for Product Support Services, developing and delivering training focused on Systems Management Server (SMS) 2.0 to the support professionals. During his time at Microsoft, Wally has developed training materials for all versions of SMS. Thanks so much for joining us again today, Wally.

Wally Mead: Thanks, Heidi. Welcome. Hopefully you'll find today's topic of SMS 2.0 Service Pack 2 updates and fixes worthwhile and beneficial. Heidi has already introduced me, so let's jump right in.

Our agenda for today is going to start off with a discussion on what Service Pack 2 is and what it is not. There's a lot of confusion out about what Service Pack 2 will accomplish in customer environments and I want to dispel some of those rumors. I'm not going to cover every single thing that's been modified or changed or fixed in Service Pack 2, I am basically concentrating on some of the major issues. There just isn't time to cover everything, nor would it be interesting to cover everything for you.

Then we want to spend some time talking about the prerequisites. What do you need to do to prepare your sites to apply Service Pack 2? Service Pack 2 is unique in that there are some prerequisites that must be taken care of, in certain cases, prior to application of the service pack, unlike Service Pack 1 was.

Then we want to spend some time on the installation. What are the different methods that you can use to acquire Service Pack 2 and how can you go about applying Service Pack 2 to your sites?

Then we'll spend considerable time on server-side updates. What are some of the component behavior changes that have been implemented as of Service Pack 2 that you need to be aware of? Things that will modify how the components operate; some of the network traffic that is being reduced; and things that will just help you in your support of your sites that are running Service Pack 2.

Then we'll spend a little bit of time focusing on the same issues for client sites. So for client computers, what are some of the things that have changed for behavior of the client components themselves, particularly looking at the upgrade process, upgrading from RTM code or Service Pack 1 up to Service Pack 2, and a few other client issues.

Then I want to touch on the release notes and the importance of the release notes and the fact that you should be reading those, prior to your application of Service Pack 2 and periodically once you've got Service Pack 2 installed.

So I will feel like this session has been very worthwhile if I can get you to remember two things when the session is all done, so you might want to write them down right now just in case you forget.

The first thing is, if you can remember the required hot fixes. There are required hot fixes for Service Pack 2 that we'll discuss, and if you can remember those when we're done with our session, I'm happy.

Second is the release notes. We find too many people aren't spending any time at all looking at our release notes. They contain a wealth of information as to not only things that have changed, but also things that you need to do at your site to be aware of how to apply, in this case, Service Pack 2; and also use and administration of the product. So if you can remember those two things when we're done with our session — required hot fixes and the release notes — then my job will have been complete.

Okay. What Service Pack 2 is and is not. Service Pack 2 is a set of fixes to SMS 2.0. These fixes can be applied to either the released version of SMS 2.0 — and throughout this presentation I'll call it the RTM code or RTM version — as well as Service Pack 1.

These fixes fix the major issues known at Service Pack 2 development time. We do not fix every single known issue with Service Pack 2. There are going to be things that are not solved in Service Pack 2 that you may encounter in your sites. Primarily, the areas of fixes for Service Pack 2 revolve around stability, scalability, large hierarchy environments, and performance.

Again, there are certainly areas that we're not fixing with Service Pack 2 because it's not a major issue or it only happens in a very isolated case. Or the development time just didn't warrant it, in trying to get Service Pack 2 out in a timely fashion and so on. Some of those issues will be fixed in Service Pack 3 and other releases of SMS.

Also, some people are confused and have a misconception that, once they apply Service Pack 2, they'll never have another problem with SMS 2.0, and that is certainly not the case. As I already stated, there are some issues that are not fixed with Service Pack 2, and we do know those and we understand those.

There are also things that we don't know in the product that you will find out for us once you're running [SMS]. At that point in time you'll find the issues, you'll call in to Product Support Services and PSS will reproduce it, and we'll get a bug filed and hopefully a hot fix for it. So there are going to be things that occur after the application of Service Pack 2 that we don't even know about yet. So just take that under advisement. Just be aware of that.

A couple of other things for Service Pack 2: Service Pack 2 adds Microsoft^® Windows^® 2000 support, so it adds support for Windows 2000 Professional, Server, and Advanced Server, in client and server roles. We discussed this quite a bit in last month's Support WebCast, so you can go back to the archives and find that if you need to.

Service Pack 2 provides support for Microsoft SQL Server 2000. So now Service Pack 2 will let you install your SMS 2.0 sites on top of SQL Server 6.5, Service Pack 4 later, Microsoft^® SQL Server™ 7.0, as well as SQL Server 2000. SP2 provides support for WMI version 1.5. Now, Service Pack 2 itself does not add or upgrade your existing implementation of WMI from version 1.1 on Microsoft^® Windows^® 95, Microsoft^® Windows^® 98, and Microsoft^® Windows NT^® boxes up to version 1.5, but it does add support for version 1.5. Version 1.5 is what Windows 2000 does install by default. So we do support that; and if you want to apply that manually to your sites, you can go ahead and download WMI 1.5 from the Microsoft location, from the downloads location for Windows 2000; and you can download WMI 1.5 and apply it manually to your sites.

Service Pack 2 also does provide support for NetWare 5, as well as NetWare IP. So we do supply support for NetWare 5 in binary emulation mode or NDS mode, as well as NetWare IP and we still do provide support for NetWare IPX.

The list of all the bug fixes that are documented is noted in the release notes. So in the release notes for Service Pack 2, it does point out the Knowledge Base (KB) article, and I'll mention it here for you if you want to look it up when it becomes published. That's Q258682, and that is documented in the release notes for Service Pack 2.

Okay, so prerequisites for Service Pack 2. What do you need to do to prepare your sites for application of Service Pack 2? The first thing again is that Service Pack 2 can be used to upgrade an existing RTM site or Service Pack 1 site. So either site can be upgraded to Service Pack 2 with the Service Pack 2 CD itself.

Now, in any site scenario you may have to apply some hot fixes. The requirements here are anytime you have multiple SMS sites sharing any type of site system (and that site system will primarily be logon points, which are the most common site system shared between sites), but anytime you have two SMS sites sharing site systems, then you are required to apply these hot fixes.

The hot fixes, there are two fixes for RTM version of SMS 2.0 as well as for Service Pack 1; they are supplied on the Service Pack 2 CD. When you get your Service Pack 2 CD, you go to the \SMS\QFE directory and under that directory there will be two folders: one listed as NoSP (that's for RTM code) and one for SP1 (which is for Service Pack 1). You need to apply the two hot fixes from the folder that is appropriate for your site, let your site implement those hot fixes, and then you're safe to apply Service Pack 2.

If you do not apply these hot fixes and you have logon points shared between versions of SMS, for example SP1 and Service Pack 2. So if one site upgrades to Service Pack 2 and another site is not upgraded to Service Pack 2 yet, and they're sharing logon points, what can happen is that client computers may get into a stuck state where they're trying to look at a Service Pack 2 implementation, but their site is Service Pack 1, and they can't upgrade. And you're also not allowed to in some cases install new clients, so if you want to have all those things function properly, you need to make sure that you apply these hot fixes to your sites prior to application or installation of Service Pack 2.

If you're a stand-alone site, in other words your site is not integrating or sharing site systems with any other site, then these hot fixes are not required. You can still apply them if you wish to, but they're not required in that case.

So you need to go through and read the release notes. This is documented very, very well in the release notes. So when you open up the release notes or Readme.htm on the Service Pack 2 CD, in big, red, bold letters at the top of the release notes after the normal introduction stuff, it talks about the required hot fixes. It tells you when you need them and it points you to the hot link in the Readme file for the installation and what hot fixes are required. So make sure you apply those.

One note is that if you do apply these hot fixes to your site and then you do upgrade to Service Pack 2, when you do upgrade to Service Pack 2, the Windows NT Logon Server Manager for SMS will not be triggered to update the logon points to Service Pack 2 immediately. If you don't apply these hot fixes, or if you install it fresh onsite or whatever, then NT logon Server Manager will be triggered to update logon points automatically.

But with this hot fix applied, Logon Server Manager will not upgrade the logon points immediately to SP2. It will upgrade those, but it will wait until its next polling cycle; and its next polling cycle will be when you've configured it as an Administrator on the Logon Settings tab of Windows Networking Logon Discovery or Windows Networking Logon Client Installation. So just be aware of that, that your logon points won't get updated to Service Pack 2 immediately, once you've updated everything else.

Okay, let's talk about SP2 installation. So again, SP2 can be used to upgrade from RTM or SP1 sites. There are three different installation options for Service Pack 2. These mirror the installation options for Service Pack 1. First off is a Web patch. From the Microsoft SMS Web site, which is http://www.microsoft.com/smsmgmt/ (SMS Management), when Service Pack 2 is released, you'll be able to download Service Pack 2 in a Web patch format.

What this allows you to do is to take a Service Pack 1 CD (it does not work on the RTM version of the CD, only Service Pack 1), copy it to the hard disk of a server, and then apply this Web patch to that Service Pack 1 CD hard disk image; that will upgrade your hard disk image to Service Pack 2. At that point, you can go ahead and upgrade your site to Service Pack 2 or install a new site that will be Service Pack 2 immediately.

So basically you're taking a Service Pack 1 CD and converting it to Service Pack 2. Once you've done the Web patch and the hard disk of the Service Pack 1 image, you can burn a new CD if you wish to, and that would be a Service Pack 2 CD.

Next, you can get an upgrade-only CD. So you can get a CD that will upgrade an existing RTM or Service Pack 1 site to Service Pack 2. You would not be able to install a brand-new SMS 2.0 Service Pack 2 site, only upgrade an existing SMS 2.0 site.

The last option is the slipstream CD. And eventually, all of the product CDs will be upgraded to Service Pack 2 on the actual product CD. So you go to a retailer and you buy SMS 2.0. Once the product has flowed through to the channel, then that CD itself, that product will be integrated with Service Pack 2, so you can just install it from that product CD and you'll have a Service Pack 2 installation.

We recommend you upgrade in a top-down manner, which means you upgrade your central site first to Service Pack 2. Then you just go down the hierarchy in that manner. If you don't do that, then you need to make sure that you at least upgrade your senior site first. Your senior site is going to be, by default, the site with the highest site code. So a site code of a ZZZ would be a senior site over a site of AAA. The senior site is the site that maintains and controls all your logon points, so you want to make sure you update your senior site first, the one site that you want to be that senior site.

In Service Pack 1, you had the ability of designating which site is going to be your senior site. If you have not manually designated your senior site, the first site to upgrade to Service Pack 2 becomes the senior site. Then after other sites upgrade to Service Pack 2, when you go through the election process to figure out which one should be the senior site of all the SP2 sites, and that would be the site again with the highest site code. If you have manually designated your senior site with a Senior.lst file, then that assignment does remain even if another site has upgraded to Service Pack 2.

One other note is that if you're sharing the SMS provider between multiple SMS sites, you should only upgrade the SMS provider for the first site that upgrades to Service Pack 2. So the first site that upgrades to Service Pack 2 should upgrade the SMS provider. All other sites should choose No when they're prompted to upgrade the shared SMS provider, because it does shut down on the provider and you lose connectivity at that point in time. So just have the first site do so, and then all of the remaining sites would choose the option of No to upgrade the SMS provider.

Okay. The next large chunk of time we're going to spend is actually on the SP2 server-side updates. So we want to talk about the updates to SMS components on your site server. So this is just a list of the components we'll discuss in the next coming slides. So we'll talk about Windows NT Logon Server Manager, or how SMS now handles domain controllers as of Service Pack 2. We'll talk about Windows Networking Logon Discovery, or how we now determine who to replicate DDRs to and how do we create DDRs for Windows Networking Logon Discovery. We'll talk about Client Configuration Manager and how it pushes out the SMS client software out to Windows NT clients. We'll talk about Windows NT Server Discovery and its process of creating Discovery records for site systems. We'll look at Inbox Manager Assistant and its polling of the site server. We'll talk about Collection Evaluator refreshing Collections on child sites. SMS Performance Monitor counters are back in the product with Service Pack 2, and they work in Service Pack 2. And then we'll talk a little bit about scalability and how Service Pack 2 has made some changes there for scalability.

So the first server-side update we want to talk about is the NT Logon Server Manager. Some of the issues here in prior releases of SMS 2.0 were that it took a long time to either configure your domain controllers as logon points for SMS 2.0, or if you made a change to your configuration, it took a long time for those logon points to be updated with that configuration change. Or in some cases, some sites weren't able to access the PDC for a period of time, so they were deemed to be inactive, and their site information actually got removed from logon points.

All those issues are now solved in Service Pack 2. First off, Service Pack 2 implements a multi-threaded NT Logon Server Manager. In Service Pack 1 and RTM code, NT Logon Server Manager was single-threaded, which meant it could only work on a single domain controller at a time. And we always start with the PDC, but once we got done processing the PDC and its update as a logon point or any configuration changes, we would then go to BDCs. And we could only access a single BDC at a time.

So in some company cases where you had hundreds of domain controllers, it might take a long time to get your domain controllers all configured as logon points for SMS 2.0, or replicating any updated information from the PDC out to those other domain controllers. Now, with Service Pack 2, NT Logon Server Manager is multi-threaded; it defaults to five threads, which means we could work on five BDCs simultaneously once we're done with the PDC.

This can be controlled through the registry: you can control how many threads the NT Logon Server Manager has. In one customer's case, where it took a week to process an update to domain controllers with Service Pack 1, with Service Pack 2 beta code they were dropping that down to a day or slightly over a day in processing domain controller updates now, because of the multi-threaded nature.

Another issue that we had in prior releases was that NT Logon Server Manager performed too many update or work cycles. So it was generating a lot of excess network traffic because it was polling domain controllers and checking on domain controllers far too frequently. So now with Service Pack 2, NT Logon Server Manager only performs an update cycle in three cases.

First off is when scheduled by the administrator. So when you, the SMS administrator, go out and configure NT Logon Server Manager to perform an update cycle, it will do so. That configuration or that schedule is set on the Logon Settings tab of either the Windows Networking Logon Discovery method, or the Windows Networking Logon Client Installation method. You can go to the Logon Settings tab and then you have Logon Point Update Schedule. So whenever that schedule is implemented, it will perform an update cycle.

It will also perform a cycle when the logon script settings have been changed. So if you're not currently having SMS implement logon scripts and now you tell SMS to implement logon scripts, or vice versa, then we'll go ahead and perform an update cycle. And then when the Logon Server Manager is notified by a file change in its inbox, so it's got a new inbox under NT_logon.box called "Notify." In the Notify box, when it receives a special file there, it will go ahead and perform an update cycle.

That file will be created automatically when SMS needs to notify NT Logon Server Manager to perform an update cycle. For example, when you add a new domain or you remove a domain from the logon points, or if you change your Logon Settings tab, or if you add a new client access point, or if you change your site boundaries, all of those things would trigger a change, so Logon Server Manager would have to perform an update cycle.

What this also means is that no longer can you do a Net Stop or a Net Start of the SMS Executive or use SMS Service Manager to stop and start the SMS NT Logon Server Manager to toggle an update cycle to update your BDCs. That doesn't happen at all anymore, so it's only in those cases. So this means a lot less network traffic is going to be generated in your environments for domain controller updates.

What this also means is that you can have better inactive site handling. So I've mentioned the fact that in prior releases, sometimes a remote site, its site server is going to try and access the PDC. And if it couldn't access the PDC for seven update periods (the default update period is daily), so if it couldn't access the PDC exclusively for seven days, the senior site would detect that site as not being active and mark it inactive and actually remove that site's information from the domain controllers. And so the domain controllers would de-install that site information and you couldn't install new clients.

With Service Pack 2, sites now are left as active state by default, even if they can't update the PDC for a period of time. So we just don't mark them as inactive, which means they're going to remain as active sites on the domain controller. If you want to change that, you can change that back to the Service Pack 1 functionality, marking them as inactive if necessary. They don't access.

And the last change for domain controllers for this slide is logon script is going to be copied to your domain controllers automatically, regardless of whether or not you specify to have SMS modify user logon scripts. We did that in that format in the RTM version of SMS, but in Service Pack 1, we changed to only providing the logon scripts to the domain controllers if you toggled the logon scripts settings check box. Now we're going to put them in the appropriate directories of Repl$Scripts on the PDC, and the Net Logon Share on all your BDCs automatically. This will allow you to go ahead and use those files in your own logon scripts; it just will not trigger SMS to modify user logon scripts themselves to call Smsls.bat.

Okay. The next area we want to talk about is Windows Networking Logon Discovery. The issue here in prior releases was that too much network traffic was generated by Discovery Data Record (DDR) replication. This happened for a number of reasons. One is that whenever you had shared sites (multiple SMS sites sharing a single domain), if the domain controllers were shared between SMS sites, whenever a Logon Discovery record was received by the domain controller, it would replicate that to all other sites that had Windows Networking Logon Discovery enabled to that same domain. And that caused a lot of network traffic.

The second issue there was that the DDRs would increase in size and that the site, the logon point would go ahead and add in the agent site for the agent of NT Logon Discovery for each of the sites that had Logon Discovery enabled for that domain controller. So the DDRs grew to be fairly large, and you're passing a lot of DDRs around.

So in Service Pack 2, the solutions are that the SMS NT Logon Discovery Agent is now intelligent in who it passes DDRs to or who it replicates them to; and the DDRs are smaller. We're no longer providing agent site information for the agent name of NT Logon Discovery, so that will mean smaller DDRs being passed around. So with Service Pack 2, SMS NT Logon Discovery Agent is intelligent, in that it's going to figure out who it should copy DDRs to when it does copy DDRs.

So now, when NT Logon Server Manager updates the domain controllers for a site, it creates a file (if not already there) called Discovery.lst. And in the Discovery.lst file, it designates that this site is a primary or secondary site, and if this site is a child site, who its parent is. Each site would then, when they update that domain controller, they would update that Discovery.lst file. So eventually all sites would have their information there as to whether they're a primary or secondary site and if they have a parent site or not.

When the SMS NT Logon Discovery Agent starts, it reads the Discovery.lst file, and it creates site groups from that file. Site groups are groups of sites that need to work together for discovery and for DDR replication.

For example, if I'm a parent site, a primary site, and I have 10 child sites, and let's say all 11 of these sites have Logon Discovery enabled, there's no sense in Service Pack 1. We would go ahead and copy that Discovery record to all 11 sites.

Now, secondary sites can't process DDRs locally anyway, so they immediately replicate that or forward that to their parent site. The parent site processes it and then pushes it back down to whatever site it's assigned to, so it's a lot of wasted traffic. In Service Pack 2, if all 11 sites (the primary and the 10 secondary sites) had Logon Discovery enabled, what we would do in that case is that the NT Logon Discovery Agent would only send that DDR to the primary site and not to the 10 secondary sites.

So you may have multiple site groups that are created by NT Logon Discovery Agent; however, the DDR will only be replicated to one site server in each site group, even though you may have multiple site servers in that same site group, so one server per group. If they all have the same parameters as far as primary, secondary, and so on, and parent sites, then it would be randomly selected.

There will be a white paper available soon up on the SMS Web site that gives you more detail on this process of the Intelligent NT Logon Server Manager.

The admin can go ahead and override this functionality if they wish, by creating a file called Discpref.lst. So you can create a file called Discpref.lst, and in that file you can specify preferred sites. I want this site to be the site that we do replicate DDRs to, regardless of what the SMS NT Logon Discovery Agent would dictate. You can also specify sites that you are allowing DDRs to be replicated to as well as sites that you don't want DDRs to be replicated to. And that again will be discussed in that white paper coming out.

The next area we want to talk about is the Client Configuration Manager. And the issue here is that SMS accounts were sometimes locked out when you had to push out the SMS client software to Windows NT computers. So you had an environment where your users are not local administrators, so they can't successfully install the SMS client software, because you need to have admin permissions. In that case, the client would create something called a CCR, a Client Configuration Request.

That would get sent to the CAP, the CAP would then forward it to the site server, the site server would then attempt to connect up and push the SMS client software down to the Windows NT client computer. Now, to do that, we have to have an administrator account. And the way RTM and Service Pack 1 code worked was that you could assign one account called the SMS Client Remote Installation Account. So you could designate a single account as your SMS client remote installation account.

So CCM would attempt to connect up to the Windows NT computer with that account and connect up to the Admin$ share of that Windows NT computer. If that was successful, great; we went ahead and pushed down the Bootstrap program, we got the client installed.

If that wasn't successful, then we would go ahead and switch the domain context of that account. We would go from the domain that you specified to the domain of the SMS site server. Then we'd go to any other resource domain we could find. And finally we'd try it without any domain listed.

In these cases, what happens is that your account could be locked out. That account, or if that account failed in all of its different attempts, we would go ahead and use the SMS service account. The SMS service account we'd try, we'd try it in the domain listed, then the SMS domain, and then all the resource domains. And if you do account validation of the account lockout policies enabled, you could lock out the SMS service account.

So our solution in Service Pack 2 is that Client Configuration Manager does not change the domain context anymore when it attempts to push down the client software to a Windows NT client computer. CCM, the Client Configuration Manager, now allows you to add multiple SMS client remote installation accounts. So when you go to the Accounts tab of the Site properties dialog box for a site, you can specify not just one account, but multiple accounts that you want CCM to use to connect up to a Windows NT client computer. And CCM will only use the accounts listed in that dialog box. It will not switch domain context any longer.

Now, if all of those accounts fail, then it will still try the SMS service account which is, by default, a domain admin, and by default domain admins are local admins on Windows NT workstations, so that should be successful. However, we all know a number of people modify those settings.

However, when it tries the SMS service account, it will not switch domain context at all. It will keep just the domain context listed in setup. One option you have here is to add an account and preface that account with the percent (%) the machine name the percent (%) and the variable. So you can add an account, %machine name% \variable CCM_account and then whatever your CCM account is; and that will allow us to switch the variable to the actual Windows NT client computer we're connecting to, and see if that account is a local account that's an administrator on that computer.

Also, we only keep one client configuration request (CCR) per client. In some cases, if you had multiple discovery methods, finding a client computer or an attempt failed, then you might have multiple CCRs created. And if you were trying to push down the client software to domain controllers, then that would cause an account to be created called the client bootstrap account; create the account when you create an account on the DC, that could force a SAM synchronization event. Then if we fail, we would delete the account again; that would cause a SAM synchronization event. So you had a lot of SAM or domain synch events occurring, which is a lot of extra network traffic. That's going to be reduced as well. So a couple of changes there to help you out.

The next area is the Windows NT Server Discovery area. So the issue here was that too much network traffic was generated by the Windows NT Server Discovery Agent in large sites. So sites that had numerous site systems, either a lot of domain controllers, and we have some sites with hundreds of domain controllers in their sites, a lot of CAPs, a lot of distribution points. Well, currently – "currently" being prior to Service Pack 2 – the SMS Windows NT Server Discovery Agent would run daily just after noon, like 12:00 p.m. It would run and it would rediscover every single site system in your site that was in your site control file.

So if you had hundreds of domain controllers and a bunch of CAPs and distribution points, daily it was creating Discovery records for every single one of those site systems. Also, anytime this specific section of the site control file modified, which is the [System Resource Use] section, it would go ahead and rediscover all systems. So you were creating Discovery records daily for hundreds of site systems, and if you were child sites, you were pushing that information up to your parent site. And if these were domain controllers, every site was doing the same process daily, so the simple site would get bogged down with Discovery records from all these child sites discovering all their site systems daily.

So the solution in Service Pack 2 is that the Windows NT Server Discovery Agent only discovers new systems daily. So what happens now is the Windows NT Server Discovery Agent is going to remember site systems it has already discovered. So when the Agent starts up, it discovers all site systems from the site control file, so it will create a Discovery record. It will then go ahead and cache this list in the registry.

The next time the [System Resource Use] section of the site control file is modified, it compares the list of site systems in the site control file with its cache in the registry. It will only do discovery of the new systems, the systems that it hasn't already done discovery for.

The Agent still runs daily; however, it will only create DDRs for new systems; it won't create DDRs for systems it has already discovered. It will, however, now do Heartbeat discovery. So just like client computers to Heartbeat discovery, the Win NT Server Discovery Agent will now do Heartbeat discovery. And Heartbeat discovery is the process of it creating Discovery records for all site systems it has already discovered. Basically it refreshes the Discovery data for all the different site systems.

That process occurs at the Heartbeat discovery cycle. So whatever your Heartbeat discovery method is enabled for, that's when the Windows NT Server Discovery Agent will perform Heartbeat discovery. So you do need to make sure with Service Pack 2 and later that you have Heartbeat discovery enabled, because the Windows NT Server Discovery Agent uses it. If you don't have it enabled, then there is always a chance that your site system Discovery records may be removed from the database, which means no more functionality to those site systems as far as like Network Trace, because we needed the data in the Discovery database for that.

Okay, the next thing we'll talk about is Inbox Manager Assistant. The issue here is that in large sites when you had a large number of client access points, that there was a lot of network traffic generated by the client access points connecting up to the site server to check for information. So you had a lot of client access points and periodically each client access point connects up to the site server to check and see what parameters it's supposed to be working with.

In that case, it generated a lot of traffic with all the CAPs connecting up and checking and searching through all the registry entries on the site server. So the solution for Service Pack 2 is that the Inbox Manager Assistant checks the site server less frequently. So in prior releases to Service Pack 2, Inbox Manager Assistant, which is running as a thread of the Executive on a CAP, would connect up to the site server's registry every 5 minutes for the first 30 minutes of start of the SMS Executive on the CAP, and then every 30 minutes after that. And if you had a large number of CAPs in your site, it's connecting up to look for Inbox replication rules and it has to weed through a lot of Inbox replication rules to figure out what rules it's supposed to be looking at.

And the rules are what type of files it's looking for on the CAP and when it finds them in the directories, where does it replicate them to on the site server? Now, with Service Pack 2, Inbox Manager Assistant only checks twice during the first 30 minutes of startup, and then checks every 6 hours as opposed to every 30 minutes. So generating far less network traffic for client access points checking their configuration and replication rules in large environments.

The next update is on the Collection Evaluator. A couple of different issues here: too many work cycles were consumed processing collections when an error occurred; as well as too much network traffic generated when replicating collections to child sites. So a couple of solutions for Service Pack 2: performing fewer work cycles, and then schedulable refreshing of collections to children.

So first off, if Collection Evaluator fails to process a collection because of some sort of a database issue. The general scenario here is one we talked about a couple of months ago in one of our common issues sessions, is that I've created a child site that has a custom architecture, an ID MIF they created, that updates the database. That gets pushed up to a parent site. The parent site knows about it. The parent site creates a collection based off of data in that custom architecture. Collections automatically get pushed down to child sites.

Well, if another child site that does not already know about that custom architecture receives that collection, it's not going to be able to process that collection because it doesn't have that information in the database. So Collection Evaluator generates error messages, status messages, and retries that collection. It used to retry it every minute and now it's only going to retry it much less frequently than that with Service Pack 2.

So what you were seeing was multiple status messages being generated every minute, stating that Collection Evaluator was having errors. Now you're only going to see one status message every 15 minutes, and Collection Evaluator not processing that failed collection as frequently.

Another issue again is the refreshing of collections done at child sites. So automatically Collection Evaluator, every seven days, takes all collections it has and pushes them down to all child sites of the current site. We have some customers with hundreds of collections that they've created, and you might have hundreds of child sites. That's an awful lot of network traffic being generated to push these hundreds of collections down to hundreds of child sites every seven days.

So in Service Pack 2, you can configure how frequently you want Collection Evaluator to do this collection refresh process. The default is still seven days, but you can either leave it at the seven days or change it to some other number of day values. You can even turn it off if you want to.

However, this has no effect on a brand-new collection being created. That's going to automatically get pushed down to child sites immediately. It has no effect on a new child site attaching to the parent; it will automatically send all collections down to that child site immediately. It's only for the refreshing of collections every seven days. It's now configurable — what that value is — as far as when we do the refresh.

The next thing we talk about on the server side is Performance Monitor counter. The issue here is that Perf Mon counters for SMS were broken and disabled in Service Pack 1. We actually put in one of the hot fixes that disabled the Performance Monitor counters. So the solution is, the counters are fixed in Service Pack 2. So the actual counter itself, the DLL, Smsperf.dll, it's installed to the system root directory now and not just in the SMS tree, so you won't have permission issues anymore.

And the DLL is loaded, not by any SMS components any longer, but solely by Perf Mon. So Performance Monitor will load that DLL when it needs to, when you go ahead and open up Performance Monitor and now you go ahead and pull in any of the SMS objects for the Executive or Discovery data processing or software metering or whatever the case is. Also now, all the international versions will also include the Perf Mon counters for Service Pack 2. In prior releases, that was not the case.

And lastly on the server side is scalability. So a number of changes have been made to Service Pack 2 for scalability. These fit in certain areas that we'll discuss briefly.

The first is the Scheduler and Sender. So there were fixes implemented for performance. Scheduler had some issues when there were a large number of send request files backlogged to be processed; it was not able to process them very effectively. There were fixes for deleting files, but the Scheduler had issues with deleting files when it should be deleting files if the Scheduler had been running for seven consecutive days. And fixes for routing.

Routing is the process of a central site, for example, trying to send data down to a grandchild site when it doesn't have an address to the grandchild site. It wants to send that data down through its local child site, and have that child site route that data down to the grandchild site. There were issues with the send request files and the routing files being misnamed or renamed during transmit and not being set up properly, so some of the routing processes failed. Those are all fixed in SP2.

Status Summarizers. So there were some issues in hierarchies with child sites replicating status summary messages up to the parent site and we had issues with how quickly or how slowly we processed those status summaries as well as processing those message, sometimes out of order. So now we go ahead and process them much more quickly, lots, lots faster than we used to, as well as in the correct date order; the oldest one first up to the newest one.

Prochist.dat, those issues have been solved now. This is the file that was used for the SMS Executive on remote site systems, such as CAPs, component servers, remote SQL Servers, and so on, that would go ahead and note when they had to pull back on status messages because they were going to flood the system with excess status messages.

The problem with the prior release is that there was only one Prochist.dat file that was on the site server, and if a CAP had issues that they needed to update the file, it would update the file on the site server, generating traffic, and then blowing away other components' entries in that file. The file would get to be excessively large, like a megabyte in size, which would cause SMS Executive instability.

So now each site system that needs the Prochist.dat file has their own local version that they use. There's no replication of data across the wire and you're not stomping on anybody else's file. So you no longer have to go through a process of deleting the Prochist.dat file occasionally to keep SMS Executive up and running.

And lastly are our queries. Our queries have been rewritten to give you better performance. We still don't recommend that you use them in large sites with a large number of routers with a large number of IP addresses, for example. Take these as examples and create your own queries off of those, but the performance is a lot better so you're not utilizing as much tempdb space as we used to.

Now we'll kick over and talk about some of the client-side updates. So the first three scenarios or the first three issues are kind of all clumped together. I just broke them out on three separate slides because of the number of things I want to talk about: and that's upgrading a client to Service Pack 2; the base components themselves; and then upgrading the optional components; and then lastly, how the clients work in shared site scenarios. So those three are all kind of clumped together, but they are three separate slides. Then I want to talk about the client 30-day verification cycle and that issue. Hardware Inventory Agent and how it's changed in SP2, as well as Remote Control.

First off is the process of upgrading to Service Pack 2. And again, these next three slides all really relate together; they‘re just broken out on three different slides for you. So the issue here is that in the upgrade from RTM code to Service Pack 1, in environments where you were sharing logon points between different SMS sites, we basically caused problems with clients downloading components that were a later version from the logon point than what their local site version was. So one site had upgraded to Service Pack 1 and another site had not upgraded to Service Pack 1, and was still sitting at RTM code. And in that environment, client components got mismatched between SP1 and RTM code and it basically hosed the client.

Again, this generally did not happen on a standalone site. If you weren't sharing logon points between sites, it was not an issue, because you would update your site and your logon points and your counts would all be upgraded to Service Pack 1 (or now Service Pack 2) simultaneously, so everybody was fine.

So the solution now, or one of the solutions, is that for Service Pack 2, we no longer initiate an upgrade of your client components from a logon point. So the client will not initiate an upgrade to Service Pack 2 from the logon point. So what we do now is that the Bootstrap program, which in an example of a Microsoft environment would be Boot32wn.exe. When the client connects up to a shared logon point, let's say a logon point that's sharing between an SP1 site and an SP2 site, the executables on that logon point will be upgraded to the SP2 version.

So let's say the SP1 client connects up at logon point. It sees the SP2 version of Boot32wn and it runs that program. It's going to say oops, I'm a later version of what the client has; I'm not supposed to do an upgrade. So basically it's going to bail out of the logon script and not download the upgraded Clicore down to the client computer. So you won't have a scenario where part of your client components are running SP1 code and part are running SP2. So we detect the version at the logon point, and if the logon point is a higher version than our client, we don't initiate an upgrade.

What we do is rely on the client to do an upgrade itself, using CCIM, the Client Component Installation Manager. It goes and talks to its local CAP. And when its local client access point has been upgraded to SP2, the client will get upgraded to SP2. CAPs are never shared between sites like logon points are, so you don't have the issue with mixed versions of files from a client access point. So now we just wait for the client to download the new Clicore, as well as all other files from the client access point, as opposed to the logon point.

Now, for this to work properly, you have to have applied those two required hot fixes we talked about on the second or third slide of this presentation, way back when; so you have to read your release notes, read the red section on the required hot fixes. If you're in the scenario where you are sharing logon points between sites, you have to have applied these hot fixes.

If you don't, then you may run into the case where your SP1 client will download the SP2 version of Clicore.exe, expand it, install some SP2 components, and find out the rest of its components are still SP1 because its CAP is still SP1. And then your client is in a stuck state where your SP1 and SP2 client components don't work together. So you need to make sure you've applied these hot fixes properly.

So the next slide talks about component upgrades. So it's basically the same issue here that client components from the CAP may not match the base components on the logon point. In other words, Clicore from the logon point is a different version than the rest of the executables from the CAP. So the solution now again is that the client code is intelligent, to check the version of Clicore on the logon point. So we don't initiate upgrades from the logon points anymore. We initiate upgrades from client access points. That's done by CCIM on the client, and it only checks the local CAP and CAPs are never shared

The next issue that you had was in some cases, particularly in Windows 95 and 98 boxes, that when Clicore ran, if it was upgrading the component, the client from let's say SP1 to SP2, that some of the executables or some of the DLLs would be in use and Clicore couldn't update them. So now what happens is CCIM and Clicore, they'll stop all the SMS components locally so that you can go ahead and successfully upgrade those components. Clicore will go ahead and stop all SMS components during an upgrade to SP2, so that there are no SMS components in use. That way, you can go ahead and upgrade those components.

Another thing that happens is that when CCIM performs its upgrade cycle, it finds a list of CAPs that have already been upgraded to SP2. It maintains that list of CAPs, and then when it makes a request of SMS APM to upgrade one of the optional components — let's say hardware inventory or software inventory, etc. — it tells SMS APM32 what the list of upgraded CAPs is, so APM will only pull the components from an upgraded CAP and not accidentally pull one from a down-level CAP.

Now, generally your CAPs are all going to be the same version. The one case where they might not be is if a CAP was offline or had connectivity problems when you upgraded your site to SP2, so this one CAP happens to still be at SP1, and everything else is at SP2. So that would be the case where CCIM will detect that and not give APM a list of CAPs that are still running at SP1 or RTM code version.

And lastly is that we will not upgrade any optional components, being software distribution, software inventory, etc., until the base components have been upgraded, which means base, WBEM SDK, and APA Setup. So all of the core components have been upgraded to SP2; then we'll have APM update all the optional components. But until that process is completed, we will not update any optional client components.

And the third slide in this section is for shared sites. Again, the scenario is the same; the client components can be mismatched when sharing logon points between sites. So we're detecting the logon point versions and not upgrade from logon points.

Now, there is one case where we do initiate an upgrade from a logon point, and that is if CCIM on the client is dead. It's corrupted; it's been overwritten; it's been deleted; or it's not running. And you kick the logon script off or SMSMan.exe as your logon point; and your logon point determines that your site is actually updated to SP2, so your CAP should be updated to SP2 and your client basically is dead as far as CCIM is concerned. Then it will go ahead and initiate an upgrade. But in all other cases, as long as the client components are running properly, we don't upgrade from a logon point.

So in shared site scenarios, a couple of things that help you out are that, provided you've applied these hot fixes we've talked about. We don't download Clicore if it's a later version than the local version of the client computer itself.

One big change here is that we do not assign a client to a down-level site any longer. So let's take the scenario where you have an SP1 site and an SP2 site sharing logon points. My client is now an SP2 client. I kick off the SMSLS.bat file, connect up to the logon point and I look at my assignment list. And I see two sites and let's say those sites are sharing the same site boundaries. So technically my clients should be assigned to both the SP2 site and the SP1 site.

In this case, with SP2, when the client checks this, it determines that, oh, I'm an SP2 client; I cannot be assigned to anything less than SP2. So it's got to be SP2 or later. So it will not assign itself to the SP1 site, even though the site boundaries state that it should be. And the reason for that is just so that you don't get a possibility of an SP1 client component being installed on an SP2 client.

For example, let's say the SP2 site did not implement Remote Control. And the SP1 site does have Remote Tools Client Agent enabled. In that case, the SP2 client would be directed to install the Remote Control Agent from the SP1 site; so now you get an SP1 Agent mixed in with all SP2 code and you don't want that. So SP2 clients will not assign themselves to SP1 sites. We won't de-assign a client from a down-level site if it's already assigned, but if it's a new site, then we won't assign it to that new site.

So again, you need to make sure you apply these hot fixes for these last three slides to work successfully. If you don't, then your client may actually download the updated Clicore and unbundle it and have some SP2 components that are base, and everything else running SP1, and your client is basically stuck until you upgrade the site to Service Pack 2 itself.

Okay. The next issue is the client 30-day verification cycle. The issue here is that all clients in all sites are reinstalled every 30 days. SMS automatically has this thing called a 30-day verification cycle, where every 30 days CCIM verifies that all client components are installed successfully.

Well, currently what happens (currently being in RTM and SP1 code), when it does its verification process, it actually brings down the SMS installer script or bundle from the CAP and basically reinstalls the entire client component. This causes tons of excess network traffic because you're reinstalling your entire client, which might be 12 megabytes (MB) worth of network traffic, as well as causing inventory resynchronization events because you're reinstalling hardware inventory and software inventory.

Now, this wouldn't be so bad if it were just on a single client. However, the way both RTM and SP1 code work is that every single client uses the same 30-day cycle. So that at a single site, every client you had was basically going to reinstall every 30 days on the same day, which is not a good thing to do as far as network traffic went.

So now what happens in Service Pack 2, Service Pack 2 fixes the problem and reduces the network traffic. How we do so is that we now perform a proper client verification cycle, so that we verify the client components and we only reinstall them if the component is corrupted or needs to be reinstalled; otherwise, we don't reinstall the component automatically as we did in RTM code and SP1 code.

Also, each client component has a random verification time. In old code, every client was running on the same cycle of every 30 days and we verified every component on that client. Now each component that's installed in the client computer has a different 30-day verification cycle. So when you install your base component, it has a verify cycle 30 days plus a random offset time. That random offset time fits in between a range of 50 hours to 240 hours.

So maybe the base components are going to be verified in 30 days with an offset of 2 days and 7 hours. Where WBEM SDK is going to be verified in 30 days with an offset of 5 days and 17 hours and ATA is going to be verified in 30 days and 8 days and 2 hours, so each component is going to be verified at a different schedule.

Each client is going to work with its own 30-day cycle and each component on each client will work with its own component schedule. Every single client will do verification of each component independently of any other component and any other client. So you're spreading out your network traffic more evenly so there is much less on the wire. So you have less traffic occurring and it's spread out over the wire, as opposed to everybody hitting the wire at the same time.

There still is network traffic in this process, and a fully functioning client is still about 6–6.5 MB of network traffic being generated. However, again it is spread out over time, so that you might only see 100 KB at one point in time, where you're verifying one component. And the biggest component is Software Metering; that's about a third of that 6 MB, it's a little over 2 MB itself. That will help you out greatly.

For those of you who have implemented the Cliverify utility to turn off the 30-day cycle, when you do upgrade to Service Pack 2, we do reimplement that cycle. And Cliverify will not work on an SP2 site; so you are back to a 30-day cycle for this verification process. But again, it's not an issue because there is much less network traffic and it's being spread out throughout the life of the client.

The next change we want to talk about is the Hardware Inventory Agent. The issue here is that in prior releases, the SMSCliToknAcct was locked out frequently during hardware inventory. The reason being, some of your client processes – or first off, the Hardware Inventory Agent ran out of the context of the SMS Client Service. We'd use the SMSCliToknAcct to create a separate token for this one process so it wouldn't get locked up with other processes or interrelated with other processes.

And when Hardware Inventory did some of its work, it did validation of this account, every single Windows NT computer, has a different password for the SMSCliToknAcct to maintain security. So the password on the local Windows NT client was going to be different than the password for the SMSCliToknAcct in your domain. And that account would be in the domain because your domain controllers were SMS clients, so it had the Hardware Inventory Agent installed as well; and you don't have a local SAM on Windows NT domain controllers; they have a domain SAM, so the password was different, so you'd lock out the account.

So now, what we're doing in Service Pack 2 is that the Hardware Inventory Agent now runs the service on Windows NT clients. So the Hardware Inventory Agent for Service Pack 2 runs as a separate service, not as part of the SMS Client Service. It runs as the SMS Hardware Inventory Agent service. The account it uses is actually the local system account, so it uses the local system account and not the SMSCliToknAcct. So all those issues with account lockouts of the SMSCliToknAcct because hardware inventory will now be solved because we're not using the CliToknAcct for hardware inventory anymore; we're using a local system account.

Those of you who have gotten into habits of manually starting the Hardware Inventory Agent with Service Pack 1 and RTM code, you can still do so even with this new service. You can start it just like any other service, so you can go ahead and do a net start of the SMS Hardware Inventory Agent service; you can go to Control Panel Services and start it; you can go to the Systems Management program and Control Panel, and you can start it by going to the Components tab and clicking Hardware Inventory Agent, clicking Start Component; or you can still use your Cliutils utility that you might have used from the resource kit. So you can still use it the same way; it's just going to function better in that it won't lock out your Clitoken account any longer.

The next and last client component we'll talk about, or the client-side update, is for remote control. The issue here is that the SMS Remote Control Agent was using ports that were not registered for its own use. The ports that we use for RTM and SP1 Remote Control Agent were
ports 1761 through 1764, and those ports were not registered for SMS Remote Control. They're actually registered by a different company.

So now, the solution for Service Pack 2 is that we have registered specific ports for our SMS Remote Control Agent. So as of SP2, your SP2 clients will now use ports 2701 through 2704 for all of the different SMS Remote Control functions, whether it's Remote Control or any other of the Remote Tools, Execute, or Chat or whatever. So if you have firewall set up or whatever, you need to make sure that you have enabled those ports if you want SMS to pass through those for remote control.

What this means to you is that a Service Pack 2 SMS Administrator console, with an SP2 or Service Pack 2 SMS Admin console, can successfully remote control a Service Pack 2 client, a Service Pack 1 client, as well as an RTM client. What happens is that the SP2 Admin console will start on port 2701 trying to find its client. If it can't successfully find the client over at port 2701, it will downgrade to port 1761 and try and find that client over port 1761, which is what SP1 and RTM code use.

However, a Service Pack 1 or RTM SMS Admin console will not be able to remotely control a Service Pack 2 client. Service Pack 2 clients only listen on port 2701. And your RTM Admin consoles as well as your SP1 Admin consoles, only talk on port 1761 through 1764, so you're not using the same ports. So you cannot remotely control a Service Pack 2 client with an RTM or Service Pack 1 SMS Admin console. You have to use a Service Pack 2 Admin console. But you can go the opposite direction: Service Pack 2 can remotely control a Service Pack 1, or RTM client.

Okay. The last topic here is on something called recommended reading. And that is the SMS 2.0 Service Pack 2 Release Notes. You need to make sure that you read the release notes for Service Pack 2. From talking with some of our support engineers and talking to customers, we're finding that the vast majority of customers are not reading our release notes. And part of that may be that the release notes are a little bit larger than maybe documentation from some other product. But you do need to read the release notes.

There are two files for Service Pack 2. There's a Readme.htm file, and there's a Readme_Operations.htm. Readme.htm covers installation of Service Pack 2, the requirements for Service Pack 2, such as those hot fixes we've been discussing, supported platforms and so on. So it's issues revolving around the installation of Service Pack 2.

Readme_Operations.htm covers use of SMS and administration of SMS; so use and administration of your Service Pack 2 site. It also covers things that are not updated in your Systems Management Server Administrator's Guide or the online help system, so addenda to that. So I highly recommend that you read the release notes.

Don't commit all the pages to memory, because you'll never be able to do so, but read through them. Find things that you think are applicable to your site. Maybe even print out the release notes and either dog-ear the pages or get little stickies on there so you can find the pages appropriately. But make sure you have this information available to you.

And then before you ever contact somebody else about an issue with SMS 2.0 Service Pack 2, make sure you check the release notes, because it may be an issue that's already been documented in the release notes. We find that quite frequently, that our issues are already discussed in release notes and people just haven't read them. So you need to make sure you read the release notes. Partly because of just general issues with SMS and things that are now updated from the admin guide that have not been updated for Service Pack 2; as well as this is where you find the information again about those required hot fixes.

If you don't apply those required hot fixes in an environment where you're sharing logon points, you're going to wind up getting your client computers all confused and unable to do anything, as far as SMS is concerned, until all sites have successfully upgraded to Service Pack 2. And you don't want to have to do that; so make sure you've applied those hot fixes.

Okay. A quick summary for you, and then we'll get into our Q&A session. Here is what we talked about for Service Pack 2. We talked about what it is and what it is not. And basically it's a set of fixes to SMS 2.0, RTM code and SP1 code. These are fixes for the primary issues that we found that were large and major issues that need to be addressed. Service Pack 2 does not address every single issue that we know about in SMS 2.0. There are some things that we just did not have time to fix in Service Pack 2.

It also does not prevent new issues from occurring in the future. There will be new things that appear, as far as SMS is concerned, even after you've applied Service Pack 2. Remember, you do have the required hot fixes. They're required in all instances of sites sharing logon points. So if your site, at any point in time, is ever going to share a logon point or ever has shared logon points with other SMS sites and you do apply these hot fixes, you have to get them implemented properly before you upgrade to Service Pack 2 or you will get your clients in a confused state and they won't operate properly.

Service Pack 2 adds Windows 2000 support for servers as well as clients, and we discussed that in last month's Support WebCast. It reduces network traffic significantly in areas of domain controller, upgrades to logon points, configuration of domain controllers as logon points, and replication of updated information at the logon points. So you have much better handling of domain controllers, and reduced network traffic requirements there.

DDR creation and replication: Our DDRs are smaller, and we don't create as many of them in some cases, and we don't replicate them as frequently as we used to. Collection refreshes can now be scheduled so you can reduce the amount of traffic for refreshing collections on a weekly basis to child sites. And the 30-day verification cycle: We're reducing a lot of network traffic there and spreading it out over a period of time for you.

We no longer use logon points as our source of upgrading client computers. We now upgrade solely from client access points with that one exception we noted. And remember again the required hot fixes, you've got to apply those. You want to make sure you watch the SMS Web site, so go to http://www.microsoft.com/smsmgmt/ and watch that Web site for news on Service Pack 2, for when it's available as well as the Web patch, if you want to download the Web patch and upgrade your sites from there.

And then again, make sure you do look at the release notes and go through the release notes. Read them briefly, see what's applicable to your site. Print them out is what my recommendation would be, so you have them available to yourself and then you have them so that you can use them and refer to them before you ever contact anybody for any issues.

And that will conclude the presentation. Now we'll get into Q&A.

Heidi: Thanks, Wally. It is time to move on to the Q&A portion of this Support WebCast.

The Q&A portion of the Support WebCast is intended to encourage further discussion of the topic on hand; however, one-on-one product support is outside the scope of the Support WebCast program. If you do have a support issue, you will want to contact Microsoft Support directly, or post the question on the Web Response.

I have a couple of notes for you before we get into the Q&A. We do have another SMS session coming up on July 6, 2000: "SMS Backup and Recovery." Also as Wally mentioned, we had a Support WebCast last month on SMS. All of those sessions that we have done on SMS are available on the Support Online site, so you have access to them.

Also, if some of the details in the PowerPoint slides were a bit difficult to view during this broadcast, or if you'd simply like to have a copy of those slides, be sure to download the file from the Web site. Also, if you joined the broadcast late or you'd like to review the contents again later, we'll have the on-demand streaming media available within about eight hours of the live session. We'll also have a full transcript available within about three weeks.

So with that said, we've had lots of questions asked, so let's jump right in. One question has been asked a few times, so I'm going to go ahead and ask it first, to get it taken care of, and that is: Are there any dates yet for when this service release will be available?

Wally: We don't have an official date yet (Editor's note: SR2 is available as of 6/23/00) for you because we're still waiting for final feedback from our final beta sites that are testing release candidates 1 and 2 for us. I have not heard of any issues with release candidate 1 or 2 from these beta sites, so all is going as expected there; so our public date we're stating is still second quarter of this year, which is sometime this month. So we're still expecting it sometime this month, and I've heard nothing that would dictate any other date other than that.

So it's going to be fairly soon. Keep looking at the Web site and you'll find out when it is available, and it will be announced worldwide, I'm sure; you'll all be hearing about it. But it is getting soon, but I can't give you an official date yet.

Heidi:Okay. So the next question is: Will WMI 1.5 enable serial numbers to be reported without the need of having the DMI service layer installed on the server desktops?

Wally: Good question. First off, WMI 1.5 supports a specification called SMBios 2.1. SMBios is a new specification that standardizes the location of information in the PCBios for serial numbers as well as PCBios. So WMI 1.5 does support that polling of information from the PC Bios location. However, it can only do so provided that your hardware also supports SMBios 2.1. So if you have hardware that supports SMSBios 2.1, and your WMI implementation supports it, then, yes, you can get that information.

For example, on my two laptops I use, when I installed those laptops with Windows NT 4.0 and use SMS Service Pack 2 with that, I do not get that serial number information. My hardware supports it, but my level of WMI 1.1, which is the default one for SMS 2.0, does not support it. When I installed that same computer with WMI 1.5, when I did that with Windows 2000 and supplied Service Pack 2, I got that information natively.

So yes, provided your hardware supports SMBios 2.1, then yes, WMI will allow you to acquire that without doing anything for hardware inventory; no additional drivers or DMI service layers or OEM utilities at all required.

Heidi: Okay. Excellent. The next question is: When upgrading an SMS 2.0 as P2 system acting as a logon point from a Windows NT 4.0 domain controller to a Windows 2000 domain controller, is it necessary to upgrade all domain controllers to Windows 2000 before re-enabling the Logon Discovery? Or can you upgrade just the logon point server to Windows 2000, then re-enable Logon Discovery?

Wally: I'm a little confused, because with SMS 2.0, we don't allow you to specify specific domain controllers. So if you add a domain for Logon Discovery, every single domain controller in that domain is set up as a logon point. So there's no ability to upgrade just a logon point server to Windows 2000 and enable Logon Discovery. It's all domain controllers simultaneously.

Now, one thing I should note here is that in last month's session, we talked about Windows 2000 interoperability. I noted that we were requiring that you de-install or disable your Logon Discovery process on your domain controllers before you upgraded to Windows 2000, then upgrade to Windows 2000 and re-enable it. That has now been changed, and you'll find your white paper will be updated soon on the Web site. So we now are going to be supporting upgrades of Windows NT 4.0 domain controllers with SMS functions on them, to Windows 2000 without deactivating any SMS components. So that will be updated in your white paper coming up soon, but that was a change from – it happened like a week and a half ago, we just got this note on that support level now.

So you will be able to upgrade just a single domain controller to Windows 2000 and keep your functionality running. But again, there's not an issue with one versus another; it's all or nothing as far as SMS goes with domain controllers.

Heidi: Okay, next question: Does SMS 2.0 SP2 allow the Admin console to be installed on Windows Terminal Server?

Wally: SP2 supports Terminal Server for Windows 2000, not for NT 4.0. So in NT 4.0, yes, we do support the Application Compatibility mode as well as the Remote Support mode for Windows 2000 Terminal Server. But we do not support Terminal Server with the Admin console or any server functions for Windows NT 4.0.

Heidi: Thanks, Wally. Before we go on to the next question, I do want to encourage everybody that's listening in to let us know what you think about the program – this topic, other topics you'd like to see, and general comments you have about the program. During this broadcast, you can submit your feedback using the message center, and at any other time you can submit your feedback using the alias feedback@microsoft.com. Be sure if you use the alias to include "Support WebCast" in the subject line. And once again, I do want to encourage all of you to let us know what you think about the program; it definitely helps us make sure we're hitting the mark with the content we are doing for you.

Okay, the next question: Are there any new views available for SQL tables generated by SMS 2.0? If so, at what level does Microsoft support their use?

Wally: SMS 2.0 has never provided views for SQL Server in the past. So the only time we had SQL views available for any utilities was if you upgraded from SMS 1.2 to SMS 2.0; we maintained your SQL views from 1.2. However, internal work has been done to start generating views that are available for you for the utilities for accessing the SMS data outside of the SMS Admin console. Those views and the utilities that create those views have not been made public yet. It will be made available either on the Web site soon or in the next SMS 2.0 Resource Guide or the BackOffice Resource Kit.

They will be made available publicly soon; I just don't know at what point they're going to put those up on the Web site or at what point they're going to update the BackOffice Resource Kit to make those available. But we do have the code available; it just hasn't gone through enough testing right now to release it because of all the work for Service Pack 2. But the code is there and we do have it; it's just testing and getting it up on a Web site and also into the next resource kit.

Heidi: Okay. The next question: Does WMI 1.5 support provide MMC 1.2 for Cut/Paste/Printing from MMC on Windows NT 4.0?

Wally WMI 1.5 has nothing to do with MMC 1.2 and its cut, paste and printing capabilities. You can download and install MMC 1.2 on top of NT 4.0. So if you want to go ahead and upgrade your version of MMC to 1.2 so you get the cut, the paste, and there's not technically printing in MMC 1.2. You do have the exportability, so you can export your data to some other file format and print it out. You can do that. But that has nothing to do with WMI 1.5; it's a totally separate animal.

Now, maybe MMC 1.5 requires WMI 1.5, but it's not a WMI 1.5 support issue for MMC 1.2. They're two different animals. So yes, you can install both of those on your NT 4.0 environment, and then you would get the advantages of both.

Heidi: Excellent. Next question: Can the Web patch be applied against a disk image of RTM that has been updated to SP1 already?

Wally: If you mean taking an RTM CD and then using the SP1 Web patch to make an SP1 image and then applying the SP2 Web patch to the SP1 Web patch image of the RTM CD image, if that's what you mean, then I would assume yes. Because after you apply the Web patch, it basically turns that into the upgraded version of the CD. So as long as you have an SP1 CD image, whether it came from an official CD or a Web patch, you should be able to use that to upgrade with the Web patch to SP2.

Now, nobody's ever asked that before and I've not asked it; I didn't think about that. So I'd have to verify it, but my guess would be yes, it would be able to work. Easy way to test it is just try it out. The Web patch will tell you if it can't right away when it tries to run, it will tell you it's a down-level CD that we can't upgrade. But my guess would be yes, that you would be able to.

Heidi: Okay, terrific. Next question: Please go into greater detail about this senior site. I have a site that sits atop the tree that serves a reporting purpose only. My main site is directly under that. From what you have said, it sounds as if I need to make my main site the senior site. When you mentioned site names and ZZZ was more senior than AAA, is seniority based on how it fits in the alphabet?

Wally: Yes. Seniority is how it fits in the alphabet. So the highest alphabetic code, which would be ZZZ, is going to be senior to ZZY or to AAA. And if I remember correctly, 999 is senior to 000. Now, whether or not you need to make your top-level site or your central site your senior site, that's up to you. It doesn't have to be the central site. You may not want it to be. However most customers I've talked to, it is their central site that they do want to be the senior site. So you may want to do that. That's a choice that you would have to make on your own.

If you have a small site hierarchy, not that many sites, then it may not be that big of an issue to have your non-central site being your senior site. It just depends on where you want to do your administration from and control services from.

To make a site a central site, to manually designate it, you go to the – I believe it's the SitesCFG directory on the logon point. So you go to your PDC, go to the \\SMSlogon\SitesCFG directory and create a file called Senior.lst. And inside that file, just put the three characters of the site code of the site that you want to be the senior site. And then the next time the NT Logon Server Manager does its update cycle, it will go ahead and detect that and make that site the senior site. And it will then control replication of data to back up domain controllers and throughout your site.

Heidi: Okay, next question: Will the upcoming white paper show specific differences in traffic between SP2 and previous versions?

Wally: I doubt it. We haven't done a lot of network traffic. I've done some stuff in my training courses and some stuff on my own, but as far as the white paper, I don't know that it will. I saw a preliminary version of the white paper, and it did not have any network traffic stuff in there as far as specifics.

Now, obviously it does state that we're reducing network traffic because we're not replicating DDRs as frequently throughout the environment, so we do that much. As far as whether your traffic is going to be reduced from 3.5 MB to 1.3 MB now, I don't think you'll see that level of detail at all. Maybe at some point in the future, but the current one that's coming out, I don't think so.

Heidi: Okay. Moving right along to the next question: Is there a list of bugs that are not fixed in SMS 2.0 SP2?

Wally: Not that I'm aware of. So not unless you're in the internal development groups, you have access to the database where you track all that stuff, I have no way for you to find out what bugs are not fixed in Service Pack 2. Just no way of knowing or making that available to you.

Heidi: Okay. Next question: Does SMS 2.0 SP2 install MMC version 1.2?

Wally: No, it does not. And the reason for that is I believe that MMC 1.2 requires Internet Explorer 5.0, and if we then upgraded that, as well as that's why we don't upgrade to WMI 1.5, because I believe WMI 1.5 required Internet Explorer 5.0 or something to that effect. It would change our support statement and then make us change our support bundle, and it's too much stuff to do in a service pack. So, no, it does not – we do not upgrade to WMI 1.5 automatically, nor do we automatically upgrade to MMC 1.2. You have to download the code and install it on your own if you wish to upgrade. But it does not happen automatically with Service Pack 2.

Heidi: Thanks, Wally. Moving right along, the next question is: Is Microsoft working on any new tools to assist with the installation of the SMS client on remote dial-in PCs?

Wally: Yes, we are. I have nothing that's available for you today, but yes, we do know that remote or dial-in PC's are an issue with the size of the client and the amount of work that the client does. We are working on ways to allow you to do installations from alternative methods as opposed to directly from a client access point. So yes, we are working on it. We do know that. But we have nothing available for you as of today.

Heidi: Okay. Next question: Is NT Server Discovery enabled by default? Prior to SP2, did Microsoft simply recommend disabling this feature because of the large number of DDRs, or is there no way to avoid the excess traffic?

Wally: If you're talking about Windows NT Server Discovery Agent, yes, it is enabled by default and there was no way to disable it, because it is an internal function. And the purpose of this is to create discovery records for your site systems. So you do need to have the agent running; otherwise, you don't get discovery records for your site systems. If you don't get discovery records for site systems, which means you don't push out the client software to them, so your site system is not SMS client, so no Remote Control, no inventory information, no upgrading of service packs automatically and so on. And no ability to do network trace, so you do need Windows NT Server Discovery Agent running.

The change for Service Pack 2 is that it just doesn't create as much traffic because it doesn't create as many DDRs, it doesn't create them as frequently, and it runs on a less frequent cycle than it used to. So it's changed, but it is there; it's always going to be there at least for the foreseeable future. And you cannot turn it off.

Heidi: Okay. The subject of the next question is database corruption: Our main issue running SP1 is that, when a system is renamed, it tends to cause problems. We'll have an entry with multiple resource names and MAC addresses. Connecting remotely or distributing software would end up connecting to the wrong system. Is anything done in SP2 to address this?

Wally: Well, that shouldn't happen in the first place. You are allowed and I've done this on my own site. I've taken a computer that's been already inventoried and discovered and changed the computer name and then my DDR information has been reflected properly inside the database. So there's some other issue going on if this is happening on a consistent basis. So you would need to open up a case with Product Support and get them involved with it, and if there is some sort of an issue, then maybe a code fix for that can be created. But it should work properly by doing that, because we do support that process.

The next DER that's created for that client or that resource should just indicate that the computer name has been changed; and then as long as the SMS unique ID is not changed, then it would point to the same record in the database and just update that one field. So that should not be an issue at all.

So I'm not aware of any problem with it, so I can't state that there is any fix in SP2 for it, because I had not heard of it being a problem. I looked quickly at the list of fixes from that KB article I mentioned earlier and I don't recall seeing anything that would indicate that, but it was just a real quick glance at it. I'm not aware of anything and would suggest that you contact PSS and open up a case and see what they have for you on that, because I have not heard of that being an issue before.

Heidi: Okay. Next in line: Are international language versions of SP2 available, both server and client? And if they're not, when will they be available?

Wally Well, SP2 is not available at all in a release form; it's still in beta and release candidate form. And so there's nothing new there. When SP2 ships, we will have localized versions. I believe we're localizing into International Client Packs (ICP packs) 1, 4 and 5, if I remember correctly, so we're combining some of the packs together. So there will be SP2 versions of some of the international client packs, and I believe it's ICP1, ICP4, and ICP5 for the international client packs.

As far as the official date, I can't tell you that. I don't know what the schedule is. Generally ICP1 falls within 30 days, and then the other ones follow on after that. It just depends on what their schedule is and how many client versions inside it they have to update. So I don't know the schedule for the International Client Pack releases.

Heidi: Okay. Next question, regarding client-side updates: If the client is off, will verification occur at the next power on after offset?

Wally: So if your client is not turned on when it's time for it to do its verification cycle for a component, then, yes. The next time the client is powered on, when the CCIM does its cycle, it will check the date and time stamp of when it's supposed to do verification of a component, and oops, it's missed its cycle. It will go ahead and perform verification at that point in time.

It is actually possible, even though I mentioned that we spread this out over time, that if your client is turned off for the entire time period of all your components for their offset, that when you turn your client back on, it will verify the entire client configuration. Normally it's not going to do that unless you're off for a week or so. And you have to be that specific week when it's doing the verification cycle; then it could verify everything. But yes, it would take that at the next wake-up cycle.

Heidi: Okay. Next question: You mentioned that SP2 clients will only assign themselves to an SP2 site. So if we have a current SP1 site and create an entirely new SP2 site on a new server with identical boundaries, will the client automatically migrate to the new site?

Wally: No. That's not what I said. I said if you're an existing SP2 client, then when an existing SP2 client finds a site boundary that indicates it should be a member of a new SP1 or RTM site, it won't assign itself to the down-level site. So I didn't necessarily say that. A new client could still hit your SP1 site and be installed in the SP1 site.

Now, if it were a shared site scenario, so if you were sharing a logon point and you had a non-client hitting the logon point that's shared between SP1 and SP2, then it would install. It would verify both client versions or site server versions, logon point and it would say, oh, I'm an SP2 client, so yes, it would assign to the SP2 site and be installed to that site. And then should not be installed to the SP1 site.

So in that scenario, yes it would. But there's not a blanket statement there as a yes or no; it depends on whether or not it's going to hit a shared logon point, and it can determine whether or not what the versions are of those logon points and sites. If so, then it would default to the SP2 site, yes.

Heidi: Okay. With regard to the client verification cycle: The slide says the component is reinstalled only if necessary. What triggers the reinstall? What is SMS looking at to determine whether a particular component needs to be reinstalled?

Wally: It checks the files that are installed, the base files. So it's checking some of the files in the local client computer, if there's corruption in the files, the CRCs don't match. So basically it's checking CRCs of the client components, and if they don't match the CRC for the bundle up in the client access point, then it determines that it needs to reinstall that component.

Heidi: Okay. The next question is: Just to make sure someone understood something, and it is. Did I understand you correctly? After you apply SP2, you cannot use the Client Verify utility to customize the client verification cycle. Is this correct?

Wally: That is correct. With Service Pack 2 applied, we go back to the default 30-day client verification cycle and the Cliverify utility does not work on an SP2 client. So your clients are going to be doing verification every 30 days, and from what I've been told by the development people, that is not customizable at all.

Heidi: Okay. Next question: Can you use the 1.2 beta console to RC SP2 clients?

Wally: SMS 1.2? If you're talking about SMS 1.2 Admin console to Remote Control SP2 clients, then, no, because we never supported Remote Control of 2.0 clients from 1.2 Admin consoles that I'm aware of. So, and I don't know what 1.2 beta is, because 1.2 has been out four years now. So I think you meant 1.2 Admin consoles to Remote Control SP2 clients and I believe the answer to that is no. I don't believe we support remotely controlling SMS 2.0 clients from an SMS 1.2 Admin console. If I remember correctly, I'd have to look it up for sure, but I don't believe we support that, no.

Heidi: Okay, next question: I've heard that SMS 2.0 solves previous issues with trying to deploy software to a Windows Terminal Server in a manner that allows WTS client to run advertisement sent by SMS 2.0. Are you able to confirm this?

Wally: Last month we did discuss this, that in SP2 for Windows 2000 Terminal Server, we do support software distribution in the background. So after you install a Terminal Server client for Windows 2000 as an SMS client, you can send advertised programs to that client, to that Windows Terminal Server client, in the background. So no – cannot require any user input and so on.

And there is actually a white paper up on the Microsoft Web site. "Windows 2000 and SMS Interoperability," something like that title and that white paper gives you all the details on it as to what the packaged properties are, have to be, for that package and program. But basically, yes; for Windows 2000 Terminal Servers, yes, we do support that software distribution in the background.

Heidi: Excellent. Next question is: How much code is copied to logon points when updating to SP2? Is all existing code replaced?

Wally: If not all the code, the vast majority of it. I didn't do a network trace on it, but I'm guessing it's going to be pretty much the entire code base, which for a logon point is about 15 MB. So it's going to be primarily all of that, because I think the vast majority of your executables and client files are being upgraded; so I would expect it to be basically all 15 MB of it.

I personally did not check, so I can't give you a definitive yes, it is 15 MB or it's only 12 MB. But you should expect it to be all the logon point files because we are upgrading quite a bit between RTM or Service Pack 1 and Service Pack 2.

Heidi: Okay. Next question: Is SMS, Def.mof now automatically propagated to sites when changed?

Wally: If you change the proper location, it always has been automatically propagated. So if you go to \SiteServer\Inboxes\Clifiles.src\Hinv, if you modified that version of the SMS Def.mof, then it would automatically get propagated within your site.

Now, you may mean between SMS sites. If you mean between SMS sites, like from a parent site down to a child site, the answer is no. But if you mean from a site server down to client access points, down to client computers within a site, yes, it has always been the case. But propagating down to other sites in the site hierarchy, no, we do not do that.

Heidi: Okay. Next question: Will the recommended reading documents be available anywhere other than on the CD downloaded patch?

Wally: Yes. They were supposed to have already been put up on the Web site, the http://www.microsoft.com/smsmgmt/ Web site. If not, then they're going to be up there very shortly. I was told that they were up there now. I've not gone up there to look. But we are posting the release notes up on the Web site, yes.

Heidi: Excellent. Next question: Will SP2 support running NetWare 5.X NDS on NT domains?

Wally: I don't have an answer for that. I don't know. If you mean NDS for Windows NT, I don't know if we're supporting that or not. All I've heard for NetWare 5 as far as new – or new support for NetWare is NetWare 5, NetWare IP, and then also supporting the new intraNetWare Client 4.7 Redirector, which the support may be intraNetWare Client 4.71 Redirector by the time we ship SP2.

I have not heard of anything supporting NDS in a Windows NT domain. So if that is NDS for NT, I don't believe so; but I honestly don't know. You'd have to talk to somebody at PSS to what they support for that. I honestly don't know.

Heidi: Okay. Next question: We fully intend to convert to MSI just as quickly as possible. Has the SMS Installer changed in SP2?

Wally: Not in regards to natively creating MSI packages, no. There may have been some other fixes in Service Pack 2 for SMS Installer, but not any integration with MSI packaging, no.

Heidi Okay. We have another question about a list of existing issues that will be fixed in the next patch. I just want to let the individual know, in case they didn't hear it the first time, that there is not an existing list such as that.

Next question: Will the initial upgrade of SP2 on the client initiate a reinstallation of inventories?

Wally: Will an upgrade, you're upgrading an Inventory Agent, so that's basically a reinstallation. You do have a resynchronization event. So inventory is reinstalled basically because you're upgrading to a new version of it. And I'm positive that does do a resynchronization of your inventory. So, yes, you should get full inventory resynchronization as of upgrading to SP2.

Heidi: Okay. The next question, I think you just touched on this, and it's regarding NetWare 5.x again. And that is: Will SP2 support NetWare 5.x using NetWare native IP?

Wally: Yes. We do support NetWare IP. It does require the NDS — the Novel intraNetWare Client 4.7 or 4.72 Redirector — but we do support NetWare 5 as well as NetWare IP.

Heidi: Excellent. Next question: Are the required hot fixes that you mentioned also required for a brand-new installation that has never previously contained any part of SMS 2.0 installed, even if it's installed from slipstream CDs?

Wally: No. The hot fixes are only for existing SMS sites, being RTM or SP1 that are sharing logon points or other site systems with other versions of SMS. So that would be another site that might not be the same version as you are. So anytime you have shared SMS sites, where you're sharing site systems existing sites, then you need the hot fixes. For a brand-new installation, you do not need the hot fixes at all.

Heidi: Okay, moving right along: I have yet to see video acceleration become enabled either through our site or when taking SMS courses, even when doing the registry tweak to add the video driver to the supported list. Have the number of supported video chip sets been increased in SP2?

Wally: I honestly don't know. I have not looked at that list to see if the number has been changed or not. They may have added some additional ones. My guess would be no, but all I have to say is you're taking the class from the wrong location! I mean, all the classes I do, I get video acceleration to work, provided that the hardware supports it. Again, this is an issue — it's not an SMS issue — SMS just detects whether or not it thinks that the chip set is compatible with the drivers it has. And then we make the request to the registry to do video acceleration.

It's actually the operating system, Windows NT, that determines whether or not the driver that we use, the Idsntkm.dll driver, would be compatible with that specific chip set that it detects when it does its Ntdetect.com process during system startup with the operating system and our driver. So Windows NT makes the final call. And we can only state what chip sets we've tested and we know work. If manufacturers or OEMs have modified the chip set or modified the driver at all, then we just can't support everybody with that.

So I don't think the chip set list has changed. It may have, but I don't think so. But acceleration does work, like on my Toshiba laptops, every time I do remote control even in SP1, I get video acceleration, and so I can always demo it. So it does work; it just depends on your chip sets that you have.

Heidi: Okay. The next question: Regarding duplicate GUID issues, will this recognize and fix duplicate GUIDs across the network?

Wally: The only reason you should have duplicate GUIDs is if you're cloning these with the SMS client software already installed. And so you're cloning the SMS unique identifier. And there's nothing within SMS that automatically fixes that. That's an administrative process that you have to take care of to get the SMS client removed from your image that you're creating in your cloned environment. Other than that, there's absolutely no way to get a duplicate ID, because of the fact that the ID, the GUID, is created based off your MAC address, which can't be duplicated between multiple computers, as well as the specific date and time that you install and create that GUID. So the only way to get a duplicate is through cloning.

So the easiest way around it is to remove the SMS client software from your cloned image, or at least all the references to the GUID from your cloned image. However, SP2 does not natively search for duplicate clients and do any fixing on them. If you do find them, then there is a utility in the resource kit called New UID, that you can go ahead and send out to the computers, or at least run that on the computers with a duplicate ID. It will create a new SMS unique ID for that client. But SMS itself does not do any of that processing for you.

Heidi: Okay. The next question is regarding token account Hinv: Will the token accounts be deleted from the client since they are no longer required?

Wally: Who said they're no longer required? We use the token account for a lot more things than just hardware inventory, so the SMSCliToknAcct will not be removed from the client because it is used for many other processes on the client computer. It's just that hardware inventory was the main source of the lockout issues. So the account is still required, so it is going to remain on your Windows NT client computer.

It's just the hardware inventory will no longer use that account. But other functions will still use that account, because you have many different processes that are spawned off from the SMS Client Service, which is when we use the SMSCliToknAcct.

Heidi: Okay. Next question: Are any changes being set for licensing Metering Server, Client, or licensed Server components in SP2?

Wally: SP2 will just have general bug fixes for software metering, but not any functionality changes or anything else. So it's just general bug fixes for it. The actual update of the software metering code will be in the next release of SMS itself. But SP2 and all service packs are primarily bug fixes, so there's nothing new in that area for SP2.

Heidi: Okay. Moving right along: Since SP2 has all the hot fixes applied, is it safe to assume that you can do a fresh SMS SP2 install without any hot fixes?

Wally: Yes. As was asked before, no, you do not need to apply the required hot fixes at a new site because they only apply to SMS sites. So if you're installing a brand-new site, there is no site to apply the hot fixes to. So you can take your SP2 CD (as long as you've got either Web patch version or the slipstream version or full product version) and you can go ahead and install a fresh SP2 site without any hot fixes at all.

Heidi: Okay. Next question: Have you heard of support.com, an SMS alternative? If so, can you compare its functionality to SMS SP2?

Wally: No, I have not and no, I cannot.

Heidi: Okay. Moving right along: SP6a before SP2. It may be better to implement SP6a before SP2. Do I understand you correctly?

Wally: SMS itself doesn't care whether you're running Service Pack 6, 6a, or 5 or 4, as long as you've got at least Service Pack 4 installed. Now, there are some additional requirements that you need to have, such as some of the Y2K fixes. So generally we do recommend that the easiest process is to take the Windows NT 4.0 Service Pack 4 that's on the SMS 2.0 CD, apply it to your site server, and then if you want to go ahead and apply Service Pack 6a, that's fine, and you can do that prior to installing SMS. That is fine.

But there are some Y2K fixes that are only on the Windows NT 4.0 CD that we bundled together, so it's just easiest if you apply our Service Pack 4 bundle, then go ahead and apply whatever service pack you want; then go ahead and apply or install SMS. That's fine. You just need to make sure you have all the requirements met for SMS, including the MDAC version, the Internet Explorer version, as well as the Windows NT service pack stuff. Anything later than that is fine.

Heidi: Excellent. Next question: Has the speed of Remote Control been improved in SMS 2.0 SP2?

Wally: No. SP2 did not implement any changes in Remote Control other than the port numbers, and again, some general bug fixes, but there is nothing in there as far as performance. The general areas around SMS performance for Remote Control is the fact that we do encryption of our data and with encryption, it takes a long time for encryption to take place, to encrypt and decrypt.

And the other issue is video acceleration. If you have video acceleration with your chip set, then you're allowed to do high compression and you get better support and there's not much there we can do with fixing those, because it's just more of an issue with the hardware that you have. So I'm not aware of any fixes at all that we're going to implement any change in Remote Control as far as performance.

Heidi: Okay. The next question sounds like it might be more appropriate for Crystal. But I'm going to go ahead and ask it anyway. Maybe we have an answer: With SP1 and RTM code, there was a necessary workaround for the installation of Crystal Info on sites with more than 500 clients, whereby an extra level was added to the top of the site hierarchy and Crystal was installed on the site. Does SP2 resolve the issues surrounding the installation of Crystal on sites that contain more than 500 clients, or is this workaround still necessary?

Wally: First off, that was not a required workaround. It was not a necessary workaround; it's simply a recommendation. And the recommendation is that for any sites that have more than 500 clients, we recommend that you install a reporting site or new central site that's just doing reporting. So it's not a requirement; you can certainly install Crystal Reports on your existing site hierarchy with more than 500 clients, provided you have enough hardware, the hardware that will support that. So that's not a requirement.

However, Service Pack 2 does not change that functionality at all, it does not change that recommendation. So even with Service Pack 2 applied, we still do recommend for any sites that have more than 500 clients, that you do use a reporting site. So that's really just a resource issue and the resources that the Crystal Info product for SMS takes up and requires. So nothing has changed there as far as that goes.

Heidi: Okay. Next question: Will upgrading the Remote Control components from SP1 to SP2 require a reboot?

Wally: Will update to SP2 require a reboot? I've not seen a reboot required at all on any upgrades that I've done. The only thing would be is if you do reinstall Remote Control, then you have a new KBStuff driver, so the driver that allows you to do the CTRL+ALT+DEL of that Gold key functionality. That wouldn't be applicable or wouldn't work until you reboot the system. However, there is no other required reboot at all when you're upgrading to SP2.

Heidi: Okay. Next question: Will the SMS Installer be updated with SP2?

Wally: We already answered this one earlier. There may be some bug fixes in there, but nothing else as far as major functionality in SMS Installer.

Heidi: Okay. Moving right along: Is there a newer version of MMC with SP2, something that allows exporting and printing specifically?

Wally: We answered this one earlier. No, there's not. SP2 still supplies MMC 1.1. If you want to download MMC 1.2 from the Microsoft Web site, you're allowed to do so and we do support it. However, Service Pack 2 does not automatically install MMC 1.2; it does allow you to export data, so you can print it out, yes. But we don't supply it with Service Pack 2.

Heidi: Okay. Next question: Can you install the client on clustered boxes?

Wally: We still do not support clustering as of Service Pack 2. That's something we're working on, and you should be looking for something as far as support for that coming in the future. But as of today, we will are not supporting clustering.

Heidi: Okay. Next question and I actually think you might have addressed this as well, but I'll go ahead and throw it out here real quick: Do many or any table structures change in SP2?

Wally: Actually this is not the same one we answered before; that was on SQL views. I'm not aware of any table structure changes. There could be, but it should be of no difference to you because you're not allowed to go in and access the SQL tables directly anyway, without possibly corrupting data. I'm not aware of any table structure changes, but because of the fact that we don't want people in SQL Server anyway, it shouldn't make any difference. Because all the utilities you have, the WMI codes, if you're using WMI to access the data, they're still going to be applicable, but I'm not aware of any table changes in Service Pack 2.

Heidi: Okay. Excellent. The next question: Will another example SMS example project plan be published on microsoft.com for SMS SP2? My colleagues and I would find this very valuable.

Wally: I have no idea. I'm not in charge of any example things we've put up on the Web site and I've not heard of it at all, so my guess would be no, but we are updating some stuff for SP2 up there, so there is always the potential for it. But I've not heard of it at all.

Heidi: Okay, excellent. And what we can do is certainly forward that feedback to the SMS product team. The next question is: You mentioned the Cliverify install is much more efficient, stopping all SMS services, etc. Does Windows 95 get these benefits in regard to client components?

Wally: Yes. In fact I believe Windows 95 was the primary culprit that we decided to do this stopping of all the SMS client components when we did the upgrade, because 95 and 98 kept these files in use, and we couldn't update them. So yes, 95, 98, and all our clients gained the benefit of stopping the components and then doing the upgrade of them.

Heidi: Okay. Next question is a client side question: We are currently running SMS 2.0 SP1 plus the SP2 prerequisite QFEs and client bundle. The first question is, when SP2 is implemented, what is the sizing of the files that will be downloaded to the client?

Wally: It's basically going to be a full client again, even with the required hot fixes, because all of the different client components are being installed, and you're basically downloading everything. So the code is basically the same size. So whatever your initial size was of your SP1 client, we installed it; if it was 10 MB, it's going to be about the same. If it was 15 MB, it's going to be about the same. Now, WMI is still there, so that might reduce it a little bit. But basically it's going to be the same as your previous release of the client components.

Heidi: Okay. And the next question is: Clicore.exe is one of the largest client files. Is anything being done to reduce the size of the Clicore.exe?

Wally: Not with Service Pack 2, because of the fact that Clicore, the reason it's so large is that it's the base component that gets installed, that gets expanded, to give you the discovery files. You can do discovery to determine whether or not you should be assigned to the site; and then the code to do the assignment; and then the base components to actually install the rest of the SMS client processes. So it's still a little over 3 MB in size. There may be work in the future to try and reduce it, but as far as Service Pack 2 goes, it's still the same basic size.

Heidi: Okay. Next question: With support for SQL Server 2000 with SP2, is it being recommended to update to SQL 2000, and if so, why?

Wally: That would be a SQL Server issue, not an SMS issue. SMS doesn't care whether you're using 6.5, 7.0, or SQL 2000, so it's purely whether or not SQL Server 2000 gives you any benefits and any advantages that you don't have with your current implementation of SQL Server. For that, you'd have to talk to a SQL Server person to find out what the benefits are for SQL 2000 and how it compares to what you have in your existing implementation. SMS will work with any of the three different versions. We don't really care.

Heidi: Okay. And I think you already answered this question for another customer: In our experience, the Remote Control of SMS 2.0 with Windows NT is not improved. Does SP2 address slowness with remote control? Didn't you – you did, and you said it hasn't changed, correct?

Wally: Right. To my knowledge it hasn't changed at all.

Heidi: Okay. Next question: Are the SMS APM 32 memory leaks completely resolved?

Wally: What SMS APM memory leaks? I'm not aware of any! There still are some issues with APM, and what we're doing now as far as SP2 goes. We're implementing a procedure to stop and restart APM automatically. I want to say it's on a daily basis that we stop and start it and that will release any memory problems that it had, and just keep them from growing in size.

To answer the question honestly, there are still some leaks there, and to work around it for now until we get everything solved. We're doing a stop and start of the agent to reduce the memory requirements.

Heidi: Okay. Next question: Regarding the senior site, I have not implemented SMS 2.0 yet, but could you expand on the purpose of setting a senior site?

Wally: Okay. The purpose of the senior site is to designate which site you want to be in charge of all your domain controllers. By default, we take the site with the highest site code, and whatever site has the highest site code, it becomes the senior site. So all other sites, all they ever do is update their site information up on the PDC of that shared domain. Then the senior site is the site that's responsible for replicating all that site information out to all the backup domain controllers.

So basically the senior site is in charge of replicating and maintaining backup domain controllers for your SMS environment. The advantage of designating one is that you are controlling which site is your senior site, so most often, companies want that to be their central site. If you don't designate it, then whichever site either upgrades to Service Pack 2 first will become the senior site, and then it may change after other sites upgrade to Service Pack 2; or it's just whatever site has the highest site code. And it could be a site that actually is over a slow WAN link that is actually your senior site, and that can cause some issues. So if you're in that environment where you have slow links and sites spread around, then you may want to look at designating your senior site.

Heidi: Okay. Next question: Since the logon script doesn't actually upgrade clients to SP2, will it be up to 30 days before my clients update to SP2, or does CCIM trigger earlier somehow?

Wally: CCIM checks your client access points every 23 hours. So every 23 hours by default if your client's left up and running, CCIM checks the client access points for any updates. So if you've updated your site, your CAPs will be upgraded to SP2, and the next time your client does its CCIM maintenance cycle, which again is 23 hours by default, it will upgrade automatically.

If you stop and start the SMS Client Service or you go to the Systems Management Control Panel program and go to the Sites tab and do an Update Configuration, that will also trigger it. So there are numerous ways to get it triggered, but it would happen automatically doing a CCIM maintenance cycle.

Heidi: Okay. Moving right along: Is there a method for us SMS administrators to pass the information about what we need in SMS? In other words, what do we do to establish a channel between those who use SMS and those who make it? If it already exists, can you tell me what it is?

Wally: Yes; it's smswish@microsoft.com. So you just send any e-mail that you want with requests for the product to smswish@microsoft.com, and they'll go to the product managers and the people who plan out what the future version of the product is going to look like.

Heidi: Okay. Next question: Where can we download the MMC 1.2?

Wally: Boy, I don't know. I don't know what the Web link is for it off the top of my head. My guess is the Windows 2000 Web site. I've seen the Web link before but I don't have it in anything I've written down here, so I can't tell you for sure.

Heidi: Also, if you subscribe to the TechNet subscription CD, it very possibly could be on that CD and might be worth a look there.

The next question is: Is there a way to implement the SP2 client-side software components in any other way besides from the logon point and client access point? Can the client-side software be implemented from a standalone network share or a CD image?

Wally: As of yet, there's still no other facility other than accessing a logon point and a client access point, or using the Windows NT Remote Client installation method. We're working on methods of doing installations of clients through standalone methods, through a CD or something else, but as of today, there is not anything available yet. So still it's the standard methods.

Heidi: Okay. Next question: I think I just heard you say that SMS Installer does not generate an MSI file. Is this true?

Wally: That is true. SMS Installer has never generated MSI files; however, we have a beta utility available that will let you take SMS Installer packages, which are executables, and convert them into MSI packages. But SMS Installer itself has never generated MSI packages natively. This is something that's on the drawing board for it and it's being worked on, but it's not available last I heard.

Heidi: Okay. Next question: If you don't need the hot fixes, for example, you never shared logon point across SMS sites, will you run into any problems if you apply the hot fixes anyway?

Wally: No. If you apply the hot fixes and you don't need them, then you're not going to be hurting anything; you'll just be taking the time and effort necessary to get those hot fixes applied and implemented at your site. But it's not going to hurt anything to apply those hot fixes.

Heidi: Okay. Next question: Are there changes or updates to Network Monitor (NetMon) from SP1 to SP2, and where can the NetMon documentation be found?

Wally: I've not heard of any changes to Network Monitor, other than again there may just be some general bug fixes in there. But I've not heard of any changes to Network Monitor. If there are any, then the changes – Network Monitor documentation is usually either internal, into the product itself, so you go to the Help system. That's where you find the documentation for Network Monitor. Sometimes if there are any extra readme files, they're in the Netmon directory on the site server itself.

Heidi: Okay. Next question: Can you give a quick summary of the functionality added by SP2 for Windows 2000 servers and clients?

Wally: The functionality is that we do allow Windows 2000 Professional, Server, and Advanced Server to become SMS 2.0 clients for Service Pack 2. All client functionality is maintained that exist on Windows NT 4.0 or other platforms; with the exception currently of Remote Control video acceleration is not enabled. That will come in the future, but as of right now it's not there.

And as far as site systems go, all SMS site system roles are supported on Windows 2000, Site Server, SQL Server, Software Metering Server, CAP logon point, distribution point, SMS Admin console, etc. Terminal Server is supported on Windows 2000 for the Admin console as well as for client code (limited client code like hardware and software inventory and software distribution in the background); and no logon script installation, you have to do manual or remote client installation. I think that pretty well covers it for a quick summary.

Heidi: Okay. Do you happen to know where I can download WMI 1.5 for Windows 9x and Windows NT 4.0?

Wally: I think I do have that in a document here with me. Yes. You can go to http://msdn.microsoft.com/downloads/default.asp?URL=/code/topic.asp?URL=/MSDN-FILES/028/000/015/topic.xml. And there you'll find the hot links for downloading for Win 9x as well as NT 4 platforms.

Heidi: Okay. Next question: Can I use MMC 1.2 with SP1, and if so, is there any benefit?

Wally: MMC 1.2 with SP1, I've not heard of any issue with using it. I doubt it's a supported platform, because we only supported MMC 1.2 with Windows 2000, which we don't support with SP1. So it probably wouldn't be a supported platform, but it may be; I've just not heard of anybody doing it.

The benefit is MMC 1.2 is a little bit quicker. MMC 1.2 has the ability of taking data and exporting it to a text file and then printing it out. There is, oh, what else? It's quicker, you have the ability of doing counts, so if you run a query – I think when you run a query there's an option for doing a count of the number of contents that are returned. A few issues like that.

Heidi: Okay. Next question: Will Microsoft be publishing a product to create MSI format installs? Perhaps an update to SMS Installer, or will we have to use third-party products to create MSI installs for SMS pushes?

Wally: I've already mentioned that the SMS Installer, we have a utility right now that you can convert SMS Installer packages to MSI packages. As I mentioned before, we are working on taking the SMS Installer and making it create MSI packages natively. So we have something we're working on right now.

You're certainly welcome to use any third-party utilities you want; that's fine. SMS doesn't care what you use as far as your creation ability or as far as your packaging ability; SMS is just distribution technology. So you can use any other packaging utilities you want, whether it's from any third party or when SMS Installer is there.

As far as creating them and publishing documentation, I have to believe there's documentation up on the Web site for creating MSI format packages. I've got to believe there's something up there. I know there's information up there on distributing MSI packages with SMS, and how you can work with that; but as far as actual creation of MSI format installs, again that's some sort of utility that you'd use to create that actual package itself. But there is a white paper up on the Web site, http://www.microsoft.com/smsmgmt/, which talks about distributing MSI or Windows installer packages using SMS.

Heidi: Okay. The next question looks like a comment, and it is: The MSI tool is available for TechNet Plus subscribers. TechNet Plus subscribers, of course, get beta CDs with their subscriptions.

Wally: That is correct. It's called the Installer Step-Up Utility, and it is available in beta format, provided you have the TechNet Plus or the beta code.

Heidi: Okay. And the final question for today: Is the bug of untargeted advertisements following a deleted advertisement added successfully addressed with SP2?

Wally: Yes. I've not heard of that bug. I've heard of where advertisements go to non-recipients, but I've not heard of one where an untargeted advertisement follows a deleted advertisement addressed successfully. Unless again it's just a matter of reusing the same ID and then that would hit that sequence.

There are some fixes in Service Pack 2 to help address advertisements going to the proper recipients, so there are fixes in Service Pack 2 for that as well. So that may be addressed. I've not heard of this specific issue, at least in that format before, so I can't state for sure. But it does sound like it.

Heidi: Okay. And with that question answered, we have cleared the queue of all the questions posed during today's session, and we're going to go ahead and get wrapped up. Once again, if you have any feedback for us, please submit that using the alias feedback@microsoft.com. Be sure to include "Support WebCast" in the subject line.

Once again we do want to thank you so much for joining us today. We hope you found this information valuable and find time to join us again in the near future. Have a great day and goodbye.