PI Services

Le blog des collaborateurs de PI Services

Active Directory : Migration SYSVOL de FRS vers DFS-R - Etape Prepared (Partie 3)

Bonjour à tous,

Aujourd'hui nous abordons la partie 3 de notre série sur la migration du dossier SYSVOL du mécanisme de réplication FRS vers DFS-R, elle sera consacrée à l'étape Prepared.

En théorie

Déroulement de la migration

La migration se compose de 4 états globaux qui sont les suivants :

Etat  Actions  Dossier SYSVOL Dossier SYSVOL_DFSR Dossier utilisé par les services AD DS
 Start (Etat 0)  Etat par défaut, FRS réplique le dossier SYSVOL. Présent Non présent SYSVOL
 Prepared (Etat 1)
 FRS réplique le dossier SYSVOL et celui-ci est toujours utilisé par les services AD DS.
DFS-R réplique une copie de ce dossier.
 Présent Créé SYSVOL
 Redirected (Etat 2)
FRS réplique le dossier SYSVOL.
DFS-R réplique toujours sa copie et celle-ci devient le
dossier utilisé par les services AD DS.
 Présent  Présent SYSVOL_DFSR
 Eliminated (Etat 3)
Le dossier SYSVOL répliqué par FRS est supprimé.
DFS-R réplique le dossier SYSVOL.
 Supprimé  Présent SYSVOL_DFSR
 

Particularités

Comme vous pouvez le voir ci-dessus, l'état 1 (Prepared) n'est pas le plus impactant :
  • En arrière-plan, le mécanisme de réplication DFS-R est mis en place pour répliquer une copie du dossier SYSVOL, en parallèle de la version répliquée par le mécanisme FRS.
  • En façade, c'est toujours le dossier SYSVOL répliqué par le mécanisme FRS qui est présenté aux postes clients via les partages NETLOGON et SYSVOL
En revanche, il faut souligner les points suivants :
  • Un retour arrière reste possible (il faut utiliser la commande dfsrmig /setglobalstate X où X est le numéro de l'étape voulue)
  • Une copie du dossier SYSVOL actuel sera réalisée. Il convient de vérifier que le dossier SYSVOL est intègre avant de commencer les étapes de migration sinon vous vous retrouverez avec un dossier SYSVOL qui sera toujours corrompu en fin de migration.
  • Le dossier SYSVOL est copié une seule et unique fois lors de la premiere étape. Toute modification faite sur les GPOs ou le dossier SYSVOL lui même entre l'état 1 (Prepared) et l'état 2 (Redirected) est perdue.
  • Les commandes de migration sont à lancer depuis le contrôleur de domaine possédant le rôle PDC

En pratique

Etat Start

Si aucune tentative de migration n'a été faite auparavant, l'état de migration au niveau du domaine AD ainsi que celui de tous les contrôleurs de domaine doit être Start.

Etat global (Domaine AD) : dfsrmig /getglobalstate

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

Une fois ces deux points vérifiés, nous pouvons démarrer la migration vers l'état Prepared.

Passage vers l'etat Prepared

Etat global (Domaine AD) : dfsrmig /setglobalstate 1

On remarque qu'il est indiqué un délai concernant le début de la migration pour les contrôleurs de domaine.
Ceci est parfaitement normal car les contrôleurs vont aller lire l'information sur l'état de la migration depuis la partition Active Directory qu'ils auront répliqué.
Vous pouvez donc avoir un début de migration tardif à cause :
  • D'une réplication Active Directory lente
  • D'un RODC ne voulant pas passer en état Prepared. Les RODCs ne pouvant pas modifier les objects Active Directory par eux mêmes (création des objets DFS-R leur correspondant), c'est le PDC qui est chargé de le faire à leur place. Toutefois, si malgré un certain délai, les RODCs ne passent pas en état Prepared, il faudra forcer la création des objets DFS-R correspondant avec la commande dfsrmig /CreateGlobalObjects (à éxécuter seulement une fois depuis le PDC)

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

On voit ici que la migration est en cours car aucun contrôleur de domaine n'est dans l'état defini au niveau du domaine Active Directory (Etat Global).

Etat Prepared atteint

Etat global (Domaine AD) : dfsrmig /getglobalstate

La commande dfsrmig /setglobalstate avait déjà configuré l'état de migration au niveau du domaine Active Directory à Prepared. Celui-ci reste donc inchangé.

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

Le message est explicite, tous les contrôleurs de domaine sont dans l'état Prepared, le même que celui défini au niveau du domaine AD (état global).
On dit que la migration a atteint un état consistant sur tous les contrôleurs de domaine.
 
Bonus : 
En cas de succès, on constate également la présence sur tous les controleurs de domaine de l'evenement 8014 dans le journal d'évènements Applications and Servicies logs -> DFS Replication

 

La commande net share executée sur un contrôleur de domaine nous confirme que la version du dossier SYSVOL présentée aux postes clients est toujours celle répliquée par le mécanisme FRS.

Dans le prochain billet, nous entrerons plus en détail sur le déroulement de la deuxieme étape, Redirected.

SCOM - Du rififi dans la console Web

Une des principales nouveautés introduites lors du passage de SCOM au mode Semi-Annuel (SAC, versions 1801 et ultérieures) est la refonte complète de la console Web, intégralement en HTML5.

Malheureusement, cette innovation ne s’est pas faite sans quelques regrettables accrocs, aussi bien lors de son installation que lors de son utilisation quotidienne.

Concernant l’installation, les utilisateurs forums technet et uservoice font état de problèmes récurrents, mais néanmoins assez aléatoires puisque deux serveurs installés par la même personne, le même jour, sur des VM identiques peuvent ne pas présenter les même problèmes :

  • L’option « Enable SSL » lors de l’installation n’active pas SSL dans les paramètres de IIS
  • Si SSL est activé dans IIS avant l’installation de SCOM et que « Enable SSL » est coché pendant l’installation, la console web n’est pas accessible en utilisant « use windows credential », mais elle l’est en réentrant les credentials manuellement
  • Si SSL est activé dans IIS avant l’installation de SCOM et que « Enable SSL » n’est pas coché pendant l’installation, la console web est accessible aussi bien en HTTP qu’en HTTPS
  • L’authentification ne fonctionne pas directement, il est nécessaire de réentrer ses credentials à moins de modifier l’ordre des providers d’authentification dans IIS afin de mettre NTLM en premier à la place de Negotiate.

 

Par ailleurs, une partie du contenu tel que les Dashboards, les vues Event… créés dans les versions précédentes de SCOM n’est plus accessible dans la nouvelle console Web.

« Heureusement », il est toujours possible d’accéder à l’ancienne console Web silverlight à l’adresse suivante : http://nomduserveur/Dashboard

De la même facon, les liens directs vers des alertes renvoient systématiquement vers la page d’accueil de la console web…

Bref, il reste encore du travail mais à n’en pas douter, la console web finira par remplacer la console lourde…. Un jour.

SCOM – Contournements du bug APM

Si vous gérez au quotidien un environnement SCOM, ou si vous suivez un tant soit peu l’actualité de cet outil, vous avez forcément déjà entendu parler du bug APM : depuis la sortie de SCOM 2016, lors du déploiement de l’agent, le module APM (application monitoring) est susceptible de provoquer le plantage de certains webservices hébergés dans IIS, même lorsque la fonctionnalité APM est désactivée.

Cela peut évidemment avoir un impact conséquent lorsqu’il s’agit de webservices utilisés pour une application critique en production…

Jusqu’ici (et donc depuis presque 3 ans…), Microsoft s’est contenté d’indiquer avoir constaté le problème et l’avoir corrigé « en partie » au fil des mises à jour de SCOM 2016. Cette « partie » est manifestement insuffisante, puisque le problème persiste et oblige à la plus grande vigilance lors du déploiement d’un nouvel agent puisque seule l’installation manuelle avec l’option NOAPM=1 permet de se prémunir à coup sûr du problème.

Avec la sortie de SCOM 1807, Microsoft propose enfin un contournement industrialisable à défaut d’une correction : le changelog indique en effet qu’il est désormais possible de pousser l’agent sans le module APM, que ca soit via la console ou via powershell :

 

Install-SCOMAgent -DNSHostName “nomduserveur.local” -PrimaryManagementServer $PrimaryMS –NoAPM

 

Un second contournement est proposé sur certains blogs ( par exemple https://blogs.technet.microsoft.com/hybridcloud360/2018/06/29/scom-and-apm-the-simplest-workaround/ qui fournit de nombreux détails) :

Il semble en effet que cela ne soit pas le module APM de SCOM 2016 en lui-même qui pose problème, mais plutôt l’ajout du paramètre EnableRTIA Profiler à la règle Apply APM Agent configuration  contenue dans le Management Pack Microsoft.SystemCenter.Apm.Infrastructure ; ce qui explique d’ailleurs que le problème se produise également sur les serveurs disposant toujours d’un agent SCOM 2012 R2 lorsque le reste de l’environnement SCOM a été mis à jour en version 2016 ou ultérieure.

Il suffit donc d’overrider cette règle pour passer le paramètre EnableRTIA Profiler à False, et le problème disparait !

Prenez cependant bien le temps de tester ceci dans votre environnement, il est tout à fait possible qu’il ne s’agisse là encore que d’un contournement partiel…

SCOM - Déplacer le rôle Reporting

Lors du déplacement du rôle Reporting vers un nouveau serveur SSRS pour le compte d’un client, je me suis heurté à quelques problèmes et interrogations pour lesquelles les réponses n’étaient pas toujours très claires ou accessibles.

On retrouve par exemple un certain nombre de billets de blogs ou de posts sur les forums technet qui indiquent qu’il n’est pas possible de déplacer la base de données utilisée par SSRS, et donc pas possible de conserver facilement tous les rapports personnalisés et planifiés.
Il est en réalité parfaitement possible de procéder à une nouvelle installation de SCOM Reporting Services sur un SSRS vierge puis de restaurer la base du précédent SSRS, à condition de bien réaliser les opérations dans cet ordre :

  • Sur l’ancien serveur de reporting, sauvegarder les bases ReportServer et ReportServerTempDb (noms par défaut) ainsi que la clé de chiffrement de SSRS et le fichier config
  • Installer SSRS sur le nouveau serveur
  • Installer le rôle SCOM Reporting sur le serveur
  • Restaurer les bases ReportServer et ReportServerTempDb ainsi que la clé de chiffrement
  • Reconnecter SSRS aux bases restaurées
  • Reprendre les paramètres dans web.config

 

Un nouveau problème peut survenir dans la foulée : si le serveur SSRS d’origine exécutait une licence supérieure de SSRS (par exemple Datacenter alors que le nouveau serveur SSRS ne dispose que d’une licence Standard), un message d’erreur vous accueillera lorsque vous tenterez de vous connecter au portail :

 

La solution la plus logique serait de supprimer toute référence à l’ancien serveur dans l’onglet Scale-Out de la console SSRS, mais malheureusement cela ne fonctionne pas.

Il est alors nécessaire de passer directement par l’édition de la table dbo.Keys dans la base ReportServer pour en retirer toute référence à l’ancien serveur en supprimant la ligne correspondante :

DELETE FROM [ReportServer].[dbo].[Keys]

WHERE MachineName = 'AncienServeur'

Redémarrez ensuite SSRS, et confirmez que le portail fonctionne maintenant bien et que vous pouvez y retrouver toutes vos personnalisations antérieures !