Session 7: Configuration Manager Mark 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 Uncoordinated, manual infrastructure; knowledge not captured Managed IT infrastructure with limited automation and knowledge capture Managed and consolidated IT infrastructure with extensive automation; knowledge captured and reused Identity and Access Management Desktop, Device, and Server Management Desktop Management Security and Networking Virtualization IT and Security Process Fully automated management; dynamic resource usage; businesslinked service level agreements; knowledge capture and use automated Cost Center Server Management Data More Protection Efficient and Business Recovery Cost Center Enabler Mobile Device Management Strategic Asset Basic Standardized Rationalized Dynamic
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
MCS Talks Infrastructure Architecture 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 3 rd 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
MCS Talks Infrastructure Architecture CORE CONCEPTS
Configuration Manager Sites BITS Enabled DP Client Client Site Server & Site DB Management Point (MP) Client Contents of a site 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
Hierarchies of Sites Central Site Primary Site Secondary Site
The Primary Site Supported Roles 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 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 Supported Roles 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 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 Standard DP (Server/Server Share) Standard or Branch DP (Protected) Branch DP (Client) Standard DP (BITS) Standard DP (up to 4000 clients) Branch DP (Server) 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 Standard DP (Server/Server Share) Standard or Branch DP (Protected) Branch DP (Client) Standard DP (BITS) BITS Enabled Standard DP Branch DP (Server) 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 Standard DP (Server/Server Share) Standard or Branch DP (Protected) Branch DP (Client) Standard DP (BITS) Branch DP (Server) 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 Standard DP (Server/Server Share) Standard or Branch DP (Protected) Branch DP (Client) Standard DP (BITS) Branch DP (Server) 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
MCS Talks Infrastructure Architecture 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
MCS Talks Infrastructure Architecture DESIGNING SITE HIERARCHIES 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 3 rd 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
MCS Talks Infrastructure Architecture DESIGNING SITE HIERARCHIES 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? Tier 1 Central Site Primary Site Secondary Site DP or Branch DP
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 1 2 Primary Client 4 3 5 Secondary 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
Site Design: Site Traffic and Branch DPs 1 2 4 Primary Client 5 3 Client Branch DP (Server) 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
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? 3 rd Party tools
Tier 3 Site Design: Design Options Tier 3 should ideally be: Secondary Sites Branch DPs Tier 1 Central Site Tier 2 Primary Site Tier 2 Secondary Site DP or Branch DP Secondary Site Branch DP Branch DP
MCS Talks Infrastructure Architecture 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!
MCS Talks Infrastructure Architecture HIERARCHY CONSIDERATIONS 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
MCS Talks Infrastructure Architecture HIERARCHY CONSIDERATIONS FOR SUP
Key Traffic Considerations SUP Scanning Microsoft Update 1 Update catalogue downloaded from Microsoft Update 2 7 Compliance reports Site Server show aggregated Available 6 Compliance software reported to results for all updates Site registered Server in updates Configuration Manager Status Reports Software Update Point & WSUS Server Management Point 53 Client gets scans scan against policy all via updates Management and reports Point compliance to MP Distribution Point 4 Client retrieves update catalogue from SUP initiated by client policy Client
Key Traffic Considerations SUP Downloads Microsoft Update 2 Content Deployment downloaded state from 7 messages Microsoft delivered Update to site server Site Server 18 Admin Deployment approves reports updates show aggregated in console results Status Reports Software Update Point & WSUS Server 4 Update policy received from MP Management Point 6 Deployment state reported 3 New content staged on DP s and replicated through hierarchy 5 Distribution Point Required content downloaded from DP Client
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)
MCS Talks Infrastructure Architecture 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 Site Server 1 Client 3 2 Site Server Site System 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]
Site Modes: Native Site Server 1 Client 3 2 Site Server Site System 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]
Site Modes: Native + IPSec Site Server 1 Client 3 2 Site Server Site System 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]
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
MCS Talks Infrastructure Architecture 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.
MCS Talks Infrastructure Architecture 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!