PI Services

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()

Dans l’exemple suivant, Le script transfert les extracts scom du précedent article (https://blog.piservices.fr/post/2018/09/27/Script-Powershell-Extract-SCOM-to-CSV) vers un partage unix en utilisant les commandes du module Posh SSH.

Pour plus d’information sur le module Posh-SSH:

https://github.com/darkoperator/Posh-SSH

https://www.it-connect.fr/posh-ssh-connexion-ssh-depuis-powershell-sous-windows/

### TRANSFER CSV FILES THROUGH SFTP TO UNIX SHARE ###

# Requirement: POSH SSH Powershell Module (https://github.com/darkoperator/Posh-SSH)


param(
$UnixServ = ("MyLinuxSrv1","MyLinuxSrv2"),
$FilePath="D:\*.csv",
$SftpPath = "/home/myself/scomextract",
$FileToKeepCount = 2
)

$ScriptName = "SendCSVBySftp.ps1"


$SshModuleFile = "D:\Posh-SSH-master.zip"
$PSModulePath = "$($env:WINDIR)\system32\WindowsPowerShell\v1.0\Modules"



#FUNCTIONS

#Check for the existence of an event source with script name in operation manager eventlog to log some events 
         Function NewEventSource { 
         if(!(Test-Path "HKLM:\SYSTEM\CurrentControlSet\services\eventlog\Operations Manager\$ScriptName")) 
         { 
         New-EventLog -LogName "Operations Manager" -Source $ScriptName 
         }
         } 

#END FUNCTIONS

# LOG THE EXECUTION OF SCRIPT
$Message = "Execution of $ScriptName script"
write-host $Message
NewEventSource
Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1000 -EntryType Information -Message "$Message"



# Get the credentials from the previously secured passfile.txt
$CredPath = "D:\passfile.txt"
if (!(Test-Path $CredPath))
    {
    $message = "Credential secured file is not present - Unable to authenticate"
    Write-Host -F Red $message
    NewEventSource
    Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1001 -EntryType Warning -Message $message
    }


# Import the credential file
$Credential = Import-Clixml -Path $CredPath



# Check that $PSModulePath path exist
if (!(Test-Path $PSModulePath))
    {
    $message = "$PSModulePath path doesn't exist"
    Write-Host -F Red $message
    NewEventSource
    Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1002 -EntryType Warning -Message $message
    exit 1
    }


# Check if module has already been installed, and if not, install it as $PSModulePath+"\Posh-SSH"
If (!(Test-Path ($PSModulePath+"\Posh-SSH")))
            
            {


            #Unzip the SSH Powershell Module to Standard Module Path

            $shell_app=new-object -com shell.application
            $zip_file = $shell_app.namespace($SshModuleFile)
            Write-Host "Uncompressing the Zip file to $($PSModulePath)" -ForegroundColor Cyan
            $destination = $shell_app.namespace($PSModulePath)
            $destination.Copyhere($zip_file.items(), 0x10)


            # Rename the SSH Module Folder
            Write-Host "Renaming folder" -ForegroundColor Cyan
            Rename-Item -Path ($PSModulePath+"\Posh-SSH-master") -NewName "Posh-SSH" -Force

            Write-Host "Module has been installed" -ForegroundColor Green

            }


# Import of SSH Module
Write-Host -F Cyan "SSH Powershell Module already installed"
Write-Host -F Cyan "Import of SSH Powershell Module..."
Import-Module -Name posh-ssh


$UnixServ | foreach {

    # Establish the SFTP connection
    $SftpSession = New-SFTPSession -ComputerName $_ -Credential $Credential -AcceptKey



    # Check that $SftpPath exist
    if (!(Test-SFTPPath -SessionId $SftpSession.SessionId -Path "/$_$SftpPath"))
        {
        $message = "Unable to find `"/$_$SftpPath`" path"
        Write-Host -F Red $message
        NewEventSource
        Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1003 -EntryType Warning -Message $message
        exit 1
        }


        # Upload each file to the SFTP path
        try
        {
        Get-ChildItem -Path $FilePath | foreach {Set-SFTPFile -SessionId $SftpSession.SessionId -LocalFile $_ -RemotePath $SftpPath -Overwrite}
        }
        catch
        {
        $message = "Error during Sftp transfer To `"/$_$SftpPath`" path"
        Write-Host $message
        NewEventSource
        Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1004 -EntryType Warning -Message $message
        exit 1
        }


# Check that files are effectively present on sftp path
Get-ChildItem -Path $FilePath | foreach {

If (!(Test-SFTPPath -SessionId $SftpSession.SessionId -Path "$SftpPath/$($_.Name)"))
    {
    $message = "KO - The $($_.Name) file has not been copied on $($SftpSession.Host)$SftpPath"
    Write-Host -F Red $message
    NewEventSource
    Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1005 -EntryType Warning -Message $message
    exit 1
    }
    Else
    {
    $message = "OK - The $($_.Name) file has well been copied on $($SftpSession.Host)$SftpPath"
    Write-Host -F Green $message
    NewEventSource
    Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1006 -EntryType Information -Message $message
    }

}

}


#Delete older remote files
Get-SFTPSession | foreach {
$FileToDelete = Get-SFTPChildItem -SessionId ($_.SessionId) -Path $SftpPath | Where-Object {$_.fullname -like "*.csv"} | sort lastwritetime | select -First $FileToKeepCount
$FileToDelete
}




# Remove SftpSessions
Get-SFTPSession | foreach {Remove-SFTPSession -SessionId ($_.SessionId)}

Le script suivant extrait les agents, management servers et gateways vers un fichier CSV en ne conservant que le plus recent.

Decommentez la section <# + $datetime#> pour ajouter au nom du fichier, la date de création.

#############################################################
### EXTRACT OF ALL AGENTS MONITORED BY SCOM TO A CSV FILE ###
#############################################################



Param(
[Parameter(Mandatory=$true)]$MS,
[Parameter(Mandatory=$true)]$OutPutPath
)

$ScriptName = "ExtractAssetFromSCOM.ps1"

#FUNCTIONS

#Check for the existence of an event source with script name in operation manager eventlog to log some events 
         Function NewEventSource { 
         if(!(Test-Path "HKLM:\SYSTEM\CurrentControlSet\services\eventlog\Operations Manager\$ScriptName")) 
         { 
         New-EventLog -LogName "Operations Manager" -Source $ScriptName 
         }
         } 

#END FUNCTIONS

# LOG THE EXECUTION OF SCRIPT
$Message = "Execution of $ScriptName script"
write-host $Message
NewEventSource
Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1000 -EntryType Information -Message "$Message"


#Import of SCOM PS Module
try
{
Import-Module -Name OperationsManager -ErrorAction stop
}
catch
{
$Message = "Error during import of SCOM PS Module"
write-host -ForegroundColor red $Message
NewEventSource
Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1001 -EntryType Warning -Message "$Message"
exit 1
}

#Connection to $MS
try
{
$ScomCon = New-SCOMManagementGroupConnection -ComputerName $MS -PassThru
}
catch
{
$Message = "Error during connection to $MS - Check the credentials used"
write-host -ForegroundColor red $Message
NewEventSource
Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1002 -EntryType Warning -Message "$Message"
exit 1
}


$MGroup = $ScomCon.ManagementGroupName

#AGENT INFO SECTION

        #$Agents - ALL AGENTS + ALL MS AND GW, SORTED BY DISPLAYNAME
        try
        {
        $Agents = Get-SCOMAgent | select DisplayName -ExpandProperty DisplayName 
        $Agents += Get-SCOMManagementServer | select DisplayName -ExpandProperty DisplayName
        $Agents = $Agents | Sort-Object -Property DisplayName
        }
        catch
        {
        $Message = "Error during retrieve of agents list"
        write-host -ForegroundColor red $Message
        NewEventSource
        Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1003 -EntryType Warning -Message "$Message"
        exit 1
        }



                
   # Initiate the table    
   $export_array = @();

   # Fill of table
   foreach ($Ag in $Agents)
   {
   $export_array += @($Ag+','+$MGroup);
   }


# Naming of CSV file
$datetime = Get-Date -Format "yyyy.MM.dd_HH-mm-ss";
$file_name = "Extract_SCOM_$MGroup`_"<# + $datetime#> + ".csv"; # Uncoment "<# + $datetime#>" to add creation date of file
$file_path = "$OutPutPath\" + $file_name;


# Fill of CSV File
foreach($ColItem in $export_array)  
{  
  $csv_string = "";
  foreach($item in $ColItem)
  {
    $csv_string = $csv_string + $item ;
  }
  [array]$content += $csv_string
}

Set-Content $file_path $content


# Check of File Creation
if (Test-Path $file_path)
{
  $Message = "Creation of CSV file`"$file_path`" OK!"
  write-host -ForegroundColor Green $Message
  NewEventSource
  Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1004 -EntryType Information -Message "$Message"
  
}
else
{
  $Message = "Creation of CSV file KO!"
  write-host -ForegroundColor Red $Message
  NewEventSource
  Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1005 -EntryType Warning -Message "$Message"
  exit 1
}

Write-Host $file_name
Write-Host $MGroup


# Deletion of oldest files (keep only the newest)

Write-Host "...Deletion of oldest files..."
if ($(Get-ChildItem "$OutPutPath\*SCOM_$MGroup*").count -gt 1)
    {
    $Newest = Get-ChildItem "$OutPutPath\*SCOM_$MGroup*" | sort creationtime | select -last 1
    Get-ChildItem "$OutPutPath\*SCOM_$MGroup*" | Where-Object {$_.Name -ne $Newest.Name} | Remove-Item
    }
    

Bonjour à tous,

Aujourd'hui nous abordons la partie 2 de notre série sur la migration du dossier SYSVOL du mécanisme FRS vers DFS-R, elle sera consacrée au déroulement global de celle-ci.

Etats de migration

Etats de migration globaux et locaux

Il existe deux types d'états de migration :

• Global : Les commandes pour initier les étapes de migration vont agir sur le PDC. Une fois que l'état de migration a changé sur le PDC, il est défini au niveau du domaine Active Directory, d'oû sa portée globale.
• Local: Une fois que l'état de migration a été défini sur le PDC, chaque contrôleur de domaine annexe va évaluer son propre état de migration par rapport à celui du domaine et va effectuer les opérations demandées si les deux ne correspondent pas. D'ou un état de migration local propre à chaque contrôleur de domaine.

Déroulement de la migration

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

Au niveau de chaque controleur de domaine, il existe 6 états locaux qui sont les suivants :

Schématiquement, nous pouvons résumer la migration (et un retour arrière) comme ceci :

Remarques importantes

• Un niveau fonctionnel de forêt/domaine AD 2008 minimum est nécéssaire pour démarrer la migration.
• Une copie du dossier original SYSVOL, appelée SYSVOL_DFSR et située au même endroit que le dossier SYSVOL orinigal, est utilisée en parallèle par DFS-R pour la réplication des données.
• La commande dfsrmig est utilisée pour configurer les états de migration et est à utiliser de préférence sur le PDC du domaine conerné, ou tout du moins sur n'importe quel contrôleur de domaine accéssible en écriture (hors RODC donc).
• Le retour arrière n'est possible que jusqu'à l'état 2. Pas de retour arrière possible une fois le domaine en état 3.
• Il faut vérifier manuellement l'état de réplication du dossier SYSVOL à chaque étape. Il n'y a pas de vérification automatique de l'intégrité du dossier SYSVOL lors de l'utilisation de la commande dfsrmig.
• Il n'est pas possible de renommer un contrôleur de domaine pendant toute la durée de la migration.
• Toute modification de GPOs, ou d'ajout/suppression de contrôleur de domaine durant la durée de la migration est fortement déconseillée, mais reste toutefois possible.
• Un contrôleur de domaine peut être éteint et allumé de nouveau pendant la migration.
• Les états de transitions sont plus longs pour les RODCs (c'est le PDC qui fait les opérations pour eux) et les sites distants.

Commandes utiles

• dfsrmig /GetGlobalState : Indique l'état de migration du dossier SYSVOL au niveau du domaine AD
• dfsrmig /SetGlobalState Numero_etat_de_migration (0,1,2,3) : Configure l'état de migration du dossier SYSVOL au niveau du domaine AD
• dfsrmig /GetMigrationState : Indique l'état de migration du dossier SYSVOL pour tous les contrôleurs de domaine du domaine AD
• repadmin /syncall /AeD : Force la syncronisation de tous les contrôleurs de domaine AD

Dans le prochain billet, nous entrerons plus en détail sur le déroulement de la première étape, Prepared.

Bonjour à tous,

Aujourd'hui nous commençons une série de billets consacrée à la migration du dossier SYSVOL du mécanisme de réplication FRS vers DFS-R.

Historique

FRS (File Replicating System) est un mécanisme de réplication de fichiers introduit avec Windows 2000 et à été utilisé au sein d'Active Directory pour la réplication du dossier SYSVOL.

Avec l'arrivée de Windows Server 2008, Microsoft a introduit une nouvelle technologie appellée DFS (Distributed File System). Cette technologie se décline en deux composants : DFS-N (qui gère les espaces de noms de dossiers partagés) et DFS-R (qui gère la réplication entre des dossiers).
Microsoft a rendu possible l'utilisation de DFS-R pour la réplication du dossier SYSVOL depuis Windows Server 2008 (et son niveau fonctionnel de forêt/domaine correspondant).

A partir de Windows Server 2008 R2, Microsoft ne permet plus l'utilisation de la technologie FRS pour la réplication de dossiers mais pour des raisons de compatibilité laisse cette possiblité pour le dossier SYSVOL jusqu'à Windows Server 2012 R2 (et son niveau fonctionnel de forêt/domaine correspondant).

Pourquoi migrer ?

Le mécanisme FRS n'est plus supporté par aucun contrôleur de domaine à partir de Windows Server 2016.

Plus précisemment, même si vous voulez ajouter un contrôleur de domaine sous OS Windows Server 2016 et garder un niveau fonctionnel de forêt/domaine Windows Server 2012 R2, ce n'est pas possible car Microsoft à tout simplement retiré les binaires FRS de l'OS ! (ce n'était pas le cas jusqu'à la RS3).

Même si vous avez effectué une montée du niveau fonctionnel d'une forêt AD, la migration de FRS vers DFS-R n'est pas éffectuée automatiquement.

DFS-R est le mécanisme de réplication utilisé par défaut pour le dossier SYSVOL depuis le niveau fonctionnel de forêt/domaine AD 2008 pour toute création d'une nouvelle forêt AD avec un niveau fonctionnel de forêt/domaine 2008. Si vous êtes dans ce cas, alors il n'y a pas de migration à prévoir.

En revanche, si vous avez hérité d'une forêt AD historique remontant à Windows Server 2003 et que vous n'avez éffectué uniquement que des montées de niveau fonctionnel de forêt/domaine AD sans vous préoccuper du SYSVOL, il y a de fortes chances pour que FRS soit toujours utilisé pour sa réplication.

Comment vérifier si FRS est toujours utilisé ?

Il faut passer par la console ADSIEdit.

Connectez-vous au Default Naming Context (Contexte de nommage par défaut).

Dans l'aborescence, allez dans CN=votredomaine,DC=local -> CN=System -> CN=DFSR-GlobalSettings. Ouvrez les propriétés de CN=DFSR-GlobalSettings.

Cherchez la propriété msDFSR-Flags et notez la valeur présente.

Si la valeur est nulle, alors c'est FRS qui est actuellement utilisé pour la réplication du dossier SYSVOL.

Si la valeur est 48, alors c'est DFS-R qui est actuellement utilisé pour la réplication du dossier SYSVOL.

Si la valeur est 0, 16 ou 32 alors c'est que la migration du mécanisme de réplication est en cours (0 correspond à l'état Start, 16 correspond à l'état Prepared, 32 correspond à l'état Redirected et 48 correspond à l'état Eliminated).

Dans le prochain billet, nous aborderons la procédure de migration du dossier SYSVOL du mécanisme FRS vers DFS-R.