Microsoft System Center 2012 Configuration Manager: Administration Cookbook

By Brian Mason , Greg Ramsey
    Advance your knowledge in tech with a Packt subscription

  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Designing a System Center 2012 Configuration Manager Infrastructure

About this book

Microsoft System Center 2012 Configuration Manager (CM12) is a systems management application for managing large groups of Windows-based computer systems. System Center 2012 Configuration Manager provides remote control, patch management, software distribution, operating system deployment, network access protection, and hardware and software inventory.

This practical cookbook shows you how to administer System Center 2012 Configuration Manager and understand how to solve particular problems/scenarios

Packed with over 50 task-based and immediately reusable recipes, this book starts by showing you how to design a System Center 2012 Configuration Manager Infrastructure. The book then dives into topics such as recommended SQL configuration for System Center 2012 Configuration Manager, deploying Windows 7 with Operating System Deployment (OSD), deploying Applications and Software Updates, managing Compliance Settings, managing Sites and managing Inventory amongst others.

Publication date:
September 2012
Publisher
Packt
Pages
224
ISBN
9781849684941

 

Chapter 1. Designing a System Center 2012 Configuration Manager Infrastructure

In this chapter we will cover the following topics:

  • Dividing up site system roles

  • Creating migration jobs

  • Installing SQL the right way

  • Managing Internet-facing clients

  • Using remote and workstation distribution points, and BranchCache

 

Introduction


In this chapter, we will walk through the various setup scenarios and configurations for System Center 2012 Configuration Manager (CM12), which covers both the migration from CM07 to CM12 as well as fresh CM12 installation scenarios. If you are inheriting a hierarchy that's already been built, you may still find some helpful information here, especially in terms of offloading site system roles if your server is overworked.

 

Dividing up site system roles


It is likely that most installations of CM consist of a single primary site with all roles loaded locally on the same server. Depending on the hardware used (RAM and disk IO chief among them), this will suffice for many organizations. As companies grow and the workload of CM starts to stress the hardware of a single server, administrators need to offload roles to other servers.

Note

Note that while it was a best practice to offload SQL in CM07, we now advise keeping SQL on box in CM12 as SQL replication has replaced much of the file based replication of CM07. CM12 is native x64 code so there is no performance hit for a WOW64 translation like there was with CM07 on x64 servers. Underpowered VMs, however, might benefit from offloading SQL to more powerful servers.

Getting ready

Admins should move roles off as described in the the following How to do it... section until the primary site starts to perform as expected. We will start with both the Distribution Point (DP) and the Management Point (MP). Unlike CM07, CM12 allows for more than one MP with no default MP to define. Offloading these two roles will do more to alleviate stress than any other steps. For this step, have another server ready where you can move these roles to.

How to do it...

  1. Add the machine account of the primary site to the local admin's group of the server taking on the MP and DP role.

  2. If you need to prevent content from copying to any particular drive on the new server, drop a file on the root of the drive named no_sms_on_drive.sms.

  3. From the CM12 admin console, navigate to Administration | Site Configuration | Servers and Site System Roles. From the Home tab on the ribbon, click on Create a Site System Server.

  4. Enter the name of the new server, select the primary site code, and enter the FQDN of the new server.

  5. Check the boxes for both Distribution Point and Management Point.

  6. Check the box to allow CM to install the IIS role on the new server.

  7. CM12 now gives you the ability to force content on a DP to drive letters of your preference. Choose as needed.

  8. CM12 has moved the PXE service point to the DP. Select this option only if you plan to image devices with an F12 boot. Enable multicast only if needed. The rule of thumb in security is "less is better"; you reduce the surface area of attack and reduce the odds you have something to patch down the road.

  9. CM12 can now verify the content of your packages on a DP, which reduces the chance of clients failing to install an application due to corrupt files. CM12 now allows you to associate DPs to boundary groups. Use this feature only if you're trying to protect the network, otherwise leave this alone as it introduces another possible point of failure in a distribution that you may have to troubleshoot one day.

  10. For the MP settings, use the defaults for now; you can always set up SQL replication to the MP at a later time to reduce additional load.

  11. Complete the wizard, and then read the sitecomp.log and distmgrr.log on the primary server and MPSetup.log on the new server to verify a successful installation.

  12. Test the new MP by stopping the SMS Agent Host service on the primary, and then verify that clients are contacting the new MP (check the mpfdm.log on the new MP).

  13. Test the new DP by distributing content to it.

With a working MP and DP on another server, those roles can now be removed from the primary site. Follow these steps to remove the roles:

  1. From the CM12 admin console, navigate to Administration | Site Configuration | Servers and Site System Roles and select your primary site in the right-hand pane.

  2. In the bottom pane, select both Management Point and Distribution Point (use Ctrl + click) and then click on Remove Role from the ribbon.

  3. If you see a warning that this is the last management point for the site, click on No and go back to testing the new MP as the site is not aware that it is working.

How it works...

Once all IIS roles have been offloaded, IIS can be removed from the primary site. This strengthens security of the server and frees up resources for the remaining duties of the site. As you offload roles, the server has less to do as resources are freed up.

There's more...

Beyond IIS-based roles, there are still several items that can cause stress to the primary site server, which you can offload to other servers.

Offloading the SUP

With the MP and DP offloaded, the bulk of the client traffic to the primary site has been removed. The SUP role should be offloaded next as it's another point where clients can directly hit your primary site. To do this simply follow these steps:

  1. Install the latest version of WSUS on the MP/DP server (that already has IIS installed) and be sure to cancel the configuration wizard when it starts (CM will configure it instead). Also, be sure to select the option Use this server as the active software update point.

  2. From the admin console, navigate to Administration | Site Configuration | Servers and Site System Roles, select the MP/DP server, and add the software update point role. Verify that the setup encountered no errors by checking the SUPSetup.log, then look out for errors in the WSUSCtrl.log and wcm.log.

  3. With the new SUP working, that role can now be removed from the primary site. From the admin console, select the Primary server and remove the Software update role.

  4. Uninstall WSUS from the primary site server, but be sure to leave the WSUS admin console installed as its files are needed to manage the SUP.

Offloading Endpoint Protection

If you are using Endpoint Protection in your company, you can move this role next, but note that there will be no change to the server load. To do this simply follow these steps:

  1. Select the MP/DP/SUP server in the admin console and add the Endpoint Protection Point role.

  2. Verify that the setup encountered no errors by checking the EPSetup.log, then watch for errors in the EPCtlMgr.log. Often, this server will have to be rebooted before it can become functional and that will show in the EPSetup.log.

  3. From the admin console, select the primary server and remove the Endpoint Protection Point role.

Offloading SQL Reporting Services

The SQL Reporting Service Point can cause stress if people are repeatedly running reports that are hard for your primary to query. The smart move there is to simply set such reports to cache for a certain amount of time (an hour, a day, and so on) so that no matter how often the report is run, the cached data is used instead of fresh queries to the primary site's database. Additionally, reporting services for SQL 2008 and above no longer require IIS, so offloading the role doesn't help towards the ability to remove IIS. Should you still wish to offload that role anyway, (perhaps just as a rule you might decide that no other roles be allowed on a primary) select a server with SQL Reporting Services installed (IIS is not necessary). Follow these steps to offload the SQL Reporting Services Point role:

  1. In the admin console, navigate to Administration | Site Configuration | Servers and Site System Roles, and select the Create Site System Server from the Home tab in the ribbon. Enter the FQDN of the server and choose the CAS if you have one or the primary server.

  2. Select the Reporting services point as the role, verify the settings by clicking on the Verify button, and enter a domain account that you have granted the smsschm_users role in SSMS (generally, the same account used when SRS was created on the primary site).

  3. Complete the wizard and verify that the new site is working by running a report from the Monitoring | Reporting node in the console and choosing the new server (not the primary site).

  4. In the admin console, navigate to Administration | Site Configuration | Servers and Site System Roles, choose your primary site and remove the Reporting services point role.

  5. Log on to the primary site, click on the Start button, type SQL Server Installation Center (64-bit), and hit Enter. Run the installation wizard and remove the reporting services role by unchecking it thereby completing the wizard.

The remaining roles should cause no discernible stress to the primary. But there is one additional step you can take to reduce the impact of the MP role to your server and that is to create a transactional replica between the primary site and the MP. With such a replica, the MP can answer all client requests without querying the primary site. This also allows clients to remain functional if the primary site is down for maintenance or patching (assuming you've offloaded other roles needed, such as DP, SUP, and so on).

By creating this replica, there is a benefit in that if other roles are offloaded from the primary site, the primary site could go down for patching or maintenance while software distribution and patching could continue.

See also

 

Creating migration jobs


Migrating objects (packages, collections, task sequences, and so on) from CM07 to CM12 use a different process than we used from SMS 2003 to CM07. Due to the significant changes in the backend infrastructure, we can no longer attach and upgrade an existing CM07 site server to CM12. To make our side-by-side upgrade process easier, Microsoft created a new migration process that lets us select multiple CM07 sites (even from different CM07 hierarchies if desired) to migrate objects. Migration jobs allow us to pick and choose which objects to migrate.

Getting ready

Before we create a migration job, we must have a configured Active Source Hierarchy. To configure an Active Source Hierarchy, we need valid credentials to see the objects, just as we would for granting someone read rights to objects in CM07. All migration steps are performed in the admin console under Administration | Migration.

From the Active Source Hierarchy subnode, run the Specify Source Hierarchy Wizard and observe the progress in the progress dialog as well as the migmctrl.log file on the CM12 site server. All information related to migration is logged in this file.

Configuring the Active Source Hierarchy will automatically synchronize all computer objects from the source hierarchy (or hierarchies). This process also automatically discovers all child sites of the configured CM07 site. Note that we can only migrate owned objects from the specified source hierarchy. If we need to discover and migrate objects from child sites in the CM07 hierarchy, we must also configure those as source sites. Once we have configured our source hierarchy we can create multiple migration jobs.

How to do it...

To create a new migration job, perform the following steps:

  1. In the CM12 admin console, navigate to Administration | Migration | Migration Jobs and click on Start in the ribbon to start the New Migration Job wizard.

  2. Enter a unique job name, and select Object migration for the job type.

  3. Select the desired objects from the dialog:

  4. Select the CM12 site that will own the migrated content (this is usually your CAS or single primary site).

  5. Select the security scope to apply to the migrated objects. Create a new one if desired.

  6. On the Settings tab, specify when the job should run, as well as advanced settings such as overwrite previously migrated objects, and transfer organizational folders:

  7. After the job has been successfully created, we can monitor the Summary page for the job, as well as view the migrated object(s) state with the Objects tab. If required, view the migmctrl.log for additional troubleshooting information.

How it works...

The migration tool uses the credentials specified in the active source hierarchy configuration to migrate the desired object to the CM site. In this example, we selected specific objects to migrate. Notice that in the object selector dialog, we can identify which objects have already been migrated.

Note

CM users in the default roles of Full Administrator, Infrastructure Administrator, and Operations Administrator have security rights to create migration jobs.

There's more...

In addition to the object-based migration we just performed, we can also select a collection-based migration. When we specify a collection-based migration, selected collections and all objects required for those collections are migrated by default. We can clear a checkbox in the wizard so that only the collections are migrated, if desired. When we select a subcollection for migration, all the collections that are required to traverse to the root are also migrated.

Also, notice from the previous image that we can determine which collections have been migrated, which collections are device collections, and which collections are user collections. In CM12, a collection cannot contain both devices and users. Click on the View Collections that Cannot Migrate… button to view collections that meet one or more of the following criteria:

  • Mixed Query Collection is a collection that contains a mix of users and devices, or custom collection types.

  • Mixed Collection Hierarchy is a collection that has a parent collection of a different type

  • Multiple Collection Limiting is a collection that is limited to multiple collections using custom WQL

  • Collections that are a collection limited to any collection that meets the above criteria cannot be migrated

Also, notice from the previous image that some collections will be migrated to a folder instead of a collection. CM12 does not support nested collections. The migration process will ensure that collections are migrated and organized similarly to the CM07 configuration, but will not be exact. Always run the migration process in a test environment before running migration jobs in production.

Note

It's important to know that for each new package we create (software package, update package, image package, and so on), the source will automatically be inserted into the CM content library (by default, C:\SCCMContentLib) as soon as the package is created. If you run migration jobs in your test environment, ensure that you have a disk large enough to contain all files from your selected package sources. CM12 leverages a single instance source for all files which will help, but when you migrate a large number of packages, you may completely consume the hard drive(s) of your test environment simply by running the migration tool.

After we have performed object collection-based migration, we still need to migrate the actual clients in the migrated collection. We can leverage any type of client installation to meet our requirements.

Using multiple sites

As you will almost certainly be flattening your CM07 hierarchy to CM12, keep in mind that you can migrate objects and collections from multiple primary sites to a new single primary site (or central administration site) as part of your consolidation efforts, and simply assign the proper security scope to the objects.

Re-migrating objects

We can use the migration tool to re-migrate objects that were previously migrated. This is important if an object has changed in CM07,for example, package source, command-line switches, or even package source version.

DP sharing

We can configure distribution point sharing to allow CM12 clients to access CM07 distribution points to obtain content of migrated packages during our infrastructure transition to CM12. Once our migration is complete, we can use the migration tool to migrate distribution point shares (that have no other CM07 role on them) to CM12, without the need to re-send existing content to the newly-reconfigured CM12 distribution point.

See also

 

Installing SQL the right way


How well SQL is installed before CM can have a dramatic effect on how people perceive CM to be as a product. Common complaints heard are "CM is slow", "The console is slow", and "It can't keep up with this many clients." A well thought out installation will go unnoticed where the reverse can cause downright agony for admins.

Getting ready

Get the latest supported version of SQL, the latest supported service pack, and the latest version of the cumulative update files. An already slipstreamed set of files from Microsoft will make things easier if available. The enterprise version has many benefits like online reindexing of tables, support for more than 50,000 clients, and more, but the decision of which edition to use usually comes down to cost, as the enterprise edition is far more expensive than the standard version.

The more memory SQL has access to, the better it will run. The more disks and controllers it can use, the better it will run. SQL doesn't perform well in a virtual machine on virtual disks. This can be done in a lab or even on a laptop as a lab, but for production, memory and disks will define the CM experience.

How to do it...

Consider the following disk layout optimized for an enterprise class primary site or CAS:

Disk

Controller

Number of Drives

Drive letter

Partitions

0

0

4

C

OS

1

1

4

T

TempDB

2

1

4

X

TxLogs

3

1

6

R

SQLDB1

4

2

6

S

SQLDB2

5

2

8

D

Data\Backup

External controllers 1 and 2 get as much RAM as you can afford (1 GB optimally). Each gets one hot spare drive. All controllers are formatted with RAID 10. SQL activity is split across 2 controllers. RAID cache settings should be set to Write Back, no Read Ahead.

From the previous table, you can peel away as costs constrain your budget in the following order:

  1. The OS could be on a simple mirror.

  2. The TempDB and TxLogs could be on a single drive.

  3. The SQL files could be on the same drive.

  4. The SQL files could be mixed with the TempDB.

  5. The SQL files, Data\Backup, and TempDB could be on the same drive.

  6. Move the TxLogs to the C: and all other data on the second drive.

  7. Everything sits on one drive (small lab scenario).

How it works...

With the best layout of disks you can afford and the most memory you can afford, SQL will be able to stand the stress CM puts on it. If using SAN, multiple dedicated LUNs are best, if available. Notice the TxLogs were the last to be compromised as nothing can be committed to SQL until first written to the TxLogs. Even with plenty of RAM, data must still be written to disk, which makes the TxLogs an important point in any design.

There's more...

Drive layout is the key to smooth SQL operations. But that's just the start. A few more easy steps will keep your installation bug free and optimized for CM use.

Installing SQL with an unattend file

After the preparation of the drives, SQL can be installed using an unattend file, which has the additional benefit of being reused for a reinstall, or being used on similar primary sites. An example of an unattend file is included in this chapter. It includes two sections of note:

PCUSOURCE=\\Server\Share\SQLServicePackX
CUSOURCE=\\Server\Share\SQLCUX

The location of any service pack not already slipstreamed should be used for the PCUSOURCE and the location of the latest cumulative update should be used for the CUSOURCE. If either have already been slipstreamed into the setup files, simply comment them out.

To callout the unattend file, simply use a command line similar to the following:

Setup.exe /CONFIGURATIONFILE=cmsqlconfig.ini

Edit the unattend file as needed to match your drive layout. It is currently set to use R, S, T, and X drives so read carefully. The file works only for SQL 2008 R2, but SQL 2008 and SQL 2012 are similar enough that some simple editing can make them work. The key here is that you can read the file to see how to properly layout the files and options in advance.

SQL 2012 replaces PCUSOURCE and CUSOURCE with what it calls Product Updates. Differences are detailed at http://www.mnscug.org/blogs/brian-mason/176-installing-sql-2012-with-a-configuration-file.

Setting some limits

SQL will be happy to eat all the memory on a server leaving nothing for the OS, base applications, or CM. So you need to limit it. Simply open SQL Server Management Studio (SMSS) and right-click on your server to view properties, and navigate to Memory. Because CM12 is all x64, leave AWE alone. But you do want to enter a maximum server memory here. Leave the OS with 2 GB, (your base apps could vary, but 1-2 GB should suffice,) and leave CM with 4 GB. Add all that and subtract it from the server's total memory and enter that number here. Note that a CAS requires 8 GB minimum to be dedicated to SQL (anyone choosing to use a CAS is likely to use 16 GB or more anyway).

Transaction logs have been known to grow to consume the entire drive and when that happens, everything stops as nothing can be committed to SQL until first written to the transaction log. A fair limit would be 15 percent less than the entire free space of the drive. See step 5 in SQL file layout for where to do this.

SQL file layout

With SQL installed, it now has to be configured to make the best use of the processors on the server. Use more than one file for the SQL database. The rule of thumb is to use as many files as there are physical processing cores.

  1. From the Microsoft SQL Server Management Studio (SMSS), right-click on your CM database and choose Properties. Go to Files and then click on the Add button.

  2. If you had eight cores and two drives for the SQL database (R and S), you would add four files to R and three more to S (assuming you initially installed SQL to S).

  3. Set the initial size of each file to one-eighth the size of what you expect your entire database size to be.

  4. Set the Autogrowth to 1000 MB.

  5. Set the Autogrowth of the transaction log to 1000 MB. Additionally, restrict the growth of the file to a size that is smaller than the free space on the drive on which it resides.

  6. Click on OK to commit the changes; no need for reboot.

Helping SQL

CM has a maintenance task to rebuild indexes, which is disabled by default. Over time, SQL will slow down as the indexes grow stale.

  1. From the CM admin console, navigate to Administration | Site Configuration | Sites and click on Site Maintenance in the ribbon.

  2. Change the properties of the Rebuild Indexes task to be enabled to Weekly.

  3. Choose a time of day where CM isn't busy. The default of 1 a.m. on Sunday is probably a good choice.

  4. Repeat for all primary sites (and the CAS if you have one).

Additionally, if you have no need to keep data around for 3 months, then help keep the database size smaller by shortening the clean-up tasks from 90 days to something you can live with (perhaps 21 days or 30 days).

Lastly, verify that the recovery model for the CM database is from Full to Simple. Because CM runs backup itself, only its point in time backup can be used to recover the database so you will never recover to some point in time with a full backup. This also keeps the transaction log from having to be backed up. This setting can be found in SMSS by right-clicking on the database, navigating to Options, and selecting the Simple for the Recovery model.

See also

 

Managing Internet-facing clients


Depending on the environment, you may have clients that:

  • Regularly move between the Internet and the intranet

  • Are home computers, and never connect to the intranet

Managing clients that are not always connected to the internal network can be a challenge. If remote computers use Virtual Private Networking (VPN) to connect to the corporate network on a regular basis, Internet-facing support may not be required. But if we know that clients may use some type of remote desktop to connect to the corporate network, or maybe they don't have to connect to the corporate network at all to do their job, then Internet-facing support should be considered to ensure proper patch and asset management.

If "Native Mode for CM07" rings a bell, we have good news for you. CM12 does not have a "Mixed Mode" and "Native Mode". It simply has two client communication methods: "HTTPS" only and "HTTPS or HTTP". One CM12 site can support both HTTPS and HTTP communication if required.

Getting ready

Public Key Infrastructure (PKI) certificates are required for Internet-based client communication. Engage with the team that owns PKI in your infrastructure. If a PKI infrastructure doesn't currently exist, follow Microsoft's step-by-step example of deploying PKI http://technet.microsoft.com/en-us/library/gg682023.aspx. Once you have all valid certificates, proceed to the next section.

How to do it...

To enable Internet-facing clients, perform the following steps:

  1. In the CM12 admin console, navigate to Administration | Site Configuration | Sites, and select the desired site to support Internet-based clients. Right-click on the site and select Properties.

  2. From the Client Computer Communication tab, select either HTTPS only if you only want to support HTTPS, or HTTPS or HTTP as required.

  3. Enable the checkbox to Use PKI client certificate, and then click on the Modify button to select the client certification selection criteria, as well as the store name, and then click on OK.

  4. Click on the Set button to specify the Trusted Root Certification Authorities, and then select the starburst to browse to a new certificate file.

  5. Select OK to save changes to Site Properties.

  6. From the Servers and Site System Roles node, select the desired site in the top pane. Select the desired roles from the bottom pane (Management Point, Distribution Point, Software Update Point, as well as Application catalog Point, if required).

  7. Specify HTTPS for client communications types.

  8. As long as the new site systems are accessible from the Internet at this point, the infrastructure configuration is complete. Follow the client installation instructions at http://technet.microsoft.com/en-us/library/gg699356.aspx to install the CM client properly.

How it works...

Unlike CM07, CM12 allows clients assigned to the same primary site to use either HTTP or HTTPS communications. If a client has the PKI cert, it can be set to use HTTP for the intranet and HTTPS for the Internet.

See also

 

Using remote and workstation distribution points, and BranchCache


When CM administrators ask us "What are the most resource-intensive components of CM?", we usually start with the obligatory "It depends", and then quickly follow-up with distribution points. Distribution points are the file shares and websites that clients use for installing software, security patches, operating system deployments, and more. So depending on the content we plan to deploy, we may need more distribution points than any other server.

CM07 uses Distribution Points, Distribution Point Shares, and Branch Distribution Points, each of which work in slightly different ways. CM12 takes the good old distribution point to a new level, supporting a single instance store, adding consistency checks with the distribution point role, and adding a sender for throttling. Troubleshooting and deploying a distribution point to a workstation is very similar to troubleshooting and deploying a distribution point to a server.

In addition to standardized distribution points, CM12 also has integrated BranchCache, which allows us to reduce the amount of traffic that occurs between each network client and the distribution point for downloading content. For example, when a supported system needs to download content, it will first check to see if any system on its local network already has the content (based on file hash), and if so, it will download from a peer. If not, it will download from the distribution point, and then store the content so that it can be shared among other peers on the same network in the future.

Getting ready

We described the process of installing a distribution point in the recipe, Dividing up site system roles, so we will use this section to help you determine how to choose which type of distribution point(s) you need.

How to do it...

To determine the best distribution point for your needs, ask the following questions:

  • How many clients will use the distribution point?

  • Will Preboot Execution Environment (PXE), also known as network-based boot, be required?

  • Must the distribution point support BranchCache?

  • Is the distribution point connected to the site server over a slow or fast network link?

  • Do you plan to use any third-party add-on tools or WAN accelerators for remote locations?

  • Do you require redundancy, in the event that a distribution point is offline or a DP fails?

Review the following table to help determine the proper DPs for your environment:

CM Feature

Workstation DP

Server DP

Supports PXE

No

Yes

Supports multicast

No

Yes

Supports BranchCache

No

Yes

Maximum concurrent connections

20

Unlimited

Supports bandwidth throttling

Yes

Yes

Supports single instance store

Yes

Yes

Supports content validation

Yes

Yes

Supports boundary groups

Yes

Yes

Supports additional site roles (MP, Web Svc Pt, and so on )

No

Yes

How it works…

You cannot distribute software or software updates to clients without DPs. The decision on how many to place, where to place them, whether or not to throttle them and if so, how much, are all considerations that affect the ability of clients to get software in an efficient manner. Don't just throttle a DP because you can now. Do so only because you need to alleviate a possible network bottleneck.

There's more...

As we can see from the previous table, bandwidth throttling is available on DPs either on a workstation or a server. This new feature alone may allow you to reduce the need for secondary sites in remote locations. Review the following sections for more discussion about maximizing content efficiency with CM12.

When to choose BranchCache

BranchCache is practically free, so be sure to spend some time evaluating it for your needs. If your environment meets the requirements for BranchCache, you should consider enabling it at least at remote sites to reduce bandwidth utilization, possibly reducing the need for CM infrastructure in those remote locations.

BranchCache is supported on the following operating systems:

  • Windows 7 Enterprise and Ultimate Editions (or newer)

  • Windows Server 2008 R2 (or newer)

  • Windows Vista Enterprise with at least service pack 2 and BITS 4.0

  • Windows Server 2008 with at least service pack 2 and BITS 4.0

The configuration for the server component of BranchCache is only supported on Server 2008 R2 (and newer Server OS). CM DPs must reside on a server with the BranchCache feature enabled for clients to leverage BranchCache. Also, CM requires BranchCache to be configured in distributed mode.

Some WAN accelerator configurations may interfere with BranchCache, so be sure to review BranchCache documentation as well as test in your environment. Follow the instructions referenced in the See also section of this recipe for configuring BranchCache. After configuring the CM DPs, we can use GPO to configure BranchCache on client systems.

When to choose a workstation distribution point

Workstation DPs can be a great addition to your CM hierarchy, and significantly reduce the need for server-class hardware in smaller locations. The following table briefly describes the limitations to a workstation DP:

CM Feature

Limitations

Supports PXE

Workstation operating system does not support this WDS server feature

Supports multicast

Workstation operating system does not support this WDS server feature

Supports BranchCache

Workstation operating system does not support the server feature required for BranchCache configuration on a DP.

Max concurrent connections

Windows 7 has a maximum of 20 concurrent connections. Windows XP has a maximum of 10 concurrent connections. This may put larger locations of clients into a "waiting for content" situation, until enough connections become available.

Supports additional site roles (MP, Web Svc Pt, and so on)

Workstation operating system does not support additional roles for a CM site.

Operating System Deployment (OSD) is probably the most affected as far as limitations on a workstation operating system go, as PXE and multicast are not supported. We can still use bare-metal builds, as well as OS deployment from Software Center, and successfully build systems.

When to choose a server-class distribution point

For a full-featured DP, choose to install the DP on a server operating system. All features described previously in this chapter are fully supported. As mentioned previously, we may find that we can simply install a DP at a remote location, instead of a full secondary site (as we did in CM07 to handle bandwidth throttling).

See also

About the Authors

  • Brian Mason

    Brian Mason is a Systems Engineer at Wells Fargo where he manages over 350,000 resources with CM (note that any views expressed in this book are Brian's and not necessarily those of Wells Fargo). Brian is a 6-time Microsoft MVP for Configuration Manager (CM). He currently runs the Minnesota System Center User Group and its website where he blogs. He can be found answering forum questions on TechNet and myITforum.

    Browse publications by this author
  • Greg Ramsey

    Greg Ramsey is a Systems Engineer specializing in global systems management for Dell Services. He has a B.S. in Computer Sciences and Engineering from the Ohio State University and is a Microsoft Most Valuable Professional (MVP) for Microsoft System Center Configuration Manager. Greg co-authored SMS 2003 Recipes: A Problem Solution Approach (Apress, 2006) and Microsoft System Center Configuration Manager Unleashed (Sams, 2009). Greg is the co-founder of the Ohio SMS Users Group and the Central Texas Systems Management User Group.

    Browse publications by this author
Book Title
Unlock this book and the full library for FREE
Start free trial