Bonjour à tous,

Qui n'a jamais rencontré d'échecs lors de la mise en domaine d'un poste ?

Les messages d'erreurs fournis à cette occasion ne sont pas forcément des plus explicites, ni des plus détaillés.

Heureusement il y a une solution et celle-ci s'appelle NetSetup.log

Vous trouverez ce fichier dans le dossier C:\Windows\debug.

Pour ce qui est de la structure du fichier, vous pouvez vous référer à la capture ci-dessous, mais voici un résumé des informations contenues dans celui-ci :

• Nom du contrôleur de domaine contacté pour la jonction au domaine
• Nom du site Active Directory détecté
• Identifiants utilisés pour la jonction
• OU de destination du poste
• Résultats lors de la création de l'objet ordinateur (SPNs, Nom DNS, ... )
• Etc ...

Bonne découverte !

Bonjour à tous,

Aujourd'hui, nous allons aborder l'initialisation du dossier SYSVOL lors de la promotion d'un contrôleur de domaine (ou "DCPROMO" pour les intimes).

Quelques précisions pour débuter

Tout d'abord, il convient de rappeler quelques informations à propos du dossier SYSVOL en lui même.

Ce dossier se divise en plusieurs sous-dossiers, dont les deux plus importants sont :

• Policies : dossier qui contient tous les fichiers de définitions de toutes les GPO pour le domaine Active Directory concerné
• Scripts : dossier qui contient tous les scripts/fichiers/installeurs que vous voulez utiliser dans des GPO ou autres. Ce dossier Scripts est partagé sous l'URI \\contoso.com\NETLOGON.

Le principe du dossier SYSVOL est d'être automatiquement répliqué entre tous les contrôleurs de domaine d'un domaine Active Directory via les mécanismes suivants :

• FRS : mécanisme de réplication utilisé jusqu'à Windows Server 2003 R2. Il est à noter que lors d'une opération de mise à jour d'une Infrastructure AD, le mécanisme FRS reste en place même si le niveau fonctionnel du domaine est passé en 2008 R2. Il faut utiliser l'utilitaire Dfsrmig.exe pour mettre à jour manuellement le mécanisme de réplication vers DFS.
• DFS : mécanisme de réplication utilisé à partir de Windows Server 2008. Utilise DFS-N pour la mise à disposition du dossier Sysvol sous la forme de l'URI \\contoso.com\SYSVOL et DFS-R pour la réplication des données du dossier.

En résumé, ce dossier SYSVOL est mis à disposition sur chaque contrôleur de domaine via les deux partages suivants :

• SYSVOL : X:\SYSVOL\sysvol
• NETLOGON : X:\SYSVOL\sysvol\contoso.com\SCRIPTS

Promotion d'un contrôleur de domaine

Le but de cette section n'est pas de revenir sur comment faire la promotion d'un contrôleur de domaine, mais plutôt de préciser ce qu'il se passe lors de cette promotion pour l'initialisation du dossier SYSVOL.

Le diagramme de flux ci-dessous nous présente les étapes d'une promotion d'un contrôleur de domaine. La partie qui nous intéresse se situe plus spécifiquement lors de l'étape Installation et après le redémarrage post-promotion du contrôleur de domaine.

Une fois les pré-requis validés dans l'assistant de promotion, la copie de toutes les partitions de l'annuaire AD est effectuée à partir de l'AD de référence (renseigné précédemment).

Lorsque la copie des informations des partitions de l'AD est complète, le nouveau contrôleur de domaine redémarre.

Pour ceux que cela intéresse, le détail de la promotion se situe dans le fichier de log suivant : %SystemRoot%\debug\DCPROMO.TXT

Pour ceux qui veulent encore plus de détails, vous pouvez allez voir le fichier de log : %SystemRoot%\debug\DCPROMOUI.TXT

Initialisation du dossier SYSVOL

On pourrait croire, suite au redémarrage du serveur, que celui-ci est devenu d'office contrôleur de domaine mais ce n'est pas le cas.

En effet, si les informations des partitions de l'AD ont été copiées, en revanche, le dossier SYSVOL lui n'a pas encore été initialisé.

Vous pouvez le constater en tapant la commande net share, les partages en question n'apparaissent pas.

Si vous faites un DCDIAG, vous verrez que les tests Advertising et Netlogons sont en échec, ce qui est normal à cette étape.

Si vous regardez la section Replication DFS de l'observateur d'événements, vous devriez apercevoir l'événement suivant (4614) :

Cet événement indique clairement que le dossier SYSVOL est en cours d'initialisation à partir du DC de référence indiqué lors de l'assistant de promotion et que ce serveur ne s'annoncera pas contrôleur de domaine tant qu'il n'aura pas fini l'initialisation de ce dossier.

Si tout se passe bien, au bout de quelques minutes/heures/jours (rayez la mention inutile), vous devriez voir l'événement suivant (4604) indiquant que le dossier SYSVOL s'est bien initialisé :

Si vous tapez la commande net share, les partages SYSVOL et NETLOGON apparaissent et un DCDIAG ne vous donne plus d'erreur sur les tests Advertising et Netlogons.

En conclusion, votre serveur est devenu un contrôleur de domaine pleinement fonctionnel.

Quand l'initialisation ne fonctionne pas

Malgré de nombreux cafés pris, il se peut que le dossier SYSVOL n'est toujours pas initialisé, ce qui se traduit par la présence de l'événement 4614 mais que vous attendez en vain l'événement 4604 dans l'observateur d'événements.

Une plus ample analyse des journaux de votre serveur ne vous donnera pas beaucoup d'aide sur les raisons de cette non complétion, mais en revanche, ceux du serveur partenaire de réplication le peuvent.

En regardant ces journaux sur le serveur partenaire, nous voyons que la cause de la non-réplication est un fichier du dossier SYSVOL resté en lecture seule. Cependant, ce n'est qu'un exemple parmi d'autres de points de blocage.

Pour débloquer la situation, à partir de ce constat, vous avez deux choix :

• Résoudre le problème sur le serveur "source" pour la réplication
• Dé-promoter le serveur et le re-promoter mais en choisissant comme contrôleur de domaine source un serveur fonctionnel au niveau de la réplication DFS

Suite à ces corrections, vous n'aurez plus qu'à "guetter" l'événement 4604.

Désormais, lorsque vos partages SYSVOL et NETLOGON sont manquants, vous n'aurez plus d'excuses !

Bonjour à tous !

L'article d'aujourd'hui rentre dans la catégorie "trucs et astuces", mais de celles qui vous feront gagner beaucoup de temps.

En effet, l'installation de la fonctionnalité .NET Framework version 3.5 sous Windows Server 2012 R2 n'a jamais été une sinécure.

La faute en revient à la fonctionnalité Features on Demand introduite avec Windows Server 2012. Afin de rentre le dossier d'installation de Windows Server 2012 moins volumineux, Microsoft a décidé que les fichiers nécessaires pour installer les rôles et fonctionnalités de Windows Server ne seraient plus présents en totalité sur le disque dur local de l'OS. En conséquence, l'installation de certaines fonctionnalités requiert une source externe (ISO ou ressources sur le réseau) et la fonctionnalité .NET Framework 3.5 en fait partie.

La méthode classique

Concrètement, cela se traduit par un chemin à renseigner vers les sources externes Windows Server lors de l'installation de la fonctionnalité .NET 3.5 au sein du Gestionnaire de Serveur.

Ces sources peuvent être une ISO que vous aurez préalablement monté ou des fichiers stockés sur une ressource réseau.

Si vous ne précisez rien dans le chemin des sources, le Gestionnaire de Serveur utilisera Windows Update comme moyen pour télécharger les sources manquantes.

Et c'est là "tout le sel de l'opération", à savoir que si le serveur est managé par un WSUS, le téléchargement des sources externes via Windows Update n'est pas possible et si vous n'avez pas l'ISO Windows Server sous la main, il vous faudra la transférer et vous n'avez peut être pas le temps, ni la bande passante pour envoyer 4,6 Go !

Heureusement, il existe une alternative.

La méthode Windows Update

La méthode suivante vise à permettre le téléchargement des sources manquantes directement via Windows Update, même si le serveur est dans le périmètre de gestion d'un serveur WSUS.

Nous allons donner ici la méthode "unitaire" pour passer la modification, mais celle-ci est très facilement adaptable en GPO.

1) Pour se faire, ouvrez la console GPEdit.msc sur la machine concernée.

2) Allez dans Computer Configuration -> Administrative Templates -> System

3) Allez à l’option Specify settings for optional component installation and component repair.

4) Passez le paramètre à Enabled si celui-ci est à Disabled ou Not Configured.

5) Cochez l'option Contact Windows Update directly to download repair content instead if Windows Server Update Services (WSUS). Cliquez sur Apply pour valider la modification.

6) Passez la commande GPUpdate /force dans une invite de commande afin que le poste prenne en compte la modification dans ses paramètres de mise à jour.

7) Relancez l'installation de la fonctionnalité .NET Framework 3.5 depuis le Gestionnaire de Serveur, en laissant l'Alternate File Path vide. L'installation devrait désormais être fonctionnelle.

Bonjour à tous !

Nous allons nous pencher aujourd'hui plus profondément dans les entrailles du produit Quest Migration Manager for Active Directory, notamment avec l'étude d'un cas problématique et de sa résolution.

Le cas que nous allons étudier ci-dessous est susceptible d'être peu rencontré, mais il n'en est pas moins "vicieux". J'espère donc que ce billet n'en sera que d'autant plus utile.

Les symptômes

• Vous avez migré un ensemble d'utilisateurs à l'aide de QMM.
• Vous avez lancé des processings avec RUM sur un ensemble de postes.
• Sur certains postes, le processing se passe correctement, sur d'autres non.
• Aucune erreur particulière n'est rapportée dans la console RUM, le seul signe visible est qu'aucun élément n'est mis à jour lors du processing (Aucun fichier, aucune clé registre, ...).
• Si vous remigrez les utilisateurs à l'aide d'un autre serveur Quest, et si vous effectuez de nouveau des processings sur les précédents postes avec ce nouveau serveur, vous pourrez constater que certains postes sont correctement processés cette fois-ci, et que d'autres ne le sont plus.

Analyse du problème

La console RUM de Quest ne nous indiquant aucune erreur particulière lors des processings sur les postes en question, c'est donc vers les fichiers de logs que nous allons devoir nous tourner.

Le premier fichier de log nous intéressant va être celui qui remonte les détails du processing d'un poste.

Vous pourrez trouver, pour une instance RUM, tous les fichiers de processing de l'ensemble des postes dans le dossier suivant :

C:\Program Files (x86)\Common Files\Aelita Shared\Migration Tools\Resource Updating\Logs\

Allez dans le dossier correspondant au poste voulu et ouvrez le fichier de log correspondant au processing "en échec".

A première vue, il n'y a rien d'inhabituel dans le fichier de log, à part que l'on remarque bien qu'il n'y a aucun élément mis à jour lors de processing. Cependant, il faut bien regarder le Warning présent à la deuxième ligne.

Nous y trouvons l'avertissement suivant, à savoir que Le fichier INI contient une ligne invalide :

INI file contains invalid line '9;User_XXX;106572;;User;XXX@sourcedomain.local;User;XXX@targetdomain.local;1'. Escape to next domain pair

Avant de pouvoir analyser la ligne en question, il nous faut donc parcourir le fichier INI en question. Ce fichier correspond en fait au fichier de mappage des utilisateurs que RUM utilise lors de ces processings. A chaque processing, un nouveau fichier de mappage est généré selon les utilisateurs migrés par l'instance QMM. Tous les fichiers de mappage générés se trouvent à l'intérieur du dossier suivant :

C:\Program Files (x86)\Common Files\Aelita Shared\Migration Tools\Resource Updating\Configs\

Si l'on prend le fichier INI cité précédemment, voici ce que l'on trouve à l'intérieur de celui-ci :

La 1ère ligne représente une ligne correctement formée, à savoir que tous les champs du fichier de mappage sont séparés par un point-virgule.

La 2ème ligne surlignée correspond à la ligne citée en erreur. Quand on effectue une analyse de celle-ci, on remarque qu'elle contient plus de point-virgule que pour une ligne correctement formée. Je vous remets le message d'erreur avec le surlignage pour bien mettre en évidence les anomalies :

INI file contains invalid line '9;User_XXX;106572;;User;XXX@sourcedomain.local;User;XXX@targetdomain.local;1'. Escape to next domain pair

En l'occurrence, après une vérification dans les propriétés de l'utilisateur dans l'AD Source, il s'avère que le SamAccountName de l'utilisateur en question est bien "User_XXX" mais que l'UPN de celui-ci est "User;XXX" !

Le fichier de mappage va donc inclure d'office ces points virgules supplémentaires ce qui va causer l'erreur citée précédemment, qui n'est donc pour le moment pas explicitement gérée par Quest dans le sens ou, précédemment, la migration de cette utilisateur via QMM n'a donné lieu à aucun avertissement.

La conséquence de cette erreur nous est donnée dans le message d'avertissement, à savoir Escape to next domain pair.

Une domain pair dans le jargon de Quest correspond à une paire domaine source - domaine cible déclarée dans Quest. Si vous avez plusieurs domaines distincts à migrer avec QMM, vous devez déclarer une domain pair pour chacun d'entre eux. Ce qu'indique le message d'erreur, c"est que toute la partie du fichier de mappage qui est après la ligne en erreur est ignorée, jusqu'à la prochaine domain pair rencontrée comme schématisé dans l'image ci-dessous :

C'est ce fait qui explique pourquoi certains postes n"étaient pas procéssés, tandis que d'autres l'étaient correctement. C'est également ce fait qui explique les disparités observées dans les processings effectués à l'aide d'une autre instance de Quest RUM. En effet, comme le fichier de mappage des comptes est re-généré à chaque processing, l'ordre des comptes à l'interieur de celui-ci diffère suivant les instances, c'est donc pourquoi le processing était de nouveau fonctionnel pour certains postes, et pour d'autres non avec une nouvelle instance.

Solution

La résolution du problème se présente sous la forme suivante :

• Modifiez l'utilisateur en erreur dans l'AD source et dans l'AD cible afin de retirer le caractère point-virgule du nom d'utilisateur
• Effectuez une nouvelle migration de l'utilisateur (un merge dans le cas présent car l'utilisateur est déjà existant dans l'AD cible) avec QMM car RUM se base sur les utilisateurs migrés avec QMM pour construire son fichier de mappage des utilisateurs (voir la section Addendum pour les exceptions)
• Effectuez de nouveau un processing des postes en erreurs, celui-ci devrait être désormais fonctionnel, avec notamment le message suivant dans le fichier de log des postes procéssés :

Addendum

Il nous faut ajouter une petite précision, car nous avons précisé au paragraphe précédent que RUM se basait sur la liste des utilisateurs migrés avec QMM pour construire son fichier de mappage des utilisateurs.

Ce n'est plus systématiquement vrai avec la version 8.13 de QMM et RUM, car nous pouvons indiquer à RUM lors des processings de se baser directement sur le SIDHistory de l'utilisateur cible (SID de l'utilisateur source) dans l'AD cible pour effectuer la correspondance des comptes utilisateurs sur les machines migrées.

Vous trouverez l'option lors de l'étape suivante du processing :

Bonjour à tous !

Lors d'une migration effectuée à l'aide du produit Quest Migration Manager for Active Directory, vous vous retrouvez souvent en fin de migration avec un nombre conséquent d'agents Quest à désinstaller de tous les postes migrés.

Ce que vous pouvez très bien faire à l'aide de Quest RUM (Resource Updating Manager) via l'option Cleanup :

Mais il peut arriver qu'entre temps que certains postes migrés soient devenus indisponibles. Plutôt que de refaire une passe numéro X pour désinstaller les agents, nous allons voir comment automatiser la désinstallation de ceux-ci.

Prérequis

Pour ce faire, il vous faut :

• Un serveur sur lequel sera placé un partage accessible par toutes les machines ayant un agent Quest
• Un éditeur de script Powershell
• Une console d'édition de stratégies de groupe

Le partage de fichiers

Afin que notre script de désinstallation puisse écrire les logs nécessaire, il doit avoir à disposition un partage sur lequel les machines concernées puissent avoir un droit d'écriture de fichiers.

Par défaut, le script va utiliser le nom de partage QuestUninstallLogs$ mais vous pourrez le modifier via les arguments du script. Nous rajoutons un $ à la fin du nom du partage afin de masquer celui-ci.

Il faut ajouter sur le partage (droit de partage) le droit en modification pour le groupe Everyone.

Il faut ajouter sur le dossier (droit NTFS) le droit en modification et en écriture pour le groupe Authenticated Users. 

Une fois cela fait, nous pouvons passer à l'édition du script.

Le script

Arguments

Le script s'appelle à l'aide des arguments suivants :

• -Pole (obligatoire) : Nom du dossier de 1er niveau des logs
• -Site (obligatoire) : Nom du dossier de 2ème niveau des logs
• -LogServer (obligatoire) : Nom du serveur devant recevoir les logs
• -LogShare (facultatif) : Nom du partage devant recevoir les logs

Sortie

Deux types de fichiers de logs vont être générés en sortie dans le chemin indiqué en paramètre du script :

• XXX_SUMMARY.log : Fichier résumant toutes les désinstallations effectuées par le script
• COMPUTERS\PC-XXX.log : Fichier détaillant le déroulement de la désinstallation de l'agent Quest pour le poste concerné

Code

#-------------------#
# Script Parameters #
#-------------------#
# Description
# The Uninstall_Quest_Agent script is uninstalling the Quest RUM Agent
# 
# How to use it 
#
# .\Uninstall_Quest_Agent.ps1 -Pole "POLE_IDF" -Site "Site_1" -LogServer "LOG_SERVER_1" -LogShare "QuestUninstallLogs$"
#
# -Pole = Targeted Pole
# -Site = Targeted Site
# -LogServer = Server on which the uninstall logs will be stored
# -LogShare (not mandatory) = Network Share on which the uninstall logs will be stored

########## PARAMETERS ##########

[CmdletBinding(DefaultParametersetName="Common")]
param(
	
	#Attribute field to check
	[Parameter(Mandatory=$true,Position=1)][string] $Pole = $null,
	
	#Attribute field to check
	[Parameter(Mandatory=$true,Position=2)][string] $Site = $null,
	
	#Attributes fields to check
	[Parameter(Mandatory=$false,Position=3)][string] $LogServer = $null,

	#Attributes fields to check
	[Parameter(Mandatory=$false,Position=4)][string] $LogShare = "QuestUninstallLogs$"
	
	)

########## SCRIPT EXECUTION ##########

# Check if script has been executed (log file already exists)

# Define logfile path and name
# Detailed logs
$LogFileDirectoryPath = "\\" + $LogServer + "\" + $LogShare + "\" + $Pole + "\" + $Site + "\COMPUTERS"
$LogFileName = $env:computername + ".log"
$LogFilePath = $LogFileDirectoryPath + "\" + $LogFileName

# Summary logs
$SummaryLogFileDirectoryPath = "\\" + $LogServer + "\" + $LogShare + "\" + $Pole + "\" + $Site
$SummaryLogFileName = $Pole + "_" + $Site + "_" + "SUMMARY.log"
$SummaryLogFilePath = $SummaryLogFileDirectoryPath + "\" + $SummaryLogFileName

# End script if Quest Agent Service is missing
$Service = Get-Service QsRUMAgent -ErrorAction SilentlyContinue

if($Service -eq $null)
{
    Exit
}

########## LOG FILES MANAGMENT ##########

# Checking if directories need to be created

# Check if pole directory exists
$PoleFilePath = "\\" + $LogServer + "\" + $LogShare + "\" + $Pole

# If directory don't exist, we create it
if(!(Test-Path $PoleFilePath))
{
    New-Item $PoleFilePath -ItemType Directory
}

# Check if site directory exists
$SiteFilePath = "\\" + $LogServer + "\" + $LogShare + "\" + $Pole + "\" + $Site

# If directory don't exist, we create it
if(!(Test-Path $SiteFilePath))
{
    New-Item $SiteFilePath -ItemType Directory
}

# Check if COMPUTERS directory exists
$ComputersFilePath = "\\" + $LogServer + "\" + $LogShare + "\" + $Pole + "\" + $Site + "\COMPUTERS"

# If directory don't exist, we create it
if(!(Test-Path $ComputersFilePath))
{
    New-Item $ComputersFilePath -ItemType Directory
}

########## UNINSTALLING AGENT ##########

$Date = (Get-Date).ToString()
$ComputerName = "\\" + $env:computername

# Log
$ToWrite = $Date + " - " + "Begining of Quest agent uninstallation"
Add-Content $LogFilePath $ToWrite

# Stopping and Deleting Quest Migration Manager RUM Agent Service
$Service = Get-Service QsRUMAgent -ErrorAction SilentlyContinue

#If service exists
if($Service)
{
    Stop-Service $Service.Name
    # Log
    $ToWrite = $Date + " - " + "Quest Migration Manager RUM Agent Service - Stopped"
    Add-Content $LogFilePath $ToWrite

    sc.exe $ComputerName delete $Service.Name
    # Log
    $ToWrite = $Date + " - " + "Quest Migration Manager RUM Agent Service - Deleted"
    Add-Content $LogFilePath $ToWrite

    # Log Général
    $ToWrite = $Date + " - " + $env:computername + " - " + "Agent Deleted"
    Add-Content $SummaryLogFilePath $ToWrite
}

else
{
    # Log
    $ToWrite = $Date + " - " + "ERROR : Quest Migration Manager RUM Agent Service not found !"
    Add-Content $LogFilePath $ToWrite
}

# Deleting Quest Migration Manager RUM Agent Directory
$QuestAgentDirectory = "$env:SystemRoot\Quest Resource Updating Agent"

#If directory exists
if(Test-Path $QuestAgentDirectory)
{
    Remove-Item $QuestAgentDirectory -Recurse
    # Log
    $ToWrite = $Date + " - " + "Quest Migration Manager RUM Agent Directory - Deleted"
    Add-Content $LogFilePath $ToWrite
}

else
{
    # Log
    $ToWrite = $Date + " - " + "ERROR : Quest Migration Manager RUM Agent Directory not found !"
    Add-Content $LogFilePath $ToWrite
}

# Log
$ToWrite = $Date + " - " + "End of Quest agent uninstallation"
Add-Content $LogFilePath $ToWrite

Utilisation du script

Vous pouvez utiliser ce script directement sur le poste concerné ou par GPO pour une désinstallation groupée.

Par GPO, le script s'utilise dans la section Powershell dans les Paramètres Ordinateurs de la console de configuration des GPO.

Le chemin pour y accéder est Configuration Ordinateur > Stratégies > Paramètres Windows > Arrêt > Scripts Powershell

A minima, le script doit s'appeller à l'aide des paramètres suivants :

Au fur et à mesure que le script est exécuté, vous devriez voir le dossier des logs se remplir, que ce soit pour le log SUMMARY qui résume toutes les désinstallations ou pour les logs individuels par machine.