Si il y a bien une chose que j'essaie de pousser dans un environnement Active Directory, c'est de supprimer les comptes avec un mot de passe qui n'expire jamais, utilisés pour exécuter des tâches planifiées; pour les remplacer par des gMSA.

Souvent mal appréhendé, je vais ici vous montrer qu'il n'y a quasiment pas de différence dans l'utilisation.

Créer une tâche

Via GUI

Pour créer une tâche en mode graphique, on ne change pas les habitudes.

Dans un premier temps on lance le Task Scheduler

Puis on créé un tâche que l'ion va nommer

On lui définit ses paramètres

Bon jusque la rien de différent de ce que vous avez l'habitude de faire.

Passons donc à la suite, éditez la tâche.

Et à partir d'ici remplaçons notre compte par le gMSA.

Donc on sélectionne "Change User or Group..." et on s'assure de rechercher sur le domaine donc on sélectionne "Location"

On sélectionne "Entire Directory" et on valide

à partir de la on va sélectionner "Object Types..."

Et tout désélectionner  sauf "Service Accounts" puis on valide

Enfin on recherche son gMSA et on valide

Et voilà, comme quoi il n'y a rien de plus simple car, on s'évite même de devoir gérer les identifiants du compte de service.

Via Powershell

$TaskAction = New-ScheduledTaskAction -Execute C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe  -Argument "-File C:\Temp\ImportPfx.ps1"
 
$TaskTrigger = New-ScheduledTaskTrigger -At 00:00 -Once # vous pouvez utiliser d'autre valeurs selon vos besoin Par exemple Daily
 
$TaskPrincipal = New-ScheduledTaskPrincipal -UserID Lab\gMSA01$ -LogonType Password
 
Register-ScheduledTask MygMSATask –Action $TaskAction –Trigger $TaskTrigger –Principal $TaskPrincipal

Modifier un tâche

Via GUI

Souvent, la première fois qu'on y fait face c'est un peu déroutant, car lors de la modification de la tâche le popup demandant les identifiants arrive.

Pour éviter cela rien de plus simple, ouvrez votre tâche planifié.

Modifiez vos paramètres, par exemple ici nouds allons modifier l'heure d'exécution.

Une fois modifié, nous validons avec "Ok", puis nous retournerons sur le menu "General"

Puis comme nous l'avons fais lors de la  création de la tâche planifiée, donc on sélectionne "Change User or Group..." et on s'assure de rechercher sur le domaine donc on sélectionne "Location"

On sélectionne "Entire Directory" et on valide

à partir de la on va sélectionner "Object Types..."

Et tout désélectionner  sauf "Service Accounts" puis on valide

Enfin on recherche son gMSA et on valide

Et enfin on sélectionne "Ok"

Via Powershell

$Task = Get-ScheduledTask -TaskName MygMSATask
$Time = New-ScheduledTaskTrigger -At 21:00 -Once
$TaskPrincipal = New-ScheduledTaskPrincipal -UserID Lab\gMSA01$ -LogonType Password

Set-ScheduledTask -TaskName $Task.TaskName -Trigger $Time -Principal $TaskPrincipal

Windows Error reporting aussi abrégé WER a été introduit depuis Windows Vista et permet de générer un fichier de dump lorsqu'un processus crash. C'est particulièrement utile car tous les processus ne génèrent pas forcément leur propre logs.

Identifier le processus fautif

L'identification du processus qui crash se fait à l'aide du gestionnaire d'événement ou event viewer en anglais. Il permet d'accéder à plusieurs informations du crash tel que l'heure et le nom du processus en erreur.

Dans l'exemple suivant, on voit que c'est une défaillance du process lsass.exe qui fait planter la machine et le module responsable du crash de lsass.exe est ntdll.dll

Activer la génération de crash dump pour le processus en erreur

1. Ouvrir l'éditeur de registre regedit sur le serveur qui est concerné par le crash
2. Naviguer jusqu'à HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
3. Créer une nouvelle Key qui a comme valeur le nom du processus défaillant, dans notre exemple lsass.exe
4. Dans la précédente clé, créer un premier DWORD (32-bit)
   1. Name : DumpCount
   2. Valeur : le nombre de crash dump a sauvegarder, par exemple 5
5. Créer un deuxième DWORD (32-bit) value
   1. Name : DumpType
   2. Valeur : 2 cela permet de générer un full crash dump, celui-ci est le plus complet
6. Créér une String value
   1. Name : DumpFolder
   2. Valeur : le chemin complet du dossier qu'il faudra créer et qui contiendra les dumps, par exemple c:\temp
7. Créer un dossier temp dans le disque C:

Récupérer le fichier de log et l'analyser

Au prochain crash du processus, un fichier de log sera créé dans le dossier choisi dans la base de registre.

Pour pouvoir lire les fichiers de log, il est nécessaire d'installer un outil tel que WinDbg

Supprimer la génération de fichiers de dump

Pour supprimer la génération de log, il faut supprimer la clé précédemment créée dans la base de registre, dans notre exemple cela reviendrait à supprimer la clé lsass.exe

Pour aller plus loin

Documentation officielle Microsoft sur l'activation de Windows Error Reporting

Ce script permet de désactiver les éléments non essentiels au serveur lors de son installation.

##################################
# Step 1 : Network configuration #
##################################
Write-Host 'Network configuration' -ForegroundColor Green
Write-Host 'WINS configuration' -ForegroundColor Gray
$Arguments = New-Object System.Collections.Hashtable
$Arguments.Add('DNSEnabledForWINSResolution', $false)
$Arguments.Add('WINSEnableLMHostsLookup', $false)

$ErrorCode = (Invoke-CimMethod -ClassName Win32_NetworkAdapterConfiguration -MethodName EnableWINS -Arguments $Arguments).ReturnValue
If ($ErrorCode -gt 0) {
	Write-Host 'Error when disabling WINS' -ForegroundColor Red
    }

############################
# Step 2 : Remove Features #
############################

Write-Host 'Features configuration' -ForegroundColor Green
$Features = @(
    'FS-SMB1'
    )
$Features | ForEach-Object { 
    $CurrentFeature = $_
    Try {
        Uninstall-WindowsFeature -Name $CurrentFeature -ErrorAction Stop
        }
    Catch {
        Write-Warning $($_)
        }
    # Release
    $CurrentFeature = $null
    }

######################################
# Step 3 : Disabling Scheduled Tasks #
######################################

Write-Host 'Scheduled Tasks configuration' -ForegroundColor Green
$ScheduledTasks = @(
    '*XblGameSaveTask*'
    '*XblGameSaveTaskLogon*'
    )
$ScheduledTasks | ForEach-Object {
    $CurrentScheduledTask = $_
    Try {
        Get-ScheduledTask -TaskName $CurrentScheduledTask | Disable-ScheduledTask -ErrorAction Stop | Out-Null
        }
    Catch {
        Write-Warning $($_)
        }
    $CurrentScheduledTask = $null
    }

################################
# Step 4: Windows Applications #
################################

Write-Host 'Windows Applications configuration' -ForegroundColor Green
$Apps = Get-AppxPackage -AllUsers | Where-Object {$_.NonRemovable -eq $false}
$Packages = Get-AppxProvisionedPackage -Online:$true

# Verifying if some Apps could be remove
If ($Apps.count -gt 0) {
    $Apps | ForEach-Object {
        $AppName = $_.Name
        Try {
            $Package = Get-AppxPackage -Name $AppName -ErrorAction Stop
            If ($Package) {
                Try {
                    # Remove App
                    Write-Host "Removing $AppName" -ForegroundColor Cyan
                    #Remove-AppPackage -Package $Package -ErrorAction Stop
                    $Package = $null
                    }
                Catch {
                    Write-Warning $($_)
                    }
                }
            Else {
                If ($Packages.Count -gt 0) {
                    # Remove the app with Online Package
                    $Package = $Packages.Where({$_.DisplayName -eq $AppName})
                    If ($Package) {
                        Try {
                            Write-Host "Removing $AppName" -ForegroundColor DarkCyan
                            Remove-AppxProvisionedPackage -PackageName $Package.PackageName -Online -ErrorAction Stop
                            }
                        Catch {
                            Write-Warning $($_)
                            }
                        }
                    }
                }
            }
        Catch {
            Write-Warning $($_)
            }
        # Release
        $AppName = $null
        }
    }

###################################
# Step 5 : OneDrive configuration #
###################################

Write-Host 'OneDrive configuration' -ForegroundColor Green
If (Get-Process -Name "*onedrive*") {
    Try {
        Get-Process -Name "*onedrive*" | Stop-Process -Force -ErrorAction Stop
        If (Test-Path -Path "$env:SystemRoot\SysWOW64\OneDriveSetup.exe") {
            Try {
                Start-Process -FilePath "$($env:SystemRoot)\SysWOW64\OneDriveSetup.exe" -ArgumentList '/uninstall' -ErrorAction Stop | out-Null
                }
            Catch {
                Write-Warning $($_)
                }
            }
        Elseif (Test-Path -Path "$env:SystemRoot\System32\OneDriveSetup.exe") {
            Try {
                Start-Process -FilePath "$($env:SystemRoot)\System32\OneDriveSetup.exe" -ArgumentList '/uninstall' -ErrorAction Stop | out-Null
                }
            Catch {
                Write-Warning $($_)
                }
            }
        }
    Catch {
        Write-Warning $($_)
        }
    }
Else {
    Write-Host "No Process OneDrive here" -ForegroundColor Cyan
    }

###################################
# Step 6 : Services configuration #
###################################

$services = @(
    'AppVClient';
    'AudioEndpointBuilder';
    'Audiosrv';
    'AxInstSV';
    'Browser';
    'bthserv';
    'CDPUserSvc';
    'CscService';
    'dmwappushservice';
    'FrameServer';
    'icssvc';
    'lfsvc';
    'lltdsvc';
    'MapsBroker';
    'NcbService';
    'NetTcpPortSharing';
    'OneSyncSvc';
    'PcaSvc';
    'PhoneSvc';
    'PrintNotify';
    'QWAVE';
    'RemoteAccess';
    'RmSvc';
    'SCardSvr';
    'ScDeviceEnum';
    'SensorDataService';
    'SensorService';
    'SensrSvc';
    'SharedAccess';
    'ShellHWDetection';
    'Spooler';
    'SSDPSRV';
    'stisvc';
    'TabletInputService';
    'tzautoupdate';
    'UevAgentService';
    'upnphost';
    'WalletService';
    'WiaRpc';
    'wisvc';
    'wlidsvc';
    'WpnService';
    'WSearch';
    'XblAuthManager';
    'XblGameSave'
    )

$services | Get-Service | Stop-Service -Force

$services | Get-Service | Set-Service -StartupType Disabled -Status Stopped

Try {
    Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NgcCtnrSvc" -Name "Start" -Value 0x4 -Force -ErrorAction Stop
    }
Catch {
    Write-Warning $($_)
    }
Try {
    Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NgcSvc" -Name "Start" -Value 0x4 -Force -ErrorAction Stop
    }
Catch {
    Write-Warning $($_)
    }
Try {
    Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\PimIndexMaintenanceSvc" -Name "Start" -Value 0x4 -Force -ErrorAction Stop
    }
Catch {
    Write-Warning $($_)
    }
Try {
    Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\UnistoreSvc" -Name "Start" -Value 0x4 -Force -ErrorAction Stop
    }
Catch {
    Write-Warning $($_)
    }
Try {
    Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\UserDataSvc" -Name "Start" -Value 0x4 -Force -ErrorAction Stop
    }
Catch {
    Write-Warning $($_)
    }
Try {
    Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\WpnUserService" -Name "Start" -Value 0x4 -Force -ErrorAction Stop
    }
Catch {
    Write-Warning $($_)
    }

$services2 = @(
    'NgcCtnrSvc';
    'NgcSvc';
    'PimIndexMaintenanceSvc';
    'UnistoreSvc';
    'UserDataSvc';
    'WpnUserService';
    )

$services2 | Get-Service | ft Name,StartType,Status

If (Test-Path -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NgcCtnrSvc_*") {
    Try {
        Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NgcCtnrSvc_*' -Name 'Start' -Value 0x4 -Force -ErrorAction Stop
        }
    Catch {
        Write-Warning $($_)
        }
    }


If (Test-Path -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NgcSvc_*") {
    Try {
        Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NgcSvc_*' -Name 'Start' -Value 0x4 -Force -ErrorAction Stop
        }
    Catch {
        Write-Warning $($_)
        }
    }


If (Test-Path -Path "HKLM:\SYSTEM\CurrentControlSet\Services\PimIndexMaintenanceSvc_*") {
    Try {
        Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\PimIndexMaintenanceSvc_*' -Name 'Start' -Value 0x4 -Force -ErrorAction Stop
        }
    Catch {
        Write-Warning $($_)
        }
    }


If (Test-Path -Path "HKLM:\SYSTEM\CurrentControlSet\Services\UnistoreSvc_*") {
    Try {
        Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\UnistoreSvc_*' -Name 'Start' -Value 0x4 -Force -ErrorAction Stop
        }
    Catch {
        Write-Warning $($_)
        }
    }


If (Test-Path -Path "HKLM:\SYSTEM\CurrentControlSet\Services\UserDataSvc_*") {
    Try {
        Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\UserDataSvc_*' -Name 'Start' -Value 0x4 -Force -ErrorAction Stop
        }
    Catch {
        Write-Warning $($_)
        }
    }


If (Test-Path -Path "HKLM:\SYSTEM\CurrentControlSet\Services\WpnUserService_*") {
    Try {
        Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\WpnUserService_*' -Name 'Start' -Value 0x4 -Force -ErrorAction Stop
        }
    Catch {
        Write-Warning $($_)
        }
    }

If (Test-Path -Path "HKLM:\SYSTEM\CurrentControlSet\Services\xbgm") {
    Try {
        Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\xbgm' -Name 'Start' -Value 0x4 -Force -ErrorAction Stop
        }
    Catch {
        Write-Warning $($_)
        }
    }

Quand on veut faire du ménage sur son WSUS et également dans la base de ce dernier, il peut s'avérer utile de supprimer les KB dont le statut est "IsDeclied".

Pour réaliser cela rien de plus simple que quelques lignes de Powershell et de la patience (beaucoup de patience si ça fait longtemps que cela n'a pas été fait).

Connexion

# Define Server Name
$WsusServer = "Mon-Server-WSUS"
# Define connection port
$WsusPort = "8530"

# Initiate Connection
[void][reflection.assembly]::loadwithpartialname("microsoft.updateservices.administration")
$Wsus = [microsoft.updateservices.administration.adminproxy]::getupdateserver($WsusServer,$false,$WsusPort)

# Verifying connection (Should be return the name of the wsus server)
$Wsus.name

Définition des Updates à supprimer

# List All Kb in WSUS database
$AllKb = $Wsus.GetUpdates()

# Filter on "IsDeclined" status
$IsDeclined = $AllKb.Where({$_.IsDeclined -eq $True})

Suppression des KB

# Delete KB
$IsDeclined | foreach {
    # Define Current Id
    $Id = $_.Id
    Try {
        $Wsus.DeleteUpdate($Id.UpdateId.ToString())
        }
    Catch {
        Write-Warning $($_)
        }
    # Release variable
    $Id = $null
    }

Cette commande est un peu longue mais si elle est exécutée régulièrement, la purge dure moins longtemps.

Vous venez de déployer un serveur WSUS, finir sa configuration et rattacher les premières machine à se dernier; mais lorsque vous vous rexonnectez sur le serveur afin d'exécuter la console "Windows Server Update Services" vous avez le droit au message d'erreur suivant :

La cause :

Bien souvent cette erreur est lié à IIS, je vous invite donc à exécuter "Internet Information Services (IIS) Manager" puis déroulez le serveur et sélectionnez "Application Pool", ici vous pourrez constater que le "WsusPool" est arrêté.

La solution :

Sélectionnez le et faite "Advanced Settings..." dans le volet de droite, sélectionnez le "Start Mode" pour le passer de "OnDemand" à "AlwaysRunning" puis validez en faisant "OK".

Démarrez le "WsusPool", puis vous pourrez fermer la console IIS.

NB : Tant que le serveur WSUS n'aura pas redémarrez la configuration du IIS ne sera pas effective (vous devrez relancez le "WsusPool" Manuellement à chaque nouvelle connexion au serveur).

Retournez dans la console "Windows Server Update Services" et faites "Reset Server Node"

Enjoy

Un environnement homogène avec des OS installé en Anglais, c'est la vision de notre éditeur préféré (je parle bien sur de Microsoft).

Dans la pratique on a pas toujours l'opportunité d'avoir tous les OS dans la même version et pire encore dans la même langue d'installation.

Quel impact ?

Même si pour certain, installer un OS en Français est plus "Confortable / facile d'administration", en terme de "recherche / résolution" d'incident on est quand même nettement moins bien aidé (entre les messages d'erreur qui ne veulent rien dire ou les commandes qui diffèrent, avoir un langage différent de l'anglais peut vous faire perdre quelques heures).

Des Exemples :

Prenons un exemple simple l'activation ou la désactivation du "SID Filtering" dans un "Trust" entre deux domaines.

OS Anglais :

Si les OS des serveurs contrôleur de domaine sont en Anglais les commandes sont simples :

Pour désactiver le SID Filtering : 

Netdom trust **TrustingDomainName** /domain:**TrustedDomainName **/quarantine:No  

Nb: Remplacez **TrustingDomainName** par le nom du domaine qui doit approuver l'autre et **TrustedDomainName ** par le nom de domaine qui doit être approuvé.

Pour activer le SID Filtering : 

Netdom trust **TrustingDomainName** /domain:**TrustedDomainName **/quarantine:Yes

 Nb: Remplacez **TrustingDomainName** par le nom du domaine qui doit approuver l'autre et **TrustedDomainName ** par le nom de domaine qui doit être approuvé.

OS Français :

Lorsque les OS sont en Français il y a une petite subtilité :

Pour désactiver le SID Filtering : 

Netdom trust **TrustingDomainName** /domain:**TrustedDomainName **/quarantine:Non  

Nb: Remplacez **TrustingDomainName** par le nom du domaine qui doit approuver l'autre et **TrustedDomainName ** par le nom de domaine qui doit être approuvé.

Pour activer le SID Filtering : 

Netdom trust **TrustingDomainName** /domain:**TrustedDomainName **/quarantine:Oui

Nb: Remplacez **TrustingDomainName** par le nom du domaine qui doit approuver l'autre et **TrustedDomainName ** par le nom de domaine qui doit être approuvé.

Vous l'avez ?

Et oui la commande est quasi identique puisqu'elle est en Anglais, mais les arguments eux sont en Français et le pire dans tout ça c'est que si vous passez la commande en Anglais avec les arguments en Anglais, l'OS vous dira que la commande s'est terminée avec succès même si ce n'est pas le cas; mais dans la pratique cette dernière aura échouée.

Alors de grâce ayez le réflex lors d'une installation serveur de sélectionner un Iso en Anglais et de l'installer en Anglais (rassurez vous pour le clavier et le fuseau horaire le Français est autorisé ^^ ).

Comme certain d'entre vous j'en ai eu marre de ne plus avoir de place sur mon disque mais surtout de devoir re-déployer Windows Server à chaque nouvelle VM pour un Lab; voici donc comment créer un disque de différenciation sous Hyper-V.

1. Créer la VM de référence

1- Dans un premier temps, sur votre poste de travail définissez un répertoire dans lequel sera stocké le disque de référence.

Dans mon cas je vais créer le serveur de référence dans mon disque "D" dans un répertoire "Template" et placer son disque dans un sous répertoire "Virtual Hard Disk".

2- Ensuite lancez "Hyper-V Manager"

3- Puis sélectionnez le serveur Hyper-V et faites un clic droit « New » puis « Virtual Machine ».

Dans la fenêtre « Before you Begin » faites « Next »

4- Dans la fenêtre « Specify Name and Location » donnez un nom à votre machine de référence et sélectionnez « Store the virtual machine in a different location » et cliquez sur « Browse… »

5- Sélectionnez le répertoire dans lequel seront stocké les éléments de configuration de la VM puis « Select Folder »

6- Faites « Next »

7- Sélectionnez le type de génération de la VM (dans mon cas une VM de génération 2) et faites « Next »

8- Assignez une quantité de RAM à la VM (au moins le prérequis système) et faites « Next ».

9- Il n’est pas obligatoire d’assigner une carte réseau pour la machine de référence, faites « Next ».

10- Dans la configuration du disque dur choisissez une taille suffisante pour l’OS (et éventuellement les mises à jour), puis faites « Next ».

11- Sélectionnez l’ISO du Système d’exploitation et faites « Next »

12- Relisez le résumé de la configuration et faites « Finish »

13- Une fois la VM créée dans Hyper-V Manager sélectionnez la et faites « Settings »

14- Naviguez jusque « Checkpoint » et désélectionnez « Enable Checkpoints » puis faites « OK »

La VM est maintenant prête, nous allons donc pouvoir déployer l'image, rendez vous donc dans la partie 2.

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.

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.