session 7: configuration managerdownload.microsoft.com/documents/uk/technet/post... · ad schema...

Session 7: Configuration ManagerMark Aslett – Consultant

Adam Shepherd – Consultant

MCS Talks Infrastructure Architecture

Agenda

Introduction

Gathering requirements

Core Concepts

Hierarchy Design

Scaling up and out

Introduction

This series is a high level series

We’re aiming to share our recommendations

We’re getting feedback that people would like more depth:

Planning for mini series next year to cover topics in more details

Let us know what you’d like to see!!

Introduction - Infrastructure Optimisation

Standardized DynamicRationalizedBasic

More Efficient

Cost Center

Strategic AssetBusiness

Enabler

Cost Center

Managed IT

infrastructure

with limited

automation and

knowledge

capture

Fully automated

management;

dynamic resource

usage; business-

linked service

level agreements;

knowledge

capture and use

automated

Managed and

consolidated IT

infrastructure

with extensive

automation;

knowledge

captured and

reused

Uncoordinated,

manual

infrastructure;

knowledge not

captured

Identity and Access Management

IT and Security Process

Desktop, Device, and Server Management

Security and Networking

Data Protection and Recovery

Desktop Management

Virtualization

Server Management

Mobile Device Management

Configuration Manager Frequently Used

Features

Hardware and Software Inventory

General reporting

Audit for planning deployments

Application Distribution and Installation

Standardised packages created centrally and replicated out

Targeted deployments

Operating System Deployment

Development and production

Software Updates

Deployment and compliance reporting

Configuration Manager, lesser discussed

features

Workstation Remote Control

Integration with Windows Remote Assistance

Software Metering

Generation of usage metrics

Network Access Protection

Integration with System Health Validator

Recommended Patching Solution

Desired Configuration Management

App-V application deployment

Client Status Reporting

GATHERING REQUIRED

INFORMATION


Business Drivers

Make sure you have business level support for the project

Some common reasons:

Upgrade a desktop estate

To support new features (App-V, NAP etc)

Migration from a legacy version of the software

Migration from a 3rd party tool

Gathering information

Understand which features you need to support:

ESD, Inventory, Metering, OSD, NAP, App-V, Patching

Client and/or Server based management

Environment details:

Physical Topology – locations, client numbers, link speeds, workgroup computers, non-Windows computers, home based users

Active Directory Topology – forests, domains, AD Sites

Planned Changes – open / closure of sites, other infrastructure refresh projects

Existing management and patching infrastructure

CORE CONCEPTS


Configuration Manager Sites

Client

Management

Point (MP)

Site Server & Site DB

Client

BITS Enabled DP

1 1 or more boundaries (AD Site, IP Subnet, IP range, IPv6 prefix)

2 A site server and 0 or more site systems

3 Configuration Manager Clients assigned to that site

Contents of a site

Client

Hierarchies of Sites

Primary Site Secondary Site

Central Site

The Primary Site

Key Points

Boundaries of Administrative Control (non autonomous)

Has a site database

Has clients assigned

Supports up to 100,000 clients

Requires a ConfigMgr license

Requires a SQL Server license

Can have parent and child sites

Supported Roles

Site Server

Site Database

Management Point (MP)

Distribution Point (DP)

Branch Distribution Point (BDP)

Software Update Point (SUP)

Fallback Status Point (FSP)

PXE Service Point (PSP)

State Migration Point (SMP)

System Health Validator (SHV)

Server Locator Point (SLP)

Device Management Point (DMP)

Reporting Point (RP)

Asset Intelligence Synch Point

The Secondary Site

Key Points

No database

No ConfigMgr license, or SQL license required.

No directly assigned clients

Recommended max of 5000 clients

No administrative control

No Child Sites

Used to ease traffic to Primary

Supported Roles

Site Server

Proxy Management Point (PMP)

Distribution Point (DP)

Branch Distribution Point (BDP)

Software Update Point (SUP)

Fallback Status Point (FSP)

PXE Service Point (PSP)

State Migration Point (SMP)

Device Management Point (DMP)

Reporting Point (RP)

Asset Intelligence Synch Point

Understanding DPs

Branch DP (Client)

Branch DP (Server)

Standard DP

(Server/Server Share)

Standard DP (BITS)

Standard or Branch DP

(Protected)

Standard DP (up to 4000 clients)

Standard Server DP (also supports Mobile Devices)

When a package is copied to a Server DP it is copied to the NTFS volume with the most space

Standard Server Share DP (also supports mobile devices)

Server shares used to control drive usage, requires admin manually creating share first

ConfigMgr doesn’t create a DDR to monitor the health of the system

Server shares more likely to fail due to lack of space

Server shares not supported for IBCM

Uses SMB to download content to clients

Understanding DPs

Branch DP (Client)

Branch DP (Server)

Standard DP


Standard DP (BITS)


(Protected)

BITS Enabled Standard DP

Requires IIS and WebDAV (WebDAV not included in Server 2008)

Uses BITS to transfer content from distribution point to ConfigMgr client.

Provides throttling and checkpoint restarting

Can resume from same or different BITS enabled DP, but resumes beginning of a file

A BITS enabled DP is required for Branch DPs, IBCM and mobile device management

NB. BITS is not used for ‘Run from Distribution Point’ option of an advertisement

NB. BITS 2.5 or above required for Native Mode (hence why Windows 2000 clients not supported)

Understanding DPs

Branch DP (Client)

Branch DP (Server)

Standard DP


Standard DP (BITS)


(Protected)

Branch DPs (up to 100 clients)

Allows a server or a workstation (10 concurrent users) to be used as a DP

Requires a BITS enabled DP to deliver it content (provides throttling/scheduling)

Package distribution to the Branch DP can be done by:

1. Using standard distribution

2. On Demand (configured at the package level) and ONLY for protected Branch DPs

Packages can be pre-staged (similar to a courier send)

Can support App-V streaming over SMB

Not supported on Windows 2000 machines

Understanding DPs

Branch DP (Client)

Branch DP (Server)

Standard DP


Standard DP (BITS)


(Protected)

Protected DPs

Clients outside of a protected boundary cannot access content on the DP

Applies to the entire site system but only effects the DP and SMP

Used to protect DPs on the end of a slow/unreliable network link

Can apply to Standard and Branch DPs

DESIGNING SITE HIERARCHIES


Some Pre Design Considerations....

AD Schema Extensions Recommended as a best practise (more considerations later)

Understand how your network infrastructure is modelled:

AD Sites, Subnets etc

Do AD Sites need remediation work

Plan for replication

Binary Differential Replication can help

Native Mode, more secure but needs a PKI infrastructure

For management of Internet based clients

Plan to engage with other teams, IIS, SQL

Single vs. Multiple Hierarchies

In most environments a single hierarchy will be sufficient

Multiple Hierarchies can give you:

Complete isolation between two separate countries or business units

However, multiple hierarchies are also

More expensive

No centralised reporting


TIER 1 DESIGN


Tier 1 Site Design: Central Site

Central Site – top level primary

Design Considerations:

Function – Administration vs Reporting

How large is the environment?

Will central site be used to aggregate data and feed that to a 3rd party system?

What Configuration Manager roles should be hosted at the central?

NB: Packages should be imported at this level to allow reporting on them

Should database be hosted on the site server or remote SQL cluster

Scalability – Single vs Multiple servers


TIER 2 SITE DESIGN


Tier 2 Site Design: Design Options

Design Options depends on Tier 1:

Is central server dedicated for reporting?

Is central server manages clients?

DP or Branch DP

Tier 1 Central Site

Primary Site Secondary Site

Tier 2 Site Design: Primary

Single Primary Site where possible

Consider using a Primary:

A level of autonomous control

Support for different security modes

Different client agent settings (rare)

Support for a site with more than 5000 assigned clients (due to limits of secondary sites)

Sites with more than 500 secondaries

Sites with more than 100,000 assigned clients

Tier 2 Site Design: Primary

Architectural Considerations:

Primaries can sit in different AD forests

Requires SQL database

Requires SQL Server and Configuration Manger license

Will need to put a backup solution in place per primary

Note, backing up the database alone is not enough to restore a site

Consider splitting out site system roles:

Distribution Points

Software Update Points

Management Points

Tier 2 Site Design: Secondary

Consider using a secondary:

To ease load on site systems

To give better control of network traffic and utilisation

Need to support some OS deployment scenarios locally on site

Architectural Considerations

Cannot be moved to a different Primary

Proxy Management Point

Software Update points (more on this later)

Single vs. Multiple physical servers

Site Design: Site Traffic and Secondaries

Client

Secondary

Primary

1 Client to Site Server comms generates traffic (policies, inventory, discovery, status)

2 Client to Site Server traffic is uncompressed over WAN

3 Add Secondary Site on LAN of the Client

4 Client to Site Server traffic is still uncompressed, but kept on local LAN

5 Traffic is passed up hierarchy, but compressed, throttled and scheduled

1

2

34

5

Site Design: Site Traffic and Branch DPs

Client

Primary

1 Client receives advert, requests content from MP

2 No local infrastructure so each client downloads content across WAN using BITS

3 Add Branch DP local to Client

4 Branch DP downloads content via BITS once to local site

5 Clients download from local DP using SMB

12

35

4

Branch DP (Server)

Client

Tier 2 Site Design: Branch DPs

Consider a Branch DP:

For remote sites where no dedicated hardware can be added

For sites where a site is being considered just to support software distribution


Can be Desktop or Server based

If on a desktop, how do you manage it as a business

Performance hit on Branch DP machine

Capacity planning

Manage as an Internet Client?

3rd Party tools

Tier 3 Site Design: Design Options

Tier 3 should ideally be:

Secondary Sites

Branch DPs

DP or Branch DP

Tier 1 Central Site

Tier 2 Primary Site

Secondary Site

Tier 2 Secondary Site

Branch DP

Branch DP

HIERARCHY CONSIDERATIONS

FOR APP-V


Key Design Decisions for App-V

Two key delivery methods:

Streaming

Download and Execute

Both DPs and Branch DPs can support App-V streaming

Streaming should only be used on well connected LAN environments

...join us for Session 10 when we talk App-V design in more detail!


FOR OSD


Key Design Decisions for OSD

Two key components:

PXE Service Points

State Migration Points

Key design decisions:

How widely do you want to support PXE operated OSD

Will you be migrating user state


FOR SUP


Key Traffic Considerations – SUP

Scanning

Microsoft Update Site Server

Distribution Point

Client

Management PointSoftware Update Point

& WSUS Server

Status Reports

1 Update catalogue

downloaded from

Microsoft Update

Available software

updates registered in

Configuration Manager

2

Client gets scan policy

via Management Point

3

Client retrieves update

catalogue from SUP

initiated by client policy

4

Client scans against all

updates and reports

compliance to MP

5

Compliance reported to

Site Server

6

Compliance reports

show aggregated

results for all

updates

7

Key Traffic Considerations – SUP

Downloads

Microsoft Update Site Server

Distribution Point

Client

Management PointSoftware Update Point

& WSUS Server

Status Reports

4

Update policy

received from MP

Admin approves

updates in console

1

Content

downloaded from

Microsoft Update

2

New content staged

on DP’s and

replicated through

hierarchy

3

Required content

downloaded from DP

5

Deployment state

reported

6

Deployment state

messages delivered to

site server

7

Deployment reports

show aggregated

results

8

Software Update Management


Typically implement at Top Level at Central Site (internet connectivity or export / import)

Software Update Point deployed at each Primary Sites (Clients access SUP within assigned site via machine policy)

Single SUP supports up to 25,000 clients

Extend support using NLB

SUP can be optionally deployed at Secondary Sites

Cannot use WSUS GPO’s

Implementation of Forefront Client Security brings challenges! (and a 10,000 client support limit per site)

CONFIGURATION MANAGER

SITE MODES


Site Design: Site Modes

Two main modes:

Native Mode

Mixed Mode

Microsoft official guidance is to use Native mode where possible

Native mode is much more secure as an enterprise solution and brings additional capabilities

Site Modes: Mixed

Client

Site Server

1 Site to Site communications are signed, but not encrypted

2 Site Server to Site System communications are not encrypted

3 Client to Site System (MP/DP/SUP/SMP) is over HTTP

[SUP can potentially be over HTTPS]

1

23

Site System

Site Server

Site Modes: Native

Client

Site Server

1 Site to Site communications are signed, and encrypted

2 Site Server to Site System communications are not encrypted

3 Client to Site System (MP/DP/SUP/SMP) is over HTTPS

[FSP/SLP is still over HTTP]

1

23

Site System

Site Server

Site Modes: Native + IPSec

Client

Site Server

1 Site to Site communications are signed, and encrypted

2 Site Server to Site System communications are encrypted with IPSec

3 Client to Site System (MP/DP/SUP/SMP) is over HTTPS

[FSP/SLP is still over HTTP]

1

23

Site System

Site Server

Site Hierarchy: Site Modes


Mixed Mode

Required to support SMS 2003 clients or Windows 2000 clients

Native Mode

Requires PKI in place

Required for IBCM

Requires Parent Site in Native Mode

Additional failure points

Native Mode + IPSec

Most expensive to implement

Hierarchy:

Can have mixture Native Mode with IPSec

Secondaries automatically take security mode of parent

CONSIDERATIONS FOR

INTERNET BASED CLIENTS


Site Hierarchy IBCM Design Considerations

Features Not Supported

Software Distribution to Users

App-V streaming

Branch DPs

Client Deployment

Auto-site assignment

NAP

Wake-on-LAN

OSD

Remote Tools

Clients can roam between Internet and Intranet

Site Hierarchy IBCM Design Scenarios

Scenario 1: Dedicated Site for Internet Based Clients

Site systems (MP, SUP, DP, FSP) sit in perimeter network

Site Server / Site Database options:

Site Server / Database in DMZ

Site Server / Database in Intranet - can talk to SQL Server directly or host a replica in DMZ

Scenario 2: Same Site manages Internet and Intranet Based Clients

Single site with different site systems for Internet or Intranet focussed clients.

Single site with site systems that have two NICs and span intranet and perimeter networks.

SCALABILITY AND

AVAILABILITY


Site Hierarchy: Supportability Limits

Clients:

200,000 Clients per Hierarchy

100,000 Clients per Primary

5000 Clients per Secondary

25,000 Clients per MP

25,000 Clients per SUP

4000 Clients per DP

100 Clients per Branch DP

100,000 Clients per SHV

100,000 Clients per FSP

Servers:

500 Secondaries per Primary

2000 Branch DPs per site

Site Design: Resilience and Scalability

Key Considerations

SQL Server Clustered and/or Remote

Must be an Active/Passive cluster

Only consider remote if have GB connectivity

Management Points, Software Update Points and Server Locator Points:

Over 25,000 clients use NLB (max 4)

Over 25,000 clients consider a SQL Transactional Replica

NB. Remember Forefront / Configuration Manager supportability limitations!

Distribution Points can’t be load balanced but can add more DPs to manage load

Summary

We’ve covered some of the key design principles for Configuration Manger design

Planning and information gathering can be key to a successful design

Keep hierarchies as flat and as simple as possible to avoid cost and complexity

Thank you for attending this TechNet Event

Visit our blog at:

http://blogs.technet.com/mcstalks

Register for the next session, Operations Manager, at:

http://msevents.microsoft.com/CUI/WebCastEventDetails.as

px?EventID=1032393349&EventCategory=4&culture=en-

GB&CountryCode=GB

Please fill out your evaluations!

http://blogs.technet.com/mcstalks

http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032393349&EventCategory=4&culture=en-GB&CountryCode=GB




session 7: configuration managerdownload.microsoft.com/documents/uk/technet/post... · ad schema...

Documents