PI Services

Le blog des collaborateurs de PI Services

Exchange 2010 – Page OWA vide après le passage d’un RU

Contexte

Après le passage d’un Rollup Update, lorsque vous vous connectez à l’OWA la page ne se charge pas et reste vide.

Dans le journal d’évènement l’erreur suivante est présente :

Outlook Web App couldn’t initialize.
A base theme couldn’t be found. The base theme must be in a folder with name = “base”

AA1

Solution

Pour résoudre cette erreur, il faut lancer le script UpdateCas.ps1 qui se trouve dans le dossier Scripts présent dans le répertoire d’Exchange Server.

A1

Exchange 2010 – Erreur “Flow of control cannot leave a Finally block”

Contexte

Lors d’un passage d’un Rollup Update ou d’un Service Pack (voir lors de l’utilisation d’un script PowerShell fourni par Microsoft), l’assistant d’installation d’Exchange 2010 échoue et l’erreur suivante est présente dans les logs :

Flow of control cannot leave a Finally block.

1

Solution

L’erreur provient d’une incompatibilité entre votre version de PowerShell et le script.

Pour résoudre l’erreur il faut regarder dans le fichier de log quel script et quelle ligne pose problème.

Ici c’est le script ManageScheduledTask.ps1 ligne 462 qui contient la commande return $success qui est en erreur.

2

Pour la résoudre il faut remplacer le return $success par Write-Output $success.

3

Une fois le script modifié, relancer l’assistant d’installation.

Exchange 2013 – Update Rollup et redémarrage en boucle

Problématique

Lors de l’installation d’un CU sur un serveur Exchange 2013, l’assistant d’installation vous demande de redémarrer en boucle sans jamais valider le redémarrage.

2018-03-29_160513

Solution

Si après un redémarrage le message d’erreur apparaît toujours, vous pouvez aller modifier la clé de registre suivante :

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations

Supprimer la valeur de cette clé et relancer l’assistant d’installation.

2018-03-29_192556

Exchange 2013 – Erreur HttpEvent 15021

Problématique

Sur un serveur Exchange 2013, la connexion PowerShell ne s’effectue pas et le portail d’administration affiche une page blanche.

2018-03-29_105153

2018-03-29_105411

Dans le journal d’événements système un grand nombre d’erreur HttpEvent 15021 est présent.

2018-03-29_105128

Ces erreurs peuvent intervenir après le changement d’un certificat sur le serveur Exchange.

Résolution

Le problème vient de la liaison du certificat qui est incorrect sur le port 444. Il faut donc la supprimer et la recréer.

Pour cela, afficher l’ensemble des liaisons SSL avec la commande :

netsh http show sslcert

2018-03-29_105203

Récupérer les valeurs du hash et l’application ID de la liaison sur le port 443.

Supprimer la liaison du port 444 avec la commande :

netsh http delete sslcert ipport=0.0.0.0:444

2018-03-29_105239

Et recréer une liaison en utilisant le hash et l’application ID du port 443 avec la commande :

netsh http add sslcert ipport=0.0.0.0:444 certhash=XXXXXXX appid=”{XXXXXXXX}”

2018-03-29_105352

Dans le journal d’événements deux avertissements HttpEvent 15300 et 15301 apparaissent.

2018-03-29_105518

Une fois la modification effectuée, la connexion PowerShell et le portail d'administration sont de nouveau accessibles.

Azure AD Connect – Relancer les synchronisations après la suppression d’un domaine Active Directory enfant

Contexte

La synchronisation entre l’Active Directory et Office 365 est un sujet extrêmement sensible dans un environnement de production. Une mauvaise configuration peut entrainer la suppression de nombreux objets dans le cloud (comptes, groupes…).

Le domaine enfant de mon domaine Active Directory a été décoché dans la configuration de mon connecteur dans la console Synchronization Service Manager.

2018-01-10_1613512

Figure 1 – Propriétés du connecteur

Lorsque l’on coche à nouveau le domaine enfant et que l’on relance une synchronisation, le domaine enfant n’est pas resynchronisé.

Solution

Lors de la suppression du domaine enfant, les étapes de synchronisation associées sont supprimées.

On remarque en allant dans Configure Run Profiles… sur le connecteur qu’il n’y a qu’une seule étape qui correspond au domaine parent.

2018-01-12_1111362

Figure 2 – Profil du connecteur pour le Full Import avec une seule étape (domaine parent)

Il est donc nécessaire de recréer les étapes pour le domaine enfant. Pour cela il est recommandé de lancer l’outil de configuration d’Azure AD Connect.

Une fois l’outil de configuration terminée, les étapes pour le domaine enfant sont de nouveaux en place.

2018-01-12_1142582

Figure 3 – Profil du connecteur pour le Full Import avec deux étapes (domaine parent et domaine enfant)

Il est ensuite nécessaire de relancer dans l’ordre :

  • Full Import – Connecteur Active Directory
  • Full Synchronisation – Connecteur Active Directory
  • Export – Connecteur Active Directory
  • Delta Import – Connecteur Office 365 (domaine.onmicrosoft.com)
  • Delta Synchronisation – Connecteur Office 365 (domaine.onmicrosoft.com)
  • Export – Connecteur Office 365 (domaine.onmicrosoft.com)

Windows 10 – Réouverture automatique des applications au démarrage

Contexte

Depuis la mise à jour de Windows 10 Fall Creator Update (Windows 10 - 1709), lorsque vous éteignez votre machine, au redémarrage l’ensemble des applications qui étaient ouvertes s’ouvrent à nouveau automatiquement.

Pas très pratique si l’on est du genre à éteindre son poste alors que de nombreux programmes sont encore ouverts.

Solution

Pour le moment Microsoft ne propose pas d’option pour activer / désactiver cette (nouvelle) fonctionnalité.

Les solutions possibles pour ne pas avoir ce comportement :

  • Passer par ALT + F4 pour éteindre Windows : on remarque alors que Microsoft à ajouter la ligne Ferme toutes les applications et éteint le PC (cf. image)
  • Utiliser la ligne de commande shutdown /r /t 0

image

Office 365 - Nouvelle interface d'administration pour Skype for Business et Teams

Depuis quelques temps Microsoft propose une nouvelle interface d'administration pour Skype for Business et Teams.

Pour y accéder vous pouvez utiliser le lien suivant : https://adminportal.services.skypeforbusiness.com/analytics/home

2017-11-24_151049

Pour le moment toutes les fonctionnalités annoncées ne sont pas encore actives. Cependant on peut déjà analyser les appels passés via Skype Online !

2017-11-24_151427

Sur un appel / une conférence de mauvaise qualité il est possible de voir quel utilisateur a eu des problèmes.

2017-11-24_151650

Tout comme dans Skype for Business OnPremise les rapports nous permettent d’avoir des informations précises sur l’incident (micro de mauvaise qualité, jitter trop élevé, nombre de paquet perdu…).

2017-11-24_151810

2017-11-24_151856

Vivement la suite des fonctionnalités !

Office 365 - Script de récupération des fonctionnalités O365 pour l'ensemble des utilisateurs

Contexte

Dans un environnement Office 365 il peut être nécessaire de savoir quelles fonctionnalités (Exchange, Skype, Yammer...) sont actives sur les utilisateurs.

Script

J'ai écrit le script suivant afin de récupérer automatiquement ces informations :

Get-UsersO365Features.ps1 (6,44 kb)

Pré-requis : 

  • Avoir un compte administrateur dans Office 365
  • Avoir un dossier C:\temp\ sur sa machine

Limites :

  • Actuellement le script ne prend en compte que les licences E1, E3 et K1

Résultat :

Une fois le script exécuté, vous avez dans le dossier C:\temp\ un dossier Export contenant :

  • Trois fichiers contenant l'ensemble des utilisateurs et leur utilisation
  • Trois dossiers contenant chacun le nombre de fonctionnalités actives et inactives

Licence du script : 

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.

Exchange Online – Erreur avec les listes de distribution dynamiques et le filtre UsageLocation

Contexte

Dans Exchange Online il est possible de créer des listes de distribution dynamiques en se basant sur l’attribut UsageLocation. Cet attribut est défini par l’administrateur lors de l’attribution d’une licence à un utilisateur.

2017-11-21_151051

Cependant lorsque vous créez une liste de distribution il se peut que le filtre ne fonctionne pas et que l’erreur suivante apparaisse lorsque vous tentez de lister les membres de la liste :

2017-11-21_144233

Explications

Lorsque l’on regarde le filtre via la commande Get-DynamicDistributionGroup “dl_language_it” | fl recipientfilter on remarque que la valeur pour l’attribut UsageLocation est en Français. Ceci est causé par le fait que l’outil Microsoft Sign-In Assistant a été installé en Français.

2017-11-21_143648

Même si l’on créé le filtre à l’aide de la norme ISO 3166 (comme décrit dans la KB suivante https://technet.microsoft.com/en-us/library/bb738157(v=exchg.160).aspx), l’outil remplace le code par le texte en Français avant de l’envoyer au serveur Exchange.

Après avoir contacté le support Microsoft, nous avons eu une confirmation de ce problème et une mise à jour doit être apportée dans le code source de l’outil.

Solution

La solution en attendant le fix est de supprimer la liste de distribution et de la recréer depuis une machine où l’outil est installé en anglais. Pour cela, lancez les commandes suivantes :

Remove-DynamicDistributionGroup “dl_language_it”

2017-11-21_144451

New-DynamicDistributionGroup "dl_language_it" -RecipientFilter {UsageLocation –eq “IT”}

La liste des codes ISO pour l’ensemble des pays sont disponibles au lien suivant : https://www.iso.org/obp/ui/fr/

Si l’on vérifie avec la commande Get-DynamicDistributionGroup “dl_language_it” | fl recipientfilter on remarque que l’attribut UsageLocation est maintenant en Anglais.

2017-11-21_144550

Si l’on utilise la commande suivante pour lister les membres, l’erreur n’apparait pas et les membres du groupes apparaissent.

$group = Get-DynamicDistributionGroup ‘”dl_language_it”
Get-Recipient –RecipientPreviewFilter $group.RecipientFilter

2017-11-21_144739

Office 365 migration tenant-to-tenant – Retour d’expérience 1/3

Contexte

Cet article divisé en trois parties est un retour d'expérience sur une migration Office 365 tenant-to-tenant. La première partie traitera de l’architecture et des pré-requis à la migration. La seconde partie traitera du plan d’action et de la migration. Enfin la troisième partie traitera des problèmes rencontrés lors de celle-ci.

Architecture

L’architecture de cette migration est assez simple. Deux environnements similaires contenant chacun Active Directory, Azure AD Connect, ADFS et O365. Le but de la migration est de migrer l’ensemble des données du tenant A vers le tenant B. Les comptes Active Directory ne sont pas migrés et l’ADFS A sera toujours utilisé par les utilisateurs de l’Active Directory A. La synchronisation vers le tenant utilisera bien évidemment le serveur AD Connect B. Enfin les adresses emails garderont le même nom de domaine de la source vers la destination.

Figure 1 – Schéma source de l’architecture

schemaSource

Figure 2 – Schéma cible de l’architecture

schemaCible

Pré-requis

Le premier pré-requis est d’avoir une relation d’approbation inter-forêt entre les deux forêts AD.

La migration tenant-to-tenant nécessite également un outil tiers afin de migrer l’ensemble du contenu des boites aux lettres (emails, contacts, calendrier…).

Un nombre de licences suffisant dans le tenant B est également indispensable pour accueillir les comptes du tenant A.

Enfin il est important d'avoir un compte administrateur global utilisant le domaine par défaut de microsoft (@domaine.onmicrosoft.com).

 

Voilà qui conclut la première partie de mon retour d'expérience. Stay tuned!