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

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

Wally Mead: Welcome, everyone. This topic we actually introduced during our session about Topaz and Active Directory® Integration on November 29, 2001. That was just an overview. Today's session is going to concentrate solely on security within Topaz. So we'll look at not only advanced security, which we'll concentrate on this session, but we'll also review the standard security mode in Topaz to give you a quick comparison between the two.

So today's session agenda (slide 2), first off, we'll give you an overview of the Topaz security modes, so basically a quick intro into the two different security modes that are available in Topaz. Then, as we go through the overview of each of the two security modes, we'll discuss Site Server to site system communications, in terms of security and which accounts are used. Then, we'll talk about site-to-site communications, again in terms of accounts that are used and security aspects of that. Then, we'll delve really deeply into the Advanced Security mode of Topaz.

Once we've covered advanced security fairly well, then we'll go ahead and talk about accounts for advanced security. So we'll look at the accounts that are no longer used when you install Topaz in an Advanced Security mode. We'll look at the accounts that are automatically created when running in advanced security, the current accounts that are created as well as the ones that are planned when we get the Topaz product released to you all as a final product.

Then, we'll look at some accounts that you create optionally, if you want to implement a couple of the different features of Topaz. There are a couple of accounts that you may need to create in certain circumstances, particularly if you're going to be supporting standard clients, they'll be some accounts that you'll have to create.

Then, we'll talk about the process of converting from a standard Topaz installation over to an advanced Topaz installation, so how do you convert from standard to advanced security, and what happens when you do this conversion. Then, we'll recap the security modes by talking about the advantages of advanced security, why do you want to use advanced security, why is it important to me, what's the benefit of it. Then, we'll talk about a couple of restrictions of advanced security; so what are the things that you need to know about advanced security so that you can be successful in implementing advanced security within your SMS sites. Last, we'll talk about the mobile client and how it fits into the security mode of Topaz, so how does it fit in both of the two different security modes.

First off, we'll talk about the standard security model (slide 3), which is the model that you are all familiar with from SMS 2.0. The Topaz standard security model is the same as what you have from SMS 2.0. Basically, nothing changes there. It's the same as you have from 2.0. There are a few minor changes in the UI and some of the security settings, but as far as the overall implementation of the accounts and the security system, it's basically the same. Now, there are a few bug fixes in there, where we've had bugs with accounts, how they're used, the implementation, and so on, but for the most part again, it is the same. As you're very well familiar with the standard security model or the SMS 2.0 security model, this required many different accounts for many different purposes.

If you can think back to the SMS 1.x days, so 1.0 to 1.2, in that environment, we had a single account that basically did everything. We had the SMS Service account, and he was king. He was a domain administrator, and he was used for everything. Customers told us that they didn't like that implementation, because it was a single account that did everything, and that single account, because it was doing everything, required so many privileges. If that one account got compromised, then your entire security system of your domain got compromised, because of the fact it was a domain administrator.

So when we went to 2.0, we decided to improve our security scheme for SMS. To do so, we decided to isolate processes from each other, and to use separate accounts for processes. For example, use a local administrator account to start up a service on a Client Access Point, distribution point, or the computer running Microsoft SQL Server™, but then use a domain user account to transfer the data that that service needed over to the Site Server or to use that account to retrieve settings and configuration information from the Site Server. So we use different accounts for different purposes. That was, again, to improve your security, so you didn't have a single account that was used for everything.

There were also some optional accounts that you could create for SMS 2.0 to improve your security settings to make it even more secure, because by default, we would use the SMS Service account as the substitute account or in place of a couple of these optional accounts. So if you really wanted to improve your security, it required that you, the admin, would implement a few additional accounts in your environment, and then maintain those accounts.

Now, what all this did for you was that it wound up creating a lot of accounts in your environments. So you wound up having a large number of accounts that we created. So we went from the low-end extreme of one account up to the high-end extreme where you may have a ton of accounts being created. In some scenarios, we had customers that had multiple hundreds of accounts that were created with multiple sites in a single domain; we'll talk a little bit about that later on. Again, that security model doesn't change for Topaz. It's the same.

One of the advantages of the standard security model is that it does not require Active Directory. If you're still in an environment where you've upgraded and migrated to Microsoft® Windows® 2000, but you have not implemented Active Directory yet, then you can still utilize the Standard Security mode for Topaz. When you migrate from your SMS 2.0 environment up to Topaz, it will be a clean migration for you, because Topaz still supports that same security mode as SMS 2.0.

The downside to the standard security model is that you lose control over many of the accounts in your environment. So whether those are in the Microsoft Windows NT® 4.0 domain environment or in the Active Directory environment, there just are a number of accounts that are created that you don't have control over. There are some accounts that you can control, but others you can't. So there's an inconsistent experience for the administrator as to what accounts you have control over, so what accounts you physically name according to your corporate naming standards, versus the naming standards that SMS implemented on you, and what accounts you are allowed to modify their password or control the password policies for. You just didn't have an easy experience with that, because some accounts you couldn't touch, other accounts we did give you some control over. So it made it very difficult for, and we certainly understand that.

That's the standard security model. Now how the standard security model was implemented in an environment with your site systems talking to your Site Servers, we have a graphic here that shows you a Site Server and a site system (slide 4). Whether that's a database server, distribution point, Client Access Point, or a logon point, it doesn't really matter. On the left-hand side of your graphic is a site system, any one of those different roles, and on the right-hand side is your Site Server. I've got three different accounts listed there, in different colors for you, with a key or legend down at the bottom.

So first off on your Site Server, your Site Server ran its services under the SMS Service account. So the SMS Service account, by default, is this domain administrator account that's got a high level number of privileges available, and it's the main account for SMS. So that is the account that's used to run the vast majority of the Site Server services as far as SMS is concerned.

Now when the Site Server needs to communicate with a remote site system, then one of the accounts we could use is that SMS Service account. So we could use that domain administrator account to go across the wire to go ahead and connect up to your remote site system for installation, for configuration, for de-installation, for transferring data files, whatever is necessary. That generally worked, because the SMS Service account was a domain admin, which meant it most likely was an administrator on your remote site system.

Now, if you wanted to improve your security and prevent the SMS Service account from being used across the wire to talk to that remote site system, then you could implement that account in green, the SMS site system connection account. This is an optional account that you could create, and if you did create that account, you would need to create it in your domain or at least on the remote site system and have it be an administrative account on the remote site system, and then tell SMS that that was site system connection account for your servers.

If you did so, then whenever the SMS Site Server needed to communicate with that remote site system, we would try to use that site system connection account. If it was successful in doing what it needed to do, no reason for us to try the SMS Service account. If that failed however, then we could fall back to the SMS Service account, again because it is a domain admin and hopefully it had the privileges on the remote site system. So that was the communication process between the Site Server and the site system, from the Site Server to the site system itself.

Now in the reverse direction, from the site system to the Site Server, we used an account in yellow; that's the SMS Server Connection account. The SMS Server Connection account would be used to transfer data from the site system up to the Site Server, or when the site system needed to access the Site Server to retrieve configuration settings or other information.

Now the site system itself, if it had an SMS service running, it would be running under a different account, and that different account it would be running under was called a remote Service account. So the remote Service account, in a lot of cases, was an account named SMSSvc_YourSiteCode_nnnn (four numbers), in the case of a CAP or a SQL Server–type of computer. That account would be a local administrator account, but we wouldn't use that account to go across the wire to access the Site Server; we would use that SMS Server Connection account. By default, that account name was SMSServer_YourSiteCode. So that's the basic communications between Site Servers and site systems in a standard security model.

Now if we go to the next slide (5), the next slide talks about some of the problems with that environment. First off, and we've already discussed this a couple of times, is that the SMS Service account, by default, was a domain administrative account. There are ways you could make it a local administrator, if you installed your Site Server on a member server. However, if you were using the SMS Service account to talk to your site systems, the easiest way of doing so was to make it the domain admin account, so that it did have automatic privileges to all your remote site systems. Again, the downside is, you'd make it a domain admin, and then if you did use it across the network, then it could become a security risk, because any time an account goes across the wire, there's always a potential for that account's credentials to be hacked.

So if you had a common SMS Service account using a large hierarchy, if you had a large hierarchy, let's say a central site, a first-level tier, a primary site, maybe a half dozen or up to 10 primary sites, and then hundreds of secondary sites down below that, and let's say out in your remote offices, you were using your backup domain controllers as your SMS Site Servers, because oftentimes at secondary sites, the only server you have available is the BDC that you use for local log ons, in that environment oftentimes customers would use a single SMS Service account for all their SMS sites. Since they were in a single domain anyway, go ahead and use the single account.

In theory, that sounds okay, but if you then decide you need to change the password for that account, you would go up to your central site, you would change the account policies, the account credentials inside the Active Directory or the domain, and then you would try to replicate that out to all the backup domain controllers. That would generally work well.

However, a couple of cases that you may get a server that got the new account information through SMS prior to the account being replicated down to the backup domain controller. Then, you'd try to restart SMS, and it couldn't start, because SMS knew the account with the new password, but the domain controller says, "Hey, I can't use that account, because that's the wrong password." The more likely case is that the backup domain controller or the account synchronization process occurred prior to you being able to get all of your child sites or grandchild sites updated with the new account credentials within the SMS Administrator console or performing a site reset. So the domain would know about the account with the new password, but SMS wouldn't know about that account and password on the remote sites. So you'd restart your server or restart SMS, and it would not be successful in starting back up, because the account credentials were no longer valid, or maybe you already started but now you're trying to validate something across the network. They do account validation, and your credentials are incorrect now, so some operations could fail. That was a big problem when you were using a single SMS Service account and a large hierarchy.

Then, as I mentioned on the last slide, when you had remote site systems, we had this SMS remote Service account was created as a local account on each site system. So that wasn't too bad. Each site system might have its own account created, and it's a local account.

The account's name there is listed for you, SMSSvc_YourSiteCode_0000 and then it would start with four zeros and increment as new accounts were created. If you used domain controllers as your site systems, then that account became a domain account. Now, you might have a multitude of that account listed in your domain. Again, the last four digits would be incremented, so they'd all be unique.

So again, it's another set of accounts that we may be creating in your domain environment for you. Again, this is one of those accounts you had no control over the account name or the account password. We created that for you. Again, that just got to be another account that was duplicated within your environment and you had no control over.

Unfortunately, that's not all the problems with the standard security model. We have one more slide on it (slide 6), before we move on to advanced security.

On slide 4, where we saw the graphic of the two site systems communicating, the Site Server and the site system, we had the SMS Server Connection account in yellow. In some cases, you create one of those per site. You create one SMS Server Connection account per site, and it is SMSServer_YourSiteCode.

Now if you have multiple sites within your domain, the example again is that large hierarchy where you had a central site, a half dozen primary sites, and then hundreds of secondary sites, if that was a single domain environment you had, which is not uncommon, you would have maybe a couple of hundred or more SMS sites within a single domain. By default, each of those SMS sites would create its own unique SMS Server Connection account.

So inside your domain, and since you installed all those Site Servers on backup domain controllers, because that was what your server was in those remote locations, then you would have multiple, or in this case hundreds, because I think I said a couple of hundred secondary sites, you could have a couple of hundred SMS Server Connection accounts within your domain environment, so the SMSServer_sc1 down through site 200+. So that's a lot of accounts again that are created.

One of the things we did a few service packs ago was give you some ability to control that. So when you set up your SMS site on a command-line switch, you could specify, when you ran SMS Setup, the account you wanted to use for your SMS Server Connection account. Instead of having 200+ SMS Server Connection accounts in your domain, you could create one SMS Server Connection account. Then, on the command line, when you ran SMS Setup, you could specify what your Server Connection account name and Server Connection account password was that you had created within your domain environment. Then, SMS would install it using that account.

You would just run that same command-line switch in all your hundreds of secondary sites and the first tier primary sites, so that all the sites were sharing a single Service account, the Server Connection account. That made it nice and easy for you. It reduced the number of accounts you had in your domain. It was just a pain that you had to go through to either remember to use the command-line switch, or there was actually an ASCII text file, an .ini file, you could create called SMSAccountSetup.ini, and if you put that in the correct directory and formatted it properly, then whenever you ran Setup, then we would find that file and use the credentials that were listed in that file. However the downside was, it was an ASCII text file. So you'd have to make sure that that file was secured within your environment.

The last problem was that in some cases, when you ran a site reset, the process of telling SMS to go ahead and reinstall all the SMS services, oftentimes after a recovery scenario or you made some configuration change, like an account or a password, that you would do a site reset; during that process, SMS would reset the SMS Server Connection account password. It would re-create the account, because we're reinstalling the services. Then when we re-create the account, we create a new random password, unless again you had that switch that told us to use a specific account password.

In that environment, a couple of problems could occur. If any of your site systems were offline during your site reset, they might not get the new password. So if they're offline (not available on the network), then you reset the site and create a new password, they'd have the old password. Your new site would have the new password. Now, when that old site system comes back online, it tries to communicate with your Site Server using that old password, and it won't be able to, because the credentials had changed in the domain. What would happen is, if you had account lockout policies enabled, then you could lock out the SMS Server Connection account for site systems that actually had the correct password and were successful in communicating.

Another case could be if you had domain controllers you had installed in domain controllers and you had account synchronization issues. So the changed password and so on didn't get synchronized in your domain.

Now, one thing we did for you in SP2 (I think) and later was, we changed SMS Setup so it now prompts you whether or not you want to reset your SMS Server Connection account password. The default is, no, to not reset the password during your site reset. So the last problem here, talking about site reset and so on, that was a problem in SMS 2.0.

In Topaz, we've alleviated this problem a little bit by the fact that if you do install Topaz on a member server, then these accounts that we're creating and talking about here are local accounts, as opposed to domain accounts. Because they're local accounts, you don't have the account synchronization problems, because the account is stored locally on the member server itself and not a domain account. So it got a little bit easier for you. Now, if you install Topaz on your domain controller, then these become domain accounts, and you still have the same issues.

Just as a recap for you, the major problems or the biggest issues that we have around the standard security model are: 1) The number of accounts we create in your environment; and in some cases it was hundreds of accounts we would create; 2) The lack of control that we gave you, the administrators, over those accounts that were created; and in a lot of cases, you didn't have any control over those accounts; in other cases, you weren't sure whether or not you had administrative control over those accounts, and you just weren't positive on what you could and couldn't do.

Then, the default implementation of 2.0 was not in the highest level of security you could get it to. To get it to the highest level of security, it meant more administrative intervention. You had to create some optional accounts. You had to maintain additional accounts in your environment. So it meant more interaction or more administrative functions for you, the administrator.

So our solution in Topaz to try to help alleviate some of these problems is to create and implement something called the Topaz advanced security model (slide 7). So the Topaz advanced security model is going to help alleviate all those problems we talked about with the standard security model.

Now, we're not getting rid of the standard security model. It's still there. You can still implement it. It may very well work fine for your implementation, and that's not a problem. It's nice. It's easy. If you don't have to go in there and create some of those optional accounts, it's not bad as far as administration, as long as you can live with our account naming convention and our account password policies and so on.

For the advanced security model, so if you do need additional security, you want to have more of a hands-off environment, as far as administering SMS accounts, then the advanced security model may be the way you want to go. One thing is that this does require Active Directory for all your site systems. So within an SMS site, you have to have Active Directory for all your site systems; Topaz automatically always requires Windows 2000 or later site systems anyway. So it just means that you have to have Active Directory implemented. We'll discuss why in a couple more slides.

What the advanced security model provides to you though is control over all the accounts of the domain, because SMS is not going to create all these user accounts that we created in the standard security model. So we're not going to create those accounts. You don't have to worry about what accounts SMS created, which ones you can and can't control, what are our account names, our naming convention, our password policies, and so on.

We don't create user accounts in the advanced security model. We do create a couple of group accounts. We'll talk about that in the next couple of slides, but for the most part, we're not creating user accounts in the advanced security model. So you don't have to worry about our accounts anymore.

You can also configure advanced security either during SMS setup or post-SMS setup. So this is very nice if you're in an SMS 2.0 environment and you want to migrate over to Topaz, then you can go ahead and upgrade successfully, because Topaz still supports the same security model as SMS 2.0. Then, when you're ready to go ahead and convert to the advanced security model, you can go ahead and convert over to the advanced security model. Or let's say today you're running in a non-Active Directory environment in your Windows 2000 environment, then at some point in the future you're going to migrate over to Active Directory, once you migrate over to Active Directory, you can then convert SMS from standard security to advanced security and take advantage of all the cool things we're doing with the advanced security model.

So what we're doing with advanced security basically is that all the SMS services run under the Local System account. We're not creating separate user accounts for the SMS Service account. We're not using Sender Address accounts. We're not using Server Connection accounts. We're not using site system connection accounts. All of those accounts you folks are familiar with, and in a lot of cases don't care for, we're not creating and using those in the advanced security model. We're using local system for all the SMS services running on the site systems so the Site Server and all of the CAPs, management points, distribution points, SLP, SQL computers, and so on.

So very few accounts are created or used. Again, those are primarily some group accounts we'll create, and we'll talk about, and we never need to communicate across the wire from one site system to another site system, so from the Site Server to a CAP or from the management to the database server, or whatever the case is, we go ahead and use the Computer account. The Computer account is what is used to communicate across the wire.

This is why Active Directory is required, because in an NT 4.0 domain model or a Windows 2000 in a non-Active Directory environment, we use the machine account. The machine accounts are not full security principles until you get into the Active Directory environment, and in Active Directory environments, there are principles that you can use to add to groups as well as set access control on for files, for registry, for database access, and so on. So you have the ability of setting access control entries or ACEs in your access control list for your Computer accounts. Again, that's why we need the Active Directory environment.

So, the implementation of the advanced security model (slide 8), again, no additional SMS user accounts are created. We do create some group accounts. In today's build, so in the current build of Topaz, we actually do still create one user account, but we're going to get rid of that account by the time we release the product. So, when you guys see it, as far as a released product, there won't be any user accounts that we create automatically for you out-of-the-box when you install in an advanced security environment.

We create a few security groups, and I'll talk about those security groups a little bit later on. Just to give you a quick idea, there's a Site Server Access group which is used for a site system to communication with the Site Server that would replace the SMS Server Connection account. There is a Site Address Access group, that's for site-to-site communications. So what would replace your Sender Address account is the Site Server Access group. The third one will be the Database Access group. This will be for server locator points, for management points, and reporting points to communicate with the database server. So, the three groups are Site Address Access, Site Server Access, and Database Access.

Now, we still also do create one more group, and that's the SMS Admins group. The SMS Admins group is the group that we create in 2.0 today that's used to control who has access to the SMS site database for the SMS provider. So, all site system communications use the Computer account for access to the Site Server. To the site system, we'd use the Site Server Computer account, which is siteserver$ (the Site Server, whatever the name of the computer is, dollar sign). The site system, when it communicates with the Site Server, would use its Computer account, which is sitesystem$ (the site system name, dollar sign).

To implement this, the Site Server's Computer account must be an administrator on each remote site system. So whereas in the standard security model, you use the SMS Service account to communicate across the wire and that SMS Service account needs to be an admin account or optionally you can use the SMS site system connection account, but again, it has to be an admin at the remote site system.

What you do instead now with advanced security is, you just make sure that your Site Server's Computer account is a member of the local administrators group on each of your site systems. You're using a Computer account that's already there for you in your Active Directory environment, so you're not creating an additional account; it's there by default. It's a password that you don't have any control over and neither does SMS. It's controlled by Active Directory itself; it's maintained and modified through Active Directory, so it's a very secure account and password.

The Site Server would automatically grant the appropriate rights to site system Computer accounts when the site system role is added. In other words, when you add a CAP, we would go ahead and automatically add the CAP's Computer account into the permissions that are required on the Site Server.

On the next slide (9), we have a screen shot. This is one of a couple of different ways of setting up an advanced security site within Topaz. This is actually from the SMS Setup Wizard. So you're going through the process of installing your site initially, and we now have a page that appears called SMS Security Information. We ask you what security mode you want to implement at your site. Do you want standard security, which is the SMS 2.0 model, or do you want advanced security? If you were to select the bottom option Advanced Security Mode, then what would happen is, the Service account name and password boxes would become unavailable, because there is no Service account or password for the Advanced Security Mode. So those become unavailable, and you can't even configure those.

Now, another way you can set this is by performing a site reset. So if you go through and your site's already installed, and you go back to SMS Setup and you choose the last option of Modify or reset the current installation, then this same wizard page will appear. You can migrate from standard security to advanced security at that point in time.

Then, the last way is within the SMS Administrator console. So within the SMS Administrator console, you go to your Site properties dialog box. So, go to your Administrator console, expand Site Database, expand Site Hierarchy, select the appropriate site, access its Site properties, and we have a new button there called Set Security. If you select the Set Security button, it will convert your site from standard to advanced. We obviously present a confirmation dialog box to let you say, "Yes, I do want to convert," and so on, because it's important to note that this is a one-way conversion. Once you convert from standard security to advanced security, you can't convert back. You're in advanced security mode, and you'll stay there until you uninstall SMS.

Adding remote site systems (slide 10); I kind of started this a couple of slides ago. When you add a remote site system, the Site Server's Computer account must be manually added as an administrator to the remote site system. So you're going to have to go through and manually add your Site Server's Computer account as an administrator on the site system that you want to set up. So on the computer you want to become a site system, the Site Server's Computer account needs to be an admin. So if your Site Server's name is Server1, you need to make sure that Server1$, which is what the account name is for your Computer account for the Site Server, is added as an administrator to the remote site system's group. So make it a local administrator. So you have to do that manually.

Once you do that, then you just go into your SMS Administrator console, and you add the computer to your site systems. You assign the appropriate site system role to it, such as the Client Access Point. Then, SMS will go out across the wire, validate that it's an administrator on the remote site system, and then configure the appropriate services and files (in this case, the SMS Executive for the Client Access Point), and create the directory structure, install both the Executive and the Inbox Manager Assistant. Those will be running under the Local System account, so not a separate Service account created any longer for the remote site system either.

What SMS will do, it will automatically take the remote CAPs Computer account and add it to the SMS Server Connection group. So in fact, as the bottom bullet there tells you, the actual group name inside the Active Directory you would see is SMS_SiteSystemToSiteServerConnection_sc. If you don't want that default name, you can control the group name for this account in the same SMSAccountSetup.ini file. We'll document how to do that.

So you just make sure your Site Server's an admin on the remote box, which means the Site Server's Computer account is the local admin. Tell SMS to use that computer as a site system. We'll install the appropriate service and files that are necessary there. Then, we'll add that remote site system's Computer account to the SMS_SiteSystemToSiteServerConnection group. Then, that group automatically has permissions to the Site Server that are required to communicate with the Site Server. Again, this would then replace your SMS Server Connection account, that old SMSServer_sc account is what this group account would replace for you.

I have a picture of this on the next slide for you (slide 11). Here, we have advanced security, our Site Server to site system communications process. So here we only have two accounts, and you see the accounts that are used are your Computer accounts.

So the Site Server, in blue, when it communicates with the site system, it uses the Site Server's Computer account, so a siteserver$ or whatever the name of the computer is. Again, remember in standard security, this was the SMS Service account or the optional SMS site system connection account is what you would use there to communicate across the wire. So you'd have an extra account or two accounts in your environment that you'd have to maintain and make sure you had appropriate rights to it, there was just the Computer account. Again, this Computer account, for the Site Server, must be manually added to the site system's Administrators group on the left.

Now when the site system is set up and it needs to communicate back to the Site Server for transferring data files, retrieving configuration files or settings or whatever, it would go ahead and use its Computer account to communicate with this Site Server. So that would be whatever the site system computer name is with a dollar sign at the end of it. SMS would automatically add that account to the SMS_SiteSystemToSiteServerConnection group. That group has the appropriate security rights, through NTFS, to the Site Server itself.

So there's nothing else you'd have to do on the Site Server end. Just make sure I'm an admin remotely, and then add the role, and then SMS takes care of the rest of it. So no user accounts are used here at all. No user accounts are created. Where in the past, that might have been one, two, three, four different accounts that were used here, the site SMS Service account, maybe a site system connection account, your Service account created on the remote site system, and then the SMS Server Connection account used to communicate across the wire. So there you would have had four accounts. Now, that we're added to your domain environment, now you have no accounts that are added to your domain environment, because these two accounts, the Computer accounts, are already there. So we're just utilizing something that's already implemented for you by default.

Okay, site-to-site communications (slide 12). In standard security, you had to create a Sender Address account. You would go in there and create your address for your child site or the parent site. When you created that address, you would specify what accounts you wanted to use to communicate with that remote site. That account had to have appropriate rights to the destination or the target SMS_SiteShareName, which pointed to \SMS\Inboxes\Despoolr.box\Receive directory. By default, it was administrators you had to put that account as a member of, make them a local administrator, or you had to go in there and set the appropriate rights to that folder, \SMS\Inboxes\Despoolr.box\Receive to give them the ability to write files, delete files, and then be able to read and modify their files; so basically you had to do everything but full control. Again, that was a manual process.

In your advanced security environment, no accounts are required here. So the SMS Executive runs under the Local System account on both boxes. So you're running local system for your services. Now to communicate across the wire in that case, you'd use your Computer account. So the Computer account is used to communicate from the parent site down to the child site, and the child site back up to the parent site uses its Computer account. All you need to do is make sure that your Computer account is added to the remote site's SMS_SiteToSiteConnection_sc group. So that's your site address access group.

So just make sure that your appropriate Computer accounts are added to the appropriate group, so the source Computer account to the destinations group, and reverse that going in the opposite direction. That group already has the appropriate security rights implemented on the folder we mentioned, the \SMS\Inboxes\Despoolr.box\Receive folder. It has the appropriate rights to go ahead and be able to communicate, do its transfer of data files, and do everything it needs to do. So again, it's very nice and clean and very easily implemented. We automatically set the security rights, so all you need to do is make sure the appropriate accounts (the computer accounts and/or sender accounts) have been added to the group.

I have a graphic for you on the next slide (13). If you're implementing secondary sites remotely from the Site Server, so from the primary site you want to implement secondary sites, we automatically add the primary site's information into the secondary site's server, into its group information automatically. You just have to add your secondary site information back up to the primary site groups manually, but we take care of the primary site down to the secondary site.

So the graphic is showing you the picture of site-to-site communications when you're running in an advanced security environment, remembering in standard security, this was Sender Address accounts you had to create. So Site Server 1 would have to create a Sender Address account, and then make sure that account was either a local administrator in Site Server 2's appropriate folders or give it NTFS rights to be able to create files, delete files, modify files, and read files, and so on to the \SMS\Inboxes\Despoolr.box\Receive directory at the remote site. Alternately, the Site Server 2 has to create the same information and set security rights back up at SMS Site Server 1 to communicate from the child site back up to the parent site.

In advanced security, this is all handled by the Computer accounts again. You just need to make sure you add your Computer accounts to the remote site's site address access group, so SMS_SiteToSiteConnection group. So Site Server 1 would have his account added to Site Server 2's group. Site Server 2 would have its Computer account added to Site Server 1's group. Then, you're all set.

One "gotcha" here is that this doesn't work in Windows 2000, if you're in different forests. There's an issue here with different forests currently in that in Windows 2000, when you have different forests, if you set up trust relationships, those are explicit trust relationships, which use LAN Manager–type authentication. Computer account principles require Kerberos authentication, which is not implemented in the environment where you have trust relationships with Windows 2000.

So in this environment, to make this work effectively in an advanced security environment, you would either need to be in a single forest, but you could still have multiple domains but a single forest, or .NET Server will handle this properly for you. So if you upgrade to .NET Server when it becomes available, then you'll have the appropriate rights that you need. We're trying to work out a different method of handling this for you, but as of today, that's the requirement you have to look at, is your restriction there for either being in a single forest (multiple domains) if you wish, or being on .NET Server, in that environment.

Here's a picture that we have for you. When you're implementing advanced security, it does not mean all of your sites have to be advanced security (slide 14). You can mix a hierarchy of advanced security and standard security if you wish. The restriction is that all of your sites have to be in Active Directory. So any site that wants to communicate with an advanced security site must be in advanced security, again because the advanced security site is going to use its Computer account as the account used to transfer data across the wire or access the other sites. That security count, which is a Computer account, is not a security principle outside of Active Directory.

The standard security site would need to be in Active Directory for that Computer account, the security principle, to be active and valid, but as long as, in this case, both these sites are Active Directory, one can be advanced security, and one can be standard security.

So in this case, Site Server 1, its site is set up in advanced security, and Site Server 2, its site is set up in standard security. What you would have to do is that the Sender Address account, which would be from Site Server 2, the Sender Address account that it knows about, because it doesn't know about local system and using the Computer account, you would have to add the Sender Address account to Site 1's SMS_SiteToSiteConnection group. Now, since the advanced security site doesn't know about Sender Address accounts, it knows about the Local System account, which means it's using the Site Server's Computer account across the wire, then the Site Server's Computer account from Site Server 1 would have to be added to Site 2's SMS_SiteToSiteConnection group.

Now, we create these security groups, in this case, the security group is SiteToSiteConnection group, in all Topaz implementations. Whether you're running advanced security or standard security, you get these same three groups that we've talked about, and we'll talk about them again on the next couple of slides. So that group will already be there. All you have to do make sure you manually add the advanced security site's Site Server's account into your SiteToSiteConnection group.

Okay, accounts that are no longer used when using advanced security (slide 15). These are accounts that we're not using anymore for SMS Topaz when you migrate to advanced security. The SMS Service account, instead we're using the local system; the SMS Site System Connection account, again we're using the local system for that (local system being for the service itself and then we're using the Computer account across the wire); the SMS Server Connection account; and then the Sender Address account. Those four accounts are all now running under the local system as far as the services that they utilize. Then, we use the Computer accounts to go across the wire.

Now, the bottom three accounts, the SMS Client Connection account, the SMS Client Service account (SMSCliSvcAcct&), and the SMS Client Token account (SMSCliToknAcct&), those three accounts are not used, if you're implementing the mobile client. The Mobile Client service, as we talked about in last month's presentation, the service on a mobile client runs under local system, as does the Site Server and all the site system accounts and services in advanced security. So it runs under local system.

However, the Topaz standard client hasn't changed. It still utilizes the same account services and account credentials as it does in SMS 2.0. So that if you're using standard client, you're going to have to have an SMS Client Connection account, and we'll automatically create the SMS client Service account and the SMS Client Token account. We won't create those automatically for you; however, when you do implement standard client, then we'll go ahead and get some of those accounts created for you. We'll discuss that in a couple more slides.

Accounts that are automatically created (slide 16). Right now we create three group accounts for you, the first of which is SMS Admins. The SMS Admins group, which is the standard group you have today in SMS 2.0, that's to give you provider to the SMS site database to the SMS provider. So that's what that provides for you. That group is still there. That's to give you your SMS Administrator console security, so who can do what inside the Administrator console.

Then, the group accounts we create are the Site Server access group, which is by default the name is SMS_SiteSystemToSiteServerConnection_sc, and that would replace the SMS Server Connection account. That group has the appropriate rights to the Site Server as necessary for the site system to communicate and transfer data files to the Site Server.

Then, the next one is the Site Address Access group, which is SMS_SiteToSiteConnection_sc. That replaces your Sender Address account. That group has the appropriate rights necessary to the \SMS\Inboxes\Despoolr.box\Receive folder for this parent or child site, at least the remote site communicates with the local site.

Now, these three groups are created regardless whether or not you're in advanced security or standard security in Topaz; you can have those three groups created.

Currently in today's builds of Topaz, we do create one user account. The user account is listed for you on this slide. It's SMS_SQL_RX_sc. This account is used by management points, server locator points, and reporting points to access the SMS site database. These three site system roles don't go through the Site Server to gain access to data, they go directly to SQL Server. So they go to SQL Server to gain access to the information they need to perform their functions.

So we have to have an account for those services running on those boxes to communicate with the SQL database. So right now, we're using this account, SMS_SQL_RX_sc. Now, this is created locally on the database server. So if your database server is a member server, then that would be a local account on the database server itself.

By the time Topaz releases to manufacturing, this account will be replaced with a new group account. The group account is called the Database Access group. I haven't seen what the official name or what the syntax of the account group name is going to be, like SMS_SiteSystemToDBAccess, I don't know what it's going to be, but something to that effect. So it will create a new group that will have the appropriate rights assigned to it in the SQL Server, so that you won't have any user accounts created by default in an advanced security environment.

Now, optional accounts (slide 17). There are cases where, even in an advanced security environment, you may have to create some additional accounts to facilitate certain functions. Most of these revolve around the standard client. So if you're going to implement standard client, which is the same client platform that SMS 2.0 has, then you're going to have to have these accounts in your environment.

First off is the SMS Standard Client Installation account. This is the account that's used by the Site Server to push out the SMS client software out to a standard client. So if the logged on user is not a local administrator, they can't install the SMS client software completely, so then they create what's called a CCR, Client Configuration Request. It writes it to the CAP, the CAP then moves it to the Site Server. The Site Server says, "Oh, this computer needs help with installation." Then they connect to that remote client computer, using this Standard Client Installation account, connect as an administrator to the Admin$ share, dump out some files, create a new bootstrap server, and complete the installation of your client service. This account, you'll be required to create if you need to push out the SMS client software, either because the logged on user is not an administrator or because you're using the standard client push installation method, which means you discover a client through some discovery method, like Network Discovery or Active Directory System Discovery, and then you decide, "Okay, I want to make that guy a standard client by default." You'd have to create this account. In standard security, if you don't create one of these accounts, which by default there is not one, we go ahead and use the SMS Service account.

However in advanced security, there is no SMS Service account. So if there's no SMS Service account, there's no account for us fall back on. So if you need to push out the SMS standard client code to standard client computers, then you need to create at least one of these accounts, and this account has to be a local administrator on your client computers.

The next is the SMS Client Connection account. This is required for the standard client platform to communicate with its Client Access Point. Standard clients don't use local system, and they don't use Computer accounts. Instead, they use the SMS Client service, which then uses the SMS Client Connection account to communicate across the wire. So you need to make sure that you have created an SMS Client Connection account. In standard security, it's the SMSClient_sc account that we create for you automatically.

Standard Client Software Installation account. Now this is an optional account that even if you have standard clients, you may not have to create. This is the same account as in SMS 2.0, I think we called it the Windows NT Client Software Installation account. So this is the account that if you're running software distribution and your program requires administrative rights, but the logged on user is not going to have those administrative rights. In that case, we use the SMSCliToknAcct, but the SMSCliToknAcct is not a network account, it's a local account, and so it can't access resources across the wire.

So then, you would use this account to access another server on the network if the program you're distributing requires access to another server, other than just the distribution point. So you can still create this account for running programs in administrative rights when you need access to a third server besides your CAP and your distribution point.

Now, there's one optional account for the mobile client, and that's the Mobile Client Network Access account. I think I mentioned this in last month's presentation. This is basically analogous to the Standard Client Software Installation account, in that I have a program I'm distributing, and that program requires access to another server on the network. Well, the mobile client is running under the Local System account. So when it communicates across the wire, generally it's going to use the Computer account, because it doesn't use the SMS Client Connection account. So it's going to use this Computer account, but you may be in an environment where you don't have Computer accounts available for your distribution points or other servers, so instead what we use is the Client Network Access account.

So when you have a program that requires admin rights for a mobile client, we use the Local System account, but again, no network access. So what we want to use instead is the Mobile Client Network Access account. You create this account. You tell SMS about it, and this account then is used to communicate with that additional server across the network. We can use the user account to go to the distribution point, but to the other server, we need to use this account.

So this account is one that you have to create manually, tell SMS about, and then give this account permission to the third server on your network, basically make it a domain user account so it has the same permissions. This is only used for network access. It's not used to run the program, like the Standard Client Software Installation account on a standard client. This program still runs in the context of the Local System account.

There is one other case I just heard about the other day where Network Discovery, in certain cases, requires an account. If you think about the case of Network Discovery, one of the things that Network Discovery, one of the things that Network Discovery can do is communicate across the wire to your boxes and find out what operating system they're running. Since in an advanced security environment, you're running local systems in the Computer account, well you may be connecting up to non-Active Directory systems that you have in your environment, which don't support the Computer account. So then you would need to have an account for Network Discovery.

I think we're trying to use one of the existing accounts that you might create, like the Standard Client Push Installation account, but I'm not positive on that yet. I just found out about that yesterday, and we just found out that that was an issue. So I have to find out what we're doing in that environment.

Okay, we're getting down towards the end, a few more slides to go. So converting from standard to advanced security (slide 18). I'm in a Topaz standard security model right now, and I want to convert to advanced security. What do I have to do?

It's a very simple process. I showed you the one screen shot where it had the Standard Security mode or Advanced Security mode. You can set that during installation. Of course, then you wouldn't be converting, because you're installing it clean, or if you're converting, you can use that same wizard page in a Site Reset. So you can do a Site Reset and then migrate or convert from standard to advanced security, or you can go to your Site properties dialog box inside your SMS console and then click the Set Security button. There's a Set Security button, and when you select that, it will pop up and tell you, "Hey, I'm going to convert from standard security to advanced security. You can't convert back. Are you sure you want to do this?" You say, yes, and then Site Component Manager would go ahead and do a site reset for you, basically uninstall your SMS services, reinstall them in the context of advanced security, so now running under local system. So when you do this conversion, all of your services now run under local system.

However, we don't remove any of the accounts that we created from this standard security model. So we leave all those accounts there, because we're not sure if you're using those accounts for anything else. So we leave those accounts. You'd have to go through and clean out all the accounts that aren't being used anymore. So you can go through the process of cleaning out the account. Basically, you'd have to leave the group accounts we create: the SMS Admins, the SMS_SiteSystemToSiteServerConnection group, the SMS_SiteToSiteConnection group, and then the user accounts being basically the accounts for your standard clients, so your Client Service account, your Client Token account, the SMSInternalCliGrp account, which is used for the standard clients, and your SMS Reporting Users group, if you've enabled a reporting point at your site.

Again, there is no automatic removal process. You just have to go through and clean those out. Again, if you're using standard client, you still have some accounts that are required, which are the Service account, the Client Connection account and then the Client Token account.

(Slide 19) There are a couple of verification things that you have to do. Make sure that you have your Site Server's Computer account set as a local administrator on all your remote site systems. Again previously, that was the SMS Service account or the SMS Site System Connection account that was used. You have to make sure that this account, which is your Site Server's Computer account, has been added as a local administrator on each of your remote site systems; that's something you have to do when you convert.

You also have to make sure that your remote site system Computer accounts have been added to your SMS_SiteSystemToSiteServerConnection group. Previously, that was your SMS Server Connection account. So just make sure that the Computer account of each remote site system has been added to the SiteSystemToSiteServerConnection group account.

Then, if you're using standard clients or you want to create standard clients, you need to make sure that you have an SMS Standard Client Installation account. You need to have that if you're going to be pushing out the SMS standard client installation. Again, that may have been previously accomplished by the SMS Service account.

Okay, advantages of using advanced security (slide 20). If you install on member servers, then we don't create any domain accounts at all. Again, if you install your SMS Site Server on a member server, there are no domain accounts created. We'll create some local accounts, being those group accounts we've talked about, but no local accounts.

Again, currently, there's one Local User account that will be gone by the time we ship. So that means no account maintenance. You don't have to worry about what accounts we created, what the naming standard is, what our password policies are, whether or not you can control the account name or the account password or anything with accounts, because we're not creating any accounts for you. We're creating a few group accounts, local or domain, it depends on where you installed, but those are to give security rights for the Computer accounts.

Computer accounts are controlled automatically by the system, the account names and the passwords. So there's no maintenance for you at all for that. The services all use the Local System account as opposed to the SMS Service account.

Then again, the Computer accounts we maintain for you automatically. This is fully integrated with Active Directory. So it's one more step in getting closer to Active Directory and utilizing it for more things. Again, if you install on a member server and you don't touch your domain controllers, SMS won't touch your domain controllers at all.

There is no impact at all on your domain controllers, unless you happen to install a site system role on a domain controller. Then obviously, we'll impact you there, but other than that, if you install a member service, we're not going to touch your domain environment; and it gives you improved security, because there are fewer accounts to hack using local system and using Computer accounts. Those are some of the advantages you have for your advanced security model.

There are a couple of things you need to be aware of (slide 21). When you're looking at advanced security, make sure that you can implement it successfully in your environment. It does require Active Directory. So, all of your site systems must be in your Active Directory. Again, the reason for that is, we're using the Computer accounts which are actually out there for NT 4.0, but they were only used to identify the computer in the domain. They weren't full security principles. They're not security principles that can be assigned permissions until Active Directory. So you have to be in an Active Directory environment to utilize advanced security. Now, if you want to use standard security again, you don't have to have Active Directory, you can use your NT 4.0 domain model.

It requires manual creation of an SMS Client Connection account for standard client. So if you want to utilize standard client, then you need to create some accounts manually. You need to your SMS Client Connection account, which is what the clients use for accessing the CAP. You need to create the SMS Standard Client Installation account, if the Site Server's going to be pushing out the SMS standard client installation. So there are some accounts you have to create and make sure you have access to, before you can utilize your standard client platform.

Again, for mobile clients, there are no accounts you have to create. You might want to create the Mobile Client Network Access account for certain software distribution scenarios.

So a picture of standard client communications (slide 22); even in an advanced security environment, you have your standard client (in the lower right). It runs under the context of the SMS Client Service account. So the client's running under an account that's going to be a locally created account though, that's going to be to local to the SAM of the client.

It communicates with the CAP through a Client Connection account, which is an account you have to create if you're in an advanced security model. I have it listed as optional accounts in advanced security. It's optional because we don't create it automatically for you, but it is required if you're using standard clients.

The CAP would run its services under local system. It would communicate to the Site Server using its Computer account. The Site Server services run under local system, and it would communicate with the CAP under its Computer account. If the Site Server needed to push out the SMS standard client platform to the client computer itself, then it would use the Standard Client Installation account, which again is not created for you automatically. You would have to create it manually and use that account to push out your SMS client software, if you're using the push installation method or if the logged on user is not a local administrator. Then again, using standard clients would create a few additional accounts for you, the SMS Client Service account (SMSCliSvcAcct&), SMS Client Service Token account (SMSCliToknAcct&), and SMS Internal Client Group (SMSInternalCliGrp). Then, you need this Client Connection account, which is the SMSClient_sc.

Okay, the mobile client (slide 23), we talked about in last month's presentation, so just a real quick recap. Its service is the SMS Agent Host service. This runs under the Local System accounts and no additional accounts are created for the mobile client. So it utilizes local system. When it communicates across the wire to its management point, it uses Microsoft Message Queue and BITS (Background Intelligent Transfer service), and it uses the Computer account to transfer information and communicate with the management point. So no SMS Client Connection accounts are required at all.

You may however need to create a Mobile Client Network Access account for those scenarios where the software you're distributing requires admin rights and access to another server on the network other than the distribution point. Then, you can create this account, make it a Domain User account, so it has rights to that third server, and then when you run this program, it runs in the context of the local system on the client, but across the wire to that third server, where it would use the Mobile Client Network Access account. Again, it's only for network access, it's not for running the program; the program still runs under the local system.

Here's a quick picture (slide 24) of the mobile client platform. Mobile client runs its service under the context of local system. It would communicate using BITS or MSMQ to the management point using its Computer account. The Management Point services run under local system, communicate to the Site Server with their Computer account, the Site Server's services run under local system and communicate with the management point under the Computer account for the Site Server.

All right, that's it. Let's do a quick summary (slide 25), and then we'll get Jason kicking off the Q&A session.

Security is very important to Microsoft. We know we put you through a few pains in 2.0. We're trying to make things better in Topaz. The better things we're doing in Topaz all revolve around the mobile client and the advanced security model however.

The standard security mode still works for a lot of Topaz deployments. So we're not stating you have to convert to advanced security. The standard security mode may work extremely well for you, you understand it, you know what accounts are there, you know what accounts you can't handle, which ones you can handle, you've got you're procedures all set, you may very well want to stick with standard security, or maybe you're not Active Directory integrated yet, so you can't go to advanced security, or you want to integrate with SMS 2.0 child sites, so you want to use the same security model. There are numerous different reasons you might want to stick with standard security, and it's still there in Topaz. It does basically the same things it did for SMS 2.0.

However, if you want to improve your security scenario, not have all those additional user accounts that are created or ones that you have to create for additional security, then you might want to consider the advanced model. It does require Active Directory in your hierarchy for all the sites that are communicating with this advanced security site. So at least the site with advanced security and its immediate parent or child sites have to be in Active Directory.

However, you can mix advanced security and standard security sites within your hierarchy. We use Computer accounts and Local System accounts in place of the special user accounts the standard security model utilizes. So there are fewer accounts for you to maintain. So it's easier administration for you. No user accounts required, except for the standard clients and if you need that special software distribution account, the Mobile Client Network Access account for mobile clients. So it's a lot easier for you. It's easier to maintain, and it's more secure because of the fact that we do have the secure accounts where you're using the Computer account as well as the Local System account.

All right, with that I'll kick it back to Jason.

Jason Bennett: Okay. Thank you, Wally. All right, just a couple of quick notes before we move on to the Q&A portion of this Support WebCast. If you'd like to have a copy of the PowerPoint® slides, be sure you download the file from the Support WebCast page. To access information about all upcoming Support WebCasts and the archived content from all past WebCasts, an easy to remember URL is http://support.microsoft.com/webcasts/.

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

What are we looking for in terms of a time frame, Wally? I know several folks are asking how they can get on the beta. The questions of the hour include: What's the plan for release? Is the Topaz beta going to be released on TechNet Plus? How do I contact the Early Adopter Program Group to apply for SMS Topaz, the evaluation program? Any comments you can make about any of that?

Wally: There are a lot of things in there. First off, beta is still scheduled for the first quarter of this year, unless something's changed that I haven't been told about, but last I was told, last week, we were still targeting first quarter of this year for beta.

The Early Adopter question, the Early Adopter program is closed. We've got all the Early Adopters we need and can handle right now. So that's not available for you. That's been closed for quite a while now.

As far as open beta, the field can nominate people for open beta currently. You'd have to go through your Microsoft contact, your Microsoft representative, and they know how to get to the beta nomination form or Web site to nominate customers for the beta. If they decide, and I don't know, I'm not involved with this, but if they decide to do a marketing beta, where it's available to everybody, I believe in the past, we've either put that on something like TechNet or MSDN. I don't recall that it's been on TechNet, maybe, maybe not, I don't recall, but on we usually put our beta code on MSDN. Sometimes we've had the ability to order CDs or request beta kits through the Systems Management Server site at http://www.microsoft.com/smserver/. So you can check there as well, but as far as open betas, nominations are being accepted right now and you'd have to go to your Microsoft field representative to get nominated for that.

We're kicking off training currently. So we're having an airlift for the Early Adopters, in fact yesterday and today. So as soon as I'm done here, I'm running back to the airlift, doing some hands-on labs there. So we're getting training out to people.

Then, we'll have additional events in the future, such as if you go to the Microsoft Management Summit in Las Vegas the very end of April and first couple of days of May, April 29, 2002 through May 3, 2002, or whatever that is that week; there'll be tons of Topaz stuff there including these labs we're doing for the Early Adopters yesterday and today. We'll have those labs available for you at the Microsoft Management Summit as well as some 2.0 stuff, other MOM stuff, and other management stuff. So it's more than just Topaz.

Release of the product as far as final RTM code totally depends upon on what the Early Adopters state as well as other people beta testing. So we're not going to release it until particularly with the Early Adopters and those of you who have beta concerns state that, "Hey, this is quality-driven enough that we're there. You guys are ready. We like it. It does what we need to do. No problems with it," or at least no major problems, because every piece of software has problems when it's released. So customers are going to drive when we actually release the product. We're targeting this year, but it totally depends upon what the beta feedback happens to be.

Jason: Why could the SMS Client Token account in SMS 2.0 not connect to network shares? I know that the SMS Client Token account is not a domain user account, but why is this a requirement for network connection?

Wally: If you look at the Client Token account, if you look at the privileges the Client Token account has in the domain, so if you go to Active Directory or your NT 4.0 domain scenario, if you look at the SMS Client Token account and look at its group membership, it's not a member, it's not a domain-type group. It's a local account. It's a restricted account, in that it doesn't have the abilities as a domain user. In fact, it's not a member of domain users.

The only group that it happens to be a member of is one we specifically create called the SMS Internal Client group. The reason for that is, we give it a couple of extra permissions for that group, plus the fact that every account has to be a member of a group. So we had to have one, but we didn't want this account going across the network. We wanted it to be a local account only, only used to create new tokens for access or isolation of processes within the SMS Client service on the client computer itself. So we didn't want it going out across the network.

Now, there are cases where it does hit, and that's why you've had some account lockout issues in 2.0, because either some SMS code incorrectly tried to use that to go across the network, or we've talked before about some, I think it was third-party audio drivers, were incorrectly hooking that account, for whatever reason, and then having lockout scenarios because this account is in a domain environment, because you have to have logon points in 2.0, and we automatically create those as site systems and as clients, so we add that account in the domain. It's the same account on the client, different password, so account lockout.

So that's basically why, it's just not given the permission to go across the network. It's a restricted account just for local access for creating process tokens, for process isolation, and for security within the client processes.

Jason: It seems to me there is no easy way in SMS 2.0 to create a random target list, because there is no machine group anymore. Are there any plans to change this for Topaz, or is there a workaround in 2.0? In SMS 1.2, we can select machines in the query and then drop into the machine group, and what I mean by a random target list is that there is no relationship between a list of machines and we cannot build the query to query SMS database.

Wally: You're correct, there is no machine group like we had in SMS 1.2, and that's been out for a long time, obviously since 1.2. What we have instead is collections within SMS 2.0. SMS 1.2 did have a drag-and-drop capability, where you could run a query, grab machines, drag them, and then drop them into your collection, where you can't do that in 2.0. The Administrator console that we have is not utilizing drag and drop.

So what you have is collections. We thought it was going to be a better scenario for you, in that you were going to use dynamic collections, and your dynamic collection could be based off of queries, which is generally what you were doing in 1.2. Occasionally, you just manually find a client and drop it into a machine group, but oftentimes you would run a query, select the query results, and drop them into a machine group.

You can do essentially the same thing with your collections with SMS 2.0 and Topaz, in that you can create a collection that is based off of a query and as that query is evaluated by the collection evaluator. If it detects that that client is a computer that's now a member of that collection, based on the query criteria, it will be dynamically added to that collection or dynamically removed from the collection, and you just target your software to that. So it's actually easier in most cases.

Now, where it is not as easy is if you want to have a manual grouping of people and computers you just drop in there every once in a while and then distribute software to. I understand that, and you can create manual collections or direct membership rules, as they're called in collections in SMS 2.0. So you can create a collection and then specifically add computers to that collection. However, it's not the drag-and-drop method. I know it's a little bit harder, but you can accomplish the same thing between either your dynamic collections or your direct membership rule collections within SMS 2.0. So you can get there. It's just not the same method as you did before.

Jason: Will Topaz eliminate the need to have a Password Never Expires checked on all SMS accounts? SMS should reset passwords consistent with the domain directory account security policy.

Wally: For standard security, no. Standard security is not changing at all, other than a few bug fixes. So what you know today for SMS 2.0 is exactly the same way it's going to be with a few bug fix-type scenarios for standard security in Topaz.

If you go to advanced security, then yes, because you're not using user accounts in advanced security. So you don't have those few little accounts that you might need for standard clients, but again, if you go to mobile clients, then you may very well be able to get by without any SMS accounts at all. Again, if you install SMS on member servers and not domain controllers, any accounts that we do create are local accounts and not domain accounts.

So you're in better shape yet, so you don't have to worry about your domain policies, but for standard security, it's not changing other than the fact that if you install on a member server, you get local accounts as opposed to domain accounts. So there's less domain impact, but from there, Password Never Expires check boxes or any other policies that are set today in 2.0 are going to be basically what you're going to see in Topaz for standard security.

Jason: Will there be a way incorporated into SMS 2.x to allow reducing the huge numbers of Systems Management Server internal and other automatically created accounts?

Wally: Sure. It's called advanced security. In advanced security, you'll be able to get rid of all those accounts that we create. If you can't go to advanced security and you have to rely on standard security, then the method is going to be, if you're in a multiple site, single domain scenario that you're using a common connection account for the server connection and the Client Connection account, maybe use a common SMS Service account. So you're reducing those accounts that might be one per site, and you have multiple sites in your domain, down to one per domain, and all your sites use that single account, but nothing other than what you're doing in 2.0 today or you have the ability to do in 2.0 today.

You may not be utilizing some of the optional methods in 2.0, like controlling your Server Connection account, your Client Connection accounts and Service accounts. You may not be utilizing that, but it is available in 2.0 today, but in standard security, nothing else is being changed there. Again, as far as a general rule of thumb, standard security is the same as SMS 2.0 security. If you go to advanced security, then yes, you can get rid of the vast majority, if not all, of those accounts, depending upon what client platform is used.

Jason: Can you briefly describe what is meant by a token?

Wally: I kind of did in the question with the Client Token account earlier, but a token is just basically a way of isolating processes within a single process. So you have the SMS Client service, which is where all the SMS client functions work off of, and in that, you have a lot of different things that are happening. You have a lot of different pieces of code that are running and doing processing.

To improve security, we're isolating each process from the other, even though they're in a single service, so each of those different threads, you're using different tokens. So a token is just a means of gaining a security identity that's unique for that one process or that one thread. We use the Client Token account as giving the ability of creating those process-level tokens. So it can create a token for a specific process, like transferring data across the wire, for generating inventory or for CCIM maintenance or discovery, whatever the case may be.

Jason: Will it be possible to remove the Windows NT client software installation account from the Site Server in Software Distribution properties if you decide not to use this account if it's already been created?

Wally: I know that's an issue in SMS 2.0. I know that if you do assign that account, then you can't get rid of the account. You have to have something there. Now, you can change it to a different account. You could change it to a bogus account that's not being used, if I remember correctly, but there is no way of clearing that account.

In Topaz, let me look, I have a Site Server right in front of me. I don't recall if we allow you to clear that option once it's been set. Yes, there is an option to clear. So it looks like we do allow you to clear that in Topaz, where we didn't in 2.0.

Jason: We are getting quite a few questions. We appreciate the questions, but we really have to set a limit as far as how many we can take.

Wally: Mixed mode is fine. As long as you're Active Directory, that's all we need. So you can have Native mode to support NT 4.0 domain controllers, if that's what your environment is. However, those NT 4.0 domain controllers can't be site systems for Topaz, because Topaz requires Windows 2000, but we just need to have an Active Directory environment so you have the Computer accounts that are full security principles for advanced security.

Jason: Will advanced security require Service Pack 2 or Service Pack 3 when released for Windows 2000 to work?

Wally: Advanced security doesn't make any difference in what level of Windows 2000 you have. However, Topaz does currently require Windows 2000 Service Pack 2 or later. So to install Topaz, you have to be Windows 2000 SP2 or later for that. Just for Topaz, yes, you have to be at Windows 2000 SP2. No requirements right now for SP3 for anything, but SP2, but not anything specific for advanced security.

Jason: The next question is a bit unclear, but I'm hoping it refers to one of your slides. Can this be started if the initial mode is standard security? I'm assuming they're maybe referring to advanced security.

Wally: Can this be started if the initial mode is standard security? There's not enough there. So I'd request that you e-mail a further clarification on there, because maybe you were referring to a specific slide, but at the time this was submitted, I don't know what slide I was on. So if you could send in a follow-up, that would be great.

Jason: If that user wants to just go ahead and put follow-up at the beginning of their message, and just type it in right where you typed in your original question, we'll make and get to it before we finish the WebCast.

Wally: It totally depends upon the security mode you're in. If you're using pass-through authentication, we certainly can do pass-through authentication. So if you're using multiple domains without trust relationships, then we go ahead and use pass-through authentication. If you're using domains with trust relationships, then we go ahead and go through the domain authentication model, but we certainly do support pass-through authentication for Windows NT or Windows 2000 environments, yes.

Jason: What is the Local System account? I've heard confusing things about its definition and roles.

Wally: A Local System account is just a security context that is available in the operating system. So it's an operating system–created account, and it's just there for running services. If you open Control Panel, double-click Administrative Tools, and then double-click Services (or in Windows NT 4.0 point to Programs, point to Administrative Tools, and then click Services; note that these instruction may vary depending on the operating system you are using) to look at your services, and if you look in the Log On As column, you'll find that the vast majority of your services are running under what's called Local System. So it's just an account that's used internally for logging on and starting up systems, because services require administrative rights to start up. So they use the Local System account as an administrative account to start up your services and give you all the permissions you need. However, it doesn't have network access because it is local system only. So it's restricted to the local computer itself.

Jason: In order to support Opal child sites, do we need to change permissions on the SMS_Site share?

Wally: On the share, no, because the site share itself should be the Microsoft standard, which is everyone full control. So if you go look at the shared permissions for SMS_Site, it should be everyone full control. However, we then do the restriction down at the file system level. So you would need to go in there and change your NTFS permissions to make sure that whatever account you're using has permissions to transfer data.

In this case, you say in order to support Opal child sites or SMS 2.0 child sites, that's not going to make any difference whether it's for SMS 2.0 or Topaz. If you're in a standard security model, you need to make sure that the Sender Address account that you're creating is either a remote administrator on the target Site Server or that the Sender Address account that you've defined to communicate with the remote site has appropriate permissions to the file directory that the SMS_Site share name points to, which again is \SMS\Inboxes\Despoolr.box\Receive. So if you go there and set the NTFS permissions, then that gives you the appropriate rights that you need.

So you need to go in there and set that to give access. What you need basically is not full control, but everything except for full control, and you need to have modify, read/execute, read/write/delete. You need to have those permissions, but since you're just giving rights to a single folder, you can certainly give them full control if you want to. That's the reason why a lot of people just use the SMS Service account or make your Sender Address account an admin so it's easy for them to set the NTFS rights.

Now, if you're Topaz and you want to communicate with an Opal child site or SMS 2.0, just take the SMS 2.0 Sender Address account and just add it to the group account that's created. The SMS_SiteToSiteConnection group, just add the Sender Address account to that group, and you don't have to worry about your NTFS permissions at all.

Jason: Do you have word on when Microsoft Press® will release anything around SMS Topaz?

Wally: I've heard nothing from Microsoft Press on Topaz. I would assume they're going to do something, but I've not heard anything from them as to what their plans are or when their releases are.

Jason: Does the local system have its own token?

Wally: I would assume so. I'm not an expert on the Local System account, but I would assume it has. Every process has its own token, so it should have its own token for security credentials. So it should have its own token, yes.

Jason: Can we control the names of the groups, or do we have to stick with the SMS default naming convention?

Wally: It depends on what groups you're talking about. If you're talking about those that I talked about in my presentation, the site address access, the Site Server access and the database access, yes you can control those. We haven't documented for you how, but it's going to be in that same .ini file I talked about before, the Smsaccountsetup.ini, most likely, and in there, you can go ahead and specify what the account names are for the groups that we create. So yes, you will be able to control those. We just haven't published yet how you do so, but that will be made available to you prior to release.

Jason: Is there any way to automatically add the SMS account to the Local Admin group on a remote server?

Wally: If you're talking about the SMS Server Computer account, to make it a local admin on the remote server, as in the advanced security model we were talking about, is there any way to automate that? You can do a command-line function, but there's nothing within SMS that's going to automatically add the Site Server's Computer account to the Remote Administrator's group. So it's going to have to be something you're going to have to do yourself, whether that's through the Active Directory environment in your user interface there or just through a command line. There's a Net Local group, so Net localgroup accountname or the groupname you want and then the account name you want to add, /add I believe is the syntax. The complete command line to use is net localgroup groupname accountname /add.

Jason: With advanced security, can domain controllers be used as Site Servers for child sites?

Wally: Yes, you can certainly use DCs as Site Servers. It's not recommended, and the sole reason for not recommending it is the fact that you create domain accounts now for any accounts that are created as opposed to local accounts. However, if you're in advanced security, then we're not creating accounts. So you're in better shape. It's just that a lot of people don't like using domain controllers for anything other than the domain controller functions. A lot of IT shops don't like you touching their domain controllers or installing any other pieces of code on them. So you certainly can do it. I'm doing it on my laptop right in front of me, my PDC as well as my Topaz advanced security site. So yes, you can.

Jason: Is Windows 2000 required on site systems or is NT 4.0 sufficient?

Wally: Topaz requires Windows 2000 and later site systems. No support for NT 4.0 site systems. NT 4.0 as a client, yes, but not as a site system.

Jason: Can advanced security be rolled back if it's found to be wanting in your environment?

Wally: No. You probably sent that in before we answered that, but it's a one-way conversion. Once you convert it from standard to advanced security, you remain at advanced security. You could uninstall your site and reinstall back to standard, but you are advanced security. There's no conversion back.

Jason: Will SMS delete the old accounts if I decide to use the advanced security?

Wally: I'm sure that question was sent in before I got to the slide as well. When you convert, no we don't delete the accounts, because we don't know if you're using them for any other purposes. So we do not rollback any of your accounts or delete them. I'm sure we will publish a list of the accounts that you can get rid of once you convert over. In the lab, I have the people who are going to do the airlift for converting to advanced security. I list all the accounts that they need to maintain and which ones they can remove in their environments.

Jason: Does using the local system or machine account cause any security issues? Can these events be audited like a user account could be audited when using the SMS Service account?

Wally: For security issues, I guess anybody could write a service that uses the Local System account, because it's a standard account there. I'm sure if you had the ability of creating a service and installing it on a system, you could go ahead and create that service to use that account. So I'm sure you could do that. Then, when you do that, since you don't have network access, you use the Computer account across the wire. So you'd have access going across the wire using the Computer account. So whatever permissions the Computer account had to the remote computer, that's the permissions that you might have as that service you created, but yes, you can audit this. So if you turn on security auditing, you'll see what accounts are being used, and you'll see local system as an account being used for running processes or accessing network resources.

Jason: I do want to take just a second to solicit some feedback from our audience. If you've come in before or if this is your first time checking out these WebCasts, we're definitely very interested in your feedback regarding them. I pull it from every session and forward the feedback to the presenter or to an appropriate manager. So we definitely do take your feedback into account. If you want to talk about what you thought of the quality of the presentation, the information presented, what you thought of Wally, what you think of me, no personal jibes or anything, but we're definitely interested in seeing what you think of the overall program and how we can improve. You can send it to us in e-mail at feedback@microsoft.com. If you do that, just put "Support WebCasts" in the subject line, and that makes sure it gets routed to my Inbox.

Wally: To use advanced security, every site system in your environment has to be Active Directory. There's no doubt about that. So every system migrated to AD? Yes, that is a requirement to use advanced security. However, it's not a requirement for every site to be advanced security. Again, you can mix your advanced security and standard security sites. However, those that are communicating do need to be Active Directory as well.

Now, we do understand that there is an issue right now that we're trying to work through in that you may want to still use a Sender Address account in your environment because of your inability or the time it's going to take you to migrate to Active Directory and then to advanced security. In that environment, we recommend a top-down approach. So you start at the central site, convert it to advanced security, which means Active Directory, and then, go down the hierarchy. That may take a while to get through that process when you have hundreds or thousands of child sites.

So we're looking at how we can solve that problem for you, still maintaining as much security as we can, but as of today, the way we sit, in advanced security there is no Sender Address account. You cannot create one. We use the Local System account, which means that we're using the Computer account across the wire for advanced security. You have to be in an Active Directory in order to communicate and use that account. That means the local account that's running advanced security needs to be in Active Directory as well as the destination site needs to be in Active Directory, because that's where you need the Computer account principle.

So until we come up with a new security mode, or at least the ability for you to assign a Sender Address account in a higher security model, that is the restriction we're living with. We hope to have a solution for you shortly on how to get around that, because we do know it is an issue, but where we're sitting today, those are the requirements we have.

Jason: What happens to site system and Site Server communication if the Site Server's Computer account password changes for some reason? For example, I may have to restore an old image of my Site Server, which has a different password than the site system is expecting. Will Site Server to site system communication fail? If so, how can I reestablish connection, reset the Computer account from Active Directory Users and Computers or something else?

Wally: The nice thing is, you don't have to control that at all. The password, you don't get to control. The operating system is going to control those. If I remember correctly, I believe it changes the password for your Computer accounts every seven days, at least I know it did when I was doing some stuff with domain controllers back in the NT 4.0 environment, and I think it does the same thing now, in that it changes these passwords every seven days.

If it's the same as it did in the NT 4.0 environment with the domains, then not only do we keep the current password, but we keep the old password in the domain model or hopefully in the Active Directory. So that if you did have it in an environment where you had to restore that image of that domain controller, because again the account and password is stored in the domain controller, it's not on the computer itself, well the computer knows what the account password is, but if you restored an old image, then the computer would try to communicate with the old password, and the domain model would go ahead and say, "Oh, this is the old password." Then, it would go ahead and allow connection, and then, I believe at that point, force the new password being generated so that you're up-to-date again.

The nice thing is that the SMS servers don't maintain the password. All they know is that you're communicating with a Computer account, but you don't supply the account name and password. You just say SMS Server 1, but you don't says SMS Server 1 and password is ABC, because you have no idea what the password is. You just say the account that's in my group is SMS Server 1. Then, as long as that Computer account has been authenticated in the domain, then it will have the appropriate security credentials and the token. Then, it will have the access to the SMS environment.

So it shouldn't be an issue for you at all, because the operating system should take care of your passwords. If you have to restore an image with an old password, at least it used to maintain the old passwords, so you were fine still getting in there and being able to get updated and get your security token created for access across the wire.

Jason: In the backup and recovery process, when reinstalling a site, one of the steps is to remove the Computer account from the domain. If we were using this for the authentication, doesn't this interfere? How does this affect that process?

Wally: If it's the same Computer account, it sounds like it fits in with the last question in that, if you remove the account from the domain and re-create it, which I don't recall seeing, but that was probably up in the first part of the recovery expert stuff on the rebuilding phase, and constant through the restore and repair phases, if you do have to do that, then when you re-create the account, so when your computer comes back up and it joins the domain again, it's going to create a new account and a new password. The account name is still going to be the same. It's still going to be your Computer account, and the password is going to be controlled by the computer and then the Active Directory environment or the domain environment.

So SMS again just knows it by the Computer account, which is SMSServer1$, so it's got the dollar sign at the end to indicate that this is a Computer account. We don't know what the password is. So what we're looking for is the account name itself with the dollar sign at the end and then the security credentials being created through the domain, just like when a user logs on and gets a security token, your Computer account will get a security token that it would have. So as long as you've got a valid security token and your account name is valid, then you'd have access to whatever rights you have according to the group membership you have.

So I don't see it being an issue. I think it's going to be something that's handled automatically for you by the operating system.

Jason: What kinds of disaster recovery will be implemented for advanced security, but I'm not as interested in standard, if for example the Active Directory and the forests or tree fails and/or crashes?

Wally: In Topaz, we provide the SMS Site Recovery Expert for you with the code. So when you install your Topaz Site Server, when you run that splash screen, when you insert your SMS CD in the CD drive or you run Auto Run (if you run it from the CD manually), when the splash screen comes up, the next to last option is Install Recovery Point. If you install recovery point, what you get is the recovery expert locally. It's installed locally for you on whatever computer you're doing the installation from; you just have to have IIS 5.0 or later.

When you do that, we go through those recovery scenarios for you, and we ask you those types of questions. So you do have the ability, we'll give you all the information you need to recover from a domain controller or an Active Directory controller having to be reinstalled. So, we'll ask you those types of scenarios, and we'll give you the information that you to know to successfully recover and repair your site in the SMS environment.

Jason: Within a site, the Site Server needs to be in Active Directory. If we want to use advanced security, do all site systems need to be in Active Directory as well? I think you might have answered that.

Wally: Yes. For advanced security, all site systems have to be Active Directory, because that's where the Computer account becomes a security principle that you can assign permissions to. So yes, all site systems have to be in AD.

Jason: I believe we answered this one as well. Are legacy accounts automatically deleted when an SMS 2.0 Topaz upgrade is performed?

Wally: No. When you go to advanced security, we leave the accounts, because we don't know if you're using them for other purposes.

Jason: What problems, if any, are there for upgrading from SMS 2.0 to Topaz (2.5?) with the additional Topaz group accounts and other security items for both standard and advanced security?

Wally: Good catch, because there is no version number assigned to Topaz yet. So a lot of people are saying 2.5, and if you're in the Early Adopter Program, you've seen some of the builds. We actually do have 2.5 there, but there is nothing official as far as what our version number is. So it's still Topaz.

Are there any problems upgrading from 2.0 to Topaz with the additional groups and so on? No, we handle that seamlessly, other than those few little things in that slide I mentioned, that the accounts are left, you have to remove what you don't want, you have to make sure that your Site Server's Computer account is an administrator of each of your site systems, and that your site system's Computer accounts are added to the SiteSystemToSiteServerConnection group. So those are some manual things you'll have to do when you migrate from standard to advanced security, but other than that, the security is all set up, because the groups are still there. The groups are there in standard security as well as advanced security.

Now, going from 2.0, you didn't have those groups. So when you upgrade to Topaz, we'll go ahead and create the groups appropriately. Then, if you migrate from standard to advanced security, you just have to make sure of those few things I just mentioned (and that were on a couple of slides), make sure that you've got the appropriate accounts in the appropriate groups.

Jason: What happens in Topaz if I try to install a program that requires administrator rights but the user is not logged on?

Wally: If you tell Topaz or SMS 2.0, for that matter, that this program requires administrative rights, we don't use the logged on user at all. When you tell SMS, whether it's Topaz or 2.0, that this program requires administrative rights, we automatically use a different account.

We don't check to see if the user is logged on. We don't check to see if it has admin privileges itself. We just go ahead and immediately use the SMS Client Token Account. So on a standard client, we would use the SMS Client Token Account, or you have the optional Windows NT Client Software Installation account. For the mobile client, you would use the Local System account.

Now, the other thing you have to look at is, make sure that your program doesn't that it requires the user to be logged on. If the advertisement states the user must be logged on, then the program won't run if there's no user logged on. Still, if you state it requires admin rights, we don't care about the user. We go directly into one of our special accounts that we use.

Jason: How does Microsoft suggest that customers record, secure, and change all of the new account passwords used in advanced security? Is there information in MOF to support all of the new accounts?

Wally: Again, in advanced security, there aren't accounts. There are the group accounts we create, but there are no user accounts unless you decide to create some of the optional accounts.

So if you need to create some of the optional accounts, then it's going to be the same type of scenario, because basically it's the same accounts that you would have had from SMS 2.0, being the Client Connection account, the Client Push Installation account and maybe the Client Software Installation account. So those would be the accounts that you're going to be creating and utilizing.

The other accounts, the Client Service account and Client Token Account, those are created on the local client itself, not in the domain. So those are local client accounts.

So, the ones that might reside in your domain, might be the Client Connection account and the Push Installation account. So those are going to be standard accounts that you're going to have control over. So you can control those any way you want to. If you make changes, just update SMS appropriately if you have to specify the account name and password within SMS. Other than that, we're not using user accounts within advanced security. We're using local system and then Computer accounts.

Jason: With the SMS Standard Client Installation account, is there a wizard to ask the engineer if he or she would like to create an Active Directory Group Policy to add an SMS standard client installation account to the local administrator's group of the domain's clients?

Wally: There's not a wizard for that. That's a manual process you'd have to go through. Now, that doesn't mean there won't be a wizard for that by the time we release, but there's nothing there today.

If that's something that you think is very important to have, you can always send your request to smswish@microsoft.com. That's an alias that's monitored by the program managers, the people who decide what SMS is going to do. So you send it to smswish@microsoft.com, and I think they've got another one smscust@microsoft.com, where you can send wishes to as well, and then say that this is something that we would like to see have happen.

Now, that doesn't mean it's going to make it, because we're getting kind of late. Beta is right around the corner. So we don't want to be having a lot of churn (last minute changes) in the code. So that doesn't mean it's going to happen for this release, but it may be something in the future or maybe a tool that's added on later on, I don't know, but as of today, there is nothing there. I've not heard of any plans of having a wizard that would ask somebody if they want to do that automatically.

Jason: We're currently having problems with client installation of SMS 2.0 on Windows 2000 PCs where users are only users. No, not everyone uses power user. To fix this, we've had to use the CompatWS template until a Microsoft fix is released. My questions are: 1) Are you aware of this problem? and 2) Is there a fix for SMS 2.0 in Topaz in the works or on the way?" As a follow-up on this query, the customer also says, The MS support page only mentions this type of problem as being caused by spaces being present in the Temp path variables. While this problem is fixed by the removal of spaces, the problem is also fixed by setting Windows 2000 users to a level along the same as NT users.

Wally: No, I'm not aware of that problem. I've never heard of the CompatWS template. Whenever I do any training, we use Windows 2000 obviously as our site systems and our clients. I always have a low rights user logged on at my client computer. I always demonstrate the low rights installation. I never use high rights for my Windows 2000 clients. I never have a problem getting the client to install properly. So I've never seen that as an issue.

Now, there are issues if you've gone in there and locked things down further than what our defaults are, but you don't have to be a power user, you don't have to be an administrator. We need to have an administrative context, so whether that's the logged on user or the SMS Client Push Installation account or whatever we called it in 2.0 now, the Windows NT Client Installation account, that's the case.

Now, if there are problems with TEMP environment variable, that's one of the things that will blow up a client installation. At an internal conference a couple of years ago, I wrote a lab on client installation where I had five different things on the client or on the site that were incorrect that the people had to troubleshoot to get the client installed properly and having an invalid Temp variable was one of those things, an out of disk space problem, not having rights to anything on the client, like a lockdown scenario, and a couple of other things.

So this specific problem, I've not heard of. I've not heard of any fix in the works for it, because I've not heard of the problem, because I use it all the time, installing clients with low rights, non-administrative users or standard users.

As of SMS 2.0 Service Pack 2, where we officially supported Windows 2000, we do have support for non-power users or above for installing SMS client software on the client, as long as your Site Server has an administrative account to push the installation down to the client computer, because the client will try to access the registry, and it will say, "Oops, I don't have permissions." So it creates a CCR almost immediately and pushes that up to the CAP, which sends it to Site Server, and the Site Server pushes out the install. It seems to work very well.

Now again, if you have TEMP environment variable problems, then that certainly is going to prevent some of the other things from even getting that far, but I'm not aware of that problem at all.

Jason: Can the Standard Client Software Install account and the Mobile Client Network Access account be the same account?

Wally: I know of no reason why you couldn't use a single account for both. They're listed separately in the user interface, but I don't know any reason why you couldn't have a single account listed as the account for both of them. I can't think of any reason at all why you would not be able to do so. So I'm assuming you certainly can have that same account being used for both purposes.

Jason: Is the Mobile Client Network Access account used only for BITS or Drizzle?

Wally: No, we don't require it for BITS or Drizzle (code name for BITS). We only need that account if the program that you're distributing requires access to another server other than the distribution point. So think of the case where you have a network setup program, so your advertising Setup.exe is what you're pushing down to the client, but Setup.exe has a path that goes out to File Server 2. File Server 2 is not the distribution point. So when you run that program locally at the client, it requires access to File Server 2. That's where you may need to use the Mobile Client Network Access account, because if you advertise this program and state that it requires admin rights, then we're not using the logged on user. We're going to use the Local System account, which doesn't have network rights. Then, you'd have to have this account to be able to access that other server.

If it doesn't require admin rights, then you just don't tell SMS it requires admin rights, and the logged on user would have access to the distribution point. You'd have to make sure the logged on user had rights to the File Server 2 in this. So it's not necessarily used for BITS or Drizzle, because you're not getting that from the local distribution point. It's getting out to another account, another server that you're using.

Jason: Are you aware of any white papers that are going to be available with the beta release that talks about upgrading to Topaz? If so, will the docs be in the beta software or the SMS Web site?

Wally: There are a lot of plans I've heard of for white papers. However, with the amount of work that needs to be done in the documentation environment, as well as getting the code out, doing training and everything else, I don't know that there'll be any white papers available for the beta release.

There will be some documentation in the beta code, so if you're a beta customer, and you get the beta software, you will have help files, and the documentation will be on the CD. Documentation people have to cut their timeframe quicker than the CD has to for shipping. So the docs may be slightly out-of-date from where the code is at the beta timeframe, because of the fact that they usually require a couple of weeks lead time to get their stuff in the correct format, legalized, and edited. So it may be slightly out-of-date, but there will be some documentation available on the beta CD.

As far as putting it on the Web site, I've not heard of any plans of putting the beta documentation up on the Web site. Again, particularly for white papers, I'm not aware of any white papers that will be ready for beta time.

Jason: During the upgrade of SMS 2.0 to Topaz, will all the Service accounts migrate to Topaz?

Wally: Yes, we'll have a clean installation or clean upgrade for you from 2.0 to Topaz. So we'll migrate all the accounts that we need up to the Topaz environment, which again is going to be all the accounts, unless you're upgrading immediately to advanced security. All those accounts will be migrated to the Topaz platform for use by Topaz.

Jason: We might have answered this. If there are any additional comments you want to throw in: Are there any issues to be aware of security-wise for site interaction while SMS 2.0 and Topaz sites are present in the hierarchy during the upgrade process or even if child sites in some areas choose not to upgrade to Topaz and stay with SMS 2.0?

Wally: No. As long as your SMS and your Topaz environments are still in standard security, then you got the same security model on both ends. The problem would be if you went to advanced security and that would mean your 2.0 site would have to be in an AD environment as well to be able to support the security principle for the Computer account. As long as you're sticking with standard security, which would most likely be the case that you want to do in that scenario, since you'd have the same security model for both sites, then there are no problem at all with communication between a 2.0 site and a Topaz parent site.

Jason: Are any Active Directory schema modules required for the advanced security model?

Wally: We do require schema modifications or schema extensions, not specifically for advanced security, but for access of Management Points, Server Locator Points, finding your site for global roaming, and so on. There's nothing specific or nothing additional just because of advanced security. It's just the standard things we want you to do for the standard security to be able to support Management Points, Server Locator Points, and discovering them out of the Active Directory from your clients.

Jason: Is there any functionality in advanced security for secondary sites? Quite often, it's unrealistic to install on the member server. Usually it's a DC.

Wally: Correct, that is the case. A lot of times, secondary sites are installed on the domain controller, a BDC, because that's the only server you have at a secondary site or at a small location. You can certainly use advanced security on secondary sites. So you can certainly do that, and if you push it out from the Site Server, we'll take of the group modifications. I mentioned that you have to add the secondary site's Computer account to the primary site's SiteToSiteConnection group, but yes, we do support advanced security down at secondary sites.

Jason: We've mentioned all site systems having to be in Active Directory. Can a CAP or Distribution Point in advanced Topaz model be an NT 4.0 member server with the Active Directory client, or must all site systems be Windows 2000 or higher?

Wally: We already answered that. Yes, every site system in Topaz has to be Windows 2000 or later.

Jason: Where can I get more information on BITS?

Wally: I was told there was a white paper up on the Microsoft.com site on BITS that was supposed to be pretty detailed. I have not had the time to go look for it, so I don't know where it's at. One of the developers, I asked him a question on BITS, and he said, "Oh, you can find this from the BITS white paper." I'm pretty sure he said it was up on the Microsoft.com Web site. Go search on http://www.microsoft.com/ and search on BITS or Background Intelligent Transfer Service and see what comes up. There is supposed to be at least one white paper up there.

{Editor's note: We were unable to locate any white papers, but you can find more information on the BITS Start Page at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/bits/drzportal_06xx.asp?frame=true.}

Jason: Can advanced security be used if child sites owned by other agencies decide not to upgrade or cannot upgrade to Topaz due to funds or licensing?

Wally: If your child site is in Active Directory, then yes, you would basically be running a Topaz standard security site, which can integrate with advanced security, but it does require Active Directory. You'd have to be Active Directory–enabled at that child site to do so, but you should be able to have 2.0 child site Sender Address account added to the appropriate group at the parent site. Then, just take your Topaz parent site Computer account and add it directly to the file system permissions for \SMS\Inboxes\Despoolr.box\Receive so that you can transfer data from the parent site back down.

Jason: As I said before, if you want to send us feedback about this WebCast or any other WebCast that you've seen, you can send it to feedback@microsoft.com and just put "Support WebCasts" in the subject line, and that assures that it gets routed to my Inbox. So I'll pull it out and send it to the appropriate managers.

I want to thank everybody for joining us today. I hope this session was useful to you. We hope you join us again in the near future. Thank you and good-bye.

Question: Are universal groups going to be supported in a Package's Access Accounts section?

Wally: Topaz does not support universal groups for package access accounts. We do support them for targeting however.

Question: Will you have setup walkthroughs and tips on the Web site?

Wally: I'm not sure what the plans are for the public Web site in this regard. I'm sure we'll offer whatever we can, but I'm not sure that we'll have a lot of extra material available prior to beta, or at release of the product. The product documentation will include setup procedures.

Question: Is Topaz going to support Mac systems?

Wally: No, you'd have to maintain an SMS 1.2 grandchild site to support Macs, as SMS 2.0 doesn't support them either.

Question: How about a resource kit tool that will identify the accounts that remain active after converting to Advanced Security?

Wally: I'm not sure a tool is really needed. It is very easy to identify the SMS accounts in AD, because most of them start with SMS. The accounts are already documented in training and other WebCasts, and you could use that to determine which accounts you can safely delete after converting to Advanced Security, and which ones do require remaining in the AD.

Question: Are nested groups going to be supported in the Access Accounts section?

Wally: It doesn't look like Topaz will support nested groups for securing package access.

Question: This is a bit off topic, but what are Microsoft's future plans regarding SMS? Will there be more products after Topaz?

Wally: Topaz is not the end of systems management for Microsoft. There is work being done today on future releases of systems management technologies from Microsoft.

Question: From the view of software distribution, slide 23 talks about a Mobile Client Network Access. Since this client is a domain user, will this solve the problem of the install-on-demand products? This is when a program is using this feature, and is also mobile that they don't have access to the feature. So will this new account somehow keep it in memory and then the next time the mobile client connects to the network, it will try and install that feature?

Wally: I don't think it is going to work the way you are assuming. The Mobile Client Network Access account will only be used for package installations (or whatever program is advertised) when the program is configured to require administrative rights. In those cases, we run under the Local System account, which doesn't have network access. Instead of using the computer account, we instead can configure and use the Mobile Client Network Access account to access the additional server. After the program has successfully run, that account is not used again (until another program requires that account). When running the application that was installed, it would use the logged on user to access the source files across the network.

Question: Can you address the known stability of the beta?

Wally: Since the product has not reached the beta stage yet, that would certainly be guesswork on my part. However, I'm sure we'll release a version of Topaz for beta that is stable enough for you to use. Not in production, but in your test labs. Of course, there will be issues with the beta, as there are with any beta product.

Question: Will Topaz streamline Terminal Server instead of Remote Tool?

Wally: Topaz has the ability to launch Terminal Services, Remote Assistance, or Remote Control to the appropriately configured clients.

Question: What changes to the distribution of client software are available with Topaz? Specifically will Topaz have the capability to push client software and/or agents to specific machines?

Wally: Client agents are still site-wide settings. So, if an agent is enabled, it would be installed and/or enabled on all clients in the site. However, since there is no concept of Logon Discovery and Logon Client Installation, you are in total control of all client installations. You must configure your own methods to install clients, such as your own logon scripts, Web pages, etc. Topaz does not provide the automated logon point/logon script any longer.

Question: What are the dates for the Las Vegas show?

Wally: April 29, 2002 through May 3, 2002.

Question: I know this chat is on security of Topaz, but I am curious about any improvements to the licensing portion of SMS.

Wally: I'd recommend you check the Overview of Topaz session that I presented on September 6, 2001. It discussed a little on the revised Software metering solution. But briefly, it is integrated into Topaz now, uses standard SMS server components and client installation methods, a single database, and revised to scale much more easily than the SMS 2.0 version. Being integrated into Topaz also means that it is easier to configure and administer. It will not however, support online metering (or enforcement by a specific number of licenses).

Question: What if you have site components placed on several DCs in the same domain? For example, the local groups will then be domain groups. Can they cooperate?

Wally: The groups that we create are only created on the Site Server and the SQL Server computer. So, you wouldn't have local groups for each site system you create. Rather, the new site systems would become members of the SMS_SiteSystemToSiteServerConnection group.

Question: The computer account A will be a member of the remote group on computer B and the opposite way too, but both site systems are DCs in the same domain, therefore, it is the same group or groups; so what happens?

Wally: All groups are specific to a site (have the site code appended to the group name), so you'd have multiple instances of the SMS_SiteSystemToSiteServer or SMS_SiteToSiteConnection groups in the domain. The exception here is the SMS Admins group, but that is created on the SQL Server to allow access to the SMS site database through the SMS provider. It won't be an issue for you.

Question: SMS 2.0 took away the ability to search for a specific file. Will Topaz bring that ability back?

Wally: Topaz does allow wildcard searches for software inventory. So, yes, you can identify a specific file to be inventoried.

Question: I had heard that there would be a tool released that would remove the need for Logon Points in SMS 2.0, when will we see this?

Wally: It is a member of the SMS Value Pack. That is a resource kit–like toolkit of SMS utilities. It is scheduled to release in Q2 of this year. There will be a WebCast on the SMS Value Pack in the very near future (tentatively scheduled for March 29, 2002).

Question: On the slide you said that if you are in advanced security mode that domain controllers are untouched unless a site system is installed on a DC. What is required in terms of your DC's security, account, and special privileges (logon as a service) for logon discovery?

Wally: There is no longer a Windows Networking Logon Discovery, so there are no requirements. You discover clients outside of logon points (which Topaz does not have). You can use either Network Discovery or Active Directory System Discovery as server-based discovery methods. For client-based discovery, that happens during the installation of the standard or mobile client.

Question: Does Advanced Security Topaz installs related to Active Directory integration?

Wally: I'm not sure that I understand the question. Advanced Security in Topaz is dependent upon the site being Active Directory enabled. So, from that aspect, it is another level of Active Directory integration with Topaz.

Question: Can Topaz be installed on Windows NT 4.0 SP6 or just Windows 2000 and .NET?

Wally: Topaz requires Windows 2000 SP2 or later, so it is not supported on Windows NT 4.0 Servers as site systems (as clients are supported).

Question: Is there an install difference for Advanced Server and Datacenter Server?

Wally: Not in regards to SMS specifically.

Question: Will the Standard Client be available as an MSI package? This would be very helpful for deployment.

Wally: No, it installs through Capinst.exe or Smsman.exe (like SMS 2.0 clients). It must have access to a CAP to install the standard client (just like SMS 2.0), but does not need access to a logon point (as Topaz does not use logon points).

Question: Can SMS 2.0 and Topaz sites be mixed?

Wally: Yes they can, with Topaz always a parent to SMS 2.0 in a site hierarchy.

Question: Why are regular workstations treated differently from mobile clients?

Wally: Because the Topaz standard client is the SMS 2.0 client, and we didn't want to use the time and resources required to rewrite it. We wanted to concentrate on the client platform.

Question: Couldn't you make one model that would fit both mobile and non-mobile clients?

Wally: You can use the Mobile Client platform on your desktop clients if you wish. That certainly is supported and works well, as long as you can live with the restrictions we discussed in the January 8, 2002 session: no secondary site support, no software metering solution, and only Windows 2000 and later. There could be changes, but that's the current plan of record.

Question: I'm not sure if you covered this or not. Currently, the client communicates with the server and vice versa using the service account.

Wally: The client does not communicate with its CAP using its Service account. It uses the SMS Client Connection account, which is a domain account, and not stored locally on the client (other than encrypted in the registry). The SMSCliSvcAcct& is used to start up the SMS Client service, and then it runs most of its processes under the SMSCliToknAcct&.

Question: If someone removes the account from the client, SMS cannot communicate.

Wally: They would have to remove the encrypted values from the registry to do so. If you mean the SMSCliSvcAcct&, then you just have to reinstall the client to re-create the account (either Smsman.exe or Smsls.bat).

Question: Other than locking down the clients, which will come, but not soon, is there going to be a way to preserve the connection between the client and the server, and vice versa?

Wally: It depends on which account you mean. If it is the SMSCliSvcAcct, then I've just offered a way to do so. However, the best security is to not allow the local users to be local admins, so they couldn't delete the SMSCliSvcAcct at all. If you mean the SMS Client Connection account, that account is only encrypted in the registry on the client, and does not appear in the client's Local Accounts database. If this did get corrupted or deleted from the registry, then you'd need to run an installation method (Smsman.exe or Smlsls.bat) to retrieve from the logon point.

Question: Why won't the remote control work on the servers that are on a remote site (different domain) while it works on the regular workstations at the remote site?

Wally: I'm not aware that it doesn't. It should work the exact same way. My guess would be security rights or name resolution or network connectivity issues. If you can't get it to work, I'd open a case up with PSS.

Question: Are there any advantages or disadvantages to having a Topaz secondary site server sitting on a domain controller?

Wally: The disadvantages are that any accounts created become domain accounts, and that you have now installed new code on the domain controller (which a lot of IT shops do not like to see happen). It is supported, but we recommend installation on member servers when possible.