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

Heidi Moeller: Hello and welcome to the Microsoft Support WebCast. We'd like to thank all of you for joining us today. Our topic will be "Microsoft Systems Management Server 2.0 Accounts." Our presenter will be Wally Mead. I am Heidi Moeller. I'll be your host for today's session.

We'll start this session with Wally's presentation and follow that up with a question-and-answer period when the presentation is finished.

You should see a Message Center to the right of the PowerPoint® slides from which you can submit your questions. You can submit your questions at any time during the live session via the Message Center. However, we will hold off on addressing those questions until the presentation portion of this session is finished.

I'd like to now take a quick moment to introduce Wally. Wally Mead joined Microsoft as a trainer back in 1992. He's been involved with SMS training since the SMS 1.0 beta, and has been focusing on the SMS 2.0 product for more than two years. He currently works for Product Support Services, generating and delivering Systems Management Server 2.0 training to Microsoft Support Professionals.

Thank you so much for joining us today, Wally.

Wally Mead: Thank you. Welcome to you all. Hope you all are having a good morning, or afternoon, wherever you are.

So, in our session today, we're going to talk about SMS 2.0 accounts.

On the overview slide, which is where we are now, the big questions that a lot of people have on SMS 2.0 is, "Why do we have so many accounts?" As you know, if you are familiar with 1.2, we had many fewer accounts active. Now, in 2.0, we have many more.

So, just to address that, first off — the biggest reason we have so many accounts in 2.0 is to provide better security than we had with the SMS 1.2, and previous versions, 1.0 and 1.1. As you've realized, if you're familiar with previous versions of SMS, we had the one account, the SMS Service Account, that was pretty much king of the entire environment for SMS. It could do anything it wanted to do, and was a Domain Administrator and had all permissions everywhere.

In our attempts to make 2.0 more secure, it became necessary to create additional accounts to separate processes and to keep different functions local, such as administrative access. So, we'll discuss that much more as we go through.

A couple of general guidelines you have on your accounts are that, for the most part, the administrator has a little bit of control over some accounts. Some accounts you have great control over, such as the SMS Service account. You can set the name, the password, and some of the permissions for it. Other accounts, you have a little bit of control over — you might be able to designate what the account name is, or what domain the account resides in. Other accounts you have no control over at all, such as a lot of the client connection accounts and the client service accounts — you don't have any control over those, for the most part. We'll go through those as we go through the different accounts. I'll talk about what you can do with those accounts as far as local administration. As a general rule, the server accounts tend to provide a little bit more functionality as far as administrative control than the server-based accounts do.

On SMS 2.0 accounts, the different sets of accounts that we'll talk about are just in categories. We'll talk about the SMS Service account a little bit. Then, we'll focus a lot of time on the SMS Site System accounts, as there are a number of those. We'll spend some time on those separately. We'll talk about the SQL Server™ accounts that SMS uses to talk to the SQL Server database. We'll talk about the SMS accounts that are created specifically for Windows NT® clients. In a 9x or Win 3.1 environment, you don't have to worry as much about those accounts, but for an NT environment, we create a number of different accounts for those NT clients, due to permissions aspects and different contexts of who's logged on with permissions. Then, we'll talk about several more internal accounts for SMS and the clients. Then, lastly, we'll talk about integration with NetWare site systems. If you're integrating in a NetWare environment, we'll talk about what accounts you have to create and how we interact with those.

The SMS 2.0 Service account: again, if you're familiar with SMS 1.x, it's basically the same type of account. It's created and modified during SMS Setup. So, as you do your installation of your primary site or secondary site server, one of the questions that's asked on one of the wizard pages is, "What account do you want to use as your SMS Service account?" It has a default name of SMS Service. You can use that, or you can go ahead and change it if you wish. And you can designate a password.

If that account has not been pre-created in your domain, SMS will create that account during the setup process. If you need to modify that account later on, you can go back through setup and choose the option to modify or reset current installation. You can change your account name and/or password.

If you do change the account name and/or password, you probably should change it in User Manager for Domains first, especially if you're just changing the password. You want to change it manually. Then, go to SMS to change.

The account created is a member of the local administrator's group. It is also created, by default, as a member of the domain admin group. It is a Domain Administrator group. I'll talk in just a minute about how you can change that if you wish, but by default, it is a Domain Administrator.

It is also a member of the Domain Users group.

The account is used to start up almost all of the SMS services on the site server. It's used to start up the SMS Executive, the SMS Site Component Manager, and the SQL Monitor Service if SQL Server's running on top of the site server. It's also used to start up the SMS Site Backup service, which is a new service in SMS 2.0 SP1, as well as starting up the Crystal Reports services, the Info Agent, Info APS, and Info Sentinel services. Those services are all started up using the SMS Service account.

One thing some customers want to do is to try to make that account more secure. As setup does create it as a domain administrative account, you can change that account properties and make it a member of just the local administrative group if you wish, and not a domain admin. If you do that, you have to be careful to make sure that that account has administrative permissions on any other Windows NT server you want to use in your environment. If you want to set up a domain controller or a client access point or distribution point, this account has to be an administrator at that computer in order for SMS to interact with that remote computer. There is another option we'll talk about on the next slide if you don't want to use that.

So, that's the SMS Service account. Again, it's used primarily on the site server. Occasionally, it does cross the network. We'll talk about how you can restrict that if you wish. This is the account in SMS 1.x that was basically the only account we had. It did everything, all NT clients as well as all Windows NT servers.

Next, we'll talk about the different site system accounts. There are a lot of different SMS Site System accounts that we'll go through.

The first set is the SMS Remote Service accounts. The SMS Remote Service accounts are accounts that we create on SMS site systems other than the site server. For example, a client access point, a logon point, a distribution point, software metering server, etc. Those are the accounts that we use to start up the Remote SMS site system — or excuse me, the service on that system. On a client access point, for example, we create the SMS Executive — it starts up on a client access point. Its purpose is to run a thread, called the Inbox Manager Assistant, which copies any client data files that clients send to the client access point. It copies them over to the site server: {files} such as discovery records, hardware/software inventory, status messages, or CCRs (client configuration requests).

Because we're starting a service locally on that client access point, the SMS Executive, we need to have an account that it starts up under. So, we create a Remote Service account. The account we create on a client access point is SMSServer_your sitecode_, and then four numbers to indicate the sequence of that account. That account is a local administrator account. It is used to access the local computer, being the client access point, as well as to start up that service. That account does not access the network. It is not used to transfer the data from the account to the site server. A different account is used for that. That's the next account, the SMS Server Connection account.

That account is also created on a SQL Server if your SQL Server and site server are not the same computer. It will use that same account name, SMSSvc_xxxx. The reason for the four digits is, if you are in a domain environment, and your site systems are domain controllers, you don't have a local SAM where this account is normally created. You have a domain SAM. Each remote site system would have a separate account to start up with, so we increment the last four digits. 0000 would be the first one, 0001 would be the next, and so on.

So, this account, the SMS Server, SMSSvc_sitecode_xxxx, is used by remote CAPs and remote SQL Servers.

Another SMS Remote Service account we create is the account for logon points. When you enable Windows Networking Logon Discovery, and/or Windows Networking Logon Client Installation, we install that domain controller as a logon point. Particularly for the Logon Discovery process, we create a service called the SMS NT Logon Discovery Agent. Its purpose is to take DDRs, discovery records that were generated by clients during the logon process, and to transfer those over to the site server.

The service needs the account to start up again as a local administrator. That account is SMSLogonSvc. That account is created in the domain that that logon point is a member of. Since it doesn't have a local SAM, it has a domain SAM, we create the account in the domain: SMSLogon Svc. It is a local administrator, but again, that account did not use the transfer data from the local logon point over to the site server. That is the next account, the SMS Server Connection account.

So, the SMS Remote Service accounts are used to start up SMS services on non-site servers, start up the appropriate SMS service, and interact with the local computer. From there, any data that needs to be transmitted from that site system to the site server uses a different account. That account is the SMS Server Connection account.

The SMS Server Connection account is the account that, by default, is titled SMSServer_sitecode. That account is the account that's used by CAPs and logon points to transfer data to the site server itself. This account is created during setup, automatically. But, in Service Pack 1, there is the ability for you to change that account name or designate the password. There is a command-line switch you can run on setup if you want to designate this account. The switch is Setup/Server account domain_account\user_account /server password account_password. You run SMS Setup with that switch. It will go ahead and create the account that you designate as opposed to the standard account that we would create, SMSServer_sitecode.

You can also create a test file called Smsaccountsetup.ini, and place that in your System32 directory. That would list the same parameters: the server account and account name, server password, and the appropriate password. Then, any time you ran setup, provided that file was still in that directory, the Win NT\System32 directory, we would go ahead and use that account.

If you don't do that, then we're going to create that account. When you run your setup process, we'll create the account. We'll set its password at that point. Any time you were to do a reset of your site, using the Modify or reset current installation option, you would go ahead and change that password as well, and then push that account parameter out to your remote site system, so they knew the account and password was to talk back to the site server.

One of the difficulties you have is in environments where you might have a lot of SMS sites sharing a single domain, which is fairly common. In that environment, if you were to set up separate SMS sites on each one of your backup domain controllers spread throughout the United States or the world, each logon point would be shared by all other sites if you were to turn on Logon Discovery, Logon Client Installation.

If you have Logon Discovery turned on, then all those sites are going to share the same domain for Logon Discovery. When you set up those different sites, we're going to go ahead and create the SMS Server Connection account for each site. So, in that one domain you're sharing, you may wind up having numerous SMSSvr_sitecode accounts, one for each site you have. That can be a burden to some customers when you have hundreds of domain controllers, and each of those domain controllers is set up as a separate SMS site.

In an effort to reduce the number of Server Connection accounts that are created, we've implemented the command-line switch and the Smsaccountsetup.ini text file that I talked about before. That will allow you to designate the accounts you want to use. And all of your different sites can share that same parameter and that same account so that you can reduce the number of accounts created down to a single Server Connection account. That account, again, is used to transfer data from Remote Site Systems to the site server itself — primarily from the logon point or from the client access point.

The next account we have, the SMS Server Network Connection account, is an optional account. It is not created by default, but it is one you can create if you want to control the site server's interaction with your remote site systems. By default, since we don't create this account for you automatically, we'll use the SMS Service account. That is why we create the SMS Service account as a Domain Administrator. That way the account should have permissions on all other site systems you have in that same domain.

If you don't want to do that, if you want to take your SMS Service account and make it a local administrator and not have that account leave your site server itself, you can create the SMS Server Network Connection account. Where you create this is in the SMS Administrator console, in the site database, and then your sitecode, site settings, connection accounts, and then site system. You go to that location in the Admin console. Do an Action, New, then you choose Windows NT account. When you create a new Windows NT site system account, this is what we're calling the SMS Server Network Connection account.

If you do create that account, you have to manually create it in your domain. Then you go ahead and designate it in the Admin console. Then, whenever the site server needs to talk to the CAP, or a logon point, or any other site system, it would use this Server Network Connection account as opposed to the SMS Service account, provided the account was valid and it did have administrative permissions on the remote site system. That allows you to designate a different account other than your SMS Service account as the account to use to talk to your remote site systems.

A lot of customers find that very beneficial. You can create numerous of those accounts. We'll start at the top. We'll go through each of those different accounts until we find one that works. If none of the Server Network Connection accounts you create are able to talk to a site system, then we will go down and try the SMS Service account. The account would need to be an administrator account on your remote site systems.

In the environment where you're integrating with Novell NetWare in an NDS environment, you do have to create this account as a NetWare NDS account. We'll talk about that later on, but I just wanted to point that out here as well. So again that's an optional account. Sometimes, again, it's called the Site System account.

The next account is the SMS Site Address account. The SMS Site Address account is the account that's used when one SMS site transfers data to another SMS site. When you have a parent-child relationship, and you're transmitting data between the two SMS sites, this account is used to transfer data. This account is designated by the administrator when you create the address for the parent site or the child site. As you're creating your site address to another SMS site, you have the option at the bottom of the General tab to set the account. You need to designate the account name and password that you want to use to connect up to the remote site.

A lot of times, customers will use the SMS Service account in this environment. That is okay if you don't mind having your SMS Service account shared among multiple SMS sites. The downside to doing this is that the remote site has to create the address back to your site. So, if you want to use your SMS Service account, you would have to tell the remote site, "Here's my service account. Here's my password." As you may know, by default, the SMS Service account is a domain administrative account. If the account is a domain administrative account, then they now have access to an administrative account in your domain at your site, which may be giving them more access to your data than you really want to give them. So, you may want to create the Site Address account.

You create this in your domain. It doesn't have to have any special permissions in your domain — you can create it as a domain user. Then you designate it when you create an address to an additional SMS site.

Now, the permission that this account needs is to the directory structure that the sender is going to connect to when it transfers data to your remote site. That location is on your site server in the SMS\Inboxes\Despooler.box\Receive directory. That directory structure, this account that you're creating — the SMS Site Address account — needs to have permission added manually. If you look at that location by default, we have the SMS Service account — it has full permission, or administrators have full permissions — as well as the SMS Connection account. So, the SMS Server Connection account has permissions. However, you don't know what the password is for that account unless you're controlling it through the setup switch.

Create your account, designate it here. The permissions you need to give it are not full control, but you do need to give it change permissions. When you create your SMS Site Address account, you assign it to SMS\Inboxes\Despooler.box\Receive directory, and you give it change permissions. It needs change permissions because, when we connect up to test connectivity to the remote site, we create a temporary file. So we have to be able to create files and write data. Then we delete that file. If we can successfully create and delete the file on the remote site, then the sender will go ahead and transfer the appropriate instruction file, as well as the package data, and transfer that across to the remote site. So, you need change permissions there, but you don't need to give them administrative permissions, nor do you need to give them full control permissions.

Now, the one case where this account does need administrative rights is if you're going to set up a secondary site over the network — if you want to install a secondary site, and you're going to initiate that installation from the primary site. So, you sit at the primary site, you go to your site code, you do an Action, New, Secondary Site. You initiate it from there. What we do, in that case, is we connect up to the Root$ share of the drive you designate during the Setup Wizard. We connect up to the $ share, which means you have to have administrative rights. In that case, this account would need to be an administrator. Once you've set that secondary site up, however, you can change the account from being an administrative account. You can demote it to just a domain user, and then individually assign access rights to that directory structure — again, the SMS\Inboxes\Despooler.box\Receive directory.

You can actually have a separate SMS Site Address account for every single one of the sites that you have set up. So, for each address, you can designate a different account, or you can designate the same accounts if you wish.

The last one of the site system accounts we'll talk about is the Software Metering Server account. I mentioned earlier that, technically, it fit in under the SMS Remote Service accounts. It can because this account is used to start up the SMS Licensed Server Service on a software metering server. So, when you designate a Windows NT computer to be a Software Metering Server, we ask you, on the page where you enable the site system, for an account to use.

The default account is SWMAccount. We recommend that you change that, and you actually designate a domain context for that account. So, you would change that to say, Domain 1\SMS account, or SWMAccount, or some other account you want to use. If the account is not created, we'll go ahead and create it automatically. The account is used to start this service. So it is a local, administrative account, but this account is only used to start up the service, the SMS licensed server service, on the Remote Software Metering Server and to interact locally with the software metering data cache. It does not transfer any data over the network. It doesn't interact with clients at all. Clients connect up to the Software Metering Server to transfer data and request licenses. The site server connects up to the Software Metering Server to pull usage data and to push down product data as well. So, it's solely a local account for that box.

The reason I separate it out from the SMS Remote Service accounts is that you have a lot more control over this account than you do the other SMS Remote Service accounts. You can't control the SMS Logon Service account. You can't control the "SMSSvc_sitecode__xxxx account. You can't control those. SMS creates those and handles those on its own. However, you do have full capabilities of controlling the Software Metering Server account. That's why I listed it separately.

Just as a quick recap on these accounts, you don't have a lot of control over the SMS Remote Service accounts. You can control the SMS Server Connection account from the aspect that, if you want to use the command-line switch or the .ini file that I mentioned earlier, Smsaccountsetup.ini, you can control the account name and password. You have full control over the SMS Server Network Connection account. You create it, you designate it, you assign it. SMS Site Address accounts — you have full control those. If you do create one that is not an administrative account, you need to remember to assign permissions to the Despooler.box\Receive directory. You have pretty good control over the Software Metering Server account.

Next, let's talk about the SQL Server account. The SQL Server account is the account that's used by the SMS services themselves to access the site database. If you were in Doug's session last week where he talked about SMS security, he talked about the SMS Provider. The SMS Provider is how we control what users have access to the SMS site database. Well, the SMS services don't use the SMS Provider. They go directly to the SQL Server because there are services. We know exactly what they're doing. We know who's doing what, so we have the security involved there. We go directly to the SQL Server database. This is the account used by the SMS site services that will access the SQL Server database.

The account that's used here depends upon the security mode that you have SQL Server set up in. If you're using SQL Server in standard security, by default, when you do an installation, we'll expect that you want to use the sa account. If you don't want to use that account during setup, we prompt you, and you can go ahead and specify a different account to be used that you would have created in SQL Server separately. Otherwise, you can use the sa account.

If you're in integrated mode, then we would go ahead and use your Windows NT logon account. We already discussed that the account used by the SMS services would be the SMS Service account. So, the SMS Service account, which is an administrative account, would have access to the SQL Server database. That's what we would use to communicate from the SMS Services to the SQL Server database.

The third option is mixed mode for SQL Server. That's an environment where you can use either your standard account or accounts that you create manually inside SQL Server, such as sa, or any other login ID you would create, or your logged on user account, such as integrated security. SQL Server would support either one.

That just depends on what security mode you're running.

If you're using standard security, this account is prompted for during setup, and can be changed during setup as well. We'll ask you that just like the SMS Service account. There also is an Accounts tab. If you're familiar with the SMS Admin console, you look at the Site Properties dialog box in the Admin console, you go to your site code, and then do an Action, Properties . On the Accounts tab, we give you the option for seeing your SMS Service account as well as your SQL Server account. If you're running SQL Server in standard security mode — so if SMS is set to talk to SQL Server in standard security mode — you'll see that sa will be listed there by default, or, if you change it during setup, you'll see the account listed there.

If you're in integrated mode, you'll see nothing there. That's because you're using the SMS Service account. You do also have the option of changing those accounts there if you wish. It's not recommended, however. We do recommend that you run SMS Setup and then do a Modify or reset current installation to change your SMS Service account or your SQL Server account.

One thing to caution you about on these accounts is to be very careful that you don't restrict access permissions. We've had some customers who have gone in, and they've taken whatever account they're using, be it the SMS Service account or the sa account, and they've restricted the account from using Named Pipes. If you do that, you'll find that your site does not process data properly, and that, if you go under your Admin console and make any changes to your Administrator console, to your site settings — such as changing client agent schedules or adding new accounts, whatever — the site won't process those. The reason for that is when you make the change, the data is written directly to the SQL Server database. Then, there's an extended store procedure in SQL Server that notifies the SMS site server that something has changed. How the SQL Server notifies the site server, which is the SMS SQL Monitor Service, how it notifies that account is through Named Pipes. So, if you restrict named pipe access from that account, then the SQL Server can't notify SMS that something's changed. Then, you'll just have to wait until SMS falls into its background mode of waking up hourly, or whatever the appropriate service is, to check to see if there's work to be done. So, it's much more like what 1.x was, as far as configuration of the site. It won't be dynamic as it is right now. Just be careful not to restrict your SQL Server account from the use of Named Pipes, because it is required.

Now, we'll move on. We'll talk about some of the accounts that are used for Windows NT clients. There are a number of different accounts that we use when we're integrating with Windows NT client computers.

The first account is the SMS Client Remote Installation account. The SMS Client Remote Installation account is not created by default, but this is the account that can be used by SMS if the logged on user at a Windows NT computer does not have administrative permissions. If the logged on user who's attempting to install SMS — either through the logon script and the SMSls.bat file or by running SMSman.exe — if that user is a local administrator, then he has permissions to install the SMS client software. We won't need this account at all.

However, in a lot of environments, local users are not local administrators. So, the user kicks off the SMS logon script or SMSman, he'll be able to proceed part way through the installation, but he won't be able to complete the installation process, because he doesn't have permissions to create services in the registry or start services locally.

What happens in that case is that the client computer creates something called a client configuration request, a CCR. They write that back to the client access point, which is then pushed to the site server. When the site server detects that client configuration request, the CCR, it will go ahead and connect up to the client computer and push down the SMS client software. SMS has to be able to connect up to the remote client as an administrative account. If you don't have an SMS Client Remote Installation account created, the account that we use is the SMS Service account. That should work because your SMS Service account is, by default, a Domain Administrator, and, generally, Domain Administrators are members of the local administrator's group on your Windows NT clients. So, unless you've modified those settings so that the SMS Service account is not a Domain Administrator, or if you've removed the Domain Administrator's group from your local admin group on the client, the SMS Service account should work.

If you don't want to use the SMS Service account, then, in your Admin console, on the Site Properties dialog box, on the Accounts tab, you can go ahead and designate the SMS Client Remote Installation account. You would need to create this account in your domain, manually, and then designate it on the Accounts tab. Then, whenever SMS receives a CCR — the next time CCM starts up, the client configuration manager — it would detect this new account. It would go ahead and attempt to connect up to the admin$ share on your Windows NT client computer with this account. If it's able to do so, it'll copy down the SMS client bootstrap program and the other files that are necessary, kick off the installation, and do the service creation and start up that it needs. It will go ahead and then let the local client finish the rest of the installation process.

One of the things we do here, because this account is optional, is that once you've designated this account, once you've connected up successfully to a client computer, we'll go ahead and remember that. The next time a client sends a CCR and requests help with the installation of the SMS client software, SMS will try that account first. It calls it the "best shot" account. It's the one that last successfully talked to a Windows NT client computer. So, we'll remember that.

Another thing to consider is that if you don't have this account created, or you do have this account created, but it's not an administrator in an NT workstation, we'll try this account in numerous contexts. We'll try the SMS Client Remote Installation account in the domain designated. So, we'll use whatever domain the account's created in. We'll use its context. So, it'll be, domain\whatever_ your_CCM_account_is.

If that's unsuccessful, then we'll go ahead and try this account using the context of the domain the site server is a member of. So, if the site server's in a resource domain, we'll use that resource_domain_name\your_CCM_account.

If that's unsuccessful, we'll go ahead and try the resource domain that the Windows NT client is a member of; so, NT Workstation domain\the CCM account.

Lastly, we'll try the same account with no domain prefix, assuming it might be a local account on the Windows NT client in its local SAM.

We'll do the same things for the SMS Service account. So, you have the SMS Client Remote Installation account and/or the SMS Service account. We'll try all those different contexts, trying to find one that works to talk to the remote NT box to push down the client installation. When we find one that's successful, we remember it and we'll try that again next time.

So, that's the SMS Client Remote Installation account. It's only required if you need to push down SMS client software to Windows NT clients, where the logged on user is not a local administrator. Or if you want to push out the SMS client software after doing a network discovery, and then using the Windows NT Remote Installation method. You would need this account as well.

The next account is the Windows NT Client Network Connection account. The Windows NT Client Network Connection account is the account that the Windows NT client computer uses to interact with the client access point. So, whenever your client needs to transfer data or look at configuration information as part of its normal processing (hardware inventory, software inventory, for example), it will go ahead and use this account to connect up to the client access point and transfer that data to the client access point.

Sometimes we'll use the logged on context of the user, but generally, if it's an automated SMS client (such as transferring inventory data or status messages or discovery records, checking for logged on software or advertised programs, and so on) we can go ahead and use the SMS NT Client Network Connection account. This account is created by default for you. The default name is SMSClient_sitecode.

Because of the fact that it's SMSClient_sitecode it has the same type of problems in large site environments that we talked about for the SMS Server Connection account, and that is you have a lot of different SMS sites sharing a single domain, then we'll create one of these accounts per site. So, you may wind up with numerous accounts in your domain called SMSClient_, then sitecode, one for each of the different sites.

If you want to control the number of accounts created, there is a command-line switch for the Windows NT Client Network Connection account, just like there was for the SMS Server Connection account. The switch is Setup /Client_account your_Account_name/client_password account_password, or you can use the Smsaccountsetup.ini file that we talked about before as well.

You can control the account to some extent using that process. It is also extremely important for you to manually create Windows NT Client network Connection accounts. How you do this is, really, you'll want to follow the SMS 2.0 Service Pack 1 Release Notes. We have documented that very well, in those release notes, the process for going through and creating additional NT Client Network Connection accounts. Because you create the account in a domain. You create the account. You set the password. You assign that account in the SMS Admin console. And how you do so is through your Site Settings, Connection Accounts, and then Client, and then create a new account there.

Because you're in control of that account, if you ever have a process where you need to reinstall your SMS site, but you don't want to reinstall all your clients, when you do that, we'll create that new account for you. It may have a different password than when you last created it, unless you're using this command-line switch or the .ini file we talked about. In that case, what would happen is you would orphan your SMS clients. Your SMS clients would know the SMS Client Network Connection account with one password; where the site has been reinstalled, it may have the exact same account name, but it will have a different password. So, the account will not be valid to transfer data over to your client access point. In that case, your client becomes orphaned.

If you do get in that situation, you can recover your clients by running your installation method again. So, either run the SMS logon script (Smsls.bat from the logon point) or run SMSman manually. That will go ahead and connect up to a logon point. It would pull this data back down from the logon point (the new account name, and the new account password). Then you'll be able to connect up again.

To prevent that, the easiest thing to do is to create numerous Windows NT Client Network Connection accounts, manually. Again, the Service Pack 1 release notes document very well how to do that and a procedure for doing so.

The next account is the Windows NT Client Software Installation account. This account is an optional account. We don't expect that you will have to use this account very often at all. The account can be used for running advertised programs. In the general context, when you create an advertised program, and you advertise it to a client computer, there's three different contexts that program can run under.

The first context is the context of a logged on user. So, I'm logged on as Wally, I would go ahead and run the program. That may work fine. However, a lot of software in today's marketplace requires administrative permissions on an NT box to install. If I'm not a local administrator, I wouldn't be able to successfully install that software.

So, when you're creating your program, one of the properties you can set on program is that the program runs under administrative rights. If you designate that the program runs under administrative rights, then what we will do is we won't use the logged on user context. Instead, we'll go ahead and use the SMSCliToknAcct& as the administrative user. That account is created in your local workstation SAM; however, if you look at the account properties, it is not an administrative account. However, when we need to use that account to run a piece of software, an advertised program, in an administrative context, we'll go ahead and take that account, we'll add it to the local administrator's group, and we'll run the advertised program. Then, as soon as we're done, we'll remove that account from the local administrator's group. That will give it an administrative context to run these advertised programs.

In some cases, that's not going to be successful for you. Your advertised program may actually require additional network access. The SMSCliToknAcct& is not supposed to access the network. So, in that case, if you need to talk to a third server on your network, besides your client access point, besides your distribution point that you're running the program from, let's say, another file server if you're advertising a network application, and then, a network application maybe has a UNC path in it (pointing to a third server on your network). The SMSCliToknAcct& would not be able to connect up to that third server. That's where you would create and use the Windows NT Client Software Installation account.

So, you would have to create this account manually in your domain. You can create it as just a domain user. It does not have to be the administrator. You designate it in the Admin console. Where you designate it is under Site Settings, Component Configuration, and Software Distribution; the last option on the General tab, again, is your Client Software Installation account. You designate it there. Then, in your Program Properties, you designate the required admin rights and then select the check box to Use the Windows NT Client Software Installation account.

Now, when this program is run, that account is local to your client, but it's not in the client's SAM. You'll find it in the registry of the client. So, it's encrypted in the client's registry from normal maintenance cycles. It'll be updated. Then, when you run this program, it requires this account, and it requires admin permissions, we take the account from the registry, we decrypt it, we add it to the local administrator's group, and we run the advertised program. Then, we'll remove the account from the local SAM entirely. So, it won't be a local user. It won't be a local administrator at all anymore. It will only be present encrypted in the registry again. That gets us the administrative account. It's a domain user, so you should have permissions to access that third server on your network. Of course, if you have permissions set up, you'll have to manually make sure this account has permissions to that third server.

So, again, we don't expect you have to use this account that often, but in those cases where you need to access a third server, then you would go ahead and create this account, and designate it in the Admin console and also in your program.

The last set of accounts is the SMS Windows NT Client Remote Control accounts. This is the account that's used to actually perform remote control on a remote Windows NT client computer. This is also known as your Permitted Viewer's List. So, if you look at your Remote Tools Client agent, if you go to the Security tab, you'll be able to see a list of accounts that are allowed to do remote control. By default, you see administrators spelled eight or nine different ways in there. So, you would want to go ahead and remove all those accounts that are not appropriate for your site and then add in user accounts, group accounts, whatever is necessary for your environment, that you do want to allow to do remote control. Then, whenever this information is brought down to your local client computer, when the SMS remote control agent starts up on an NT client, it will go out to your domain controller, it'll validate the SIDs for these accounts, and then, when someone attempts to perform remote control, it'll validate that they're a member of one of those groups. So, that's the Permitted Viewer's List for remote controlled NT computers.

Next, we'll talk about a couple additional internal accounts that SMS creates for Windows NT client computers.

The first account is the SMS Client Service account. This is the account that's used to start up the SMS client service on Windows NT clients that are not domain controllers. A standard Windows NT computer that has become an SMS client will have to start up the SMS client service, and it uses this account. The account is SMSCliSvcAcct&. It's created automatically. We create the password, we control the password automatically. You basically have no control over this account at all. It is a local administrative account, so it can start the service, but it does not access the network. Again, to transfer data across the network from the client service to a CAP, it would use the SMS Client Network Connection account. So this account is solely to start the SMS client service on Windows NT client computers.

If your Windows NT client computer is a domain controller, we can't use this same account because this account is created in a local SAM of the Windows NT client computer. Because domain controllers don't have a local SAM (they have a domain SAM), we can't use a single account, like the SMSCliSvcAcct& like you do in NT. Instead, what we do is we create the next account, the SMS&_domain controller name account. So, if you had ten domain controllers in your domain, you would have ten of these accounts if they were all set up as SMS clients. SMS&_dc1, dc2, and so on. One for each domain controller that is an SMS client.

This account, again, is controlled by us. You're not allowed to change this account, either the account name or the password, at all. In either case if these two accounts get corrupted or if the password gets modified, and we can't start the service, you would have to run your installation method, like SMS logon script or the SMSman program, to recover this account.

The third account on the page is the SMSCliToknAcct&. We've already talked about this account on a previous slide. One of the purposes for this account is if you need to run an advertised program with administrative rights. We can go ahead and use the SMSCliToknAcct&. Again, the account is created in a local workstation SAM. It is not a domain administrative account. It's not a local administrative account, for that matter. All it is is a member of a special group that we create called the SMSInternalCliGrp. The reason for that is every account has some member of some group. So, we create this group called SMSInternalCliGrp. Then we assign special user rights to this group and the account. For example, the other purpose for this account, besides running programs in administrative context, is creating tokens to separate SMS client processes. So you'll create separate tokens for each client process that's kicked off by the SMS Client Service. That's to keep the context of that process separate from any other processes that are running from that same service, the SMS Client Service. One of the advanced user rights that this group and account has is replace process level tokens. It has a couple other advanced rights as well. This account is created on the local workstation's SAM, and it's controlled locally by us. Again, it's one of the accounts that you have no control over at all.

Now, one of the areas that you may have seen difficulties with this account is account lockouts with this specific account. The reason for that is your domain controller becomes an SMS client, it creates this account as well. It creates the SMSCliToknAcct&. It tried to create that in its local SAM; however, again, domain controllers don't have local SAMs. They have a domain SAM. So, it's created in the domain. The account password is different here than from your NT workstations. So, your NT clients, when they try to connect up across the network to get validated, they'll get invalidated because the password is different between the two accounts. So you get your account lockout problems.

There are numerous fixes for the SMSCliToknAcct& lockout issues in SMS 2.0 Service Pack 2, which is not out yet. It's going into beta later on this month. Also, the SMS Client QFE Bundle, is a brand new set of hotfixes that's come out in the past couple of weeks: it's called the Client QFE Bundle. There are numerous fixes in there for the SMSCliToknAcct& lockout. So, if you have that {problem}, contact your local PSS person and get the Client QFE Bundle to work with those account lockout issues.

The last account is the SMS Client Network Connection account, which we've already talked about. This is the account that the SMS Client Service uses to transfer data to client access points. So, when the client creates a DDR, a CCR, a hardware/software inventory, or a status message, this account is used to transfer the data to the client access point and not the SMSCliSvc account.

Again, we talked about this already. It's very important that you create numerous of these accounts. Follow the SMS 2.0 Service Pack 1 Release Notes on creating additional of these accounts so you don't orphan your client computer.

Next, we'll talk about integration with NetWare. If your SMS environment needs to integrate with NetWare site systems, logon points, client access points, distribution points, how do we integrate with them?

If you're in a bindery environment, if your NetWare computers are running NetWare Bindery, or in bindery emulation mode, then we use something called the NetWare Bindery Connection account. The NetWare Bindery Connection account is used to connect up to the bindery server as a CAP, a logon point, or a distribution point, and do any appropriate configuration necessary.

This account is not created by default. However, if you don't have this account created, we will use the SMS Service account. If you want to use your SMS Service account for this account, you need to create this account in your bindery server, in the bindery, and make it a supervisor. So, give it supervisor equivalence. That will allow the SMS site server to configure and interact with the NetWare bindery site system.

In an NDS context, we do not use the SMS Service account at all. So, you will be required to create a NetWare NDS site system connection account. Again, where you do that is under Site Settings, Connection Accounts, Server, and then NetWare NDS, provided you have the appropriate NetWare NDS support loaded.

You create the account there. The account needs to be created in your OU itself. It needs to have permissions to the NDS container for Create, Erase, and Modify. Go ahead and set up the appropriate SMS files that are necessary. If you want to use logon scripts for your container, it would need write permissions to the container logon script. Go ahead and kick off our batch file from there.

In both cases, it is recommended to create the connection account, even for bindery, even though we will use the SMS Service account. Just go ahead and create your own account and use it. If that fails, then we'll fall back and try the SMS Service account. With NetWare NDS, you've got to create the account manually.

The last couple of slides we have are designating which accounts that you have some control over as an administrator, and which accounts you have no control over. The slide we're on now is the SMS accounts the administrator has some control over. It doesn't mean full control, but at least some level of control.

The SMS Service account: you have full control over this account. You can designate the account name. You can designate the password. You can make it a local administrator as opposed to a Domain Administrator. So, you have pretty good control over it. You designate it the SMS Setup program.

The SMS Server Connection account: this is the account, again, used by remote SMS site systems to transfer data to the site server. By default, we create the account, SMSServer_sitecode. If you don't want to use that account, you can go ahead and use the command-line switch we talked about before, the /server account/server password or the Smsaccountsetup.ini file. So, you can create it there and designate it there. Other than that, if you're using our default account, you don't want to modify it; otherwise, you'll wind up orphaning your site systems. So, the only control you have is with that command-line switch or the Smsaccountsetup.ini file.

The SMS Server Network Connection account, you have complete control over this account. This is the account used by the site server to talk to remote site systems to set up logon points, set up client access points, etc. So, you can create this account and control it.

The Site Connection account, or before, I think I called it the Site Address account: this is the account used to transfer data between SMS sites. You have complete control over this account. You designate it when you create an address to a remote SMS site. The account needs change permissions to the SMS\Inboxes\Despooler.box\Receive directory.

The Software Metering account: you have complete control over this account. We will create it for you automatically if you want us to, if it's not already created. You designate it when you create your site system as a Software Metering Server. You designate it there. It will be a local administrator account, but you can go in there and set the account name and password.

The SMS Client Network Connection account: you can control it, again, from the aspect that if you don't want to take our default account, SMSClient_sitecode, you can use the client account and client password switches on SMS Setup or the Smsaccountsetup.ini file to control the initial account. Additionally, it is very important for you to go in and create additional of these accounts so you don't orphan your clients, in the event you reinstall your site. Again, that's documented extremely well in the Service Pack 1 Release Notes.

The SMS Client Remote Installation account: this is the account used to install Windows NT clients with the SMS client software if the local user is not a local administrator. That account you have complete control over. It does need to be an administrative account on your NT client computer.

The SMS Client Software Installation account: again, you have control over this account. You create it. You assign it. You set the password. It does not need to be an administrative account. We'll make it in admin when we need it for running advertised programs, so you don't need to do that. Just create it in your domain as a domain user.

I guess we could also add on this slide the SMS Remote Control accounts — your Permitted Viewers List. You have complete control over that account as well — what account names or group names are listed there. So, you can control that.

Then, the next slide is the accounts that you have no control over at all. The SMS Client Service account, which is SMSCliSvcAcct&. You can't create the name. You can't change the password. If you do, you'll wind up orphaning your client until you go ahead and run your installation method again.

The SMS Client Service account for domain controllers: the default is SMS&_domain_controller_name. Again, we're in complete control of that account. You're not allowed to change it or modify it.

The SMS Remote Service accounts: the accounts used by CAPs and logon points to start up their services. SMSSvc_sitecode_0000 SMSlogon Svc: you can't control those. We're in control of those accounts as well.

Then, the SMSCliToknAcct&: that account is our account we're maintaining. So, you can't modify it at all either.

Basically, if you look at any of the SMS accounts in your domain, and any of those accounts in the domain, you'll notice that they have a check box on them, Password never expires. Some of the accounts also say, Do not modify. Basically, any of those accounts, you don't want to touch them, or you're going to cause some sort of problem, orphaning your client, or orphaning a site system, and you'll have to do some sort of reinstallation of the client or SMS Site Setup to recover those accounts.

That is the last slide. So, at this point, I think we're ready for Q&A.

Heidi: Okay. Excellent. Thank you so much for that presentation, Wally.

Before we start the Q&A, I want to give you all a couple of program notes. If you joined our session a little bit after the beginning and would like to listen to a replay of this session, within about 8 hours of the live presentation we do post the on-demand streaming media files. With those you will also see the PowerPoint slides, if you would like to download a copy of those. I know that sometimes some of the images tend to be a little bit small and difficult to see within the browser.

Lastly, within about three weeks of the live session, we also have a full transcript of this session posted in that same location.

Before we get into the Q&A, I also want to encourage all of you to let us know what you think about this program. During the live event, you can submit any feedback you have using the Message Center. Following the session, you can send us feedback at any time via the e-mail alias feedback@microsoft.com. We are very interested in your feedback regarding the program overall, any recommendations you have for us to make the program better or more usable for you, topics suggestions, or just any comments you have about sessions you've already seen. Once again, either through the Message Center during the live session, or to feedback@microsoft.com at any other time.

We have had several questions submitted. So, let's go ahead and get started.

Wally, do we have an answer on this, or does this sound more like a one-on-one product support issue?

Wally: I would guess it's a one-on-one product issue. My comments would be we don't actually put services on distribution points, so generally, all we need is to have the SMS Service account or the SMS Server Network Connection account as an administrative context on that remote computer, be able to access it, and then be able to find an NTFS drive to store packages on. Outside of that, if it's something specifically with that one box, we'd have to open up a case with PSS to find the specific issue. I've not heard of that computer system at all.

Heidi: OK. Great. We have had several questions. They look like great questions, but I do want to remind everybody that one-on-one product support issues are outside of the scope of this program. If you do have a specific question that needs to be addressed by Product Support, I'd encourage you to phone into Product Support or to look at other resources on the Web, such as Web Response.

Wally: The caution here is you can't change the password once it has already been set up. Once you're already set up, basically, you're stuck with that. There's an issue right now with Service Pack 1 that, if you try to change the password, it can orphan your site systems. So, it's for a clean installation. But the syntax is, you run setup manually, not through the Autorun function, but you go to on the CD, go to the SMS\Setup\Bin\I386 directory, and run Setup /server_account account_name /server_password account_password. And you need to make sure you use that same syntax every single time you run setup or you'll wind up changing your functionality, and that will orphan your SMS site systems.

So, it's really for clean installs entirely, not for changes after the fact.

Heidi: Okay. The next question is: "Can Smsaccountsetup.ini, can that file be used when pushing secondary site installs from the MMC? And then it has in parentheses here (with media available locally)."

Wally: You would have to put that file down on your secondary site server in the Win NT System32 directory. If it's down {on the secondary site} during the installation process we should recognize that file, and we should create the account specified in that file.

Heidi: From a security standpoint, it is necessary to change the account and password on administrator account? Right now, it would appear that the running of Setup at each site is the only way to do this. In a domain of over 350 secondary sites, this is impossible to do in a timely fashion. Is there a utility to do this more effectively?

Wally: Today, no. However, we are working on a utility that will help you do this in a site hierarchy such as yours much more efficiently. The utility is not available today, and it probably will not make SP2 and will be posted probably on the Web site some time after Service Pack 2. But there will be an Account Management Wizard that will help you with this environment. But, now, yes, you have to run setup manually on each of those to change your SMS service account. You can do it remotely through remote control. But it will get better after Service Pack 2.

Heidi: So, not the answer you were hoping for, but the answer.

The next question is: "Is it possible to use a restrictive permissions account to prevent users from reporting unsupported .mif files into the SMS data base?"

Wally: When clients generate hardware inventory and they attach their .mif files, those are sent to the client access point by the SMS Client Connection account, so the SMS client_sitecode, by default. They're sent there by using that context. You can't change that other than the fact you can change a different account if you want to use that. So, it wouldn't be a restricted account, because that same account is used for all client functions from the client to the client access point. So, if you did that, you wouldn't get any hardware inventory at all. You can't just restrict it for certain .mif files.

When the .mif file gets to the site server, it will process it, and if it's invalid as far as syntax, it will kick it out. If it's valid as far as syntax, it will add it to the database. It might not be what you wanted, but that's the way the process goes. It only checks for syntax. But currently you can't restrict one function without restricting all functions in the client.

Heidi: I want to let everybody know, we have several questions coming in, and that is absolutely terrific.

So, the next question is: "Since SMS does not support moving SMS sites to different domains, will the clients be orphaned if the SMS site is reinstalled after the server has been moved to another domain?"

And the individual then states: "I have implemented one Additional Client Connection account."

Wally: The key there is implementing the additional Client Connection accounts. Because those are accounts you create, you know the account name and the password, all you have to do is create that same account in your new site — when you reinstall the site, create that new account — and the clients will still have that old account listed there. They wouldn't be able to use your standard Client Connection account, even if you used the same site code, because the password would have changed. However, because you created your own account, you've prevented that client from being orphaned. So, it should be fine, because it has that account cached locally.

In the worst case, if you goofed up your account, you would just run the SMS logon script or SMSman manually on the client and that would pull the information down from the logon point. If you've created it on both sites (the exact same context and account name and password), then you should be fine.

Heidi: The next question is: "We have discovered that when we try to add an NT group name to the permitted viewers list that contains spaces and is 24 characters long, SMS fails to add the group to the list. Is this a known problem? And if yes, will it be fixed and when?"

Wally: Yes, yes, and yes. It is a known problem. And it is fixed. Last I heard about it, it was already fixed. I don't know the hotfix number for it. So, I would search the Knowledge Base on "remote control," and if the hotfix is available now, it will be listed there. Search on "remote control permitted viewers list," or something to that effect, and you should be able to find it.

It was not too long ago, so the hotfix may not be available yet. But it should be very close, if not. Definitely in Service Pack 2 — that has been fixed in Service Pack 2.

Heidi: "Can we remove domain controllers as clients in order to get around the SMSCliToknAcct& lockout problem?"

Wally: By default, if your domain controllers are within the site boundaries, we will install them as client computers, and that will then create the SMSCliToknAcct& because they're a client. One of the ways to get around the account lockouts until you get the client QFE Bundle or Service Pack 2 is to actually remove the SMS Client Service account from your domain controllers. You can do that manually. You can run SMSman, and there's an option in SMSman on the first page to remove SMS client functions. And then, if you want to prevent it from being reinstalled, there's a registry key on the site server you can create. Actually, it's already there; you just have to update it. It's on HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\Components\SMS Discovery Data Manager\ and then the key is Exclude Servers. And that's a multi string. Just list each individual server that you don't want set up as a client, and then, when SMS does the discovery and wants to push out the client software, it will check that key first: "Oops, I'm not supposed to send the software out to that one," and it will prevent it.

However, if a user at the domain controller logged on with the logon script or ran SMSman locally, it would reinstall the software. This is only for SMS server discovery pushing out the install. But, yes, you can remove it. And that would then help out with your Client Token account lockout issues.

Heidi: Was there a better way to state that syntax? I want to make sure all our customers are aware of exactly what kind of lockout problem we were talking about.

Wally: Just SMSCliToknAcct.

Heidi: The next question is: "If you do not wish to make your SMS service account as a Domain Administrator, what systems must it be a local administrator {for}? Do you remove it out of the Domain Administrator's group after it has set up the net logon shares or the domain controllers?"

Wally: It depends on if you're going to implement the SMS Server network connection account. If you want to make your SMS service account a local administrator instead of a Domain Administrator, then the best thing to do is to create the SMS server network connection account — and that's again, in the Admin console under Site Settings, Connection Accounts, Server, and then Create Site System. Create one there, and then make that an administrator account.

One of the two accounts needs to be the administrator on all SMS servers, logon points, client access points, and distribution points. Domain administration is just the easiest way to do so. However, for security, if you want to restrict that, you can make it a local administrator and then have the account be manual administrator, local administrator in each of those boxes, or use the other account — either way.

Heidi: The next question I can answer. "Will the Q&A be available on the replay?"

And the answer to that is yes. The on-demand streaming media includes the entire presentation and the Q&A session.

The next question is, apparently there was a reference to not being able to change a password or doing some sort of password reset, and the question simply states: "Can't change the password for what feature?"

Is that enough information for you, Wally?

Wally: No. On most of our accounts, you can't change password. Certain ones you can, like the SMS Service account and some of the other ones. Any accounts that you can create in the Admin console, you can pretty well control and change the passwords; other ones, you cannot change passwords.

So, if you had a specific account, you could ask again; other than that, that's the general rule.

Heidi: And if the individual who asked that question needs clarification, submit your additional questions via the Message Center. We can maybe come up with a more complete answer if we're missing the boat there.

The next question is: "Can someone changing SMS accounts cause Windows® 95 clients to hang? We have not pushed any software yet, but SMSMon32.exe is hanging Windows 95 PCs, and I'm wondering if this can cause the system to hang?"

Wally: No. Changing your accounts won't affect your Windows 95 or 98 clients. However, there are numerous problems in Service Pack 1 related to Windows 95 and 98 lockups. There are a couple of individual hotfixes available right now. The best thing to do is to open up a case with PSS, complain that you have Windows 95 lockup problems, and that client QFE Bundle that was just released has all the fixes in there. That's the best thing to do for Windows 95 clients.

Heidi: The next question is: "Are the Setup.exe switches published, and if so where?"

Wally: The ones I specified were not published yet. Hopefully, in the next release of the documentation, they will be. I don't know for sure. There's a small possibility they might be put in the SP1 Online Administrator's Guide, but I don't think so. So, to my knowledge, they're not published anywhere, but they're slated to be for Service Pack 2.

There actually is a KB article on it. I don't remember the Q article number, but there is a KB article on it. So, you can search on that.

Heidi: If you create a null session share, how does file level security apply?

Wally: I don't see how that has anything to do with the SMS stuff, but generally with the null session, everyone has to have appropriate access or the guest account enabled. From there, I honestly don't know. I've forgotten most of my NT stuff just doing the SMS stuff over the last few years.

So, if it's something specific you want to ask, go ahead and update the question, or send a more complete one and we'll try that.

Heidi: Is there a method for recovering orphaned clients?

Wally: Sure. If you're client has been orphaned because you reset the site or you reinstalled the site, you just run the SMSls.bat file from your logon script off the domain controller, or you can run SMSMan.exe. You can run it from the domain controller, or it is installed locally on your client in the Windir\MS\SMS\Core\Bin\00000409 directory. You can run it from there.

When you run it, it will connect back up to a logon point. You'll download the new connection account information into the registry, and then your client should be nonorphaned again.

Heidi: The next question is: "Can you let us know the URL for MS for public support? Mr. Eby (who gave the last SMS session a week or two ago) mentioned http://www.microsoft.com/smsmgmt/. That, my guess, would be off of http://www.microsoft.com/."

Sorry if that is unclear. We do have everything under http://www.microsoft.com/, but there are a few differentiations for going to the actual support sites.

Wally: Yes, there's http://support.microsoft.com/, and I've heard that's been revamped, and you can get to SMS support very easily there. There are also the public newsgroups, which are msnews.microsoft.com. And there's a series of SMS news groups there that are self-monitored. You're working amongst your peers. Microsoft people might monitor it, but there's no assigned person to it. They're just self-monitoring.

And there's the one for many different topics there. So, you can go there and talk about hardware inventory or installation, or whatever.

Heidi: One more note: for Microsoft Online Support, we do not have a single site. We have several online support sites that we have customized depending on your needs as an individual. For example, the TechNet Online Support site would be available for IT professionals. There's another site available, from http://support.microsoft.com/, for home users. The MSDN support site is for developers. And we are working hard to make sure that we are customizing the data that's on these sites to meet your specific requirements. So, where you go for support or which option you choose really depends on your customer type. So, that was a bit of a side note.

Wally: Understood, and the product group understands this as well. There are efforts underway to start reducing the number of accounts we created. The reason for it was to keep each client (in this case each domain controller) running separate accounts with separate passwords so there was less chance of anybody hacking into a domain controller by finding out the account password for the client service account. It winds up being if there are no local SAMs, they're all on the same SAM, and they're all local administrators — basically everybody has the same permissions. It didn't wind up being as successful as we wanted it to be, so we do understand how you feel about having the client software out there and a separate account for each one, and we are working hard to try to reduce that interaction and how that operates. It probably won't happen for SP2, but looking at the next release of SMS, we hope to have further abilities for you to reduce the numbers of accounts.

Heidi: The next question addresses clients and servers. The first part is: "Can SMS Server 1.2 and 2.0 peacefully coexist in a single domain?" And then that is followed up by the statement: "Half of the PCs in the domain are running SMS 1.2 and the other one-half were deployed with 2.0 clients."

Wally: Yes, they can coexist. A couple things you want to look at are, chapter 5, I believe, in the SMS 2.0 Administrator's Guide. Chapter 5 is an entire chapter devoted to interoperability between SMS 1.2 and SMS 2.0, and how you can have a single domain supporting both 1.2 and 2.0.

In the SMS 2.0 Resource Guide, there's a chapter in there, as well, on interoperability.

Then, also on the Systems Management Web site, which is http://www.microsoft.com/smsmgmt/, there are some white papers there. I believe they're under Technical Details, I think that is the link from there. This will have white papers on interoperability between SMS 1.2 and 2.0. But, yes, they can coexist and they can even share domain controllers. There are a couple things you have to make sure you've done properly, so you don't downgrade client or upgrade clients you don't want done. That's documented in all three of those sources.

Heidi: The next question is: "Once secondary is created with default account, can I re-run setup locally with command-line switches to specify a single domain account?"

Wally: No. Once you've set up your site using the default SMS Server Connection account or SMS Client Network Connection account, if you go out and run the command-line switch to change that, there is a problem right now in the SP1 code that winds up orphaning all your site systems. So, once you're set there, it's best to leave it the way it is now, and then, in SP2, they're hoping to have the ability for you to be able to change that. But as of now, I've heard there are problems with trying to change it, and you will orphan your site systems, which is not good.

Heidi: "Is it possible to put a Dfs server between SMS and the distribution server selection process?"

Wally: Currently, SMS doesn't support Dfs. That's on the table for support, but it's not currently there. Dfs is not currently supported on SMS.

Heidi: "Can an error loading dynamic link library ClieX32.dll on Windows 95 clients be related to an SMS account, or would this be another problem?"

Wally: The Cliex32.dll — error loading that — that is loaded by the SMS Client Services, as part of the client service, so if the client service can't get started, then, yes; however, I don't know of any issues on Windows 95 related to that. I have not heard of any issues on it.

There are other things on NT with local user permissions and account permissions, but you said Windows 95. I have not heard of that issue at all.

Heidi: "Can you move a site server to a new, more powerful system? Our SQL Server is housed on a separate box. The site system would remain in the same domain. If you can, is there documentation that gives a process to do this?"

Wally: There is a Knowledge Base article on it I've heard of, and also in the SMS 2.0 Admin Guide, they do talk about that process. You are allowed to move your site server to a new hardware platform, provided you keep the computer name the same, the domain the same, the same platform — in other words don't go from Intel to Alpha or from Alpha to Intel — and that you count SMS installs on the same drive. So, if you were installed in drive E before, SMS still needs to be on drive E. Provided you keep those four things the same, yes, you can back up and restore and have your SMS server move from one hardware platform to another.

Heidi: "With regard to any of the system-generated accounts: If the system changes their passwords, what sorts of failures might occur? For what reasons? And how might we detect the failures? For example, log entries. Are you seeing any change failures in the field?"

Wally: Generally, SMS does not automatically change our account passwords. That's why, if you look at any of our accounts in the User Manager for Domains, if you look at their properties, you'll see Password Never Expires. We generally don't change our accounts automatically, the passwords for them.

Sometimes some accounts do get reset if you do a site reset. So, if you do a site reset, some of the accounts will get changed, and their passwords. But other than that, we don't automatically change our passwords. So, if you do go out there and manually change passwords, then, yes, you will cause problems. It could be as simple as account lockout, being that the account has changed, and now you're trying to validate with a different account, so the account gets locked out. It can be that your site system or your client is orphaned — in other words they can't talk to the site server, or they can't talk to their client access point again. Those things you would see in log files, depending upon what function it is, and generally it would listed as just a "Cannot Access account." It might give you and error 5, like "Access Denied." Or 1326, "Credentials Conflict." You might see those logged there. But there's not one place that you would look to see if the account has been changed and if it's caused any problems.

Heidi: "Can you discuss the process of setting up NT access to newly created SMS shares? In particular, share level versus file level access?"

Wally: All of the SMS functions on site systems create share names, and those share names we give the standard Microsoft response or setup of Everyone-Full Control, and then nothing else listed at the share level. And then at the file system, almost all of our site systems require NTFS permissions. NTFS is where we really do the security, and we maybe set everybody to read permissions, or maybe just users to Read/Write/Execute. So we'll set the permissions individually at NTFS level, but the share level we'll set everyone full control in almost all cases.

A couple cases we do a little bit beyond that, but generally, it's Everyone-Full Control. And then once we've set those, we generally don't change those permissions at all. If you go up and modify them, make sure you don't remove our standard permissions at the file system level; otherwise, you might impair our functionality. If you create some of your own accounts, you may have to assign your permissions manually.

But, share level, Everyone-Full Control is predominant. At the file system, then we lock down pretty well through NTFS.

Heidi: The next question is: "We have SMS 1.2 working at our site, at least the features that we use. As a corporation, my company wants to implement SMS 2.0 with our site becoming a child site. Can we reasonably expect to implement SMS 2.0 without ripping out everything and going to a clean install?"

Wally: Yes. In the different locations I talked about earlier in the SMS 2.0 Administrator's Guide, Chapter 5, and the SMS 2.0 Resource Guide, as well as on the http://www.microsoft.com/smsmgmt/ Web site and the white papers therewe have white papers on the upgrade as well as information on the interoperability between the two.

The biggest areas of concern would be if you happen to have shared domain controllers between your 1.2 site and your 2.0 site. There are a couple of issues you need to look at, making sure that you aren't replacing the 2.0 logon script with the 1.2 logon script. So, you would turn off Automatically configure workstation logon scripts in 1.2.

Other than that, yes, they can coexist and integrate. And the 1.2 site would have to be a child of 2.0. It can never be a parent of 2.0.

Heidi: We are looking at installing SMS at our site. Would you know of a course that has hands-on practice to familiarize us with the numerous features and options?

Wally: Yes, we have three different training courses that are publicly available on SMS. You can get them from most any CTEC, Certified Technical Education Center. The course numbers would be MOC (Microsoft Official Curriculum) 825; course 825 is a one-day overview course for SMS 2.0. So, you walk in there and in one day you learn as much as you can about SMS 2.0. Granted, it's very fast paced.

MOC 827 is a three-day class. It covers how to administer an SMS 2.0 site. It's not as much on the installation process of installing a site server, but how you install clients and how you do normal administration — create packages, distribute software, do software metering, inventory, remote control, etc.

And then we have a five-day class, which is MOC 828. That class covers installation of a site, as well as support and deployment information. It looks at parent/child relationships. It looks at some of the support tools. It looks at adding additional site systems, and integration with SQL Server. It also spends a lot of time looking at log files on the client server as well as Network Monitor traces of client to server interaction so you can plan your network usage.

So those would be three course that are available. You'll find some CTECs have taken the five-day and three-day classes and combined them into a five-day "accelerated course." Those are also optional, but that's not a Microsoft Official Curriculum, whereas the 825, 827, and 828 are, and they are taught very frequently.

Heidi: "Is there an easy way to update (change) the SMS service account password? We have over 30 SMS sites using a single SMS service account residing in an NT account domain. SMS sites reside in a resource domain, trusted in the accounts domain. The last time we changed the SMS service account, we experienced some lockout problems. Is there a documented process or procedure for changing the SMS Service account for large organizations?"

Wally: This is basically the same question that somebody asked a number of questions ago. We're working on a tool, I believe they're calling it the Account Management Wizard or Tool, something to that effect, that will be out post – Service Pack 2 that will help out in this environment. However, for right now, the procedure is to manually change the account in User Manager for Domains, and then at each individual site run SMS Setup and set the account in SMS Setup.

You don't want to use the method of going to the Site Properties dialog box and going into the Accounts tab. You can set the accounts there; however, that takes a while to shut down the servers, and it doesn't get them restarted, and some of the issues you may have had were because maybe the new account information wasn't synchronized at all your domain controllers.

What we recommend in this case is don't change the password, but create a brand new account. So take your SMS service account, clone it to a new account name, give it whatever password you want, and then run SMS Setup and tell it to use the new account. That way you've got the old account that's still valid, and the new account that's valid, and all of your sites, when you run setup, they'll be able to interact and get all the services running, and do all their work. Then, when everybody's upgraded to use the new account, you go ahead and decommission the old account.

That's the best way of doing this in large environments so you don't have the problems that you had when you last tried.

Heidi: "Are there known issues with the SMS client and the Issmgr.vxd?"

Wally: I have no idea what that program is. I am not familiar with that. If it's a .vxd, it means it's a Windows 9x thing, and I'm not aware of any interaction problems between Windows 9x/95 and that specific virtual driver. You'd have to open up a case with PSS, or search the Knowledge Base on that. I haven't heard of any issue at all with that.

Heidi: "Should we update SMS with the QFE for servers and clients or wait for SP2? I know SP2 is in beta now." Actually, I think you said it will be in beta shortly

Wally: It's not out in beta yet.

Heidi: Okay. And the next question is: "Will SP2 require the QFE?"

Wally: Well, it depends on which QFE you're talking about. If you're talking about the one I mentioned a couple of times, being the client QFE Bundle, that is not required to upgrade to Service Pack 2. However, when Service Pack 2 does come out, there will be a QFE that's required, and the reason for that is to prevent RTM or SP1 clients from getting upgraded before the site's fully available for upgrading. In other words, the logon point might get upgraded, but the client access points aren't. So, that will be one required QFE that will be on the SP2 CD, so there will be instructions on how to install it.

From there, it really depends if you're having problems that the client QFE Bundle can solve: if you're having account lockout issues, or if you're having Windows 95/98 lockup issues. If you're having any of those issues, then the client QFE Bundle can help you out right now, whereas Service Pack 2, again, beta won't happen until later on this month, and it won't be released for awhile after that, depending on when people say it's ready. So, it just depends on what your needs are. If you can wait until Service Pack 2, then, obviously, it prevents you from having to deploy something right now. Test it and deploy it, and then deploy Service Pack 2 in a couple months or whenever it becomes available.

Heidi: I think the next question was partially addressed by your answer just now, but I'm going to ask it because it has a little bit of a different twist.

Wally: I haven't heard of any specific issues because of Y2K, any patches applied, or any Windows 95 lockup issues at all. I haven't heard that. Y2K was a big non-event for us and it went very well. SMS had no problems, and I'm not aware of any issues at all.

You'd have to open up a case with PSS and find out if they've heard of anything, but I haven't.

Heidi: "Our NT Security Group would like to implement share level security where you are using file level security within this share directory structure. What are the implications of attempting this radical change to your default method?"

Wally: There shouldn't be any issue at all, because, again, we just set the default permission at Everyone-Full Control, which, if you have things locked down at the NTFS level — I don't see why they want to do that, because they can't get any further than NTFS will allow them to. But the SMS services themselves don't use the share names, they use the internal drive writers and paths, or if they're going to remote sites then, yes. For example, if I'm a parent site and I'm sending data down to a child site I go to the SMS_sitesharename. So as long as my site address account has permissions there to interact, and then transfer my data between the share and the NTFS level, that's fine. As long as you don't lock us down beyond what the NTFS level is, you should be fine and not have a problem at all.

Heidi: "You mentioned that during setup you could use an approach that involves creating an .ini file that would have the account name and the password in it. Since this account would have full administrator privileges, doesn't the standard text file expose your domain to a security risk, since the file is not encrypted?"

Wally: The account that you're specifying there is not an administrative account. The account that you're using that .ini file for, the Smsaccountsetup.ini file, that is for the SMS Server Connection account and/or the SMS Client Network Connection account. Both of those accounts are just domain users. They're not administrative accounts at all. All you're doing is designating an account you want to use. So, just look at the default accounts we create, SMSServer_sitecode, SMSClient_sitecode, and you'll see that neither of those accounts are admins. They're domain users, and they're used solely to transfer data between clients and CAPs or between CAPs and logon points from the site server.

So, unless you're creating accounts on your own that are admins, and that you're opening up in that file and specifying in that file, then it's not a security issue because it's just a domain user account by default. Yes, that file would be a text file, and if you were giving it additional permissions, then, yes, you are opening yourself up. So, you want to go with our default permissions of domain user, and then you're safe.

Heidi: Regarding QFEs: "I know there's a QFE for servers specifically, different from the clients. Should that be installed immediately for any reason?"

Wally: There is a Server QFE Bundle. I'm not positive it's available in the field yet. Last I heard, earlier this week, it was still in final testing. So, it may not be available. The Server QFE Bundle is something that you'd want to apply if you had a large site hierarchy, more than 30 sites. Or if you had a lot of sites sharing a single SMS domain. Or if you have problems with summarization of status messages — then, you'd want to look at the Server QFE Bundle.

Otherwise, all those things are fixed in Service Pack 2.

Heidi: "When SP2 comes out, will it have to be applied to all SMS sites, or just the primary sites?"

Wally: It will have to applied individually to each site — to each site independently — and then through the admin console you'll select your secondary sites and you can say Upgrade, and we can push it out to your secondary sites. But you do have to apply it manually to each site.

Heidi: And with that question answered, we're going to wrap up this Support WebCast.

Thanks for joining us today. I do hope this session was useful for you. Once again, please send any feedback you have to feedback@microsoft.com. We are very interested in your feedback and I want to encourage all of you to let us know what you think.

Have a fabulous day and we hope that you join us again in the near future.