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).

Monday, September 4, 2017

Exchange 2010 / Online - cross organization permissions and access - PART 4

In my previous blog posts, we examined two types of situations: granting a migrated user access to mailboxes that remain onsite and granting an on-premises user access to mailboxes migrated to Office 365 (O365). In this blog post, I want to define permissions before the migration of a user mailbox and observe to what extent the permissions continue to function.


***


We will migrate the mailbox of user Alex Heyne to Office 365.

Permissions are configured as follows...

Alan Reid (on-premises user) has Full Access and Send As permissions to Alex Heyne's mailbox:





Alex Heyne has Full Access and Send As permissions to Alannah Shaw's mailbox (which will remain onsite):





Alex Heyne also has Full Access and Send As permissions to the on-premises Finance shared mailbox:





Lastly, Alex Heyne, through membership in the CALPER_FinCal security group has Publishing Editor rights to the "FinCal" (Finance Calendar). This is distinct from the Finance shared mailbox and serves the purpose of testing permissions if they were granted in this manner.



Before the move, I ensure that the "mynet.lan" domain name is not present as part of an email address. Since this is not an accepted domain in O365, its presence would cause the migration to fail, as we have observed in previous migrations.





Out of curiosity, I note the size of the mailbox to be migrated. Since these are test mailboxes containing only some test messages, it is not surprising that the mailbox is only 176 KB in size:



Besides observing permissions and access in a hybrid environment, I also have secondary objectives in executing these migration operations and in particular, taking note of the time necessary to migrate the mailbox. I would predict that a 176 KB mailbox would take very little time to migrate. We'll see if that is the case.


I'm also interested in the protocols used to access the mailbox. Before migration, Outlook 2010 (SP2 - with patches) uses encrypted RPC to access the mailbox hosted on an Exchange 2010 SP3 (RU18) server:




Note: observe the use of the CAS array, the protocol (RPC/TCP), and the RPCPort.

After the migration, we'll see if the same protocol or different protocols are used.



***


Now we will migrate Alex Heyne's mailbox to O365. I will leave his Outlook client open so I can see the effects of a live migration on the end user experience.

I will refer the reader to this blog post for the step-by-step directions ...

Exchange 2010 / Online - mailbox migration steps

And limit my commentary to some observations in the lines below.

First, I initiate the migration in the recipients | migration section of the Exchange admin center (EAC).

There was a transient error that did not prevent the migration from finishing:








If I look at the details of the migration (not shown in the screenshot), it looks like the process took at least 20 minutes, which leads me to conclude that there is a minimum amount of time required to set up the new mailbox in O365 / Exchange Online. The amount of data migrated is listed as 508 KB compared to the 176 KB mailbox size shown in an earlier screenshot.

It is very important to assign a license to the mailbox manually if you do not have an automatic process for this (unlicensed mailboxes are purged after 30 days). We do this in the Office 365 Admin center:






Now we have two licensed users (Aisha Bhari and Alex Heyne). Our other users are listed as unlicensed but that is not a concern since their mailboxes have not been migrated to O365 and therefore do not risk deletion:






And now, let's return to Alex Heyne's Outlook client...

Since we have no Single Sign-On (SSO), Outlook attempts to reconnect and prompts us for credentials:




No sooner do I provide the credentials than a message appears, stating that Outlook requires a restart:


Note: observe the state of the connection ("Send/Receive error" and "Disconnected").


Once I restart Outlook (connected as Alex Heyne"), I observe the connection status and notice that two different protocols are being used concurrently. The three connections with Office 365 use HTTP instead of RPC. However, we also have an RPC connection because Alex Heyne still connects to mailboxes onsite where RPC is still used:






***


Now we will observe if the mailbox permissions configured for our various mailboxes still function as desired (I will only provide screenshots if the operation fails).

Note: they were all verified as functional when all the "actors" were still on-premises.


  • Can Alan Reid access the mailbox of Alex Heyne? - Yes


(But if originally auto-mapped it must be re-added manually)




Alex Heyne's  mailbox was auto-mapped to Alan Reid's Outlook profile and disappeared after I enter the credentials. It was visible when I first opened Outlook (as Alan Reid) but when I attempted to expand the folders the error message above displayed. However, if I (re)add the mailbox to Alan Reid's Outlook profile manually, I can access and expand the folders. Of course, lacking SSO, I must enter my credentials multiple times.


  • Can Alan Reid send as Alex Heyne? - Yes (message received by Alannah Shaw)


  • Can Alex Heyne access the mailbox of Alannah Shaw? - Yes (but after an initial failure)



After a second try, it succeeds (note the message Alan Reid sent as Alex Heyne):




  • Can Alex Heyne send as Alannah Shaw? - Yes


  • Can Alex Heyne access the Finance shared mailbox? - Yes (but after an initial failure - see example of Alannah Shaw above)


  • Can Alex Heyne send as the Finance shared mailbox? - No (this fails consistently)





Is this because the right is granted through group membership that O365 cannot validate? We should keep in mind that Alex Heyne was granted Send As rights to Alannah Shaw's mailbox directly (and not through membership in a security group).

I'll attempt some troubleshooting in just a moment but I'll answer one more question first:

  • Can Alex Heyne access and edit the FinCal shared calendar? - Yes (no problems here)


***

It seems that we can "send as" another user if we are granted Send As rights directly to their mailbox but not necessarily if these rights are granted via group membership. Let's attempt some troubleshooting...

Is the group granting permissions (GMPER_Finance) synced to O365?

No (because of filtering by OU)

What if I sync it?

No change (Alex still cannot "send as" Finance)



What about Aisha Bhari who is also member of the GMPER_Finance security group?

She cannot send as the Finance shared mailbox either.



What if we mail-enable the GMPER_Finance security group?

I make the change and to ensure it takes effect immediately (on the server running Azure AD Connect)...

Start-ADSyncSyncCycle -PolicyType Initial

No change (even after successful sync).


I grant Alex Heyne "Send As" rights directly and attempt to send another message. This results in another failure. However, permission changes do not always take effect immediately so I will try again later. 

***

Directly granted permissions function just fine for user mailboxes (see the example of Alannah Shaw above). It is not clear if there is a particularity with shared mailboxes that would change expected behavior. Otherwise, I do remark that "Send As" permissions were also the type of permissions that encountered the most obstacles in the testing conducted by Henrik Walter in this blog post:

Exchange Hybrid Cross-Premises Mailbox Permissions Demystified (Part 4)