1. Commande: adprep /domainprep /gpprep: 
   • Problèmes de droits:

   Lors du lancement de cette commande, vous avez un code d’erreur “LDAP API ldap_modify_ext_s() finished, return code is 0×32” alors il s’agit problème de droits, la commande a pourtant bien été lancée avec un compte membre de “domain admins” . En ouvrant le fichier adprep.log nous avons les informations suivantes:

   [2010/11/26:15:12:19.468]
   Adprep was about to call the following LDAP API. ldap_modify_s(). The entry to modify is CN={64E2BDA7-0FC4-48DA-BB70-79261A7B4822},CN=Policies,CN=System
   ,DC=ldap389,DC=info.
   [2010/11/26:15:12:19.468]
   LDAP API ldap_modify_ext_s() finished, return code is 0×32

   Il s’agit d’un problème sur une GPO qui intervient lors de la partie gpprep du setup. Nous allons donc vérifier les permissions sur celle ci:

   

   L’administrateur qui a créé la GPO a retiré les droits au groupe “domain admins”, pour corriger cela il faut se mettre propriétaire de l’objet et rétablir les droits sur celui-ci. Une fois cela corrigé, la commande adprep /domainprep /gpprep passe sans problème.

   • Remarque concernant le staging:

   Si l’intervalle de réplication entre certains de vos contrôleurs de domaine est long (i.e. un de vos DCs réplique une fois tous les X jours avec ses partenaires de réplication) alors le répertoire de staging de votre SYSVOL peut augmenter de manière conséquente, ceci de manière temporaire. En effet, l’ensemble des GPOs de votre domaine étant modifiées par la partie gpprep du setup, toutes ces modifications doivent être répliquées sur l’ensemble des DCs, le répertoire de staging voit alors sa taille augmenter tant que le DC répliquant le moins souvent n’a pas répliqué les modifications, cette taille baisse au fur et à mesure que ce DC réplique les modifications sur son partage SYSVOL.

2. Commande adprep /rodcprep:

Si vous rencontrez le message d’erreur suivant: “Adprep could not contact a replica for partition DC=DomainDnsZones,DC=ldap389,DC=info“, alors il vous suffit de lancer le script correctif fournit dans cette KB.

Si vous désirez lire plus d’articles concernant les erreurs avec adprep je vous conseille la lecture de cet article technet et de ce post de askDS.

Les principaux problèmes rencontrés sont apparus lors du lancement de la commande: “setup.com /PrepareAD /OrganizationName:<Organization Name>”. Nous allons voir la résolution  d’un problème bloquant et d’un warning.

1. Message d’erreur: “The Exchange organization name is invalid”:

Le setup sort en erreur avec le message d’erreur suivant, que l’on trouve dans le fichier Exchangesetup.log:

The Exchange organization name is invalid. Message: ‘The property value you specified, “{335A1087-5131-4D45-BE3E-3C6C7F76F5EC}”, isn’t valid. The value must not contain “‘~’, ‘`’, ‘!’, ‘@’, ‘#’, ‘$’, ‘%’, ‘^’, ‘&’, ‘*’, ‘(‘, ‘)’, ‘_’, ‘+’, ‘=’, ‘{‘, ‘}’, ‘[', ']‘, ‘|’, ‘\’, ‘:’, ‘;’, ‘”‘, ”’, ‘<’, ‘>’, ‘,’, ‘.’, ‘?’, ‘/’”.’

Cela est du au fait qu’une précédente préparation du schéma pour Exchange 2003 a été réalisée, ceci sans qu’aucun serveur Exchange n’ai été installé dans votre domaine. La commande setup /forestprep créé un nom d’organisation temporaire avec le GUID mentionné ci dessus lors du lancement de la preparation de schéma pour Exchange 2003. Le nom d’organisation définitif n’est définit que lors de l’installation du premier serveur Exchange. Pour plus de détails sur l’extension de schéma pour Exchange 2003 vous pouvez lire cet article. Dans les versions suivantes de Exchange, le nom de l’organisation est donné lors de la préparation du schéma AD.

Pour corriger cela il vous suffit d’utiliser le CD d’installation Exchange 2003 et de lancer la commande “Setup /removeorg”, ceci afin de supprimer l’organisation temporaire (voir cette KB pour plus de détails). Puis de relancer votre commande “setup.com /PrepareAD /OrganizationName:<Organization Name>” avec les sources Exchange 2010.

Ce problème a déjà été evoqué sur un forum technet pour Exchange 2007, nous avons rencontré le même problème pour la preparation du schéma Exchange 2010. La même résolution est proposée.

2. Warning: The recipient “ldap389.info/users/test-user” is invalid and couldn’t be updated:

Ce message d’avertissement ne bloque pas l’extension de schéma Exchange 2010. Mais peut poser problème lorsque la BAL pour test-user sera configurée. L’attribut MailNickName du compte possédait une valeur, cet attribut existait sur les comptes du domaine (apporté par la précédente modification de schéma Exchange 2003) mais a été utilisé pour les besoins d’une autre application que Exchange. La valeur de l’attribut a donc du être nettoyée afin d’éviter ces warnings

L’application et la réplication des GPOs dans notre domaine fonctionnait normalement, par contre l’édition des stratégies de groupe sur le DC impacté devenait impossible, en même temps que la GPMC freezait une surcharge CPU du process lsass.exe survenait sur le contrôleur de domaine et ceci tant que la GPMC n’était pas killée sur la console. Nous avons donc continué à éditer nos GPOs à partir d’autres DCs et le fonctionnement de la production était quasi-normal le temps de la résolution de l’incident.

Afin de mieux comprendre le problème, la première chose à faire est de lancer lors du freeze de GPMC une analyse avec Server Performance Advisor sur le DC dont voici le résultat:

On voit que le DC a du mal à effectuer une recherche LDAP initiée par la GPMC et cela entraine une consommation anormale du process lsass.exe, afin d’en savoir plus nous réalisons deux analyses de trames avec WireShark sur nos consoles d’administration: La première en reproduisant le problème en lançant la GPMC connecté au DC impacté, la seconde en connectant la GPMC à un autre DC et sur lequel l’édition de GPOs est possible:

On voit que sur le DC posant problème la requête LDAP n’aboutit pas, au bout de plus de 2 minutes toujours pas de résultat. Lors d’un fonctionnement normal de la GPMC, les GPOs liées à notre OU sont trouvées en quelques secondes.

Il nous faut maintenant identifier quelle requête LDAP n’arrive pas à traiter notre DC, pour cela nous allons activer le diagnostique Active Directory Field Engineering, l’événement d’ID 1644 sera alors généré lorsque le problème survient, celui ci est caractéristique d’une requête LDAP consommant trop de ressources. Une fois l’audit activé, nous avons alors l’événement suivant qui apparaît lors du freeze de GPMC:

Les valeurs retournées par la requête sont GPLink et GPOptions (on peut d’ailleurs observer le résultat sur la capture de trames réseau).  Le filtre de recherche se fait sur ObjectCategory qui est un attribut indexé par défaut de la base AD. La requête LDAP devrait donc être réalisée rapidement, ce qui n’est pas du tout le cas, nous en avons malheureusement la confirmation en lançant la même requête avec ldp.exe, le résultat est le suivant:

———–
***Searching…
ldap_search_ext_s(ld, “DC=ldap389,DC=info”
, 2, “( |  (objectCategory=CN=Domain-DNS,CN=Schema,CN=Configuration,DC=ldap389,DC=info)  (objectCategory=CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=ldap389,DC=info) )”, attrList,  0, svrCtrls, ClntCtrls, 10, 0 ,&msg)
Error: Search: Timeout. <85>
Server error:
Error<94>: ldap_parse_result failed: No result present in message
Getting 0 entries:
———–

La requête tombe en Timeout, alors que sur les autres DCs aucun problème avec celle ci. Nous avons donc décidé dans un premier temps d’augmenter la valeur du paramètre MaxQueryDuration des stratégies LDAP de notre DC, ainsi que de configurer ldp.exe afin d’augmenter la période de TimeOut. Ces manipulations n’ont servi à rien.

Après quelques recherches nous sommes tombés sur cet article très instructif de Tim Springston. Il affirme que:

“if the attribute(s) which are showing as taking an extended amount of time to search for are already indexed then the lack of an index is clearly not your problem.  Sometimes indices, perhaps through frequent changes or other reasons, need to be re-indexed to remove “whitespace” or other problems.  So checking the integrity of the database or doing an offline defrag may be the way to go.”

Procédons donc d’abord à une analyse sémantique du ntds.dit de notre DC:

Le résultat est immédiat: des inconsistances dans la base ont été trouvées. Nous relançons cette fois la même analyse sur la base, mais en mode “fixer les problèmes” (voir point 11 de la KB). Pour terminer nous réalisons une défragmentation offline du ndts.dit et nous quittons le mode DSRM pour rebooter notre DC normalement.

Une fois le DC redémarré nous essayons d’utiliser la GPMC en étant connecté sur le DC qui posait problème: L’utilisation de l’éditeur de stratégies de groupe se fait normalement et nous pouvons à nouveau éditer des GPOs sur ce contrôleur de domaine.

 
On Error Resume Next
 
'Input domain's distinguishedname
DomainDN = "dc=ldap389,dc=info"
 
Const ForAppending = 8
Const ADS_SCOPE_SUBTREE = 2
 
'We search for objects stale since 6 months
dtmDateValue = DateAdd("m", -6, now)
 
Set objShell = CreateObject("Wscript.Shell")
lngBiasKey = objShell.RegRead("HKLMSystemCurrentControlSetControl" _
    & "TimeZoneInformationActiveTimeBias")
If (UCase(TypeName(lngBiasKey)) = "LONG") Then
    lngBias = lngBiasKey
ElseIf (UCase(TypeName(lngBiasKey)) = "VARIANT()") Then
    lngBias = 0
    For k = 0 To UBound(lngBiasKey)
        lngBias = lngBias + (lngBiasKey(k) * 256^k)
    Next
End If
 
' Convert datetime value to UTC.
dtmAdjusted = DateAdd("n", lngBias, dtmDateValue)
 
' Find number of seconds since 1/1/1601.
lngSeconds = DateDiff("s", #1/1/1601#, dtmAdjusted)
 
' Convert the number of seconds to a string
' and convert to 100-nanosecond intervals.
str64Bit = CStr(lngSeconds) & "0000000"
 
Set fso = CreateObject("Scripting.FileSystemObject")
 
CibleFileOU = "Resultsusers.csv"
CibleFileOU2 = "Resultscpu.csv"
 
Set df3 = fso.OpenTextFile(CibleFileOU,ForAppending,True)
Set df4 = fso.OpenTextFile(CibleFileOU2,ForAppending,True)
 
Set objConnection = CreateObject("ADODB.Connection")
Set objCommand =   CreateObject("ADODB.Command")
objConnection.Provider = "ADsDSOObject"
objConnection.Open "Active Directory Provider"
Set objCommand.ActiveConnection = objConnection
 
objCommand.Properties("Page Size") = 1000
objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE 
 
objCommand.CommandText =_
    "SELECT DistinguishedName,sAMAccountName,lastLogonTimestamp FROM 'LDAP://"&DomainDN&"' WHERE objectCategory='user' AND lastLogonTimestamp < '"&str64Bit&"'"
 
Set objRecordSet = objCommand.Execute
 
objRecordSet.MoveFirst
Do Until objRecordSet.EOF
 
disting = objRecordSet.Fields("DistinguishedName").Value
SAM = objRecordSet.Fields("sAMAccountName").Value
Set StrFlagMCP = objRecordSet.Fields("lastLogonTimestamp").Value
 
           intLastLogonTime0 = StrFlagMCP.HighPart * (2^32) + StrFlagMCP.LowPart
           intLastLogonTime0 = intLastLogonTime0 / (60 * 10000000)
           intLastLogonTime0 = intLastLogonTime0 / 1440
           'Convert lastlogontimestamp in date format
           StrFlagPwd = intLastLogonTime0 + #1/1/1601#
 
df3.writeline(SAM&";"&StrFlagPwd&";"&disting)
 
objRecordSet.MoveNext
Loop
 
objCommand.CommandText =_
    "SELECT DistinguishedName,sAMAccountName,lastLogonTimestamp,WhenCreated FROM 'LDAP://"&DomainDN&"' WHERE objectCategory='user' AND NOT lastLogonTimestamp = '*'"
 
Set objRecordSet2 = objCommand.Execute
 
objRecordSet2.MoveFirst
Do Until objRecordSet2.EOF
 
disting = objRecordSet2.Fields("DistinguishedName").Value
SAM = objRecordSet2.Fields("sAMAccountName").Value
LastLOG = objRecordSet2.Fields("lastLogonTimestamp").Value
Whencreate = objRecordSet2.Fields("WhenCreated").Value
 
df3.writeline(SAM&";NEVER LOGGED;"&disting&";"&Whencreate)
 
objRecordSet2.MoveNext
Loop
 
objCommand.CommandText =_
    "SELECT DistinguishedName,sAMAccountName,lastLogonTimestamp FROM 'LDAP://"&DomainDN&"' WHERE objectCategory='computer' AND PwdLastSet < '"&str64Bit&"'"  
 
Set objRecordSet3 = objCommand.Execute
 
objRecordSet3.MoveFirst
Do Until objRecordSet3.EOF
 
disting = objRecordSet3.Fields("DistinguishedName").Value
SAM = objRecordSet3.Fields("sAMAccountName").Value
 
set StrFlagMCP = objRecordSet3.Fields("lastLogonTimestamp").Value
 
           intLastLogonTime0 = StrFlagMCP.HighPart * (2^32) + StrFlagMCP.LowPart
           intLastLogonTime0 = intLastLogonTime0 / (60 * 10000000)
           intLastLogonTime0 = intLastLogonTime0 / 1440
           StrFlagPwd = intLastLogonTime0 + #1/1/1601#
 
df4.writeline(SAM&";"&StrFlagPwd&";"&disting)
 
objRecordSet3.MoveNext
Loop
 
df3.close
df4.close
 
msgbox "done!

Pour télécharger le vbs c’est ici:

Changer la valeur de DomainDN en indiquant le DistinguishedName de votre domaine, ici on recherche les objets inactifs depuis 6 mois, changer la valeur dtmDateValue si vous désirez utiliser un autre seuil.

Les résultats concernant les comptes utilisateurs sont retournés dans le fichier Resultsusers.csv. Pour les comptes dont le LastLogonTimeStamp est nul, la date de création du compte est indiqué, car un utilisateur dont le compte a été créé il y a quelques jours peut ne s’être toujours pas logué. Une fois le tri fait vous pouvez désactiver les comptes avant de les supprimer, si il n’y a pas de retour de la part de votre hotline d’ici quelques semaines alors vous pourrez les supprimer.

Les résultats concernant les comptes ordinateurs sont retournés dans le fichier Resultscpu.csv , attention certains objets ordinateurs de votre AD dont l’OS n’est pas Windows (serveurs CIFS, OS X…) ainsi que les objets Microsoft Cluster Server Virtual Server peuvent ne pas mettre à jour leur attribut PwdLastSet, il faudra les exclure de votre liste.

Nous allons maintenant nous intéresser aux objets de stratégie de groupe inutiles dans votre domaine. Pour cela il vous suffit d’utiliser les scripts fournis avec la GPMC qui se trouvent dans %programfiles%gpmcscripts. Nous allons simplement lister les GPOs désactivées et non liées avec les scripts FindDisabledGPOs.wsf et FindUnlinkedGPOs.wsf. Si il s’avère que vous ne vous servez plus de ces GPOs vous pouvez les supprimer.

Bien maintenant vous avez supprimé tous ces objets et la taille votre ntds.dit n’a pas bougé et cela pour deux raisons:

Tout d’abord vos objets effacés sont tombstonés, ils ne sont pas encore supprimés del’AD et cela pour une période de 60 ou 180 jours (paramétrage par défaut), c’est le TombstoneLifeTime, ceci de façon à être réanimés facilement en cas de suppression accidentelle, une partie des attributs sont effacés mais pas tous. Pour plus d’informations sur le détail des attributs sauvegardés voir cet article. Par ailleurs pour les réanimation d’objets du Tombstone je vous conseille ADRestore.NET qui est la version graphique de ADrestore. Si vous avez activé la corbeille sous 2008, ces outils ne vous sont pas utiles.

Si vous etes une personne pressée vous pouvez réduire ce TombstoneLifeTime avec adsiedit.msc en changeant la valeur (exprimée en jours) de l’attribut tombstonelifetime dans la partition de configuration cn=directory service,cn=windows nt,cn=services,cn=configuration,dc=<forestDN>. Attention cette manipulation peut s’avérer dangereuse, le TombstoneLifeTime ne doit jamais être inférieur au délai de réplication d’un objet au sein de toute votre forêt. Une fois tous les objets réellement supprimés du Tombstone n’oubliez pas de remettre la valeur par défaut à votre attribut tombstonelifetime. Par ailleurs ci une suppression accidentelle a lieu pendant que vous avez réduit la valeur de cet attribut vous riquez de devoir restaurer les comptes avec un backup. Ce paragraphe est à titre informatif, ne pas utiliser cette méthode si vous considérez que c’est trop risqué.

La deuxième raison est qu’une fois tous les objets supprimés du Tombstone il faut défragmenter le fichier ntds.dit hors ligne. Nous allons avant cela activer un audit afin de voir quel gain de place nous pouvons espérer d’une telle défragmentation. Pour cela activer sur vos DCs le diagnostic de garbage collection, une fois la valeur 6 Garbage Collection de la clef HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSDiagnostics égale à un nous avons un événement d’ID 164 enregistré dans le journal d’évènements lors de chaque défragmentation en ligne de la base (toutes les 12heures).

Sur l’exemple donné, le gain est de 584Mo si nous effectuons une défragmentation hors ligne. Il s’agit d’un cas extrême, n’espérez pas gagner autant de place sur votre environnement, à moins d’avoir supprimé quelques dizaines de milliers d’objets. Ensuite il ne vous reste plus qu’à suivre la procédure fournie par Microsoft.

Cette procédure prend de 5 à 10 minutes, hors temps de reboot en mode DSRM sous Windows 2003, en 2008 il vous suffit de stopper le service AD. Vous devrez effectuer cette opération sur chacun des DCs car ce gain de place ne se réplique évidemment pas. Ce sont les changements sur les objets qui sont répliqués et non la base elle même.