Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

Microsoft Systems Management Server 2003 : Developing Site Hierarchies (part 2) - International Site Considerations

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
6/12/2012 5:20:19 PM

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.

Real World: Enabling Client Features as Sitewide Settings

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:

  • Chinese (simplified and traditional)

  • English

  • French

  • German

  • Japanese

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:

  • Chinese (simplified and traditional)

  • Czech

  • Danish

  • Dutch

  • Finnish

  • French

  • German

  • Greek

  • Hungarian

  • Italian

  • Japanese

  • Korean

  • Norwegian

  • Polish

  • Portuguese-Brazilian

  • Portuguese-Portugal

  • Russian

  • Spanish

  • Swedish

  • Turkish

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. 

Other -----------------
- BizTalk 2009 : Dealing with Extremely Large Messages (part 2) - Large Message Encoding Component
- BizTalk 2009 : Dealing with Extremely Large Messages (part 1) - Large Message Decoding Component
- Microsoft SQL Server 2008 R2 : Client Setup and Configuration for Database Mirroring
- Microsoft SQL Server 2008 R2 : Testing Failover from the Principal to the Mirror
- System Center Configuration Manager 2007 : Site and SQL Server Backups (part 3) - Restoring ConfigMgr Backups - Performing a Site Reset
- System Center Configuration Manager 2007 : Site and SQL Server Backups (part 2) - Restoring ConfigMgr Backups - ConfigMgr Functional Crash
- System Center Configuration Manager 2007 : Site and SQL Server Backups (part 1) - Backing Up ConfigMgr
- Security and Delegation in Configuration Manager 2007 : Securing Configuration Manager Operations
- Security and Delegation in Configuration Manager 2007 : Securing the Configuration Manager Infrastructure (part 4) - Securing Service Dependencies for Configuration Manager
- Security and Delegation in Configuration Manager 2007 : Securing the Configuration Manager Infrastructure (part 3) - Securing Configuration Manager Accounts
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server