SMS Design and Planning Issues

Goto the SMS Home Page
This page details problems and issues relating to Designing and Planning an SMS Infrastructure

Can I Install a Secondary Site in a Different Domain to the Parent Primary without Establishing a Trust?

Contributed By: Wally Mead [MS]
 If you need to install a new Secondary site in a different Domain to it’s Parent Primary you can establish a trust although a better option would be use to use Pass Through Authentication as discussed in this article… [Go to article]
 

Can I install SMS 2.0 on a cluster server?

Has anyone installed SMS 2.0 on a cluster server? any problems to report or gotchas to look out for?

Contributed By: Cliff Hobbs [MVP SMS]
 Microsoft Knowledge Base Article 237366 'SMS: Microsoft Systems Management Server and Clustered Server Environments' provides the details on this.
 

Can SMS 1.2 and 2.0 co-exist in the same site?

The company I'm working at, plans to roll out SMS 2.0 in parallel to an existing SMS 1.2 architecture and finally replace it altogether when the roll out is complete. In talking to a Microsoft SMS consultant, it appears that this is not feasible, i.e. SMS 1.2 and 2.0 cannot coexist on the same network and ultimately the SMS will crash if allowed to do so.

Can you guys please send me specific reasons as to why SMS 2.0 & 1.2 can not co-exist on the same network/domain?

I'm asking this because the server hardware currently in the field can't really handle any new software, and the company prefers to leave the SMS 1.2 infrastructure untouched while we roll out 2.0 on new server boxes. I, on the other hand, am recommending that SMS 1.2 be uninstalled prior to rolling out SMS 2.0

Are specific SMS files modified (ex. SMS 1.2 modifies SMS 2.0's smsls.bat) when version 2.0 is introduced on the same network as version 1.2?

1.2 and 2.0 can certainly coexist. In fact, 1.2 can report to 2.0, and the two could be used together, though with some limitations. But coexistence on the same network shouldn't be a problem. Just be sure to be using 1.2's SP4 - it introduced some changes to ensure this coexistence would be peaceful.

You have to keep in mind that when configuring logon Discovery/ Installation methods SMS 2.0 will grab all existing DC's and that SMS 2.0 and 1.2 server functions cannot reside on the same systems. This means that a temporary 1.2 / 2.0 coexistence means that you'll have to reduce the number of SMS 1.2 server to the bare minimum, before you can roll out the server side of your SMS 2.0 environment.

Also, check to see if you really have the 1.2 SP4 netlogon files, because the SP4 scripts supports SMS 2.0 coexistence on the client side.

Finally, you should the rename the SMS 1.2 SMSLS.BAT and configure you logonscripts accordingly, because 2.0 also has a file named SMSLS.BAT.

For more information, see the "Microsoft Systems Management Server Version 1.2 and 2.0 Interoperability" whitepaper.

As your deployment proceeds, you might want to de-install the 1.2 clients and then install the 2.0 clients - that's a pretty common practice. But that can be done on a client by client or site by site basis. But 1.2 and 2.0 clients can exist within the same organization, or even the same physical location. 1.2 to 2.0 upgrades should work fine, but most people seem to prefer the 1.2 de-install route.
 

Can Two Primary Sites at Different Service Pack Levels Share the Same Domain?

Contributed By: Hans Schefske [MVP SMS]
 If you’re planning on introducing another Primary site at a later Service Pack level into a Domain that currently has other Primary(s) then take care… [Go to article]
 

Can two Site Servers share the same subnet?

Contributed By: Cliff Hobbs [MVP SMS]
You can setup two site servers on the same subnet. To avoid problems you should take care not to have the same boundaries on both of the servers.  Fewer, bigger servers with a flatter structure is better than a deep structure with lots of site servers (other factors may prevent you from doing this though such as network links, number of physical sites, etc.)  Keeping the structure as simple as possible reduces the SMS administrative burden and will eliminate some SMS issues.
 

CCR Errors with Domain with 3 characters

Contributed By: Cliff Hobbs [MVP SMS]
 If your domain is 3 characters long look out for this SMS bug documented in Microsoft Knowledge Base Article 265882 'SMS: Client Configuration Manager Does Not Append .ccr to the Client Configuration Request.'

If the initial installation for a client that is a member of a domain name that is composed of less than four characters is unsuccessful, the resulting retry may not be processed. Under these conditions, Client Configuration Manager (CCM) does not append the .ccr file extension to the Client Configuration Request (CCR) when it is moved to the 'SMS\Inboxes\Ccrretry.box' folder (the file name remains as 'netbiosname.domainname'). A Hotfix is available.
 

Consider installing another Remote Control program

Contributed By: Cliff Hobbs [MVP SMS]
When installing your SMS servers, consider installing another Remote Control program such as pcAnywhere on your site servers. Although this involves the cost of an additional license, you can use this additional program to apply SMS QFEs, Service Packs, etc. that may make an SMS Remote Control session either not viable or potentially unstable (the last thing you want to do is logon to a SMS server using SMS Remote Control, apply a patch that may kill your SMS session and the server is left in an unsecure state).
 

Do my Site Servers need to be Domain Controllers?

Can the SMS Primary site server be an NT member server? Or does the site server have to be a PDC?

In SMS 2.0 it can be either. In 1.2 it must be a Domain Controller. It may be better to install all of your Site Servers on Member servers as this allows you to control who has access to them through the local SAM.
 

Does anyone have a document that introduces SMS to users?

Install the SMS Support Tools from the SMS CD which installs the 'Sample Client Preparation Document' ('Client.WRI') which you can customise for your own use.
 

Does it matter whether the Partition I Install SMS to is NTFS or FAT?

I'm in the process of planning my SMS installations. Does it matter whether the partition I install SMS to is NTFS or FAT?

Contributed By: Cliff Hobbs [MVP SMS]
 As documented in Chapter 6 "Installing SMS 2.0 Sites" of the SMS Administrator's Guide, you have to have an NTFS partition on which to install your SMS Site Server.  Why?  Well for starters SMS uses NTFS permissions to secure access to the various SMS directories and shares that are running on the Site Server.  Also NTFS is much more secure than FAT.

As for your clients it doesn't really matter what file system they are running.
 

Have Microsoft published any 'Best Practices' for SMS Site Design?

Yes - you'll find a link has been added to the Hot Links page.
 

How Do I Configure SMS to Work through my Firewall?

Contributed By: Cliff Hobbs [MVP SMS]
See Microsoft Knowledge Base Article 200898 'SMS: How to Use Systems Management Server Through a Firewall' for details.
 

How Do I Control which CAP and DP my clients use?

Contributed By: Cliff Hobbs [MVP SMS]
By default, a client computer selects the CAP and DP at random the first time it installs the SMS client software. This is fine in single site environments of those where network bandwidth isn't an issue. However, in the majority of cases you'll want to control which CAP and DP you clients use as the last thing you want is for a client in London to be using a CAP/DP in Edinburgh. The BackOffice Resource Kit provides two tools to help you with this:

  • SetSMSSvr.exe

  • PrefServ.exe

Details on these utilities and their usage can be found in the BackOffice Resource Kit.
 

How Do I Move SMS Site Servers Between Domains?

I have an SMS Primary server in X domain. The Central site server (parent of my primary site) in domain Y domain. There are 4 Secondary sites also sitting in Y domain. I need to move my Primary server into domain Y and was wondering what is the best practise to be followed in such a case?

Contributed By: Cliff Hobbs [MVP SMS]
 Microsoft have written the 'Moving SMS Servers Between Domains' whitepaper for such cases which you can download from:

http://www.microsoft.com/smserver/techinfo/administration/20/maintaining/dommov.asp

How Does SMS interact with Active Directory?

Contributed By: Cliff Hobbs [MVP SMS]
 If you're wondering how SMS 2.0 interacts with AD the "Active Directory/Systems Management Server Collection Synchronization Tools" will help which you can download from:

http://www.microsoft.com/smserver/downloads/20/tools/smsadsync.asp

How Many Licenses Do I Need to Run SMS in my Environment?

Contributed By: Cliff Hobbs [MVP SMS]
See the 'Do I Need an SMS License for my Secondary Site Server?' article on the Site Server Miscellaneous page  for details of SMS licensing.
 

How much Data gets Transferred to a Secondary Site when you Install it from the MMC?

Contributed By: Cliff Hobbs [MVP SMS]
SMS creates as 53 MB package on the destination server called 'SMS_BOOTSTRAP.PKG' which it uses to install the Secondary site.
 

How Resilient is SMS?

Does anyone have any experience of the resiliency of SMS? For example, I have software distribution setup on a server with the CAP and DP on a dedicated 9 GB E: drive. The server goes bang or some form of disaster hits the site. To recover, I rename a box of the same spec to the NT name of the failed site, but there is nothing on the E: drive.

Is SMS clever enough to notice that the CAP and DP are missing and therefore re-create them as they were on the original server?

I have encountered this several times and yes it will be able to recreate the CAP as long as you retain the same NetBIOS Name and the same drive letter is available (the SMS Site Component Manager will recreate the CAP when it notices that the CAP is not set up properly).

Regarding packages, you may need to go into the MMC and tell SMS to refresh all of the packages that live on that DP.  I don't think this is an automated process.
 

Is it Possible to Share Computers between SMS Sites?

Contributed By: Wally Mead [MS]
 Wondering if you can install a Secondary, CAPs or other components for a new Site on servers already being used by another SMS Site?.. [Go to article]
 

Is SMS Affected by an NT 4.0 to Active Directory Upgrade?

Contributed By: Michael Griswold [MS]
 Thinking of upgrading your domain from NT 4.0 to Windows 2000 with Active Directory and worried about the impact on SMS?.. [Go to article]
 

Is there a Limit on the Number of Secondary Sites that Can Be Attached to a Primary?

Contributed By: Wally Mead [MS]
 Planning an effective Site Hierarchy is a key part of your SMS design and this is one question you're bound to ask and here's some advice… [Go to article]
 

Is there an easy way to document my SMS environment?

I've got a smallish SMS environment (60 or so users, 1 site server) that I'd like to document - I'd like to have an understandable document describing the environment to include with the rest of my network documentation. Are there recommended methods and tools to accomplish this?

You could use Network Trace to help you. You could also use Ecora to document your NT/Windows 2000 boxes and Exchange servers:

https://www.ecora.com/ecora/

NTFS permissions on an SMS server

We're trying to lock down our server NTFS permissions and I'm looking for some documentation on what needs access to the various SMS directories on our SMS servers. Can anyone steer me towards such a source?

Contributed By: Cliff Hobbs [MVP SMS]
Chapter 4 of the SMS 2.0 Administrators guide is pretty good for all the default permissions, and explaining which shares and directories can be locked down tighter (you can find this on page 98 of the SMS Administrator's guide but, as of SP1, this was changed a bit).

A more current list is on pages 707-710 in the Microsoft Systems Management Server 2.0 Administrator's Companion which is available from the FAQShop Bookstore.

The permissions for CAPs have changed in SP2 as detailed in the readme file. The readme_operations file is also worth reading on the SP2 CD. Also take a look at the security whitepaper that ships on the SP2 CD which available from here.

Although the Administrator's guide hasn't been updated for SP2, in addition to the Rlease Notes being updated there is an new SP2 whitepaper up at:

http://www.microsoft.com/smsmgmt/techdetails/sms_sp2_fixes.asp

Reducing the Number of NT Accounts created by SMS

Contributed By: Cliff Hobbs [MVP SMS]
Every time an SMS site is installed, the installation process creates a unique client connection account called SMSClient_XXX (where "XXX" denotes the site code), and a unique server connection account called SMSServer_XXX.

 Where several SMS Sites share a single domain, the number of accounts generated can become quite large.

To help overcome this, from SP1 onwards it is possible to specify the Server and Client Connection accounts SMS Setup should use when installing an SMS site through either the use of the following command line:

setup /ServerAccount DOMAIN\<account> /ServerPassword <password> /ClientAccount DOMAIN\<account> /ClientPassword <password>

As an example, to use DomainA\SMSServerAccount as the server connection account (with a password of Peter)  and DomainA\SMSClientAccount as the client connection account (with a password of Paul), you would type the following at the command line:

setup /ServerAccount DomainA\SMSServerAccount /ServerPassword Peter /ClientAccount DomainA\SMSClientAccount /ClientPassword Paul

This command however can only be used when you run the Setup program directly from the SMS CD - not a lot if use when you want to install a Secondary site over-the-wire. All is not lost though. You can create an INI file that specifies the server and client connection accounts you want to use. You then place this file in the \WINNT\System32 directory of the Secondary server before you install it.

The INI file needs to be called SMSAccountSetup.ini and has the following format:

[ServerAccount]
Name=SMSServerAccount
Password=Peter

[ClientAccount]
Name=SMSClientAccount
Password=Paul

When the setup program is run, it checks for the existence of this INI file.  If this file exists, the accounts and passwords contained in this file are used as the command-line arguments.  You can also use the INI file to setup a Primary site to save you having to manually type the command line each time.

Important Points

  • You cannot use the command line to install a remote Secondary site as you need to be able to run the command line from the server itself.
     

  •  You need to create the Server and Client connection accounts BEFORE you run setup.  Failure to do this will result in an error when the setup wizard has completed and SMS won't be installed.  These two accounts need to be a member of the Domain Users group.
     

  • You can only specify passwords up to 14 characters when using this method to install SMS, even though NT/2000 supports passwords up to 16 characters.
     

  • If for any reason you need to run a site reset make sure you do it with the same command line you used to originally install the site - if you don't then the Server and Client connection accounts get created for the site you are running the Site Reset on.

    • On a Primary site use the original command line used to install the Primary site or make sure the SMSAccountSetup.ini file exists

    • On a Secondary site make sure the SMSAccountSetup.ini file exists

Failure to do so will result in SMS generating the Server and Client connection accounts and passwords and using these for the site in question.

  • Remember that the SMSAccountSetup.ini is a plain text file - delete it from the \WINNT\System32 folder as soon as the installation has completed, or check who has access to this directory to close a potential security loophole

  • If you need to change the passwords for the user specified server or client connection accounts, you need to re-run the Setup program with the same command line as the initial installation, but this time specify the new passwords (or modify the SMSAccountSetup.ini file to reflect the changes).

Microsoft Knowledge Base Article 235169 'SMS: Reducing SMS Accounts Required for Installation on Large Domains' contains further information relating to this problem as does the Security Essentials whitepaper that ships on the SP2 CD or you can download a copy from here.

SMS Server Network Connection Account
The SMS Server Network Connection Account (default SMSServer_sc where 'sc' is the three character SMS Site code), is used by remote site systems to connect back to the site server when transferring data.  The account must be created in the local domain as a member of the Domain Users group before the first site is installed in that domain.

SMS Client Connection Account
The SMS Client Connection Account (default SMSClient_sc where 'sc' is the three character SMS Site code), is used by SMS clients to connect to Client Access Points and Distribution Points even when no user is logged on or if the logged on user doesn't have permissions to the CAP.  (Connection to Logon Points is made with the credentials of the logged on user).

The Client Connection Account must be created in each domain as a member of the Domain Users group before the first site is installed in the domain.  This account also needs to have Change access to the CAP share and it's directories.

It is recommended that two additional client connection accounts are configured on each site server once the site installation has completed to allow for account rotation and prevent clients from being orphaned should the first connection account get locked out for any reason.  These must be created in the each domain as a copy of the original Client Connection Account.

 Further details regarding SMS Security can be found in the Security Essentials whitepaper which available from the 'Technical Details' section of the Microsoft SMS web site (http://www.microsoft.com/smserver/default.asp)
 

Secondary Site IP address change

Lets assume that some Network guys goes and changes four of your Secondary Sites IP Addresses (without telling you) (-: The question is .. . what will I loose? Do I need to reinstall the Secondary Site, or SMS will find that out by itself?

If the IP's are now not in the boundaries you set, you need to include the new subnet. SMS will identify the boxes and make the change in its database. If they are new but still in the boundaries, eventually SMS will get around to recognizing the change pretty smoothly without your intervention. Make sure your WINS server knows about the change (especially if its in a different domain) and all will be well.

In both cases, synchronizing the domains and WINS is the key to the speed of this process (if we are indeed discussing separate domains here).
 

Should I install a CAP on a remote site with 15 users?

I have a server that is off site across a T1 line back to our main site. There are about 15 users that logon to that server. Should that off site server be a CAP?

Contributed By: Cliff Hobbs [MVP SMS]
The jury is out but things to bear in mind:

  • If you want to reduce some of the traffic over the WAN link, make it a Logon point, CAP, and a Distribution Point. This way the interaction the remote clients have with the system will be with that local server.
     
  • Unless you install a separate site server over there, you would still need to use the Preferred Server tools in the resource kit to force those clients to use that local CAP or DP. Otherwise they will pick a CAP or DP randomly.
     
  • If you have a T1 link back to the main site, and the network is not overly loaded up, the T1 would afford adequate connection speed so as not to cause a lot of client issues... key of course is existing link load without SMS impact.

Sizing SMS Servers

Have Microsoft published any information on sizing SMS Servers?

Contributed By: Cliff Hobbs [MVP SMS]
Yes:

http://www.microsoft.com/smserver/techinfo/planning/smssizing.asp

SMS Client Network Traffic Statistics

Contributed By: Hans Schefske [MVP SMS]
 Need an idea of how much network traffic the SMS Client generates? Here’s some pointers… [Go to article]
 

SMS Servers in the Resource or Accounts Domain

When installing SMS in a Master Domain model should the SMS servers be installed in the Master Accounts Domain or Resource domain?

Contributed By: Cliff Hobbs [MVP SMS]
As SMS uses NT domain security, it is important that you have a thorough understanding of NT domain security and the issues surrounding it. To help you with this, Microsoft have created the Security Essentials whitepaper at:

http://www.microsoft.com/smsmgmt/techdetails/secessentials.asp

Other things you need to consider are:

  • Logon Points - Whatever domain you put the site servers into, all of the domain controllers will be installed as Logon Points. So if you install your site servers into the Resource domain, you'll have to add the Master Accounts domain to get it's domain controllers to install as logon points.
     
  • SMSService Account - The 'SMSService' account MUST have domain administrator rights in any domain(s) that will participate in SMS. So if you install your site servers into the Resource domain you will have to create a duplicate account in the Master Accounts domain, or alternatively use an account from the Master Accounts domain.
     
  • CAPs - There is one exception to the default SMS NTFS permissions being sufficient and that is where the CAP is in one domain and the user account is in another. In this case SMS sets the security rights through NTFS to the Users and Guests groups from the domain the CAP is a member of. If the CAP is in a Resource domain and the user accounts are in the Master Accounts domain, you need to grant NTFS permissions for the Domain Users group from the Master Accounts domain to the CAP - if you don't the installation may fail.

SMS Site Code Reserved Names

Are there any limits on the Site Codes I can use in my SMS hierarchy?

Yes, check out:

http://www.myitforum.com/articles/1/view.asp?id=107

SMS Vs Group Policy

Contributed By: Cliff Hobbs [MVP SMS]
 Confused over whether to use SMS or Group Policy/ IntelliMirror, what you’d use each one for and why? Well let us try to clarify things for you… [Go to article]
 

Why should I install SQL and SMS on the same box?

I'm thinking there would be a big performance hit if SQL server and SMS lived on different boxes. Any thoughts/documents?

Contributed By: Cliff Hobbs [MVP SMS]
There are pros and cons with installing SQL and SMS on the same or different box, some of which are:

Same Box

  1. It will usually cost less as less hardware is required

  2. The Server's bus I/O is faster that Network I/O (SQL and SMS do a LOT of talking)

  3. Single point of Administration

  4. Best if you don't already have overpowered SQL servers

  5. Easier to upgrade

  6. You're eliminating network devices as a point of failure (such as hubs and routers )

Separate Box

  1. Good if you have a crack database team and they help maintain the SQL side

  2. Best if you already have database servers that are over-powered or over-licensed

  3. Fault tolerance, if you loose SMS you don't loose the data - on the other hand, if you loose data you still keep SMS

Your decision to run SQL and SMS on the same or different boxes will be determined in a large part by the size of your organisation (for example if you have say 30,000 clients, you would be better off running SQL and SMS on different boxes.
 

Will SMS 2.0 Work with Windows Server 2003?

Contributed By: Jeff LeBlanc [MSFT]
 Windows 2003 maybe the best OS since sliced bread but can SMS 2.0 take advantage of it?..  [Go to article]
 

WINS Replication and SMS Site Servers

Contributed By: Cliff Hobbs [MVP SMS]
This article looks at WINS, Firewalls and VPNs...  [Go to article]
 

© FAQShop.com 2003 - 2008

Goto the SMS Home Page

 Email the Author