Site Design
Designing
a site involves analyzing several items and making decisions on the
settings to apply to those items. You will need to analyze items such as
client agent settings or policies to determine what the best setting is
for the environment the site will be managing. A great example of this
is the notification options selected for users to experience when they
receive advertisements to run packages on their systems.
Site design items are not specific to client agent settings; they consist of many things, including the following:
Is the server physical or virtual?
Where is the server?
What is the storage subsystem?
Is SQL Server installed on the site server or a separate system?
Is the site a primary or secondary?
What are the site boundaries?
Which ports will be used for client communication?
Is the site in mixed or native mode?
What is the hardware inventory frequency?
Who are the administrators and operators of this site?
What is the hardware inventory collecting information on?
Which discovery methods will be used?
What is the discovery method’s frequency?
What LDAP path is being queried for discovery?
What client push installation system types are selected?
What client push installation account is being used?
What rights does the client push installation account have?
Which roles does the site hold?
What site maintenance tasks are enabled, and what are their settings?
What site systems are in the ConfigMgr site, and what are their roles?
Is Wake On LAN (WOL) enabled, and what are its settings?
Although some settings may
only be useful in a disaster-recovery scenario, many of them can have
negative impacts when used incorrectly. As an example, when you’re
performing discovery from multiple ConfigMgr sites within a hierarchy,
it is possible for a system to be discovered multiple times with its
data discovery record (DDR) sent up the hierarchy and processed by each
system that handles it. This not only results in duplicate DDR analysis
effort, but every site will have to analyze each DDR and determine which
is newer. It is best to let sites discover only resources that belong
to that site, even for child sites—because discovered data flows up the
hierarchy. This is easily viewable by looking at the properties of any
discovered system or client in a collection.
Due to ConfigMgr’s
scalable design, sites may host multiple ConfigMgr roles. In most
implementations of 10,000 managed clients or fewer, you can use a single
site server with specifications similar to those listed in the next
sections.
Site Design for a Smaller Environment
In a small ConfigMgr site, you can configure a site server containing a management point as follows:
Dual Xeon 3GHz
4GB of RAM
SAS drives with battery-backed cache
RAID1 array for OS and SQL TempDB
RAID1 array for ConfigMgr files and SQL database and log
Site Design with 25,000 Clients
In larger environments of approximately 25,000 seats, Microsoft found the following site design to be sufficient.
Site server:
Dual Xeon 3GHz
4GB of RAM
SAS drives with battery-backed cache
RAID1 array for OS
RAID1 array for ConfigMgr files
RAID10 array (four disks) for SQL Server database, log, and TempDB
Management point:
Site Design with 50,000–100,000 Clients
When you scale up
to 50,000 clients, this site’s physical design adds NLB management
points to support the additional load. At 100,000 clients, the
management points are load-balanced across four systems and the
management points read from a SQL site database replica. The following
configuration details the hardware recommended to achieve this client
density on a single site.
Site server:
Quad Xeon 2.66GHz
16GB of RAM
SAS drives with battery-backed cache
RAID1 array for OS
RAID1 array for SQL TempDB
RAID10 array (four disks) for ConfigMgr files
RAID10 array (four disks) for SQL data files
RAID10 array (four disks) for SQL log files
RAID1 array for SQL replication distribution database
Four management points in the NLB cluster:
Dual Xeon 3GHz
4GB of RAM
SAS drives with battery-backed cache
RAID1 array for OS
RAID1 array for ConfigMgr files
RAID10 array (four disks) for SQL replication distribution database
Site Design with Over 100,000 Clients
When implementing
ConfigMgr with greater than 100,000 clients, use a central site with no
clients reporting to it. Ever since SMS 2.0, the central site was
intended for inventory rollup, status processing, centralized
administration, and reporting. The key difference is that although
during the SMS 2.0 timeframe hierarchies over 500 clients were
recommended to implement a central site with no clients, Microsoft now
baselines that architecture at hierarchies greater than 100,000 clients.
Client Architecture
When you define which
agents will be loaded into the ConfigMgr client, you are actually
defining the ConfigMgr client architecture. This architecture requires
planning to ensure future initiatives will work without issues.
As an example, defining
an initial ConfigMgr client cache value is an important task to perform
before rolling out clients to the enterprise. Although you can modify
the cache size on an individual client basis, initial packages may fail
if they exceed the default cache size.
Another setting is
choosing to have the client display a visual indicator or even generate
an audible alert when the client is being remote-controlled. Enabling
the audio is considered annoying by users, and systems have been known
to have problems with it. Displaying a visual indicator is suggested,
because it lets the user know the system is still being controlled and
identifies when the remote administrator has closed the session.
ConfigMgr clients
consist of multiple agents, each of which has unique settings that can
be assigned to them. When the settings are defined, ConfigMgr creates
XML (eXtensible Markup Language) policies, which are downloaded via the
management point to clients. The following agents have policies defined
that collectively make up the ConfigMgr Client architecture illustrated
in Table 7.
Table 7. Client Agents
| Agent | Settings |
|---|
| Hardware Inventory Client Agent | Defines
which objects should be queried from the system hardware, Registry,
file system, and so on, and the frequency in which they should be
inventoried |
| Software Inventory Client Agent | Defines which file extensions should be scanned and the frequency |
| Advertised Programs Client Agent | Defines client behavior when advertisements run |
| Computer Client Agent | Used
to specify the accounts ConfigMgr will use for network access,
customization of balloon pop-ups, reminders for users, BITS, and restart
settings |
| Desired Configuration Management Client Agent | Defines the interval in which compliance against the defined baselines are evaluated |
| Mobile Device Client Agent | Only applies to Windows Mobile devices, defined hardware, software, file collection, and software distribution settings |
| Remote Tools Client Agent | Defines
which administrators can remote-access client systems using the Remote
Desktop Protocol (RDP), and settings to manipulate the end-user
experience while being remotely viewed |
| Network Access Protection Client Agent | Maintains
settings for compliance and out-of-compliance resolution and
notification to end users; works in conjunction with Windows Server 2008
Network Policy Server; requires Configuration Manager 2007 R2 |
| Software Metering Client Agent | Specifies the schedule in which software-metering data is collected |
| Software Updates Client Agent | Defines
the schedule for processing Windows Update deployments, reevaluation,
installation behavior, and end-user experience settings |
Client architecture is
fairly flexible in that if a setting is not initially deployed
correctly, it can be changed centrally with the clients updating to the
new setting in fairly quick fashion (as fast as the setting for the
Computer Client Agent Policy Polling Interval). The importance of
understanding the agents and their settings is primarily to facilitate
creating a correct ConfigMgr site design and to position the ConfigMgr
deployment team for success.
Multilanguage Scenarios
In
today’s global economy, more companies have networks spanning multiple
countries than ever before. The nature of the different languages used
from country to country presents new challenges for system
administrators. When Microsoft Windows client operating systems are
installed using the native, non-English language of the country,
ConfigMgr administrators must look at available options to address their
system management needs. The International Client Pack (ICP) is a
specialized set of client files split across two separate downloads,
supporting the following 22 languages. You can download the ConfigMgr
2007 SP 1 ICPs by searching for ICP at www.microsoft.com/downloads.
ICP1 contains the following languages:
English
French
German
Japanese
Spanish
ICP2 contains all languages from ICP1 plus the following:
Chinese (Simplified)
Chinese (Traditional)
Czech
Danish
Dutch
Finnish
Greek
Hungarian
Italian
Korean
Norwegian
Polish
Portuguese
Portuguese (Brazil)
Russian
Swedish
Turkish
ICPs are client files only. The files consist of the following:
ICP Versioning
ConfigMgr site and
service pack versions must correlate to the ICP version implemented. As
an example, you should only install the Microsoft System Center
Configuration Manager 2007 SP 1 International Client Packs on a
ConfigMgr 2007 SP 1 site.
Caution: ICPs and Service Packs
When using ICPs
with ConfigMgr, you cannot upgrade to a new service pack level until the
associated ICP is also available. ICPs are released shortly after
service packs. Once the ICP is released for a new service pack, install
the service pack and then install the new ICP.
ICPs are versioned in a
fashion where the client version number is greater than the service
pack level of the current ConfigMgr client. You can identify service
pack, ICP, and hotfix numbers from the version number, which is the last
four digits of the Configuration Manager 2007 version number. Let’s use
a sample scenario to illustrate how clients know they need to upgrade
to an ICP-versioned client. The following illustrates a current
ConfigMgr 2007 RTM install that is being upgraded to SP 1:
ConfigMgr 2007 RTM Client version— 4.0.5931.0000
ConfigMgr 2007 SP 1 Prerelease version— 4.00.6086.1000
ConfigMgr 2007 SP 1 Client version— 4.00.6221.1000
ConfigMgr 2007 SP 1 ICP1 Client version— 4.00.6221.1400
ConfigMgr 2007 SP 1 ICP2 Client version— 4.00.6221.1700
ConfigMgr 2007 R2 Client version— 4.00.6355.1000
|
Microsoft TechNet at http://technet.microsoft.com/en-us/library/bb680389.aspx states the following:
“You can determine
whether an ICP is installed by checking for multiple language folders,
such as the 00000409 folder for English and the 00000407 folder for
German on the site server. There is a folder for each client language
supported by that ICP.
The first digit of the fourth part of the version number, such as n
in n000, is the service pack release number. As an example,
2.50.2485.2000 denotes SP 2. If the Configuration Manager 2007 version
number is 2.50.2485.3000 or higher, then the service pack is SP 3.
Additionally, ICP1 has
a 4 as the third-to-last digit. For example, 2.50.2485.2400 indicates
SP 2 ICP1, and 2.50.2485.3400 indicates SP 3 ICP1. Likewise, ICP2 has a 7
as the third-to-last digit. For example, 2.50.2485.3700 indicates SP 3
ICP2.
The last three digits are the hotfix version number, which can range from .0001 to .0299.
If you apply
Configuration Manager 2007 SP 2 ICP1 to a Configuration Manager 2007 SP 2
U.S. English site that had several hotfixes installed after SP 2 was
installed and files with the same name are included in ICP1, then ICP1
overwrites the newer files because the files in ICP1 do not contain the
bug fixes. If the ICP overwrites new files, whatever problems caused you
to apply the hotfixes might reappear. As an example, you may have
previously applied a hotfix to prevent Configuration Manager 2007 APM32
from using the CPU at 100 percent. Later you apply ICP1, which does not
contain the hotfix. After ICP1 installation, your site server CPU usage
is back to 100 percent. To prevent this from occurring, contact
Microsoft Customer Support and Services (CSS) and obtain the version of
the hotfix that correctly matches the ICP you intend to install before
ICP installation. After you install the ICP, immediately install the
hotfixes that were released later than the ICP.”
|
To
determine the version of an ICP on a site server, check the version
value of HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\Setup in the
Registry. To validate the management point has been updated, verify that
language directories such as 00000409, 00000407, and so on, exist and
contain .mst files. To verify clients have received the updated client
binaries, create a custom query and include the Client Version property
from the System Resource class. To verify the client has received the
updates at the client, open the Configuration Manager applet in Control
Panel and view the version of each client on the Components tab.
Caution: ICPs and Hotfixes
When you’re applying a hotfix to an ICP client or site, the hotfix must support the ICP version running on the system.
ICP Scenarios and Implementations
If an ICP is installed on a site server, the only prerequisite is the operating system must be English.
End-user experience will vary depending on whether or not the ICP is deployed. The following scenarios could exist:
Scenario 1— The site server is running the English operating system without any ICP.
Clients
running native language OS will show the ConfigMgr client in English;
users may not be able to read ConfigMgr dialog boxes.
Clients
running the Multilanguage User Interface (MUI) will have the same
experience as those running native OS; users may not be able to read
ConfigMgr dialog boxes.
Scenario 2—The site server is installed in English and ICP1 or ICP2 is installed.
Clients
running native language will be able to see the ConfigMgr client dialog
boxes in their language as long as the ICP version includes their
language.
Clients
running MUI will be able to see the ConfigMgr client dialog boxes in
their language as long as the ICP version includes their language.
Take
special considerations when deploying the ICP to ConfigMgr hierarchies.
Always read the release notes and product documentation, and test
thoroughly in a lab and pilot environment.
