Session 7: Configuration Manager - Microsoft Home Page | Devices
Transcript of Session 7: Configuration Manager - Microsoft Home Page | Devices
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
MCS Talks Infrastructure Architecture
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
MCS Talks Infrastructure Architecture
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
(Server/Server Share)
Standard DP (BITS)
Standard or Branch DP
(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
(Server/Server Share)
Standard DP (BITS)
Standard or Branch DP
(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
(Server/Server Share)
Standard DP (BITS)
Standard or Branch DP
(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
MCS Talks Infrastructure Architecture
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
DESIGNING SITE HIERARCHIES
TIER 1 DESIGN
MCS Talks Infrastructure Architecture
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
DESIGNING SITE HIERARCHIES
TIER 2 SITE DESIGN
MCS Talks Infrastructure Architecture
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
Architectural Considerations:
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
MCS Talks Infrastructure Architecture
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!
HIERARCHY CONSIDERATIONS
FOR OSD
MCS Talks Infrastructure Architecture
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
HIERARCHY CONSIDERATIONS
FOR SUP
MCS Talks Infrastructure Architecture
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
Architectural Considerations:
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
MCS Talks Infrastructure Architecture
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
Architectural Considerations:
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
MCS Talks Infrastructure Architecture
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
MCS Talks Infrastructure Architecture
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!