mercredi 26 septembre 2012

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.


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

jeudi 20 septembre 2012

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

mardi 18 septembre 2012

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 :
  • 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

dimanche 16 septembre 2012

Sélection de Stencils Visio

"Un schéma vaut mieux qu'un long discours". Cette expression attribuée à Napoléon est toujours d'actualité surtout avec des produits aussi complexes que ceux de la suite System Center.

Je vous propose une petite sélection de Stencils Visio plus ou moins récents, mais toujours très utiles.
Vous pouvez les téléchargez ici.
J'en profite pour saluer au passage toutes les personnes à qui nous devons ces Stencil.

Pour commencer les ITPro_PosterStencils et les ITStencils pour faire des Schémas comme sur le Technet (la clâsse !! ) :

 Les objets pour SCCM 2007 et SCCM 2012 (v0.9, un grand merci à Jean Sébastien Duchêne) :














SCOM 2007 :








Tout un ensemble d'objets autour de la Virtualisation et de HyperV : Virtualization 2008 et Virtualization_Modern :


et pour finir, quelques Stencils VMWare :








A vous de Jouer !!
Julien

jeudi 6 septembre 2012

CAS ou Pas CAS... avec le SP1

Débat débuté dès la sortie des premières versions de SCCM 2012 et qui continue à faire parler de lui dans les entreprises : "Faut-il installer un CAS ou pas ?"

Pour bien commencer, rappelons ce qu'est un CAS :
Par rapport à SCCM 2007, l'organisation des Sites SCCM 2012 s'est vue fortement réduite : il n'est plus possible de mettre un site primaire enfant sous un autre site primaire parent. Un site primaire peut seulement héberger des sites secondaires (250 max par site primaire). En contrepartie, il est possible de mettre jusqu'à 10 Management Point par site primaire et de gérer jusqu'à 100.000 clients (25.000 client max par MP).

Dans certains cas, on peut faire le choix d'implémenter un site central appelé CAS (Central Administrative Site) permettant d'administrer plusieurs sites primaires. Ce site n'a pas vocation à gérer de clients mais seulement à :
  • Gérer la réplication entre les sites primaires
  • Donner une vision globale de l'infrastructure (reporting...)
  • Centraliser l'administration des différents sites primaires
Note : On parle de hiérarchie quand une infrastructure SCCM contient un CAS avec un ou plusieurs sites primaires. Une infrastructure constituée d’un site primaire "standalone" (sans CAS) et de sites secondaires n’est pas considérée comme une hiérarchie puisque les sites secondaires ne sont pas acteurs dans l’administration de la solution.


Quand doit-on mettre un CAS ?
Je vous renvoie à l'excellent article de Brian Mason listant les raisons pour lesquelles il faut installer ou éviter d'installer un CAS :
http://myitforum.com/myitforumwp/2012/04/22/cas-considerations-for-cm12/

Retenons les grands principes :
OUI :
  • Si vous avez plus de 100.000 clients à gérer
  • Si votre infrastructure SCCM contient plusieurs sites primaires (voir le chapitre dédié à ce sujet)
  • Si vous souhaitez simplifier certains aspects de vos restaurations (je parle de recovery, pas de manger pour pas cher, hin ;)). En effet, votre paramétrage étant répliqué entre le CAS et ses sites primaires, lors de la restauration d'un site il est possible de récupérer certaines données depuis le reste de l'infrastructure. Cependant, cela ne dispense absolument pas de faire des backup, mais disons que votre infrastructure sera plus rapidement opérationnelle avec notamment un inventaire à jour.
NON :
  • Parce que cette fonctionnalité requière une machine super puissante (http://technet.microsoft.com/en-us/library/hh846235.aspx)
  • Parce que cette machine supplémentaire requière nécessairement des licences, des coût de runtime...
  • Parce que ce serveur supplémentaire, entraînant des réplications SQL et complexifiant votre infrastructure, demande un effort supplémentaire de gestion et apporte son lot de causes de pannes supplémentaires.
Grosso modo, on peut estimer que dans 95% de cas, il n'est pas utile d'installer de CAS.

 
Quand doit-on avoir plusieurs sites primaires ?
Avoir plusieurs sites primaires implique forcément avoir un CAS. Reste à savoir si le contexte nécessite d'avoir plusieurs sites primaires comme dans SCCM 2007, au risque (encore une fois) de complexifier l'infrastructure.


En effet, SCCM 2012 a fortement diminué les raisons pour lesquelles il faut installer plusieurs primaires : il est notamment possible d'avoir plusieurs politiques clients au sein d'un même site, d'avoir des connexion HTTP et HTTPS (mode mixte et natif sous SCCM 2007) et la délégation a été très nettement améliorée.
Sous SCCM 2007, il était aussi souvent nécessaire de créer plusieurs sites pour gérer des forêts sans relations d'approbations. Au contraire sous SCCM 2012, les relations inter-sites nécessitent des relations inter-forêts bi-directionnelles (réplication SQL oblige). Les relations inter-forêt non-bidirectionnelles ne peuvent être gérées qu'au sein d'un site. (Nous étudierons cette question épineuse dans un prochain message).



On peut vous imposer politiquement ou pour des raisons de sécurité... d'avoir plusieurs sites primaires mais avec ce CAS, vous aurez de toute façon une vision centrale, des réplications et la possibilité de lancer des opérations sur tous vos sites primaires.


Bref, vous l'avez compris, si vous avez moins de 100.000 clients, il est peu probable que vous ayez besoin d'avoir plusieurs sites primaires.

Sur le technet, Microsoft présente un scénario avec 2 sites primaires (et encore, on n'exclue pas d'utiliser un site secondaire et une délégation correctement appliquée) : 2 sites géographiques gérés par 2 équipes techniques différentes selon des règles de gestions différentes. On pourrait envisager d'avoir 2 sites primaires standalone mais ils veulent avoir une vision de l'ensemble ce qui implique l'installation du CAS.
Si le scénario est intéressant, le cas risque d'être assez rare dans la vie réelle :o)






Pourquoi un tel débat ?
Jusqu'à présent ce choix était crucial puisque contrairement à SCCM 2007 qui permettait d'attacher/détacher n'importe quand un site primaire à une hiérarchie, sous SCCM 2012, un site primaire doit être rattaché dès son installation à son CAS ; sinon, il restera à jamais un site Standalone.
Le problème se pose donc par exemple quand aux potentiels projets de fusion/acquisition d'une entreprise : Certains administrateurs souhaitent installer un CAS dans le cas où l'entreprise voudrait rattacher une entité indépendante à son infrastructure SCCM 2012. Notons pourtant qu'il ne sera pas possible de rattacher à postériori une site primaire à un CAS. A partir de là, le débat fait rage quand à la vraisemblance de tels scénarios et au travail qu'il faudra de toute façon fournir.

Prochainement, cette limitation ne sera plus un argument puisque parmi les améliorations annoncées dans SCCM 2012 SP1, on trouve la possibilité "d'étendre" un site primaire standalone en installant un CAS qui lui est alors rattaché. Le Technet indique déjà la marche à suivre : http://technet.microsoft.com/en-us/library/jj591551

A noter qu'il sera seulement possible d'étendre un primaire standalone. Il ne sera donc toujours pas possible de rattacher à postériori un site primaire standalone à une hiérarchie existante. Par contre, le SP1 encore nous permettra de réaliser des migrations d'un environnement SCCM 2012 SP1 vers un autre environnement SCCM 2012 SP1. Typiquement, il sera donc possible de fusionner ou d'exporter des infrastructures SCCM 2012 SP1. On pourra aussi utiliser cette fonctionnalité pour faire communiquer des environnements de test, pré-production et production. Promis, on en reparle...


Pour info, voici la liste complète des améliorations prévues dans le SP1 : http://blog.coretech.dk/kea/configmgr-2012-sp1-announced-teched-2012/


@bientôt
Julien


Ajout du 14 sept 2012 : Je vous disais qu'un CAS pouvant simplifier les opérations de restauration... mais elle peut aussi les compliquer grandement.
Simplifier : parce que si un primaire ou un CAS tombe, l'autre site peut retransmettre des informations à l'autre site après la restauration. Pratique donc surtout si les sauvegardes sont espacées.
Compliquer grandement : Lors de la restauration d'un CAS, celui-ci passe en mode maintenance tant que TOUS les sites primaires ne sont disponibles. De son coté, lors de la restauration d'un site primaire, il fait indiquer le nom du serveur CAS et que celui-ci soit fonctionnel. Dans le cas (extrême mais possible) où il faudrait restaurer un CAS + un site primaire, la réinstallation de chaque site nécessitant que l'autre site soit opérationnel, l'affaire tourne à la réinstallation intégrale de l'infra :-(

lundi 3 septembre 2012

Technet in the Pocket

Le Technet, c'est bien ! C'est même notre Bible à tous (n'est ce pas, hin !?!). Par contre, l'affaire se corse en l'absence d'une connexion Internet ou pour faire des recherches...
C'est sans doute parce que vous ignorez qu'il est possible d'exporter des groupes entiers d'articles.

Dans cet article, je vais vous montrer comment en quelques clics, il est possible d'exporter jusqu'à une centaine d'articles dans un PDF.

Tout se joue depuis l'icone d'impression en haut à droite du Technet.
 - Cliquez dessus et sélectionnez Print Multiple Topics


Une fenêtre d'aide apparaît.
 - Cliquez simplement sur Start














 

Vous revenez à votre documentation Technet. A cela près qu'une barre vous permet de gérer votre sélection d'articles.
 - Cliquez avec le bouton droit sur un article ou une rubrique.
Un menu vous propose d'ajouter cet article ou tous les articles de la rubrique (et vous indique le nombre).


Créez votre compilation selon vos besoins.
Actuellement, une compilation est limitée à 100 articles maximum. Si en sélectionnant une rubrique, vous voyez (100+), c'est qu'il y a trop d'articles à ajouter dans votre compilation.

 - Une fois terminé, cliquez sur Collection (XX Topics)


Vous retrouvez toutes les rubriques et articles que vous avez sélectionné.
 - Vous pouvez modifier l'ordre des éléments, créer des chapitres et même personnaliser le nom de votre "livre"
 - Dans la partie Avancée, sélectionnez votre format de sortie : HTTP / PDF
 - Cliquez sur Generate






La génération peut prendre plusieurs minutes selon la quantité d'articles sélectionnés.
 - A la fin, cliquez sur Download Your Document











Dernièrement, j'ai pu exporter l'intégralité de la documentation Technet SCCM 2012 dans 5 PDF. Vous les trouverez sur mon espace SkyDrive publique : http://sdrv.ms/R3mTxS
Je tâcherai de les mettre à jour régulièrement.


Bonne lecture
Julien