January 25, 2000

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

Barbara Lamkin: Hello, and welcome to the Microsoft® Support WebCast. We'd like to thank all of you for joining us today. Our topic is "Systems Management Server 2.0 Security," and our presenter will be Doug Eby. I'm Barbara Lamkin, and I'll be your host for today's session.

We will start the session with Doug's presentation, and follow that up with a Q&A period when the presentation is done. You should see a message center to the right of the PowerPoint® slides from which you can submit your questions. If you do not see that message center option on your screen, you can expand the view by clicking the appropriate icon at the top of the page. You can submit your questions at any time during this live event, and for a few minutes after. We will hold off on answering those questions until the presentation is done.

I'd like to now take a moment to introduce Doug. Doug Eby started at Microsoft in July 1995. He has worked as a Systems Management Server (SMS) Support Professional for over two years, and has been a Technical Lead in the Systems Management Server Support Group for about one and one-half years. Thank you so much for joining us, Doug. Please begin.

Doug Eby: Okay. I'm going to talk today about security in Systems Management Server 2.0. I'm just going to go over the basic fundamentals of security, and how it relates to SMS. I'm not going to be going into too much detail in any one area, as it'd take a lot more time than what I have today.

For more information on what I'll be talking about today, and for more detail, you can look at the SMS Administrators Guide (specifically chapter four, which is all about security), the SMS 2.0 Resource Guide, and you can also find white papers and other information on the Web site at www.microsoft.com/smsmgmt. And there are public news groups you can go to at news://msnews.microsoft.com/microsoft.public.sms {there are eleven different SMS newsgroups available}, to find additional information. {If you are not familiar with newsgroups, go to http://support.microsoft.com/highlights/default.asp?pr=news&cl=182.}

On slide number 2, I'm going to go ahead and go over the overview. What I'm going to talk about is how SMS protects data through file system security; database access, which includes the SMS provider and SMS object access; how to customize the SMS administrator consoles; and I'll finally talk about how the Microsoft SQL Server™ account works.

Hopefully, by the end of my talk, you'll have a better idea of: how to choose an appropriate security strategy for your site; how access to shares, directories, and files is set up; how to use the Microsoft Management Console (MMC) security to limit access; how to use the Security Rights container to limit access to SMS functionality; and how to choose an appropriate security mode for Microsoft SQL Server.

Let's look at slide number 3, "Security Overview." Securing an SMS site means finding an appropriate balance between the need for greater security and the administrative overhead that goes with it. Now, it's important that you understand what permissions are required by SMS components for various tasks, and the options available for applying minimum or maximum security.

By default, SMS provides the minimum security settings. Many of the accounts that SMS uses are either local or global administrator accounts. Now usually it's a domain user account, which is added to the local administrators group on the site system. Creating a more secure environment will also create more admin overhead.

Now things that can be done to provide for a more secure environment include giving admin minimum rights, giving the SMS accounts minimum rights, and by installing the Site Server on a member server.

Let's move on to slide number 4, "SMS File System Security." SMS requires NTFS partitions on almost all site systems, including the Site Server, which secures the SMS file structure from unauthorized users. Now, security is generally set to provide administrators with full control, while restricting most non-admins to either read access, or no access at all.

Each of the various site system rules implement security as necessary for the SMS component or user access. Permissions to shared folders are usually left as the default of the Everyone group Full Control permissions, and then we restrict the file level security, NTFS permissions, as appropriate.

On slides 5 through 9, "SMS Site Server Security," I'm going to talk about the share level and the NTFS file security on the following site systems: the SMS Site Server directory structure itself, the client access point (CAP), the logon point, distribution point, and the software metering server.

The SMS directory is shared as SMS_sitecode. The Everyone group has full control of the share. The SMS directory is configured to allow local administrators full control permissions to the NTFS permissions.

In addition, the SMS Server Network Connection account, SMS_Site, is granted Read permissions to most of the directory structure. This allows remote site systems the ability to access Site Server for configuration information. An example of this would be if, let's say, we create a component server as a sender. It would need to access the Site Server SMS directory structure for configuration information.

The SMS Server Network Connection account also has full control permissions to different inboxes, such as the Dbm.box, or the Ccr.box folders, so that it has the ability to write to these folders when moving files from remote site systems, such as a CAP or logon point, to the Site Server.

As far as intersite communications, that's communications between a parent or a child site, we have a folder that's created for this. It's in the SMS inboxes, the Despoolr.box\Receive folder. And this folder is shared as the SMS_Site folder.

This is the share that the parent and child site send information to while communicating to the site. And again, the default permissions are Everyone with Full Control to the share. As far as NTFS permissions are concerned, the administrators group and the SMS Server Network Connection account have full control.

Now, when you have a child or a parent site, you have to create an address to come back to the site that we're talking about, and you have to specify an account. Now, if you create an account that doesn't already have directory, or NTFS permissions to the Despoolr.box\Receive folder, then you're going to have to manually add that account so it can access that folder.

Let's move on to slide number 6, "SMS Client Access Point Security." SMS clients need access to the client access point (CAP) directory structure to read installation and configuration information, as well as to write back client configuration requests, data discovery records, inventory data, and status messages. Clients connect to the CAP and to either the context of the local logged on user or the SMS client connection account. And this account is called the SMSClient_sitecode.

The CAP location must be installed on an NTFS partition, like most site systems. The CAP folder is shared as the CAP_sitecode. It's the same as the folder name. Like most SMS shares, everyone has full control to it, again.

Now, for NTFS permissions, administrators have full control, and then read permissions are given to the entire CAP structure for local users and guests, except for five folders, where they have read, write, and execute. These folders are the Ccr.box, the Ddr.box, the Inventory.box, Sinv.box and the Statmsgs.box. The clients actually write files to these folders.

The Users and Guests account is added from the local domain only. This means if you have multiple domains, that a Domain Users group from outside the local domain will need to be added to the Local Users group on the local domain. Or, if the CAP is on a member server, you need to add the Domain Users group from outside the domain to the Local Users group on the CAP itself.

On slide number 7, "SMS Logon Point Security," let's look at how the logon point role provides an initial point of contact between client computers and the SMS environment. The logon point location must be installed on an NTFS partition that resides on the domain controller. Logon points are installed automatically when Logon Installation or Logon Discovery is enabled.

The logon point directory tree is shared as SMSLogon. Again, the same name as its folder. The share permissions to the SMSLogon grant local administrators full control, and everyone else has special access permissions. This is one of the few shares that actually doesn't have full control for everyone.

File system security is implemented to restrict everyone to read or no access to the directory structure, with the exception of the Ddr.box, which allows users read, write, and execute permissions, so we can create data discovery records during Logon Discovery.

Let's look at slide number 8, "SMS Distribution Point Security." A site system that stores package files received from the Site Server performs the distribution point role. Client computers contact a distribution point to obtain programs and files after they've received advertisements from the CAP. Now, the default package share for a distribution point is the SMSPKGd$. So it's a hidden share.

Everyone is given full control permissions to the share. And also, the share can be specified as something other than the SMSPKG share when creating the package in the SMS Administrators Console.

Because SMS 2.0 requires NTFS permissions on the distribution points, file system security is useful for assigning permissions at the file system level. These permissions are set for each package that is created, using the Access Accounts object under Packages. By default, local administrators have full control to the distribution point file structure, and local users and guests have read rights. This is something that you can specify during package creation.

Now, one thing to look at would be the Knowledge Base article Q244409. If you have a multiple domain environment you should review this article. This has to do with when there's a group specified for distribution point permissions. The wrong domain may be prefixed in front of the group, so that's something that you might want to look at.

Let's move on to slide number 9, "SMS Software Metering Server Security." The software metering server doesn't require that an NTFS partition be on the computer where it's installed. This is one of the few site systems that actually allows a non-NTFS partition. The software metering server is shared as the Licmtr share, and the folder name is different. It's Swmtr. Everyone, by default, has full control permissions to it. If NTFS is used, the permissions for the directory tree are Administrators Full Control, and Everyone and Server Operators have change access.

Now, to better secure your software metering server, you can install it on an NTFS partition. You can set the Swmtr folder to Everyone Read, and give the software metering account and the SMS service account full control permissions.

The one folder that you need to have read, write, and execute permissions for everyone would be the Swmtr\Inboxes\Offline folder. Everyone needs read, write, and execute permissions to that.

On slide 10, "SMS Site Database Security," site database security is achieved by using multiple security layers between a user and the data. What I'm going to talk about here is the NTFS permissions on the Site Server folder, the SMS folder: the SMS provider (WMI) access, permissions to SMS objects, and custom SMS Administrator consoles.

Let's look at slide number 11, "SMS Provider Access." The first layer is the permission to start the SMS Administrator console on the Site Server. This is controlled by the file system security on the SMS partition of the Site Server. By default, the security restricts access to just local administrators on the Site Server, and granting other account permissions to the files required to run the SMS administrator console can be accomplished through the NTFS permissions. Just add the user to that directory structure. But with the default permissions, a user would have to be a local administrator to start the administrator console on the Site Server itself. Now, installing the SMS administrator console on a remote Windows NT® computer doesn't place this restriction, because NTFS isn't a requirement as it is on the Site Server itself.

The next layer of security is access through Windows Management Instrumentation (WMI), specifically the SMS provider. The provider controls who has access to the SMS site database. This is restricted by default to members of the local SMS Admins group. This group initially contains only the user who was originally logged on when he or she installed SMS, and the group really has no other function or permissions. It's just an easy way to grant permissions to the provider.

To grant other accounts permissions to this CIM repository and the SMS provider, you can do any of the following three things. You can add them to the SMS Admins group — again this is a local group — and it's going to be present on the SMS Site Server, as well as the computer that the SMS provider is installed on.

If we have SQL on a separate box, and we decide to put the SMS provider on that remote SQL Server, then they'll be automatically created in SMS Admins local group on the Site Server, and on that SMS provider machine. So, we'll have to add the user to both local groups.

The second way is to run the Wbemperm utility to add users or groups. By default, the SMS Admins local group is added, as well as the local Administrators group. Now, this is new in SP1. You can't see it when you start Wbemperm, but the local Administrators group, by default, has permissions in Service Pack 1. In the RTM version, the local Administrators group didn't have permissions by default.

The third way is to make the account a member of the local Administrators group. Since this group is added to the WBEM permissions by default, any user who is a member of this group will have the appropriate permissions.

One thing to note is that all access is logged to the Smsprov.log, and this is one of the few logs that is enabled by default in SMS.

Moving on to slide 12 — "SMS Security Objects" — SMS security is based on access to the database, as provided through the WMI and the SMS providers we just talked about. Now, further access to specific objects in the database can be controlled as well. The SMS Administrator console Security Rights object allows configuration of permissions to the various objects: either an entire class or individual instances.

Object access is granted on Windows NT accounts, which can be users or user groups. By default, the local system account, as well as the user that originally installed SMS on the Site Server, has access to administer all objects in the database. They have default permissions to all objects. All other users and groups must be specifically added.

Now, security rights can be assigned to the following class objects: Advertisements, Collections, Packages, Queries, Sites, and Status Messages. The specific permissions that can be assigned to objects can vary, depending on the object type. Generally, there are permissions of administer, create, delete, modify, and read, but for collections, the Advertise and the Remote Tools rights are available. And for packages, the Distribute Right is available.

There are three methods to assign rights to SMS objects. The first way is that you can right-click on the Security Rights objects in the console tree, and then create a new Class or an Instance security right.

The second way is to start the Manage SMS Users Wizard, and follow the directions to add a new account and Security Right. Now, in SP1, the Manage SMS Users Wizard now shows user accounts, as well as local and global group accounts. In RTM we had a problem showing the local groups, and we actually had some problems with global groups as well. In SP1 we do show those.

The third method is that you can go to the properties of an SMS object, and just right-click and go to Properties, and there's a Security tab that you can assign rights to.

Class security provides access to all instances of a specific class. For example, creating the Class security right for a collection gives you access to all collections. Now, an Instance right would be applied to a specific instance in that class. An example of that would be, let's say, the "All Windows 95 Systems Collection" inside of the Collection class.

One thing to note is that security rights are additive. In other words, if a single account is granted various security rights, they all combine to grant the account with the highest permissions available for those rights.

Let's look at slide number 13, "Custom SMS Administrator Consoles." Another way to limit access for specific administrators is to build custom SMS Administrator consoles that contain only the necessary SMS objects. Now, with SMS administrator consoles in MMC snap-in, it's possible to create custom consoles that only present specific objects in the console. This custom console file can be saved and made available to users as a means of restricting the objects that they can see and execute. And this deters the administrator from looking around and doing something that he or she shouldn't do.

Now, for example, if an organization has multiple administrators who are responsible for, let's say, various aspects of maintaining and administering SMS, you can create a custom console for each specific purpose. This allows the various administrators to accomplish their required work without giving them access to the resources not required.

Now, let's say we had an administrator whose only function was to create SMS packages for distribution. A custom MMC console could be created that only presents the Packages node. Now, the administrator could then create packages, programs, assign distribution points, but he wouldn't be able to advertise any packages to any collections, because he couldn't see them. The packages node would be the only node available in his custom console.

One thing to take note of is that this method is not as secure as actually setting object security rights. It's just a way to limit what's seen by administrators. And the other thing to note is that a user still needs to have SMS security rights assigned to the objects in the custom console, or else he won't be able to see those objects.

So, by tying both the SMS security rights and the custom console MMCs together, this provides a really good level of security for multiple administrators.

After creating a custom console, all you have to do is place it in the \SMSadmin\Bin\I386 folder, and this would override the default Sms.msc file, and then whenever the admin starts the administrator console, it's going to load the customized console.

On slide 14, the SQL Server account is used by the SMS services to access the SMS site database and the software metering database. Separate accounts can be used for each, or you can use the same account. These accounts are created during setup. The account used here is dependent upon the type of SQL Server security that's implemented. I'll talk about that in a second. The SMS services that access the SMS database access SQL Server directly, and do not use the SMS provider.

If standard security is used for SQL Server 6.5, the sa account may be used to access the database. If an express setup was performed at install, SMS sa will be the account used. You won't have a choice. But if you do a custom setup, this indicates SQL Server is already installed, and in this case it's going to prompt you to specify the account, and this can be whatever account you specify. No other accounts are necessary, as access to the SMS site database from the SMS Administrator console and other utilities is controlled through the WMI security.

If integrated security or Windows NT Authentication Mode is used for SQL Server 6.5, or SQL Server 7.0, the Windows NT account that the user logs on with is used to access the SQL Server. Now, in the case of SMS, this would usually be the SMS service account, as user access to the SQL database for SMS is controlled by WMI. No special accounts are required at all in this case, in integrated security.

One thing to note is that integrated, or Windows NT Authentication, is the recommended security mode for SQL Server. Standard security in SQL Server 6.5, or mixed mode authentication in SQL Server 7.0, provides greater security, but there's a lot more administrative overhead. In this way, no user can access the database without at least one SQL Server account being created manually.

If mixed security or Mixed Mode Authentication is used, then either a Windows NT account, or a SQL Server account can be used to access the SQL Server data.

Well, that concludes the presentation. It was a quick and basic presentation, but I hope it's given you a good understanding of how security is set up and used in SMS 2.0.

Barbara: All right. Thank you so much for a very informative presentation, Doug. We will now move on to the Q&A portion of the WebCast. If the PowerPoint slides were difficult to view in your browser, be sure that you download the file from the Web site. Once again, you can submit your questions in an e-mail message using the message center to the right of the PowerPoint slides.

The Q&A portion of our Support WebCast is intended to encourage further discussion of the Support WebCast topic. One-on-one product support issues are outside the scope of the Support WebCast, but 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.

And we do have several questions already waiting for us. The first one, I believe I can answer for you, and that question is: When can Microsoft provide a very highly detailed discussion, and/or white paper, regarding security issues, especially regarding the automatically created accounts?

We are always looking for additional topics, and I will be sure that that information is passed on to the coordinator for our Support WebCast, and we will look into providing a more detailed, higher level discussion somewhere in the next couple of months, we hope. Regarding a white paper, we will pass this information also to the correct group at Microsoft to have one written and reviewed and posted to our Web site. So keep an eye on the support Web site.

And our second question is: I have a customer with stand alone workstations. If the user logs into that station as a local admin, and maps and IPC$ to the LP, and runs SMS, will SMS be able to operate properly? What do I need to watch out for?

Doug: I believe that just running the SMSLS from the logon point will work just as well as running the SMSLS from a logon script. The alternative would be running SMSMAN to install the client as well. But, the preferred method is to run SMSLS in a logon script, and, if you're going to install the SMS client manually, to run SMSMAN.

Barbara: Excellent answer. We do have another question: Why are separate accounts created for every domain controller? With hundreds of domain controllers, this can be pretty worrisome.

Doug: Well, that's been a popular topic, but the main reason is so we could get more granular security. There are also several client accounts that are created on domain controllers. Each domain controller has its own account to start the client service under. Since we share the SAM database, we all need to have a different account to start the client service.

We do share some accounts, and actually, there's a KB article, Q235169, on how to reduce the number of accounts as well.

Barbara: Thank you, Doug. We do have a couple of more questions: The automatically created accounts are all marked "Password Never Changes." Are the passwords ever changed by SMS, and if so, can you discuss the mechanism that SMS uses to do this? How might that mechanism break, and how might we detect that and fix it?

Doug: That's a pretty advanced question, actually. SMS does periodically change passwords. They're created randomly by SMS. They are strong passwords. If, for some reason, we can't start a service that started under one of these accounts, then it is possible that we'll reset that password, or re-create the account itself. Now, during a site reset, many of these accounts do get their password reset as well.

But, for more information on this, I believe that there are some resources, possibly in the resource guide, and possibly a white paper that's going to come out shortly in the future. Or, actually a Support Professional would be able to help you with that as well.

Barbara: All right. And, those kinds of resources are available on the Microsoft Online Support site, so keep an eye out there.

Our next question is: When a client access point is in a resource domain, why are users unable to complete the installation of the SMS client software properly?

Doug: Actually, this is a fairly popular support call. This usually occurs when SMS is in a resource domain, and the client connection account — that's the account I specified earlier, the SMS_sitecode — is in the master accounts domain. Well, on the CAP, by default the permissions are for local user and local guest.

Now, if the client connection account is in the master accounts domain, this isn't going to be added to the CAP by default. So, what you'll probably have to do is add the domain users group from the domain where the SMS client connection account is located to the local users group of the domain where the CAP is located. And if you have multiple CAPs in different resource domains, then you'll have to do this in each of these domains.

Now, the other thing to keep note of is, if you have a CAP on a member server, then instead of adding the domain users group from the domain where the client connection account is located, you'll have to add the domain users group to the local users group on the CAP itself. And that should give you the appropriate permissions to talk to the CAPs. And, that should help you with the installation.

Barbara: Super answer. Thank you.

Our next question is: What do I do if a user corrupts the original SMS snap-in file?

Doug: Actually, what you can do is, on the SMS 2.0 CD, you can just copy the Sms.msc file to the Site Server, or the remote console machine, and just overwrite the corrupted Sms.msc file. This file is on the CD, and I believe it's located in the SMS\Setup\Bin\I386 folder. And you just overwrite the one that's been corrupted.

Barbara: All right. We do have quite a few questions, now. Thank you for your active participation.

I believe I may be able to answer this one. The question is: Are there any white papers describing recommended best practices for modifying the default security?

Again, your best option is to go to the Microsoft Online Support sites, and query for white papers, and include your topic name.

Do you have any additional input on where we might find that white paper?

Doug: Actually, you can look on the www.microsoft.com/smsmgmt Web site for current white papers, and we do have some security white papers that give a more detailed security description coming out in the near future.

Barbara: Very good. Thank you for the location of that Web site.

We do have several more questions, and it's always good to see active participation here.

And our next question is: How will the next version of SMS be integrated into Active Directory?

Doug: Okay. Actually, I have Dan Conley. He's a co-worker of mine, and he's going to be happy to answer that one for you.

Dan: Yes, actually I'm a Beta Support Engineer right now, working on the beta for Service Pack 2 for SMS 2.0, so I think I could probably field this one.

Basically right now, the best answer I can give you is, Service Pack 2 for SMS 2.0 will actually provide us some added functionality with Windows® 2000. At this time, we haven't released the official statement yet, but you should expect to hear the official public release on what actually we're going to support in Windows 2000, right about the time we release the beta version of SMS 2.0 Service Pack 2.

And incidentally, if you're interested in taking a look at what that'll be like, also on www.microsoft.com/smsmgmt, there's a section there where you can actually nominate yourself for your company to receive the beta CD. And right about that time, that should hopefully give you a real good idea of where we're going with Service Pack 2, and SMS, and Windows 2000.

Barbara: Thank you, Dan.

We have a short question coming up next: Is there a way to repair a client installation without being logged on locally?

Doug: There is. Well, actually that's a hard question. CCM, the client configuration manager on the Site Server, can install clients remotely if the client isn't a local administrator. But, it depends on what state the client is in. If it's still running the logon script, then possibly the client can be repaired. It just depends on the state that the client is in. That's a hard question to answer.

Barbara: Sometimes the short questions are tough. I'm familiar with that.

Our next question is regarding senders: What are the least and the most access restrictions required on senders?

Doug: Boy, I'm not completely sure about the answer to that question. Do any of my colleagues have an answer for this person? Yes, actually the most access would be admins with full control. But, as far as the minimum access, I believe that the account that is used when sending needs to have at least write permissions to the Despoolr.box\Receive directory. That's the directory that we actually talk to when we're sending to another site. So, I believe we'd at least need write access.

Barbara: All right. And, if that doesn't take care of your question, will the sender please send us a further elaboration on what information you were looking for? In the meantime, I believe it sounds like we have consensus that we may do a little bit more research on this topic, and we will include that in the transcript when that is finished. So, keep an eye on the Web site for the transcript {Additional research proved that the answer given was complete}.

We have another question here, and this one says: The documentation states that we should regularly create new client connection accounts, and delete the old ones in order to maintain security. How do we know when all clients have synchronized with the new connection account details, and it's safe to delete those old account details?

Doug: Well, I can't think of a way that the clients can be checked for these accounts. These accounts are encrypted, as well as the passwords. I guess, you know, the client, every 23 hours, goes up to the CAP and gets the information. Assuming that the information has been updated on the CAP, that is a fairly safe assumption if the client is either running logon scripts (getting the information from the logon point every time it logs on) or it is getting the account information from the CAP every 23 hours.

It's always a good practice to let your clients, after adding a new account, sit at least 48 hours, just to make sure. And there are always going to be some people that are on vacation for a week or two, and their machines are going to be turned off. So, when they turn their machines on, if they have a logon script, then it should update at that point.

Now, it gets a little more complicated if there has been a remotely installed client. If these machines are turned off for a couple weeks, it could be possible that these clients can be orphaned. That's why it's always a good idea to stagger deleting these old connection accounts and adding the new connection accounts. And it's always a good idea to have at least two or three connection accounts, just in case something like this happens.

Okay, actually Eric, one of my co-workers here, has something to add to that.

Eric: One of the most common things that we hear is that an administrator will go in and, for whatever reason, change the password on this default account and on the default SMS client connection account. And, if you haven't pre-created a secondary, or a backup client connection account, this is an encrypted password, and basically there's no way for you to let your clients know of this encrypted password.

So, if you create the backup client connection account, you have obviously specified the password, and you will always be able to add that back into your site properties at a later time, if for whatever reason the site looses the account, or the client is unable to connect.

That can help you there.

Barbara: All right. Thank you for the elaboration, Eric.

If you do have any suggestions for topics for future Support WebCasts, you can also send those to us using the message center now, and immediately following this session. Should you later decide to send feedback, please use the feedback@microsoft.com alias, and include Support WebCast in the subject line.

Our next question is regarding user accounts: Why aren't user accounts given permissions to the Site Server directory structure?

Doug: Actually, user accounts shouldn't have permissions to the SMS directory structure because they should either talk to a CAP, a logon point, or a distribution point, depending on what they're trying to do. The SMS services themselves should only be the users that actually access the directory structure, except for maybe the SMS_sitecode accounts, when it copies files back to the Site Server.

Otherwise, users really don't need any access, and you wouldn't want users to have access to the directory structure, so that users wouldn't be able to manipulate any files that you wouldn't want them to manipulate on the SMS directory structure.

Barbara: Very good information, thank you.

The next question is discussing SQL Server security: In that regard, isn't standard security much more powerful than integrated? Do you have any other considerations that we should take into account?

Doug: Well, without going into much detail at all, it is true that standard security is more secure than integrated. The trade off is that you would have more administrative overhead, and if you don't mind the administrative overhead, then maybe standard security is the best for you.

As far as any other considerations, I can't think of anything, but Dan Conley would like to talk about that.

Dan: Maybe one of the other considerations you might want to look into is the fact that, if you're actually running your SQL Server on a separate server that's actually now being shared with other database applications. It is going to be a big decision factor on if you're going to go with standard or integrated security. That's basically the first to have popped into my mind. So, depending on if your other application requires you to have integrated security, so the other apps can use the same SQL Server.

Doug: A lot of times SMS administrators are not SQL administrators, so they're not very familiar with the SQL enterprise, in dealing with SQL security, so that's a common reason also.

Barbara: All right, thank you gentlemen.

We have another question regarding primary sites and secondary sites, and what kind of tools. The question here is: We have 11 primary sites and over 100 secondary sites. What tools are provided to permit automatic configuration and subsequent monitoring of the security setup of these sites?

Doug: Okay, Eric Kratzer has a comment for this question.

Eric: There's a resource kit utility — I believe it's called SMS Properties Manager, or something like that. It's Smsspman.exe. You can find this in the Resource Guide of the BackOffice® Resource Kit 4.5. Basically, this will allow you to export a particular set of site properties, anything from one specific detail property of say, heartbeat discovery, or full properties of your entire site.

Say you want to clone your site properties out to your 100 secondary sites. You could export this from one site and then import this and select the number of sites that you would like to import those properties into, and you can do that all from within this one utility, in kind of a single instance there. But again, remember that it is a resource kit utility, so it isn't fully supported. So, you may want to test this in a test environment before going into production with it.

Barbara: All right, good information.

Our next question has a lot of details, but I think it really is a global question that we'll be able to work on here: We recently ran into a situation when we had our SMS site blow up. We re-created the site, and the sites and the clients that were remotely installed could not connect via the client connection account. We had to manually run SMSMAN on each client to get the updates to them.

Doug: Okay, actually this is a problem that we run into quite often. And that's why we recommend that you create a second connection account, right after installation. This way you know the name of the account, and you know the password of the account. The one that's set up by default is a randomized password, so if your site does blow up, and you re-create the site, then it re-creates the account. And it might have the same name, but it won't have the same password, because it's randomly created.

Now, if you had an existing second connection account that you created, you could add it back as soon as you re-create your site, and add the password that you had before. The client should be able to talk again to the CAP.

Now, it is unfortunate if your site does go down, and you have remote client installations out there, remote pushed clients. They do get orphaned, and pretty much the only way to get them reinstalled is by running SMSMAN on the client, or by enabling logon scripts for those, which isn't the preference usually.

One thing to note, I believe it's in 60 days that these clients will be removed, and once they are removed, then you can do another remote push. But, 60 days is quite a long time to wait.

Barbara: All right, thank you very much.

Our next question is: When I attempt to create a custom MMC snap-in for SMS, it always displays the default SMS console objects. Can you tell me why that's happening?

Doug: Well, what may be happening is that when you start the Site Connection Wizard — it's the wizard that starts when you add the Systems Management Server snap-in to the MMC — by default, all items are selected. It's kind of hard to see; it's towards the bottom. If you select the Custom option, you'll get a window that shows all the different tree items, and then you can select or deselect any of the items that you want to customize the snap-in.

Barbara: Excellent answer.

Our next question asks: The reducing accounts first appeared in the SMS product flash on 16 July 99, not the SP1 release notes, regarding article Q235169. Can you shed any light on that?

Doug: Actually, I don't have the article in front of me. If you're referring to the Q article that talks about minimizing the amount of accounts that are created in a domain, that is something that I think we've said we can post some information on. Maybe we can shed a little bit more light on that article. If you could write back in and explain what new information, or what other detailed information you need from that article, then maybe we can send that as well.

Barbara: Okay, we will follow up with the customer who sent that question, and include that information in the transcript {It was determined that article Q235169 has complete information, and no additional information is needed here}.

And our next question is: Does SMS work in a lock down environment? Does SMS require full admin rights on the client in order to install and run?

Doug: Okay. SMS does work in a lock-down environment. There are some things that you can watch out for, and actually, there were some problems with, let's say the client token account, causing lock-out problems. We have recently released a client bundle hotfix that does address those issues.

Barbara: Does it require full admin rights on the client?

Doug: If the user that logs on to, let's say an NT machine has full administrator rights to that machine, then no. We wouldn't necessarily need full administrator rights. But, if we are a low rights user, let's say, not an admin, then what we do is we create a CCR file up to the CAP. It sends it over to the Site Server, and then Client Configuration Manager uses the SMS service account.

Or, if you have a Remote, Client Installation Account specified, it'll use that account first, to connect back to the clients Admin$ share, and install the client. So, at that point, we would need to have administrator rights, or at least rights for the SMS service account, or the Remote Client Installation Account.

Barbara: Very good information. Thank you again, Doug.

Our next question is: I'm new to SMS. Is it possible to have one SMS server to manage multi non-trusted domains? If it is possible, how?

Doug: Well, we do have customers who do have one SMS server in non-trusted domains, but it's really not a good setup. What you can do is, most of the time, you'll have to create the service account in each of the domains and use pass-through authentication so the service account would have to have the same name and password.

Now, one thing to note is that Remote Administrator consoles don't use pass-through authentication, so you'd probably be limited to where and in what domains you'd be able to have the remote administrator console in. And, actually, a future white paper will talk a little bit about pass-through authentication, and the different domain models, and so on. And, we're hoping that this paper is out in the near future. And that can be found on the SMS Management Web site, as we've pointed you to before.

Barbara: All right, thank you.

Our next question asks for a potential release date, and the question is: When will the server bundle be released? Do we have an idea on that one yet?

Doug: Actually Dan Conley can address that question.

Dan: Yes, actually I don't have an exact release date for you on this. I can tell you that it is going to be very soon. It's in the final testing stages right now, because we want to make sure it's very stable and it's not going to cause you any more pain, before we release it. So, basically my best suggestion is to go ahead and hang tight, and it should be out there very, very soon.

Barbara: All right, thank you.

Our next question is: How do I get the client bundle hotfix for the client token lock out?

Doug: Okay. What you can do is call the Support line and talk to a PSS engineer for SMS. And we won't charge you for the call, as it is a hotfix bundle. You just call a Support Engineer, and we'd be happy to send it to you.

Dan: Actually, I want to add one comment back to the user who had the question about the multiple non-trusted domains. You know, they mentioned they're very new to SMS, and I want to make something really clear, that, right now, SMS deals in site boundaries, which are IP sub-nets. And I want to make sure that, when you're thinking about putting this in your bunch of non-trusted domains, all these domains are connected by fast, reliable links.

One of the biggest support calls that we get a lot is people trying to stretch their SMS site boundaries across slow WAN links. And that is not a good idea. And that will actually cause you more grief than anything that's going to help you out.

Basically, the definition of an SMS site is a collection of resources connected by fast, reliable links. So, when if anyone that's now sitting down and planning how they're going to deploy SMS 2.0, please keep that in mind. And if you do have remote sites, please go ahead and consider using secondary sites across those slow WAN links.

I hope that helps.

Barbara: Very, very good information. Thank you so much for the elaboration.

A follow-up question on the client hotfix bundle. The question is: Do you mean that the client hotfix bundle is available now?

Doug: Yes it is. It was released last week.

Barbara: Excellent, thank you.

We are down to the last question. And our final question at this moment is: Do global groups work for SMS 2.0 security rights?

Doug: Okay. Actually, in SMS 2.0 RTM, we did have some problems in assigning security rights to groups. But, in SMS SP1, they do work pretty well. You can assign permissions to them.

Barbara: Excellent.

At this point, we have answered all of the questions that were submitted. So that's going to wrap up our session today.

I want to thank all of you for participating in today's Support WebCast. And I do hope this information was useful to you. We are very interested in your feedback regarding the WebCast program. The message center link will be available for you to send that feedback for a few more minutes.

Otherwise, if you want to send comments or suggestions later, use the

e-mail alias feedback@microsoft.com, and be sure to include Support WebCast in the subject line.

We hope you'll join us again in the near future. Thank you, and goodbye.