Utilisation de /domainprep

journal Security, /domainprep
met à  jour la politique de sécurité
sur le DC local que le processus
Setup connecte pendant l’installation.
Win2K utilise ensuite FRS pour répliquer
le changement vers les autres DC
du domaine. (Pour plus d’informations
sur la réplication RFS, voir l’article
Microsoft, « FRS Replication Protocol
and Topology for SYSVOL Content » à 
http://support.microsoft.com/support/kb/articles/q220/1/40.asp.)

Dans certains cas, FRS ne réplique
pas correctement la politique de sécurité
mise à  jour sur un ou plusieurs DC
après que l’on exécute /domainprep. Si
FRS est ainsi défaillant et si un serveur
Exchange 2000 sélectionne l’un de ces
DC comme DC de configuration, le
service Information Store démarrera
correctement mais Exchange 2000 ne
sera pas capable de monter des bases
de données. (Pour savoir quel DC
Exchange 2000 utilise comme DC de
configuration sur des serveurs
Exchange 2000 et Exchange 2000 SP1,
vous pouvez vous servir de l’utilitaire
Dsadiag. Cet outil est disponible dans
le Microsoft Exchange 2000 Server
Resource Kit. Pour voir ces détails pour
des serveurs qui exécutent Exchange
2000 SP2, ouvrez la console Microsoft
Management Console -MMC –
Exchange System Manager (ESM), sélectionnez
le serveur, ouvrez sa boîte
de dialogue Properties et allez à  l’onglet
Directory Access.) Ce défaut est
ennuyeux et peut être difficile à  détecter
parce que tous les signes apparents
montrent que tout fonctionne parfaitement.
Si vous pensez que FRS a échoué,
vous pouvez examiner les Local
Security Settings sur le serveur
Exchange 2000 qui souffre du problème,
pour déterminer s’il y a eu réplication.
Pour ouvrir la boîte de dialogue
Local Security Settings,
sélectionnez Administrative Tools,
Local Security Policy. Dans le panneau
de gauche, étendez l’objet Local
Policies, puis étendez l’objet User
Rights Assignment. Examinez la politique
Manage auditing and security log
dans le panneau de droite. En théorie,
si la réplication de FRS a fonctionné
correctement, le groupe de sécurité local
Exchange Enterprise Servers sera
inclus dans l’ensemble de comptes et
de groupes figurant dans la colonne
Local Settings.

Dans l’exemple de la figure 1, c’est
le groupe de sécurité global Exchange
Domain Servers qui est indiqué – une
situation qui est survenue après qu’un
administrateur ait réparé la réplication
RFS en forçant le dossier SYSVOL à  répliquer
tous les DC dans le domaine.
Mais comme le groupe Exchange
Enterprise Servers inclut tous les
groupes Exchange Domain Servers à 
partir de tout domaine dans la forêt,
l’accès nécessaire est en place pour
laisser la fonction politique et pour
laisser Exchange 2000 monter les bases
de données. Le fait d’exécuter /domainprep
à  nouveau n’ajoutera pas le
groupe Exchange Enterprise Servers à 
la politique ; il faudra le faire manuellement.
Comme l’absence du groupe de
la politique ne pose pas de problème
dans ce cas particulier, il vous appartient
de décider si vous allez prendre le
temps de le faire ou non, pour pouvoir
revoir la situation lorsqu’apparaîtront
de futures versions et de futurs packs
de service Exchange.
Avant de modifier la politique sur
un DC, il faut confirmer que la réplication
FRS a copié la politique nécessaire
sur ce DC. La vérification manuelle de
chaque DC dans un grand domaine
prendrait beaucoup de temps, mais
Microsoft propose un utilitaire appelé
Policytest (policytest.exe dans le dossier
\i386\support du CD-ROM
d’Exchange 2000) qui s’en chargera.
Cet outil se connecte à  chaque DC du
domaine et vérifie que le groupe
Exchange Enterprise Servers a le privilège
de gérer le journal de sécurité et
d’audit, directement ou par héritage
(comme dans mon exemple). Pour
exécuter correctement Policytest, il
faut posséder les droits Domain
Admin. (Si vous voyez une erreur disant
!! LsaEnumerateAccountRights returned
error 5 !!, vous n’avez pas l’autorisation
d’ouvrir la Local Security
Authority – LSA – sur le DC.) Il est
conseillé d’exécuter Policytest un jour
ou deux après avoir exécuté /domainprep.