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

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

Wally Mead: Welcome. Good morning and/or good afternoon as appropriate. Since SMS 2.0 Service Pack 2, the SMS product group has produced two different service packs that were simply a rollup of QFEs or hotfixes. As a result of those, there wasn't any compelling reason to have WebCasts on either of those two service packs, either SP3 or SP4.

SMS 2.0 Service Pack 5, however, does introduce some new features and some new functionality in addition to the standard QFE rollup that we would have. Because of these new features and new functionality, we felt it necessary to have a session on SP5 to let you know what was coming down the pipe in SP5, so that you could be prepared for it and see what some of the new changes and things that are introduced and how they're going to have an effect on your network environments.

The topic of today's session is "What is included in SMS 2.0 SP5, and do I really need it?" Our agenda for today is, we'll talk initially about what is Microsoft SMS 2.0 Service Pack 5 (slide 2). Why do we need a session on it to discuss QFEs? As I just mentioned, it's more than just QFEs for this service pack. We've gone out of the mode of just releasing QFEs, because there are some very important things we wanted to get covered in Service Pack 5. There are some implementation changes and functionality changes that are going to hit your SMS environments when you do upgrade to Service Pack 5, so we're going to have a session on it.

We're going to talk about the different types of updates in SP5. Basically, those are in a couple different groups. Some of the updates are pretty self-explanatory, so all I'll need to do is reference the update itself; that this update does this, and you'll know all you need to know about it as far as what it's going to do for you. Some of the other updates, however, are a little more detailed in how they operate and what they do your SMS environment, so we'll spend some more time on those specific or individual updates as necessary. In some cases, I'll just have a single slide that will cover an entire category of updates, such as interoperability with SMS 2003, so I'll just have a single slide. For other topics I'll have multiple slides on a single topic getting into more detail on areas that might be a little more confusing for you, or areas that are going to change your functionality enough that you really need to understand things.

What is in SMS 2.0 SP5 that requires us discussing it (slide 3)? There are three major themes of SMS 2.0 Service Pack 5.

The first theme is improving SMS 2.0 security, and we'll discuss this a little bit later on, this is an overview slide. We want to make the SMS environment more secure, ensuring that there are fewer opportunities for hackers to gain access to your environment through the SMS system.

The second theme is improving support for Windows® Server 2003. This is the new offering system that will be released very shortly, and we want to make sure that you can utilize it effectively in your SMS environments.

Thirdly, improving interoperability with SMS 2003. We already do provide interoperability with SMS 2003 with SMS 2.0 Service Pack 4, but we're improving that with some of the changes made in Service Pack 5 that we'll discuss a little bit later on.

There are some additional changes that we'll talk about and reference throughout the presentation.

As usual, there is also a rollup of QFEs or hotfixes that were released after SMS 2.0 Service Pack 4. We'll discuss those, as well as a few additional fixes, but primarily, we're going to focus on those three themes. I'm not going to go through and talk about individual QFEs that are fixed in Service Pack 5. You can get that from the KB (Knowledge Base) article when it becomes available, when the product gets closer to release.

Just to answer your questions now, Service Pack 5 just went to beta last week. I believe it was Wednesday of last week Service Pack 5 went to beta (follow-up information: it went to beta on January 24, 2003). It will be released to manufacturing later on this quarter. We're targeting a March timeframe for RTM (release to manufacturing) and release to the Web of Service Pack 5.

Of course, this is subject to customer verification and approval. We're going to, as usual, allow our customers to dictate when this service pack is ready to be released.

I'll discuss, at the end of the presentation, how you can gain access to the SP5 beta if you do want to participate as a beta tester or if you do want to test it out in your own environments, but it did just release to beta last week.

Let's talk about some of the specifics on the service pack, and that will be the majority of our presentation time today (slide 4). There are a number of specific feature areas that were addressed in SMS 2.0 Service Pack 5. I mentioned three of these already as the major themes of Service Pack 5.

One is Windows Server 2003 support. SMS 2.0 SP4 offered very little support for Windows Server 2003. We're providing full support for it in Service Pack 5.

We're providing better SMS 2003 interoperability. We're improving the support that was already offered with SMS 2.0 Service Pack 4.

Network communications, we're going through a process of reducing the network traffic requirements on your networks because of SMS. That should excite you, because we're reducing some of those network traffic areas, specifically in the area of clients doing advertisement verifications, so going to the client access points, looking for advertisements. We're reducing the amount of traffic required there, and I'll talk about that toward the end of the presentation.

We'll spend quite a bit of time, in this presentation, talking about security enhancements. What are some of the things we're doing in SMS 2.0 Service Pack 5 that will provide a more secure environment for your SMS infrastructure after you upgrade to Service Pack 5. We'll spend a lot of time discussing that, a number of different slides on that topic.

Then, there are a few miscellaneous changes we'll talk about, such as slow link detection for advertisement running, so we'll talk about those things that are important to be noted.

Again, there are going to be things I'm not going to cover in this WebCast, individual hotfixes that are being fixed in SP5 and so on. You'll be able to get that from the Knowledge Base article when it is released later on.

The first thing we want to talk about is support for Windows Server 2003 (slide 5). Windows Server 2003 will be releasing before SMS 2003 is released, so we need to make sure that our existing SMS customers can take advantage of the newest operating system from Microsoft. We're going to spend a little time discussing our Windows Server 2003 support. We'll look at all the different features that are listed on this slide. Again, this is an overview slide, and I'll go into more detail on the next couple slides.

The areas we'll discuss include using Windows Server 2003 as an SMS site system as well as an SMS client.

Then, we'll talk about a specific problem that we encountered with the SMS provider in a Windows Server 2003 environment. There was an issue there that caused problems in the SP4 timeframe that we have solved for you.

Windows Server 2003 is now listed as a supported platform for software distribution targeting.

User and group names longer than 64 characters are now supported, where they were not supported in Service Pack 4. There was a problem that you would not be able to utilize any account names that were longer than 64 characters.

The SMS User Wizard, when you want to set up security rights, has had a fix to it, or Service Pack 5 has had implementation changes that allow you to utilize the SMS User Wizard in a Windows Server 2003 native mode domain environment.

That's just a quick overview. Now, let's talk about some of the details (slide 6).

As a general rule, there was no support for Windows .NET Server, which is now called Windows Server 2003, in SMS 2.0 Service Pack 4 without specific QFEs that were applied on top of Service Pack 4. For a long time, we limited those QFEs to simply members of the JDP program. SP5 changes this dramatically.

First off, all SMS site system roles are supported. In other words, you can upgrade your SMS site systems, whether it's a site server, whether it's a SQL Server computer, whether it's a CAP, a distribution point, a software metering server, a logon point, whatever it is, you can upgrade those servers to Windows Server 2003 and expect that the SMS site system role will function properly. We do have full support for all SMS site system roles.

In addition, when you upgrade those computers to Windows Server 2003, we're going to automatically upgrade the SMS client component running on those computers, provided that they're within the site boundaries, so they are an SMS client, and we'll upgrade those to Service Pack 5 clients.

All SMS client functions are fully supported as well, so hardware inventory, software inventory, software distribution, metering, remote control, and so on. All those features are supported in the new operating system.

A couple of updates specifically for software metering, software metering is supported even with Terminal Services installed and enabled. That was something that we did not do and we do not support for Windows 2000 or Windows NT® 4.0 servers that had Terminal Services enabled. Software metering was not installed and it was not enabled there. It is on Windows Server 2003 with SP5.

One caveat there is that software metering can monitor only 32-bit applications. If you're running software metering code on a Windows Server 2003 computer as a client computer, you can do software metering but not metering 16-bit applications. You can only meter 32-bit applications.

Another issue was that in SP4 and previous releases, when your SMS provider made a request to the WMI (Windows Management Instrumentation) to retrieve data, if the data was coming from a Windows Server 2003 environment, so a WMI running on top of Windows Server 2003, it returned the data with a fully qualified domain name (FQDN). The SMS provider in SP4 and earlier did not support fully qualified domain names. In essence, no data was returned to the SMS Administrator console. If you went in there, opened the console and tried to view collections, packages, or advertisements, and expand those in the Admin console, you got no data returned. That was because the WMI code in Windows Server 2003 used fully qualified domain names, which the SMS provider did not support. That is now supported in Service Pack 5. Service Pack 5, the SMS provider does support the fully qualified domain names that are going to be returned from WMI when running on top of a Windows Server 2003 computer.

Another update is that Windows Server 2003 is listed as a supported operating system for software distribution. When you go to your program for your package and you go the Requirements tab, you can now list Windows Server 2003 as a target platform. You can go in there and restrict what platforms you want this advertisement to be applicable for, and then the client will filter those out when the client tries to validate the advertisement. You can designate that as a target platform, in addition to your standard discovery will detect the operating system. You can then do queries that would target the operating system as well, but this would be the specific filtering on the operating system by the SMS advertised programs client agent.

A few more updates (slide 7) for providing better Windows Server 2003 interoperability, CCIM, which is the Client Configuration and Installation Manager, this is the piece code on an SMS client computer that will, every so often, wake up, go out to your client access point, look to see if there any new client agents that need to be installed, any client agents that should be de-installed, any updates to schedules or configuration for any of those clients agents, and so on, as well as looking for upgrade of the client components because the operating system has changed or your SMS service pack level has changed. That code had an issue in SP4 on a computer that was running Windows 2000 that was upgraded to Windows Server 2003.

When you had a Windows 2000 computer that was an SMS 2.0 SP4 client, and you upgraded that computer to, back then it was Windows .NET Server, and again now it's Windows Server 2003, what happened was the NAL registry permissions were lost. In the registry for NAL, HKEY_LOCAL_MACHINE\Software\Microsoft\Nal\Client, the registry permissions were lost, so that the SMS client components couldn't access NAL, and you had some issues. What happened is that, if you went to your Systems Management Control Panel program and then went to the Components tab that lists all your components, they would all list Repair pending as their status.

We've now fixed that and what happens now in Service Pack 5 is that CCIM, again the Client Configuration and Installation Manger, will periodically check the permissions set on the NAL key in the registry and if necessary, it will reset those permissions as necessary for the SMS Client service to do it's work. Then, it will use that, so all your client components will appear properly with the correct status.

Another upgrade to allow better interoperability is the area where we now can support account names (either user accounts or user group accounts) that are longer than 64 characters in length. If you used Windows user discovery or Windows user group discovery and you had account names that were longer than 64 characters, when you were including the domain name and the account name, Service Pack 4 was not able to retrieve those on top of a Windows Server 2003 domain. From a Windows Server 2003 domain, if the domain name and the account name were greater than 64 characters, those accounts were basically just ignored and no discovery record was created for those accounts. Service Pack 5, now it does allow you to do discovery, Windows user accounts and Windows user group accounts of a Windows Server 2003 domain and create DDRs for accounts that were greater than 64 characters in length.

The last thing we'll talk about in this area is support for Native mode domains when using the SMS User Wizard for security right assignment. What was happening in Service Pack 4 is that, if your domain that you were using for browsing names in the SMS User Wizard was a Windows Server 2003 domain in Native mode, the SMS User Wizard was not able to retrieve group accounts. Now, we do have support for Native mode Windows Server 2003 domains when running the SMS User Wizard and then clicking the Browse button to produce a list of accounts, user accounts and group accounts, that you could use for importing into the wizard for assigning your security rights.

That's Windows Server 2003 interoperability. We've done a nice job in giving you support for the latest operating system when it becomes released. You should feel free in upgrading your environments to Windows Server 2003, if you're ready to do so.

The next area we want to talk about is SMS 2003 interoperability (slide 8). This all fits on a single slide, so there's just a single slide on this interoperability. SMS 2.0 Service Pack 4 already does provide some interoperability with SMS 2003 beta, so we've got the basics there already, but we've made some improvements in Service Pack 5 to provide better interoperability with SMS 2003.

The first area is support for signed site-to-site transfers. We're going to talk about this in greater detail a little bit later on in the presentation when we get to the security enhancements, because it will be the same for SP5 to SP5 as it is for SP5 to SMS 2003. Basically what this upgrade means is that SP5 of SMS 2.0 acts just like SMS 2003 does as far intersite communications and that we sign the communications between sites now when we're communicating with equal sites or up-level sites. We'll talk about the interoperability with down-level sites that don't do signing, and we'll talk about that a little bit later on in the security section. But just as a reference, we do now provide site-to-site transfers that are signed from SP5 up to SMS 2003 and vice versa, so your SMS 2003 parent site can communicate with an SP5 child site, because it will be doing signed communications.

The next fix is for the ability of using Courier Sender to send packages from an SMS 2003 parent site down to an SMS 2.0 child site. What was happening in SP4 was that the SMS 2.0 Service Pack 4 despooler was not able to read the instruction file that came from the Courier Sender parcel because of the fact that SMS 2003 now does signing. When it does signing of its data, it's not doing compression of the instruction files, and the despooler was trying to decompress the file, when it wasn't compressed. Now with this fix, the SP5 despooler will look for compressed instruction files as well as signed instruction files and be able to retrieve those parcels from a 2003 parent site. You can unbundle them and utilize the Courier Sender parcel down at your SMS 2.0 Service Pack 5 child site.

The next fixed area is that SP5 clients will not "over install" (install on top of) SMS 2003 clients. There was an issue with prior releases that the SMSMan utility and in some cases the Smsls.bat, the login script, they weren't validating the version numbers of the clients that might already be installed as SMS clients. Because of that, they would allow, specifically in SP4 environments, to install on top of an SMS 2003 client. Even though SMS 2003 had a higher release number, a higher version than SP4, the SMS Man program was not validating that version correctly, so it was thinking it wasn't an SMS client, and it would kick off an installation and install SMS 2.0 on top of SMS 2003, whether that was the Standard client or the Advanced client, so that caused some issues. Now what we've done in SP5 is that we fixed the SMSMan and other utilities so that when they do a version check, they properly validate the version numbers for SMS 2003, they detect that, "Hey, this an up-level client," and they would bail out and not do anything. You will no longer install SMS 2.0 clients over top of SMS 2003 clients. So that allows you to have a mixed environment and not worry about your down-level client stepping on top of your up-level client.

Lastly is a scenario where you had a parent-child relationship, a primary site and a secondary site let's say, both running SMS 2.0, and you upgraded your primary site to SMS 2003. Now, you have an SMS 2003 primary site and an SMS 2.0 child site. Let's say, when they were both SMS 2.0, they were sharing logon points, so it was a single domain, and they were sharing logon points. What would happen was that the Copylog.tcf file on the logon point would have reference only to the parent site, because it would be the senior site, most likely. The parent site would be listed in the Copylog.tcf file as the site that owned the logon point.

When the parent site upgrades to SMS 2003, as you know SMS 2003 no longer uses logon points. As a result, we would remove the parent site's site code from the Copylog.tcf file. But because the child site, the secondary site's site code, was never added to that Copylog file, then there was basically no site that could be used for installing new clients. What happened would be that any attempts to install new clients, when you'd upgraded your senior site to SMS 2003, would put you in a place where you couldn't install your clients, because the logon point wasn't properly configured in the Copylog.tcf file.

Now with SP5 what we do is, each site is added to the Copylog.tcf file if it is running the same version of SMS as the senior site. You would upgrade your primary site and your secondary site to SP5, and both those sites would be listed in your Copylog.tcf file. Now if you were to upgrade your parent site to SMS 2003, you would still have the child site listed in the Copylog.tcf file, so now attempts to install new clients at that child site would be successful because there would be a site code reference that was valid in the Copylog.tcf file. That will let you install new clients for SMS 2.0 in a mixed environment, when you've upgraded one of your existing sites to SMS 2003.

That's the interoperability updates we have for SMS 2003. Again, I'll spend a lot of time on the signed intersite transfers in a few more slides.

Network traffic requirements are very important to many customers (slide 9). Reducing or limiting the amount of traffic generated over the network is a great benefit. SP5 helps in this area as well. One of the things that we've done in SP5 is to reduce the amount of network traffic generated in a couple different scenarios.

The first scenario is with the Advertised Programs Manager or you can just easily say software distribution. What happens now is that the APM, the Advertised Programs Manager, on the client computer, which is basically SMS APM and the ODPs (Offer Data Providers) on the clients are more intelligent in how they access the network for scanning for advertisements. What happens is that when your interval is reached for checking for advertisements, and by default it is hourly, your APM code on the client would wake up two different ODPs (Offer Data Providers). They would go to the client access point and look for any advertisements that were available to that computer, to the logged on user, or to the user groups that the logged on user was a member of. Those Offer Data Providers would go the CAP and look for specific files to determine whether or not there were any advertisements available for the computer, the user, or the user group the user was a member of. What used to happen was that the ODPs used to scan the entire CAP, so they would just do a search of the entire CAP and all the folders looking for the lookup files that they needed.

Now what happens is that we just do a quick check to make sure we have access to the CAP. Then, we go to the specific Offerinf.box directory looking for those lookup files. We used to do a scan of the entire CAP, validating that we had access to the CAP, and then we looked for the files we need. That generated a lot of traffic over the wire. Now, we just verify that we have access to the CAP itself, and then we go specifically to the Offerinf.box, looking for the lookup files for computers, users, and user groups. That reduces traffic dramatically.

Another thing that's changed is that when APM or the ODPs did their scanning on their hourly basis or whatever the configured interval was, and I know some customers have dropped that down to every five minutes or something smaller, that generates a lot of network traffic. One of the reasons was not only the way we access the CAP, but also that when the ODPs launched off, they would go out there and validate all the package files for any advertisements that they had previously run. This was to see if any of the program data had been updated for those advertised programs that they had already run. That, again, generated a lot of network traffic.

Now what we're doing is, we no longer are looking for updated program files for these advertisements that we've already run. We'll just look at the program data, the package data, when we run those advertisements themselves and not do the looking for updates of those files on an hourly basis or, again, whatever your configured interval is.

In talking to some people, some of the tests that I've heard about and seen were that the traffic was reduced by more than 50 percent by making these couple of different changes in APM code. You should see some significant savings in network traffic requirements through APM after you upgrade to SP5. These savings go up the larger the number of clients you have and the larger number of advertisements you have. In one case, I was seeing that a customer had like 1,500 advertisements in their environment, and the amount of traffic was reduced by something like 80 percent by making these SP5 changes. You should look for some significant traffic savings for your client computers communicating with your client access points when you're doing software distribution and looking for new advertisements or just doing your verification on an hourly or your configured interval basis.

The next area of network traffic improvements is fewer domain replication events. This comes from a couple of different areas. One is due to some changes we've made on the client installation on domain controllers and the bootstrap accounts; some fixes there, so that you don't have as many retries with the many bootstrap accounts that are being created, profiles that are being left over. There are also some changes in accounts that we'll discuss later on. Basically, we've taken one of the accounts that used to be a domain account, and we've now made it a local account. By making it a local account, it's not in your domain any longer, so it won't be a new account added, and that will generate fewer replication events as well.

I haven't seen any traffic numbers on this, because it's hard to qualify because of many different environments and environmental issues that we'll discuss later when we talk about one of the accounts at the very end of the presentation. Any time you can reduce a domain replication event, that's a good thing, so we are helping you out in that area as well.

Providing a secure environment is a very important thing to Microsoft (slide 10). You see security patches released on a regular basis to resolve specific issues that have been discovered. The SMS product group spent a number of months doing security analysis of both SMS 2.0 and SMS 2003. There have been a lot of fixes added to SMS 2003, and that's why you saw some of the schedule flips in that product, because of the security enhancements and more appropriately the time spent required doing the security analysis. There weren't actually that many things we had to improve in SMS 2003. SMS 2.0 Service Pack 5 is an update that does provide security enhancements for your SMS 2.0 environments. There are a number of different things that we've done in the security area to make your environment more secure for SMS 2.0.

The first one is optional signed site-to-site communications. I'm not going to discuss that one on this slide, because the next three slides are going to discuss site-to-site communications and the signing. I'm going to leave the details for the next three slides. I just wanted to make sure it was referenced here, that we are now doing signing of site-to-site communications between SP5 sites. Again, I'll discuss that area, which is coming up very quickly.

Next area is that optionally, you can now maintain your SMS logon points using a non-administrative SMS account. That, again, I will cover in a few more slides. Right after the site-to-site communications, I'll talk about the logon point maintenance updates, and how you can use a non-administrative SMS account to maintain your logon points. I have a couple of slides on that for you.

The last four bullets on this slide are things I don't have additional slides on. I'll just talk about them on this one slide.

First off is, we went through and did a sweep of all our Access Control Lists and did a number of validations and updates to registry ACLs, file ACLs, folders, name pipes, mail slots, and so on. All those different areas of access were reviewed and validated as to whether they were locked down as far as they could be or should be, or whether they needed to have some additional work done on them. We've done a review of our Access Control Lists in many different areas to make sure that we're not providing more access than we really need to provide in some areas.

Additionally, there are a number of different fixes internally in the code that help to provide more secure internal communications between SMS resources. Those resources might be how accounts are accessed or how data is transferred and encrypted, whereas before they used to be non-encrypted mode, or how the accounts are being accessed or utilized, internal Access Control Lists being updated for and secured for non-SMS-type access. We've done a lot work going in there validating that the security of the environment is as much as we could do, hacker proof, or at least less potential for hacker intervention.

A big area that will make a lot of you very happy is the SMSCliToknAcct& issue, that basically forever in SMS 2.0; we've had issues with SMSCliToknAcct& lockouts. The reason for the lockouts is that all SMS clients generate an account called the SMSCliToknAcct&, and that account is used for internal communications and spawning off other threads of the SMS Client service to maintain separate processes and maintain security. That account is a local account on all SMS clients, but if you have an environment where you're using domain controllers as SMS logon points or just as SMS clients outside of the logon points, but anytime you're using a domain controller as an SMS client, it also has to create the SMSCliToknAcct&, and as you know, a domain controller doesn't have a local accounts database like does a Standard client computer or a member server. It only has a domain SAM. When you created the SMSCliToknAcct&, it was created inside the domain. Every single client has a unique password for the SMSCliToknAcct&, but domain controllers can't have a unique password, because they're all sharing a single account. The domain controllers, their versions of the SMSCliToknAcct& had a password that all the domain controllers knew and they shared, and each individual Windows NT 4.0 and higher client had a unique SMSCliToknAcct& with its own unique password. There were times when that account was used to access resources across the wire, which meant the account had to be validated to cross the network. Because of the fact that each client has a unique password for that account, when that account was validated in your domain, the SMSCliToknAcct& in the domain had a different password than the SMSCliToknAcct& on the client computer. If you had account lockouts enabled, very quickly that account would be locked out.

We've done numerous different fixes over numerous different versions and service packs and so on to improve that, and in every service pack, we've actually improved the areas where that account gets locked out. Software distribution had some; hardware inventory had some and so on. We fixed a lot of those issues. They just keep cropping up, however, frankly.

What we've done in Service Pack 5 is that we've left the SMSCliToknAcct& as a domain account for domain controllers. When your domain controllers become SMS clients, they utilize the SMSCliToknAcct&, and they share a single password. However, on non-domain controllers, so on all SMS clients that have a local accounts database that's a non-domain controller, Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003, member servers, and just clients, what we've now done is implemented a new account. That account is SMSCliToknLocalAcct&. We've created a new account name for those clients and again, they'll have unique passwords, but because this account name is now different than the accounts the domain controllers use as clients, then you won't have account lockout issues, because this account will not exist in your domain, so it won't be an account that's locked out. It will just be an account that's not validated.

The domain controllers still use the SMSCliToknAcct&. However, all non-domain controllers use a different account, and those accounts will never access each other. If they try to get validated across the network in the domain, the account won't exist and you won't have password problems and your account won't lock out. That will be a great win for you guys to help reduce those account lockout issues.

The last area that we updated for security is the SMSCliSvcAcct&. On your client computers, they run the SMS client service under a user account called SMSCliSvcAcct&. We never recycled that password on a consistent basis. If you reinstalled the client code, then you'd get a new password and so on, but there was never a scheduled recycling of that password. That caused problems in some of your environments where you had policies where you had to go out there and recycle your passwords.

Now what happens in SP5 is, the SMSCliSvcAcct& generates a new password on a weekly basis. Every week, it's going to go in and change the password for the local account. Again, this is not an account that is shared anywhere else. It's just used locally on the client. Even in a domain controller environment, each domain controller had a separate, unique account, it was SMS&_ and the computer name, so that you might, if you had an environment with 100 DCs, you'd have 100 of those accounts in your domain, but they'd all be unique. On non-domain controllers, the account is SMSCliSvcAcct&, and this account is now cycled weekly. You can configure this if you want to.

If you want to specify a different interval for your password regeneration for the SMSCliSvcAcct&, you can do so through a registry update. I'll give you the path here. It's HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\Client\Client Components
\SMS Client Base Components, and then you add a new registry value called ServiceResetInterval. In the SMS Client Base Components key, you add a value of ServiceResetInterval. It's a REG_DWORD, and you specify your interval in seconds, so the number of seconds you want for the SMS Client service to generate a new password. Then, we'll take care of the generation of the passwords for you at that time.

One of the big areas for improvements for security to give you better security in your SMS 2.0 environments, as well as to improve your interoperability with SMS 2003, is the area of site-to-site communication changes (slide 11). What we're doing now to improve security as well as interoperability is that SP5 sites always sign data when communicating with a parent or child site that's running SMS 2.0 Service Pack 5 or SMS 2003. If my current site is SP5 and my parent site is either SP5 or SMS 2003, then I will always use signed site-to-site communications. My site control files, my discovery data, my inventory replication, and my status messages going up will always be signed. Any data flowing down from the parent down to my site would be signed as well, advertisements, packages, collections, and so on. If my child sites are also running SP5, I'll use signed communications between them, so we're improving the security by using signed communications in an intersite environment, so in a site hierarchy environment between SP5 sites as well as SP5 and SMS 2003, which again will always be a parent, never a child.

Signing is always enabled in an SP5 environment. However, by default, communications with down-level sites, in other words SP4 sites and earlier, is automatically allowed. We don't restrict it to saying that because you're now signing at your SP5 site, you can no longer communicate with a down-level site, let's say an SP4 site.

By default, you are allowed to communicate with a child site that's running SP4 or earlier. However, that is an option that you can configure. If you want, you can configure your site to say, "My site is SP5. I only want to communicate with other sites that are doing signing of intersite communications," so that would be SP5 as well as SMS 2003. The SP5 site knows child sites and what versions those child sites are. Even your SP5 site, when it is communicating with signed data up to a parent site that's SP5 or SMS 2003, if it knows the child site is SP4, by default, it will use unsigned communications down to that SP4 child site. You would communicate with your down-level sites as you normally would. It's just that when you are going site-to-site with SP5 or up to SMS 2003, you'd always do signing.

If you do want to restrict your communications to communicate only with SP5 and higher sites, you can enable that through your Site Properties dialog box. On this next slide (12), I have a screen shot for you of the new Site Properties Site Communications tab for SP5. You can see, there are a couple of check boxes here, and they're identical to the check boxes that you have in SMS 2003 on its Site Properties dialog box, if you can think about that.

The first one says, Do not accept unsigned data from sites running SMS 2.0 SP4 and earlier. That is not selected by default, which means that you can successfully interoperate in your hierarchy between down-level sites (meaning SP4 and earlier) and your SP5 site, even though it's doing signing. What would happen here again is that we'd recognize that these child sites are SP4 or earlier, and we would use unsigned communications.

If, however, you select that check box so that you're not allowing any communications with SP4 and earlier, then you will not be able to successfully interoperate between an SP4 or earlier site and your SP5 site. It would only allow you to communicate with another SP5 site or an SMS 2003 parent site.

It's very important that you understand that, so that you don't go out there an upgrade willy-nilly in your site hierarchy, and have some sites where you enable this check box and now all of a sudden, you don't have proper communications between the sites in your hierarchy. What actually would happen is that your SP5 site still would send down unsigned data down to your SP4 child site, so you would still have down-level communications. However, what would happen is that your SP4 child site would try to send unsigned data up to your SP5 parent site, or it could be vice versa, the SP4 site could be a parent site and send data down to an SP5 child site, however we do generally recommend top-down flow of service packs, but regardless, your SP4 site could send unsigned data to your SP5 site.

If this check box was enabled, that data would be deleted by the despooler at your SP5 site and not processed. If you think about that for a second, you could control your down-level SP4 sites and send data down to them, however you would not receive discovery data, inventory data, status message data, etc., up to your parent SP5 sites. You need to be very careful of that. If you do enable this and your child sites haven't upgraded successfully to SP5, you're not going to have a valid picture of what your child sites look like, because you're going to have out-of-date data. They're going to discover new resources or get updated inventory data, updated status on interoperability, communications, and so on, and you're not going to have a true reflection of that, because you won't be processing any of the data they send you from the time you select this check box. The key thing is, don't select the check box unless you have upgraded all your sites to SP5, otherwise you are going to have communications issues.

The second check box there that says Require secure key exchange between sites also is similar to SMS 2003. In SMS 2003, when you select that check box to require secure key exchange, that means that the SMS 2003 environment will retrieve the keys from Active Directory®. Since SMS 2.0 doesn't utilize Active Directory, it requires manual key exchange by an administrator to dump the keys for the parent site and manually replicate them down to the child site, putting them into the child site's Hman.box directory, so the child site can process them, and then have those keys implemented, so that now you can communicate between your sites using signed communications. If you have the secure key exchange, it's a manual process of dumping out your keys for the child or the parent site and then manually sending them up to the other site or down to the other site, processing them into the local site, and then you can do your standard site-to-site communication process.

The new Preinst utility for Service Pack 5, so the Preinst utility in Service Pack 5, has a number of new switches added to it that allow you to dump out your keys in a format for transfer to parent sites or child sites. It's just some implementation information on this change for site-to-site communications.

Again, all communications are signed with public and private keys (slide 13). That happens by default when you're communicating with an SP5 site or an SMS 2003 parent site. In site-to-site with SP5 or SMS 2003, all communications are signed. If the data is not validated, it's not processed. It will be ignored or deleted by the despooler. If the keys are not valid, the data will be deleted by the despooler.

When you enable the check box to say, "I do not want to communicate with unsigned communications with down-level sites," then you, again, lose communication abilities with your SMS 2.0 SP4 and earlier child sites or parent sites. Again, it's important that you understand when you want to select that check box, and that's only when you're communicating only with SP5 sites or with SMS 2003 parent sites. With that check box enabled, you will lose the ability to effectively communicating with your child sites that are SP4. Again, you can send data down to them, because you're going to send down in unsigned mode, but data flowing up will not be accepted. It will be deleted from the unsigned child sites.

If you have two separate SP5 sites, that are stand-alone sites, and now you attach them together, then at site attachment, those keys will be transferred automatically. Those keys will transfer, and we'll do some package routing, so that when you attach to the new parent, the parent will send you down its keys, and you'll replicate those down to your child sites, so that your child sites can have keys as well, in case the parent then tries to send data directly down to your child site.

Again, with that check box enabled, you may have impaired communications with your down-level sites (being SP4 and earlier). You won't accept any data they send to you, so be very careful of that.

Again, it does interoperate fine with SMS 2003, which does the exact same data signing. Basically, SP5 now acts like SMS 2003 as far as the site-to-site communications go.

What you'd want to do is validate by looking at your Despooler.box\Receive. After creating a user account, you can configure the sender to use a specified account in the Addresses portion of the folder for a backlog of instruction files from a remote site that haven't been processed. If you do upgrade sites to SP5, it can take awhile for the public keys to get transmitted between sites and processed. I've heard it may take a half hour or so for that to get fully processed, transmitted down the wire and processed. You'd want to validate by looking at the Despooler.box\Receive folder to see if you are having a backlog of data from your SP5 site. If so, then you just need to give the communication process more time to get those keys transferred and processed locally. If it's not happening after a period of time, you may have to use the Preinst utility to dump the keys out of the parent site, replicate them down manually, and add them into your site hierarchy.

This is very important that you understand this, at least to the point of not enabling the check box until you're ready to do so; otherwise you will have some issues with your site-to-site communications with down-level sites.

Another cool feature of SP5 is the ability to maintain SMS logon points without an SMS account being made as an admin on the domain controllers (slide 14). This was an area that many people didn't like, is the fact that in SP4 and earlier, we required administrative rights to configure and maintain the logon point. That was either the SMS Service account or the SMS Site System Connection account. They had to be made by the local administrator on the DCs. As you know, there isn't really such a thing as a local administrator on a DC. Once you're a local admin, you're basically a domain admin, because you have full rights to everything in the domain. A lot of people didn't like that.

SP5 now introduces the ability for you to use a domain user as the SMS Service account or SMS Site System Connection account and still maintain your logon points. The SMS Service account and/or the SMS Site System Connection account still need to be administrator of the local computer, so the SMS Service account still has to be a local admin, because you're still running the SMS Executive and other SMS services, so it needs to be a local admin.

The scenario would be, you've installed SMS site server on a member server, and you want to set up logon points. The member server, the SMS Service account, needs to be a local admin. However, in the domain, going to your domain controllers, it doesn't have to be an admin anymore; it can be just a user account. You can still successfully maintain your logon points.

This is enabled by a configuration of a registry key. I have the path for you on the slide, HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\Components\SMS_NT_Logon_
Server_Manager\Domains\Your Specific Domain Name, and then you set the Security Mode Enabled key, and you set it to a value of 1. When you set that registry key to a value of 1, then what you're doing is enabling a security mode of not requiring admin rights. That allows you to use the SMS Service account as a domain user to maintain your logon points.

However, this requires manual intervention by you, the administrator, to configure this operation (slide 15). We still have to have things done on the logon point that require administrative rights. That's going to mean you're going to have to go out there and do some manual intervention with the domain controllers to configure them properly, so SMS can complete the work as a domain user.

You're going to have to manually create the SMSLOGON share with the appropriate comment on the domain controllers. You're going to have to manually configure the NTFS rights on the SMSLOGON share and all the structures, so all the folders down there, you're going to have set the NTFS rights, and we'll have that documented for you, what you need to set those to. If you want to use logon scripts, you're going to have to manually update the Netlogon share with the appropriate user script files as well as the SMS files, like Slownet, Smsboot1, and a couple other utilities. We'll document what files you have to place in your Netlogon share. You're basically going to have to set up the share, set up the rights, pre-stage the Netlogon share with the utilities and logon script necessary, and then allow SMS to do its work of populating the rest of the SMS logon folders.

You can also control the number of SMS NT Logon Server Manager status messages. By default, we're going to limit the number of status messages to 100. Then, we're going to stop sending messages regarding the fact that, "Hey, we don't have admin rights on the domain controllers to do any work." You're going to understand that, obviously, because you're setting the security mode. The security mode is allowing you to get by without that, but we are going to generate some status messages. You can go in there and configure a registry key to limit the number of status messages from NT Logon Server Manager or to disable status messages entirely from SMS NT Logon Server Manager, because you know the fact that, "Hey, I'm running in this scenario, I don't have admin rights, I understand that," so you can specify that if you wish to.

You can now allow your SMS Service account to be a non-admin on your domain controllers, but it requires you to go in there and do some manual intervention to pre-stage your domain controllers with specific information, so that we can go out there and maintain your environment. This also means that you can't use Logon Discovery, because Logon Discovery requires the installation of a service, the SMS NT Logon Discovery Agent service, which has to be done by an admin. You can't pre-stage that yourself, it's done through SMS, so your SMS Service account or your SMS Site System Connection account would have to be an admin to get that service installed.

A few more updates, a couple of slides on software distribution slow link detection (slide 16). This is an area of the product that had issues in previous versions, in regards to slow link detection, not only as what the local LAN has been configured but primarily in the area of advertisements.

In your advertisements, there's an option you can set that says, Assignments are not mandatory over slow links. There's a site control file edit you can generate to specify what your definition of a slow link is. It defaults to 40 kilobits per second (Kbps) if I remember correctly. That slow link detection is still there, we still use that value to determine what a slow link is or to define what a slow link is, but what we're changing now in SP5 is the method we use to calculate the link speed between the client and the distribution point.

What we're doing now is, we've got a new piece of code that we're using, a new API call, that's being called to do this verification. The slow link detection for software distribution implements a new file copy test procedure that's going to hopefully more accurately detect your network link speed.

What happens is when you upgrade to Service Pack 5, a dummy file is copied to your site server. Then, when you enable the slow link detection, which is not enabled by default, you have to enable it, but when you do enable the slow link detection, then what we do is copy this file to your distribution points. Then, when a client connects up to your distribution point to see what advertisements are available, if they find the Assignments are not mandatory over slow links check box is enabled, it will perform a test of that link speed by copying this dummy file across the wire and calculating the speed through the transfer of that file and to use that value to determine whether or not it thinks this is a slow link or a high-speed link. You configure this through a registry update that I'll talk about on the next slide.

The dummy file is called Netspeed.dat. If you enable the slow link detection testing, it is copied to your distribution points. By default, this file is 3,400 bytes in size, which is an okay size to use in environments where you're using slower links. However, if you're using higher speed links, it would be very beneficial for you to increase the size of that file. It doesn't matter what the file contents are. It's basically create a file with the appropriate size that you feel is valid for doing your testing, and then name it Netspeed.dat, put in on the site server, so it can then be copied over to the distribution points. The file goes in the SMS\Bin\i386 directory on your site server. From there, we will take care of copying it to the distribution points, provided that you've got the registry keys configured properly.

Some of the things I've seen say that the 3,400 bytes, the default file size, is okay for the slower links, but if you really want to test something, let's say a 512 Kbps link, then you might want to set a 50 KB file. Create a 50 KB Netspeed.dat file, put it on the site server, and that will give a better and more valid testing of your link speed on those little bit faster links.

Your file size can actually range up to 4 gigabytes (GB) in size. If you have a 100 Mbps Ethernet or fiber optic something, you may want to use a much larger file size. The larger the file size on faster networks, the better throughput testing you'll have so the more accurate results you'll get.

How you implement this is, we still use the Slow Network Threshold Speed registry value to define what a slow link is (slide 17). Again, that defaults to 40 Kbps. When you've implemented these two registry keys, and I have them at the very bottom of this slide, just the names, but the full path to this registry key to implement is HKEY_LOCAL_MACHINE\Software\Microsoft
\SMS\Components\SMS Distribution Manager and then the two keys listed on the last bullet, Slow Link Support Enabled and Slow Link Test File Enabled. You would set both those values to 1. Then, the next time you restart the Executive, we'll copy the Netspeed.dat file, whatever file size it is, over your distribution points, and we'll utilize it for the client testing. Then, the next time your clients test, they'll detect that the link speed testing is enabled, they'll copy the file down, and do their calculation of what the link speed is.

The client, when it copies this file from the distribution point, it actually documents the results in the new Smsapm32.log file. Now, I say "new," that log file has been around for a long time. It's new in that we've made some changes to it that we'll talk about on I think it's the next slide. Basically, we've made it less verbose. We've taken out a lot of the information that was in that log file to make it easier to troubleshoot. Because of the fact that that file would wrap around so quickly, you might actually lose valid data, because your default maximum log file size on clients is only 100 KB, and it was very easy to reach that 100 KB in environments, and you would lose good, valid data. We've taken out some of the verbosity of that log file, but we do document the slow link test speed for you.

This new implementation is going to fix the problems that you guys have seen where you've designated your advertisements, you're not mandatory over slow links, and they still run, as well as sometimes your local LAN speed determination was not exactly determined properly, and that would prevent advertisements from executing when you really were on a LAN, but we detected them as slow links, and the advertisements weren't running. Those are the two big things we're going to fix for you with this update.

Again, we talked about the two registry values. Now, an interesting thing you can do here is that you can place this file, if you want to, in the individual package folders on your distribution points instead of on the distribution point share itself. What the client will do when it connects up to the distribution point, it will start at the package folder and then work its way out to the root folder for the distribution point looking for the Netspeed.dat file.

What that means is that you can use a different file size for different packages. A big package, like Microsoft Office, you might want to have a larger test file size than a smaller package that might just be a real quick virus update, because you want to make sure that you're testing more appropriately for the big package, Microsoft Office, that might be hundreds of megabytes in size, where your not as concerned for a smaller update, like a virus scanner, that might be a few kilobytes, a couple hundred kilobytes, maybe a megabyte in size. You can actually put different files of different sizes in your different folders to control the access and the speeds for each of those tests for those packages.

A few final, miscellaneous updates (slide 18), and then we'll talk about implementation of SP5.

One cool thing is that the SMS Client Connection Account is now a local account. In previous versions of SMS, the SMS Client Connection Account, which defaults to SMSClient_your site code, was a domain account. That was okay if you had a small site hierarchy in your domain. However, in those environments where you might have multiple SMS sites in a single domain, each site would, by default, have its own SMS Client Connection Account, so you might have 100 SMSClient_individual site code accounts in your domain. Obviously, each time you have an account in your domain, that's going to require replication out to all your domain controllers.

By making this now a local account instead of a domain account, it reduces the number of accounts in your domain. This is one of those areas we had talked about earlier about reducing the domain replication traffic, because this is no longer a domain account, it's now a local account. It just reduces the number of accounts in your domain that have to be managed in the domain environment, which is very good for just plain administration as well as replication.

APM now accepts polling interval changes. There was an issue previously where if you went in and set your APM interval, in the Admin console, for your client settings (the site settings on the client agent), that you set it there, but you couldn't set it locally. Sometimes there were issues where it might not even reset if you changed it at the site-setting level. There were some issues with that, but that has now been fixed in SP5, so that you now can effectively manage that setting, site-wide setting or local client agent setting.

As I mentioned in the previous slide, Smsapm32.log is now less verbose, which means it's easier for you to find important troubleshooting information. We've taken out a lot of the extraneous information from that log file, just giving you the good important information, so that you can now more effectively find what you need and not have to worry about your log rolling over as quickly as it did before, because we used to reach the max size way too quickly. It's likely that you might have even lost your data in the rollover log file, because it logged too much.

Now that we've discussed SP5 in some of its details, what are the considerations for upgrading to Service Pack 5 (slide 19)?

As a general rule, you want to upgrade with typical service pack fashion and procedures. In other words, we recommend that you upgrade from the top-down. As per usual, and there's a white paper up on our Web site about deploying SMS service packs, you would follow that white paper, and that is, start at your top level site and work your way down.

Usually, you want to look at making sure your senior site is, if not the first, one of the very first sites to upgrade, otherwise you're not manually designating your senior site, then you'll have senior sites being swapped around as you upgrade individual sites.

Each SMS site system in your site will be upgraded automatically when you upgrade to SP5.

Each SMS client will be upgraded the next time it accesses the CAP for a CCIM maintenance cycle. Whether that's the next time they stop and start the SMS Client service, whether that's the next time they reboot the computer, whether that's the next time they go to the Sites tab of the Systems Management Control Panel program and click Update Configuration, or the next 23 hours, it will happen automatically, they'll upgrade the client. It will upgrade to Service Pack 5.

For a fully functioning client, which is all the client agents enabled, Hardware Inventory, Software Inventory, Software Distribution or Advertised Programs Client Agent, Remote Tools, Client Agent, Software Metering Client Agent, Event NT Trap Translator Agent; it's about 6 MB of network traffic to upgrade the client from whatever the current service pack is up to Service Pack 5. Now, that is unless they have disabled client upgrades. There's a utility called CliUpgrade, where you can disable client upgrades, so if you disable client upgrades, then obviously we won't upgrade the clients.

You want to plan for interoperability with down-level SMS sites. Signing is automatically enabled, but if you enable the check box which says, "Do not communicate or allow communications to unsigned sites running SP4 and earlier," then you won't effectively be able to communicate with your down-level sites. You actually can communicate down, but they can't communicate up, because you'll be looking for only signed data.

It is important for you to look at the 811378 hotfix for client installations to work successfully. There was an issue with logon point updates and which version was actually controlling the logon point, so some of the down-level sites had issues with that, so you want to make sure that hotfix has been applied to your down-level sites, so that they don't overwrite the SP5 logon point information.

A note for you is that when you upgrade to SP5, the Network Monitor Control Tool is removed from the SMS Admin console. You still have Network Monitor, Network Monitor is not going away, but the actual Network Monitor Control Tool, the one that you use to set events that you want to look for, like rogue DHCP servers or Internet break-ins and so on, that monitor tool has been removed from the Admin console, because the Network Monitor group no longer supports that tool. It's an unsupported tool now, so we removed it from the Admin console, so you're not in an unsupported scenario.

As a recap (slide 20), and then we'll kick it over to Otto for Q&A, SP5 provides many new features and functions to SMS 2.0. Again, that's why we wanted to have a session on it, so you guys were aware of some of the things, specifically and very importantly, the intersite communications issue. We provide better interoperability with Windows Server 2003. We provide better interoperability with SMS 2003. We provide better security in some different scenarios and better slow link detection for software distribution. There are also rollups of QFEs in Service Pack 4. It's very easy to install off the normal service packs, you just run Upgrade. You just run SMSetup on the SP5 code, and you'll be able to do your normal upgrade. Do a top-down approach, as a general rule. You need to make sure that you do understand though the interoperability with down-level sites when you've got signing enabled and communications enabled and restricted. You're automatically doing signing, but if you select the check box in your Site Communications tab of the Site Properties dialog box, you will be restricting your ability to effectively communicate with your SP4 and earlier down-level sites.

As a final thing to say before we kick it over to Otto, I mentioned that the product went to beta last Wednesday. It is in beta format now. The code is available up on BetaPlace. I don't know how big the download is. The CD image that I got when I was preparing for this WebCast was 370 MB. I don't know if it's going to be one-third that size or what, but it's going to be probably around 100 MB or so to download from BetaPlace.

Everyone who was accepted into the SMS 2003 beta program is automatically accepted into the SP5 beta program. If you have a beta ID for SMS 2003, you can use that same beta ID to go to BetaPlace and download the SP5 beta. It got posted yesterday, so the code should be on BetaPlace now. I asked and the Program Manager who was in charge said it was posted yesterday, so it should be there for you.

If you were a not an SMS 2003 beta participant and you do want to test SMS 2.0 Service Pack 5, you would nominate yourself, just like you would have for SMS 2003. You would go to BetaPlace. You would sign in. You would use the guest account as SMSInvite. Then on the next page, click on SMS 2003 Beta Program, click the Eligibility Survey, and then within two weeks, you should get a notification that you were accepted into the program. You only need to nominate yourself again if you're not already an SMS 2003 beta participant. If you are, you're already accepted into the SP5 program. You can use your SMS 2003 sign in to go up to BetaPlace and download the SP5 bits that were posted yesterday. At that, I'm going to kick it over to Otto, and he's going to kick off our Q&A session.

Otto Cate: Thank you very much, Wally. Before we jump into the Q&A here today, I'd like to share a couple of quick program notes with our listeners. If any of the details on the PowerPoint® slides were difficult to view in your browser or you'd like to have a copy of the slides, feel free to download them from the Web site. They are available on support.microsoft.com/webcasts, and you simply click on today's WebCast. This WebCast is under the Systems Management section in the Past Support WebCasts. The on-demand streaming media is also available there. All that content is going to be available on that page.

We have quite a number of questions that have already come in, so there is a chance I might need to, at some point here pretty soon, cut off any more incoming questions, but I'll certainly let you guys know.

One-on-one product support issues are outside the scope of what we're able to address during this live broadcast. The Q&A portion is really intended to encourage further discussion of the exact topic at hand as well. If you do need some more technical assistance, feel free to submit an incident on the Web or contact Product Support Services directly and speak to a Support Professional.

Let's get into the first couple of questions here: Does this release of SP5 effect or potentially affect the release date of version 2003 that's upcoming?

Wally: No. There is a different team of developers and testers that are working on the service packs as opposed to the SMS 2003 product, so no. This has absolutely no effect on SMS 2003 release. We're still on the same target we were on when we talked last month or I guess it was earlier this month. Whenever the last WebCast was we had, I talked about the 2003 beta program, so that hasn't changed.

Otto: There are a few questions here in regards to the improvements in interoperability with version 2003: Will an upgrade path from SP5 to 2003 be available? I know that you had mentioned some upgrade options.

Wally: Even SP4 is upgradeable to SMS 2003, so some of the tests we did in some of our EAP sites, we did do upgrading of their SMS 2.0 site directly to SMS 2003, and that was supported as of SP4. Nothing here makes it really change there. This is more, not upgrade, but more interoperability, but we do have upgrade, that is already in the product, the ability of upgrading from SP4 up to SMS 2003, so that is there, and that plan does not change.

Otto: We have numerous SMS sites whose users log on to the same domain. When we upgraded from SP3 to SP4, we experienced some issues installing new clients at SP3 sites, a down-level version detected. Unfortunately, we don't have the luxury of upgrading all of the SMS sites within the same week. Will we potentially run into the same problem when upgrading from SP4 to SP5?

Wally: I thought there was a hotfix that took care of that problem with the down-level sites from previous releases, but I think it was on my upgrading slide, there was a hotfix, 811378, because we changed our numbers, so the upgrading slide (19), the next to last bullet, "Install the 811378 hotfix" to your down-level sites. That will allow you to install new clients at your down-level sites, even when your other sites have been upgraded to SP5. That should take care of that issue for you.

Otto: Based on the number of questions that we already have received, I'm going to need to cut off any more incoming questions at this time. We certainly appreciate the active Q&A, and we'll certainly try to get to as many of these as we possibly can.

Moving on to the next question: Generally, do you know about how soon, after the release of SP5, that the SP5 versions for the International Client Packs might be available?

Wally: Those range for the different ICPs. Actually up on BetaPlace right now, we have ICP1, so International Client Pack 1 is already up on BetaPlace, as well as the English, Japanese, and German versions of SP5. ICP1, I think we're targeting zero delta there, so it should be available right about the same time, and then some of the other ones, like ICP5, may be a couple of months out. I don't know what the schedule is for the rest of them, but I'm pretty sure ICP1 is a zero delta, so we're trying to get it out the same day we release the full code.

Otto: We have several questions wondering whether we can install new sites directly to SP5, or if it's a situation where we need to go through previous service packs beforehand.

Wally: Unless something changes that I've not heard, we're not going to slipstream, you'll need to install a base version and then upgrade from SP2 up to SP5. You can create new secondary sites directly from the Admin console at SP5, and I believe also maybe the CD as well, you can create new secondary sites, but primary sites, you would have to install as an SP2 site with our CD and then upgrade to SP5 from there. I have not heard of any plans on slipstreaming.

Otto: As a best practice, should we consider updating to Server 2003 before activating SP5, or can we install SP5 on a Server 2000 system?

Wally: If you saw some of the interoperability stuff we talked about in the section on Windows Server 2003 interoperability, basically my statement was, "We didn't have a lot of support for Windows Server 2003 in SP4 without some specific hotfixes." I would definitely upgrade to SP5 and then upgrade to Windows Server 2003, because you need SP5 to get the support for Windows Server 2003.

Otto: Does the SMS provider support FQDN with SP5 for Windows 2000 as well?

Wally: Windows 2000 doesn't give us the FQDN from WMI. It was only in Windows Server 2003 that WMI does that, so we don't have an issue on Windows 2000. You're probably just thinking of straight FQDNs, and you're trying to get rid of NetBIOS or something and use just DNS, and that's not the case. This was specifically that the WMI code in Windows Server 2003 returned back FQDNs, which the SMS provider did not support. That was not the case with Windows 2000, so it's not an issue there. I think you're trying to go elsewhere and that wasn't what we were talking about.

Otto: I'm not sure if you addressed this during the presentation, but the question is: In SP4, the queries are loaded very slowly. We're wondering if that performance has increased in SP5.

Wally: When I was doing my research for this presentation, I didn't see anything that really talked about giving you better performance, speeding things up in SP5. There were a couple of things, but I never saw anything related to SMS Admin console interoperability and that, and I've not heard that as an SP5 feature. SMS 2003, absolutely, but I've not heard that anywhere in SMS 2.0, so to the best of my knowledge, no, the query performance, nor any of the other performance areas does not improve with SMS 2.0 SP5.

Otto: Does SP5 support clustering of servers?

Wally: SP5 does not add any additional clustering support from what we already had as of SP3. There's a white paper up on our Web site, microsoft.com/smserver. I assume it's under, I don't know if it's Planning or Deployment, but there's a white paper up there on SMS 2.0 clustering support, and SP5 has not changed that is all that I've heard. There are a few cases, like distribution points you could do, but not very much at all for clustering in SMS 2.0.

Follow-up answer: The "Microsoft Windows 2000 Server Clustering Interoperability with SMS" white paper is available for download on the System Management Server Web site at http://www.microsoft.com/smserver/techinfo/administration/20/integrating/clusterinterop.asp.

Otto: In version SP4, there were some SMS-related resource kit tools that were broken. Do you know if those have been fixed in SP5? It's not very specific here.

Wally: I think I know what he's talking about. There were a couple of the utilities we had in the resource kit, like MakeDP, MakeCall, and so on, that broke as of SP4. I honestly don't know if those have been updated. I have not heard any update on those. I think it would be a different group that would be working on that, but I have not heard any updates on those utilities. That was posted up on the newsgroup a long time ago about fixes, and last time I checked on it, they were in the works, but I had heard nothing about any update on them, and I didn't think to check, so to my knowledge, no, there's not been any update on those specific for SP5. It would just be normal working with those utilities, but I've not seen any updates for them for SP5.

Otto: What's the maximum number of clients per SMS Server for license metering in SP5?

Wally: Software metering doesn't change at all, unless there were some basic bug fixes, so the software metering product has not changed, for the most part. I can't give you a maximum number, because it depends on your hardware and other configuration, whether you're in online mode, offline mode, and so on. There was a white paper, at one point in time, up on our Web site that talked about software metering scalability, and the numbers, honestly, weren't great. That's why we're totally rewriting the software metering code for SMS 2003, to make it something that really does scale, gives you some good performance and does what you need it to do, without having to have a lot of servers to support that infrastructure. I can't give you a maximum number for all situations, unless there's something hard-coded, and there is not a hard-code limit on it. So it really depends on how you use that feature, how many clients you have, how many servers you have, what type of servers you have, what your infrastructure is, online, offline, and a lot of different issues, but SP5 doesn't change that functionality.

Otto: Will SP5 require a reboot?

Wally: No, it does not.

Otto: I have an SP4 site running NT 4.0 server n SQL 7.0 and will most likely update to aSdP5. We're curious if there are any significant issues we'll have upgrading the site server to either Windows 2000 Server or Windows 2003 Server.

Wally: There were some Knowledge Base articles specifically regarding upgrade of NT 4.0 to Windows 2000 and some compatibility issues, like a pre-Windows 2000 compatibility group issue and an SMS Admin console issue. Go to the Knowledge Base and search on "Upgrade to Windows 2000," and there were three or four different Knowledge Base articles. I actually pointed them out in a previous WebCast that we had probably two years ago. I'm trying to think what the title was. I don't remember if I did a WebCast specifically on SMS 2.0 and Windows 2000, it may have been, back when we did the SP2 WebCast, so maybe two or three years ago now, but I know I did a WebCast, and I had a slide in there on a few different issues with Windows 2000 systems.

I remember one being the pre-Windows 2000 compatibility group, that there was an issue when you upgraded that it didn't include everyone in there and that it should. There was another issue with the Admin console, like if your site server was NT 4.0 and your Admin console was on Windows 2000, the DCOM was set differently between named pipes and TCP or whatever it was, and that caused an issue. There are definitely a couple of issues to be aware of, but they are documented in Knowledge Base articles. I would search there.

As far as Windows Server 2003, you'd have to look, and I don't know if Windows Server 2003 supports SQL 7.0 any more. I don't know. I'm not saying it doesn't, I just don't know, because SQL 7.0 has been out for quite awhile now, so you may need to go to SQL 2000 before you can upgrade to Windows Server 2003. That would be something to look at, I honestly don't know. It might just be 6.5 they don't support any more, but you'd have to check that out before you went there.

Otto: I guess this is a clarification: Will SP5 be a prerequisite for SMS 2003?

Wally: No. SP4 is the prerequisite to go to SMS 2003. We would recommend going to SP5, because then you have the site-to-site intersite transfers so that you could use signed communications to have better security there and a couple of other things on that slide. But SP4 is the requirement, and we don't have plans on making SP5 the requirement, that I've heard of, or anything else to provide better interoperability. We've got what we need, as far as we know, right now.

Otto: Does SP5 include changes made in the SP4 hotfix rollup package? Are there issues created after installing the HRP with Windows 9x operating systems? Is that issue resolved as well in SP5?

Wally: I don't have a list of everything that's in SP5, so I can't tell you if they've included all the HRP stuff. However, as a general rule, service packs are rollups of the hotfixes. Since the HRP was a hotfix rollup package post SP4, you would assume that the hotfix rollup package is included in SP5, but I don't have a list of everything single thing that they fixed in there to know that, and that wasn't something that the people that were working on the SP5 gave me and said, "Make sure your people know this." They just said, "It's a general rollup of QFEs, as we normally do." So I'm assuming that the HRP code is there, which would mean that any issues it had with 9x clients in the HRP would be solved in the SP5 code.

Otto: What's the mechanism used by SMS 2.0 SP5 and SMS 2003 for signing site-to-site transfers or communication?

Wally: If you're asking for the algorithm that's used and stuff, I can't tell you that. I don't know what it is, but we do sign all communications between the two with private keys and public keys. The keys are transferred in the instruction file to be evaluated, and they're validated by the despooler on the receiving site with data from the site control file that's stored from the other site. We know that when we attach our sites, we transfer each other's keys to the other side, and we use that information, with what's in the instruction file, to validate that this is proper data that's been signed properly. Then, we can un-sign that data and do the proper validation and processing of the instruction file, so the despooler can do it's work, but as far as what the algorithm is, I have no idea what it is.

Otto: What service pack of SQL would you suggest we use with SP5?

Wally: There are no specific SQL requirements as far as running SMS 2.0 SP5. It's the same SQL Server versions as we've supported in SMS 2.0, so it's 6.5 we still support, as well as 7.0, as well as SQL 2000. It's whatever your SQL Server is that you want. Obviously, we recommend you move up to the latest version of the appropriate utilities that you have, in this case SQL 2000, which would be SP3, the latest service pack there, because then you have the latest code, you have updates for security, you have fixes in there and so on. That would be the general recommendation, but there's not any requirement to go beyond what you already have, so whether it's SQL 6.5 SP4 or above, somewhere in there, whether it's SQL 7.0, there is no requirement for any SPs there, or SQL 2000.

Otto: Will the ability to "rush" an advertisement be available in SP5 at all, or do we have to wait until 2003? Do you happen to know?

Wally: I'm not aware of an advertisement rushing facility in SMS 2003 at all. You can schedule advertisements for specific dates and times. You can say "As soon as possible," but I can't think of any facility in SMS 2003 to make it work any faster than it already does, unless you mean there is a pre-release version of a value pack utility from the Admin console to force clients to check for new advertisements, but I'm not aware of anything else. If you have a follow-up on that you want to send in to give me more clarification, that's fine, but I'm not aware of any rushing capabilities even in SMS 2003.

Otto: Do you know if there is any documentation available on network communication improvements?

Wally: As of right now, there is no documentation on SP5, even when you download the beta code from BetaPlace. It still has SP4 Release Notes. There aren't any SP5 Release Notes yet. From what I've seen, whether that's good or bad, what you saw here today is all of the public information that's available for SP5. There will be release notes in the RTM version of SP5, and I'm sure they will outline the network communication improvements as well as all the other improvements in the SP5 in those release notes, but I have not seen anything else that's publicly available at all.

Otto: Currently, we use the same advertisements and just modify only the schedule and available time to push a new version of the package. With changes in SP5, will this no longer work if clients already have run that advertisement?

Wally: That shouldn't make any difference, because all that's changing with SP5 is how the client looks and how it retrieves advertisements off your client access point, as well as how it detects what the slow link detection is. It shouldn't make any change to how the clients interact with an advertisement or how the clients process an advertisement, unless now that the slow link detection is now fixed, where before it wasn't working and advertisements ran when they shouldn't have before. Other than that, there should be no change that I'm aware of as far as the timing and processing of advertisements.

Otto: Will the current SMS value pack components function seamlessly with SP5?

Wally: We know of no incompatibility issues at all with the feature packs and SMS 2.0 SP5, so we're expecting them to work fine.

Otto: I'm not sure exactly which slide we were on when this question came in, but the question is: Is one of the security enhancements going to be a Deny Access addition, so that users or groups of users can be denied access to specific collections etc.?

Wally: We had a slide where we talked about security stuff, and it was on slide 10. I can tell you here really quickly, but no, we've not added in that level of functionality into the Admin console to give you a Deny function. The security rights assignment processing has not changed at all in SP5. To my knowledge, I don't have an SMS 2003 site with me, just my 2.0 SP5 site. I don't recall a Deny option in security right assignments in SMS 2003 either. I'll take that back and write that down as something that we want to look at, but I have not heard of that being something that's being implemented at all.

Otto: I believe we were quite possibly on this same slide when this question came in, and that's simply: The user's account would be locked out?

Wally: That was talking about the SMSCliToknAcct&. Not the logged on user account, but the SMSCliToknAcct& itself would get locked out in a number of different scenarios, and we've had fixes throughout the years in different service packs. SP5 is going to help tremendously in that area by changing the actual account name that's being used on non-domain controllers, but it would not be the logged on user account. It would be the actual internal account, the SMSCliToknAcct& that would have been locked out.

Otto: You had mentioned, during the presentation, some traffic reduction that's going to be available in SP5. We're wondering if this applies between site server and site systems, CAPs to DPs, over the WAN.

Wally: I can't think of anything in SP5 that's going to change your CAP interoperability or CAP access across the wire. For distribution points, nothing, that would be, again, SMS 2003 with the delta replication that's going to really help with your distribution point updates. Most of the stuff is really client-to-server communications. I can't think of anything in SP5 that's going to change the site server to site system communications aspect at all. No, I can't think of anything.

Otto: In a parent-to-child relationship that exists in the same domain, what is the behavior of the logon points when the parent is upgraded to SMS 2003, for instance, but not the child? Can logon points still exist, or do they have to be removed, or how does that affect the child SMS site that would still be on SMS 2.0?

Wally: That was something I talked about on slide number 8, when I talked about SMS 2003 interoperability, and that was the scenario I gave you at the very bottom. If you have two sites that are communicating in the parent-child relationship and they're sharing logon points and you want to upgrade the parent site to SMS 2003, you can do so. You have to disable logon points at the parent site, because we do not allow you to upgrade if you have logon points enabled, because we don't use logon points in SMS 2003, so they would be orphaned. You do have to disable logon points at your parent site or the site you're upgrading.

The issue we had prior to SP5 was that only the parent site, assuming the parent site was the senior site, but only the senior site was listed in a special file on the logon point that clients would look at to see what sites were available and what site version the logon point was. When that site that was referenced there was upgraded to SMS 2003, it was removed because of the fact that we don't use logon points anymore, so you removed it, and you didn't have another site listed, so clients could not install properly. With SP5, that's all been fixed. With SP5, you have your 2.0 site hierarchy. You then decommission your logon points for your parent site, leaving them intact for the child site, and then you upgrade your parent site to SMS 2003, and you should be able to install clients fine and not have any logon point issues.

Otto: How often is the SMSCliToknLocalAcct& password recycled? Does the SMSCliToknLocalAcct cycle passwords like the SMSCliSvcAcct does?

Wally: I want to say we don't change that password on the SMSCliToknAcct&. I want to say that password is not changed, but it may be one of those things that is changed automatically every time you start your service, it recycles your passwords. I don't recall. We can mark this as a follow-up, and I can go verify, but I want to say it doesn't get changed and it wasn't an issue, because of the fact that that account, which is a single local account, was never shared, and it's not supposed be across the network and so on, and it's not a standard user account like some of the other accounts are, but I'll have to verify because I don't remember off the top of my head. I want to say it's not updated at all.

Otto: You had mentioned a registry key for the SMSCliSvcAcct& password reset. Is that available in a KB article by any chance?

Wally: Not yet, because we don't have our KB article created yet for SP5, because they're still in beta mode. It will be, I'm sure, in the Release Notes. In the Release Notes, they'll have a reference to the KB article, so it will be there, but as of today, it's not because, talking to the PSS guys, they haven't created any KB articles for SP5, because it hasn't been released yet. As of today, my understanding is, it's not documented. It will be in the Release Notes, I'm sure, for SP5, which means PSS that will create a KB article appropriately for that.

Otto: Will SP5 change the format of site control CT0 or only add additional entries?

Wally: It doesn't change the format, no. As far as adding additional entries, I have not looked to see if there are additional entries added. Logically, there could be for some of this other stuff. Actually, most of the stuff that I can think of is all controlled through the registry, so there may not be. There probably are additional things, yes, for signing. There are additional things for signing, but as far as the format, no. The format of the site control file is not changing.

Otto: What's the recommended order of updating sites and enabling signed data transfer when there are parent-child relationships between them?

Wally: As normal, we recommend upgrading in a top-down fashion, so go from your central site on down through the hierarchy. Signing is going to happen automatically between SP5 sites. You do not want to enable the check box from the Site Properties dialog box, from slide 12 I believe it was, until you have your sites configured properly for all up to SP5.

Now, let's say you have your central site SP5, your child site SP5, the central site, you can turn on the check box, it only talks to SP5 sites. The second tier sites you would not want to set that until its child site or the central site's grandchild site became SP5, but you might have two sites that are SP5, then two sites below them are not SP5 in a hierarchy, and they could communicate with SP4 unsigned, but you would not want to change the check box on the Site Properties dialog box until all of your sites were SP5 enabled. Otherwise, you'll always have some site in there that's not SP5, and it will not be able to communicate with the SP5 sites.

So, top-down approach, but don't enable the check box until you do have all your sites up to SP5. Otherwise, you will have at least one site, maybe more, it depends on your hierarchy and so on, that can't communicate with other sites, any up-level sites, because of that check box.

Otto: This question is related: On the New Site Connection tab, if we check the "Do not accept unsigned data," will the despooler on the SP5 site generate warnings when it receives and deletes unsigned data from child SP4 sites?

Wally: My understanding is, no, it does not. My understanding is, no, you don't get a warning message or any kind of a status message saying, "Hey, I'm receiving data from an unsigned site that I'm not allowed to." It's purely because the despooler just throws that information away when it sees that it's unsigned. Now, on your child site, actually you wouldn't get error messages either, because of the fact that it successfully transferred the data up to the parent site, so no; you wouldn't get any messages at all. Your only indication would be the fact that you're not receiving updated information from your child site, that's going to be your only indication, so that's why we spent enough time on here, hopefully drilling it into your head, so that you don't want to select that check box, enable it, until you have all your sites appropriately and upgraded to SP5. I was told, when I was warned about this myself, that there was no status messaging regarding this.

Otto: Does the new slow link detection have a fail-safe timeout in case there's network saturation or the continued attempt to copy Netspeed.dat is contributing?

Wally: Not that I've heard of. What would happen is if you're trying to transfer the file, it's not going to calculate its network speed until it does transfer the file. If that doesn't work properly, then what would happen is that you just wouldn't run that advertisement this time. The next time your ODPs woke up and checked the advertisement, you would try it again in the next interval, so whatever your interval is would be the next time that you would try that. There may be a timeout built-in, but if so, it was not related to me in any of the information I was given or that I've seen on the new slow link detection process.

Otto: When upgrading to SP5, will we have to delete the old accounts that will no longer be needed manually, or will that be automatic?

Wally: There aren't any account differences in SP5 as far as accounts that are no longer needed, so all the same accounts are there. The only few changes in the accounts are the SMSCliToknAcct&, and it's going to remain in the domain, because it is still used by the domain controller, just implemented differently on the clients, but it's not in the domain. And then the SMS Client Connection Account goes from a domain account to a local account. If that's the account you're talking about, I honestly don't know if we delete that automatically.

Normally, we don't delete accounts automatically, because we don't know if you might have used them for some other purpose. This is because you can control, through a command-line switch or an .ini file, the name of the default SMS Client Connection Account. Because of the fact that you know the name and the password, if you're controlling it, then you may be using it for some other purpose. I would be surprised if we deleted it for the fact that you can control it, but that would be the only other account that's changing, besides the SMSCliToknAcct&, which is not going to change as far as whether you need the account or not. It would only be this account. My guess, it's not changing. I didn't set mine up on a member server. I had it on a DC, so it still became a domain account.

I can't think of any other accounts that you would be referencing or thinking that you would be able to delete, and I would think that we wouldn't delete it on our own, because you may be using it for some other purpose. Most likely, you would have to delete it on your own.

Otto: Regarding Netspeed.dat, the question is: How does adjusting the size of Netspeed.dat for each individual package equate to setting a different slow link threshold for each package, or does it simply detect the link speed more accurately?

Wally: Correct, the second one. It's going to give you a better analysis of your slow link detection. It's not going to change what your slow network speed threshold is. You're still going to be whatever the value is in the registry, 40 Kbps by default, but it would give you a more accurate picture of your transfer speed for that one specific package. For example, some very large package that might be hundreds of megabytes, you'd want to make sure that you had a better picture of your link speed, a more accurate result, so you'd use a larger Netspeed.dat file, so you're transferring a larger file, it takes longer, you get a better accurate reading than transferring the 3,400 byte file by default. It's purely giving you a more accurate determination of what your link speed is versus changing what your slow threshold is.

Otto: Is there an option to maintain the Client Connection Account on the domain controllers? For smaller sites wishing to rebuild, this makes a fairly easy transition.

Wally: Not to my knowledge. I'm not aware of any option for you to keep that in your domain, as opposed to making it a local account. I will write that down as a wish from someone to maintain the SMS Client Connection Account as a domain account, so an option for that and see if that's something that they've thought about doing or if it's something they're interested in doing, but I'll take that back to the developers and say that was a request and see what a response is on that. My guess is, it's going to be one way or the other, it's either a domain account like it is now, or in SP5, it's going to be a local account. I don't know that we have an option that let's you keep it one way or the other.

Otto: When upgrading, will I need to back up the usual files, for instance, Sms_def.mof?

Wally: Sure. When you do an upgrade, you always would want to back up, just in the event that things don't go how you expected them to go. Absolutely, we would always recommend that you would do a backup of your site. Use the Backup SMS Site Server task. Use that task, make sure you have a backup of your site to get you a snapshot of the registry, of your SMS database from SQL, your SMS file structure, back that up, move it off your site server, then do your upgrade. If things don't work, you can do your rollback from there, not rollback per se, but you manually do your downgrade back and reinstall, but yes, you would want to back up any files that you had made any modifications to.

In specific reference to the Sms_def.mof, I don't recall any changes to the Sms_def.mof specifically for SP5, but I honestly did not look, now that I think about it, because that was not something that was listed as something being changed. I didn't look, so I don't know that there are any changes, but you definitely would want to make a backup of your entire site server as a general rule.

Otto: Do you know, offhand, if query enumeration is fixed in SP5?

Wally: That sounds like one of the very first questions that we had on query speed, and to my knowledge, no, there has been no improvement in the SMS Admin console and its performance for enumerating resources, queries, collections, and so on.

Otto: After the entire hierarchy is upgraded to SP5, can we manually delete the domain\SMSclient_sitecode accounts from the domain?

Wally: Sure. This follows on with the question somebody asked earlier, if they could manually delete those or if they had to, to my knowledge, we don't delete those accounts. We would leave them, but again, I didn't test that out, because I was on a domain controller. Once you do, however, verify that your SMS Client Connection Account is now on your member server on the local site server in its local SAM, that it's there and it's referenced in your site settings under your site code, site settings, connection account, and client, once you verify that it is referenced there properly, then yes, you certainly could go to your domain controller and remove those excess accounts from your domains, verifying again that your site servers do have the local version present.

Again, the best thing to do is that you are manually creating your own SMS Client Connection Accounts. You should always do that and not just rely on the default one. If you rely on the default SMS Client Connection Account as your only Client Connection Account, then you're going to be in a scenario where you very likely could orphan your clients because of the fact that, if you ever reinstall with the same site code, new password is created, and your clients can't talk anymore. You always want to have your own for safekeeping and for use, but yes, once you've verified that the site is using the local version, you could certainly go out there and clean up your domain.

Otto: Do you know offhand, if the issue with file dates on files inventoried during software inventory being incorrect in SP4, do you know if that might be resolved in SP5?

Wally: I know it's an issue. I have not heard of it being fixed in SP5. I did not see that in the list of bugs that I saw that were fixed. I know it is fixed in SMS 2003, that's something that somebody asked me on, and I verified that. I'm trying to look at my site really quickly to see if I have taken software inventory, I don't recall. I don't recall whether or not that was something that's in SP5, so we can mark that as something to follow-up on, and it looks like I'll maybe a couple of other questions to answer as well after the WebCast, and I can check on that and verify.

Otto: I'm confused about site-to-site signed communications. Where do the digital certificates come from? Do they come from the Active Directory? Will there be some manual intervention needed to copy them from their originating point to some topmost point in SMS, after which the topmost site server will "auto-magically" transfer them to the rest of the needed areas?

Wally: SMS 2.0 does not understand Active Directory at all, so it uses an Active Directory environment as basically an NT 4.0 domain. That will not be an option for you at all in SMS 2.0. In SMS 2003, then yes, getting your signed data, your keys, from Active Directory is an option that you have. For SMS 2.0, the key transfer will happen automatically when your child site attaches to the parent site in a new attachment scenario, you'll automatically transfer your keys then.

When you upgrade your sites to SP5, we'll automatically push them around as necessary, but there is a manual utility that you can use called Preinst.exe. It's in your SP5 code. You can use Preinst.exe, and there are some command-line switches you can specify to have it dump out your keys for your local site, which you could then manually copy to your child site and place it in the Sms\Inboxes\Hman.box directory and then let Hierarchy Manager process that into the site control file of the local site.

That would be the two ways of getting your keys: let SMS take care of it itself when it gets around to pushing the keys around to the sites that need to have those keys, or you can manually stage them, if you want to, and you actually have to do that manual staging if you select that second check box on the Site Connection tab of the Site Properties dialog box that says, "Require secure key exchange". Then, you have to use the Preinst utility, dump out your keys in an appropriate file format, and then copy those to the child site or parent site as appropriate, Hman.box directory and let them get processed in. That would be something that you would have to do on your own at that point in time.

Otto: I heard that we would eventually be able to make an inventory of software that's only listed in the client's Add/Remove. Is that available in SP5 or is that going to be 2003?

Wally: You actually get that with the SMS features packs, either one of the feature packs, and then the Web Reporting utility. In the Web Reporting utility, from the SMS feature packs, has the Sms_def.mof extensions that you would need for adding in Add/Remove Programs Inventory. I know it's listed as software inventory, but it's done by hardware inventory itself.

I'm trying to look in my SP5 Sms_def.mof to see if it's there and if it already has it integrated by default. It probably isn't in there, and I don't see it in here, so it's not something that's added into the Sms_def.mof that I can see by default in SP5, but in the Web Reporting utility that comes with the feature packs, either one of those two feature packs, when you do the installation, a check box there asks you if you want to enable Add/Remove Program Inventory. You could use that to get a more accurate picture of your software inventory than you do with the standard software inventory utility.

In reference to the previous question, I'm looking at creation date on file in software inventory, and it looks to have the correct date and time. I don't have any collected files, however, and I don't remember if the problem was with collected files. I think it was just with collected files, now that I think about it, and if it is with collected files, then I don't have any collected files there to look at the modified date, but it looks like the creation date looks to be correct, from what I can see in software inventory for SP5.

Otto: With that, we've answered all the questions that we were able to get to in the time allowed. We certainly appreciate everyone coming out and listening to the broadcast. We definitely hope that this information was useful to you. I definitely also wanted to thank Wally for coming out and giving us a great presentation as always.

You can always send e-mail to us at supweb@microsoft.com if you have any suggestions for future topics, comments about the sessions, or even the WebCast program as a whole. Our overall goal has always been to ensure that we're providing you the right content in the best way possible, so that feedback is absolutely important to us, and we certainly appreciate it.

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