Bonjour à tous !

Aujourd'hui nous allons parler des produits QMM (Quest Migration Manager) et RUM (Resource Updating Manager).

Cet article s'adresse plus particulièrement aux personnes utilisant ce produit pour effectuer une migration de forêts AD contenant plusieurs sites Active Directory, donc plusieurs sites physiques différents.

En effet, pour effectuer des migrations utilisateurs/ordinateurs, les deux produits Quest font appel aux différents contrôleurs de domaine présents sur la forêt concernée.

Il peut arriver, pour des raisons pratiques, que vous vouliez migrer un utilisateur/ordinateur sur un contrôleur de domaine particulier.

Les paramètres de contrôleur de domaine préféré sont propres à chaque logiciel, ils sont donc à définir à la fois sur QMM et RUM suivant vos besoins.

Définition d'un contrôleur de domaine préféré pour QMM

1) Il faut d'abord déclarer une Domain Pair dans la console QMM avant de configurer le contrôleur de domaine préféré à utiliser.

2) Ouvrez les propriétés de l'Agent Manager en cliquant dessus.

3) Dans le menu de gauche, faites un clic-droit sur le nom de l'agent voulu et cliquez sur Properties.

4) Sélectionnez le domaine voulu et cliquez sur Edit.

5) Rentrez le contrôleur de domaine voulu dans les deux champs.

6) Le contrôleur de domaine préféré est configuré pour la migration des utilisateurs/groupes.

Définition d'un contrôleur de domaine préféré pour RUM

1) Il faut ouvrir l'éditeur de registre sur la machine où est installé RUM, puis aller à cet endroit de l'arborescence : HKLM\SYSTEM\CurrentControlSet\Services\QsRUMController

2) Une fois à cet endroit, il faut créer la clé config.

3) Une fois la clé crée, vous devez créer une entrée de type Chaîne (String).

La nomenclature du nom de la chaîne est importante.

Si le nom court (NetBIOS) du domaine voulu est DomainA pour le domaine DomainA.local par exemple, le nom de la chaîne doit être le suivant : DomaineAPreferredDC pour définir le contrôleur de domaine préféré sur le Domaine A.

4) La valeur de la chaîne correspond au FQDN du contrôleur de domaine voulu.

5) Il faut redémarrer la machine pour appliquer les modifications sur RUM.

Gérer Windows Server Update Services c’est bien, mais on n’a pas toujours envie de se connecter à un ou plusieurs serveurs pour le faire. Et si on troquait l’interface graphique pour Powershell ?

I- Les prérequis

• Depuis un poste client en Windows 7 :

Pour un poste en Windows 7 il faut installer le RSAT "Windows Server Update Services 3.0 SP2" disponible ici:

https://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=5216

• Depuis un serveur en Windows Server 2012 R2 :

Pour un serveur en Windows Server 2012 R2 il faut installer la fonctionnalité "Windows Server Update Services Tools"

II - Connexion au Serveur WSUS

Pour se connecter il va falloir déterminer 3 variables:

• Le nom du serveur WSUS
• L'utilisation ou non du SSL ($true ou $false)
• Le port de connexion (8530, 8531, 80 ou 443)

Dans l'exemple que j'utilise je me connecterai sur le port 8530 sans SSL, d'où la présence du $false.

$WsusServer = "Mon-Server-WSUS"
$WsusPort = "8530"
[void][reflection.assembly]::loadwithpartialname("microsoft.updateservices.administration")
$Wsus = [microsoft.updateservices.administration.adminproxy]::getupdateserver($WsusServer,$false,$WsusPort)

Avec ces 4 lignes vous êtes connecté au serveur WSUS, pour le vérifier rien de plus simple, appelez $Wsus

III - Cmdlet disponibles

Pour déterminer les actions possibles sur le serveur regardons les cmdlet disponibles, pour cela utilisons : 

$Wsus | gm

Comme vous pouvez le voir nous avons un grand nombre d'actions possibles.

Dans la prochaine partie nous verrons les informations que nous pouvons récolter avec quelques lignes de commandes.

Bonjour à tous !

Aujourd'hui, nous allons parler de la commande Netdom trust (nous allons donner plus de détails sur cette commande dans un prochain article).

Quand vous êtes dans le cadre d'une migration de forêt/domaine Active Directory, il est probable que vous vouliez autoriser l'utilisation des SidHistory afin de préserver les accès aux ressources du domaine historique pour les postes/utilisateurs migrés.

Pour se faire, nous utilisons deux commandes (depuis un contrôleur de la nouvelle foret) :

• netdom trust DomaineHistorique /D:NouveauDomaine /UO:Utilisateur_Nouveau_Domaine /PO:* /Quarantine:yes/no
•  netdom trust DomaineHistorique /D:NouveauDomaine /UO:Utilisateur_Nouveau_Domaine /PO:* /EnableSidHistory:yes/no

Mais que se passe t'il si vous entrez cette commande sur un contrôleur de domaine en langue française ?

Nous entrons donc la commande suivante afin d'avoir le statut de la mise en quarantaine des SID : netdom trust DomaineHistorique /D:NouveauDomaine /UO:Utilisateur_Nouveau_Domaine /PO:* /Quarantine

Nous voulons maintenant effectuer une action en désactivant la mise en quarantaine des SID : netdom trust DomaineHistorique /D:NouveauDomaine /UO:Utilisateur_Nouveau_Domaine /PO:* /Quarantine:no

Bizarre, nous obtenons le même message que pour la commande précédente ...

Après vérification, la commande n'a pas désactivé le filtrage.

En revanche, si vous entrez la version suivante de la commande, vous obtiendrez un résultat fort différent ! 

netdom trust DomaineHistorique /D:NouveauDomaine /UO:Utilisateur_Nouveau_Domaine /PO:* /Quarantine:non

Et voilà ! La commande marche enfin ! Elle n'a été traduite que pour un seul paramètre.

Il est à noter qu'il faut faire exactement la même chose pour le paramètre /EnableSidHistory.

Vous êtes désormais averti, ce bug est encore présent même sous Windows Server 2012 R2.