Configuring the Software Distribution Component

[Previous] [Next]

Additional settings can be configured for the package distribution process if the SMS defaults are not appropriate within your environment.

To access these settings, in the SMS Administrator Console, navigate to the Component Configuration folder under Site Settings, expand it, right-click on Software Distribution, and select Properties to display the Software Distribution Properties window, shown in Figure 12-39.

Figure 12-39. The General tab of the Software Distribution Properties window.

The Package Processing Thread Limit option on the General tab lets you identify how many threads to allocate to Distribution Manager to process packages for the site. The default value is 3, but it can range from 1 through 7. In this case, more is not always better. If your site server were only processing packages—and not performing any other functions—you might bump up this number, monitor the performance of the site server, and determine what value achieves an optimum level of performance between package processing and other server functions. A higher number of allocated threads may be appropriate and assignable.

However, if the site server has all SMS functions enabled—package distribution, software metering, Remote Tools, inventory collection, all site system roles, and so on—increasing the number of threads may prove to be detrimental to the overall performance of the site server. The best rule of thumb would be to try adjusting the number if you feel you need to improve package processing performance and then use the various tools available to monitor the performance of the site server and its other functions to find the best balance.

Two other options you can configure on the General tab are Location Of Stored Packages, which identifies for SMS the drive on which it should create the compressed package folder (SMSPKG), and the SMS Windows NT Client Software Installation account. When programs are executed at the client computer, they will run under the local user account's security context. Since most users are logged on as users and not as administrators, this means that these programs will run under the local user context. As you have probably discovered, most application software installs .DLL files, modifies registry entries, stops and starts services, and performs other tasks that require an administrative security context on the client. For Windows 95 and Windows 98 clients, this security context is not usually a big issue. However, it is a big issue for Windows NT clients since they maintain a local account database and provide more security over system modifications.

Security poses a problem when you're dealing with SMS packages. One of our main objectives here is to be able to remotely install software on clients without the users'—or the administrator's—intervention. Earlier versions of SMS simply had no way to deal with this problem, and eventually resource kit and third-party utilities were created to assist the SMS administrator.

SMS 2.0, however, does provide two solutions to the security issue. The first involves the use of an internal account that SMS creates on the client when a higher level of security access is required to run a program. This account, named SMSCliToknAcct&, is created automatically and is granted Act As Part Of The Operating System, Log On As A Service, and Replace Process Level Token user rights on the client. The SMSCliToknAcct& account will be sufficient in most cases. However, if the program execution requires that the program connect to network resources other than the distribution point, SMSCliToknAcct& will fail because it is created as a local account rather than a domain account. In this case, you should use the second solution, the Windows NT Client Software Installation account.

You create the Windows NT Client Software Installation account in the Windows NT domain (or domains) your clients are members of. The easiest thing to do, of course, would be to make the account a member of the Domain Admins global group in the domain that the Windows NT client is a member of. As you know, when a computer running Windows NT joins a Windows NT domain, the Domain Admins global group is made a member of the local Administrators group on that computer. Making the account a member of the Domain Admins group would give it the appropriate level of local rights on the Windows NT client (provided you haven't altered the local Administrator group memberships to exclude the Domain Admins group), but this arrangement is not very secure. Ideally, this account should be made a direct member of the local Administrator's group on each client computer or be given the appropriate level of security access required to run the programs you create.

After you create and configure the account appropriately, identify it to SMS on the General tab of the Software Distribution Properties window by clicking the Set button next to the Windows NT Client Software Installation Account text box and entering the name of the account in the Windows NT Account dialog box.

The Retry Settings tab of the Software Distribution Properties window is fairly self-explanatory, as shown in Figure 12-40. It lets you alter the retry settings for Distribution Manager's attempts to deliver packages and for Advertisement Manager's attempts to advertise programs and specify the delay between attempts.

Figure 12-40. The Retry Settings tab.