Monday, October 16, 2017

Cisco - Catalyst 3560-CG : configuration (FR) - 1

English summary: I add a Cisco Catalyst 3560-CG switch to my test network and configure it via a USB to RJ45 console cable. Notes on the different modes (user, enable and configuration), securing access to the switch interfaces and basic "show" commands that display the switch configuration from various perspectives. Some knowledge of basic Cisco switch configuration is assumed.

***

Jusqu'à présent, les hôtes physiques de mon réseau d'essai étaient reliés les uns aux autres avec le commutateur intégré d'un pare-feu Cisco ASA. Cette solution de base fonctionnait assez bien mais se limitait à une bande passante de 100 Mbit/s alors que je voulais passer à 1 Gbit/s. Remplacer le pare-feu par un modèle plus récent était une option mais j'ai lu que les nouveaux ASA 5506 n'ont plus, justement, la fonction de commutation intégrée. Je ne sais pas si cela est exact d'ailleurs. Quoi qu'il en soit, j'avais un second objectif : ne pas oublier tout à fait les connaissances en matière de configuration de commutateurs acquises lors de ma certification CCNA et peu utilisées depuis.

J'ai donc fait l'acquisition d'un commutateur Cisco Catalyst 3560-CG. Après l'avoir déballé, je voulais en faire la configuration de base, ce qui ne va pas de soi dans la mesure où celle-ci ne peut se faire que par la console. En effet, les connexions Telnet et SSH sont désactivées par défaut. Autrefois, on accédait à la console par le port série de son ordinateur mais de nos jours ce genre de port n'existe presque plus. En revanche, on vend des câbles avec une interface USB à un bout et une interface RJ45 à l'autre, ce qui permet donc une connexion via un port USB dont à peu près tous les ordinateurs modernes sont dotés.

J'ai acheté le modèle suivant qui a l'avantage de ne nécessiter d'autres pilotes que ceux fournis avec le système d'exploitation Windows (Windows 7 dans mon cas - je ne peux rien garantir dans d'autres) :

USB Console Cable USB to RJ45 Cable

J'ai raccordé ainsi le commutateur à un portable et le lien semblait se faire. Dans le gestionnaire de périphériques, je vois s'ajouter le port "USB Serial Port (COM3)" :



Mais les pilotes qui rendent cette connexion possible ne suffisent pas. Ils ne me permettent ni de voir la configuration du commutateur ni d'envoyer les commandes pour la modifier. Il me faut un logiciel comme PuTTY ou TeraTerm.

J'ai choisi PuTTY dont le site de téléchargement se trouve à cet Url :

PuTTY

C'est un site digne de confiance et qui affiche d'ailleurs la signature de chaque version en MD5 et SHA qu'on peut vérifier après téléchargement. Nul besoin d'un logiciel spécial pour cela d'ailleurs. L'outil certutil le fait très bien :

certutil -hashfile [chemin vers le fichier téléchargé]

Il semble que SHA1 soit le hachage par défaut. Si vous voulez vérifier un autre hachage (comme MD5), il faut le préciser : 



Note : MD5 n'est plus sûr. Je ne l'utilise que comme exemple. Il faut préférer SHA1 ou mieux encore SHA2.

Mais revenons à la configuration de notre commutateur. Une fois PuTTY installé et ouvert, j'accède à la console avec les paramètres suivants :





Si tout se passe bien, je devrais me trouver à cette invite :

Switch>

Au départ, je suis en "mode utilisateur" ("user mode" ou "user EXEC mode"). Dans ce mode, nous pouvons voir des paramètres mais nous ne pouvons rien y changer. Pour cela, nous devons passer en "mode privilégié" ("privileged mode" ou "privileged EXEC mode" ou encore "enable mode"). Il suffit de taper le mot "enable" :


Note : le signe de l'invite passe de " > " à " # ".


Naviguer entre les modes - quelques remarques

En retenant les termes anglais d'origine, nous pouvons passer du mode "user" au mode "enable" avec la commande "enable" et du mode "enable" au mode "configuration" avec la commande "configure terminal" ou "config t" :

User mode -> Enable mode -> Configuration mode

Dans le mode configuration, nous pouvons revenir sur nos pas avec cette commande :

exit

Nous pouvons quitter le mode configuration (et n'importe quel sous-mode, comme "line console") avec cette commande :

end

Nous pouvons quitter le mode privilégié (et regagner le mode utilisateur) avec cette commande :

disable



Tout cela précisé, je veux maintenant accomplir les tâches suivantes :
  • Changer le nom d'hôte du commutateur. Par défaut, il est "switch".
  • Protéger l'accès au mode privilégié avec un mot de passe.
  • Protéger l'accès au commutateur par Telnet avec un mot de passe.
  • Chiffrer les mots de passe définis ci-dessus. Sinon, ils apparaissent en clair lorsqu'on affiche la configuration du commutateur. 


J'accomplis tout cela par les commandes suivantes (les mots de passe sont dissimulés derrière les cadres blancs) :



Quelques commentaires...

Encore une fois, il ne suffit pas de passer en mode privilégié pour configurer le commutateur. Il faut en plus saisir cette commande qui nous fait passer en mode configuration :

configure terminal

ou en abrégé :

config t

Je change le nom d'hôte à "SW1" avec cette commande :

hostname SW1

En fait, nous ferions mieux de choisir un nom conforme à notre protocole de nommage et qui ait un sens dans notre environnement. Pour cette présentation, le nom "SW1" suffira.

J'active le mot de passe pour le mode privilégié avec cette commande :

enable secret mot_de_passe

Une autre option existe : enable password. Cependant, cette commande génère un mot de passe en clair, ce qui est moins sûr que le mot de passe chiffré qui résulte de la commande enable secret. Nous devons donc préférer cette dernière.

Quant aux autres mots de passe, si nous voulons les chiffrer eux aussi, nous devons exécuter cette commande, de préférence avant de les définir :

service password-encryption

Ensuite, je définis un mot de passe pour la console et les connexions Telnet avec ces commandes :

- line console 0
-- password mot_de_passe
-- login
-- exit
- vty 0 15
-- password mot_de_passe
-- login
-- exit

C'est la commande "login" qui active le mot de passe. Dans la capture d'écran, vous remarquez peut-être que je l'ai oubliée pour la console. J'ai dû l'ajouter après. Puisqu'il n'y a qu'une seule connexion simultanée possible à la console, nous saisissons l'ensemble "line console 0" (compter à partir de 0) mais "vty 0 15" parce que le commutateur prend en charge jusqu'à 16 connexions Telnet simultanées (toujours en comptant à partir de 0) et nous voulons les protéger toutes.

Ainsi, la prochaine fois que je tenterai d'ouvrir une session, il faudra que je saisisse un mot de passe pour la connexion à la console et puis pour passer en mode privilégié ("enable mode") :




Nous venons donc de changer la configuration dite "courante" (running-config) du commutateur mais nous perdrions ces modifications si nous le faisions redémarrer (avec la commande reload, par exemple), sans exécuter la commande suivante :

copy running-config start-config

ou

copy run start

ou encore (une vieille commande toujours valable) :

wr

(pour "write").


Il s'agit là d'une configuration de base qui sécurise l'accès au commutateur et lui donne un nom d'hôte avec plus de sens. Nous pourrions encore configurer des messages qui s'affichent lors de la connexion du commutateur ainsi qu'une adresse IP qui permettrait une gestion à distance via Telnet ou SSH et encore autres choses. Ce sont là des sujets à traiter à l'avenir. A présent, cependant, je vais consacrer le reste de ce texte à l'affichage de certains paramètres du commutateur.

Note : je présente d'abord la commande complète et puis différentes formes abrégées.


show running-config

show run

sh run

Cette commande montre la configuration actuelle ou "courante" du commutateur (avec les changements que j'ai apportés surlignés en jaune) :

Building configuration...

Current configuration : 1105 bytes
!
! Last configuration change at 08:26:43 UTC Wed Mar 30 2011
! NVRAM config last updated at 08:27:01 UTC Wed Mar 30 2011
!
version 15.0
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname SW1
!
boot-start-marker
boot-end-marker
!
enable secret 5 $1$w0oU$Skn9l/1DGtFUDEEr3Tay51
!
no aaa new-model
system mtu routing 1500
!
[...]
!
spanning-tree mode pvst
spanning-tree extend system-id
!
[...]
!
vlan internal allocation policy ascending
!
[...]
!
interface GigabitEthernet0/1
!
interface GigabitEthernet0/2
!
interface GigabitEthernet0/3
!
interface GigabitEthernet0/4
!
interface GigabitEthernet0/5
!
interface GigabitEthernet0/6
!
interface GigabitEthernet0/7
!
interface GigabitEthernet0/8
!
interface GigabitEthernet0/9
!
interface GigabitEthernet0/10
!
interface Vlan1
 ip address dhcp
!
ip http server
ip http secure-server
!
!
!
line con 0
 password 7 151D1D03507E737C041D
 login
line vty 0 4
 password 7 10411F1651434A53202A
 login
line vty 5 15
 password 7 10411F1651434A53202A
 login
!
end

---


show start-config

show start

sh start

Si nous enregistrons nos modifications avec la commande "copy run start", les commandes "show run" and "show start" devraient afficher des données identiques.

---


show interfaces

sh int

Cette commande fournit des détails sur chacune des interfaces (ports) du commutateur y compris l'interface virtuelle VLAN1 et notamment son adresse IP :



Voici les détails sur l'interface GigabitEthernet0/1 :



Si nous estimons que ces détails sont surabondants, nous pouvons nous concentrer sur une interface spécifique avec ce genre de commande :

show interfaces GigabitEthernet0/1

sh int g0/1




Autre option : nous pouvons ajouter "status" pour une vision d'ensemble plus concise :

sh int status



En particulier, cet affichage nous montre si les paramètres Duplex et Speed ("vitesse" ou plutôt bande passante dans ce contexte) résultent d'une configuration automatique négociée ("auto-configuration") ou d'une configuration manuelle. Le préfixe a- indique l'auto-négociation, soit a-full et a-1000. Rappelons que les interfaces gigabit fonctionnent toujours en mode "full-duplex".

---


show ip interfaces

sh ip int 

Cette commande nous offre une autre perspective sur les paramètres des interfaces de notre commutateur :




Nous pouvons obtenir un affichage plus succinct avec cette commande :

sh ip int br




Et puis...

show protocols





Enfin, la commande show version fournit, entre autres, des détails sur la version du logiciel IOS, le fichier système pour IOS et le type de licence, ipbase par exemple :




Note : les captures d'écran ne montrent que les éléments que je voulais mettre en évidence. Il y en a d'autres.


***


En conclusion, les commandes que je viens de présenter permettent de sécuriser l'accès au commutateur et d'en voir la configuration par défaut ainsi que les quelques changements que j'y ai apportés. Il reste encore beaucoup d'autres paramètres que nous pouvons ajuster et dont certains seront traités dans des textes à venir.











Saturday, September 30, 2017

Windows 10 and Office 2016 : ADMX files for Group Policy

Until now, I've used Windows 7 (SP1) and Outlook 2010 (SP2) for my experiments with Office 365 / Exchange Online. In this blog post, I'll add Windows 10 and Office 2016 ADMX files (and language specific ADML files) to my Group Policy templates so I can manage features like "cached Exchange mode" for these versions just like I had done in the past for Windows 7 and Outlook 2010:

Manage Outlook 2010 with ADMX files

Note : we could add Windows 10 and Office 2016 ADMX files separately. There is no requirement to add them together. After all, we could be using Office 2016 with Windows 7 and in that case only the Office 2016 ADMX files would be necessary.


***


First, we need to download the Windows 10 and Office 2016 ADMX files:

Windows 10 ADMX files (1703)

Office 2016 ADMX files

Note: for Office 2016, we only need the ADMX and ADML files. We do not need the OPAX/OPAL files for Office customization.

I've downloaded both files (and prefixed the Office 2016 file with "O2016"):



Note that the Windows 10 file is a .msi file and the Office 2016 file an executable. In both cases, we must execute the files to extract the content, that is the ADMX (and ADML) files themselves. The Office 2016 ADMX files are extracted to the admx subfolder in the same folder as the downloaded executable: 



For now, we can ignore the content of the admin subfolder and the Excel (xlsx) file.

The actual ADMX files should look like this (with the ADML files in the language specific folders - Taiwan Chinese is visible in the screenshot below). In particular, there is an ADMX file for Outlook 2016 (marked with a red dot):




As for the Windows 10 ADMX files, they are extracted to the following location:




Once they are extracted, we need to copy both the Windows 10 and Office 2016 ADMX files from the locations above and paste them into the PolicyDefinitions folder of a domain controller, located here:

C:\Windows\SYSVOL\sysvol\mynet.lan\Policies\PolicyDefinitions

Note: on the domain controller, you can enter the UNC path to the location of the extracted files or map a drive or do whatever you prefer do transfer the extracted files to the PolicyDefinitions folder.

Yes, we can overwrite the existing files (if prompted to do so):


Says who?

Jeremy Moskowitz, for one:

What’s new in ADMX and Group Policy for Windows 1703 Creators Edition

The Windows 10 ADMX files will function with previous versions of Windows such as Windows 8.1 and Windows 7. Unlike the Office ADMX files (see below), we do not need OS specific files for Windows.

Normally, we will have no Office 2016 ADMX files present so the copy/paste operation should complete without additional prompts.

Remember to copy the appropriate ADML files to the corresponding language folder (we most likely will only have one or two, en-us or fr-fr, for example).

If you encounter this error:


You can backup the "winstoreui" admx and adml files (just in case) and then delete them. I eliminated the error without renaming any files. For more information, please see this discussion:

WinStoreUi error

Now if we open a GPO for editing, we should see a folder for Access, Excel, Outlook 2016 (etc.) next to whatever previous versions of Office we may have managed with Group Policy in the past: 




Moreover, we can now manage Windows 10 with Group Policy now that we have imported the Windows 10 AMDX files.




Saturday, September 16, 2017

Exchange 2016 - Désinstallation - 2

English summary: now that we have moved mailboxes to other databases and removed the databases on the server we intend to decomnission, we can begin the uninstall of Exchange 2016 itself.


***

Maintenant que nous avons déplacé toutes les boîtes à lettres vers des bases de données sur d'autres serveurs, et supprimé les bases de données du serveur que nous allons retirer du service (rappel : EX16-4), nous pouvons amorcer le processus de désinstallation lui-même.

Je vais voir l'état des files d'attente pour confirmer qu'elles sont vides. Nous ne voudrions pas perdre des messages importants :

Get-Queue

Get-Message [Indiquer le nom de la file d'attente ici]




Je vais donc tenter la désinstallation en utilisant la commande suivante :

setup.exe /mode:uninstall /IAcceptExchangeServerLicenseTerms

En fait, je rencontre à plusieurs reprises des messages d'erreur qui indiquent que tel ou tel service n'arrive pas à s'arrêter, dans ce cas le service MSExchangeADTopology :



Dans un autre cas, c'était le service Transport même si tout donnait à penser que le service était bel et bien arrêté :



Il a fallu faire redémarrer le serveur à plusieurs reprises. Chaque fois, la désinstallation a repris là où elle a calé. Après plusieurs essais, elle s'est enfin achevée :




Je constate ensuite que le programme de désinstallation supprime non seulement les connecteurs de réception d'EX16-4 (je m'y attendais) mais aussi la référence à EX16-4 parmi les serveurs source de notre seul connecteur d'envoi :






Dans l'interface graphique, nous verrions plutôt ceci :






Enfin, je voulais vérifier si mes clients pouvaient toujours accéder à leur BAL après la désinstallation d'Exchange 2016 sur le serveur EX16-4. A ma surprise, le premier à essayer, Mark Patel, ne le pouvait plus. L'outil de vérification de l'auto-configuration indiquait l'échec d'autodiscover :




C'est à cause de mon répartiteur de charge. J'ai mentionné au début de mon précédent texte qu'il faut parfois tenir compte de l'ensemble de l'environnement quand nous faisons des changements comme celui-ci. Après la désinstallation, je n'ai pas éteint le serveur et le répartiteur, pouvant encore communiquer avec lui, croyait qu'il était encore une cible valable pour les tentatives de connexion Outlook. Dans ce genre d'interaction, il vaudrait mieux configurer le répartiteur à vérifier la disponibilité d'un service plutôt que la disponibilité d'un serveur. Après tout, comme dans le cas présent, le serveur pourrait fonctionner parfaitement bien mais le service, au contraire, connaître des difficultés.

Voici à quoi cela ressemblait avant la mise hors tension du serveur EX16-4 :


Et après :




Cela corrigé, le répartiteur a commencé à ne diriger les clients que vers le serveur restant, EX16-3.

Friday, September 15, 2017

Exchange 2016 - Désinstallation - 1

English summary: after outlining the procedure to recover a failed Exchange server with the /recoverserver parameter in an earlier blog post, I now examine the process for an uninstall in normal conditions, that is, when the server remains fully operational. In this first blog post on the subject (a second post follows),  I look at migrating the mailboxes to other servers and removing databases, both single copy and those part of a Database Availability Group (DAG).


***

Dans un de mes textes précédents, j'ai envisagé un scénario où l'un de nos deux serveurs Exchange 2016 a une défaillance irréparable, ce qui nous a conduit à recourir à une réinstallation complète avec le paramètre /recoverserver:

Exchange 2016 (21) : récupération d'un serveur membre d'un DAG (1)

Dans ce texte-ci (et le suivant), je vais réviser la marche à suivre pour une désinstallation en circonstances normales, c'est-à-dire en utilisant l'applet "Programmes" ou "setup.exe" à la ligne de commande avec la paramètre "uninstall". De plus, je veux tenir compte de tous les aspects du processus dont la suppression des références au serveur retiré dans d'autres paramètres Exchange (parmi les "serveurs source" pour les connecteurs d'envoi, par exemple).

Note : il ne s'agit pas ici d'un scénario où nous retirons le dernier serveur Exchange de l'organisation. Dans ce cas-ci, il reste encore un serveur. Nous pourrions plutôt nous imaginer dans un scénario où nous remplaçons un vieux serveur par un nouveau.

Note : nos deux serveurs Exchange 2016 sont membres d'un DAG (Database Availability Group), ce qu'il faut garder à l'esprit quand nous démontons le serveur à retirer du service.

***

La désinstallation d'Exchange elle-même est un simple processus et ne semble pas avoir inspiré beaucoup de documentation. La plupart des articles concerne la résolution d'un blocage. Le meilleur article que j'aie trouvé pour la simple désinstallation, c'est le suivant, composé par Anderson Patricio (en anglais) :

Removing an Exchange Server Mailbox from your environment

Son article a le mérite de rappeler des aspects comme :
  • La désinstallation des logiciels de protection comme l'antivirus.
  • La désinstallation des logiciels de sauvegarde.
  • L'enlèvement des références au serveur dans des systèmes de gestion comme SCOM.
Il est donc utile de se rappeler que d'autres systèmes pourraient tenter de communiquer avec le serveur et qu'en retirant les objets qui le représentent ailleurs, nous pourrions au moins éviter la multiplication des messages d'erreur.

Quant à moi, je vais me concentrer sur les éléments d'Exchange eux-mêmes et laisser de côté les logiciels tiers qui pourraient se trouver sur notre système. Dans cette première partie, je vais montrer comment nous devons déplacer certains éléments (comme les boîtes à lettres) vers d'autres serveurs avant d'amorcer la désinstallation elle-même (que nous verrons dans la seconde partie).



***


Migrer les boîtes à lettres vers d'autres serveurs


La désinstallation d'Exchange échouera si le serveur en question abrite encore des boîtes à lettres (BAL). De ce fait, nous devons déplacer ces BAL vers d'autres serveurs. Ce processus diffère selon que nous sommes en présence d'une simple base de données de BAL ou d'une base de données faisant partie d'un DAG.

Dans mon environnement d'essai, j'ai deux serveurs Exchange : EX16-3 et EX16-4. C'est sur le second des deux que nous allons désinstaller Exchange 2016. Je vais commencer par voir quelles ressources résident sur EX16-3 compte tenu de la nécessité de les déplacer avant d'amorcer la désinstallation.

Note : nous pouvons déplacer les BAL entre bases de données mais nous ne pouvons pas déplacer des bases de données entre serveurs.

Nous avons deux bases de données : MBXDB-01 et MBXDB-03. La première fait partie d'un DAG et compte une copie sur chacun des deux serveurs Exchange. Nous nous en occuperons un peu plus tard. La seconde existe en une copie unique sur EX16-4, le serveur que nous allons retirer du service.

Get-MailboxDatabase


Note : vous pouvez cliquer sur les images pour les agrandir.


MBXDB-03 contient seulement deux BAL :

Get-MailboxDatabase MBXDB-03 | Get-Mailbox





Nous devrions nous souvenir que la commande Get-Mailbox n'affiche pas par défaut les boîtes à lettres système. Nous devons ajouter le paramètre -Arbitration pour les afficher :



Nous avons de la chance : toutes ces BAL se trouvent sur le serveur EX16-3. Nous n'avons donc pas besoin de les déplacer. Si, au contraire, j'avais besoin de déplacer ce genre de BAL, je pourrais revoir un de mes textes précédents à ce sujet (en anglais) :


Il suffit donc que je déplace les deux BAL : celle de Karen Roberts et celle de Mark Patel. Nous allons le faire à la ligne de commande avec l'applet de commande suivant, d'abord avec le paramètre -whatif et ensuite sans ce paramètre :

New-MoveRequest Karen.Roberts -TargetDatabase MBXDB-01 -Whatif



Nous pouvons suivre la progression de l'opération avec la commande...

Get-MoveRequest



Mais après un moment (je ne sais plus combien de minutes), je me rends compte que quelque chose cloche. Suite à quelques vérifications, je constate que l'index de contenu est en état d'échec, tant pour MBXDB-01 que pour MBXDB-03 :



J'apprends que cet état peut bloquer la migration d'une BAL vers une autre base de données. Il faut donc résoudre ce problème avant d'aller plus loin.


**********************************

Début de digression

Ce genre d'obstacle n'est pas la règle pour la migration d'une BAL et la désinstallation d'Exchange. Cependant, je tiens à en présenter la solution. Si vous ne rencontrez pas ce genre d'obstacle, vous pouvez sauter à la fin de la digression plus bas.

***

La marche à suivre consiste à supprimer l'index. A cette fin, nous devons arrêter les deux services suivants :

Stop-Service MSExchangeFastSearch
Stop-Service HostControllerService

Nous supprimons l'index, c'est-à-dire le répertoire entier qui le constitue. Voici l'exemple de l'index de la base de données MBXDB-03 :



Note : l'index se trouve dans le même répertoire (parent) que la base de données à laquelle il est associé.

 Après suppression de l'index, la base de données devrait rester seule (exemple de la base de données MBXDB-01) :


Supprimer l'index peut paraître une solution extrême mais il suffit de relancer les deux services arrêtés pour qu'il soit recréé :

Start-Service MSExchangeFastSearch
Start-Service HostControllerService


Note : ce processus pourrait prendre beaucoup de temps dans le cas d'une base de données volumineuse et constituer une charge lourde pour les ressources du serveur, ce dont il faudrait tenir compte dans un environnement de production.

Note : si nous avons un DAG, nous pouvons, en principe, reconstituer l'index à partir d'une bonne copie située sur un des autres serveurs. Dans notre cas, cependant, toutes les copies sont en état d'échec. Je n'exclus pas la possibilité qu'une particularité de mon environnement d'essai en soit la cause.

Peu à peu, les index sont remis en état :






Fin de digression

**********************************


Dès que les index retrouvent un état "sain", nous pouvons retenter la migration.

Cette fois-ci elle réussit :



Et nous faisons de même pour Mark Patel :





Supprimer les bases de données à copie simple

Maintenant que les boîtes à lettres ont été déplacées, je vais supprimer la base de données MBXDB-03 avec la commande suivante :

Remove-MailboxDatabase MBXDB-03 -Confirm:$false






Nous n'avons plus qu'une seule base de données (MBXDB-01) mais le message (en caractères jaunes) nous avertit que le fichier .edb de la base de données reste sur disque (ainsi que les fichiers des journaux de transaction). Nous allons éliminer ce serveur et nous pourrions sans doute les laisser tels quels mais je vais montrer comment les supprimer tout de même.

Remarque : mes bases de données sont sur le volume E: et les fichiers de transaction sur le volume F:

Nous supprimons le répertoire contenant les journaux de transaction avec cette commande :

F:\>Remove-Item MBXDB-03 -recurse

Et le répertoire contenant le fichier .edb et les index :

E:\>Remove-Item MBXDB-03 -recurse

Mais pourquoi supprimer les bases de données si nous allons de toute façon supprimer le serveur ensuite ? Parce que Exchange bloque la désinstallation tant qu'il abrite des bases de données. Ce serait une sorte de protection contre une désinstallation sans réflexion. 


Supprimer les bases de données (DAG)

En ce qui concerne la base de données MBXDB-01, nous sommes en présence d'un DAG, ce qui nous oblige à supprimer la copie qui se trouve sur le serveur EX16-4 mais sans toucher la copie du serveur EX16-3 :



Selon l'état de chacun des membres du DAG et des bases de données qu'il héberge, plusieurs obstacles pourraient se dresser devant nous.

Si le serveur à retirer (EX16-4 dans notre cas) tient la copie dite "active" de la base de données, nous ne pouvons pas le supprimer :



Nous activons la copie sur EX16-3 avec la commande suivante :

Move-ActiveMailboxDatabase MBXDB-01 -ActivateOnServer EX16-3



Si le serveur tient le rôle "PAM" du DAG, il faut déplacer le rôle avec la commande suivante (nul besoin de désigner un serveur particulier si le DAG ne compte que deux membres) :

Move-ClusterGroup "Groupe du cluster"




Nous pouvons vérifier qu'EX16-3 tient désormais le rôle grâce à cette commande :



Je ne sais pas pourquoi mais il semble que la copie active soit revenue sur EX16-4 et j'ai dû exécuter la commande plus haut à nouveau. En fin de compte, cependant, la copie active (et le "PAM") se trouve sur EX16-3 :




Maintenant, nous pouvons supprimer la copie de MBXDB-01 sur EX16-4...




Et sortir EX16-4 en tant que membre du DAG :




***


C'est ici que je vais prendre une pause avant de passer à l'étape suivante : la désinstallation elle-même d'Exchange 2016 sur EX16-4. A suivre (dans mon prochain texte).