Fin du support d'Exchange 2010 le 14 Janvier 2020

Bonjour à tous, juste une information importante concernant la fin du support d' Exchange 2010.

En effet le support prendra fin le 14 Janvier 2020 et Microsoft n’assurera  plus aucune demande d'assistance et il n'y aura plus de mises à jour sur cette version.

https://blogs.technet.microsoft.com/exchange/2018/04/10/exchange-2010-end-of-support-is-coming/

Pour information, la plupart des versions Exchange 2010 sont installées sur Windows 2008 Server, produit qui perdra également son support le 14 Janvier 2020.

https://www.microsoft.com/en-us/cloud-platform/windows-server-2008

 Vous avez donc un an pour enclencher la migration vers les versions Exchange supérieures.

Pour remplacer Exchange 2010 vous avez les possibilités suivantes:

• Migration vers Exchange Server 2016 (sous Windows Server 2016)
• Migration vers Exchange Server 2013 (sur Windows Server 2012 R2)
• Migration vers Office 365

Bien évidemment la migration vers Exchange 2016 ou office 365 (Exchange Online) aura plus de sens que de migrer vers Exchange 2013.

Si vous souhaitez migrer vers la dernière version de Microsoft à savoir Exchange 2019, il vous faudra effectuer une migration intermédiaire vers Exchange 2013 ou Exchange 2016.

 Concernant la migration d'Exchange 2010 vers Office 365 il faudra bien prendre en compte les liens ci-dessous comme le dé-commissionnement ou non d'un serveur Exchange 2010 en mode hybride.

https://docs.microsoft.com/fr-fr/exchange/mailbox-migration/decide-on-a-migration-path

https://docs.microsoft.com/fr-fr/exchange/decommission-on-premises-exchange

https://docs.microsoft.com/fr-fr/exchange/mailbox-migration/use-minimal-hybrid-to-quickly-migrate

https://docs.microsoft.com/fr-fr/previous-versions/office/exchange-server-2010/ee332361(v=exchg.141)


Voilà tout est dit. Vous n'avez plus qu'à migrer. 😏😏

Certificat let's Encrypt

Bonjour dans le cadre d'un POC ou d'un test en laboratoire, je suis amené à mettre en oeuvre le mode hybride entre Exchange et office 365 (Exchange Online).

L'un des prérequis principal pour la mise en oeuvre d'un  Exchange en mode Hybride est un certificat publique et Microsoft oblige à utiliser un certificat venant d'une autorité de certification connue.

Donc nous avons deux solutions:

- Acheté un certificat Wildcard ou multi SAN mais cela revient assez chez pour du test.

- Deuxième solution que je vais vous présenter, let's encrypt. Cette solution va nous permettre de générer un certificat reconnue par une autorité de certification publique valable trois mois et largement suffisant pour des tests et donc d'avoir un certificat gratuit.

Je ne vais pas faire une présentation de let's Encrypt, Wikipédia s'en chargera pour moi: https://fr.wikipedia.org/wiki/Let%27s_Encrypt.

La seule chose que je peux ajouter concernant let's encrypt c'est que sur les nouvelles versions, il est plus facile à utiliser.

Dans mon exemple je vais utiliser let's encrypt sur mon serveur Exchange  qui utilise du IIS.

Mon objectif sera de générer un certificat pour Exchange avec les SAN "mail.dude16.fr" et "autodisvover.dude16.fr".

Le nom "mail.dude16.fr" sera le principal.

Pour utiliser let's encrypt il nous faudra en prérequis:

- ACME client for Windows (téléchargement ici).
- Les noms DNS devront être résolus et accessible sur le port 80

Une fois tous ces prérequis appliqués nous allons pouvoir lancer l'exécutable "let's encrypt.exe" depuis une console "CMD"

Plusieurs menus s'offrent à nous:

Nous allons taper "N" pour créer un nouveau certificat.

Nous allons ensuite taper 4 pour entrer manuellement nos noms DNS

Ensuite taper les différents noms DNS que vous souhaitez pour votre certificats.

Pour terminer, attribuer le certificat au site web par défaut (choix 1).



Le certificat est maintenant généré et nous pouvons le vérifier en allant sur IIS

On peut voir ci-dessous que le certificat est automatiquement configuré.

On l'affiche pour vérifier.
Le certificat est bien livré par "Let's Encrypt" à "mail.dude16.fr" pour trois mois.

Mes SAN ont correctement été ajoutés.

Je redémarre les services IIS pour appliquer le certificat à mes services Exchange

L'accès OWA nous montre que le certificat a bien été ajouté à mon serveur Exchange.

Dans cet article, nous avons vu comment facilement mettre en place un certificat gratuit reconnu par une autorité de certification publique.

Cette utilisation est bien sur la même pour tous serveurs web nécessitant un certificat.

Je vous laisse à vos tests et à très bientôt pour un nouvel article. 😏

Active Directory: Création d'un "cookie"

Bonjour à tous et très bonne année.

Pour ce premier article en 2019, je voulais partager avec vous une commande Active Directory que je trouve très pratique.

Il arrive parfois que certains clients demandent d'identifier les modifications pouvant être apportées sur l'active directory lorsque par exemple on augmente le niveau fonctionnel de l'active directory ou lorsque l'on ajoute une application comme Exchange ou ADFS.

Pour ce faire, nous allons créer un "cookie" avec la commande "reapadmin".

Il nous suffit de lancer les commandes ci-dessous:

repadmin /showchanges <nom-du-DC> dc=labo,dc=local /cookie:labo.bin > nul

repadmin /showchanges <nom-du-DC> cn=configuration,dc=labo,dc=local /cookie:labo-cfg.bin > nul

PS: La commande "nul" permet de minimiser le temps de génération du cookie.

Les deux fichiers "cookie" sont maintenant correctement générés.

Nous allons maintenant ajouter des modifications à notre Active Directory en installant le service "ADFS" et nous augmenterons ensuite le niveau fonctionnel du domaine.

Installation de l'ADFS ok:

L'identification des changements dans l'AD associé à l'installation de l'ADFS sera obtenue en présentant le cookie précédemment généré (le cookie sera actualisé).

Un différentiel sera créé entre les premières commandes et les dernières.

Nous pouvons à présent lancer les 2 commandes sans le paramètre "nul".

repadmin /showchanges <nom-du-DC> dc=labo,dc=local /cookie:labo.bin

repadmin /showchanges <nom-du-DC> cn=configuration,dc=labo,dc=local /cookie:labo-cfg.bin

La sortie ci-dessous de la première commande nous montre que l'installation de l'ADFS nous a créé un nouveau conteneur.

La deuxième commande nous montre qu'il n' y a pas eu de modifications au niveau de la partition de configuration de l'Active Directory avec l'installation du service "ADFS".

Nous allons maintenant augmenter le niveau fonctionnel du domaine.

Nous relançons à nouveau les commandes "cookie".

La première commande nous retourne les modifications après l'augmentation du niveau fonctionnel.
On observe  que le niveau fonctionnel du domaine a bien été augmenté.

La deuxième commande concernant la partition de configuration nous renvoie cette fois-ci des modifications.
On observe donc que l'augmentation du niveau fonctionnel du domaine modifie également la partition de configuration.

Ces commandes sont vraiment pratiques et peuvent être utilisées dans des environnements de pré-productions afin d'étudier les impacts ou problèmes potentiels (droits...) que peuvent amener des modifications sur un environnement aussi critique que l'Active Directory.

A très bientôt pour un nouvel article.