F.A.Q

Mise a jour  par FTP
Upload fichier de configuration par le ftp

Reboot par SSH
Se connecter avec Putty et commande reboot

Modifier regedit (Admin)
ou CMD (Admin)

REG ADD HKLM\\\\SYSTEM\\\\CurrentControlSet\\\\Services\\\\PolicyAgent /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 0x2 /f

REG ADD HKLM\\\\SYSTEM\\\\CurrentControlSet\\\\Services\\\\RasMan\\\\ /v ProhibitIpSec /t REG_DWORD /d 0x0 /f

et modifier les propiété de la carte réseau (Onglet securité – 2 coches Protocol CHAP

Pour lancer le processus d’archivage, il vous faut :

1. Un PC Std Windows
2. Installer le module supplémentaire dans PowerShell pour Exchange
3. Se connecter au compte admin de la console Exchange
4. Lancer la commande d’archivage

Dans les détails

Ouvrir l’app PowerShell (PS) sur le PC (en utilisateur Admin)
Install-Module ExchangeOnlineManagement

Ouvrir une 2ème fenêtre PS pas admin

Import-Module ExchangeOnlineManagement

Connect-ExchangeOnline

Start-ManagedFolderAssistant -Identity [Adresse mail a archiver]

Pour voir le status

Get-Mailbox [Adresse mail a archiver] | Start-ManagedFolderAssistant

Plus de détail

&([scriptblock]::Create((irm « https://debloat.raphi.re/ »))) -RunDefaults

Les référence:

https://github.com/Raphire/Win11Debloat
https://www.youtube.com/watch?v=Q7DmD8dtNws
https://www.ecosia.org/search?tt=mzl&q=win11debloat

Les maîtres d’opérations peuvent être déplacés d’un contrôleur à un autre pour des raisons de performances ou de bonnes pratiques. Les cas les plus fréquents sont cependant une migration ou pire un crash d’un contrôleur. Nous allons donc voir dans un premier temps comment localiser les maîtres d’opérations dans votre infrastructure et ensuite comment les déplacer celons les différents cas de figure.

Si vous désirez plus d’information sur les maîtres d’opérations, nous vous engageons à lire notre article Les maitres d’opérations Active Directory.

Microsoft a également réalisé un KB très complet sur la localisation des rôles que vous pouvez consulter ici.

Localiser et déplacer les maîtres d’opérations par l’interface graphique

Nous allons débuter par l’utilisation de l’interface graphique pour localiser et déplacer les 5 rôles. En effet, l’interface graphique permet de réaliser les deux opérations de façon similaire. Bien entendu, les deux possibilités n’ont pas les mêmes implications cependant nous avons trouvé plus pertinent de les regrouper.

Localisons dans un premier temps les maîtres d’opérations de niveau domaine (Maître RID, Maître d’infrastructure et émulateur PDC) en ouvrant la mmc « Ordinateurs et utilisateurs Active Directory » depuis «Démarrer » | « Outils d’administration ». Réalisons ensuite un clic droit sur la racine « [MONDOMAINE] » et sélectionner « Maîtres d’opérations… ».

·

http://www.alexwinner.com/images/stories/20_move_FSMO/1/image001.png

Nous avons dès lors accès à trois onglets pour chacun des rôles «RID », « CPD » et « Infrastructure ». Le champ « Maître d’opérations » indique quel est le contrôleur détenteur du rôle. Le deuxième champ indique tout simplement quel est le serveur sur lequel la console est connectée.

Nous pouvons voir également le bouton « Modifier… » qui permet justement de déplacer le rôle. Il faudra cependant réaliser cette action depuis le serveur devant accueillir le rôle car vous n’avez pas la possibilité de choisir un contrôleur spécifique à partir d’une liste. Le deuxième champ sert justement à identifier clairement vers quel serveur vous vous apprêtez à transférer le rôle.

· http://www.alexwinner.com/images/stories/20_move_FSMO/2/image003.pnghttp://www.alexwinner.com/images/stories/20_move_FSMO/2/image005.png

·

· http://www.alexwinner.com/images/stories/20_move_FSMO/2/image007.png

Concernant les deux autres maîtres d’opérations, de niveau forêt, il faudra accéder à deux interfaces graphiques différentes.

Pour localiser le maître d’attribution de noms de domaine, ouvrez la mmc « Domaines et approbations Active Directory » et sélectionnez « Maître d’opérations… » à l’aide d’un clic droit directement sur la racine « Domaine et approbations Active Directory ». La fenêtre «Maître d’opérations » se présente exactement sous la même forme que précédemment et « Modifier… » s’utilise dans les mêmes conditions.

· http://www.alexwinner.com/images/stories/20_move_FSMO/3/image009.png

· http://www.alexwinner.com/images/stories/20_move_FSMO/3/image011.png

Pour le dernier maître d’opérations Maître de schéma, nous allons passer par la mmc « Schéma Active Directory », toutefois la console n’est pas disponible par défaut et il faut inscrire au préalable sa DLL. Depuis « Executer », lancer la commande « regsvr32 schmmgmt.dll ».

· http://www.alexwinner.com/images/stories/20_move_FSMO/4/image013.png

Une fois la commande exécutée, lançons « mmc » toujours à partir de « Executer ». Depuis mmc, aller dans « Fichier » | « Ajouter/Supprimer un composant logiciel enfichable… », sélectionner le composant logiciel enfichable « Schéma Active Directory » et cliquer sur «Ajouter ».

· http://www.alexwinner.com/images/stories/20_move_FSMO/5/image015.png

· http://www.alexwinner.com/images/stories/20_move_FSMO/5/image017.png

· http://www.alexwinner.com/images/stories/20_move_FSMO/5/image019.png

Désormais, nous avons le logiciel composant enfichable « Schéma Active Directory » à notre disposition. Double-cliquons sur la racine pour nous connecter sur le serveur local et accéder aux différentes propriétés. Sélectionnons «Maître d’opérations… » à l’aide d’un clic droit pour enfin afficher le nom du contrôleur désigné comme maître de schéma et pour en changer le cas échéant et si nécessaire.

· http://www.alexwinner.com/images/stories/20_move_FSMO/6/image021.png

· http://www.alexwinner.com/images/stories/20_move_FSMO/6/image023.png

Localiser et déplacer les maîtres d’opérations par l’invite de commandes

La ligne de commande est plus efficace pour localiser rapidement les maîtres d’opérations. En effet, l’usage de l’interface graphique nécessite l’accès à trois mmc différentes et l’enregistrement d’une DLL pour obtenir ces informations alors qu’une simple commande va nous permettre d’obtenir le même résultat. Nous avons la possibilité d’utiliser par exemple l’outil NETDOM, DCDIAG ou NTDSUTIL.

Remarque : Les manipulations réalisées ci-dessous sont faites sur un contrôleur « W2K3 » disposant des 5 rôles pour le domaine « domaine.local ».

« NETDOM » est l’outil fournissant le résultat le plus clair. Il suffit de saisir « netdom query /domain:[MONDOMAINE] fsmo » à partir de l’invite de commandes pour obtenir la liste des maîtres d’opérations et les serveurs associés.

· http://www.alexwinner.com/images/stories/20_move_FSMO/6a/image002.png

Pour « DCDIAG » il suffira de lancer depuis l’invite de commandes « dcdiag /test:KnowsOfRoleHolders /v » et d’analyser le résultat au niveau de Démarrage du test : KnowsOfRoleHolders. Pour chaque rôle vous avez le CN du serveur détenant les rôles après CN=NTDS Settings.

· http://www.alexwinner.com/images/stories/20_move_FSMO/7/image025.png

«NTDSUTIL » est un peu plus complexe étant l’outil de maintenance Active Directory alors que DCDIAG n’est, quant à lui, qu’un outil d’analyse. Nous allons commencer par lancer la commande « ntdsutil » depuis l’invite de commandes. Ensuite il faudra saisir séquentiellement les commandes suivantes :

· roles

· connection

· connect to server [MONSERVEUR]

· quit

· select operation target

· list roles for connected server

· http://www.alexwinner.com/images/stories/20_move_FSMO/8/image027.png

Nous obtenons donc un résultat similaire à celui fourni par DCDIAG grâce à la commande « list roles for connected server ».

Remarque : Les manipulations réalisées ci-dessous sont faites sur un contrôleur « W2K8 » en liaison avec un contrôleur « W2K3 » disposant des 5 rôles pour le domaine « domaine.local ».

Pour déplacer les maîtres d’opérations depuis l’invite de commande, nous n’aurons pas d’autres choix que d’utiliser « NTDSUTIL ». Pour transférer un rôle, il faudra, comme à travers la mmc, se connecter sur le serveur qui l’accueillera et saisir les commandes suivantes :

· roles

· connection

· connect to server [MONSERVEUR]

· quit

· transfer PDC

· transfer RID master

· transfer infrastructure master

· transfer naming master

· transfer schema master

· http://www.alexwinner.com/images/stories/20_move_FSMO/9/image029.png

· http://www.alexwinner.com/images/stories/20_move_FSMO/9/image031.png

A chaque transfert, une demande de confirmation apparaîtra sous la forme d’un popup.

Forcer le déplacement des maîtres d’opérations

On parle en général de saisir les maîtres d’opérations ou encore plus communément on utilise le terme de seize. Cela correspond à forcer le transfert des rôles sans prévenir le contrôleur détenteur parce qu’il n’est pas possible de le faire autrement. En effet, quand un transfert des maîtres d’opérations est réalisé entre deux contrôleurs, le nouveau contrôleur prévient l’ancien contrôleur qu’il est désormais le maître d’opérations. Lorsqu’on réalise une opération de saisie des rôles, le nouveau contrôleur maître ne préviendra pas son homologue. Ce genre de manipulation est réalisé dans le cadre d’une avarie grave et irréparable d’un maître d’opération, qui n’étant plus joignable, ne peut réaliser le transfert des rôles dans un cadre normal.

ATTENTION !!! Lorsque les maîtres d’opérations sont saisis, il ne faut en aucun cas que le l’ancien contrôleur maître ressurgisse sur le domaine. En effet, n’étant pas au courant de cette saisie de rôles, ceci pourrait entraîner de lourdes conséquences.

Remarque : Les manipulations réalisées ci-dessous sont faites sur un contrôleur « W2K3 » disposant des 5 rôles et un contrôleur « W2K8 » qui va en prendre possession. Le domaine est « domaine.local ».

La saisie est réalisée par le biais de la commande « NTDSUTIL ». Lançons donc la commande « ntdsutil » depuis l’invite de commandes et exécutons les commandes suivantes :

· roles

· connection

· connect to server [MONSERVEUR]

· quit

· seize PDC

· seize RID master

· seize infrastructure master

· seize naming master

· seize schema master

A chaque demande de saisie, « NTDSUTIL » essayera toujours dans un premier temps de transférer si possible chaque rôle. En toute logique, cela échoue est génère une erreur car la prise de rôles forcée est liée à l’impossibilité de les transférer simplement donc ne tenez pas compte de l’erreur du type problem 502. Vous aurez également un popup qui apparaîtra pour valider la prise de rôle. Enfin, réalisez une vérification sur la saisie des rôles à l’aide de la commande « list roles for connected server ».

· http://www.alexwinner.com/images/stories/20_move_FSMO/10/image033.png

· http://www.alexwinner.com/images/stories/20_move_FSMO/10/image035.png

· http://www.alexwinner.com/images/stories/20_move_FSMO/10/image037.png

Une saisie des rôles induit donc qu’un contrôleur n’a pu être rétrogradé. Malgré son absence physique au sein de votre infrastructure, il est cependant toujours présent dans la base Active Directory. Nous aurons donc besoin de le supprimer manuellement de la base Active Directory une fois les rôles transférés. Cette opération s’appelle metadada cleanup et est détaillé dans un article Microsoft à votre disposition ici.

Conclusion

Nous avons donc vu dans cet article comme localiser et déplacer les maîtres d’opérations qui servira de point de départ à un prochain article sur les règles de placement pour assurer un fonctionnement optimal de votre annuaire Active Directory.

Configuration du Centro Business pour tout Internet sur le port 1 pour un VPN avec un Firewall suppl.
IP Passthrough Security Gateway

Lien sur la page Microsoft

Lien vers la page de Dell

Lien vers la page de malekal.com

En cours d’exécution slmgr /dlv génère une fenêtre contextuelle contenant de nombreuses informations sur l’état d’activation du système d’exploitation (OS) en cours d’exécution. Le résultat ressemble à ceci :

Numéro de build du système d’exploitation : Le numéro de build inclut une valeur qui identifie la version du système d’exploitation.
   N° 26100 : Windows Server 2025
20348 : Windows Server 2022
17763 : Windows Server 2019
14393 : Édition du système d’exploitation Windows Server 2016

Le slmgr /upk .

En cours d’exécution slmgr /upk Supprime la clé de produit du système d’exploitation en cours d’exécution. Le système d’exploitation n’est plus activé tant qu’une nouvelle clé n’est pas installée.

Le slmgr /ipk .

En cours d’exécution slmgr /ipk <key> installe une clé de produit dans le système d’exploitation en cours d’exécution. La validation de base est effectuée sur la clé fournie, mais la clé peut être acceptée et ne parvient toujours pas à activer le système d’exploitation.

Le slmgr /ato .

En cours d’exécution slmgr /ato force le système d’exploitation en cours d’exécution à tenter l’activation. Cela n’est pas souvent nécessaire, car l’activation doit se faire automatiquement après la saisie de la clé de produit.

Le slmgr /rearm .

En cours d’exécution slmgr /rearm sur une version d’évaluation de Windows réinitialise son minuteur d’activation à 180 jours. Il ne s’agit pas d’un substitut à l’octroi d’une licence appropriée au système d’exploitation, car cela ne peut être fait que quelques fois avant que le minuteur d’activation n’expire définitivement. Le nombre de réinitialisations restantes est indiqué dans la sortie du slmgr /dlv .