Archives de catégorie : Virtualisation

Update Rollup 4 for System Center 2012 Service Pack 1

J’ai un peu de retard mais le Rollup 4 pour la gamme System Center 2012 SP1 est sorti la semaine dernière. Cela concerne donc tous les produits de la gamme System center 2012. Avant de se lancer dans l’installation, attention à bien lire les remarques de la KB. C’est pas toujours aussi simple pour tous les produits (SCVMM) ainsi que l’ordre d’installation.

 

BenoîtS – Simple and Secure by Design but Business compliant.

HP StorageWorks P4000 Virtual SAN

Voila une initiative intéressante. Le stockage est un sujet sur lequel il est difficile de s former si on a pas de baie de disque sous la main. Pour résoudre cette problématique, HP met à disposition son StorageWork P4000 Virtual SAN Appliance au format ESX et Hyper-V.

 

Dans cette approche, le SAN est virtualisé, c’est du iSCSI. C’est pas parfait mais au moins on peut se faire une première idée de StorageWorks.

 

Le tout est disponible à cette adresse.

Support de la réplication du profil de l’utilisateur

Depuis Windows 95, on disposait des profils errants. Avec l’arrivée de la virtialisation de présentation (Terminal Server / Citrix), on a  réutilisé ces même profils errants, tout comme pour le VDI.

 

Avec l’arrivée de ces nouvelles infrastructures, le stockage des profils errants en un point unique est considéré comme un SPOF (Single point of Failure). La consolidation des infrastructures pose le problème de la disponibilité des profils errants.

 

Tout de suite, le première réflexe, c’est DFS-N et DFS-R. La problématique n’est portant pas si simple. Afin de clarifier les choses, l’équipe de support d’Active Directory vient de publier un billet résumant les architecture réellement supportées. A lire à tête reposée. Maintenant le sujet est clair.

 

Benoîts – Simple and Secure by Design (J’insiste sur le Secure)

Cycle de support de Windows 2000/2003

Le sujet fait toujours débat, mais tout arrive un jour (même Windows NT 4.0 est passé par là fin 2003). Tous les produits de Microsoft suivent un cycle de support identique. Il faut donc se préparer à abandonner certains systèmes d’exploitation.

 

On a beau dire, Windows 2000 a fait son temps. La date est proche (13 Juillet 2010). Il faut donc se préparer à migrer ces serveurs “résiduels”. Attention, migrer ne veut pas dire virtualiser. Il faudra bien migrer sauf si vos applications ne supportent pas un système d’exploitation plus récent (Windows 2003).

 

A la même date, ce sera la fin de la période principale de support de Windows Server 2003 et Windows 2003 R2. C’est moins critique car on a encore cinq ans. Pendant cette période de support étendue :

  • Microsoft continuera à fournir des correctifs de sécurité

  • Nous auront toujours accès à la base de connaissances

  • Les correctifs ne concernant pas la sécurité ne seront disponibles qu’aux clients ayant souscrits au programme EHS (Extended Hotfix Support)

Concernant Windows Server 2003. Microsoft a fait savoir qu’il n’y aura pas de Service Pack 3. Conclusion, il faut très rapidement entamer la migration des applications hébergées sous Windows 2000 et commencer à réfléchir au cas de Windows Server 2003. Il y a la problématique du système d’exploitation mais aussi des applications qu’il faudra bien réfléchir  : Virtualiszation or not is the question.

 

Benoîts – Simple and Secure by Design (j’insiste sur le Secure)

Une librairie PowerShell pour Hyper-V

Pour ceux qui ne peuvent mettre en œuvre SCVMM pour gérer Hyper-V, on constate que Microsoft n’a pas donné grand chose pour scripter son administration. Si WMI ne vous rebute pas, vous pouvez toujours vous orienter vers le site web MSDN de Microsoft pour y trouver les API mises à disposition par Microsoft. Mais alors pourquoi pas de provider PowerShell?

 

Heureusement, un certain James O’Neill a eu la bonne idée de développer une librairie PowerShell pour gérer Hyper-V. Il est disponible sur CodePlex chez Microsoft à cette adresse.

 

Maintenant, plus d’excuse pour ne plus utiliser Hyper-V dans un environnement de production.

 

BenoîtS- Simple and Secure by Design (J’insiste sur le Secure)

Les challenges des nouveaux projets de migration

Après le marathon DirectAccess (qui aura une suite dès que j’ai un peu plus de temps), j’avais besoin d’un peu de temps pour le prochain billet, un peu moins technique, plus axé sur les challenges des futurs projets de migration.

 

Multiplicité des sources de migration

C’est un fait, les infrastructure AD/Exchange mises en œuvre depuis Windows 2000 n’ont pas permit de réduire le nombre de domaines et donc de serveurs. On a souvent migré à l’identique, en conservant le nombre de domaine. Pour quelles raisons?

  • Techniques : En France, la principale limitation a été le coût du WAN. Maintenant, ce facteur et beaucoup moins important avec la généralisation des technologies DSL et le déploiement de la fibre optique.

  • Conformisme : C’est tellement plus simple de refaire ce qu’on a déjà fait dans le passé.

De ce fait, lorsqu’on migre ces infrastructures, on a plusieurs “sources” de migration. Qui dit plusieurs sources dit conflits de noms lors de la migration. Pour adresser cette problématique, on a deux possibilités  :

  • Traiter la problématique à la source : C’est la méthode la plus simple. On renomme les objets dans le domaine “source” de la migration. Par contre, renommer un compte utilisateur a un certain nombre d’impacts. Il faut donc pouvoir anticiper cette phase au plus tôt.

  • Traiter la problématique à la cible : Renommer sur le domaine “cible” demande autant de travail mais on peut communiquer aux utilisateurs au plus tôt, ce qui permet de minimiser l’impact.

 

Un conflit peut aussi donner lieu à la fusion des objets (contacts en double, groupes en double). Cela ne pose pas de problème particulier sauf que plus on multiplie les sources, plus nos utilisateurs migrés seront membres de groupes (via le Sid-History). Cas concret, la fusion de sept domaines en un seul, l’utilisateur migré est membre au minimum du groupe “Utilisa. Du domaine” mais aussi des mêmes groupes issus des groupes des domaines sources (cas de migration vers Windows 2000). Que va t’il se passer si nos utilisateurs sont membres de trop de groupes? Y a t’il une limité? Et bien oui, 1015 KB328889, et cela a un impact sur les GPO : KB263693. L’impact sur les utilisateurs sera multiple.

Limitations autour du Sid-History

Le fait qu’un utilisateur migré puisse accéder à ses données dans l’environnement “source” repose uniquement sur le “Sid-History”. Encore faut-il que les applications soient capables de l’utiliser. Un exemple chez Microsoft? SharePoint :

Mais sans aller aussi loin, il y a une limitation propre à Windows. Si on regarde ADMT, il n’est pas capable de migrer l’appartenance aux groupes “Built-in”. Or, il arrive souvent qu’on ait utilisé des groupes tels que ‘”Utilisa. du domaine”. Et là, ADMT bloque. Pas de problème me direz-vous, la solution de migration de Quest elle y arrive. Vrai, sauf si la source est Windows Server 2003. La raison est toute simple : The security IDs for built-in domain groups are filtered in Windows Server 2003. Pour adresser cette problématique, il n’y a que deux solutions :

  • Corriger les permissions positionnées sur les ressources à la source et les remplacer par de nouveaux groupes (Démarche ADMT)

  • Migrer ces groupes sous un autre nom dans le domaine “cible”

Les serveurs d’impression

Migrer un serveur d’impression, c’est facile, super facile avec Windows Server 2008. Il y a un assistant qui fait cela très bien. Pour que la migration fonctionne, encore faut-il disposer du pilote d’imprimante équivalent sous Windows Server 2008 qui ne fonctionne pas en mode noyau (car impossible sous Windows Server 2008 64bits). En plus, l’outil de migration est bien capable de migrer mais depuis Windows Server 2003, pas Windows 2000. Pour ce dernier, il faut passer par un serveur pivot Windows Server 2003 et le bon vieux Print Migrator. Dispose t’on des pilotes pour les imprimantes pour Windows 2008? Bonne question. Il y a un risque pour que non ou que le pilote ne reprenne pas toutes les fonctionnalités du pilote initial.

GPO installation d’applications

Lorsqu’on utilise les stratégies de groupe pour installer des applications, la migration peut poser problème. Lorsque le poste va migrer, l’application va automatiquement être réinstallée si on migre aussi la stratégie de groupe. Comment éviter la réinstallation sur les postes migrés et continuer à déployer l’application sur les nouveaux postes? Pour cela, pas d’autre solution que d’identifier la population des postes migrés par un groupe que l’on va utiliser sur la stratégie de groupe pour en filtrer l’application (en refus).

DFS

C’est là le pire. Certains clients ont découvert DFS avec Windows 2000 (pas brillant sur la réplication) et surtout avec Windows Server 2003 (bien mieux avec DFS-R). Migrer une racine DFS est impossible, il faut la recréer. On a deux problèmes :

  • Le changements de chemin UNC
  • La réplication

 

En recréant une racine de domaine dans le domaine “cible”, c’est un nouveau chemin UNC. Que va t’il se passer pour les documents Office qui font référence à d’autres documents? La réponse est simple, la référence ne fonctionne plus car elle est exprimée avec le chemin UNC de la racine DFS. Donc l’utilisateur vient se plaindre que ses fichiers Excel avec multiples références ne fonctionnent plus. Il est a noter que la problématique est identique sans DFS, le simple fait de migrer les données de l’utilisateur sur un autre serveur de fichiers produit le même effet.

La réplication DFS. Un cauchemar sous Windows 2000, nettement mieux sous Windows Server 2003. Le problème, c’est qu’un groupe de réplication ne peut contenir des membres que de la même forêt. Dans le cadre d’une consolidation de forêts, il y a donc un problème. Mais alors comment migrer? Il n’y a pas de réponse “Microsoft” à cette problématique, sinon un exemple. Comment migrer la racine DFS SYSVOL de la réplication. Avec DFSRMIG, tel que je l’avais présenté dans le billet DFSRMIG & SYSVOL. Voila l’idée de base qu’il faut reproduire. Cette fois on ne migre pas quelques mégaoctets mais des giga-octets. L’erreur est ici interdite.

La virtualisation

C’est devenu un composant essentiel pour tous les projets de migration, que ce soit plus la plateforme de pré-production ou même la plateforme de migration. Cependant, la virtualisation pose aussi un certain nombre de problèmes. Premièrement, tous les logiciels ne sont pas entièrement supportés. Le cas Exchange est le plus connu, mais c’est aussi valable pour MOCS.

Conclusion

Les projets de migration seront d’autant plus compliqués qu’il y aura plusieurs domaines à consolider. L’aspect technique peut être traité. Cependant, il ne faut pas sous-estimer la communication aux utilisateurs et l’assistance à fournir en avance de phase de la migration. Plus les domaines “sources” seront rationnalisés, plus la migration s’en trouvera simplifiée.

BenoîtS – Simple and Secure by Design (J’insiste sur le Secure)

La synchronisation horaire en environnement virtuel

Dès lors qu’un système d’exploitation est virtualisé (Citrix, Vmware, Microsoft, …), le socle de virtualisation se propose de fournir un certain nombre de services additionnels sous forme de “Integration services” ou tout autre nom. L’un de ces services trait à la synchronisation horaire.

 

D’un certain point de vue, l’approche est intéressante. Cependant le bon fonctionnement de bon nombre de protocoles sont liés à une stricte synchronisation horaire. Kerberos est un exemple assez connu dans le monde “Microsoft” avec sa tolérance de seulement cinq minutes (configurée par la stratégie de domaine).  Kerberos n’est pas un cas isolé. L’ensemble des processus liés à la réplication Active Directory utilisent l’heure GMT. Dès lors qu’un ou plusieurs systèmes ne sont pas à l’heure ou pire donc l’heure n’est pas stable, on peut s’attendre à bon nombre de problématiques.

 

La toute récente KB976924, fait référence à cette problématique dans le cadre des contrôleurs de domaines hébergés sous Hyper-V. Cependant, cette problématique ne concerne pas seulement Hyper-V. La problématique est la même quelque soit l’Hyperviseur.

 

Personnellement j’étendrait même cette KB aux serveurs membres car eux aussi ont besoin de conserver une synchronisation horaire stable. Qu’arriverait-il à un cluster CCR Exchange 2007 si l’heure n’était pas stable? Ou alors à une PKI avec les listes de révocations.

 

Benoîts – Simple and Secure by Design