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

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

Wally Mead: This is a topic that I introduced in September 2001, in our WebCast on introduction to the next release of SMS, code-named Topaz. I introduced Active Directory integration there, but this will be the first of a series of WebCasts we're going to have, providing more detailed information into specific areas of Topaz, to get you prepared for the Topaz environment when the beta roles around, as well as when you start preparing for your implementation. In this presentation, we're going to delve into Topaz Active Directory integration.

Our session agenda for today (slide 2): first we'll do a quick overview of Active Directory™ integration. What are the requirements and supported integration scenarios for Active Directory integration with Topaz? Then we'll dig deeper into each of the different areas listed on the agenda. We'll talk about site boundaries and how we can integrate with Active Directory site boundaries. We'll talk about the different discovery methods for Active Directory integration. We'll talk about how you can use the information from the Active Directory discovery methods to target software distribution: not only targeting based off of computers and a little bit of inventory information, but also tying your Active Directory information (such as organizational units and containers) into your hardware inventory or software inventory, developed by SMS, and then do specific targeting for your software distribution.

Then we'll talk about a new feature of Topaz called Advanced Security. I'll introduce to you the Advanced Security model for Topaz, which does rely on Active Directory environments. We will have a separate WebCast next year on more complete information on the Advanced Security model. I'll introduce it today, because it does fit in with the Active Directory integration topic.

Last, we will talk about the schema extensions that Topaz will want you to do in your Active Directory environment, but not necessarily require you to do, and what those schema extensions will provide for you.

First off, we'll talk about our Active Directory support requirements (slide 3). This slide I believe was in my introduction to Topaz WebCast a couple months ago, but I want to hit it again for a couple of clarifications or highlights.

When we were talking to customers about what they wanted to see in the next release of SMS, which is called Topaz, the feedback was very clear that we were to not make the next release of SMS be Active Directory-dependent. In other words, customers didn't want us to require Active Directory to be able to use the next release of SMS. So we took that to heart, and the next release of SMS, being Topaz, will not be Active Directory-dependent. It can work in a domain environment.

So, SMS 2.0 supports but does not exploit the Active Directory environment. Some customers have integrated Active Directory information into SMS 2.0 today, by using the Adsync utilities found on the SMS management Web site (http://www.microsoft.com/smsmgmt/downloads/default.asp). So you do have that capability now to start a little bit with Active Directory integration. However, those of you who do have Active Directory environments want SMS to more fully leverage your Active Directory environment to provide additional capabilities for SMS. That's what Topaz will provide for you: the ability to take advantage of Active Directory environments. But Topaz does not require it, for those of you who have not upgraded or expanded out to an Active Directory environment yet.

The most common request that we got from our customer base, regarding Active Directory integration, was to allow Active Directory container membership, group membership, and so on, to be integrated with the inventory information that you get through SMS by default — the hardware inventory, software inventory information — you tie that together with information you can discover from the Active Directory, and you can use that for targeting of software distribution environments. So basically, you're targeting software distribution by tying together SMS inventory and Active Directory information.

The five different areas that we'll talk about, as far as Active Directory support (slide 4), are Active Directory site boundaries, Active Directory discovery methods, Active Directory software distribution targeting, and the Active Directory security model, which is the Advanced Security I just mentioned a couple of slides ago; then we'll talk about what schema extensions Topaz can make in your Active Directory environments. The rest of the presentation is going to cover those five different areas. So, we'll start with Active Directory site boundary support.

First off, what I want to do is talk about what SMS 2.0 provides for site boundaries (slide 5). I'm sure you're all fully aware of where SMS 2.0 is, as far as site boundaries. SMS 2.0 basically only supported IP subnets. Now, I say, "only supported IP subnets"; for those of you in a NetWare environment, or using IPX or our NWLink stack, we also support IPX network numbers. So we have that support. But the vast majority of our customers are in an IP environment, so basically we look at SMS 2.0 supporting IP subnets.

What that meant for you is if you were in an Active Directory environment and running SMS 2.0, you may have had to manage your IP subnets in two different locations. You all are aware of the SMS site boundaries, so you would go to the Site Properties for your site, and then you click the Boundaries tab. There you can add or remove IP subnets, as appropriate for your environment, for whatever you wanted for your SMS site boundaries. Then you could create Active Directory site names. In your Active Directory sites, you could manage IP subnets there as well. This left you with having to do IP subnet management in two locations. If you wanted Active Directory to integrate with those same sites, as well as SMS to use those same IP subnets, you had to add the subnet to your SMS site boundaries, as well as maintain that information in your Active Directory environment.

Oftentimes, you may remember to add the subnet information into one of those two locations, but you may forget to add it to the other locations. So you might properly set up your Active Directory environment with your site properties, and add the appropriate subnets, but you might forget to go into SMS and update your site boundaries for the new subnet that you generated. What that would mean is that Active Directory would look and detect that the client was a member of the AD site; however, SMS would say it may or may not be a member of this site, according to what the boundaries were.

Topaz allows definition of SMS site boundaries using Active Directory site names, so this will give you some great advantages, and we'll talk about that on the next slide. That's a great way of allowing you to only maintain your subnets in one location. Topaz will still support IP subnets, as SMS 2.0 does. So if you want to keep maintaining your existing infrastructure, and work with your Topaz site boundaries the same way you do with SMS 2.0, being management of IP subnets, you're more than welcome to still do so. However, you can now integrate with Active Directory site names. Topaz will allow you to use Active Directory site names, or IP subnets, or both. In fact, when you install Topaz, by default you're going to get two boundaries. One boundary will be the IP subnet that your site server is a member of. Your second boundary will be the AD site that your site server is a member of.

What are the advantages (slide 6) of allowing SMS to integrate with Active Directory site boundaries, or integrate Active Directory into SMS site boundaries? Well, the advantages are that Active Directory gives you much more granularity in handling your Active Directory boundaries, as far as IP subnets go. Active Directory site boundaries allow you to subnet an existing IP subnet. For example, you could take a class C address and subnet the fourth octet of that class C address. So your subnet mask in a class C environment most likely is 255.255.255.0. And that is what SMS would treat as its site boundary: the first three octets of your IP address, with a .0 in the fourth octet, for your host name.

Active Directory subnets, however, allow you to subnet that single octet address into an additional subnet. In other words, you take a physical IP subnet and break it into multiple logical subnets to be maintained in Active Directory. So you could take that fourth octet of your class C address and put a subnet mask on it to make multiple logical subnets on your one physical subnet. SMS 2.0, or Topaz, doesn't allow that. So the SMS site boundaries, when you're working with IP subnets, are full IP subnets. We don't allow you to subnet that one class address into multiple logical partitions.

Active Directory sites also allow you to combine two physical subnets into a single subnet for your Active Directory site, and SMS, again, does not allow you to do that through IP subnets. So now you can maintain those addresses, you can subnet a physical subnet. You can combine or supernet multiple subnets into a single subnet in Active Directory site names. Then you can take that Active Directory site name and use that as your site boundary in SMS. So, you only have to maintain your subnets in one location, that location being in the Active Directory. And Active Directory gives you more capabilities and more granularity in how you utilize and maintain those subnets. So you have more flexibility in the Active Directory environment.

The scenario is, you go to your Active Directory site. You create your subnets. You configure them the way you want them with the appropriate bits that you want to use for your subnet mask. Get your Active Directory site created with those subnets. You go to your SMS site boundaries, and for your SMS site boundaries, you specify that you want to use that Active Directory site name. Don't even bother with IP subnets in Topaz. Again, you still can use IP subnets. You can mix your IP subnets and your Active Directory site boundaries in the Topaz environment. So a single site can have both IP subnets and Active Directory sties.

This is a screen shot of the Topaz parent site properties (slide 7). This shows you that in this environment I have an Active Directory site name or an Active Directory site called Topaz-site. I also have an IP subnet of 192.168.21.0.

To add an Active Directory site, all you have to do is click the little new button, which is the star button next to the X button, which is the delete. So you click the star button. In SMS 2.0, your two options for a new site boundary were IP subnet and IPX network number. Topaz now lists IP subnet and Active Directory site. So just click Active Directory site, and then in the Active Directory site name box you type in the name of your Active Directory site. There are no browsing capabilities there. You have to know what the name of your site is. You just select that and add it to your boundaries. Then you can remove the existing IP subnet if you want, or what the default Active Directory site may be, according to what your site server is assigned to.

That's Active Directory site boundary integration. It has great capabilities for allowing you to integrate IP subnets in a more granular and flexible fashion than what SMS provides, by default, by the IP subnet.

The next topic we'll talk about is Active Directory Discovery (slide 8). How can you leverage information from the Active Directory into SMS for collections, and for targeting of software distribution?

In Topaz, there are three distinct discovery methods to discover different resource information from the Active Directory, and I'll go into each of these three different methods in more detail on the subsequent slides.

The first one is Active Directory System Discovery. What Active Directory System Discovery will do for you is discover system resources from the Active Directory. In other words, it will go up and find computers that have been added to your Active Directory.

The next one is Active Directory User Discovery. That's going to go out and discover user accounts from the Active Directory, as an admin: Wally, Jim, whatever the case may be, it discovers user accounts from the Active Directory.

The third discovery method is Active Directory System Group Discovery. Active Directory System Group Discovery can be thought of as "Heartbeat Discovery" for systems in the Active Directory, but only for systems that are assigned to your SMS site. So it retrieves additional data for assigned SMS resources from the Active Directory. Now let's dig into each of those in a little more detail.

Actually, what I want to do on the next slide is talk about some common features of all three discovery methods (slide 9), so I don't have to reference this all three times on each of the different discovery methods. These are common to all three of the different Active Directory Discovery methods.

None of these are enabled by default. So if you do a custom setup, none of these Active Directory Discovery methods are enabled. If you do an express setup, they are enabled; however, we don't add the path information, and I'll show you an example of the pathing in some of the screen shots coming up. There's no path information. You have to go in there and physically add the path before you get any data.

The path that you add can be from the local domain, it can be from the local forest, or from the remote forest. The syntax of the path is going to be LDAP with your DN syntax, or GC with the appropriate DN syntax after that. LDAP is the syntax if you choose your path as a local domain. If you choose local forest or remote forest, then your path is going to be global catalog or GC.

When you create your path, by default the query for that path is going to be recursive. In other words, if I select my root domain in my Active Directory environment, if I select that as my path, my LDAP path will be what's shown in the screen shots coming up shortly, my full domain path. Then we're going to do a recursive query, which means look at all the containers in that path: so users, computers, domain controllers, and everything else. We'll look at all the different containers.

You can, if you want to, configure each query to be non-recursive. In other words, configure just entities in the specific path, but not any subcontainers. Don't open up any containers and look at resources in those containers. You can specify in your path either the entire domain or a specific container to be queried.

When you enable the discovery method, you specify what path or paths you want to query or do discovery from. You can schedule this just like you can any of these other discovery methods. So you have the normal scheduling capabilities of a full schedule: hourly, weekly, monthly, the first day of the month, the last day of the month, the third Tuesday of the month, or whatever schedule you want to have.

You can also schedule this to run as soon as possible. So there's a new check box on all of the discovery methods in Topaz that reads Run discovery as soon as possible. So you select that check box. You don't have to schedule, if you don't want to. As soon as the site control file and everything has been updated, we'll run that discovery method, report your data, and then the discovery method is turned off, and we'll wait until the next scheduled interval, if you want to have a schedule. That's a pretty cool feature, if you want to initiate discovery without having to change your schedules.

Now, network traffic is going to be generated to go to either your domain controller through LDAP or to your global catalog if you're doing your forest. So you are going to generate network traffic from your site server out to that domain controller environment to retrieve this data. So you do have to go out there and generate that. We'll talk about that a little further on, as we get through the presentation.

Now the requirements are you just have to be a domain user; so the SMS service account (SMSService) just needs to be a domain user in that domain to be able to do your query. You don't need to have any advanced rights for this query.

So, the first method we'll look at in more detail is Active Directory System Discovery (slide 10). Active Directory System Discovery allows you to discover systems from the Active Directory. Systems are not required to be assigned to the local SMS site to be discovered. So just any computer resource that has an account in the Active Directory will be queried. Again, it doesn't have to be a member of your SMS site, so just do discovery of the appropriate resource: all the computers or whatever container or whatever path you specify.

The SMS site server will connect to each resource that it discovers. Each of the resources will be discovered. When we find a computer resource in the environment, we're going to go out there and do network queries across the wire to each of those resources to pull specific data from that resource. What we're trying to acquire from that resource is the Active Directory site name. So we're going to go up and connect to each of the resources and query for the Active Directory site name.

Now, this is not a lot of network traffic on a per-resource basis. In the testing I did, it was about 22 frames, which includes all the session overhead frames for your TCP session, your NetBIOS session, your SMB session and so on, and all those connections. It's about 22 frames total and about 5 KB of network traffic, so it's not bad, on a per-resource basis. However, when you get into environments where you have a lot of different resources, then that can be a significant amount of network traffic, so you do want to take that into consideration. What that means for you is that you may want to be specific in your targeting of your query. You may not want to query your entire domain. You may want to query just a portion of your domain, specific containers that you want to look at.

This discovery is only available for Windows^® 2000 and Windows XP clients, so you have to be a client that has Active Directory-enabled in order to do the discovery, so it's only for your Windows 2000 and Windows XP environments. The agent name that's generated from the DDR that gets created is SMS AD System Discovery Agent that will be the agent name listed.

The type of information we'll return here is your Active Directory site name, your SMS site, the user, the resource name, your operating system, your resource domain — it will return that information — primarily spacing information about the computer, as well as the Active Directory site. It does not return any organizational unit or container or group information. That comes from a different discovery method.

On the next slide (slide 11), we have a screen shot of the Active Directory System Discovery environment.

In the screen shot, what you'll see is that I've enabled Active Directory System Discovery, and then my distinguished name or my path. You'll see it says LDAP, and then it specifies the path. So LDAP, I'm going to a local forest, and then you'll see the DC=Topazdom, which is my domain name, and then my DC=wally, DC=microsoft, DC=com. My Active Directory site name was Topazdom.wally.microsoft.com. So it's a full path that I'm going to, to the local domain. Also notice, on the right-hand side, it says Recursive. Recursive is we're going to go from the root of that down through the entire tree structure, through all the different containers we have, and then pull up any data in all those different containers.

That's just a screen shot. Basically, you select the check box. You then click the new (star) button to specify whatever path you want. You have the ability to browse for your appropriate path. Then you go to the Polling Schedule tab and do your scheduling, or select the check box that says, Run discovery as soon as possible.

On the next screen shot (slide 12), we'll look at the results of Active Directory System Discovery. Here are the results of discovery. This is a computer called TOPAZSERVER. In TOPAZSERVER, the big thing you're seeing is the first entry, ADSiteName. So we have the Active Directory site name, and this was acquired by going to the appropriate client after discovering the computer name out of the Active Directory, and then querying that computer across the wire to find its Active Directory site name. You also see the AgentName, SMS_AD_System_Discovery_Agent, the SMS site that did the discovery, and you'll see the computer name, the NetbiosName, the OperatingSystemNameandVersion, and the ResourceDomainORWorkgroup. So you have some basic information that is returned there.

The next discovery method we have, on the next slide (slide 13), is Active Directory User Discovery. Active Directory User Discovery is going to discover user accounts from the Active Directory. So we're going to go out to the Active Directory Discovery user accounts, which are very similar to the Windows NT User Account Discovery method that SMS 2.0 has. By the way, that discovery method is still available in Topaz, so in case you have a Windows NT^® 4.0 domain environment that you want to go and query, you can still do so.

When it goes out and queries your users, it's going to include all the user groups that those users are members of. So it will go out and query not just the user, but when it returns the user data, it reports all the group names that user is a member of. All those groups are applicable, and that's useful for software distribution. You can specify all users of the SMS Admins global group, if you wish. So it reports the container, such as users. It will report the DMS domain name, Topazdom.wally.microsoft.com, all the group membership: domain users, domain admins, administrators, or Terminal Server users. Whatever groups you're a member of, it will return those, as well as your Windows NT domain name — the NetBIOS domain name that was queried from your Active Directory domain.

No additional network traffic is generated here, other than the normal traffic to find your Active Directory, the domain controller, and pull the data. If Topaz happens to be installed on top of a domain controller, then there would be no network traffic generated for User Discovery, because of the fact that you're discovering from the local DC. The agent name is SMS AD User Discovery Agent.

On the next slide (slide 14), we see a screen shot of Active Directory User Discovery. So here I'm enabling that method. What you'll see is LDAP, again, for the local path, so I'm going to the local domain. However, if you look at the first entry there, it says CN=Users. In this environment I went to a specific container called the Users container. So I'm not querying the entire Active Directory domain, I'm querying from the Users container, and then on down, if it has any objects inside of it. You see this is recursive, so if I had any other containers, other objects there, I would query them as well. So I'm looking at a specific container. This is just an additional example.

The next screen shot (slide 15) will show you the results of Active Directory User Discovery. The Active Directory User Discovery Data screen shot shows you a resource that was discovered. In this case, it's SMSAdmin. It shows you the Resource class as User, and it shows some of the information that's returned. I scrolled down a bit so you could see the domain name and group name information. At the top, it would say Active Directory User Discovery Agent, and the local site. But you see the name is SMSAdmin, the operating system, and it goes down to the UniqueUserName, which is TOPAZDOM, my domain name, and SMSAdmin. It shows you the container as users. It shows you the domain name, Topazdom.wally.microsoft, group names, administrators, domain administrators, or domain admins. This one doesn't show domain users, which, by default, the SMSService account is a member of, and that's been fixed in a later release. The build I'm currently running, after the screen shots were made, does return all the group names, then the user name and the Windows NT domain. So you get a lot of good information returned, including those group names for which you can do your targeting for software distribution. So that's Active Directory User Discovery. Now we'll go on to Active Directory System Group Discovery.

The next slide (slide 16) is Active Directory System Group Discovery. I've kind of termed it as "Heartbeat Discovery for assigned system resources." What that means is that as you run this discovery method, it's only going to generate discovery data for system resources in the Active Directory that are specifically assigned to your SMS site. So if you have computers in your Active Directory that are not assigned to your SMS site, they're in a different Active Directory site by other site boundaries, they will not be discovered in System Group Discovery. Only resources assigned to your site and that are in the Active Directory will be discovered here. So it's very useful for cutting down the amount of traffic that's generated, because you're not querying everybody. You're querying more specific information.

This is only available for primary sites; so if you have a secondary site that's running Topaz, and you look at your discovery methods, you won't see Active Directory System Group Discovery. However, what you do is at the parent site of that child secondary site, when you do Active Directory System Group Discovery, it will discover resources for the secondary site automatically, and then push those resources that are assigned to the secondary site down to the secondary site, as we normally would.

This discovery method, System Group Discovery, does not contact the individual systems as Active Directory System Discovery does. The reason for that is we already know what the Active Directory site name is, because we queried that from System Discovery. So we know what the site name is, and that's all we're going to system for, is site name and some other computer resource information. Now what we're doing is going to the Active Directory and we're finding additional information about that resource that's assigned to your site. This information would include your system container, such as domain controllers or computers; your DNS domain name; your system group names, such as domain controllers or domain computers — so it returns the groups that the resource is a member of, as well as the container that the resource is assigned to. It also returns your organizational unit information. It does not retrieve the Active Directory site name, because that's done by System Discovery, and we're not doing System Discovery. So it's not going out and querying the individual client.

The agent name for this resource is called SMS AD System Update Agent. The SMS AD System Update Agent is going to be returned here, and it's going to retrieve from what you had before. It's going to add to your System Discovery. It's going to add your organizational unit information, your container information, as well as the system group information. I didn't create a screen shot for this for you, because all it's doing is adding a couple of new fields to your existing screen shot, the existing data.

We'll move on to the next topic, which is Active Directory targeting (slide 17). After you've used these three Active Discovery methods — System, User, and System Group Discovery — you now have information that you've discovered from your Active Directory. So you now have a lot of information pulled in SMS collections. And you have collections for all systems, all users, and so on. You also, in Topaz, have collections for Windows 2000 clients, as well as Windows XP clients, and so on. So you have some updated collections inside Topaz.

Now that you have this Active Directory information, you can use that information for targeting to your appropriate environment. So now you can coordinate or integrate the Active Directory information you've discovered with your SMS inventory or whatever collections you want to create. So for targeting computers, Active Directory System Discovery, and System Group Discovery, we'll gather your domain name, your organizational unit, your Active Directory site, your security groups that your computers are members of, in your appropriate containers. So you have all that information you can use for targeting. That is available for targeting through software distribution.

For targeting users, Active Directory User Discovery gathers the domain name, the organizational unit, and the security group that users are members of. Again, you could say "all users in the Sales group" or "all users that are in the Marketing organizational unit." When we talk about groups, we include global groups, universal groups, nested groups, non-security groups, or distribution groups, which are supported as well.

Basically, the Active Directory Discovery methods gave you everything you need to discover from the Active Directory. Now it's just a matter of you utilizing that information, tying it together with hardware/software inventory if you choose to do so, and then using that information for targeting of your software distribution.

On the next slide (slide 18), we'll talk about some of the benefits of using the Active Directory information for targeting. The benefits are that any of these properties can be used to query and generate collections. You can look at the examples down at the bottom of the slide. I want to target an application, a program, to all users in the Finance organization unit that are also members of the Remote User global group, so you're tying Active Directory information together. There you're just looking at purely Active Directory information.

Next we try Active Directory information along with SMS hardware inventory. So we're looking at all computers in the Servers organizational unit, that are in the Redmond SMS site, that are in the SMS Servers Universal Group, and that have at least 512 MB of RAM. There you have SMS information, that is, the Redmond site. You have Active Directory information, the Servers organizational unit and the SMS Servers Universal Group; and hardware inventory information is the 512 MB of RAM. Again, you can use this information independently, if you want to, or standalone, because it's just going to all users in the Finance organizational unit, or you can integrate it with the SMS hardware inventory, most likely for more complex targeting.

On the next slide (slide 19) I have a screen shot of a query that ties some of this information together. Some of you may not like looking at query language, but it's not bad. This example is a query I created with SMS Servers, and it's looking for ADSite name = Redmond, so everybody in the Redmond Active Directory site. The system group name = SMS servers, and the system OU name = servers, so all servers. There's going to be Server computer, that's an SMS server, and you're inside the Active Directory site name called Redmond. Now I didn't have hardware inventory enabled at this point in time, so I don't have a link there to show you, and I have 512 MB of RAM. I apologize for not getting that in there, but you certainly can do that. All this information was from Active Directory System Discovery and Active Directory System Group Discovery. However, you certainly could integrate it with your hardware inventory data. I apologize for not having a screen shot that does that for you.

That's Active Directory Discovery and targeting. Now we'll move on to a new feature of Topaz, and that is the Advanced Security model (slide 20).

You're all familiar with SMS 2.0 and the security system that SMS 2.0 provides. SMS 2.0 has some pretty decent security. But to achieve that security, it creates a lot of accounts.

Some of you, and probably most of you, are aware of SMS 1.2, and you've utilized it, so you're aware of the security model it had. In SMS 1.2 it had a fairly basic security model, in that it was a single account that basically did everything. Your SMSService account was the account that was used primarily for everything inside SMS 1.2. That wasn't necessarily good, because of the fact that the SMSService account was a domain admin, so it's not really desirable to have an administrator account being used across the wired access resources across your network. That leaves more opportunities for that account to be hacked or compromised, because it's a domain administrator account. Then if you do compromise that account, there are vulnerabilities to other resources that you probably shouldn't be vulnerable.

When we went from SMS 1.2 to SMS 2.0, the SMS 2.0 model was to improve security; we decided to generate multiple SMS accounts. So we created multiple SMS accounts, and each of those accounts had a specific purpose. The purpose of that account was to do a specific function. Generally, not always, but generally, when we were going across the wire, we were not using the SMSService account. There are a couple cases when we do, and you can always override that by creating an additional account to use in place of the SMSService account, so you have the capability to not use a domain administrator account across the wire at all.

A lot of the time, the account used to transfer data across the wire was a domain user account, so there were no special capabilities at all, nothing that a standard user wouldn't have. So when transferring data from a client to a CAP, it was primarily in a Windows NT/Windows 2000/Windows XP environment, and it was a domain user account. When the client access point was forwarding data that it received from the clients up to the site server, it was a domain user account that was used to transfer that data; so it was an administrative account.

Some people, however, think we went a little too far with SMS 2.0 security, in that we created a few too many accounts. So we're trying to accommodate you in the Topaz environment by creating a new security environment called Topaz Advanced Security. This environment does require Active Directory. So for those of you who want to upgrade to Topaz and who are not running Active Directory, you can still certainly use Topaz, but you'll have the same security model, as far as accounts go, that you had in SMS 2.0. In Topaz, that's called the Standard Security model, so there's basically no change there. There have been a few things that have been modified, enhancements to the product in that area, but for the most part it's basically the same. Standard Security in Topaz is essentially the same as SMS 2.0 security, with the multiple accounts.

If you do choose to use the Advanced Security model in Topaz, that gives you, the administrator, control of all the accounts of the domain, because of the fact that the Advanced Security model is not going to create additional accounts for SMS. This is because you're not creating additional accounts in SMS. As you know, some of those accounts that we create in SMS are accounts that you are not supposed to administer as an administrator. You're supposed to leave the account alone. Let SMS create the account. Let SMS modify the account. Let SMS change the password, if it needs to be changed, and so on. So there are some accounts that you are hands off on. A lot of administrators didn't like that. In the Advanced Security model, you don't have any additional SMS accounts created, so you do have control over all the accounts that you have, because SMS isn't forcing any accounts on you.

The Topaz Advanced Security model can be configured during SMS setup or after SMS setup. When you're going through the SMS setup process for Topaz, you'll have a selection or an option to install it in the Advanced Security mode. If you do so, then we install and we don't create any additional accounts for SMS in the Topaz model. However, if you're upgrading from SMS 2.0 to Topaz and you want to keep your existing security model for a while, and now you upgrade to Active Directory, you can always convert later on, or after the fact, from Standard Security to Advanced Security. However, it's a one-way conversion. After you've converted to Advanced Security, you can't revert back to Standard Security. So there is no ability to say, "I really don't like this ‘no account' thing. I want to go back to the way it used to be." You can't convert back. After you've gone to Advanced Security, you're there. You would have to deinstall and then reinstall to get you back to Standard Security.

Next we'll talk about the implementation for the Advanced Security model. On the next slide (slide 21), we'll talk about implementations. The first unique issue is no additional SMS accounts are created in the Advanced Security model. Now, I need to qualify that: as of today, we do create one account, and we're trying to figure out how to get rid of that one account that's created. If I remember correctly, it's an account that's required for access of a management point or a server locator point to new site systems in Topaz, to access the SQL Server. I believe that was the account. I've been talking to one of the program managers about it; he said they're working very hard to work around the fact that that account is created, so try to get rid of that. So right now, there does happen to be one account that's created, but the goal is to have no additional SMS accounts created.

We do create three security groups in an Advanced Security model. Actually, these three security groups are also created in the Standard Security model, so the three groups are going to be created, regardless. These three groups are called the Site Server Access Group, the Site Address Access Group, and the Database Access Group. Now, the Site Server Access Group is used for remote site systems — being CAPs, distribution points, or whatever type of site system you have — that need to access these site servers. So, your database server and your client access point need to access the site server.

In the Standard Security mode, that's the SMSServer_sitecode account that's used, we're creating a security group. Right now it's called the SMS_SiteSystemtoSiteServerConnection_sitecode group, and you place whatever accounts you want to use in that group.

We're no longer using user accounts, but instead we're using computer accounts. What you would do is make sure that your site system, the CAP account, the CAP computer name, or the SQL Server computer name is a member of that group, and SMS or Topaz will do that for you automatically, when you create that site system.

The next group is the Site Address Access Group, which is the group used to allow a child site to connect up to a parent site's SMS_siteshare, the appropriate folder being SMS\Inboxes\Despooler.box\Receive to transfer data from a child site to a parent site, or transfer data from a parent site back down to a child site. That's the group that you would use to enter whatever accounts you would transfer data between SMS sites. That's your site addresses. So when you create a site address in Topaz, if you create an account in Advanced mode, you would use your machine account again. You use the child site server Computer Account, and place that in that group, so you have appropriate permissions.

The third one is your database access group. This is the account for which we're hoping to be able to move the one account that is created for access of a management point and server locator point to access the SQL Server computer. Again, we're not using the user accounts, but instead computer accounts. So in the Active Directory environment, we create computer accounts for each computer, and you see that as your computer name with a dollar sign ($), as an account. Your site server, when it talks to remote resources, connects using the site server name $ account. When the site system connects to the site server, it uses the site system $ account to talk and communicate. So those are trusted accounts, because they're computer accounts, to which Windows 2000 or Windows XP maintains the passwords. In a .NET Server environment, they are maintaining the passwords on the computer accounts themselves.

What you need to make sure of is that your site server computer account is an administrator on the remote site system. So when you want to add a remote client access point, you need to make sure that your SMS site server's computer account is a local administrator on that remote CAP computer, so that SMS can create the appropriate data necessary on that CAP computer: the CAP share and the SMS Executive service.

When you add that additional site system, as long as the site server is an administrator remotely on that box, the site server will automatically grant the appropriate rights to that site server computer account, where it's necessary. So basically, it's going to add that account to the SMS Site Server Access Group, which has the appropriate security rights to the SMS folders necessary to transfer data from the CAP or the SQL Server computer to the site server. All that data will be done for you automatically. The thing you have to do is make sure that your site server account is a valid administrator on any computer you want to make a site system, and then SMS handles the rest.

On the next slide (slide 22), I have a screen shot of enabling the Advanced Security model. This is the screen during SMS setup. During SMS setup, when we're asking for your security account information for your SMSService account, we now have two check boxes. One check box is for the Standard Security Mode, and then the other one is for the Advanced Security Mode.

The screen shot shows you that by default I'm running the Standard Security model. With the Standard Security model, it does show me the SMSService account name; in my case it's TOPAZDOM/SMSService, and the appropriate password. If I were to select the check box for Advanced Security Mode, then my service account name is blanked out. Those fields are unavailable to me, because we're not using accounts. What the SMSService is using instead is the LocalSystem account. So we use the LocalSystem account for all the SMS services, and then the computer account to transfer data across the wire.

If you choose to go with the Standard Security mode during setup, you can then later move to the Advanced Security mode by simply going to your site properties dialog box. You go to your SMS Administrator Console; you expand out site database, site hierarchy, select your sitecode, go to the Properties for your site code, and then at the bottom of that Properties dialog box, you have a new button there, which is for Advanced Security. It actually says Set Security Mode. When you choose Set Security Mode, we put up a message box that says, "You're about to convert from Standard to Advanced Security. This is a nonreversible operation. Are you sure you want to do so?" If you chose to do so, then we do the appropriate work of converting your site from Standard Security to Advanced Security.

The next topic is Active Directory schema changes (slide 23). So, what changes are made to the Active Directory schema, as far as Topaz?

Topaz does have the capabilities of extending your Active Directory schema. This is not a requirement for Topaz. However, it is a capability, and it is very useful if you extend your Active Directory schema for Topaz.

The Active Directory schema can be extended by SMS setup. During SMS setup for Topaz, you'll have a new option during setup that will ask you, "Do you want to extend your Active Directory schema?" We'll talk about, on the next slide, the reasons for the Active Directory schema extensions. Basically it's for clients to find systems when they need systems, management points, and server locator points.

If you chose to, during setup, have your Active Directory schema extended, then SMS setup will attempt to do that schema extension. That requires that the logged-on user must be a member of your schema admin security group. So the schema admin security group must include the logged-on user. If that is the case, and by default the administrator is the only member of the schema admin security group, if you logged on as an administrator, you may have the capabilities to extend your schema.

The second requirement is that the schema extensions must be enabled on the domain controller. So on the domain controller, you have to have schema extensions enabled. You need to have schema extensions enabled. That's done by using the Active Directory schema MMC snap-in. You'd launch the MMC console and then add the Active Directory schema console. If you do that, then you're allowed to select the check box that says, "The schema may be modified on this computer," and that will give you the second capability. So your logged on user must be a schema admin, and the computer that you're sitting at must allow schema modifications. If so, SMS can do your schema extensions during setup.

If that's not the case, or you choose not to do the schema extension during setup, you can extend your schema post-setup. After setup, you have the capability of extending your schema with a utility provided with Topaz. There's a utility called Extend AD Schema, or Extadsch.exe. You can use that utility from the SMS\Bin\I386 directory, and that will do the schema extensions for you. That's what the requirements are.

On the next slide (slide 24) we talk about the Active Directory schema extensions themselves. We don't do a whole lot in the Active Directory schema, but Topaz does add a container. In the System container in Active Directory, we do create a System Management container, so we create a System Management container in the System container, and inside the System Management container we create a couple more objects. The first thing we would create would be an object called SMS-Site-sitecode. This is the SMS site that's registered in this Active Directory environment.

Then we will create containers and objects for management points and server locator points when you add a management point or a server locator point to your SMS environment. So in your Topaz environment, we'll add an object for server locator point and a management point. You see that in the middle bullets in your slide, where it says, "System Management container," and then SMS-Site-sitecode is your Active Directory site object. Then there's SMS-SLP; SLP is server locator point, -sitecode, and the name of the server locator point. The same thing for management point: SMS-MP, for management point, -sitecode, and the management point name. So we'll create those objects in the Active Directory schema when you have extended the schema, and then when you publish a server locator point or management point to your environment.

Hierarchy Manager and Site Component Manager will be responsible for creating these objects as appropriate. So as you need to publish your Active Directory site information there, Hierarchy Manager enters the SMS site, the sitecode information, and Site Component Manager would publish the server locator point information and the management point information. Clients will then retrieve this data from the Active Directory, when required. So what we're looking for is server locator points and management points.

On the next slide (slide 25) I'll talk about whether or not these are required. Is the schema extension required in an Active Directory environment for Topaz? It is not. You can get by without extending your schema. So if you have very rigid procedures in your environment where you can't allow schema extensions, then Topaz can still function in an Active Directory environment without extending your schema. If you do, however, you're not going to lose functionality, but it's going to be less flexible or less automated for the administrator. So the administrator may have to perform some manual steps to provide the same functionality that you would have achieved by performing these extensions automatically.

The extensions are primarily for the SMS desktop clients to find a server locator point. If you remember from the session a couple of months ago on Topaz, the server locator point is used to find a client access point. In Topaz, we're not using logon points to initiate discovery and installation. We're going to do so without logon points. You need to find a CAP, because that's how you're going to install a client. The client is going to go to the Active Directory and look for a server locator point. The server locator point then will tell it what CAP to use for its site, because it will know what the Active Directory site name is.

If you haven't extended your schema, your server locator point is not in the Active Directory, and then as an administrator, when you run the utility called Capinst.exe to install a desktop client, you'll have to specify the path to the server locator point. You would do something like capinst /slp=, and the computer name for your server locator point. Then the client would query that server locator point using HTTP to find a client access point for its site to perform the installation. If you don't have the extensions there, it's a manual process for the administrator to either modify logon scripts to specify the /slp switch, or a command-line switch doing a batch file, or whatever else to specify where the SLP is.

SMS mobile clients, or the new remote client for Topaz, use the schema extensions to find a management point. They're looking to find a management point for your Active Directory environment so they know where to find resources. They need a management point to download policies. They need a management point to be able to find resources, such as a content server or a distribution point, to download packages.

If you have not extended your schema, then when you create a management point, if Active Directory schema extensions aren't there, in other words the management point can't publish itself in the Active Directory, then your management point will register itself with your WINS environment. So you would need to have WINS or some other form of NetBIOS name resolution to register that management point. You see at the bottom in parenthesis how the management point registers itself with WINS, with MP_sitecode, and then your 16th character is a 1A, so MP_sitecode with a <1A> attribute. If a mobile client can't find a management point in the Active Directory, it will go out there and query through NetBIOS to try and find one through WINS.

On the next slide (slide 26) I have a screen shot that shows you the Active Directory schema extensions. I apologize, it's kind of small, but you can see I'm selected or I'm highlighted on the System Management container inside the System container. You can see the three objects I have. I have my SMS site and then TPZ, which is my site code. My SMS object is there, so the clients can find out what site they're a member of, as far as SMS. Then I have the SMS-MP-TPZ, my site code, and then my computer name was TOPAZPDC. My SLP name is TOPAZPDC. So I was using a single computer for everything. But there you can see what will be registered. If you have multiple management points, you can have multiple entries there.

On the next slide (slide 27), we'll finish up with SMS client mobile roaming. I'll talk about this more in another WebCast; I believe it's in January that we have a session scheduled on the SMS mobile client, or the new client platform. On the next slide I want to talk about client roaming. If you can think back to the screen shot that you just saw, when a mobile client is trying to find resource information, it goes to the Active Directory to find a management point for the local site. When I install a mobile client, I specify what site it is a member of. I then go to the Active Directory and find a management point for my site, so I can download policies or SMS site settings for my client.

When that client roams to a new SMS site — so I go from my existing SMS site, I disconnect my laptop, go to some other SMS site, which maybe is in my hierarchy or maybe not, it depends on whether you have global roaming or non-global roaming, regional roaming. We'll talk about that during the presentation on mobile clients. We'll query the Active Directory to find a management point for the local site at which I'm residing. That will allow me to find distribution points at the local site that I can try and download content from. If I roam to a remote site and I receive an advertisement that says, "Upgrade to Office XP," I don't want to run Office XP remotely from the site I originally came from, because Office XP is kind of a big package to cruise over this possibly very slow link. Or maybe I'm a laptop user at home dialing in.

What you want to do is have a management point pointing to a local distribution point that might have that Office XP program distributed to it as well. If that's the case, then I can run that advertised program from my local DP on the local sites. So I have local traffic, as opposed to going over remote link, which may be a slower link to my home site. We'll talk about that in more detail in January, when we talk about the mobile client, and we'll talk about roaming for the mobile client.

We'll also get you more information on this in next month's presentation, in just a couple of weeks, which is on software distribution in Topaz (http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com/servicedesks/webcasts/wc121101/wcblurb121101.asp). We'll talk about some of the new things there. So I'll get you more information on mobile client roaming and accessing remote distribution points then. I believe that is next month. In the next couple of WebCasts, we'll have more information for you there. From now through however long necessary, each month for our WebCast, we're going to have a topic specific to Topaz.

My last slide (slide 28) is just a session summary, so we'll just wrap this up and kick it over to Jason for the Q&A portion.

One of the key features of Topaz is its Active Directory integration. As customers, you wanted to be able to integrate with Active Directory more fully than in SMS 2.0. We're providing that to you, so you have numerous, different ways to integrate with the Active Directory. One of those ways is through AD site boundaries — the ability to take your Active Directory site names, which include all the appropriate subnets assigned to that site, and use those as your SMS site boundaries, in place of or in addition to IP subnets — the big advantage being you're maintaining your IP subnets in one location, not multiple locations. Active Directory sites give you more flexibility and granularity on what you can do with your IP subnets, as far as subnetting or supernetting.

Active Directory Discovery, the three different discovery methods, allow you to discover system resources and user resources, including the user groups that the users are members of, for Active Directory targeting. So you can target to computers specifically out of the organizational unit or specific security groups, or specific users and containers and different organizational units, or in specific security groups. So you have a lot of capabilities, with the Active Directory Discovery, that lead into software distribution targeting. You can also coordinate or integrate your Active Directory Discovery information with SMS hardware inventory for more complete targeting through SMS.

We now have a new Advanced Security model for you. Active Directory integration allows you to convert your Topaz site into an Advanced Security model, which would give you ease of account administration. You don't have to maintain SMS accounts. You don't have to worry about passwords expiring, or the inability to change passwords or account lockouts or anything else, because of the fact that we don't have accounts. We're using computer accounts — which you're not creating, they are there already — and the Local System accounts to run our services and to do our communication. So there are great new capabilities there. You can choose to implement security after the fact, if you want to.

Then you have schema extensions, which are optional. They give you ease of administration in your environment for working with your clients, whether it's your desktop clients or your mobile clients, in looking for resources for their local site — for installing or downloading policies, or for local resources.

That's it for Active Directory integration. I'll kick it back over to Jason, and we'll do our Q&A session.

Jason Bennet: Thanks for the presentation, Wally. Just a couple of quick notes before we move on to the Q&A portion of the Support WebCast.

The Q&A portion of the Support WebCast is intended to encourage further discussion of the Support WebCast topic. One-on-one product support issues are outside the scope of the Support WebCasts, so if you need technical assistance, you should submit an incident on the Web, or call Microsoft Product Support Services and speak to a Support Professional.

I think the first one we should go through, that's on everyone's mind, if they have not been to one of the previous WebCasts, that is: When is Topaz going to be available? What's the beta looking like? I know there are several questions asking about MSDN^® subscribers. If there's anything you can comment on about that — I know we don't typically give out product release information, but if you have a basic timeframe for that, Wally, that would be great.

Wally: If you remember, I think it was in the September presentation, we talked about Topaz. In my introduction we talked about the beta coming out in October. Obviously, that has not happened. The reason for that is that when we were planning our October release for the beta, it was going to be a very limited release, and not full functionality. However, we've decided to add a few new features to Topaz, and have one beta release that's full featured for everybody who can get access to it. For example, the Advanced Security features would have not been in the October release, but the Advanced Security stuff is in now. We also have MSI Package Elevation, which we'll talk about in next month's session. That's been added. Delta replications to distribution points have been added. So there have been a few new things that have been added to Topaz, and with all these new things we were planning to add, we decided to delay the beta, so that we could have a full-featured beta for everybody.

The beta timeframe now is first quarter of next year. First quarter of next year, we'll have our beta out. We'll have announcements on the SMS Web site, http://www.microsoft.com/smsmgmt/, on when you can register yourself for that beta.

Microsoft field personnel (Microsoft MCS, SEs, TAMs, et cetera) can nominate customers for the beta right now. If you're a customer, talk to your Microsoft field person about being nominated. There's a location where they can nominate people for the upcoming beta, but the beta is due the first quarter of the year. We'll have a full-featured beta, and then anybody who is not working with Microsoft, if they just want it on their own, they can go to the http://www.microsoft.com/smsmgmt/ Web site and look for data there. The EAP program has started, so the early adopters have been getting some different builds of Topaz. They're working with it right now. But the beta program for general release is not out yet; it's scheduled for the first quarter of next year.

Jason: The first question I have in the list is someone talking about rolling out SMS in February or March. They'd like to plan their SMS 2.0 rollout, with the intent of moving shortly thereafter to Topaz: Any tips, tricks, recommendations, or gotchas to avoid on that?

Wally: We are going to have a WebCast, probably in February, on preparing for Topaz — taking your existing environment, whether it's SMS 1.2 or SMS 2.0, and getting you to the point where you can successfully upgrade to Topaz — and the things to get rid of.

Just a couple of quick things: the main thing is, if you're going to be Active Directory enabled, get there right now. Make sure your SMS 2.0 environment is at least at Service Pack 2, if not Service Pack 3. Service Pack 4 will be coming out fairly soon. I think that's scheduled for the first quarter of next year as well, so you may want to go to that. But it has to be at least Service Pack 2. You need to look at the things that Topaz will not be supporting that SMS 2.0 does support. If you go back to September's WebCast (http://support.microsoft.com/servicedesks/webcasts/wc090601/wcblurb090601.asp; slide 23), I think that's on the last slide or the next to last slide, I had a list of things that Topaz will not be supporting. Make sure you don't plan on utilizing those features with Topaz, because there are some things we are dropping, like NetWare support, like Windows 95 or earlier version support, Windows 95 support, support for SQL Server 6.5, a few things like that. I also think we may drop SQL Server 7.0 support in Topaz, but I don't remember. So look at the presentation I did in September, and then look for a WebCast coming up. We already have January's topic scheduled, so most likely it will be in February.

Jason: Will Topaz work in Active Directory compatibility mode?

Wally: Yes. You don't have to be in native mode, so you can be in a mixed mode or compatibility mode, if you want to call it that, yes. It will work in a Windows NT 4.0 environment, as far as the domain structure.

Jason: I'm going to apologize in advance, because I'm taking these questions as we were going through the presentation. So you might have already answered these: Does Microsoft have any ideas of integrating Terminal Server into SMS for remote control?

Wally: I didn't talk about Remote Control in this presentation. For Terminal Server, we are going to have the ability in Topaz to allow you to launch Terminal Server as a menu item. As you look at a collection, you look at a resource, right-click, and you have the context menu of resources. You want to start Remote Tools, and you have the ability to launch Terminal Services there. We are still going to maintain the existing remote control technology for our earlier-version clients, or our desktop clients. Then, if you have Windows XP clients, you'll be able to use Remote Assistance for remote control of the Windows XP clients, as well as for kicking off Terminal Services, if you want to.

Jason: We've heard through the MCPs that the ADSync tool is currently not very reliable. Do you have any comments on that, and are there any plans to further refine or improve this tool so it's useable pre-Topaz?

Wally: I have not heard that the utility is not reliable. However, if you read the documentation for the utility, we do state that it's a sample utility. You may not be able to use it the way it is. And we give you the source code for you to modify that tool to make it function any way you want it to function. I've heard of no plans for updating it. It doesn't mean we aren't, because I'm not involved with everything going on. But I have not heard of any plans for updating it; it was a quick fix for you to get some capabilities, and we intended to give you the source code, so you could have the base features already done, and then you could modify it for how you needed to get your own specific data out. But I have not heard of any plans to update that utility.

Jason: Will Topaz support Windows XP? Does SMS 2.0 Service Pack 3 support Windows XP?

Wally: Topaz definitely supports Windows XP. Not a problem at all. It will support .NET Server as well, as a platform.

SMS 2.0 SP3 does support Windows XP; however, there are a few issues with that. Service Pack 4 will have more compatibility. If you're in the Windows JDP program, there are some specific hotfixes you can get for support of Windows XP environments for SMS 2.0. It does support Windows XP clients, but there are few gotchas with it. I believe we have up on our Web site, http://www.microsoft.com/smsmgmt/, a link right to new feature support, and it does talk about some of the issues with Windows XP. So if you go up to the Web site, you'll find a direct statement on our Windows XP support for SMS 2.0.

Jason: Windows 2000 has a default first site for IP addresses not otherwise assigned. Will Topaz support this, and allow a default SMS site?

Wally: Your default first site name is a default site that you have in Active Directory. When you install Topaz, that will be your default Active Directory site, if that's what your site server is a member of. Whatever Active Directory site your site server is a member of, that will be your initial site boundary, along with the IP subnet that your site server is a member of. Both those will be defaults for you.

You can use that, it's already there, if your site server is a member of that site name. If not, you can add that as a site name, or whatever other site name you want to use. That's an option that you have, to specify what site names you want to use for Topaz.

Jason: Will Topaz include a CD-based client installation option that I can use on computers located on 56-Kbps circuits, or will the client software need to be installed only through the network?

Wally: Topaz will have the capability to install clients in an offline mode. In other words, not going over the network. In this environment, where we have 56-Kpbs clients, you probably want to use the new mobile client platform, which can be installed through .msi. It's an .msi script and utility you can just drop down to the clients. It's currently about 3.5 MB in size, or something like that. You can put it on a CD, and then install directly through Windows Installer. In the desktop client, we're coming up with procedures for installing desktop clients, either preinstalled or for the local CD as well. So yes, you will have capabilities, certainly more capabilities than you have with SMS 2.0, for installing clients in an offline mode.

Jason: Is an Active Directory site the same thing as an organizational unit?

Wally: No, they are different things. An organizational unit would be a container or a portion of an Active Directory site. An Active Directory site is an object that specifies what your boundaries are for your Active Directory environment.

Jason: Does Topaz require increased hardware resources? Can Topaz run on an existing SMS 2.0 site server?

Wally: We haven't done all of our scalability testing to be able to tell you exactly what we're looking at for hardware, but yes, you can run Topaz on the exact same hardware you have for SMS 2.0. I have it right here on a laptop, which is a Pentium II 366 MHz. It has 256 MB of RAM. Now granted, it's my own small test site, but it certainly does function fine on that.

In a production environment, you're still going to want to have some pretty beefy hardware, just like you have today for SMS 2.0, in that you're maybe going to want to have dual processors, 500 MB or more RAM, and lots of disk space. We haven't published specific hardware requirements yet, because we haven't gone through all the scalability testing. Certainly we'll want you to have more advanced hardware, just because of the increase in hardware capabilities over the years since SMS 2.0 first came out.

Jason: Will remote control use Active Directory-integrated DNS instead of WINS?

Wally: It depends upon what remote control you're using. If you're using the SMS remote control, the same as you have right now for SMS 2.0, it's going to be looking at NetBIOS name resolution or WINS to resolve that computer name. However, you also still have the ability to go out and find any discovery method, any way of finding that resource, but we are integrating further with Active Directory as well as DNS in Topaz. We still have some WINS requirements, as we talked about, for management points, as well as for other things in Topaz. But the default remote control product still is the same thing you have with SMS 2.0, which does require some NetBIOS name resolution.

Jason: Discovery info showed TPZ as SMS site. Is the three-character limit still a factor in Topaz?

Wally: Yes, it is. It's still a three-character site code in Topaz. TPZ was my site code. Yes, we are still bound by the three-character site code limitations.

Jason: You mentioned on one of the slides installing Topaz on the domain controller; the customer is asking: We thought that Microsoft had recommended not using a domain controller as an application server. Can you comment on that?

Wally: Sure. Our product statement is that, in most environments, it's more advantageous for you to install SMS on a member server, and not a domain controller. That gives you better security. It lets you have local accounts versus domain accounts. It doesn't impact your domain controller at all. In Topaz, we'd certainly expect the same thing. We would expect you to be installing Topaz on member servers, as opposed to domain controllers. That way you have no impact at all on your domain controllers, other than what we might publish in the Active Directory, for querying the Active Directory for discovery methods, or for management points, server locator points, and so on, but not for utilizing your domain controllers at all. Absolutely, install a member server, if that's what you prefer. We do highly recommend that. It's better for security as well. It's just that I do everything in a laptop environment for the presentation, so I always use a DC, because you have to have one. You have to have domain context. So I install things on a domain controller, but we do recommend member service.

Jason: The next question is regarding nested groups. I don't know if you discussed this in your presentation, but they just want some comments. I didn't get a clear indication of what slides they're referring to. Can you make any comments about nested groups?

Wally: Yes, there was a slide (slide 17) that did mention that, we're talking about the groups for discovery. When we mention groups, I did have something in there that I thought stated that nested groups were supported. So we are supporting nested groups in Topaz. The comment is probably coming from the fact that we don't support nested groups in SMS 2.0 when we're integrating with Active Directory. So we do support nested groups in Topaz, yes.

Jason: Is Windows XP or Windows 2000 required for Topaz, or will it still work with Windows NT 4.0 or Windows 9x?

Wally: Your SMS servers are required to be Windows 2000 or above, so Windows 2000 or .NET Server. We're not going to allow Topaz to install in any Windows NT 4.0 or earlier-version servers. It's all going to be based on Windows 2000 or above. You can certainly have Windows NT 4.0, Windows 98, or Windows Millennium Edition, or whatever you want as clients. You can have those. Not Windows 95, not anything earlier than Windows 95, but Windows 98 and later: Windows XP, Windows 2000, and Windows NT 4.0, as clients. But your site systems all need to be Windows 2000 or .NET Server, based in Topaz.

Jason: Is there a workaround for the primary site limitation?

Wally: I don't know what primary site limitation we're talking about. If it's the three-character site code limitation, no. It's a three-character code. If that's not what you mean, then you're going to have to send a follow-up question, if we have time for it.

The one thing I did mention in my presentation was primary site only was for System Group Discovery. If that's what you're talking about, then no, it is primary sites to Active Directory System Group Discovery, which does include discovering resources for your secondary sites as well, if that is what the reference was to.

Jason: What is our cross-platform support for other LDAP-capable directories, such as iPlanet?

Wally: I have no information on that at all. If it's purely LDAP, then it may work, but I have no knowledge on that at all. We're getting outside what I would know. I don't think we're testing for anything else, other than our Active Directory environment.

Jason: Is Heartbeat Discovery required on primary and secondary sites to update all clients in a master domain model, or just on the primary?

Wally: Heartbeat Discovery is for existing SMS clients to update their discovery data. When we were talking about this System Group Discovery, which I kind of termed Heartbeat Discovery, that's totally separate, and that's purely for finding resources out of the Active Directory. They don't have to be SMS clients. They just have to be assigned to the SMS site for System Group Discovery. However, you would still want to have Heartbeat Discovery for all of your clients, those clients being mobile clients and your desktop clients, so they can refresh their discovery data, and so they don't age out of the database. Yes, you would still want to have Heartbeat Discovery enabled on all SMS sites. If you remember in SP2, we also changed Heartbeat Discovery. That's an interval used by the Windows NT Server discovery agent for updating site System Discovery records. So you most likely do want to keep that enabled.

Jason: Will there be any features added to the remote control functions?

Wally: The standard remote control that you all know and love today with SMS 2.0 is basically going to be the same product. It will have a few performance enhancements to make it work better, give you better performance. But from there most of the advancements or enhancements are going to be by using a remoted system in Windows XP environments, or the ability to launch Terminal Services or something else. There's integration with other remote control-type technologies, yes, but the existing one we have, we're keeping that inside Topaz. There are going to be performance enhancements and other advancements. If you guys want to have a WebCast on that in the future, on remote control and Topaz (which we probably should have, since we have remote systems now), that's something we can talk about as we get in to next year.

Jason: Are there any more network throttling options in Topaz? Is there any documentation on specific scenarios for using network throttling?

Wally: For the network throttling options, there's not a lot, because again, SMS still assumes high-speed connectivity within the site, and then in non-high speed connectivity environments, we're assuming you're running with remote sites. In the remote sites scenario, you can throttle your traffic, it's compressed, it's scheduled, and so on.

The advancements in Topaz that I can think of for that environment are we have delta replications to distribution points now, so when you make a change to your package, you change the .ini file, or you add a new MST to your Office XP rollout. You don't have to redistribute the source files out to your DPs — just the updated files are replicated out. And the same thing between sites. Obviously, the mobile client platform totally revolves around providing efficient utilization of bandwidth, so that when you have disconnected bandwidth environments, you're not connected very long to the SMS site, or if you have slower links, we utilize that link as efficiently as possible, the computer itself, as well as the Topaz or SMS client features. So those would be the main areas I can think of, as far as throttling for network traffic.

As far as documentation, I've seen nothing. Unfortunately, the majority of stuff I've seen on network traffic is in one of the training courses I wrote, MOC 828. But there's not a lot else that's been documented for network traffic in SMS 1.2, SMS 2.0, or that I've seen for Topaz.

Jason: I'm going to set a cut off. If you have more comments or if you have more questions, this is not the only Topaz WebCast out there. We're going to be doing more in the future. Make sure to be checking the Support WebCast site, because the schedule is updated, and we schedule about a month out. That's the best way to check to see what's coming up. We typically do an SMS WebCast once a month, if not more. I think there have been a couple months where we've done two in a month. Definitely check back, because there's going to be plenty of opportunity to ask questions on Topaz before it hits the street.

Wally: We do have December already scheduled. That's software distribution. January is scheduled. I don't remember the date, but it is scheduled (http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com/servicedesks/webcasts/wc010802/wcblurb010802.asp). It's on mobile clients. We have not scheduled anything past January. My plan is, as long as you guys have things you want to talk about for Topaz, our SMS session for the month is going to be on Topaz features.

Jason: Can we create accounts ourselves and assign them to the needed roles?

Wally: There are some cases in SMS 2.0 today, or in Topaz, if you're in the Standard Security mode, where you can create accounts and use them for specific purposes. For example, if you don't want to use the SMSService account to install your clients remotely, you can create an SMS remote client installation account, and use that for the purpose of pushing the SMS client software out to your clients. Or, if you don't want to use the SMSService account access and set up domain controllers or set up client access points, or push packages out to distribution points, you can create a site system connection account to do that. Then we'll use that account instead of the SMSService accounts.

There's another account that you can create to install packages on clients, if you don't want to use the logged on user, or if you don't want to use the SMSCliToknAcct&. There are cases where you can create accounts and use them, sender addresses, and there are a few places you can.

There are some cases where you don't have any control over the account. SMS service accounts you do have control over. Other accounts you don't have a lot of control over, and you can't monkey with them, like the client service account or the SMSCliToknAcct& the service account for domain controllers, the SMS Windows NT Logon Discovery agent account. We maintain all those, so you can't specify those.

There are a few command-lines switches you can run so you can specify your accounts, such as /serveraccount or /clinetaccount, for setting up and specifying a specific client connection account or server connection account and password. I talked about those in a WebCast I did, maybe two years ago now, on SMS accounts (http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com/servicedesks/webcasts/wc020300/wcblurb020300.asp). I think I talked about the ability to use the command-line switches for some of the accounts.

Jason: If you use the Standard Security model, can you set how often you want SMS to change the account passwords?

Wally: The model is exactly the same as it is in SMS 2.0, in which you have no control over the passwords, other than the few accounts that you do have the ability to modify passwords for. Basically, the Standard Security model is the same as you have with SMS 2.0, so there are very, very few enhancements to that. Basically it's going to be any bug fixes that need to be made or granularity in security rights within the Administrator Console, but the account security features are going to be basically the same in Topaz for Standard Security. If you want more granularity than that, or you want something outside that, than you're looking at Advanced Security.

Jason: Do you need to be running in native mode to take full advantage of Active Directory integration?

Wally: No. My laptop is in mixed mode, and I can do all the Active Directory integration features in the mixed mode, or compatibility mode, as some people call it. So it's not required at all.

Jason: If we don't have Active Directory implemented yet, can you give us some compelling reasons to deploy Topaz when it comes out? Are there some other additional features we should be looking at?

Wally: Absolutely. Active Directory is just one of the reasons to have Topaz. I suggest you go back to the September WebCast and look at the features of Topaz that I discussed there. But just as a quick run through: first, delta replication, not only between sites, intersite, but intrasite, down to your distribution points — saving huge amounts of network traffic, local or remote traffic, for upgrading packages.

The new client platform: so, if you do have clients that are laptop users and that roam around a lot, or a mobile sales force that doesn't connect very often or very long, then it has a brand new client platform to allow you to work with those clients and not kill the client by downloading everything over the wire, or downloading things in spurts and doing checkpoint restarts, and so on.

Web reporting: the existing Web reporting tool is being integrated in Topaz, so you don't have Crystal Reports anymore. What you have instead is SMS Reporting, which is based off of the existing downloadable SMS Web Reporting tool (http://www.microsoft.com/downloads/release.asp?ReleaseID=28039). Off the top of my head, that's what I can think of for big changes. I want to say there's something else. Maybe the Active Directory integration is what I'm thinking of. But go back to the September WebCast and look at that. I cover all the features there, including the Active Directory stuff as an intro, but also other enhancements to Topaz.

Jason: Topaz doesn't require additional computer accounts. So when we've converted to Topaz, what do we do with the old SMS 2.0 accounts? Do we delete them? Disable them?

Wally: First off, Topaz may require accounts. It's the Advanced Security model that doesn't require specific user accounts for integration, so don't get that confused. If you install Topaz, by default, you're in Standard Security mode; or if you upgrade SMS 2.0 to Topaz, you're in Standard Security mode, which still uses all those same accounts. It's when you convert to Advanced Security that you don't need those accounts, and you use machine accounts, and the Local System account, as far as working with your processes, and so on.

Now, if you do convert or upgrade from Standard Security to Advanced Security, any accounts that SMS created itself will be removed. So when you convert from Standard Security to Advanced Security, we're going to remove all the accounts that we know we created in your domain or in your Active Directory environment, so we will remove those accounts. Any accounts that we're not sure we created, or that we're not sure if you have created, we'll leave those alone, unless you clean those up, which you certainly can do. There won't be any account usage, other than the one that we're trying to get rid of in the Advanced Security models.

Jason: How does the new Advanced Security model affect the use of network attached storage devices, such as non-Windows 2000 servers, as distribution points?

Wally: My answer is I don't know. Because we do require Windows 2000 or later for site systems, if you're using something that's not Windows 2000 or later as a site system, it won't be supported in Topaz. Now I know there are some things in network SANs and other things that we do support in SMS 2.0, so I would assume you'll have some capability for that in Topaz, but I have not looked at that at all. I have not heard that being discussed at all for Topaz, so I honestly don't have an answer for you.

If it's not purely Windows 2000 or above, then my guess is we're not going to support it. I thought those were things you added on to an existing computer, like a Windows NT 4.0 computer, maybe Windows 2000, to give you additional storage, but I'm not very familiar with them at all. I do know we have some support for SANs and other things in SMS 2.0. So I guess if that's the case, we may have that in Topaz, but maybe not, because we are requiring Windows 2000 and later for site systems. So I don't have an answer for you. I apologize.

Jason: Just to be clear, because I don't understand SMS as well as some of these other folks, when you say you're not supporting Windows NT 4.0/Windows 9x, what exactly does that mean? I have one here that says: What about remote control of Windows 9x and Windows NT 4.0 clients? Is there any kind of integration with Windows NT 4.0?

Wally: Yes, and this question probably came in after the other question that we answered. In Topaz, SMS servers need to be Windows 2000 or later. We still support Windows 98 and later, Windows Millennium Edition, Windows NT 4.0, Windows 2000, and Windows XP as clients. So we do support Windows 9x, as long as it's not Windows 95. Topaz will not support Windows 95 clients. We require Windows 98 and later, as far as clients. All the client features are still there for Windows 98 and later version clients, so remote control is there.

When we talk about requiring Windows 2000 and later, we're talking about the site systems that are required to be Windows 2000 and later, such as CAPs, distribution points, management points, reporting points, recovery points, site servers, and everything else that is required to be on Windows 2000. The other thing I mentioned in the presentation related to that was that the Active Directory System Discovery only works on Windows 2000 and Windows XP. That is because you need to have an Active Directory-enabled box. So we're only targeting that for Windows 2000 and Windows XP for System Discovery. All the other discovery methods will still work.

Jason: Do Topaz Active Directory schema extensions work in Active Directory compatibility mode? And is this operation reversible?

Wally: Yes, it does, so we answered that question already. Yes, we do work in compatibility mode. Is it reversible? There's no utility within SMS to say, "Unextend the schema." So, no. It's basically a one-time shot, as far as schema extensions. If you have some other utilities or coding capabilities so that you can delete things from the schema, that's fine. You can delete the objects we create in the Active Directory, so you can delete the System Management container and all the objects there from the Active Directory, after it has been extended and published. So you could delete that, but technically the extensions are still there. You just wouldn't be using them at that point.

Jason: Does Topaz use the replication mechanism and definition of the Active Directory to schedule its priorities for doing its housekeeping work, such as updates, CAPs, distribution of software between SMS sites, and so forth?

Wally: No, it's purely an SMS mechanism, so we'd use Active Directory replication features for replicating accounts through the Active Directory. But as far as working with your site systems, as far as I know, and I'm going to say I'm 98 percent positive on this, we would still need our standard SMS mechanism of Inbox Manager replicating items down to CAPs or distribution manager, putting items on distribution points, and so on. So it's a standard mechanism for the SMS site systems that we're using, as far as updating data.

Jason: When we implement Topaz in our existing production environment, would we want to run it parallel to SMS 2.0 and discover objects in our domain using Active Directory Discovery data only? Are there any problems or limitations with doing it as stated?

Wally: Nothing that I can think of, because you can certainly use and turn on Active Directory Discovery and discovery information from your Active Directory, whether that information came from — again, what you're discovering there is computer accounts, user accounts in Active Directory, and information related to those. So that has nothing to do with SMS 2.0. Now SMS 2.0 can use discovery methods and Topaz can use its discovery methods, and you're fine. The thing you'd want to watch is that you don't have an installation method enabled that would then try and push whatever version software, SMS 2.0 or Topaz client software, out to your environment, and that you didn't want it to be a member of. If you have SMS 2.0 clients in your discovery, you have discovery there in SMS 2.0 and you do discovery in Topaz, you want to make sure you're not pushing the SMS Topaz client base down to your SMS 2.0 clients. So just make sure you don't have your installation methods turned on, like the Windows NT Remote Client Installation Method, or the standard client push method in Topaz, and you should be fine.

Jason: Can you talk about Windows Installer support, .msi support, in Topaz?

Wally: We'll talk about that in next month's session, on software distribution. But as just a review of it, you can use .msi packages as package definition files. You can create packages out of .msi files. The SMS Installer will create native .msi files with the SMS Installer in Topaz. We do allow elevation of privileges through .msi packages with SMS, something that it's easier to do with SMS than outside of SMS. So those are the three things I can think of, off the top of my head, other than the fact that a lot of the new SMS code in Topaz is .msi-based, like setting up a management point, or setting up a mobile client. There are .msi packages that you distribute.

Jason: Can Topaz see the difference between laptops and desktops?

Wally: As far as discovery properties and things like that, we're working on ways to be able to positively identify the difference between a laptop and a desktop so you can choose your platform. We are working on that to make sure there is some way of positively identifying this computer is a laptop, versus that computer is a desktop. Today, I don't think we can, but hopefully by the time Topaz ships, we'll have a solution for you to be able to do that.

Jason: You may have already answered this: Is WINS still necessary to support Topaz with Active Directory?

Wally: Topaz has not removed the requirement for WINS, as far as, in a lot of different cases we still do require NetBIOS name resolution. We'd have to rewrite the entire Topaz product to get rid of all the LanManager and other Windows NT 4.0 calls that did browsing and NetBIOS name resolution. We're not going to take the time to rewrite Topaz to do that. So as of Topaz, you may still have requirements, in certain cases, for NetBIOS name resolution, and those scenarios will be made clear and published. Our general statement, right now, is that yes, Topaz does require NetBIOS name resolution, whether it's WINS or whether it's a LMHOSTS file, or whatever you want, but it does require NetBIOS name resolution.

If you don't have schema extensions and you get rid of WINS, you will need to have some method of NetBIOS name resolution to be able to find your CAPs. Whether that's b-node broadcast or LMHOSTS, you need to have some method of NetBIOS resolution to find the CAP.

Jason: This sounds like it's very similar: Any plans to use DNS for resolution of management points?

Wally: Right now, you use Active Directory. So we only use WINS if you're not publishing your management point names in Active Directory. That doesn't mean you have to be in the Advanced Security model. It just means that you have to extend your Active Directory schema by SMS, and then let us publish the management point names inside the Active Directory. Then we'll be able to retrieve that from the Active Directory.

Now again, management points are only related to the mobile client, and the mobile client, as we talked about in September, and I'll talk about again in January, is only available for Windows 2000 and Windows XP clients. Those are already Active Directory-enabled clients. So it's only for the mobile client. Just publish them to the Active Directory, and you don't need any NetBIOS name resolution at all. Right now, the options are find the management point in Active Directory, or if not, you are using NetBIOS name resolution. I have not heard of anything as to getting rid of that, and just using DNS. Those are the two options right now.

Jason: Are there any plans to resolve the SMS Installer versus Windows Installer issue? Are the .ipf files going away and being replaced with .msi? If I'm going to be using SMS for targeted distributions, what package format do I use? I don't really want to buy another tool to convert all my SMS Installer .ipf files over to .msi.

Wally: You don't have to buy another tool, because there's already a utility that we've released called the Installer Step-up Utility. The Installer Step-up Utility is the tool to take existing SMS Installer packages and convert them into .msi format. You don't have to go out there and buy anything to do that. It's already there. You can go up on the SMS Web site (http://www.microsoft.com/smsmgmt/downloads/installer.asp) and find out how to get that, because I don't know off the top of my head what the procedures are for getting that.

In Topaz, the SMS Installer is going to natively have the ability to write .msi files. The packaging technology that Microsoft wants you to go to is .msi. We want you to go to .msi. The SMS Installer that's available with Topaz will be able to natively write out SMS files, so that's the way you want to go.

Jason: How will the Hierarchy Manager and Site Component Manager update and write to the Active Directory schema?

Wally: If you're talking about specific calls that are being made, I'm not a programmer at all, so I can't tell you the calls. What happens is when they get a request to publish to a site or management point or whatever, a server locator point entry, they make the appropriate calls to the Active Directory to see if the extensions have been made, and then to publish that data in the Active Directory. But not being a programmer, I can't tell you what the specific calls are. If you need that, then I would tell you to go to Product Support Services (PSS) to find out what those calls are. I don't know what they are, because I'm not a developer at all. I'm a purely a trainer.

Jason: I seem to recall a limitation in SMS 2.0 that prevents targeting based on combined attributes of the user and system resources. Does that remain the case with Active Directory capabilities?

Wally: It's really not Active Directory capabilities. It's really whether or not the resource classes are used. As for what I've seen so far in Topaz, the user information is in a different resource class than your system information. It still seems to be the case. I'm talking to the PMs about a way of doing this. I have not found a way to create a query that says a specific user, "Wally, who is sitting on this specific computer, if it has this much disk space or RAM," to be able to tie all this together for targeting for distribution. The computer information, as far as System Discovery, its computer groups, and its organizational unit information, that can be tied to hardware inventory. But the user information tying users to computers, I have not seen that change, from what I've seen so far in Topaz. I'm not saying it's not going to change, but as of today, from what I've seen, that hasn't changed.

Jason: I'll take just a second and ask for feedback regarding these WebCast programs. If you want to send it in, we are very interested in your feedback regarding these programs, particularly topics you would like to see covered, what you think of the presenter, and the information that was presented. You can send us an e-mail through the e-mail alias feedback@microsoft.com. Just make sure that you include "Support WebCasts" in the subject line. That will ensure it gets routed to us.

Wally: I mentioned the SMSService account. It's done by this SMSService account. Your SMSService account is an administrator. So I would assume that we require administrator rights to publish that information in the Active Directory. But because the SMSService account is an administrator, it doesn't have to be a domain admin; it could be a local admin, but it has administrator rights. From there, I know discovery can be done through domain user, but my guess is administrator rights to do that publishing. I would have to verify, but that would be my guess.

Jason: Can you talk about why you're still using WINS and NetBIOS in Topaz?

Wally: I kind of already answered that. To get rid of NetBIOS name resolution, which may mean WINS, in Topaz we'd have to rewrite the entire server base, because Topaz is still quite a bit server-based on SMS 2.0. SMS 2.0 still had NetBIOS name resolution calls in it. So until we rewrite the entire server product to use existing calls, and not the old LanManager calls or Windows NT 4.0 type calls, we're still going to have NetBIOS name resolution requirements, which means WINS.

We're not the only product from Microsoft that requires that, unfortunately. As everybody gets to the point of upgrading all their code to newer technologies and so on, those restrictions will go away. But as of today, and as of Topaz, we're still requiring some sort of NetBIOS name resolution. Again, we'll have some statements out later on, as far as specific scenarios, but plan on that being the case for now.

Jason: You might have already answered this as well: Concerning the EAP program, has anything started yet for Topaz?

Wally: I know some of the early adopters have already been receiving builds and playing with them. If you're an early adopter and you haven't been contacted, then I would talk to your contact in the EAP program about that, because I thought for sure I heard that the early adopters were getting different builds, like build 2149. I think that was the last one that was sent out to EAPs. I thought for sure some builds were being sent out. Maybe it was a small subset of the early adopters, or maybe it's just the Tier 1 people who are receiving that, and not Tier 2 and so on. From there, talk to your EAP representative to find out what the status is.

Jason: Can Topaz work with MOM?

Wally: It certainly can. As of today, the MOM rules have not been updated for Topaz. However, again, because Topaz relies a lot on the same codebase as SMS 2.0, you're going to have a lot of the same status messages and a lot of the same information written to the event log, which is what MOM would use. Certainly you can use MOM to monitor Topaz. We'll come out with an updated application management pack or management pack for Topaz to be used with MOM after Topaz releases. But you can certainly use what you have now to get some basic functionality out of it.

Jason: Did you have a specific purpose for remote forest discovery?

Wally: Purpose for remote forest discovery—being able to find resources that are not in your local forest. So, being able to have multiple forests within an environment, and find resources that are in that environment that may be resources that you want to target as SMS clients, or just to have more asset information in your entire organization. Not just being able to look at the local force, but being able to go to another force within your organization, and have the ability to discover resources from that other forest.

Jason: What are the options for building collections based on Active Directory global security groups, when using SMS 2.0?

Wally: With SMS 2.0, there is the utility that comes with the Adsync utility called ADCallSync, or something like that (see http://www.microsoft.com/smsmgmt/downloads/default.asp), which will automatically build collections for you based off that information. However, you can certainly build your own collections. Honestly, I don't remember off the top of my head what we discover with the Adsync utilities from SMS 2.0, so I can't give you a lot of detail, other than looking at the documentation that comes with that utility, or the source code, if you have those capabilities. But I know there is a utility that comes with that, called Sync or something like that, that will create collections based off the information that you discovered. I remember you do have to create a root collection, and then when you run callsync and get pointed to that root collection, it will create all of its other collections underneath that, based off the Active Directory information. But that's all I'd be able to tell you today.

Jason: Does SMS 2.0 support SQL Server 2000? Does 2.5 support SQL Server 2000?

Wally: SMS 2.0 supports SQL Server 2000 as of Service Pack 2, so if you're not running SMS 2.0 Service Pack 2, you should be. Nobody should be running anything less than Service Pack 2. But as of Service Pack 2, yes, we do support SQL Server 2000.

There is not a product called SMS 2.5. If what you mean by that is Topaz, Topaz certainly does support SQL Server 2000. We have not assigned a version number to Topaz yet. People are always saying "2.5 or 2.1 or 3.0"; those are the common variations, but we have not assigned a version number. So I would ask you all to not give version numbers when you talk to people about Topaz, because you may be totally wrong. Just say "Topaz," and then everybody will know what you're talking about.

Jason: I'm currently running SMS 2.0 via a BackOffice^® 2000 installation. Will this be an upgrade option for us?

Wally: There will be an upgrade for SMS 2.0 up to Topaz. Yes, there will be. I'm not aware of any restrictions, just because it's a BackOffice installation that would prevent that. I'm sure if there are any, they're working on the procedures for that. I have not heard of any. Yes, we will have an upgrade from SMS 2.0 to Topaz.

Jason: Can the client be preinstalled like the previous SMS 2.0 clients?

Wally: Both the mobile client and the desktop client for SMS Topaz can be preinstalled, yes.

Jason: Because SMS would be looking at Active Directory, what happens when workstations are deleted?

Wally: I mentioned, when I talked about the Active Directory System Discovery, that we when we discover a resource from the Active Directory, we connect across the network to that resource to retrieve its Active Directory site name. So if that resource is not physically on the wire, it's been deleted, or it's been disabled or whatever the case is, the computer is physically not there, we won't find them on the wires, so we won't create DDR for it. We only create DDRs for systems that we can retrieve the Active Directory site name for.

As far as systems that you may already have in your discovery data, those will age out automatically when they're not refreshed. We have a Delete Aged Discovery Data task that automatically runs weekly to delete old data from the database; it looks for resources that haven't been refreshed in 90 days and it removes them from the database. You can change that timing if you want to so it is done weekly or monthly, or whatever you want. But eventually that would be removed. If it's new, we won't even discover it. We won't create a DDR for it or discover it for SMS, because we don't have an Active Directory site name for it. If it exists in the database already, and the box has been turned off, and it won't ever be turned back on or decommissioned, then it will eventually be removed by the delete aged discovery data task.

Jason: Could you expand more on SLPs and configuration setup?

Wally: I'll hit that a little bit more in the January presentation. It's going to be on mobile clients, but I'll talk a little bit about desktop clients as well. Basically, an SLP is a new site system role for Topaz. Its entire purpose is to provide to desktop clients a client access point that they can use to install the desktop client. Because of the fact that we're no longer using logon points in Topaz for initiating that discovery process, and that's where in SMS 2.0 clients receive their list of CAPs (from a logon point), we have to have some other method. That method is through a server locator point.

You install the server locator point on a computer in your environment, which is required to be Windows 2000 or above. It is required to have IIS on it, because it's an Internet Web page, a Web application that is used. The client would just make a call to the directory to find the SLP for its site, or use the command-line switch that I mentioned in the presentation, if you're not Active Directory schema enabled. Then the client will find the SLPs. It will then tell it its Active Directory site name and information. Then the SLP will push back to the client a client access point it can use to kick off the installation. The client will then hit the CAP and begin the installation, if you're doing it over the network.

Jason: I think you already answered this, but I want to make sure: What are the minimum rights required to run all of Topaz administration, and is this similar to SMS 2.0?

Wally: The minimum rights to run administration, if you mean inside the SMS Administrator Console, are going to be the same. You're going to have basically the same security rights that are required to run the Administrator Console, which is to have SMS provider capabilities, which is the SMS Admins group, and you need to have access rights to the folder to launch the Administrator Console. You need to have appropriate security rights within the Administrator Console to perform whatever function you want to. That depends on how you want your security set up. Outside of that, if you're talking about other things, like the accounts, then again, it can be Advanced Security, which is no accounts at all. Or if you're in Standard Security, it's basically the same as it is in SMS 2.0.

Jason: Can you point to a specific domain controller to run Active Directory Discovery? If you don't specify one, how does this select its domain controller?

Wally: It uses LDAP calls, if you're going to the local domain. If you specify a forest as your path, it's going to the global catalog, which is a specific server. In LDAP it automatically uses LDAP calls to see who returns first. I believe that is what the algorithm does. So make an LDAP call, and whichever DC responds to that request first, it uses that one. I don't know that you can specify a specific domain controller for that.

Jason: Are you going to provide tools in Topaz so that if I want to set inventory on all my secondary sites, I can do it once, and it will set it inventory for all the sites?

Wally: That's one of our goals for Topaz, is to have the ability to clone site settings from one site to multiple, other sites. You have limited capabilities with the SMS Site Properties Manager, that utility in the resource kit, but we're going to have enhanced capabilities and tools for that purpose in Topaz, yes.

Jason: Somebody was asking about MCT documentation. When can we expect MCTs to receive new MOC courseware? Do you have any info on that at all?

Wally: I know the MOC group has started looking at Topaz material creation. I don't know what their timeframe is. I would not expect to see any MOC courseware on Topaz until the product releases, just like with MOM and a lot of products. In some cases, they'll have beta courseware for you to work with MOC beta software, but in most cases you'll find that courseware comes out after the product releases, so that they can finalize the courseware. That would be my guess. To my knowledge, it hasn't been finalized by the MOC group. I have a meeting with them next week to find out where they're going with it.

Jason: Does Topaz place any information into the Active Directory database, such as markers?

Wally: All I know of is what I've already talked about, which is that we extend the schema and then we can place our site information inside the Active Directory. Obviously, we create accounts. If you're in a Standard Security mode, we create that in the Active Directory. And then there is publishing server locator points and management points in Active Directory.

Jason: At this point I think I'm going to have to cut us off, just to make sure we get in under the two-hour mark. We only have two hours allocated for this WebCast. It looks like we have about 20 questions left. What we'll do is answer these offline. If you're interested in seeing what else has been asked, we'll append it to the transcript as well, so that will be available in about three weeks.

Again, I want to thank everybody for coming in and having so many good questions to ask. I'm really sorry we couldn't get through all of them. You guys are hounds for this new SMS product. I'm really excited to see some future ones coming up.

Again, we're very interested in your feedback regarding the WebCast programs. You can send your feedback to feedback@microsoft.com. Just make sure, if you use that alias, to include "Support WebCasts" in the subject line.

We look forward to seeing you guys in the near future. Thanks, and good-bye.

[Questions answered after session was closed:

Question: How are post-implementation Active Directory updates replicated to Topaz, such as users or systems being moved to other containers?

Answer: Simply run the discovery method again, make sure the new container is in the search path specified, and Topaz will discover the new container name for the resource, and report it properly.

Question: Is Topaz part of the .NET strategy? Is there a Beta MOC course yet?

Answer: Microsoft management is moving toward .NET, though Topaz is still based on a lot of the SMS 2.0 codebase, so it is not the product to fit in there. A future release will do so.

No, there is not a MOC course on Topaz yet. I have a meeting with them next week to discuss their plans for training materials on Topaz.

Question: Could the client installation be facilitated by GPO, and is the client Windows Installer driven?

Answer: The new mobile client is a Windows Installer installation, which of course can be distributed through SMS (to current SMS clients), through IntelliMirror^® and GPOs, or manually installed. The standard desktop client is basically what you know today from SMS 2.0, which is not Windows Installer-based.

Question: I know that Windows XP has a CIMv2.5-compliant MOF on the CD that is not entirely compatible with the SMS 2.0 hardware inventory. Will Topaz support CIMv2.5 and will it install a new version of WMI on clients?

Answer: Topaz will certainly support Windows XP clients. We have not seen any issues with Windows XP and Topaz hardware inventory, it all seems to work fine. We are going to document what administrators can do in this case to modify the SMS_DEF.MOF to support inventory of CIMv2.5 data that is not in the SMS namespace. We don't have any plans to provide any later WMI installation with Topaz, other than WMI version 1.5, which is what you get with Windows 2000.

Question: We are currently deploying DCs to each remote site, approximately 260 sites in total. Are there any issues with having these DCs as SMS secondary sites as well?

Answer: If you are asking about using them with Topaz, then there should not be any issues. There currently are a few issues with the SMS client installation on DCs in large domains. Topaz will resolve those. Topaz is supported on DCs, although most people prefer member servers for increased security. Just ensure that each site has unique site boundaries for supporting clients. If you are talking about SMS 2.0, then there are other issues, such as if all 260 SMS sites enable Windows Networking Logon Discovery or Windows Networking Logon Client Installation for the domain, then each DC would be a member of each SMS site. It is not recommended to enable Logon Discovery in that case, to help prevent .ddr replication (although SMS 2.0 SP2 helps in this case as well). So, you will notice increased replication traffic in this scenario as the SMS logon points are configured and verified.

Question: Are there any recommendations for MP scalability using NLB—for example, x number of clients for which you should use NLB?

Answer: We don't have those numbers from the scalability group yet. Network Load Balancing is supported for multiple management points as a single entity to the clients, but there are no numbers on how many per client yet. We hope to have some numbers by the time most of you are ready to deploy.

Question: Is there going to be a Service Pack 4 for SMS 2.0?

Answer: Yes, it's due out in early 2002.

Question: Will the video accelerated screen improve in SMS Topaz with Windows 2000 clients?

Answer: Not that I am aware of, because I've heard of no issues with it as of SMS 2.0 SP3, which is where video acceleration was provided for Windows 2000 clients. Make sure you are at SP3.

Question: Does your entire hierarchy have to be Topaz before utilizing Advanced Security? Or can it be enabled on a site-by-site basis?

Answer: The recommendation is yes, or at least only use Advanced Security between Topaz sites that are fully Active Directory enabled. An Advanced Security site cannot communicate with a child site (or parent site) that is running Standard Security, whether Topaz or SMS 2.0, because the computer account is used as the sender address account, and only Active Directory environments support that account.

Question: Is Topaz compatible with .NET Server Active Directory?

Answer: Yes.

Question: Can a server/workstation be a part of both an SMS 2.0 and an SMS Topaz site as a client?

Answer: This is not supported. Topaz will not support clients in multiple sites, like SMS 2.0 does.

Question: Will Topaz be able to monitor security packages on monitored workstations or laptops?

Answer: If you mean security rollup packages, there is nothing automated within SMS to detect when a security package needs to be installed. It is up to the administrator to write queries and collections to detect specific versions of the OS or other files, and then create packages and advertisements within SMS to have it distribute security patches automatically.

Question: Are there any changes in Topaz to improve and simplify SMS Installer 2.0?

Answer: There are going to be improvements to SMS Installer, such as the ability to natively write .msi files. Also there will be a bunch of bug fixes. As to simplifying its use, I'm not aware of any work there.

Question: What are the reporting features going to be like? This has always be a less than robust capability that required third-party tools to provide just the simplest of reports.

Answer: Topaz removes Crystal Reports and replaces it with an integrated version of the Web Reporting tool. This is integrated into the SMS Administrator Console, which allows security rights to be applied to it. Customization is available for reports and containers, and a few other features. The biggest gain is that it is our product, and not a third-party product, and is now more integrated into Topaz.

Question: Does Topaz integrate with Active Directory GPO software publishing?

Answer: No.

Question: Any conflicts between Windows 2000 remote and Topaz remote?

Answer: If you mean remote control, there are many options for remote control in Topaz, including the same feature that SMS 2.0 uses (although with improved performance), Terminal Services, and Remote Assistance for Windows XP systems. You can launch any of them to appropriate clients from the SMS Administrator Console.

Question: How will Topaz Active Directory integration compare with. ZenWorks and NDS?

Answer: I don't look at competing products in my job. If there is any data on it, it would be on the SMS Web site (http://www.microsoft.com/smsmgmt/).

Question: Will Topaz support self-healing applications like with programs installed by Group Policy?

Answer: As far as I know, self-healing applications are really based on Windows Installer, which may be deployed through IntelliMirror and GPOs. If Topaz deploys a Windows Installer application that is configured for this, it should still work with SMS, as it does with GPO/IntelliMirror.

Question: How does MOM integrate into the SMS strategy?

Answer: MOM fits in a different management space (operations management) than SMS (change and configuration management). However, MOM has a management pack included in it to monitor SMS servers and clients.

Question: Does Topaz work with both SQL Server 7.0 and SQL Server 2000?

Answer: Yes, it supports both versions (but nothing earlier than SQL Server 7.0).

Question: Is Topaz going to be cluster aware?

Answer: No, it is not.

Question: Will software monitoring be more accurate and reliable?

Answer: The software metering design provides for much more reliable and useful data than SMS 2.0.

Question: If Topaz requires Windows 2000 or .NET Server, does that mean I have to upgrade site servers, distribution points, et cetera?

Answer: Yes, that is what that means. No site systems are supported that are under Windows 2000, as an OS.

Question: Will there be any support for Mac or UNIX Clients?

Answer: No.

Question: Does the SMS Executive account still require admin rights?

Answer: Yes, unless in an Advanced Security model, where it will use LocalSystem. Can it be scaled back? Not to my knowledge.

Question: How about video acceleration? Has Topaz expanded the supported drivers?

Answer: Not that I've heard of. Of course, the list is only for Windows NT 4.0 systems, because Windows 2000 and above use a different driver and implementation that is not driver dependent, as is the case in Windows NT 4.0 systems.

Question: Will there be a fully included backup and restore function of complete SMS environments for single sites or single site systems?

Answer: There is already a great backup task in SMS (Backup SMS Site Server). That task remains in Topaz, although the backed up data has been modified to be specific to what is required to restore a Topaz site. The SMS Site Recovery Expert will be able to be installed locally, and you won't be required to go to the SMS Maintenance and Recovery Web site (http://www.microsoft.com/smsmgmt/techdetails/recovery/default.asp) as you are today. However, we do expect you will want to visit the SMS Web site occasionally to check for any updated versions of the SMS Site Recovery Expert. Also, the SMS Site Repair Wizard will be included in Topaz as well. This allows you to repair a site in a site hierarchy, updating and synchronizing serial numbers as necessary.

Question: Will Topaz support the DMI service layer for serial number collection?

Answer: Topaz can collect serial numbers from BIOS as long as the BIOS is SMBIOS 2.1 compliant. In fact, SMS 2.0 can do this if you are running WMI 1.5.]