Client Components
Client component settings
within a given SMS 2003 site apply to all the clients assigned to that
site—they are sitewide settings. As such, there are no means of
installing certain components on one set of clients and other components
on another set. For that matter, there are no means of enabling one set
of attributes for a component for some clients and a different set of
attributes for the same component for other clients.
The most
frequent example of this situation concerns the Remote Tools component.
If Remote Tools is enabled as a client agent for the SMS site, all SMS
clients will be enabled with Remote Tools. If the Do Not Ask For
Permission configuration option is disabled for the Remote Tools Client
Agent, permission will be required on all clients before a Remote Tools
session can be established. In other words, if your site has 1000
clients and 100 don’t require Remote Tools, or if 100 don’t require
permission to establish a Remote Tools session, you can’t accommodate
those clients. They must all either have Remote Tools installed or not.
One solution would be to
create one SMS site for those clients that require Remote Tools (or
that require permission to establish a Remote Tools session) and another
SMS site for those clients that don’t require Remote Tools (or that
don’t require permission to establish a Remote Tools session) and to
enable Remote Tools appropriately. The same reasoning applies to all the
client component options.
At
first glance, it might seem that enabling client features as sitewide
settings isn’t that big a concern. Consider this case, however: suppose
you choose to enable Remote Tools for your SMS site and require that
permission at the client be granted before a Remote Tools session can be
established. Of course, all clients will be enabled with the Remote
Tools Client Agent and all will be required to grant permission before
the Remote Tools session can be established. So far, so good. You
also have a need, however, to establish Remote Tools sessions with your
Windows servers, which are also clients in your SMS site. As SMS
clients, they too will have been installed with Remote Tools and will
require that permission be granted before a Remote Tools session can be
established. The latter setting will cause problems at the servers
because typically no user is logged on at a Windows server to grant the
permission request. One
solution, of course, would be to create a separate SMS site to manage
the Windows servers. This would involve being able to identify the
servers on a subnet or subnets separate from those that the other SMS
clients are segmented on. This segregation might also involve a separate
investment in hardware and software to install the SMS site server for
that site, which might not be practical. Another solution would be to not
require permissions at any of the clients in your site—which could
raise other security or privacy concerns—or to forgo the use of Remote
Tools for your servers altogether. A
third solution might be to require permission but also allow the user
to change Remote Tools options at the client. This would let you as the
administrator turn off the permission requirement at each Windows
server. Unfortunately, this solution also lets users modify Remote Tools
attributes without regulation, which could pose other Remote Tools
problems on a client-by-client basis. In either case, the agent settings
would be reset to their sitewide settings at the client’s next update
cycle. Fortunately,
Microsoft provides a tool that allows you to modify Remote Agent
settings at specific clients so that they are different from the
sitewide settings. |
|
Location and Number of Clients
Another
factor that might affect the structure of your SMS site hierarchy is
the number and location of SMS clients and resources. Each SMS site can
potentially handle 10,000 or more clients.
The true number of clients
that any one SMS site server can manage will be dictated more
realistically by the server hardware—how powerful it is—as well as by
the number of SMS features and options you have decided to enable on
that server. The minimum hardware requirements for an SMS site server
are a 550 MHz Pentium processor, 256 MB of RAM, and a recommended 2 GB
of disk space. Let’s say that you have two site servers with this
configuration. Suppose you install and enable Remote Tools on one server
and install all options and enable all client components on the other.
The resource requirements for the latter site server will obviously
surpass those of the former server. It follows logically, then, that the
second site server could manage fewer SMS clients than the first site
server (perhaps 10 as opposed to 20—which also gives you some idea of
how minimal the minimum hardware requirements are).
Location of clients can
also be a factor, as it was with network performance. Your site server
can easily manage 10,000 SMS clients or more. However, their location in
the network might suggest the creation of multiple SMS sites depending
on the SMS features you’re implementing, the amount of network traffic
generated, the efficiency of your WAN link, and the number of clients
that need to be managed. For example, suppose you have three regional
locations. If these are relatively small offices—say, 10 to 20
clients—with a modest WAN link between them and the corporate SMS site
server, you might create a single SMS site, perhaps placing a
distribution point and a CAP in each local subnet. On the other hand, if
these regional locations had 100 or more clients, you might begin to
weigh the possibility of creating separate SMS sites in each location
and linking them together into a site hierarchy—depending, of course, on
what features (such as package distribution) you have enabled, the size
of packages, the frequency of advertisements, and so on.
International Site Considerations
Just as Windows supports a
wide variety of language versions in its operating system, so too does
SMS 2003 support a wide variety of language versions for both the site
server and SMS clients. SMS 2003 site servers support the following
languages:
Each of these site
server languages supports clients in its language, as well as
English-language clients, with the exception of French, which doesn’t
support English-language clients. Note also that English is the default
language for the server-side user interfaces for Chinese and Korean site
servers, but you can choose to display the local language characters.
The client-side user interfaces have been localized to the local
language.
In addition to English, SMS 2003 clients are available in 21 additional language versions:
For
the most part, you can create a site hierarchy with any combination of
language versions. Keep in mind, however, that some data that’s recorded
in one language version will be transferred between sites in that
language version. For example, site code, collection, package, and
advertisement names and Management Information Files (MIFs) will always
be transferred in the language version in which they were created. This
untranslated information can cause a problem if the parent and child
site servers are using different language code pages. If they’re using
the same code pages, data will be passed on and displayed correctly. If
not, the names might appear corrupted.
Default collection
names are defined at each site; however, in a parent-child relationship,
the default collection names from the parent site overwrite those of
the child sites. Again, if both sites are using the same code page to
view the default collection names, the names will appear correctly. If
the child site is using a different code page, the default collection
names might be corrupted.
If the site servers are
using different code pages, you do have a couple of options. You could
use all ASCII characters or a combination of ASCII and the language
characters either in the Name or Comment field of collections,
advertisements, packages, and programs properties to provide easier
identification. You could also use a separate Windows computer running
the SMS Administrator Console with the appropriate code page enabled.
Also, be aware that extended and double-byte character names aren’t
supported in domain and site server names. When your sites represent a
mix of languages, use ASCII characters when naming domains and site
servers.
More Info
The SMS 2003 Online Library, which includes the Microsoft Systems Management Server 2003 Release Notes,
discusses language considerations; consult these references for more
specific information. If language versions are a concern within your
organization, you should also periodically review the Microsoft
Knowledge Base articles published for SMS 2003 for references to
specific issues you might be encountering . |
Planning
If
you have installed an International Client Pack (ICP) for your SMS 2003
site and are planning to upgrade to an SMS service pack, be sure to
upgrade your ICP with the service pack version as well. If you don’t,
the ICP files will be overwritten and only English language clients will
be supported. Also, in order to correctly process and display
characters in the appropriate language in the SMS Administrator Console
on a Windows 2000 or higher computer, the Locale Regional Options
setting on that computer, located on the Control Panel, must be set to
match the language of the data you want to view or input. |
Administrative Model
The
structure of your organization’s Information Services (IS) support (as
well as company policies) will no doubt influence your SMS site
structure. Whether or not a proposed SMS site has a designated SMS
administrator locally might determine, for example, whether you install a
primary or a secondary site at that location. The size and location of
the administrative staff might also determine the number of child sites
in the hierarchy, as well as its depth.
This is a good
opportunity to make a recommendation regarding SMS administrative staff.
The reality of many corporate environments is that a small number of
persons manage large numbers of computers and networks and typically
fulfill many roles: database administrator, network administrator, mail
server administrator, and so on. The role of the SMS administrator is
just as significant and time-consuming. As you’ve already seen,
implementing SMS 2003 is far from trivial. A successful installation
requires a significant amount of planning and testing.
The ongoing
management of SMS clients and resources, troubleshooting, and
maintenance are no more trivial. Therefore, you could recommend that
many SMS tasks be delegated to other support personnel. For example,
help desk staff might be given the ability to initiate Remote Tools
sessions to facilitate their task of troubleshooting client problems.
Resource administrators in specific departments might be given the
ability to create and distribute packages to users and clients within
their departments. Nevertheless, these are administrative tasks, and
they make up only a small percentage of the overall management of an SMS
site or an SMS site hierarchy.
Active Directory Domain Model
Certainly the Active
Directory site structure that you’re using within your organization
will have a significant impact on the look of your SMS hierarchical
structure since you can use Active Directory site names to define SMS
site boundaries. Similarly, the domain model that supports your
organization will also influence your SMS 2003 hierarchical structure.
You might, from an administrative point of view, decide to simply let
your SMS structure reflect your Active Directory site structure or
domain model. If your organization spent a great deal of thought and
planning when implementing its Active Directory site structure and
domain model, and it’s well organized and optimized, then following that
model for your SMS site hierarchy will make the most sense. However, if
your current Active Directory site structure and domain model is less
than optimal, you might want to consider cleaning it up before you implement
your SMS site hierarchy or choose not to base your SMS hierarchy or
your site boundaries on your Active Directory structures.
If you’re implementing SMS in
a multiple-domain environment, especially in a mixed mode environment
(Active Directory and Windows NT domains), and you’re running SMS in
standard security mode, remember that SMS will still require the use of
the SMS Service account and several internal accounts to connect between
sites and site systems within a site. When multiple domains are
involved, and you wish to reference in one domain an SMS account such as
the SMS Service account from another domain, you’ll need to understand
how trust relationships have been implemented between those domains
(especially where Windows NT domains are involved) or create duplicate
accounts that Windows can use through pass-through authentication, or
both. Refer to your Windows documentation for more detail on the
authentication process and how it can affect your SMS sites.
