Monday, November 27, 2017

Office 365 : préparer sa migration avec IdFix (FR)

English summary: I take a look at the IdFix tool that detects potential synchronization problems between Azure Active Directory (Office 365) and our "local" Active Directory. I can safely assume that there were no signficant problems in my test domain, since I have already synchronized it with Azure AD and even migrated some mailboxes. However, I may have a need for IdFix in another context and wanted to become more familiar with it.

***

A première vue, il est bizarre que je présente cet outil après avoir déjà synchronisé mon Active Directory avec Azure Active Directory, et même migré plusieurs boîtes aux lettres vers Exchange Online.

En effet, IdFix sert à détecter des erreurs dans Active Directory susceptibles d'entraver la synchronisation des répertoires. De plus, nous pourrions nous en servir pour corriger les erreurs trouvées (ou bien recourir à d'autres méthodes pour y parvenir).

Mais voilà : j'envisage une migration à Office 365 dans un autre cadre et je voudrais voir à quel point IdFix pourrait m'y être utile.

***

D'abord, IdFix est disponible par ce lien :

IdFix Directory Synchronization Error Remediation Tool

Selon les apparences, l'outil n'existe qu'en version anglaise. En tout cas, je n'ai pas réussi à le trouver en français.

En revanche, Microsoft fournit un mode d'emploi dans cette langue :


Et voici la version anglaise originale :



Ces articles expliquent assez bien la mise en oeuvre de l'outil et je ne reproduirai pas ici ce que vous pouvez fort bien lire là. Son "installation" se fait comme c'est décrit dans l'article. Je télécharge le fichier zip que je décompresse à l'emplacement de mon choix :





Ensuite, j'exécute le fichier et vois apparaître ce message :



A vrai dire, l'application ne s'installe pas au sens strict. Elle ne s'affiche pas dans "Programmes" par exemple :


Remarque : IdFix nécessite .NET Framework 4.0 ou plus, ce qui est le cas ici.


Pour cette expérience, j'exécute l'outil à un contrôleur de domaine mais il serait possible de l'exécuter ailleurs, à condition d'avoir un accès suffisant à Active Directory, en lecture et en écriture. Je suppose qu'un accès en lecture seule suffirait si on voulait seulement voir les erreurs sans les corriger. Mais je n'ai pas mis cette supposition  à l'épreuve.

Quoi qu'il en soit, lorsque IdFix s'ouvre, nous cliquons sur le mot "Query" et l'outil cherche des éléments qui pourraient bloquer la bonne synchronisation des objets. S'il en trouve, il les affiche et suggère des actions à prendre :



Le seul problème repéré chez moi concerne les "domaines de niveau supérieur" (topleveldomain). De quoi s'agit-il ? Le nom de mon domaine d'essai est "mynet.lan" et par défaut, l'UPN (user principal name) comprend ce suffixe, par exemple : alan.reid@mynet.lan. Cependant, la synchronisation avec Azure Active Directory exige un nom de domaine routable sur l'Internet. Ce n'est pas le cas de .local ou de . lan, selon une révision de RFC2606 :

https://tools.ietf.org/html/draft-chapin-rfc2606bis-00

Je dois donc changer l'UPN. Je pourrais utiliser IdFix mais pour un changement si simple, il suffit de sélectionner tous les utilisateurs, de choisir "Propriétés" et d'ajuster alors le suffixe :



Et nous y sommes !

Pour la synchronisation  en tout cas. Si nous souhaitons migrer des boîtes aux lettres vers Exchange Online, nous devons aussi supprimer toute adresse courriel avec le suffixe @mynet.lan. 

Thursday, November 23, 2017

Office 365 : gérer son compte avec PowerShell - les commandes Get-Msol* (FR)

English summary: We can manage Exchange with PowerShell, in particular by the creation of scripts for the execution of repetitive tasks. In Exchange Online (Office 365), we have many of the same commands (or "cmdlets") at our disposal although some cmdlets, notably those for Exchange server management (Get-MailboxServer or Set-MailboxServer, etc.) will not function in the Cloud. On the other hand, we can use PowerShell to manage not only Exchange Online but also other Office 365 applications and the Office 365 tenant itself.

These commands contain the string "msol": Get-MsolUser, Set-MsolUser, New-MsolDomain, etc.. I explored the different Get-Msol* cmdlets by entering Get-Msol and then displayed the various suffixes using with the tab key. Below, I present some of those I find most useful.

OS: Windows 7 SP1
PowerShell version: 4.0


***


Dans certains cas, nous pourrions préférer gérer Exchange avec PowerShell, en particulier pour l'exécution des tâches répétées avec des scripts. Si nous faisons le saut à Office 365, nous aurons à notre disposition beaucoup des mêmes commandes (ou "cmdlets") que nous avons utilisées pour gérer Exchange sur place ("on-site"). D'autres commandes, notamment celles qui ciblent les serveurs (Get-MailboxServer par exemple), ne fonctionneront plus dans ce nouveau cadre. En revanche, nous pouvons utiliser PowerShell non seulement pour Exchange mais aussi pour d'autres applications Office 365 et même l'administration générale de notre compte. Ce dernier aspect est le sujet de ce texte.

Les commandes en question contiennent la séquence "msol" ce qui signifie en toute vraisemblance "Microsoft OnLine".

Voici des exemples :
  • Get-MsolUser
  • Set-MsolUser
  • New-MsolDomain
Je suis parti à la découverte des commandes Get-Msol* en appuyant sur la touche tabulation ("Tab") pour les afficher en succession. Je vais présenter ci-dessous celles que j'ai trouvées les plus utiles.

Note : Je me sers de Windows 7 SP1 et de PowerShell 4.0.


Avant d'ouvrir PowerShell et de découvrir les commandes pour Office 365, nous devons installer au préalable deux logiciels dans l'ordre suivant :

Microsoft Online Services Sign-in Assistant

Nom de fichier : msoidcli_64.msi

Azure Active Directory Module pour PowerShell

Nom de fichier : AdministrationConfig-V1.1.166.0-GA.msi


Ensuite, nous pouvons accéder à notre compte Office 365 en ouvrant PowerShell et en saisissant ce qui suit :

$Cred = Get-Credential
Connect-MsolService -Credential $Cred

Il vous sera demandé de fournir vos informations de connexion :



Note : utilisant la version de PowerShell et les fichiers indiqués plus haut, je n'ai pas eu besoin de saisir la commande "Import-Module MSOnline".

Et nous voilà prêts à essayer quelques commandes.



PS C:\> Get-MsolAccountSku | ft -auto

Cette commande montre les types de plan Office 365 auxquels nous sommes abonnés ainsi que le nombre d'unités (units) disponibles et utilisées.

Comme l'affichage des données copiées et collées se présente mal, et par discrétion du reste, je vais m'en tenir au strict minimum et ne pas montrer nécessairement tous les détails de mon compte à moi :

AccountSkuId                                  ActiveUnits WarningUnits ConsumedUnits
------------                                           ----------- ------------ -------------
mondomaine:EXCHANGESTANDARD         2           0            2
mondomaine:O365_BUSINESS_PREMIUM  1           0            1




PS C:\> Get-MsolSubscription | ft skupart*,status,TotalLicenses -auto

SkuPartNumber                Status    TotalLicenses
-------------                          ------       -------------
EXCHANGESTANDARD         Enabled        2
O365_BUSINESS_PREMIUM  Enabled        1

Cette commande offre une autre perspective de notre abonnement. Le terme "license" s'utilise ici au lieu d'unité, comme nous avons vu plus haut.

Note : nous pouvons parfois afficher plus de détails avec la commande format-list ou "fl". Encore une fois, je m'en tiens à ce que je crois essentiel en préférant l'option format-table ou "ft", et les propriétés spécifiques qui m'intéressent.



PS C:\> Get-MsolCompanyInformation

Cette commande affiche des renseignements sur l'entreprise hébergée en Office 365 ainsi que des détails sur la synchronisation avec le domaine local :




PS C:\> Get-MsolUser | ft DisplayName,isLicensed -auto

Cette commande montre les utilisateurs et leur statut vis-à-vis des licences. En particulier, les utilisateurs dont la boîte aux lettres a été migrée vers Exchange Online devraient se voir accorder une licence, sans quoi leur BAL sera purgée après un certain temps. Au contraire, les utilisateurs dont la BAL réside toujours sur place n'en ont pas besoin. Cet affichage permet d'en tenir compte. 




PS C:\> Get-MsolUser -UserPrincipalName alex.heyne@mondomaine.net | fl *name*,*address*

Cette commande affiche les propriétés de l'utilisateur en question et notamment ses adresses :


Note : oui, vous pouvez cliquer sur l'image pour l'agrandir.




PS C:\> Get-MsolDirSyncConfiguration | fl

PS C:\> Get-MsolDirSyncFeatures | ft DirSyncFeature,Enabled -auto

Si nous utilisons DirSync (désormais "Azure AD Connect"), les deux commandes ci-dessus peuvent se révéler utiles. Voici ce qu'elles donnent :




PS C:\> Get-MsolDomain | ft -auto

Cette commande affiche les domaines associés à notre compte Office 365 :



PS C:\> Get-MsolGroup | ft DisplayName,GroupType -auto

Comme pour les utilisateurs, nous pouvons afficher nos groupes synchronisés avec Azure Active Directory : 





PS C:\> Get-MsolPasswordPolicy -DomainName mondomaine.net | fl

Cette commande nous dévoile la stratégie de mot de passe en vigueur pour notre compte Office 365 et notamment la période de validité :




PS C:\> Get-MsolRole | fl Name,Description

Au lieu de faire de chacun de nos techniciens un "administrateur global", nous avons l'option de déléguer certains rôles à des administrateurs avec le pouvoir d'agir seulement dans ces domaines. La commande Get-MsolRole affiche ces rôles avec une description. Comme la liste des différents rôles est assez longue, la capture d'écran ci-dessous n'en montre que les premiers :




***


Nous devrions garder à l'esprit que nous ne pouvons pas exécuter des commandes spécifiques à Exchange Online dans ce cadre. Cela donnerait des erreurs de ce genre :


Pour cela, il faudrait plutôt saisir l'ensemble des commandes suivantes :

$Cred = Get-credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $Cred -Authentication Basic 
-AllowRedirection

Import-PSSession $Session -DisableNameChecking -AllowClobber


***

Cette présentation n'était qu'un survol qui m'a permis de connaître un peu mieux les options de gestion de mon compte Office 365 avec PowerShell. Je me suis contenté d'ailleurs de ne présenter que des exemples des commandes Get-Msol*.

Nous pouvons voir toutes les commandes Get-Msol* avec cette commande :

Get-Command Get-Msol*

Ou en abrégé :

gcm Get-Msol*

Nous pouvons faire de même pour afficher les commandes Set-Msol* (etc.).

De plus, vous pouvez consulter la documentation Microsoft à ce sujet ici :

Gérer Office 365 avec Office 365 PowerShell


Wednesday, November 15, 2017

Windows 10 and Office 2016 : Deployment

In a previous blog post, I installed ADMX and langauge specific ADML files that allow me to manage settings for Windows 10 and Office 2016 through Group Policy. However, I had no Windows 10 clients and no installation of Office 2016 (the Outlook mail client in particular).

That has changed. I have added a Windows 10 Pro client to my test network and purchased an Office 365 Business Premium license, which grants me the right to download and install the full version of "Office 2016 ProPlus". Among other applications, this package includes Word, Excel, PowerPoint and especially Outlook.

I had never used the downloadable version of Office 2016 before and thought I would find a download link at this location:



But only the Office versions for Macintosh are available:




What if you use Windows?


***

For Windows, we have to download the Office Deployment Tool (ODT) that will, in turn, allow us to download Office 2016 files to a shared folder from which we can deploy the application itself by a variety of methods (Group Policy with a simple installation script, System Center Configuration Manager, etc.).

So I create a shared folder on a server, download the ODT and extract the tool to that location.

This is what the downloaded executable looks like:



I extract the content to this folder, shared with the following UNC path:

\\ADCONNECT1\Shared\O365



Besides the setup.exe file, we have a sample .xml file that I have already modified and renamed. I have also created a subfolder named "SAC" that will hold the downloaded Office 2016 files.

Note: SAC means "semi annual channel". The concept of channel is related to the frequency at which Microsoft releases updates for the Office product. Enterprise customers may not want too frequent updates as the possible changes may affect productivity. This article explains the options in greater detail (and instructions for configuring the deployment folders):

Deploy Office 365 ProPlus from a local source


I need to say a word on the configuration .xml file. This file defines certain deployment parameters such as the deployment location, the version of Office 2016 to be deployed, the Office components we may want to exclude (optional), and the frequency of updates. Below is the content of my configuration.xml file:

<Configuration> 
  <Add SourcePath="\\ADCONNECT1\shared\O365\SAC" OfficeClientEdition="64" Channel="Broad"> 
   <Product ID="O365BusinessRetail"> 
     <Language ID="en-us" /> 
     <ExcludeApp ID="Access" />    
     <ExcludeApp ID="Publisher" />
   </Product> 
  </Add> 
  <Updates Enabled="TRUE" UpdatePath="" Channel="Broad" />  
  <Display Level="None" AcceptEULA="TRUE" />
</Configuration>


These articles provide additional information on the options mentioned above:

Configuration options for the Office 2016 Deployment Tool

Product IDs that are supported by the Office Deployment Tool for Click-to-Run

Overview of update channels for Office 365 ProPlus


But I still do not have the Office 2016 installation files!

So how do I procure those files?

At the command prompt, I run setup.exe in download mode, referencing my .xml configuration file:

This is the example given in the Microsoft documentation:

\\server\share\O365\setup.exe /download \\server\share\O365\config-group1-SAC.xml

In my case, it looks like this:


Note: you can click on the image to enlarge.

The files should begin downloading to the location designated in the .xml file, for example:

\\ADCONNECT1\shared\O365\SAC




Note: if problems are encountered, you can consult the log file in the %temp% directory.



***


We have made some progress. The Office 2016 (ProPlus) installation files have been copied to one of our local servers. But how do we install Office on our client machines?

There are a number of options including System Center Configuration Manager (SCCM). I will use a more simple method that may or may not be sufficient for your production environment: software deployment via Group Policy.

First, I enter the following command in notepad.exe and save it as a .bat file:

start /wait \\adconnect1\shared\O365\setup.exe /configure \\adconnect1\shared\O365\config-group-SAC.xml

Of course, you would adjust the script to match your own environment (changing server names and so forth). The script references both the setup.exe file and the .xml file for customization.

Next, I add the batch file to the the scripts section of a GPO to be linked to the OU (organisational unit) containing the user's client machine. One remark: I will assume that the reader is capable of creating and managing a GPO and will not review that process here.

So, I open the GPO for editing, go to the "Scripts (Startup/Shutdown)" section and click on the "Show Files" button:





Once this window is open, I can copy the batch file from its current location to the startup folder:




But that is not enough. I still have to click on the Add button and then browse to the startup folder (opened by default) to add the script to the GPO:




If the GPO is linked to the OU correctly and I restart the client machine (it may require a second reboot), the script should install Office 2016 ProPlus, taking into account the customization settings in the .xml file. Besides the presence of Office icons in the start menu, we should see entries in the Event Viewer (Application log) related to the installation. If Office does not install correctly, the entries here may be useful for troubleshooting:





What happens next?

I log on as user Alan Reid and open Word (we'll see Outlook later). Almost immediately, I am prompted to "Activate Office". I assume it will attempt to associate this copy of Office with the license I purchased. So I enter the email address of Alan Reid (although not shown in the screenshot below) and click on "Next"...






"Alan Reid" is prompted to sign in:




And encounters this error:




As I suspected, I cannot use Office 2016 ProPlus until I assign the logged on user a proper license. 

So I connect to my Office 365 tenant and go to the "Active users" section where I assign the license to Alan Reid:

A.



B.


C.




Now when I connect as Alan Reid, and open Word, the product activates without further ado.

As far as Outlook 2016 goes, autodiscover functions perfectly and configures the mailbox of Alan Reid without a problem:

D.



E.


F.





G.