Extension support Exchange 2010

Bonjour à tous, juste une information importante pour vous dire que le support "Exchange 2010" a finalement été prolongé jusqu’au 13 Octobre 2020 par "Microsoft" alors qu'initialement le support devait se terminer le "14 Janvier 2020".

https://www.zdnet.fr/actualites/microsoft-prolonge-de-neuf-mois-le-support-technique-pour-exchange-server-2010-39890709.htm

Bonne nouvelle donc, ça vous laisse encore quelques mois pour migrer vers "Exchange 2016", "Exchange 2019" ou même mieux vers "Exchange Online".


A bientôt.

Migration Exchange 2013 vers Exchange 2019 en mode Hybride

Bonjour à tous, dernier article concernant la migration de notre infrastructure utilisé pour Office 365.

Dans les précédents articles, nous avions migré les éléments suivants:

- Migration d'un serveur "ADFS 2012 R2" vers un serveur "ADFS 2019" (voir article).

- Migration d' un serveur "Azure AD connect 2012 R2" vers un serveur "Azure AD Connect 2019" (voir article).

-Migration d'un serveur "WAP 2012 R2" vers un serveur "WAP Windows 2019" (voir article).

La dernière étape consiste à migrer notre serveur "Exchange 2013 mode Hybrid" vers notre serveur "Exchange 2019 installé sur un serveur Core 2019".

Notre serveur "Exchange 2013" utilise le mode "full Hybrid" avec "Exchange Online" et nous souhaitons conserver ce mode et donc le migrer vers "Exchange 2019" car certain clients souhaitent conserver ce mode.

Comme toujours, il est recommandé d'avoir une sauvegarde ou encore mieux de disposer d'un dag et de déplacer les boites mails avant toutes mise à jours pour éviter les impacts utilisateurs.

Le scénario de cette migration consiste seulement à l'installation d'un nouveau serveur Exchange 2019 dans l'organisation Exchange existante, ainsi qu'une configuration identique, à savoir:

- Configuration des connecteurs de réception.

- Ajout du nouveau serveur au connecteur d'envoie (si cela n'est pas géré par une autre passerelle SMTP).

- Ajout du certificat utilisé sur le serveur Exchange 2013

- Reconfiguration des url (Autodiscover, OWA, ECP, EWS, Active Sync....).

- Reconfiguration des load balancer, reverse proxy, antispam....

- Migration des boites mails encore existante ( Arbitration, autres boites mails existante...).

- Suppression de l'ancien serveur Exchange 2013.

- Reconfiguration du mode Hybrid.

!!!!Nous ne décrirons pas la migration Exchange 2013 vers Exchange 2019 car il  existe beaucoup d'articles sur internet!!!!!

Ci-dessous on peut voir que mon serveur Exchange est correctement installé

L'autodiscover a correctement été modifié à l'identique du serveur Exchange 2013

Les boites mails présentent encore sur le serveur Exchange ont correctement été migrées sur le nouveau serveur Exchange 2019

Les boites aux lettres d'arbritation ont correctement été migrées

Le certificat présent sur le serveur Exchange 2013 a été importé dans le nouveau serveur Exchange 2019.

Les connecteurs de réceptions ont été migrés (ce script fonctionne très bien).

S'il vous reste des dossiers publics (ce qui n'est pas mon cas dans mon labo) il faudra les migrer avec la commande suivante.

Get-mailbox -Database DB2013 -PublicFolder | New-MoveRequest -TargetDatabase DB2019

Nous vérifions que nous avons tout migré vers le nouveau serveur Exchange 2019:

get-mailbox -Database DB2019
get-mailbox -Database DB2019 -Arbitration
get-mailbox -Database DB2019 -Archive
get-mailbox -Database DB2019 -PublicFolder
get-mailbox -Database DB2019 -AuditLog

Une fois que vous avez la certitude d'avoir tout migré, nous allons supprimer les demandes de déplacement des différentes boites Exchange avec la commande suivante:

Get-MoveRequest | where {$_.status -match "Completed"} | Remove-MoveRequest

On vérifie qu'il n'existe plus de traces.

Get-MoveRequest

Une fois toutes les vérifications effectuées ci-dessus, il ne vous reste plus qu'à désinstaller le serveur Exchange 2013.

!!!!Attention pensez à désactiver temporairement l'antivirus, sinon la désinstallation peut être en échec!!!!

Pour désinstaller Exchange nous allons tout simplement aller dans la panneau de configuration du serveur Exchange 2013 et dans les programmes.

Une fois la désinstallation terminée je relance l'assistant hybride pour le reconfigurer avec le nouveau serveur Exchange.

Point important depuis Exchange 2019.

Si vous souhaitez faire de l'hybride avec de l'Exchange 2019 il vous faudra faire l'acquisition d'une licence.

Ce n'était pas le cas dans les versions précédentes car on pouvait avoir cette licence à travers la console office 365.

Voir le très bon article sur le site de "pratical 365"  https://practical365.com/exchange-server/how-to-licence-exchange-hybrid-servers/

L'hybride reconnait le nouveau serveur Echange

Entrer votre compte Office 365 ayant les droits.

Ci-dessous, on voit que l'option "Configuration hybride minimale" est grisée.

Normal car nous mettons à jour l'hybride existant qui est un hybride complet.

Nous allons maintenant configurer le serveur d'accès.

Nous cochons notre nouveau serveur Exchange 2019.

Même chose pour le connecteur d'envoi.

Nous sélectionnons notre certificat.

Nous configurons notre FQDN public.

Pour terminer, lancer la mise à jour.

Une fois la mise à jour hybride terminée, je vérifie sur la console Exchange On-premise la bonne configuration.

Mon serveur Exchange 2019 est bien autorisé sur le connecteur sortant vers office 365.

Egalement, si vous souhaitez encore faire des déplacements de boites mails entre Exchange On-Premise et Exchange Online, pensez à cocher la case "Proxy RMS" dans l'url "EWS" du serveur Exchange.

Une dernière note pour terminer. 

Si vous rencontrez le message d'erreur ci-dessous, ne vous inquiétez pas cela est surement du au fait que vous utilisez un proxy.

Suivez le lien ci-dessous et tout se passera bien.

https://expertslab.wordpress.com/2015/12/21/error-unable-to-access-the-federation-metadata-document-from-the-federation-partner/

Dans cet article nous avons vu comment monter de version un serveur Exchange 2013 en mode Hybride vers Exchange 2019.

Bon tests à tous. 😏😉😊

Calculateur de dimensionnement Exchange Server 2019

Bonjour, juste un petit article pour vous informer de la sortie du Calculateur pour "Exchange 2019".

https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Announcing-The-Exchange-Server-2019-Sizing-Calculator/ba-p/644180

Le calculateur pour "Exchange 2019" est comme avec la version "Exchange 2016" un fichier au format ".csv".

Il n'est pas téléchargeable mais sera disponible dans le prochain "CU2" d' "Exchange 2019".

Bonne lecture et à bientôt. 😏😏

Mise à jour CU Exchange 2019 en mode Core

Bonjour à tous.

Dans un épisode précédent nous avions vu comment installer "Exchange Server 2019" sur un serveur Core 2019".

Actuellement je travaille sur une série d'articles concernant la migration des serveurs utilisés pour Office 365 et les faire évoluer vers Windows Server 2019.

Lors de la migration de mon serveur Exchange 2013 vers Exchange 2019, je me suis rendu compte que mon nouveau serveur Exchange 2019 était resté en version "preview".

Donc c'est l'occasion d'écrire un petit article sur comment installer un "Cumulatif Update sur un serveur Exchange 2019 en mode Core".

La première chose à faire sera bien évidement de récupérer l'iso du "CU1" sur le site "https://www.microsoft.com/Licensing/servicecenter/default.aspx"

Vous devrez donc disposer d'un contrat Microsoft ou des accès privilégiés pour récupérer l'iso.

L'application de cumulatif pour "Exchange2019" fonctionne de la même façon que pour les versions 2013 et 2016.

Comme toujours, il est recommandé d'avoir une sauvegarde ou encore mieux de disposer d'un dag et de déplacer les boites mails avant toutes mise à jours.

Une fois le CU1 récupéré, nous allons commencer par mettre à jour le schéma en se connectant sur le serveur Exchange en mode core avec la commande ci-dessous:

.\Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms

La mise à jour c'est terminée correctement, nous pouvoir allons lancer l'installation du CU1 d'Exchange 2019.

Lancer la commande ci-dessous pour exécuter la mise à jour du CU:

.\Setup.exe /IAcceptExchangeServerLicenseTerms /Mode:Upgrade /DomainController:AD2012A.labdude.local

La mise à jour du CU s'est correctement effectuée. 

Nous vérifions la bonne application du Cumulatif Update soit en PowerShell:

Lancer la console Exchange Powershell avec la commande "LaunchEMS"

Lancer la commande ci-dessous:

Get-ExchangeServer -Identity "Exch2019A" | fl AdminDisplayVersion

Ou depuis la console d'administration Exchange.

Ci-dessous un lien pour vérifier les Builds des versions Exchange.

https://social.technet.microsoft.com/wiki/contents/articles/15776.exchange-server-2013-2016-and-2019-build-numbers-with-cumulative-updates.aspx

Dans cet article, nous avons pu voir comment mettre un jour un serveur Exchange 2019 en mode core avec le dernier "Cummulatif update".

A bientôt. 😏😉😊

Maintenance d'un DAG Exchange 2019

Bonjour à tous, nouvel article sur Exchange 2019.

Aujourd'hui, nous allons voir comment mettre en maintenance un DAG sur Exchange 2019.

Dans le dernier épisode, nous avions pu voir la mise en place d'un DAG Exchange 2019, mais qui dit produit Microsoft dit bien évidemment mises à jour de nos serveurs Exchange (Cumulatifs Windows Server, Rollup Exchange..).

L'exemple le plus marquant pour la mise en maintenance d'un nœud Exchange sera bien évidement le passage d'un rollup Exchange.

L'installation d'un rollup Exchange  mettra hors connexion votre noeud, puisque le rollup désinstalle complètement l'application pour la réinstaller avec la nouvelle version.

Mais les questions qui reviennent le plus souvent sont les suivantes:

- Mais pourquoi mettre en maintenance un serveur Exchange  alors que je passe mes rollup le soir ou le Week-end?

- Mais pourquoi mettre en maintenance un serveur Exchange car je trouve que cela prend beaucoup de temps à faire toutes ces manipulations?

Comme toutes mises à jours il y a des phénomènes que l'on ne peut pas toujours anticipés, tout ne se passe pas comme prévu (il faut reconnaître qu'il n' y a plus beaucoup de problèmes, Microsoft ayant fait beaucoup d'effort sur la façon d'installer un nouveau rollup).

Chacun doit prendre conscience que l'on doit prendre un maximum de précautions même si cela doit prendre un peu plus de préparation.

Les avantages d'un DAG sont les suivants:

- Eviter de perdre des données et de rendre indisponible une base de données.
- Possibilité de passer un rollup en pleine Journalisée sans impacts sur les utilisateurs
- Possibilité de passer des cumulatifs update et redémarrer le serveur en pleine journée
- Possibilité de prendre du temps pour investiguer un problème matériel

Pour mettre un nœud Exchange en maintenance, nous n'allons pas utiliser le scripts présents par défaut dans le répertoire des binaires Exchange car je trouve qu'ils ne fonctionnent pas très bien donc je ne les recommande pas. (voir ci-dessous).

Nous allons en détails effectuer les différentes commandes.

Il est très important de comprendre le fonctionnement de mise en maintenance d'un nœud Exchange configuré dans un DAG.

Une fois que l'on maîtrise les différentes commandes on pourra automatiser le tout dans un script.

Pour commencer, nous allons nous connecter à la console "Exchange Management Shell".

La première commande à passer sera de vider le "Hub Transport" du nœud Exchange et de le passer en mode "drainage"

Set-ServerComponentState EXCH2019A -Component HubTransport -State Draining -Requester Maintenance 

Redémarrage du service.

Restart-Service MSExchangeTransport 

Nous allons ensuite forcer à rediriger tous les messages de la file d'attente vers l'autre serveur du DAG.

Redirect-Message -Server EXCH2019A -Target EXCH2019B.labo.local

Nous vérifions le résultat de la commande.

Get-ServerComponentState EXCH2019A -Component HubTransport

Nous vérifions ensuite quel serveur gère le "Primary Active Manager (https://docs.microsoft.com/fr-fr/exchange/high-availability/database-availability-groups/active-manager?view=exchserver-2019)


Get-DatabaseAvailabilityGroup -Status | fl Name, PrimaryActiveManager

Nous constatons que le PAM est géré par le noeud que souhaitons mettre en maintenance.
Il faudra donc le déplacer.

Nous allons donc déplacer le PAM vers l'autre nœud.

Remarque: vous devrez vous connecter en "PowerShell Remoting avec WinrM sur l'un deux serveurs.

Move-ClusterGroup "Groupe du cluster" -Node EXCH2019B

 On vérifie la bonne migration du PAM vers le deuxième serveur.

Get-DatabaseAvailabilityGroup -Status | fl Name, PrimaryActiveManager








Nous mettons en pause le cluster sur le Nœud Exchange.

Suspend-ClusterNode EXCH2019A

On vérifie le résultat.
Get-ClusterNode







Nous allons maintenant déplacer les copies Actives sur le nœud.
Nous vérifions quelles bases de données sont actives (Mounted) sur le Nœud Exchange.

Get-MailboxDatabaseCopyStatus -Server EXCH2019A

Nous remarquons que la base de données DB01 est active sur le serveur Exch2019A.

Nous déplaçons donc la copie active de la base de données DB01 vers le serveur Exch2019B.

Get-MailboxDatabaseCopyStatus -Server EXCH2019A | ? {$_.Status -eq "Mounted"} | % {Move-ActiveMailboxDatabase $_.DatabaseName -ActivateOnServer EXCH2019B -Confirm:$false}




Nous vérifions les copies actives sur le serveur Exch2019B

Get-MailboxDatabaseCopyStatus -Server EXCH2019B

DB01 est bien active sur le serveur EXCH2019B.





On peut également vérifier la présence dans le Centre d'Administration Exchange.

La commande ci-dessous sera nécessaire pour empêcher le serveur EXCHA2019A de pouvoir à nouveau monter la base de données DB01.

Set-MailboxServer EXCH2019A -DatabaseCopyAutoActivationPolicy Blocked

Vérification de la stratégie.

Get-MailboxServer EXCH2019A | ft Name,DatabaseCopyAutoActivationPolicy

 Pour terminer nous mettons notre nœud en maintenance.

Set-ServerComponentState EXCH2019A -Component ServerWideOffline -State Inactive -Requester Maintenance




Notre serveur est maintenant totalement hors ligne du DAG!!! 💪😏
Vous pouvez maintenant effectuer votre maintenance en toute sécurité!!!



Une fois votre maintenance terminée, nous allons pouvoir sortir le serveur Exchange de sa maintenance.

On sort le serveur du mode maintenance.

Set-ServerComponentState EXCH2019A -Component ServerWideOffline -State Active -Requester Maintenance

On réactive le cluster du le nœud.

Resume-ClusterNode EXCH2019A

On autorise à nouveau la possibilité l'auto-montage de la base de données sur le nœud.

Set-MailboxServer EXCH2019A -DatabaseCopyAutoActivationPolicy Unrestricted

    Et on vérifie.

Get-MailboxServer EXCH2019A | ft Name,DatabaseCopyAutoActivationPolicy

 On réactive le transport sur le serveur Exchange.

Set-ServerComponentState EXCH2019A -Component HubTransport -State Active -Requester Maintenance

Et on vérifie.

Get-ServerComponentState EXCH2019A -Component HubTransport





On vérifie que le serveur est à nouveau hors maintenance.

Get-ServerComponentState EXCH2019A | ft Component,State -AutoSize

 On rétablit le PAM sur le serveur Principal (Juste plus clair pour moi).

Move-ClusterGroup "Groupe du cluster" -Node EXCH2019A

On vérifie les bases de données.

Get-MailboxDatabaseCopyStatus -Server EXCH2019A

Get-MailboxDatabaseCopyStatus -Server EXCH2019B

On peu constater que tout est revenu comme à l'origine:

- DB01 est Active sur Exch2019A et Passive sur EXCH2019B
- DB02 est Active sur Exch2019B et Passive sur EXCH2019A

Voilà c'est terminé, tout est maintenant opérationnel. 😃😄

Dans cet article nous avons pu voir et comprendre la mise en maintenance d'un serveur Exchange 2019 présent dans un DAG.

Si vous avez compris et que vous maîtrisez les différentes étapes effectuées ci-dessus vous n'avez plus qu'à construire votre script.

A vos tests!Scriptez!!😊😊