Bonjour à tous,

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

En théorie

Déroulement de la migration

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

Particularités

• En arrière-plan, le mécanisme de réplication DFS-R réplique une copie du dossier SYSVOL (cette copie étant devenue depuis l'étape Redirected celle utilisée par les services AD DS), la version répliquée par le mécanisme FRS est supprimée.
• En façade, c'est le dossier SYSVOL répliqué par le mécanisme DFS-R qui est présenté aux postes clients via les partages NETLOGON et SYSVOL

• Tout retour arrière est impossible une fois cette etape éffectuée.
• Il convient de vérifier que la copie du dossier SYSVOL répliquée par le mécanisme DFS-R est intègre avant de supprimer la version répliquée par FRS. A toute fin utile, on pourra éxécuter un Rapport de Propagation de la Réplication DFS dans la console DFS Management pour le groupe de réplication Domain System Volume.
• Les commandes de migration sont à lancer depuis le contrôleur de domaine possédant le rôle PDC.

En pratique

Etat Redirected

Si l'étape précédente a été correctement réalisée, l'état de migration au niveau du domaine AD ainsi que celui de tous les contrôleurs de domaine doit être Redirected.

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 Eliminated.

Passage vers l'état Eliminated

Etat global (Domaine AD) : dfsrmig /setglobalstate 3

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 Eliminated 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 à Eliminated. Celui-ci reste donc inchangé.

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

La console DFS Management pour le groupe de réplication Domain System Volume nous confirme que la version du dossier SYSVOL présentée aux postes clients est celle répliquée par le mécanisme DFS-R.

Contexte

Après la migration d'un serveur Mailbox virtualisé vers un nouvel hoster, la réplication des bases Exchange ne fonctionne plus et le message d'erreur suivant est présent lorsque la commande Test-ReplicationHealth est utilisée :

The log copier was unable to continue processing for database DAG\MBX because an error occured on the target server: Continuous replication - block mode has been terminated. Error : the log file sector size does not match the current volume's sector size (-546)

Problèmatique

Ce problème est causé par un changement de la taille de secteur physique des disques sur lesquels les bases sont. Le problème intervient lorsque le nouvel hoster est plus récent que l'ancien et qu'il ne possède pas le même firmware pour le stockage. Exchange n'est pas en capacité de supporter automatiquement le changement d'un disque avec des secteurs de 512 bytes vers un disque avec des secteurs de 4096 bytes.

Pour vérifier cela, lancer la commande suivante : fsutil fsinfo ntfsinfo <Disk>

On remarque que le paramètre Bytes Per Physical Sector n'est pas supporté.

Solution

La solution pour reprendre la synchronisation des bases est de désactiver la réplication granulaire dans un premier temps. Pour cela, créer la clé de registre DWORD suivante avec la valeur 1 :

HKLM\Software\Microsoft\ExchangeServer\v14\Replay\Parameters\DisableGranularReplication

Après avoir redémarré le serveur, si on relance la commande fsutil fsinfo ntfsinfo <Disk> le paramètre Bytes Per Physical Sector accepte désormais les secteurs en 4096 bytes.

A la suite de ce changement, la réplication fonctionne de nouveau correctement.

Remarque : Attention, Microsoft ne supporte pas que la méthode de réplication ne soit pas la même sur l'ensemble des noeuds d'un DAG. Il est donc nécessaire de revenir en arrière une fois le changement effectué ou de désactiver la réplication granulaire sur l'ensemble des noeuds.

L'ensemble de ce problème est expliqué plus en détails sur le lien TechNet : https://blogs.technet.microsoft.com/exchange/2013/04/24/exchange-2010-database-availability-groups-and-disk-sector-sizes/

Bonjour à tous,

Aujourd'hui nous abordons la partie 4 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 Redirected.

En théorie

Déroulement de la migration

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

Particularités

• En arrière-plan, le mécanisme de réplication DFS-R réplique une copie du dossier SYSVOL, toujours en parallèle de la version répliquée par le mécanisme FRS.
• En façade, c'est le dossier SYSVOL répliqué par le mécanisme DFS-R qui est présenté aux postes clients via les partages NETLOGON et SYSVOL

• Un retour arrière reste possible (il faut utiliser la commande dfsrmig /setglobalstate X où X est le numéro de l'étape voulue)
• Il convient de vérifier que la copie du dossier SYSVOL répliquée par le mécanisme DFS-R est intègre avant d'effectuer la bascule vers celle-ci. A toute fin utile, on pourra éxécuter un Rapport de Propagation de la Réplication DFS dans la console DFS Management pour le groupe de réplication Domain System Volume.
• 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 Prepared

Si l'étape précédente a été correctement réalisée, l'état de migration au niveau du domaine AD ainsi que celui de tous les contrôleurs de domaine doit être Prepared.

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 Redirected.

Passage vers l'etat Redirected

Etat global (Domaine AD) : dfsrmig /setglobalstate 2

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 Redirected 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 à Redirected. Celui-ci reste donc inchangé.

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

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 celle répliquée par le mécanisme DFS-R.

Dans le prochain billet, nous entrerons plus en détail sur le déroulement de la troisième étape, Eliminated.

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 :

Particularités

• 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

• 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

• 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

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.

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.

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…

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 !

Le script suivant supprime tout les overrides correspondant a une propriété donné, pour un ou plusieurs monitors.

### DELETE OVERRIDES FROM MONITORS ###

Param(
$MS
,$cred = $(Get-Credential "MyDomain\Myself")
,$targetMonitorsPatern = "Check My App*"
,$OverrideProp = "GenerateAlert"
)

# Import of SCOM module
try
{
Import-Module -Name OperationsManager -ErrorAction stop
}
catch
{
write-host -ForegroundColor red "Error during import of SCOM module"
}

# Connection to management server $MS
New-SCOMManagementGroupConnection -ComputerName $MS -Credential $cred


 #The monitors 
 $targetMonitors = Get-SCOMMonitor -DisplayName $targetMonitorsPatern


 foreach ($Monitor in $targetMonitors) 
 {
 [array]$OverrideToDelete += Get-SCOMOverride -Monitor $Monitor | Where {$_.Property -eq $OverrideProp} 
 }


 $OverrideToDelete | foreach {

 [array]$targetMP += $_.GetManagementPack()
 $targetMP.FindManagementPackElementByName($_.Name).status='PendingDelete'
 $targetMP.AcceptChanges()
 }

Le script suivant crée un override pour un ou plusieurs monitors, en ciblant une instance de la classe cible, correspondant a un nom de machine donné en paramètre.

### CREATE OVERRIDES FOR MONITORS, FOR SPECIFIC INSTANCE OF TARGET CLASS ###

Param(
$MS
,$cred = $(Get-Credential "MyDomain\Myself")
,$targetMPName = "My App - Overrides"
,$TargetContextComputer = "MyServer.MyDomain.home"
,$targetMonitorsPatern = "Check My App*"
,$OverrideProp = "Enabled"
,$OverrideValue = "True"
,$OverrideSuffix = ".Override_$OverrideProp`_$TargetContextComputer"
)

# Import of SCOM module
try
{
Import-Module -Name OperationsManager -ErrorAction stop
}
catch
{
write-host -ForegroundColor red "Error during import of SCOM module"
}

# Connection to management server $MS
New-SCOMManagementGroupConnection -ComputerName $MS -Credential $cred


# The target MP
 $targetMP = Get-SCOMManagementPack -DisplayName $targetMPName

 # The monitors 
 $targetMonitors = Get-SCOMMonitor -DisplayName $targetMonitorsPatern


foreach ($Monitor in $targetMonitors)
{

    if( $Monitor.AlertSettings.AlertOnState -ne $null)

    {
    $Target= Get-SCOMClass -id $Monitor.Target.Id 
    $TargetContextInstance = Get-SCOMMonitoringObject -Class $Target | Where-Object {$_.'[Microsoft.Windows.Computer].PrincipalName'.value -eq $TargetContextComputer}   # Get the Monitoring Object that match the $TargetContextComputer

    # Name of the override
    $overridename=$Monitor.name+$OverrideSuffix

    # Create Override and fill its properties
    $override = New-Object Microsoft.EnterpriseManagement.Configuration.ManagementPackMonitorPropertyOverride($targetMP,$overridename)
    $override.Monitor = $Monitor
    $override.Property = $OverrideProp
    $override.Value = $OverrideValue
    $override.Context = $Target
    $override.ContextInstance = $TargetContextInstance.Id
    $override.DisplayName = $overridename
    }

}

# Verify and commit the change
$targetMP.Verify()
$targetMP.AcceptChanges()

Le script suivant crée un override pour un groupe de monitor en ciblant toute la classe cible du monitor.

### CREATE OVERRIDES FOR MONITORS, FOR ENTIRE MONITOR TARGET CLASS ###

Param(
$MS
,$cred = $(Get-Credential "MyDomain\Myself")
,$targetMPName = "My App - Overrides"
,$targetMonitorsPatern = "Check My App*"
,$OverrideProp = "GenerateAlert"
,$OverrideValue = "false"
,$OverrideSuffix = ".Override_$OverrideProp`_WholeTarget"
)

# Import of SCOM module
try
{
Import-Module -Name OperationsManager -ErrorAction stop
}
catch
{
write-host -ForegroundColor red "Error during import of SCOM module"
}

# Connection to management server $MS
New-SCOMManagementGroupConnection -ComputerName $MS -Credential $cred



# The target MP
$targetMP = Get-SCOMManagementPack -DisplayName $targetMPName

# The monitors 
$targetMonitors = Get-SCOMMonitor -DisplayName $targetMonitorsPatern


foreach ($Monitor in $targetMonitors)
{

    if($OverrideProp -eq "GenerateAlert" -AND  $OverrideValue -eq "false" -AND $Monitor.AlertSettings.AlertOnState -ne $null) # If we want to change the "GenerateAlert" Property to "false", we check also that Alert is activated

    {
    $Target= Get-SCOMClass -id $Monitor.Target.id
    $overridename=$Monitor.name+$OverrideSuffix

    $override = New-Object Microsoft.EnterpriseManagement.Configuration.ManagementPackMonitorPropertyOverride($targetMP,$overridename)
    $override.Monitor = $Monitor
    $override.Property = $OverrideProp
    $override.Value = $OverrideValue
    $override.Context = $Target
    $override.DisplayName = $overridename
    }

}
$targetMP.Verify()
$targetMP.AcceptChanges()