(modifié le 14 juin 2018 à 14:20)

Dans le cadre d'une migration d'une infrastructure existante vers une nouvelle version de Microsoft Exchange il peut être important d’exécuter des scripts sur des BAL hébergées uniquement sur la nouvelle ou l'ancienne infrastructure.

Voyons comment identifier si une BAL est stockée sur tel ou tel serveur, le tout en PowerShell.

Pourquoi ce script

Si votre nombre de base est restreint vous pouvez faire une recherche en spécifiant la banque de données. Cela fonctionne uniquement si chaque infra héberge des banques de données de façon indépendantes :

get-mailbox -identity <nom-utilisateur> | fl database

Avec Exchange 2016

Admettons que vos serveurs Exchange MBX 2010 se nomment :

• exch2016-mbx1
• exch2016-mbx2

Pour charger localement le module il est recommandé de faire :

. $env:ExchangeInstallPath\bin\RemoteExchange.ps1
Connect-ExchangeServer -auto -AllowClobber

Alternative 1 :

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

Alternative 2 (déconseillée car charge tous les modules) :

Add-PSSnapin *exch*

Puis lire la banque de donnée associée à un compte :

$serveur = ((get-mailbox -identity johndoe).ServerName).ToLower()

If ($serveur -eq "exch2016-1" -or $serveur -eq "exch2016-1") { write-host "nouvelle infra 2016" }
else { write-host"ancienne infra 2016" }

Ou plus simplement :

$serveur = ((get-mailbox -identity johndoe).ServerName).ToLower()

If ($serveur -like "exch2010-mbx*") { write-host "ancienne infra 2010" }
else { write-host"nouvelle infra 2016" }

Avec Exchange 2010

Seul le chargement du module 2010 diffère :

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010

Le reste du code ne change pas (voir ci-dessus).

Conclusion

Il ne vous reste plus qu'à remplacer le code au lieu de "write-host", tout comme le nom d'utilisateur ici en dur pour l'exemple qu'il faudra remplacer par votre variable dans un script qui parcourt les BAL.

Rien de bien compliqué, mais si jamais vous avez le même besoin... et puis de mon côté j'ai du écrire de bout de code pour éviter de générer des erreurs sur d'autres scripts powershell tournant sur Exchange 2010 et qui n'arrivent pas à tourner correctement avec BAL migrées sur Exchange 2016 (ils ne sont pas super copains dans ce sens-là).