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

Heidi Moeller: Hello and welcome to the Microsoft Support WebCasts. We'd like to thank all of you for joining us today. Our topic will be "Windows^® 2000 and Systems Management Server 2.0 Integration," and our presenter will be Wally Mead. I'm Heidi Moeller and I'll be your host for today's session.

I'd like to take just a brief moment and introduce Wally. Wally joined Microsoft almost eight years ago in the training group. He now works for Product Support Services, developing and delivering training, focused on SMS 2.0, to all of our support professionals.

During his time at Microsoft, Wally has developed training materials for all versions of SMS. Thank you so much for joining us today, Wally.

Wally Mead: Thank you and good morning. Welcome. Hopefully, you'll find this session informative and useful.

Let's talk about what our session is going to cover. In this session I will start out first with what support SMS 2.0 has for Windows 2000. We'll look specifically the server support that SMS 2.0 will provide, and support for Active Directory™. We'll look at the support SMS 2.0 will provide for Windows 2000 clients. We'll talk specifically about what is not supported, because the support we currently offer will not cover all features of Windows 2000.

Then we'll branch off and we'll talk a little bit about positioning SMS 2.0 and Windows 2000. There are a lot of questions and misconceptions about what is available, and why use one product over the other one, so we'll talk a little about positioning the two products together.

Then we'll spend a moment talking about how you can deploy Windows 2000 using SMS, as well as Windows 2000 technologies. We'll finish up with a little bit on Windows 2000 support for SMS 1.2; what support we'll provide there, as well as when that will be available.

My biggest agenda item is not on this slide. And that is to clear up the misconception that SMS is dead. A lot of people have the misconception that now that Windows 2000 is available, SMS is a dead product, and it will no longer be worked on; that it's going to be discontinued very shortly.

So I want to talk about that, as well as the fact that SMS is not needed, if you have a Windows 2000 environment. That may be the case in some environments, but in a lot of environments, you may still need to have SMS 2.0, even if you're a Windows 2000 shop. We'll talk about that when we talk about positioning the two products.

Okay, so go to the first slide on SMS 2.0 server support (slide 3), the support we're going to offer in SMS 2.0. The support is coming in Service Pack 2. So SMS 2.0 Service Pack 2 is where we're providing our support for Windows 2000.

We're going to provide Windows 2000 Server support in native or mixed mode. So you can either run in a pure Windows 2000 environment, an Active Directory environment, or in a mixed-mode environment. So you can support Active Directory servers, as well as Windows NT^® 4.0 domain controllers. We'll support either one in Service Pack 2.

Specifically, for Windows 2000 Server support as an SMS site system, we're basically going to support all SMS site system roles running under Windows 2000. That will be: your site server can be a Windows 2000 server; your client access points can all be Windows 2000 servers; logon points; distribution points; software metering servers; and your SQL Server™ computer can be Windows 2000.

An additional note there is that in Service Pack 2, we will support SQL Server 2000, as well as our current supported platforms of SQL Server 6.5 and SQL Server 7.0. Our support will also include having the SMS Administrator console running on top of a Windows 2000 computer.

As you look at the slide, you can see we've got pretty well all the SMS site system roles covered for the Windows 2000 environment. So for the server support, we're looking pretty good.

If you go to the next slide, there are a couple other things about the server support: we do support Network Discovery. We're using a Windows 2000 DHCP server. There were some problems with some of the earlier code, like Service Pack 1 and so on, with using a DHCP server that was running on top of Windows 2000. We now do support a Windows 2000 DHCP server, and we support having Network Discovery enumerate resources from the DHCP server running on top of Windows 2000.

What it does require, however, is that your SMS Service account is a member of the DHCP Admins group that's created on your DHCP server running on top of the Windows 2000.

We also do support Terminal Server on Windows 2000. So we give Terminal Server support for Windows 2000. This does not include Terminal Server support for Windows NT 4.0. This is solely for Windows 2000. We support remote support mode, as well as application capability mode.

So with these, it should allow you to do Terminal Server support, and all your sessions for your clients, and there have been rumors of people being able to do Win 9x administration of SMS through the Terminal Server box. That may be a possibility, as well.

There's a note at the bottom we'll talk about further, as we get into a couple more slides. But the big point here is that if you're an existing SMS 2.0 shop on top of Windows NT 4.0, and you want to upgrade to Windows 2000, any SMS site systems that are installed on Windows NT 4.0 domain controllers that are going to be upgraded to Windows 2000 domain controllers — which means you're going to an Active Directory environment — currently the support statement is that you must install any of those SMS site systems. So if you're upgrading a Windows NT 4.0 domain controller to an Active Directory environment, then you must reinstall the SMS functions there, whether it's a site server, a logon point, a client access point, etc. We'll talk a bit about that more as we get further along.

On our next slide (slide 5), we'll talk about Active Directory support, what SMS will specifically support for Active Directory.

In the Service Pack 2 time frame, we'll support Active Directory for the creation and storage of the SMS user and group accounts. So as you know from previous WebCasts, there are a number of SMS accounts that are created. You can create these accounts and store them in Active Directory, so that's not an issue at all.

We do also support user and user group discovery. The Windows NT user account discovery and the Windows NT user group discovery methods that are available in your SMS 2.0 site settings — those two discovery methods do work to discover resources from an Active Directory.

However, we do not have support for computer discovery, so we have no discovery agent that will go into an Active Directory, find computers that have been created in the Active Directory, make DDRs for those resources, and add them to the SMS database.

We do not support restricted groups, or delegation of authority in Windows 2000. The SMS Service account is required to be a domain administrator in a Windows 2000 Active Directory environment. That's something we're working on: just like right now in Windows NT 4.0, you can make your SMS Service account a local administrator. It doesn't have to be a domain admin, once you've completed setup. And Windows 2000 is required to remain a domain administrator entirely.

Nested groups: we do support nested groups; however, we only enumerate the first level of the group. Any nested members are not enumerated. We'd enumerate the root-level members, but not any nested members of nested groups.

We also do not support group policy objects for software distribution. It's one of the things that IntelliMirror^® can use, and we'll discuss that later on when we position the two products. However, SMS 2.0 does not use group policies.

Another thing, that's not on your slide, that we don't support, or that we kind of support, is universal groups. SMS does support universal groups; however, only in the context of the site server domain. So any universal groups that are in the domain the site server is a member of can be enumerated, but not outside the site server's domain. Again, there's no nesting of groups. And these groups, the universal groups that are in the site server's domain, appear as global groups, as far as SMS and software distribution is concerned.

We will have further integration, as well as exploitation of the Active Directory, in later releases of SMS. I have nothing I can announce to you today; but there will be more support coming in the future.

Now let's turn our focus to SMS 2.0 client support (slide 6). What features of the SMS 2.0 client are going to be supported on Windows 2000 platforms?

Our SMS 2.0 Service Pack 2 support will provide full SMS 2.0 client support for all Windows 2000 platforms, those being Windows 2000 Professional, Server, and Advanced Server.

We currently do not support Windows 2000 DataCenter. It's not a released product yet, either. We do support Professional, Server, and Advanced Server.

I didn't mention on the server support — the server support does include Windows 2000 Server, as well as Windows 2000 Advanced Server.

We do not support clustering yet, so the Advanced Server support is currently available only if clustering is not enabled. We are working on that as well, and we'll have something coming up in the future for you. As of today, we're not supporting clustering.

Okay, so back to the SMS 2.0 client base. All of your SMS 2.0 client features are supported. There are a couple of areas where we have gotchas to be aware of. Currently, remote control works. However, we do not do accelerated video drivers for Windows 2000 clients. That's something we're working on very hard right now, and hopefully we'll have the support very, very soon. But as of today, we do not support accelerated video drivers for remote control.

The Windows 2000 Plug and Play driver model has changed enough that our accelerated drivers don't work anymore. We are currently rewriting all those drivers, and support will come very soon. But again, as of today, we do not support accelerated video drivers.

We also do not support MUI for the SMS 2.0 client. MUI is the MultiLanguage user interface, the ability to support multiple languages on a single desktop. We don't do that, because the SMS client is not Unicode. It's not Unicode based.

SMS 2.0 client support: we have limited Terminal Server support. We do support a Terminal Server client, as an SMS 2.0 client. However, what we support is hardware inventory, software inventory, and background software distribution. That means software distribution going to the system, and not a logged-on user account, specifically.

We also do not support logon script installation. So if a user were to log on to a Terminal Server box, and the user's profile were to kick off the Smsls.bat file, then the Smsls.bat file specifically looks for Terminal Server; and if it finds it, it closes. So you'd have to do either a manual installation, running Smsman.exe, or use the Windows NT remote client installation method to push the SMS client software installation down to that Terminal Server client.

Your clients can be members of Windows NT 4.0 domains. So you can keep your domain structure in Windows NT 4.0 and just have Windows 2000 Professional clients in the Windows NT 4.0 domain; that's fine. We also support the clients in an Active Directory environment; that's acceptable, as well as NDS. We support NDS environments for Windows 2000 clients and SMS 2.0 clients, as well. We also support upgrades of the client platforms from Windows^® 95, Windows^® 98, and Windows NT 4.0 into a Windows 2000 environment.

So we have pretty good client support as well. Generally, the biggest concern for people is the remote control accelerated video drivers. We're working on it, and again, we'll have something very soon for you; but as of today, we don't have that support.

Next, let's talk about what specifically is not supported (slide 7). The support story will change over time, but this is as of today.

As of today, we do not support an upgrade from SMS 2.0 on any Microsoft Windows NT 4.0 domain controller to SMS 2.0 with Windows 2000. I mentioned that before, and this means that any SMS server roles (site server, CAP, distribution point, logon point, etc.), any SMS site system roles that are on top of a Windows NT 4.0 domain controllers that you're upgrading to Windows 2000, as a domain controller — which means Active Directory — we do not support that upgrade. You would have to retract or remove that server role from that domain controller, upgrade to Windows 2000 in to your Active Directory, and then just reinstall or reapply, or redeploy that server role.

If you're doing a clean install (so if you're installing Windows 2000 going to an Active Directory environment), and you're installing SMS 2.0 Service Pack 2 on top of that, you have full support for installation of all the different site system platforms. It's purely just an upgrade from domain controllers to Windows 2000 domain controllers. For Windows NT 4.0 domain controllers to Windows 2000 domain controllers: currently the support is not there for an upgrade. We're working on it, and we hopefully will have it at Service Pack 2 release time; or if not, then soon after Service Pack 2 release time we'll have a stated direction on what is supported in an upgrade scenario. It's just that there are so many different scenarios and combinations and iterations to work through from Windows NT 4.0 up to Windows 2000 Active Directory. The test matrix for doing that is incredibly large. We don't want to come out with a statement that says we support only this one type of scenario. We're going to wait until we have multiple, different scenarios, so that we can come out and say we are supporting this.

This does not mean that if you go and do this upgrade on your own, that it will fail. Most people that we've talked to who have done this upgrade, and most of our test efforts, working on the upgrade process, have been successful. However, it's just not a supported scenario right now. We will have that migration support coming.

If you are on a Windows NT 4.0 member server — you're not a domain controller, but a member server — you are freely able to upgrade from the member server in Windows NT 4.0 to a member server on Windows 2000, without removing and adding any of the SMS server roles. It's just in the domain controller environment where we have this limitation right now; and again, that limitation will be going away at some point in the near future, but not today.

The other three things on your slide we've already discussed. We do not support Active Directory computer discovery, being able to discover any computers that have accounts created in the Active Directory. Nor do we support group policies for software distribution. Nor do we support accelerated video drivers for remote control. Again, that support should be coming very soon.

Now for the group policy objects for software distribution — I'll talk about this later on when we get into the positioning environment — there are a couple of tools that are available that do allow you to simulate exactly what a group policy object is doing for software distribution with IntelliMirror.

You can use ADSI (the Active Directory Services Interface) and the SMS SDK. With that you can actually create some tools to discover Active Directory OUs. And from that discovery, you can create collections in the SMS 2.0 database and mirror your Active Directory OUs in SMS, and target that for software distribution.

In fact, we have samples of some script utilities available using ADSI and the SMS 2.0 SDK on the Systems Management Server Web site. That would be on http://www.microsoft.com/smsmgmt/default.asp, and then go to Downloads. In the Downloads section, I believe it's the first choice, Active Directory/SMS Collection Synchronization Tools. Get that, and you'll see a possible way of performing Active Directory discovery, and creating software distribution from that.

As long as we're talking about that topic, let's move on to "Positioning Windows 2000 and SMS 2.0" (slide 8). In this next section, I want to talk quickly about the Windows 2000 management features. We'll touch specifically on IntelliMirror, and what the IntelliMirror features are. Then I want to talk about what advantages SMS 2.0 provides for software distribution over IntelliMirror. And then I'll discuss where to use each of these different features.

The Windows 2000 management features are first. Windows 2000 has a rich set of management features that all customers can benefit from. Anybody who wants to move to a Windows 2000 environment can benefit from any of these management features, and it does a very nice job.

The features we want to talk about are, first, software application deployment. Windows 2000 has the ability to deploy software out to desktops. That deployment can be out to users or computers; it's very similar to what SMS can do. And that's through a process called publishing or assigning applications. I'll touch on that in the next couple slides.

Windows 2000 also provides user data management, the ability to make user data available from anywhere on the network, so it's not stored just on my desktop on my computer. I can log on to another desktop someplace else, across the company, and still access my data files.

User settings management is the ability to control my desktop so that when I log on to someone else's computer, the desktop looks exactly as if I was logging on to my own computer, in my own office. It also maintains any restrictions I have. So if I'm not allowed to access a specific function on Windows 2000 from my desktop, I shouldn't be allowed to perform that same function elsewhere, on somebody else's desktop. That's user settings management.

Operating system deployment: Windows 2000 has the ability to deploy Windows 2000 Professional over the network to compliant systems. That's very nice if you have an environment where you want to maintain backup computers or replacement computers running Windows 2000 Professional. If somebody's desktop fails for whatever reason, such as hardware, you can just take a new computer, plug it into their CAP, turn it on, and Windows 2000 Professional is installed over the network automatically, without the user having to do anything.

Then they can use the IntelliMirror features that we'll talk about in the next couple slides. They can have all their applications automatically reinstalled for them . These are excellent capabilities to deploy operating systems and maintain your desktop environments.

As stated before, all customers can benefit from all these features. These features should be available to any customer, and these benefits can help secure your environment, help maintain consistency in your environments, help maintain and control your data access for users, and control what they can access in their environments.

Now let's talk about IntelliMirror features specifically, because that is the one area where SMS and Windows 2000 have a big overlap in functionality.

Software application deployment: the first thing we need to talk about and make sure everybody understands is what is software application deployment, or software distribution. Software distribution is generally considered to be composed of four steps. Those steps are, first, packaging; making the software available, or getting it prepared to be distributed or installed in client desktops.

Second is deployment to distribution points, or staging areas (taking this package you've created or combined and staging it on servers for available user access). So, staging the package on servers so that users can access it.

The third step in the phase is targeting. Targeting is figuring out whom you want to make the software available to.

And the fourth step is making the package available to all the members of your targets, from the distribution points or the stored servers, staging servers.

So, packaging, deploying to distribution points, targeting, and then making the packages available to your users. Those are the four key steps in software distribution. We'll want to refer to those steps as we go through this comparison between Windows 2000 and IntelliMirror software distribution, as well as SMS.

With IntelliMirror software application deployment, it can do either publishing or assigning of software. Publishing means you're making software available to users. So when "Wally" logs on to a system, he has a set of software that's available to Wally. And to install a piece of published software, I would go to Control Panel, Add/Remove Programs, and any of my published applications would be available there; and I can just choose to install any of those applications that I want to.

Assigning applications means you're making a program available to either a user account or a computer account, but it's a mandatory program. In other words, it has to be there. You can't remove this program, so it's a required application. You would normally see those programs in your Start menu.

So I log on to a computer for the first time, I go to Start, Programs, and I see any programs that are assigned to me, because they're required; they'll be in the Start menu, thus making software available.

Another thing that people talk about with IntelliMirror is automatic repair. Suppose I'm running an application and I try and launch some function — let's say it's printing, or let's say it accesses the online help system — and there's a DLL that's been corrupted, or somebody has accidentally deleted a file that was required.

IntelliMirror has the ability to automatically repair that application. So when you try to launch that function, if it's determined that the DLL is missing or that it's corrupted, IntelliMirror can go out there, find the source files, and recover that file or set of files to make that application process complete successfully. So it automatically repairs damaged applications.

Another feature that's very popular is called Just-In-Time or On-Demand applications. Let's say you see an assigned application that's in the Start menu. So I go to Start, Programs, and I see Microsoft Word. Yet Microsoft Word may not physically be installed on that computer yet. It may just be available in my Start menu.

When I click Microsoft Word for the first time, IntelliMirror will force the installation of that application; before I was not requiring it. So it puts the icon on the desktop, and because I'm now requiring the application, and I want to use it, it's going to install that application just in time. It's just in time for my usage, thus making the application available through one method. That's publishing or assigning, and how to use them for installing that application when the user really wants it.

Now the key thing for these software distribution processes is that if an application fails, and it can't be installed properly, you have the ability of rolling back that application. In other words, you can remove all traces of it. So it will look as if you never attempted to install it on the computer.

Those are all features of Windows Installer. Windows Installer is really the key to IntelliMirror software distribution.

Windows Installer is also available to non-Windows 2000 platforms. All of these features that people think about with IntelliMirror — being Just-In-Time applications, automatic repair, rollback, and so on — those are technically Windows Installer features. And if you have Windows Installer platforms available in your environment, you can have those same features available outside of Windows 2000. I'll talk about that more coming up.

User data management is also an IntelliMirror feature. You can have user data files stored in a centralized location synchronized for offline access. So you have backup of your data — it's synchronized through different environments. You have centralized storage and access. So at any desktop I went to, I'd be able to access data files that I created on my system.

You also have disk quotas, so you can state that the user Wally cannot use more than 50 MB of disk space. User data management will allow me to implement those quotas and restrict Wally from using any more than 50 MB of disk space in the environment.

We mentioned user settings management. User settings management are group policies, the ability to make multiple desktops look identical, no matter where a user logs on. So moving from one desktop to another one, when I'm logging on, my desktop screen and icons will look exactly the same, as if it were my desktop. Any restrictions placed on my user account from my normal computer would be implemented on any other computer I logged on to. Any preferences I had, as far as icons, screen savers, desktop wallpaper, and so on, flow through or are made available throughout the entire enterprise, for my user account.

Those are the big IntelliMirror features: software deployment, user data management, and user settings management.

Now if we go to the next slide (slide 11), we'll talk a little bit about SMS 2.0 in comparison with IntelliMirror.

I mentioned in the previous slide that Windows Installer is the key to IntelliMirror's application deployment features. If you install Windows Installer on non-Windows 2000 platforms (and Windows Installer is available for Windows 95, Windows 98, and Windows NT 4.0), then SMS software distribution can do the exact same things that IntelliMirror software distribution can do.

You can have Just-In-Time deployment. You can have automatic rollbacks. You can have automatic repair of damaged applications, because those are Windows Installer features, and not IntelliMirror features. IntelliMirror just happens to be distribution mechanism to push out Windows Installer packages, as SMS can do.

SMS does not have the other features of IntelliMirror, those being user data management and user settings management. Those are OS functions, and not the computer management functions that SMS provides.

Software distribution is the area where we do have an overlap. SMS can deploy Windows Installer packages, which gives you the auto-repair, the rollback, and the Just-In-Time installation. So it looks very much like IntelliMirror application software deployment.

It can do publishing and assigning. It does it in different ways. Publishing and assigning are the Windows 2000 or IntelliMirror terms for software distribution. In SMS 2.0, the term is advertising. You advertise packages, and programs from those packages, to users or to computers, based on collections. So we're just using a different targeting scheme, and a different terminology scheme. We're not doing group policies. We're using collections.

I was going to mention the Active Directory synchronization tools that were up on the Web site. You can download those tools to make your SMS collection environment look very much like your OU environment in the Active Directory.

SMS software distribution not only can do the same things that Windows Installer can do for IntelliMirror, but it also has many other advanced features.

As we look at the next slide (slide 12), we can see some of the advanced features that SMS software distribution can perform, and that IntelliMirror cannot perform.

First off, we have support for legacy clients. The SMS software distribution scheme not only supports Windows 2000 clients, as in IntelliMirror, but it also supports Windows NT 4.0, Windows NT 3.51, Windows 98, Windows 95, and even Windows for Workgroups and Windows 3.1. So we have excellent support for legacy clients. The IntelliMirror features require IntelliMirror-based clients, which are Windows 2000 clients.

Our targeting can be based on existing hardware and software inventory. So with the SMS software distribution scheme, your collections can be based on queries that are looking for specific hardware features, or specific software applications.

You can create and target your software deployments. Let's say you target all computers with 500 MB of free disk space, at least 128 MB of RAM, and at least a Pentium 366 processor or higher. So you're targeting your software distribution to only computers that can support the application.

We have the ability to do that, and you can target based on the ability to upgrade an application. You can deploy Office 2000 only to computers that have existing Office 97 installations. You would find out about existing Office 97 installations by performing a software inventory. Then you can create a query based on that to find all computers with Office 97 installed. And then you deploy Office 2000 upgrades to those computers. That's targeting based on hardware/software inventory.

SMS does not require the Active Directory. If you want to deploy Windows 2000, but you don't want to roll out the Active Directory yet (you don't want to distribute that or deploy that directory environment), you don't have to for SMS. If you want to use IntelliMirror, it does require the Active Directory.

We have very good intersite WAN support. All data that's between two SMS sites, including software distribution, is compressed. It will take your package files, compress them, and then send those over the link.

We also have the ability to schedule when SMS can send data between those two sites. You can state that I don't want SMS sending any packages from 9 A.M. to 6 P.M., during my business hours, because I want the entire link available for user access.

We also have bandwidth throttling. So whenever you do allow transmission between those two sites, you can designate that SMS cannot use any more than x percentage of your available bandwidth. In that case, SMS actually calculates your bandwidth based on how long it takes to send the package back and forth between the two sites. Then it will go to sleep in-between sends of data, to not chew up any more than x percent of your bandwidth; for example, 50 percent. So we have very good intersite WAN support.

Next is scheduled software deployments. With your advertisement scheme, you can schedule when you want that software to be made available to the client computer, or when you want it to be forced to be installed on the client computer.

With IntelliMirror software distribution, when you publish or assign an application going to a user, the user has to log out and log back on to make those programs available in the Start menu or the Control Panel Add/Remove Programs.

If you're going to assist them (so if you're assigning or publishing to a computer), then you have to restart the computer, because when you assign applications to computers, it's based on system start-up time. You have to restart the computer to update the Start menu for your assigned application to be available on the computer.

You don't have to do that with SMS. You may want that user to be logged out or logged on in specific states to install an application, but it's not required. Our agents will periodically look at the client access point for any advertisements that are available, and then display those that are available to the user; or they will start and force them to be installed, if it's the appropriate time for an assigned advertisement.

Next is advanced reporting and status. With the status system that's built into SMS 2.0, you can actually see the status of your software distribution. You can see where the package is, as far as its deployment, throughout the environment. With Windows 2000 and IntelliMirror, it's a share-based system, and it's predominately on a single server; so there's not much need for load balancing there.

Now, with Windows 2000, you can implement Dfs. You can use DFS for performing load balancing, redundancy, and fault tolerance for your shares, as far as where the application is available for user access. So that feature is available. However, status is not available, so you won't necessarily be able to tell what the status is of those application deployments, as far as staging on your different servers.

With the SMS package status system, you can see what sites have the package, what distribution points at each site have the package, and what source version or current version of the package they have.

With the advertisement status, you can see each advertisement it has created. You can see which sites the advertisement has been sent to. You can see how many computers, whether they're clients or users, have received or rejected the advertisement. Received means it's processed and it's available to the user. Rejected means it's the wrong platform, or the date and time have expired, or whatever the case may be. And you can see what recipients or what target recipients have received the advertisement and started the advertised program, as well as the exit code for the program. In other words, what the exit code of the program told SMS was the success ratio of that program. So you've got pretty good status.

You can get even more detailed status in the SMS 2.0 Service Pack 2 support bundle. On the CD, there's a Support.exe program for SMS 2.0, and we have a couple of the utilities that get you more details on the advertisement status.

In the Software Distribution Tools folder, there's an advertisement information tool. It's Advertview.exe on the CD. Not the full res kit, but the built-in one. It gives you more detail, as far as software distribution for your packages. So you might want to look at that, on the SMS 2.0 SP2 CD.

We also support Novell environments; we have support not only for Microsoft operating systems (and legacy ones, being Windows 95, Windows 98, and Windows for Workgroups, and so on), but also Novell clients. So if you have an environment that integrates Microsoft clients as well as Novell environments, we can support bindery clients as well as NDS clients.

On the next slide (slide 13), we'll talk about some other advantages that SMS 2.0 provides outside the software distribution scheme. These are things that Windows 2000 isn't necessarily able to perform. These are other reasons why you might want to have SMS, even though you have Windows 2000.

First is application software metering. We have the ability to meter or just monitor applications that are being used on your desktops. You may have deployed an application, but now you want to see who is using that application, or if users have installed and deployed applications that are not approved on your corporate software list.

You can use our software metering function to monitor what applications are being used by the desktop users, or meter licenses for those, if you have concurrent licensing applications.

Next is server Health Monitoring. HealthMon is built into SMS 2.0, and the HealthMon for 2.0 allows you to use specific Perf Mon counters and objects to view the status of either Windows NT or Windows 2000 computers. I can see when my memory is being utilized or my processes are being heavily utilized, or if I'm having security faults from logon validations, or if my page file is having errors, or if my disk is being filled up. I can proactively monitor those things with this HealthMon code for server Health Monitoring.

Because I can monitor those proactively, it may prevent errors from occurring and services from being shut down. In some cases, when the disk fills up, some services will shut down, and some applications may not be available.

If you're monitoring the HealthMon code, you'll be notified when the disk is being utilized, when the disk space is being filled up. You can proactively move other resources off, clean up the drive, do defragmentation, or whatever is necessary to prevent the application or the service from being shut down.

Next is end-user support utilities. Those are the remote control and diagnostic utilities. Instead of having to have to dispatch a Help desk person to go out to a user's desktop, you can, over the network, perform some diagnostics.

You can start the Windows NT diagnostic functions to see the current state of the computer. You can do remote control to look at the desktop. And you can do some diagnostics through remote control. You can execute some programs remotely. Let's say it's a server that's locked in a server room with no users logged on. You can use the remote control functions and launch a virus scanner, or change a configuration file or registry setting. And if necessary, you can even restart the computer. You have those abilities with SMS.

Next are network traffic analysis tools. You have the Network Monitor code that's built into SMS 2.0, as well as the Network Monitor Control tool, to proactively look for specific events occurring on your network, such as broken DHCP servers, or possibly someone breaking into your intranet by supplying an invalid IP address. Those features are all built into SMS.

We have integration with SQL Server. SQL Server is a great database engine, and SMS stores all of its data in that database engine — the vast majority of it anyway; there are a couple of other data stores — but for the most part, SQL Server is where we store all of our data for software metering or the SMS site database. That product scales extremely well, so it's a great advantage to be able to support Microsoft SQL Server.

Finally, integration with third-party management solutions. That means you have integration with SNMP. So we have a Windows NT event that's going to need a trap translator. If you want to take specific Windows NT events that might appear in your event log and convert them into SNMP trap messages, then send them to some third-party SNMP management console, you can do that with SMS.

We also have the use of Windows Management Instrumentation. WMI is built into Windows 2000, as well. Anything that you can script for SMS, using WMI or any other utilities, you can do the same thing with Windows 2000, because Windows 2000 relies heavily on Windows Management Instrumentation, as well. There is commonality there.

So we've looked at some of the features of SMS, as well as Windows 2000, as far as management, and now let's talk about where to use each one (slide 14).

As you've seen from these last few slides, the only area of overlap between these two technologies is software distribution. All the other features are complimentary. SMS does not do user data management or user settings management, where Windows 2000 does a great job with that.

Windows 2000 does not support WAN links very well. It doesn't allow you to target based off of inventory data. It doesn't have the status reporting that SMS has. It doesn't have the ability of doing software monitoring.

All those features are complimentary to each other. You may want to use both environments.

So our recommendation generally is use IntelliMirror, if you're a pure Windows 2000 environment (in other words, all your desktops are Windows 2000, all your servers are Windows 2000), and you have no advanced needs. In other words, you do not need to deploy applications based off of inventory data — hardware/software inventory. Or you don't need to monitor what applications are being used on your desktops. And you have no bandwidth restrictions. In other words, you can blast out packages over your links any time you want, and not have to worry about scheduling, or when users are going to pull down those applications. You may very well want to use just IntelliMirror to do your software deployment.

However, if you do have advanced needs; you do want to target your software distribution based on hardware inventory or software inventory; and you do want to monitor your application usage; you do want to use Network Monitor in a full network capture mode, and the control tool looking for specific events; you do want to have the advanced reporting and help desk functions; then, you may want to integrate the two, or even replace the Windows 2000 software distribution technologies with SMS, and use SMS as the technology.

If you're in a heterogeneous environment (in other words, you don't have just Windows 2000), then you may have to go to SMS, because the Windows 2000 advanced features, the IntelliMirror features for software distribution, do require Windows 2000. If you're in a heterogeneous environment where you have Windows NT 4.0, and you have some Windows 95/98 clients, if you want to deploy or manage software, then you have to use SMS.

Next, let's talk for a moment or two about how to deploy Windows 2000 using SMS (slide 15). These are just a couple of slides on what SMS can and cannot do for Windows 2000 deployment. Then I'll go over about Windows 2000 remote install service.

SMS does not install operating systems (slide 16). SMS does operating system upgrades and updates, but not installations.

That means if you have a brand-new computer that does not already have an operating system installed on it, SMS cannot help you get that operating system installed, because SMS requires the SMS client agent to be installed — the SMS client service — and the appropriate agents, which requires a Windows-based operating system. If that's not there already, you have no SMS for that client, and there's no way SMS can push out an installation.

However, if you want to upgrade from Windows 95, Windows 98, or Windows NT 4.0 to Windows 2000, SMS can do that operating system upgrade for you. Or, if you want to update your existing platform — that is, you want to upgrade to Windows NT 4.0 Service Pack 6 or Windows 2000 Service Pack 1 — SMS can help you update your operating system, as well as upgrade it to a newer release of an operating system.

If you're in an upgrade environment, you can do silent upgrades, and that will require you to work with your Unattend.txt file for a couple of different reasons.

One reason is, unless you're in a select environment, you're going to have to supply a product ID for your upgrade. So your Windows 2000 code is going to have a product ID that has to be supplied. That can be done in an Unattend.txt file, or it can be done manually; but then again, that removes your ability of doing a silent upgrade.

Also, if you're in a Win 9x environment, those computers don't have accounts in your domain SAM, as Windows NT computers do. So when you upgrade from a Windows 9x environment to a Windows 2000 environment, you have to create an account in the domain — in this case, in the Active Directory — for your new Windows 2000 computer.

During the upgrade, that can be done automatically, if you specify the appropriate information in the Unattend.txt file. However, that's a text file that other people can look at. They could find an account that has administrative permissions, that is able to create computers.

You could use delegate authority inside Windows 2000 and limit the risk of anybody else looking at that file. Or, you could pre-create your accounts in the Active Directory for the Windows 9x boxes that are going to be upgraded to Windows 2000. So you'd have the account there, and during the upgrade it would check to see that there is an account already created, and just complete the upgrade.

SMS can help you in the deployment of Windows 2000 with a new utility called the Windows 2000 Readiness Analyzer.

This is an analyzer very similar to the Microsoft Year 2000 Product Analyzer, which we released last year. It will help you analyze your systems and determine whether or not those computers can be upgraded to Windows 2000. It checks for hard disk space, as well as RAM, processor, and any applications or device drivers that can't be upgraded to Windows 2000.

This is a utility you can download from our Web site, http://www.microsoft.com/Windows2000/upgrade/compat/ready.asp. Go to that Web page, and from there you can download the Windows 2000 Readiness Analyzer.

It's a self-extracting zip file. When you run the program, it's going to create the folder on drive C of the server that you install it on. It's going to create a Windows 2000 Readiness Analyzer Tools directory.

That directory will contain a number of different things, but it will include a package definition file. You can then import that package definition file into SMS, create a package, and deploy the Windows 2000 readiness analyzer to all your current SMS clients to see which ones can be upgraded to Windows 2000, or which ones can't be upgraded, and for what reasons.

There's a set of queries that are built in, so you can import those queries into your SMS database. Once you've run the Windows 2000 readiness analyzer, that's going to force hardware inventory to run.

Once hardware inventory has been run and the data has been collected, you can run these queries to see which systems are ready to be upgraded and which systems can't be upgraded, and for what reason. It will tell you that there's not enough disk space, or the processor isn't powerful enough, or you've got some incompatible or device driver software installed.

It also includes Crystal Reports, so you can generate a report on which systems are ready to be upgraded. That's how SMS can help you out with your deployment. You already have the Windows 2000 Professional or Windows 2000 Server package definition files built into SMS 2.0. So once you find out which systems are able to be upgraded, you can deploy the upgrade through SMS to your existing Windows clients, to your existing SMS clients.

Now one thing SMS cannot do, as we mentioned, is deploy brand new operating systems. Windows 2000 itself can do that through something called Remote Install Service, or RIS. What RIS allows you to do (slide 18) is create an installation of Windows 2000 Professional over the network.

So you plug in a computer that has appropriate hardware and software (and we'll talk about that in the next couple of bullets), turn it on, and if it's available, you'll have a menu option that pops up and lets you actually install Windows 2000 Professional over the network.

This installation will be just a core Windows 2000 Professional installation. You're taking a Windows 2000 Professional CD and prepping that; so it's called a CD prep, a CD image, and you deploy that over the network and do an installation. Or, it can be something called an RI prep, which includes not only the preinstalled operating system, but also any applications you want preinstalled, and any desktop settings, or any application settings. So you can deploy your applications along with your images, down to your new desktops.

You may be familiar with remote boot. We used to have something in one of our line manager versions called remote boot. It's very similar to that, but instead of just booting your operating system over the net, you're actually installing your operating system over the net. So it's a one-time shot. You run it one time and it installs on your computer. You don't have to do your RIS installation anymore.

It requires a special PC, a PC-98 compliant PC, or a NIC that's PXE compliant. PXE is pre-boot execution environment. So if you have a PC-98 PXE-compliant motherboard or network adapter card, then you can use the remote install service to deploy Windows 2000 Professional to brand new desktops.

That's a great way of getting replacement computers up and running as soon as possible. Just plug them in, turn them on, hit the Menu option (I believe it is F12), and then choose Install Windows 2000 Professional. You're up and running in a matter of minutes, as opposed to having to build a brand new box from scratch.

In the last couple of slides I want to talk about SMS 1.2 support for Windows 2000.

You'll find that the SMS 1.2 support is much less comprehensive than the SMS 2.0 support, and that's due to various reasons, but we do suggest that you upgrade to SMS 2.0, if you really want to integrate well with Windows 2000.

For the SMS 1.2 server (slide 19), we have no support for Windows 2000 Site Server. Your site server must remain on a Windows NT 4.0 box. We do not plan on supporting Windows 2000 Site Server in an SMS 1.2 environment.

In fact, the only 1.2 server role that we're supporting for Windows 2000 is a distribution server. You're allowed to use a Windows 2000 server as a distribution server, but not as a logon server, or as a site server, or a SQL Server computer, or a helper server. None of those roles at all. They all have to remain on Windows NT 4.0. The distribution server is the only thing we're supporting a Windows 2000 server, as far as an SMS 1.2 server role. We do not support the SMS Administrator console on Windows 2000.

We don't support logon points. So if you're in a mixed-mode environment where you have Windows NT 4.0 domain controllers and Windows 2000 domain controllers, and you want to use logon scripts, then you have to go from the option of Use All Detected Servers for your domain to Use Specified Servers. You have to manually specify your SMS 1.2 logon servers that are running on Windows NT 4.0 domain controllers. So you can only use Windows NT 4.0 domain controllers, not Windows 2000. Our service support is limited for SMS 1.2 in Windows 2000.

Our client support is better (slide 20), in that for SMS 1.2 client support, we're going to support everything on Windows 2000 Professional only. We're not going to support Windows 2000 Server clients or Windows 2000 Advanced Server clients in SMS 1.2, only Windows 2000 Professional clients.

We're not going to support Program Group Control. That's the ability to share applications. That's now handled through the operating system with IntelliMirror, as we talked about before.

We're not going to support remote control video acceleration. Just like in the SMS 2.0 environment, the drivers have to be rewritten. We're working on that, and we'll make that available when it is ready. There's no Windows NT event-to-SNMP trap translator for Windows 2000.

One other thing is there's no Network Monitor support for an SMS 1.2 client running on top of Windows 2000. So we do not support Windows 2000 Server or Advanced Server at all, just Windows 2000 Professional.

The SMS Administrator console is not supported on Windows 2000. You can only install your clients from Windows NT 4.0 domain controllers. We don't support Windows 2000 domain controllers, only Windows NT 4.0 domain controllers.

You can upgrade from Windows 9x (being Windows 95 and 98), as well as Windows NT 4.0, to Windows 2000, using a package definition file for SMS 1.2. You can manually upgrade, if you want to. You can do the upgrade, then you actually run Upgrade.bat from the Netlogon share of your domain controller to upgrade the OS, the SMS version. Tell SMS to upgrade the OS, and then the next time you run Smsls.bat, it will upgrade the SMS support for that client computer.

When is the SMS 1.2 support available? Well, when I created this presentation, it was available. There's a QFE bundle called the SMS 1.2 Support Fixes for Windows 2000.

When I created the presentation, it was available from PSS. It's not going to be available for download on any Web sites. You can only get the support through PSS.

However, I was told earlier this week that it was pulled back for a specific reason. There was a remote control issue that they're working through, and they hope to have it re-deployed or available again within the next week. So by next week, they hope to have the support bundle available again, so you can support Windows 2000 boxes with SMS 1.2.

Then, when SMS 1.2 Service Pack 5 comes out later on this year, that will include all the Windows 2000 support; so it will include the SMS 1.2 Support Fixes for Windows 2000.

So look for it next week. You can talk to PSS, your support contact, and if you need the SMS 1.2 Support Fixes for Windows 2000, you should be able to get it from your PSS contact.

However, you did see that the support is limited, so we do recommend that you do upgrade to SMS 2.0, when you want to integrate with Windows 2000. Take SMS 1.2 to SMS 2.0, then perform your Service Pack 2 upgrade. Then work with your Windows 2000 environments.

So that concludes the formal presentation. Now Heidi is going to read your questions for us.

Heidi: Okay, excellent. Thanks, Wally. A couple of program notes before we get into the Q&A.

First off, we do have an SMS SP2 support WebCast scheduled for June 1st. The same time, same place, just a different URL. You'll be able to find that on the Web.

Also, we have an SMS backup and recovery session that we're going to be slating for July. We don't have the date scheduled as of yet, but if you're interested in that topic, you might want to keep an eye out for it.

The Q&A portion of the Support WebCast is intended to encourage further discussions of the Support WebCast topic. However, one-on-one product support issues are outside of the scope of the support WebCast. If you do need technical assistance, please submit an incident on the Web, or call Microsoft Product Support Services and speak with a support professional.

At this point, we have received some questions; so let's go ahead and get started.

The first one is: Is the use of Windows 2000 DHCP supported under SMS Service Release 1, or is Service Release 2 for SMS required?

Wally: Support DHCP: SMS 1.x never had a Network Discovery agent that would go out and talk to DHCP. So there's no support at all, for SMS 1.x, to be able to use DHCP. Now, if your clients are using DHCP for Windows 2000, that's fine. SMS doesn't care about that.

But as far as Network Discovery goes, that's a Windows 2000 feature; and the SMS 2.0 SP2 service pack is required for that; it was actually in the SMS server QFE bundle that was released a couple of months ago.

Heidi: Okay, excellent. The next question is: Does SMS 2.0 fully support Windows 2000 Terminal Servers? How about Windows NT 4.0 Terminal Servers?

Wally: We discussed that during the presentation. We do support Windows 2000 Terminal Servers and remote support mode and application compatibility mode. So we have full support there as a server function.

As a client (so SMS 2.0 client software running on top of a Terminal Server computer), all we support is manual installation or remote installation, hardware inventory, software inventory, and software distribution in the background. We don't support software distribution to users. We don't support remote control. We don't support Network Monitor or logon installation in those environments.

We do not currently have any support for Windows NT 4.0 Terminal Server. We're looking at it. Something may be coming in the future, but as of today, it's Windows 2000 Terminal Server support only.

Heidi: Okay. The next question we've actually had submitted several times, and that is: When will SMS SP2 be available? Do we have any publicly available information on that yet?

Wally: I can give you an update. As of yesterday, SMS 2.0 SP2 Release Candidate was released to manufacturing. So Release Candidate is available. We're shipping it out. In fact, it went out yesterday to our EAP customers, the tier-one and tier-two EAP customers should have a CD today. The rest of the technical beta sites will get their CDs within the next week. So that's Release Candidate.

We have no publicly available date as to when the final release of Service Pack 2 will be. That is going to depend entirely on our EAP customers telling us that the code is ready to go. It's going to be a number of weeks from the time they get it and do their full testing, and then do their integration testing to verify that yes, Service Pack 2 Release Candidate does solve all the issues they had, it does not generate any new issues, and so on. So it's going to be a number of weeks yet, but we don't have a date, because they're going to tell us. The customer is going to tell us when it's ready to go. But Release Candidate was released yesterday.

Heidi: Okay. So we're getting there. The next question is: Is it possible to upgrade SMS 2.0 on a Windows NT 4.0 member server to Windows 2000 without a reinstall of SMS 2.0?

Wally: Yes. We mentioned that during the presentation as well, that Windows NT 4.0 member servers with any SMS server function on them, any SMS site system role, are fully supported to be upgraded to Windows 2000 member servers without retracting, de-installing, reinstalling, redeploying, or anything. Just do a straight upgrade from one member server to another member server from Windows NT 4.0 to Windows 2000. We totally support that.

Heidi: Okay. The next question is: Is there currently a tool to create Windows Installer packages from SMS 2.0? Possibly a white paper with examples would help.

Wally: We have a utility, that's still in beta testing right now, for the SMS Installer. We have a utility that will take SMS Installer packages and convert them to Windows Installer packages, but that's all that's available right now.

Future releases of the SMS Installer will generate MSI packages — Windows Installer packages — automatically, or at least you will have the option from SMS Installer itself to create those. But that would be the only place, because SMS itself is not an installation technology.

SMS is a distribution technology. We make programs available. Some other program actually controls the installation, and the program we want you to use for that installation is Windows Installer. So SMS itself does not create Windows Installer packages. Today, SMS Installer can use this beta utility. It's called the Installer Step-up Utility. In the future, a new version of SMS Installer will create them natively.

Heidi: Okay. Thank you. The next question is: Are the PXE-compliant NICs the same as Wake on LAN – compliant NICs, or is this a different standard?

Wally: Wake on LAN and PXE are two different standards. I've not looked at the Wake on LAN specification, but I would think Wake on LAN would probably include the PXE compliance as well. So if you have Wake on LAN support right now, you'd have to check with the manufacturer of your motherboard or your adapter card to see if they support PXE. My guess is they would, but that's purely a guess. I've not looked at the specification myself to be able to tell you that.

Heidi: Okay, excellent. Moving right along. The next question is: Where or how do you change a server role to exclude the logon point role before a Windows 2000 upgrade?

Wally: I'm not sure I understand the question, but I'll give it a shot. You don't exclude servers from specific roles. You assign roles to SMS 2.0 through the SMS Admin console. So, on the SMS Admin console, you can assign roles of client access points, distribution points, software metering servers, and so on. In Windows 2000, you assign the role of a logon point by going to your discovery methods or client installation methods, and going into either your Windows Networking Logon Discovery method or your Windows Networking Logon Client Installation method, and then enabling that method. And in the list of logon points you add the domain name.

So if it's an SMS 2.0 environment, you can't specifically exclude Windows 2000 domain controllers. What you would do is just not include the domain that those Windows 2000 domain controllers are a member of. Then you can use other domains that are Windows NT 4.0 domain controllers. Or, just get your domain controllers all set up, then add the domain. Again, it's purely just in an upgrade scenario.

So if you are in an environment where you're upgrading from Windows NT 4.0 domain controllers that are logon points to Windows 2000 domain controllers, and you want to have logon points there, you must remove the logon point role. This means you have to remove the domain from your discovery methods, your Windows networking logon discovery method, as well as the Windows networking logon client installation method. Remove that domain, and let SMS remove all the logon points from your Windows NT 4.0 domain controllers. Then upgrade to Windows 2000, promote it to a domain controller. Then add that domain back in to the appropriate discovery or installation method, and you're fine. They can't have that role on top of them when you do upgrade, because the security changes.

Heidi: Okay. And if for any reason that answer did not address the question that was posed, if the individual who submitted the question wants to send us another question with clarification, we can certainly follow up.

The next question is: SMS 2.0, in the Windows NT 4.0 environment, updates the replicated Netlogon share \Source\Export directory with required SMS files. What happens in the Windows 2000 Active Directory environment where the replication of the Netlogon feature is eliminated?

Wally: We do support putting our files in the appropriate location. So in a Windows 2000 environment, the Netlogon share \Sysvol\sysvol\fullyqualifieddomainname\Scripts. In that environment, that's where we place our SMS logon script files automatically.

So we haven't accounted for that. But we do know where that path is on Windows 2000. We do know where to put those files so that users can kick out those logon scripts at the appropriate time, when their profile has been updated, and they do a logon validation process.

Heidi: I want to encourage all of you who are listening in on our broadcast to let us know what you think about it. We definitely encourage you to send us your feedback at the alias feedback@microsoft.com. We're very interested in your feedback regarding this topic, any sessions you've seen in the past, any general comments you have about the program, or any suggestions you have for future topics.

Okay. With that said, let's go ahead and move on to the next question, which is: Will Microsoft support the ability to save packages in the new MSI format?

Wally: Well, as we've already discussed, there are numerous different installation technologies that will allow you to create MSI packages. Numerous third parties do it. Windows 2000 has its own ability to create MSI packages. SMS Installer will have the ability natively in the future; and currently, there's the Installer Step-up utility to take SMS installer packages and divert them to MSI packages.

That we've already discussed. I'm not sure what else you're getting at there. There are numerous ways of creating MSI packages. SMS itself is not going to, because SMS, again, is not an installation technology. It's a distribution technology. The installation engines are WINInstall or InstallShield or SMS Installer; other third-party utilities will have the ability to create MSI packages that can be just deployed through Windows 2000 IntelliMirror or through SMS itself.

Heidi: Excellent. The next question is: Today I see no correlation between SMS site definitions and Active Directory sites. Will SMS ever utilize the Active Directory site configurations, as opposed to having its own? Do we have any sort of information on futures like that, as of yet?

Wally: Windows 2000 bases sites off of boundaries as well. So Windows 2000 sites are based off of IP subnets, which is exactly what SMS does. So from that aspect, SMS 2.0 site boundaries were designed specifically in mind for what Windows 2000 was doing for site boundaries.

Now they may have done some different things in the later releases, and the final product for Windows 2000, but that's basically it. They're based on IP subnets.

In the future, we will have tighter integration and exploitation of the Active Directory. You may be able to get into more SMS sites based off of OUs or Active Directory forests, or whatever else you want. But we have nothing that I can tell you about today, or that I even know about today, other than rumors. We do plan on having multiple, different layers of Active Directory exploitation coming out in the future.

Heidi: The next question is: What happens with SQL databases when migrating a DC site server from Windows NT 4.0 to Windows 2000? And to collections, does anything happen to them? And does it require a client reinstall as well?

Wally: If your SMS database, your SQL Server, is staying on a Windows NT 4.0 box, then there's no pain at all involved with it. If your SQL Server installation is on a Windows NT domain controller, it is a site system role that we do not support in upgrading from a Windows NT 4.0 domain controller to a Windows 2000 domain controller. So that would require, again, that reinstallation process.

Now if this reinstallation process is causing pains, then again, we suggest that you just don't deploy Windows 2000 right now. Wait until we can give you that support. We're testing our scenarios right now, and we will have support coming up for methods of migrating Windows NT 4.0 domain controllers, with SMS site system roles on them, up to Windows 2000 domain controllers, and maintaining those SMS site systems. That hopefully will come out very soon.

As of today, the stated support plan is, for any SMS site system role on a Windows NT 4.0 domain controller that's being upgraded to Windows 2000, you have to remove the SMS site system role, whatever it is. If that's a SQL Server, then yes, you have to do so.

For collections, you would want to create new collections, so you could target just your Windows 2000 clients. From looking at Service Pack 2, I don't recall seeing any collections built in for Windows 2000 clients. I honestly didn't look, but I don't recall seeing any additional collections there. It's very easy to create your own collections, so you could do that.

As far as reinstalling the client, no, you don't have to reinstall your client. Once you've upgraded to Windows 2000, the next time the Client Configuration Installation Manager (or CCIM) on the client computer does its maintenance cycle, it will detect that your operating system has been upgraded, and it will force a reinstallation of your SMS client utilities, to make sure that you have the proper versions for that supported platform.

Heidi: Okay. Next question. Are there any steps that can be taken to enhance MMC performance?

Wally: MMC 1.2, which is available in Windows 2000, is better performing than MMC 1.1, which ships with SMS 2.0. So you could install MMC 1.2. You can download that from http://www.microsoft.com/downloads/release.asp?ReleaseID=20492/ and install it on your Windows NT 4.0 boxes, so that you have MMC 1.2, and then run SMS on top of it. Because it's better performing. It also has the ability to export data, so you can print from it.

From there, there are a number of different issues, and you're going to have to get in contact with your support person to get some of the specific things. There were some fixes in the server QFE bundle, as well as in Service Pack 2, for performance, particularly in the area of running queries, which were slow. And there have been some changes in that environment.

So there are some specific fixes, but just regarding general slow down in performance or a lack of performance in MMC. I'm not aware of any single thing that you could do for that, other than making sure you have enough SQL user connections, because we do use a number of those.

Heidi: Okay, great. We have received several comments with feedback, and I want to thank everybody who has taken the time to send those comments. We really appreciate it. We have had a few more questions submitted, so on to the next question.

This is SMS migration to Windows 2000 that we discussed before, and it's a clarification. There are several components to this question.

First off, known conditions: SMS 2.0 site servers installed on Windows NT 4.0 domain controllers must be reinstalled on a Windows 2000 domain controller. Next, SMS 2.0 site servers installed on Windows NT 4.0 member servers can be upgraded to Windows 2000 in place. For example, without uninstalling and reinstalling SMS.

So, the individual's question is: If we have all of our SMS site servers installed on Windows NT 4.0 member servers within its own Windows NT 4.0 resource domain, can we upgrade our SMS 2.0 site servers to Windows 2000, and move these servers to our Windows 2000 domain infrastructure one by one, without reinstalling SMS? Would another option be to upgrade all member servers in the Windows NT 4.0 domain to Windows 2000, then upgrade the Windows NT 4.0 domain to Windows 2000, and add to the new Windows 2000 domain infrastructure?

Wally: Everything sounded good until you got in the middle and you wanted to do your moving. SMS does not currently support moving the site server from one domain to another domain. So because of the fact that you said your SMS servers were all in a resource domain, SMS today does not support you taking those servers out of the SMS resource domain and adding them to any other domain.

This is a common thing that people want to do, and with Windows 2000 out, they want to collapse their domains that were very prevalent in Windows NT 4.0, and they're not necessarily recommended as prevalently in Windows 2000. People want to collapse their domains, and SMS currently does not support moving the site server from one domain to another domain.

With that stated, everything else you said basically is moot, in that you have to reinstall, because of the fact that you're going to move from one domain to another.

Now if you can hang on, we are working on seeing what we can do to allow moving between domains. We don't have anything available today, and I can't give you any time frame on when we might have something available; however, we are working on that. So possibly in the future, we will have the ability for you — documented procedures and maybe utilities, whatever is necessary — to move an SMS server from one domain to another domain. Today it requires a reinstall.

Heidi: Okay, fabulous. The next question is: Do you need a WINS server in a Windows 2000 SMS 2.0 environment?

Wally: Yes, you do, for two reasons. First is that a lot of Windows 2000 functions do still require WINS, so there are a lot of things there that aren't pure DNS yet. So even in a Windows 2000 environment, I've heard of other applications, like other BackOffice applications and so on, that do still need WINS.

Secondly, in the SMS environment, DNS does not return domain names properly for SMS. So SMS has to be rewritten to support the long domain names of 254 characters that can come from a DNS environment that SMS is looking for, in NetBIOS domains, which are 15 characters. So, yes, you do still need to have some sort of NetBIOS name resolution, whether it's WINS, whether it's some other b-node server or b-node broadcast, or some other name server, or just broadcast mode, whatever. You do have to have NetBIOS name resolution implemented, even in Windows 2000 for SMS, yes.

Heidi: Okay. Next question. Is there a source that the speaker can recommend where developers can find out more about conditions to be attached to component installations? I'm looking for the syntax necessary to make this work.

Wally: I've no idea what you're asking about there. I'm not a developer at all. I would look at the SMS SDK; so go find the SMS SDK. Maybe the WMI SDK, the WBEM SDK, and the SMS SDK. Those would be my only guesses. I don't know what conditions you're talking about, or anything else.

Heidi: And some more information you might want to look into the MSDN Online Support site for some of that information. You might find that there. It's a good location for developers to check out.

The next question is: Is there a recommended SQL version and/or maintenance level moving forward toward SMS 2.0 SP2? We currently use SQL 7.0 and no service packs.

Wally: No. SMS does not require anything specific, other than the fact if you're running SQL Server 6.5, you have to be at least at Service Pack 4 of SQL Server 6.5. However, we support 6.5, Service Pack 4 and later. We support 7.0, vanilla, Service Pack 1. I think I've heard of a Service Pack 2 out now, if not very soon, and SQL Server 2000. That's purely going to depend on what your other needs are, as far as that SQL Server goes. SMS doesn't care.

Obviously SQL Server 7.0 gets you better performance and some automated database maintenance tasks that SQL 6.5 doesn't perform. I don't know enough about SQL 2000 to state any benefits that it has over SQL 7.0, so I can't talk to it specifically. But it's whatever you want, corporate-wide, or whatever your DBAs think they need to have, or whatever your SQL Server support people state that you need to have as the service pack.

SMS does support 7.0 Service Pack 1 and Service Pack 2, from what I've been told. Any of those should be fine for SMS. We don't have any specific requirement for any of those.

Heidi: Okay. The next question is: What's the relevance of the SMS site code in 2.0? In SMS 1.2, it seems to have more of a significant role.

Wally: The site code is used whenever you communicate between sites. That's the identifying key between two SMS sites. If it was purely just a single-site scenario and never having to worry about another site, then technically you wouldn't need the site code itself. Now there's no way to get rid of it. We require it. You can't install a site server without it.

However, it's really there, and you have to have it for site-to-site communication. So if a site in Seattle wants to talk to a site in Dallas, they can't have the same site code, and that's how we make sure that they're unique, is by using the site code. So it is still required.

As of any plans for the future, I don't know whether they're going to get rid of that at all in the future — I have no idea. But as of SMS 2.0 SP2, we still require it, and it has to be unique throughout your entire enterprise, if you ever want to establish a parent/child relationship and have those two sites communicate. The site codes have got to be unique.

Heidi: Okay. A follow-up to the question. Is 2.0 more subnet oriented than 1.2?

Wally: Than 1.2? Sure, because 2.0 bases its site boundaries on IP subnets. So because of that fact, it is highly integrated around subnetting. After the site boundary aspect, there's not that much difference between versions, anything within the site. Whenever SMS had to send out any data, it would just blast it out over the wire, intra-site. Whereas between sites you have the compression, the throttling, the scheduling, and so on.

In either case, you could have logon servers or distribution servers or just client access points remote from computers, or remote from the site server over a WAN link, which is not good, as we talked about. I think that was in last month's session on site design issues.

You don't want to have those boxes remote from your site server. You want to have them on the same subnet as the site server. You don't want to have clients remote from those boxes. You want to have them on the same subnet as clients. So in that aspect, yes, 2.0 is very heavily integrated and surrounded by IP subnets, which is what its site boundaries are.

Heidi: Okay, excellent. And the last question in the queue at the moment is: Will SMS 2.0 utilize the Windows 2000 WBEM initiatives to pull better hardware inventory? For example, the serial numbers of Compaq and Dell computers?

Wally: Well, it has nothing to do with Windows 2000. We can do that today. It totally depends on your version of WBEM, or Windows Management Instrumentation, as well as your hardware. The hardware has got to support something called SMBIOS. So if your hardware on your platform supports SMBIOS, and your Windows Management Instrumentation supports SMBIOS, then yes, you can get that data.

For example, the WMI that ships with Windows 2000 is WMI version 1.5. That version does support SMBIOS 2.1. In my office, I have a couple different platforms, and that hardware does support SMBIOS 2.1. So when I do use WBEM 1.5 or WMI 1.5, I am able to retrieve serial numbers and computer manufacturers directly from BIOS, with hardware inventory. Nothing else is required.

However, I also have other equipment that even if I run Windows 2000 on top of it, it's not going to report that data, because the hardware doesn't support SMBIOS. The data is not available in the correct location, and the correct calls are not supported. So it totally depends upon your WMI version, as well as your hardware platform. WMI 1.5 does support SMBIOS 2.1, so as long as your hardware does, you're in good shape. A couple of the boxes I have in my office do support that, so I can get that data natively.

Heidi: Thanks, Wally. We have received a few more questions, so we'll get started on those.

The next question is: I thought I read somewhere that remote control will be evolving to include components of NetMeeting^® and terminal services technologies. Do you know if that's true?

Wally: I do know, but I can't say. We are looking at ways of improving the performance and reliability and integration of remote control in the future. I cannot tell you, or as far as I know, I'm not allowed to state anything, so I can't tell you what that direction is going to be. We are looking at other remote control technologies for the future.

Heidi: Okay. But it just sounds like that is not currently publicly available information. The next question is: Are there any plans to support site codes longer than three characters?

Wally: Nothing in the near future, that I'm aware of. Maybe in one of the future releases of SMS, yes, but I've not heard that as being something that's high on the priority scale. Three characters in a site code gets you enough flexibility, when they're alphanumeric characters. So, I don't think it's high on the priority scale, to do something longer than that.

That's what the site name or the site description is there for, to give you that more administrator-friendly name of the site. In SMS 2.0, the admin console shows you the site code, dash, and then your site name, or maybe in parentheses the site name, like (Seattle primary site) or (Wally secondary site), or whatever it is. So, I don't know honestly what the plans are. But I know it's not a high-priority item.

Heidi: Okay. The next question is once again leaning toward futures. I'll go ahead and ask it, but I have a feeling we're going to get the same answer back, in that the information is simply not publicly available yet; and the question is: Will hardware inventory natively pull DMI information in the future?

Wally: Not to my knowledge, because our stated direction is WMI. So as long as you have a DMI agent — a lot of OEM manufacturers (HP and IBM and Dell and Compaq) that do have DMI agents right now that take data and make it available — then you can pull the data from that. I've not heard any plans on having hardware inventory agents pull DMI data natively.

Heidi: Okay. And running down the same path: How will future releases of SMS leverage the Active Directory? Is there any public information on that yet, Wally?

Wally: No. Just as I stated, we will exploit it in the future, but I have not seen and I've not been told I can say anything, as far as any future direction; but we will exploit it further in the future.

Heidi: Okay. Next question is: I read that hardware inventory will be becoming a service. Do you know if this is true?

Wally: I do know. The answer is yes. In Service Pack 2 on Windows NT clients, the Hardware Inventory Agent will now run as a service, as opposed to an executable that's launched by the SMS client service. So it will be a separate service, running in Service Pack 2 on Windows NT 4.0 clients, as well as Windows 2000 clients.

Heidi: Okay, excellent. And the next question is: What is a good resource that I can use to show how to delete my current SMS site and install a new site on a different server in the same domain?

Wally: Well, I assume the SMS admin guide shows you how to remove a site. It's purely a matter of whether you have any software metering servers running. You decommission the software metering servers. Let them uninstall. And then you run SMSsetup and choose the Remove SMS option, and that will decommission your entire SMS server infrastructure. It does not do anything with your outstanding clients. It's just the servers, client access points, and so on. If you want to clean up your distribution points, you'd have to manually remove the packages in the admin console.

But I've not seen any resource, outside of training courses that I wrote. In one of our mock training courses, course number 128, in Chapter 3, we tell you how to remove a site server. We also talk about some of the residuals that are left over, because we don't do a complete removal of your site when you remove a site. We do leave a couple of files and accounts and registry entries and stuff hanging around. I've not seen any other resource that tells you everything to clean up, other than that course. I documented that.

As far as reinstallation, you know how to install one, so you know how to install another. Really the thing you're probably getting after is how to successfully uninstall, and then do a reinstall of a site.

Now, one thing: if you're talking about leaving your clients alone and then reinstalling your site, the key here is to make sure that you have manually created an SMS client connection account on your own.

So you've gone into your domain, you've created a connection account. The default is SMSclient_yoursitecode, but you've created an account. And then in the SMS Admin console, you specify that account. If you don't do that, what will happen is if you remove your site and then reinstall with the same site code, you'll orphan your clients. Your client computers will not be able to talk to the client access points, unless you hit your logon point again with Smsls.bat or Smsman.exe.

Whereas, if you create your own connection account, and then re-add that to the new site with the same account name and password, the clients will be fine. So that's an important note; but I've not seen much else documented.

As far as the client connection account, Service Pack 1 Release Notes documents it very well. There's a white paper that just came out called the "SMS Security Essentials" white paper. It's up on our Web site, http://www.microsoft.com/smsmgmt/default.asp. It's in the Technical Details section. So there's a white paper there, and it also talks about the client connection account, and how to prevent clients from being orphaned.

Heidi: Okay. The next question is: Is WMI 1.5 included with SMS SP2?

Wally: No. SMS SP2 does not upgrade WMI at all. If there are any fixes for it, then they're fixed in Service Pack 2, but we do not upgrade the version of WMI in Service Pack 2. You can download that from the Web site, if you wanted to. Go to Downloads under http://www.microsoft.com. Go to Downloads, and then search for WMI. You can download the new WMI from there, and apply it manually.

Heidi: Okay. The next question in the queue is: Will software inventory be a service, as well as hardware inventory, in SP2?

Wally: No. There's no reason to, because software inventory does not cause the SMSCliToknAcct& lockouts that hardware inventory did, when it was scanning the hardware resources. Software inventory just manually opens up files and reads headers in the hard drive. So it isn't causing lockout issues, whereas hardware inventory is doing a lot of other things, and some of these things happen across the network and cause lockouts. Software inventory doesn't do that, so there's no need to have it as a service.

Heidi: Okay. And moving along to the next question: Why are the SMS 2.0 client components split between logon points and CAPs?

Wally: To give you greater flexibility in your deployment. In SMS 1.2, everything was on a single server called a logon server. People complained that their logon servers were being bogged down by not only domain account synchronizations and logon validation requests, but also all this extra SMS stuff that was happening, like client installations, client inventory, and clients looking for advertised jobs for software distribution; and that was bogging down their domain controller performance, doing logon validations and other stuff.

So now we separate the two and make logon points purely a way of finding clients and kicking off the installation process. But from then on, clients never have to talk to the logon point again. From then on, they talk to a client access point, which is a file server in your environment, not necessarily a domain controller. You can put it on just a file server that you're already using for file print activity already, and now your clients just interact solely with that one server.

Another reason is that logon points can be shared between sites. So I might have an environment where I have 100 domain controllers spread throughout the United States, and I want to make sure that whenever my client looks for advertised programs or reports hardware inventory or looks for client maintenance, it's looking on a local resource.

CAPs are only within a site. You can't share CAPs between sites, where domain controllers can be. So if you randomly selected a domain controller, you might randomly select a domain controller on the other side of the United States. Then you're downloading a new client agent or downloading files from an advertised program, or looking for advertised programs across the United States to post to a local domain controller — in this case a client access point — which is always going to be local to your site.

Heidi: Okay. The next question is: You mentioned previously about recognizing the Active Directory location path that SMS will write to, as opposed to the Windows NT 4.0 Netlogons Source\Export directory. What happens in a mixed-mode environment where the replication to the Windows NT 4.0 backup domain controllers is sourced at a server or domain controller that is now not the PDC of the domain? I believe the SMS requirement is for it to place the required files in the \Export directory on the PDC in the Windows NT 4.0 environment.

Wally: Correct, correct. All of the above. SMS 2.0, in a Windows NT 4.0 environment, does place the logon script files in the REPL\Export\Scripts directory, as well as the Netlogon share on the primary domain controller.

If you're not using your primary domain controller as a replication source, then you're going to have to manually take that. We're going to create the REPL$ share on the primary domain controller, whether it's there or not. So if it's not there, we're going to create that share and we're going to place our files in the \Export directory for the PDC.

We don't use the directory replicator service at all to replicate our files. We replicate them manually, so the SMS_NT_LOGON_SERVER_MANAGER, it's going to place those files in the Netlogon share of all of the domain controllers.

So if you happen to have a different export source than the PDC, we're just going to put the files on the PDC, and then we're going to replicate them to the Netlogon share of our of our domain controllers, including the PDC, manually. So it shouldn't be an issue, unless you want to modify your Smsls.bat files.

In that case, you don't modify them in the \Export directory, anyway. You modify them on the site server in the SMS_DATA_NT_logon.box directory; that is where you modify your logon script. Then we'll still put it in the REPL$ share of the PDC, as well as replicate it to the Netlogon share of all of the BDCs.

If you have a different replication tree or export path, that's fine. We're just going to use our own for our own replication.

Heidi: Okay. Next question: Is there a white paper that details how to apply the WMI 1.5 to the SMS 2.0 site, so that all SMS 2.0 clients will receive WMI 1.5 upgrades?

Wally: No. SMS 2.0, when you do a client installation, will not install WMI 1.5. SMS itself supplies WMI 1.1 to Windows NT 4.0, as well as to Windows 95 or Windows 98 clients.

If the client already has WMI installed, and it's at least the same version or later, then we don't downgrade or install WMI from SMS itself. So you can't make SMS install WMI 1.5 natively when you install a client computer. It's going to be a separate process you have to do after the fact.

Now you theoretically could have SMS push out the WMI 1.5 installation as part of the software distribution deployment. You could probably do that. But none of that is documented anywhere at all, that I've seen.

So WMI is totally outside of SMS 2.0. SMS 2.0 is WMI 1.1 on all platforms under Windows 2000, and we do nothing with WMI in Windows 2000, because it already has a later WMI.

If you want to manually apply WMI 1.5 to your servers and clients, that's fine. You could use SMS to push it out as a standard software distribution package, just like you would a service pack. But you can't have SMS automatically install WMI 1.5 when it installs a brand new client. We install our own WMI, which is 1.1.

Heidi: Okay. Next question: Do you know why there was a change made in the Windows 2000 documentation that clean installs of Windows 2000 are not possible via SMS? I know that the SMS client must be installed on an OS, but is it not possible to have the Windows 2000 install be a clean install, not upgrading existing software when it is pushed to an existing OS?

Wally: In our documentation, when we say a clean installs, we assume that means something like an FDISK of the hard drive, and a format of the hard drive. Once you've done that, you've lost all your SMS data, so you have no SMS client agents running to do any software distribution.

You could certainly have SMS push out a Windows 2000 installation on an existing client computer, instead installing Windows 2000 in a fresh directory, and doing an installation that way, and not an upgrade. I think that would work fine. I don't know why we would prevent that. There may be some issues, but I've not heard of those.

But generally, when we say clean install, we mean on a freshly formatted hard drive, which means you no longer have an operating system there, and you no longer have an SMS client, so we can't do that. So I'm assuming that's what they're talking about.

Heidi: Okay. Is there a way to run specific client agents on specific client collections? For example, some clients would only run hardware/software inventory, and other clients would run those as well as software distributions, remote control, etc.

Wally: Boy, you guys are asking a lot of questions outside the scope of Windows 2000 and SMS 2.0 integration. However, no. All of the SMS client agents are site-wide client agents. All clients within the site are going to receive the same clients, and the same settings for those clients. So no, you cannot do that.

In your scenario, if you wanted that, it would be multiple SMS sites. So you'd have one site that would install and run hardware/software inventory, and another site that would run hardware/software inventory, as well as software distribution, remote control, etc.

Currently, all agents are site-wide based, so all clients in that same site will receive the same agents, and they're all running the same way.

Heidi: Okay. And with that question answered, we have cleared the queue of all the questions that were asked today. I believe Wally fielded just about between 35 and 40 questions, so it was a very active Q&A, and I want to thank all of you for participating in it.

I hope this session information was valuable to you. Again, a reminder that the SMS SP2 session is going to be held on June 1st, and we do have a backup and recovery session that we're hoping to have scheduled for July.

If you have any feedback for us, please submit it using the alias feedback@microsoft.com. We do want to encourage you to send us your feedback. We want to make sure that we're hitting the mark with this program, and giving you the kind of information that you need.

Once again, thank you so much for joining us today. I hope you have a fabulous day. I want to thank Wally for joining us. I'm Heidi Moeller and we'll see you again soon. Good-bye.