SCCM 2012 dans une architecture multi-forêts

Il est très fréquent dans les grandes entreprises de trouver une architecture Active Directory composée de plusieurs domaines, voire de plusieurs forêts avec ou sans relations d'approbation. Cette segmentation permet de sécuriser et de limiter l'interaction entre les différentes entités et équipements de l'entreprise. Cette organisation amène tout un ensemble de questions lorsqu'il s'agit d'implémenter SCCM afin de gérer les serveurs et/ou les postes répartis sur ces différents domaines et forêts.

Avec SCCM 2007, on avait généralement pour habitude de calquer l'architecture SCCM sur l'architecture Active Directory. On plaçait donc un premier site primaire central dans la forêt de ressources principale, puis des sites enfants dans les sous-domaines et forêts. Au sein d'un même domaine, on pouvait créer plusieurs sites SCCM 2007 afin de maîtriser la bande passante nécessaire aux réplications entre des sites géographiques différents.

Note : Contrairement à une idée répandue, il n'est pas nécessaire d'avoir une architecture en mode natif (authentification des clients via certificat) pour établir des liens entre des sites SCCM 2007 situés dans des forêts différentes même sans aucune relation d'approbation.

Quels sont désormais les grands principes dans SCCM 2012 pour gérer des postes répartis dans des forêts AD différentes ?

• Créer un site enfant dans une forêt distante. Gros changement par rapport à SCCM 2007 : Cette solution impose d'avoir une relation d'approbation bi-directionnelle entre les 2 forêts. Attention, de nombreux blogs (même officiels) oublient ce pré-requis et construisent des architectures SCCM 2012 comme sous 2007. Le Technet et le support sont pourtant fermes et sans appel : ce prérequis est obligatoire pour permettre aux réplications SQL d'opérer correctement.

• Installer un site system (un serveur disposant d'un rôle SCCM) dans une forêt distante. En effet, il n'est pas nécessaire que tous les serveurs d'un site SCCM 2012 soient dans le même domaine ni dans la même forêt. Il n'est même pas nécessaire que les différents domaines/forêts aient la moindre relation d'approbation. Lors de l'installation du site system, il est nécessaire de fournir un compte disposant des droits d'administrateur local sur ce serveur. C'est ensuite ce compte qui servira pour communiquer en le Site System et le Site Server (serveur principal d'un site SCCM)

• Gérer directement les postes depuis des serveurs SCCM situés dans une autre forêt. En effet, rien n'impose encore qu'un poste et le serveur SCCM qui le gère soient dans le même domaine. Rappelons à ce titre, qu'il est même possible de gérer des postes en workgroup. Quelques précautions s'imposent néanmoins pour localiser correctement les serveurs SCCM quand on ne peut pas utiliser Active Directory.

Pour plus d'information : Planning for Communications in Configuration Manager

Quelles sont les impactes directes sur l'architecture ?

Nous voyons clairement que SCCM ne peut plus suivre l'architecture Active Directory si les différentes forêts ne sont pas liées entre elles par des relations d'approbation bi-directionnelles !

Retenons 2 principes de bases sous SCCM 2012 :

• Tous les Site Servers doivent être situés dans la même forêt (ou dans des forêts ayant une relation bi-directionnelle, ce qui est rarement le cas quand on souhaite justement isoler les différents environnements).
• Par contre, au sein d'un même site primaire, il est possible de créer plusieurs Management Point et Distribution Point que l'on répartira dans les différentes forêts et domaines à couvrir.

Je rappelle qu'il est possible d'avoir jusqu'à 10 Management Point par site primaire. Il est donc possible de couvrir 10 forêts/domaines différents par site primaire. S'il faut en couvrir d'avantage ou si on souhaite mettre plusieurs MP par forêt/domaine, il faut alors multiplier le nombre de sites primaires et avoir recours à un CAS.

Et dans la pratique, çà donne quoi ?

Prenons l'exemple d'une entreprise avec :

 - 2 forêts appelées ROOT (la forêt de ressource) et CORP (la forêt contenant les postes de l'entreprise)

 - 3 emplacements géographiques : Londres, Paris et New-York

Les serveurs de la forêt de ressource ROOT sont principalement localisés à Paris.

Les postes de la forêt CORP sont localisés à Paris, Londres et NY

Nous souhaitons bien évidemment être capable de gérer convenablement la réplication entre les sites géographiques.

Pour commencer, voici, l'architecture à ne surtout pas faire sous SCCM 2012 :

Notons qu'il faut :
 - un site Central + 4 sites primaires (voire 6 si on avait voulu gérer des serveurs dans la forêt Root à Londre et Paris).
 - 5 serveurs SCCM (voire 7)

C'était tentant, mais c'est malheureusement tout à fait impossible. Bref, n'en parlons plus !

Maintenant regardons comment nous pouvons simplement faire une architecture SCCM 2012 en gardant quelques (vieux) réflexes de SCCM 2007 :

 - Toujours, plusieurs sites primaires (3), donc un CAS.
 - Les sites servers sont installés dans chaque pays dans la forêt de ressource (on y ajoute au passage les rôles MP et DP).
 - Dans chaque pays, on installe également un site system dans la forêt CORP avec les rôles MP et DP. Ce sont ces site system qui vont gérer les serveurs dans CORP.

Bilan : Nous avons donc au total 1 CAS, 3 sites primaires pour un total de 7 serveurs.
Pas tellement optimisé mais au moins, çà marche !


Pour aller plus loin... Je vous propose alors cette architecture :

1 seul site Primaire standalone et seulement 4 serveurs !
Nous voyons clairement comment désormais, avec SCCM 2012, il est possible de réduire le nombre de sites, de serveurs et donc le coût global de la solution.

J'entends déjà ceux qui se demandent comment je vais gérer mes réplications entre les 3 sites géographiques. Pour y répondre, je vous propose de me retrouver dans un prochain article où je détaillerai les différentes manières de gérer la bande passante dans SCCM 2012, y compris au sein d'un même site.

@Bientôt

Julien

Patcher les Clusters Windows

Le patching des serveurs Windows est un sujet ultra classique dans les entreprises. Microsoft répond à cette problématique via WSUS et SCCM. D'ailleurs depuis SCCM 2007, ce produit s'appuie sur le moteur de WSUS pour détecter les patchs nécessaires sur les postes, mais utilise ensuite ses propres mécanismes pour la distribution afin d'apporter d'avantage de fonctionnalités telles que les fenêtres de maintenance ou la possibilité d'interdire le redémarrage du serveur.

Le sujet devient autrement plus compliqué dès qu'il faut patcher des clusters...
Pour automatiser le déploiement de patchs sur les clusters, certaines entreprises tâchent de mettre les différents noeuds dans des fenêtres ou des groupes de patching différents. Les noeuds rebootent ainsi à des moments différents.
Ce fonctionnement trouve vite ses limites, quand les ressources n'ont pas basculé correctement ou lorsqu'un noeud n'a pas correctement redémarré.

Et qu'est ce que dit le Support Microsoft ?
Aussi étrange que cela puisse paraître, pour le patching d'un cluster, le support Microsoft n'a guère que la KB174799 : Patching Windows Server Failover Clusters à proposer, c'est à dire, une procédure manuelle. Rien d'automatique !
Dans une réponse récente, le support précise aussi que la fonctionnalité de bascule des ressources cluster est une fonctionnalité de protection qui ne doit pas être mis en oeuvre en fonctionnement nominal. Il est donc hors de question de laisser un serveur redémarrer (donc d'appliquer un patch nécessitant un redémarrage) alors qu'une ressource est en cours d'exécution. Pour Microsoft, il est en effet préférable que la bascule des ressources soit supervisée par un opérateur .

A noter que les cluster Hyper-V échappent à cette règle. En effet, grâce à SCVMM, il est possible de passer un noeud en mode maintenance entraînant le déplacement automatisé et sécurisé de toutes les ressources sur les autres nœuds actifs.


Que peut-on faire à court terme ?
Reste à trouver une solution pour patcher les clusters, certes sans revenir à un processus entièrement manuel, mais surtout sans risquer des casser les ressources hébergées (et en général critiques).
Il est, je pense, évident pour tout le monde que la production est prioritaire, mais qu'il faut tout de même appliquer ces patchs quand cela est possible. A court terme, la meilleure solution trouvée a donc été de préserver l'intégrité d'une ressource en interdisant de patcher le nœud sur lequel elle s'exécute plutôt que de patcher ce nœud au risque de corrompre cette ressource.

La solution retenue a donc été de rester sous WSUS en mettant les nœuds des clusters dans des groupes différents. A la charge pour les opérateurs de déplacer les ressources sur les bons nœuds avant chaque fenêtre de patching. Jusque là, rien de très nouveau même si le dernier point implique un travail manuel important pour les opérateurs.

Pour éviter les oublis et les catastrophes, un script est chargé de vérifier périodiquement sur chaque nœud si une ressource s'exécute et interdit dans ce cas l'installation automatique des patchs.
Les tentatives pour déplacer automatiquement les ressources par script se sont soldées par de gros échecs, principalement en raison de la complexité du processus.

Schématiquement, voila ce que çà donne :

Vous pouvez télécharger le script AutomaticPatchInstallation. Vous trouverez avec ce script la procédure d'installation/désinstallation ainsi que la procédure de patching d'un cluster avec cet outil.


Sympa le Bricolage ! Maintenant que la production est sécurisée, qu'elle solution plus pérenne peut être mise en place ?
Je l'avoue, c'est un peu du bricolage ;o) mais ce bricolage permet d'offrir rapidement une solution pour que les applications critiques conservent leur base SQL en état de marche (pas mal, non ?)


Reste bien évidement encore à trouver une solution nécessitant moins d'intervention manuelle tout en garantissant la sécurité du processus.
Notre cahier des charges est alors le suivant :
 - Un Cluster n'est patché que si tous ses noeuds sont en bonne santé
 - Les ressources doivent être déplacées d'un noeud à un autre automatiquement mais de manière sécurisé
 - L'ensemble du processus doit être supervisé et facilement adaptable aux spécificités des applications.

La Suite System Center 2012 est bien évidemment tout indiquée :
 - SCCM 2012 se charge de patcher les noeuds
 - SCOM 2012 se charge de superviser l'état du cluster et de ses noeuds
 - SC Orchestrator 2012 se charge quant à lui d'orchestrer les opérations

Le processus de déploiement sécurisé des patchs sur les nœuds d'un cluster est alors le suivant :

Le codage de workflow dans SC Orchestrator 2012 peut être plus ou moins long selon le niveau de service attendu mais nous voyons déjà toute l'intérêt de SC Orchestrator 2012 pour effectuer des tâches courantes d'administration.


@bientôt
Julien

Récupérer les bon Logs dans SCCM

Tout Troubleshoot commence par chasser les bons logs. Le terme n'est pas trop fort parce que, soyons honnêtes, SCCM en génère beaucoup qu'il dispose un peu partout, autant sur les serveurs que sur les postes de travail. D'ailleurs Microsoft a jeté l'éponge et ceux qui ont lu la page Technical Reference for Log Files in Configuration Manager ont certainement été surpris en lisant :

Locating Configuration Manager Logs
By default, Configuration Manager log files are stored in a variety of locations that depend on the process that creates the log file, and on the configuration of your site systems. Because the location of the log on a given computer can vary, use search to locate the relevant log files on your Configuration Manager computers to help you troubleshoot a specific scenario.

Il y a donc les consultants qui cherchent désespérément les logs PXE au milieu les autres logs SCCM, les techniciens qui ne remontent pas les bon smsts.log, etc...

Pour vous faciliter la vie (et/ou les aller-retours inutiles), je vous propose plusieurs idées :

• Dans le cadre d'un déploiement d'OSD, je vous recommande l'excellent guide de Nicolas Niehaus qui récapitule l'emplacement des différents fichiers de logs : http://blogs.technet.com/b/mniehaus/archive/2012/09/11/troubleshooting-windows-deployments-take-2.aspx

• Pour capturer rapidement et sans faute des logs, j'ai aussi mis au point un script qui peut capturer sur un poste local ou distant (pour peu que votre compte puisse y accéder par les partages administratifs) tout un ensemble de logs. Bien entendu, ce script peut aisément être adapté à n'importe quel produit (ou même copier autre chose que des logs), mais j'ai déjà défini les principaux logs pour les serveurs et les clients SCCM.

Vous pouvez télécharger LogHunter.vbs.

En ligne de commande, la syntaxe est toute bête :
cscript.exe logHunter.vbs [IP / Nom Distant]

Si aucun argument n'est fourni, le script cherche les fichiers sur le poste local.

Si vous fournissez un nom de poste distant par argument, le script transforme tout seul le chemin local en un chemin UNC (donc C:\logs est transformé en \\OrdiDistant\C$\Logs)

Les répertoires à récupérer sont stockés dans un répertoire généré au même emplacement que le script (donc nickel avec une clé USB par exemple pour troubleshooter un déploiement qui se passe mal). Le nom du répertoire est de la forme YYYYMMDD.HHMM-NomOrdinateur

La personnalisation les répertoires à récupérer se fait tout simplement en éditant les premières lignes du script : Il s'agit d'un tableau, où chaque élément est de la forme
"Répertoire local à récupérer | Nom du répertoire de copie".


Ainsi, si je lance le script sur l'ordinateur TOTO avec comme instruction "C:\logs|Logs_sur_C", j'aurai à coté de mon script le répertoire 20120918.214-TOTO avec à l'intérieur le répertoire "Logs_sur_C" qui contient une copie des fichiers contenu dans C:\logs
Je vous laisse étudier les autres exemple fournis avec le script.

Un script à garder pas trop loin et à mettre entre toutes les mains si vous souhaitez qu'on vous rapporte des logs exploitables :o)


N'hésitez pas à me faire des retours

Bon Troubleshoot
Julien