Architecture Configuration Manager Current Branch


  • Share on Pinterest

Voici un guide ou plutôt un aide mémoire pour la réalisation de l’architecture et le déploiement de System Center Configuration Manager 2012 R2 pour des environnements complexes avec un accent sur la haute disponibilité et l’optimisation des performances. Ceci comprend donc l’optimisation SQL que vous soyez déjà en production ou pas, configuration des rôles dépendamment de la quantité d’utilisateurs à gérer, la gestion de contenu avancée, et les environnements avec plusieurs domaines. Tout reste basé sur les bonnes pratiques et les expériences à date.

Considérations SQL Server

[eckosc_accordion title= »Design et Installation » state= »closed »]

  • Il est préférable d’installer SQL sur le serveur de site primaire, à moins d’être dans une grande entreprise (raisons politiques).
  • SQL en local signifie aussi un meilleur contrôle de la base de donnée, éventuellement pour du support/requêtes.
  • La version SQL standard suffit sans problème pour une installation d’un site primaire. Et cette version fait partie de votre licence. Vous pouvez installer cette version sur autant de serveurs souhaités tant qu’elle est utilisée pour Configuration Manager. Donc c’est possible de l’installer sur un MP Replica pour alléger la charge de la base de données principale.
  • La taille de la BD est d’environ 5Mb par client.
  • Toujours limiter la mémoire SQL.
  • 1 fichier de base de données par core, sans dépasser 8 fichiers. Le mieux c’est de le faire dès le début, car après l’installation il est impossible d’avoir les performances optimales.
  • 1 fichier temDB pour chaque 2 CPU.

[/eckosc_accordion]

[eckosc_accordion title= »Base de données de site » state= »closed »]

  • Dans le cas d’une moyenne entreprise et au-delà, précréer la BD manuellement ou avec un script utilisé en interne chez Microsoft pour avoir un contrôle total.
  • Activer la tâche de maintenance « Rebuild Index ». L’expérience montre qu’elle n’est pas si efficace dans certaines situations. Dans ce cas, utiliser le script Microsoft « UpdateIndex.sql » 1 fois par semaine en utilisant un job SQL.

[/eckosc_accordion]

[eckosc_accordion title= »Reporting Server » state= »closed »]

  • Autogrowth; mettre un seuil pour le reporting et limiter la taille des logs (pour ne pas avoir de mauvaise surprise)
  • Recovery mode = simple (par défaut il est sur Full, donc tant qu’un backup n’est pas effectué les fichiers de log ne sont pas supprimés)

[/eckosc_accordion]

Disposition des disques

Faire l’allocation NTFS de taille 64KB pour les volumes SQL
Sur un SAN, c’est primordial d’avoir d’excellentes performances IOPS

Disque Controleur # de Disques Partitions
0 0 4 OS
1 1 4 tempDB
2 1 4 fichiers Log
3 1 6 BD ConfigMgr
4 2 6 BD ConfigMgr
5 2 8 Programmes
6 x x ContentLib

[eckosc_accordion title= »Disposition typique des disques » state= »closed »]

C:\OS
D:\Program
E:\Content library
F:\ Fichiers BD (100GB)
G:\TempDB (50 GB)
H:\ BD Logs (50GB)

[/eckosc_accordion]

[eckosc_accordion title= »Disposition des disques pour site moyen » state= »closed »]

Combiner tempBD et les fichiers Log sur 1 partition
Combiner les fichiers bases de données sur 1 partition
Combiner le reste (non OS) sur 1 partition
Toujours planifier l’espace disque pour le ContentLibrary et autre sauvegarde de fichiers

[/eckosc_accordion]

Systèmes de site

[eckosc_accordion title= »Considérations pour la haute disponibilité » state= »closed »]

Dans 99% des cas, l’environnement Configuration Manager n’est pas un système critique pour une entreprise contrairement à la messagerie, etc. Mais les points suivants sont bons à savoir

  • SQL Always On est supporté depuis la version 1602
  • Le Mirroring SQL n’est pas supporté (fonctionne jusqu’au jour ou vous ferez une mise à niveau « dbupgrade » et là panique il faut réinstaller)
  • L’utilisation d’un cluster SQL n’est pas nécessaire et ne garantit pas une continuité totale si le site primaire tombe.

[/eckosc_accordion]

[eckosc_column_container count= »two »]
[eckosc_column_item]

Rôles avec instance multipes

Management point
Distribution point
State migration point
System Health Validator point
Application Catalog website
Application Web service point
Software update point
Reporting service point

[/eckosc_column_item]
[eckosc_column_item]

Rôles uniques

Site server
Asset Intelligence synchronization point
Endpoint Protection point
Enrollment point
Enrollment proxy point
Fallback status point

[/eckosc_column_item]
[/eckosc_column_container]

http://technet.microsoft.com/en-us/library/hh846246.aspx

[eckosc_accordion title= »Performance » state= »closed »]

Lorsque SQL est installé localement, c’est essentiel d’alléger la charge sur le serveur primaire en séparant les rôles face au client sur d’autres serveurs:

  • Management point
  • Distribution point
  • Application Catalog web service point
  • Application Catalog website point
  • Software update point

Tous les autres rôles peuvent être installé sur le serveur de site primaire
Pensez à utiliser le replica SQL sur les Management points (moyenne entreprise et au-delà)

[/eckosc_accordion]

Dimensionnement

Moins de 2000 Clients
1 serveur: BD SQL, tous les rôles, Site primaire
Moins de 20000 clients
1 serveur: BD SQL, Primary site, SMS provider, Endpoint Protection
2+ serveurs: Management Point, Software Update, Distribution Point, Application Catalog
Moins de 100K clients
1 serveur: BD SQL, Primary site, SMS provider, Endpoint Protection
4+ serveurs: Management Point, Software Update, Distribution Point, Application Catalog
Plus de 100K clients
1 CAS
2 PSS

[eckosc_accordion title= »Management Point / SQL replica » state= »closed »]

  • Les MP ne tiennent pas compte de l’emplacement réseau contrairement aux DP donc les clients d’un site distant peuvent communiquer avec n’importe lesquels. Si c’est une contrainte, ajouter un site secondaire.
  • Limite de 10 MP par site primaire, 1 MP pour site secondaire.
  • Le replica SQL est envisageable au-delà de 15000 clients, car il améliore les performances et la tolérance aux pannes, et sans exiger une licence supplémentaire.
  • BD de 3Go suffit, pas besoin des prérequis du site
  • Le replica SQL nécessite « SQL transactional replication », « SQL Agent » et un partage pour stocker les données du replica

[/eckosc_accordion]

[eckosc_accordion title= »Distribution Points » state= »closed »]

  • Considérer le Cloud DP pour les bureaux distant sans l’infrastructure adéquate.
  • Si le cloud DP est utilisé, ajouter un record DNS pour le cloud DP.
  • On peut configurer les alertes d’utilisation du cloud DP dans les propriétés.
  • Considéer le Brand Cache lorsqu’on ne peut pas mettre de DP local
  • Depuis le SP1 vous pouvez contrôler le trafic dans les options du DP

[/eckosc_accordion]

[eckosc_accordion title= »OSD » state= »closed »]

  • Utiliser MDT 2012 SP1/ MDT 2013 pour construire toutes vos images Windows de référence. Le fichier WIM obtenu peut ensuite être utilisé par n’importe quel outil de déploiement sur le marché. MDT peut entièrement automatiser l’injection de patchs, logiciels et autres réglages.
  • Considérer Windows Server 2012 R2 pour les DP, il y a de bonne performance pour le PXE.
  • Considérer Windows Server 2012 R2 (WDS) pour supporter les machines UEFI.
  • Utiliser des clés USB en FAT pour supporter les machines UEFI.

[/eckosc_accordion]

[eckosc_accordion title= »SUP » state= »closed »]

  • Depuis le SP1, on peut ajouter plusieurs SUP. Mais faire ceci si nécessaire, 1 SUP suffit dans la plupart des cas.
  • Le changement d’un SUP à un autre engendre du traffic (5MB) par les clients.
  • Les clients sont associés à 1 seul SUP jusqu’à ce que celui-ci échoue.
  • Une BD partagée pour les SUP représente une faille en cas de panne.
  • Voir WUAHandler pour les changements.
  • Un NLB WSUS est mieux pour la fault tolerance.

[/eckosc_accordion]

Forêts / Domaines multiples

3 scenarios:

  • a. Controller tous les clients dans un site primaire (recommandé)
  • b. Installer des sites systèmes distants, ceci n’est pas documenté, le compte de services utilisé doit être le même que celui utilisé l’installation des rôles. Et il y a des problèmes de communication avec les MP (pas recommandé)
  • c. Client Internet

Quand il n’y a pas de trust on utilise un compte pour le publishing dans AD et pour la création des objets dans le conteneur Systems Manangement.
Pour les découvertes le « path n’est pas le même et on utilise toujours le compte ad. (LDAP://contoso.com/DC=contoso,DC=com)
On peut utiliser un startup script (GPO) pour installer le client. Extension du schéma requise.

Considération des sites secondaires

  • Les sites distants ont plus de 500 clients et moins de 5000 clients
  • Vous voulez compresser et contrôler le trafic allant sur le site
  • Vous voulez un point de gestion local (MP)
  • Vous voulez un serveur de mise à jour logiciel local (SUP)