Problème

Lors de l'utilisation d'un script qui génère plusieurs requêtes depuis plusieurs serveurs en simultané afin d'alimenter une banque de données, je me suis heurté au message d'erreur suivant :

get-adcomputer : A connection to the directory on which to process the request was unavailable. This is likely a 
transient condition.
At C:\temp\Fusion.ps1:97 char:1
+ get-adcomputer -Filter {DNSHostName -eq $FullName} -Properties OperatingSystem | Select-Object -Property N ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Get-ADComputer], ADException
    + FullyQualifiedErrorId : ActiveDirectoryServer:0,Microsoft.ActiveDirectory.Management.Commands.GetADComputer

Explication

Cette erreur est liée aux valeurs par défaut du service "Active Directory Web Services" définies dans le fichier de configuration sur les DC sous : 

C:\Windows\ADWS\Microsoft.ActiveDirectory.WebServices.exe.config

En effet si vous éditez le fichier de configuration vous pourrez voir que par défaut le maximum de connexions LDAP par utilisateur est de 5.

<add key="MaxConnectionsPerUser" value="5" />

Ce qui signifie que je ne peux exécuter plus de 5 connexions en simultanée via Active Directory Web Services avec les même identifiants.

Il est possible de modifier cette valeur, mais cette action n'est pas recommandée car elle peut avoir un impact sur les performances de l'AD.

Si toutefois vous souhaitez la modifier, certaines précautions sont à prendre; il est clairement précisé dans le fichier de configuration que la valeur de "MaxConnectionsPerUser" ne peut pas être plus grande que la valeur de "MaxPoolConnections", il faudra donc aussi prendre en compte la valeur suivante :

<add key="MaxPoolConnections" value="10" />

Cette dernière spécifie que le nombre maximal de connexions LDAP, pour chaque instance de service d'annuaire prise en charge par le service ADWS s'exécutant sur un serveur.

Il peut être aussi intéressant de regarder la valeur de la clé ci-dessous : 

<add key="MaxPercentageReservedConnections" value="50" />

Celle-ci permet, de spécifier le pourcentage maximal de connexions LDAP pouvant être utilisées pour effectuer des requêtes pour chaque instance de service d'annuaire prise en charge par le service ADWS sur un serveur.

Attention :

Même s'il est possible de modifier les paramètres ci-dessus, Microsoft ne le préconise pas (cf: note ci-dessous) :

Plusieurs paramètres de configuration du service ADWS affectent la limitation de la bande passante sur un serveur Windows Server 2008 R2 sur lequel le service ADWS est en cours d'exécution.
Nous recommandons aux administrateurs de modifier les valeurs par défaut des seuls paramètres suivants:
MaxConcurrentCalls, MaxConcurrentSessions, MaxReceivedMessageSize et MaxStringContentLength.

Compléments d'informations:

https://technet.microsoft.com/en-us/library/373e68b3-abfc-4da4-ae89-72a15cfc7543

Bonjour à tous !

Aujourd'hui nous allons aborder la résolution de problèmes d'application des stratégies de groupe (coté poste client) et plus précisément la partie avancée de cette résolution.

Débug usuel

Habituellement, il faut passer par l'Observateur d'Evènements du poste client afin d'obtenir plus de détails sur l'application des stratégies de groupe.

Deux sections peuvent vous intéresser :

• Journaux Windows/Système
  • Le niveau de détail est assez limité mais c'est un bon point de départ
  • Vous pouvez filtrer les événements par les sources pour ne garder que les parties intéressantes

• Journaux des applications et des services/Microsoft/Windows/GroupPolicy
  • Est beaucoup plus détaillé
  • Ne contient que les evènements stratégies de groupe

Mais parfois, il peut s'avérer que les informations remontées par ces logs ne soient pas assez précises pour trouver la vraie cause du problème.

Débug avancé

Les messages d'état détaillés

Le fichier gpsvc.log

1. Ouvrez l'éditeur de registre avec la commande Regedit
2. Dépliez la clé HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion
3. Crééz une nouvelle clé Diagnostics si elle n'existe pas
4. Crééz une nouvelle valeur DWORD (32-bit) GPSvcDebugLevel
5. Modifiez la valeur GPSvcDebugLevel par la valeur 30002 (Hexadecimal)
6. Fermez le Registre
7. Crééz le dossier Usermode si celui-ci est absent du dossier C:\Windows\Debug\
8. Lancez la commande Gpupdate /force
9. Le fichier gpsvc.log doit se créer

Bonjour à tous,

Aujourd'hui nous allons aborder la problématique du Secure Channel (canal sécurisé) dans une infrastructure Active Directory.

Qu'est ce que le Secure Channel ?

Le Secure Channel ou Canal Sécurisé est un élément vital dans une infrastructure Active Directory. En effet, toute communication entre une station de travail et un contrôleur de domaine AD doit passer via un canal sécurisé.

Il est à noter que le canal sécurisé est également utilisé pour les communications entre deux contrôleurs de domaine.

Quand le canal sécurisé est cassé, toutes les opérations Active Directory liées au canal sont en échec (Tickets Kerberos, stratégies de groupes, ...).

Quand le Secure Channel est cassé

Le signe le plus flagrant d'un problème de canal sécurisé entre un poste et un contrôleur de domaine est le message suivant au démarrage du poste : "The trust relationship between this workstation and the primary domain failed".

La plupart du temps, ceci est du au fait que le mot de passe en usage pour établir le Secure Channel sur le poste concerné est différent du mot de passe du compte ordinateur stocké dans l'AD.

Réparer le Secure Channel

Habituellement, l'étape de réparation passe par les étapes suivantes :

1. Sortie du poste du domaine pour un retour en Workgroup
2. Réinitialisation du compte ordinateur correspondant dans l'Active Directory
3. Réintégration du poste dans le domaine

L'ancienne méthode

Une méthode, plus propre, et qui vous épargnera un redémarrage consiste à réparer le canal sécurisé directement avec une invite de commande.

La commande à utiliser est netdom resetpwd /s:domaincontroller /ud:domain\User /pd:*

La nouvelle méthode

Avec l'avènement de Powershell, une nouvelle commande a fait son apparition : Test-ComputerSecureChannel.

Si la commande renvoie True, c'est que le Secure Channel est fonctionnel entre le poste et le contrôleur de domaine concerné.

Si elle renvoie False, c'est que le Secure Channel n'est plus fonctionnel entre le poste et le contrôleur de domaine concerné.

Il faut l'utiliser avec l'option Repair afin de réparer le Secure Channel.

Le retour de la commande, True ou False, indique le succès ou non de la réparation du Canal Sécurisé.

A noter qu'à partir de Powershell v4.0, l'option Credential permet de préciser les identifiants à utiliser pour réparer le canal sécurisé.

Version Windows 7 / Windows Server 2008 R2 :

Version Windows 8 / Windows Server 2012 R2 :

Bonjour à tous,

Aujourd'hui nous allons partir à la découverte du fichier NetLogon.dns

Vous trouverez ce fichier, propre à chaque contrôleur de domaine, dans le dossier %systemroot%\System32\Config.

Comme vous le savez surement, les services AD et DNS sont très étroitement liés car les informations relatives aux différents contrôleurs de domaine ou aux différents sites AD sont stockées dans la zone DNS de la forêt AD correspondante. 

Celle-ci contient donc des enregistrements A faisant référence directement aux adresses IP des contrôleurs de domaine ou des enregistrements SRV permettant aux postes clients de la forêt AD de pouvoir accéder aux services essentiels AD.

Ce fichier intéressera donc en premier lieu :

• Ceux qui doivent résoudre des problèmes relatifs au fonctionnement des services AD et qui ont localisé des irrégularités au niveau des enregistrements stockés dans la zone DNS AD
• Ceux dont la zone DNS correspondant à la forêt AD se trouve sur un serveur DNS non Microsoft (gestion "manuelle" des enregistrements)

Un exemple valant mieux que 1000 mots, vous trouverez ci-dessous le contenu de ce fichier avec l'ensemble des enregistrements mentionnés ci-dessus :

Bonne exploration !

Dans un environnement hybride, avec des utilisateurs synchronisés depuis l'Active Directory vers O365, il n'est actuellement pas possible de changer l'UPN directement par le portail d'administration O365.

Cependant avec les commandes Powershell suivante, il est possible de modifier l'UPN directement dans O365:

Il faut passer par l'adresse technique pour changer l'UPN de l'utilisateur d'un domaine à un autre, il faut cependant que l'UPN final soit égal à la valeur présente dans l'Active Directory Onpremise.

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 !

Problème:

Sur Windows Server 2008 quand vous réalisez la rétrogradation d'un contrôleur de domaine à simple serveur membre, vous pouvez rencontrer une erreur de type :

"Operations which require contacting a FSMO operation master will fail until this condition is corrected"

Ce problème se produit quand la commande essaie de contacter le maître d'infrastructure et qu'elle echoue pour une des raisons suivantes:

• La ou les partitions mentionnées dans le message d'erreur ne sont plus existantes.
• Le maître d'infrastructure pour la ou les partitions mentionnées, a été rétrogradé de force ou est hors ligne (hors réseau ou éteint).

Solution:

Dans le premier cas de figure Microsoft préconise un nettoyage des métadonnées de la partition orpheline en utilisant l'outils Dsmgmt (cf: http://technet.microsoft.com/en-us/library/cc730970(ws.10).aspx ).

Dans le deuxième cas de figure il suffit de spécifier un propriétaire du rôle maître d'infrastructure qui est "En ligne", pour cela vous pouvez exécuter le script suivant à l'aide de la commande :

cscript fixfsmo.vbs DC=DomainDnsZones,DC=VotreNomDeDomaine,DC=XXX (Remplacez XXX par votre extension: fr, com, lan, biz...)

Le script:

Le script ci-dessous permet de modifier l'attribut "fSMORoleOwner" dans le domaine spécifié dans la ligne de commande.

'-------fixfsmo.vbs------------------
const ADS_NAME_INITTYPE_GC = 3
const ADS_NAME_TYPE_1779 = 1
const ADS_NAME_TYPE_CANONICAL = 2

set inArgs = WScript.Arguments

if (inArgs.Count = 1) then
    ' Assume the command line argument is the NDNC (in DN form) to use.
    NdncDN = inArgs(0)
	Else
    Wscript.StdOut.Write "usage: cscript fixfsmo.vbs NdncDN"
	End if
	
if (NdncDN <> "") then

' Convert the DN form of the NDNC into DNS dotted form.
    Set objTranslator = CreateObject("NameTranslate")
    objTranslator.Init ADS_NAME_INITTYPE_GC, ""
    objTranslator.Set ADS_NAME_TYPE_1779, NdncDN
    strDomainDNS = objTranslator.Get(ADS_NAME_TYPE_CANONICAL)
    strDomainDNS = Left(strDomainDNS, len(strDomainDNS)-1)
	
	Wscript.Echo "DNS name: " & strDomainDNS
    
	' Find a domain controller that hosts this NDNC and that is online.
    set objRootDSE = GetObject("LDAP://" & strDomainDNS & "/RootDSE")
    strDnsHostName = objRootDSE.Get("dnsHostName")
    strDsServiceName = objRootDSE.Get("dsServiceName")
    Wscript.Echo "Using DC " & strDnsHostName

    ' Get the current infrastructure fsmo.
    strInfraDN = "CN=Infrastructure," & NdncDN
    set objInfra = GetObject("LDAP://" & strInfraDN)
    Wscript.Echo "infra fsmo is " & objInfra.fsmoroleowner
	
	' If the current fsmo holder is deleted, set the fsmo holder to this domain controller.
    if (InStr(objInfra.fsmoroleowner, "\0ADEL:") > 0) then
	' Set the fsmo holder to this domain controller.
	objInfra.Put "fSMORoleOwner",  strDsServiceName
	objInfra.SetInfo
	
	' Read the fsmo holder back.
	set objInfra = GetObject("LDAP://" & strInfraDN)
	Wscript.Echo "infra fsmo changed to:" & objInfra.fsmoroleowner
	
    End if
	
End if	

Une fois le script exécuté vous devriez pouvoir rétrograder votre contrôleur de domaine, si toutefois le problème persistait il faudra passer par la console ADSI Edit.

Dans le cadre de la gestion des GPO, il arrive de temps en temps d'avoir des temps de chargement très long lorsque que l'on tente d'accéder à certains paramètres dans la console Group Policy Management, ce problème est peut être lié à des ADMX qui ont été chargés dans la console depuis un poste client et qui ne sont pas accessibles lorsque vous ouvrez la console.

Afin de régler ce problème qui peut être récurrent et gênant lors de l'administration des GPOs, il est conseillé de créer une banque centrale contenant les différents fichiers ADMX.

Afin de créer le magasin Central pour les fichiers .admx et .adml (les .adml sont les fichiers de langue correspondant aux .admx), créez un dossier nommé PolicyDefinitions à l’emplacement suivant sur un contrôleur de domaine :

\\contoso.com\SYSVOL\contoso.com\policies

Après avoir copié tous les fichiers .admx et .adml, le dossier PolicyDefinitions sur le contrôleur de domaine doit contenir les fichiers .admx et un ou plusieurs dossiers contenant les fichiers spécifiques à une langue .adml.

Les fichiers étant contenu dans le SYSVOL qui est répliqué, il ne devrait plus y avoir de lenteurs liées aux .admx lors de l'ouverture de la console GPMC. 

Dans le cadre d'une migration depuis des contrôleurs de domaines Windows Server 2003 vers des contrôleurs de domaine en Windows Server 2016 après avoir effectué l'extension du schéma ainsi que le forestprep et le domainprep avec succès, le gpprep échoue avec l'erreur suivante:

Gpprep operation 3 failed.

Upgrade of domain Group Policy Objects failed.

Adprep encountered a Win32 error.
Error code: 0x41 Error message: Network access is denied.

Le cas initial dans lequel cette erreur a été rencontrée est le suivant:

• Extension du schéma, forestprep, domainprep, gpprep exécutés depuis un serveur Windows Server 2016, qui n'est pas contrôleur de domaine et qui est en WORKGROUP et un compte ayant les droits suffisants. En effet l'upgrade de schéma depuis un serveur en workgroup est possible en spécifiant les crédentials et les foret/domaine en paramètres sur les différentes commandes.

L'upgrade a ensuite été de nouveau tentée dans le cadre suivant:

• Extension du schéma, forestprep, domainprep, gpprep exécutés depuis un serveur Windows Server 2016, qui n'est pas contrôleur de domaine et qui est membre du domaine.

Résultat: Même erreur que dans le cas initial.

Enfin, l'upgrade a été lancée dans l'environnement suivant:

• Extension du schéma, forestprep, domainprep, gpprep exécutés depuis un serveur Windows Server 2016, qui a été promu contrôleur de domaine au préalable et donc membre du domaine.

Résultat: Gpprep réussi.

Le fait que le GPPREP échoue, n'est pas un point bloquant pour le passage vers AD 2016, cependant il pourrait y avoir des répercussions sur les différentes GPO existantes si les modifications réalisées par le GPPREP ne sont pas appliquées correctement.

Il est également possible de faire l'ensemble des opérations depuis un serveur 2016 qui n'est pas encore contrôleur de domaine, et si le gpprep échoue, le relancer plus tard, une fois le serveur promu en tant que contrôleur de domaine.