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:


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:

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

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:


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:




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:





Tuesday, October 31, 2017

Cisco Catalyst C3560-CG : encore des options de sécurité (FR) - 2

English summary : after protecting access to our Catalyst 3560-CG switch with passwords in my previous blog post, I configure additional security options: legal disclaimer (login banner), remote management via SSH and port security.


Dans ce texte, je vais passer en revue quelques options concernant la sécurité du commutateur. Je pourrais écrire quelques options en plus car nous avons déjà protégé l'accès au commutateur par des mots de passe dans le texte précédent.

Les bannières

D'abord, nous pourrions avoir intérêt à afficher un avis aux personnes tentant d'ouvrir une session afin qu'elles sachent que l'accès au commutateur se limite aux individus autorisés. Bien entendu, cela n'empêcherait personne de continuer mais, selon les pays et les circonstances, pourrait avoir une valeur juridique.

Pour la comparaison, voici à quoi ressemble la connexion avant l'affichage d'une "bannière" (c'est la traduction la plus fréquente du mot "banner" dans la documentation que j'ai consultée) :

Le premier type de bannière que je vais configurer est pour les connexions ou "logins".

Je la crée en saisissant l'ensemble des commandes suivantes en mode configuration :

banner #
Le message de mon choix

Les dièses délimitent le message. Il en faut un avant le message et un autre après. Il est tout à fait possible d'utiliser d'autres symboles d'ailleurs mais, dans tous les cas, le symbole utilisé ne doit pas se trouver dans le message lui-même.

Voici la capture d'écran des commandes saisies (1) et puis ce que cela donne à la connexion après que j'ai fermé la session pour en ouvrir une nouvelle (2) :



Il faut bien préciser "login" sinon nous aurions le "message du jour" ou MOTD (message of the day) qui est le choix par défaut et qui pourrait d'ailleurs servir le même but.

Nous pouvons fort bien avoir les deux. J'entre l'ensemble des éléments suivants...

Et cela donne ceci :

Note : nous pouvons encore afficher un autre message : "exec". Celui-ci s'affiche après la connexion, ce qui est utile si nous voulons que seuls les utilisateurs autorisés puissent le voir.

SSH et gestion à distance sécurisée

Jusqu'ici, je configure le commutateur par un câble branché sur le port console. Cette méthode a l'inconvénient de m'obliger à être à proximité du commutateur. Je pourrais le gérer à distance via Telnet depuis que j'ai protégé cette méthode d'accès avec un mot de passe (dans le texte précédent) mais les communications Telnet ne sont pas chiffrées, donc susceptibles d'être interceptées et lues.

SSH permet lui aussi une gestion à distance mais chiffre les communications en plus.

Nous devons d'abord configurer une adresse IP de gestion pour le commutateur, et d'autres paramètres comme le masque de sous-réseau et la passerelle par défaut. Voici les commandes qu'il faut saisir :

- int vlan 1
-- ip addr
-- no shutdown
-- exit
- default-gateway

Comme vous avez sans doute remarqué, il faut être en mode configuration et puis désigner le vlan par défaut (vlan 1). Oui, j'ai abrégé les termes "interface" en "int" et "address" en "addr". L'interface était déjà activée mais je m'en assure en saisissant la commande "no shutdown". Enfin, je quitte le mode "configuration de l'interface" pour définir la passerelle par défaut.

La prochaine étape consiste à configurer SSH. La séquence des commandes varie selon les sources (Todd Lammle, Wendell Odom, documents Cisco en ligne). J'ai réussi ma configuration avec celle-ci :

- line vty 0 15
-- login local
-- transport input ssh
-- exit
- username admin password MySecretPassword123!
- ip domain-name
- crypto key generate rsa

Voici une capture d'écran avec plus de détails :

  • line vty 0 15 : cela désigne les connexions Telnet - ou SSH (16 au total - notre configuration vaut pour chacune d'entre elles).
  • login local : cela exige l'utilisation d'un compte local pour les connexions (un serveur AAA est une autre option).
  • transport input ssh : cela force l'utilisation du seul SSH ("transport input telnet ssh" permettrait le deux moyens).
  • username admin password MyPassword! : ce sont les informations de connexion imposées plus haut par la commande "login local".
  • ip domain-name : nous devons définir un nom de domaine.
  • crypto key generate rsa : cela crée la paire de clés (publique et privée) pour le chiffrement de données entre le poste de l'administrateur et le commutateur. J'ai choisi 1024 mais vous pourriez préférer 2048 qui est plus sûr face aux menaces d'aujourd'hui.

Mais comment établir une session SSH avec le commutateur ?

Il a suffi que je désigne l'adresse IP du commutateur ainsi que le port SSH (22) et choisisse comme type de connexion "SSH" :

Je me suis demandé comment j'allais importer la clé publique dans mon poste de travail. Nous avons deux choix : l'afficher avec cette commande ...

show crypto key mypubkey rsa

Et l'importer manuellement dans le client...

Ou tenter la connexion et laisser le client importer la clé publique de façon automatique (choisir Oui) :

A la première tentative, un message d'erreur s'est affiché mais à toutes les tentatives suivantes, je me suis retrouvé à cette invite où j'ai dû fournir un nom et un mot de passe :

Comme vous voyez, j'ai réussi à ouvrir une session.

La sécurité des ports

Dans la plupart des organisations, nous voulons éviter que des personnes non-autorisées puissent accéder à notre réseau. Nous protégeons l'accès au périmètre avec un pare-feu (ou plusieurs). Mais comment empêcher qu'un intrus (déguisé en ouvrier, etc.) branche un appareil portable sur notre réseau ? Si nous savons quel ordinateur (au sens large) se branche normalement sur telle interface du commutateur, nous pouvons limiter l'accès à l'interface (à cette machine) selon l'adresse MAC.

Voici les commandes à saisir :

switchport mode access
switchport port-security
switchport port-security mac-address 0050.5621.06bc

Et voici une capture d'écran qui montre plus de détails :

La première commande configure le port comme une "interface accès". C'est un pré-requis pour la sécurité des ports. Ensuite, nous devons activer la sécurité des ports avec la seconde commande et enfin préciser l'adresse MAC avec la troisième.

Nous avons quelques options pour la troisième commande :

switchport port-security maximum 2

Par défaut, une seule adresse MAC est permise par port. Nous pouvons permettre à plus d'un ordinateur de se brancher sur le port en mettant un numéro plus élevé : 2, 3, etc.

switchport port-security violation { protect | restrict | shutdown }

Si nous ne précisons rien, le port se désactive (passe en mode "shutdown") en cas de violation, mais nous pouvons le configurer pour qu'il reste activé tout en rejetant les paquets ("protect") avec en option l'envoi de messages SNMP  et des fichiers de journaux - ou logs ("restrict").

switchport port-security mac-address sticky

Dans ce dernier cas, le commutateur "apprend" les adresses MAC des ordinateurs branchés sur chaque port, ce qui évite la tâche longue et fastidieuse de les configurer manuellement, port après port. Cependant, le répertoire des adresses MAC apprises se vide lorsque le commutateur redémarre.

S'il y a violation avec l'option "shutdown", le port passe à un état spécial : "err-disabled". Pour l'en sortir, il faut d'abord le mettre en état de "shutdown" et puis "no shutdown".

En outre, Cisco recommande que les ports d'accès soient désignés comme tel par cette commande que nous avons déjà vue plus haut :

switchport mode access

Mieux encore, les ports non-utilisés devraient être mis en état de "shutdown", ce qui empêche toute connexion.

Monday, October 16, 2017

Cisco - Catalyst 3560-CG : configuration (FR) - 1

English summary: I add a Cisco Catalyst 3560-CG switch to my test network and configure it via a USB to RJ45 console cable. Notes on the different modes (user, enable and configuration), securing access to the switch interfaces and basic "show" commands that display the switch configuration from various perspectives. Some knowledge of basic Cisco switch configuration is assumed.


Jusqu'à présent, les hôtes physiques de mon réseau d'essai étaient reliés les uns aux autres avec le commutateur intégré d'un pare-feu Cisco ASA. Cette solution de base fonctionnait assez bien mais se limitait à une bande passante de 100 Mbit/s alors que je voulais passer à 1 Gbit/s. Remplacer le pare-feu par un modèle plus récent était une option mais j'ai lu que les nouveaux ASA 5506 n'ont plus, justement, la fonction de commutation intégrée. Je ne sais pas si cela est exact d'ailleurs. Quoi qu'il en soit, j'avais un second objectif : ne pas oublier tout à fait les connaissances en matière de configuration de commutateurs acquises lors de ma certification CCNA et peu utilisées depuis.

J'ai donc fait l'acquisition d'un commutateur Cisco Catalyst 3560-CG. Après l'avoir déballé, je voulais en faire la configuration de base, ce qui ne va pas de soi dans la mesure où celle-ci ne peut se faire que par la console. En effet, les connexions Telnet et SSH sont désactivées par défaut. Autrefois, on accédait à la console par le port série de son ordinateur mais de nos jours ce genre de port n'existe presque plus. En revanche, on vend des câbles avec une interface USB à un bout et une interface RJ45 à l'autre, ce qui permet donc une connexion via un port USB dont à peu près tous les ordinateurs modernes sont dotés.

J'ai acheté le modèle suivant qui a l'avantage de ne nécessiter d'autres pilotes que ceux fournis avec le système d'exploitation Windows (Windows 7 dans mon cas - je ne peux rien garantir dans d'autres) :

USB Console Cable USB to RJ45 Cable

J'ai raccordé ainsi le commutateur à un portable et le lien semblait se faire. Dans le gestionnaire de périphériques, je vois s'ajouter le port "USB Serial Port (COM3)" :

Mais les pilotes qui rendent cette connexion possible ne suffisent pas. Ils ne me permettent ni de voir la configuration du commutateur ni d'envoyer les commandes pour la modifier. Il me faut un logiciel comme PuTTY ou TeraTerm.

J'ai choisi PuTTY dont le site de téléchargement se trouve à cet Url :


C'est un site digne de confiance et qui affiche d'ailleurs la signature de chaque version en MD5 et SHA qu'on peut vérifier après téléchargement. Nul besoin d'un logiciel spécial pour cela d'ailleurs. L'outil certutil le fait très bien :

certutil -hashfile [chemin vers le fichier téléchargé]

Il semble que SHA1 soit le hachage par défaut. Si vous voulez vérifier un autre hachage (comme MD5), il faut le préciser : 

Note : MD5 n'est plus sûr. Je ne l'utilise que comme exemple. Il faut préférer SHA1 ou mieux encore SHA2.

Mais revenons à la configuration de notre commutateur. Une fois PuTTY installé et ouvert, j'accède à la console avec les paramètres suivants :

Si tout se passe bien, je devrais me trouver à cette invite :


Au départ, je suis en "mode utilisateur" ("user mode" ou "user EXEC mode"). Dans ce mode, nous pouvons voir des paramètres mais nous ne pouvons rien y changer. Pour cela, nous devons passer en "mode privilégié" ("privileged mode" ou "privileged EXEC mode" ou encore "enable mode"). Il suffit de taper le mot "enable" :

Note : le signe de l'invite passe de " > " à " # ".

Naviguer entre les modes - quelques remarques

En retenant les termes anglais d'origine, nous pouvons passer du mode "user" au mode "enable" avec la commande "enable" et du mode "enable" au mode "configuration" avec la commande "configure terminal" ou "config t" :

User mode -> Enable mode -> Configuration mode

Dans le mode configuration, nous pouvons revenir sur nos pas avec cette commande :


Nous pouvons quitter le mode configuration (et n'importe quel sous-mode, comme "line console") avec cette commande :


Nous pouvons quitter le mode privilégié (et regagner le mode utilisateur) avec cette commande :


Tout cela précisé, je veux maintenant accomplir les tâches suivantes :
  • Changer le nom d'hôte du commutateur. Par défaut, il est "switch".
  • Protéger l'accès au mode privilégié avec un mot de passe.
  • Protéger l'accès au commutateur par Telnet avec un mot de passe.
  • Chiffrer les mots de passe définis ci-dessus. Sinon, ils apparaissent en clair lorsqu'on affiche la configuration du commutateur. 

J'accomplis tout cela par les commandes suivantes (les mots de passe sont dissimulés derrière les cadres blancs) :

Quelques commentaires...

Encore une fois, il ne suffit pas de passer en mode privilégié pour configurer le commutateur. Il faut en plus saisir cette commande qui nous fait passer en mode configuration :

configure terminal

ou en abrégé :

config t

Je change le nom d'hôte à "SW1" avec cette commande :

hostname SW1

En fait, nous ferions mieux de choisir un nom conforme à notre protocole de nommage et qui ait un sens dans notre environnement. Pour cette présentation, le nom "SW1" suffira.

J'active le mot de passe pour le mode privilégié avec cette commande :

enable secret mot_de_passe

Une autre option existe : enable password. Cependant, cette commande génère un mot de passe en clair, ce qui est moins sûr que le mot de passe chiffré qui résulte de la commande enable secret. Nous devons donc préférer cette dernière.

Quant aux autres mots de passe, si nous voulons les chiffrer eux aussi, nous devons exécuter cette commande, de préférence avant de les définir :

service password-encryption

Ensuite, je définis un mot de passe pour la console et les connexions Telnet avec ces commandes :

- line console 0
-- password mot_de_passe
-- login
-- exit
- vty 0 15
-- password mot_de_passe
-- login
-- exit

C'est la commande "login" qui active le mot de passe. Dans la capture d'écran, vous remarquez peut-être que je l'ai oubliée pour la console. J'ai dû l'ajouter après. Puisqu'il n'y a qu'une seule connexion simultanée possible à la console, nous saisissons l'ensemble "line console 0" (compter à partir de 0) mais "vty 0 15" parce que le commutateur prend en charge jusqu'à 16 connexions Telnet simultanées (toujours en comptant à partir de 0) et nous voulons les protéger toutes.

Ainsi, la prochaine fois que je tenterai d'ouvrir une session, il faudra que je saisisse un mot de passe pour la connexion à la console et puis pour passer en mode privilégié ("enable mode") :

Nous venons donc de changer la configuration dite "courante" (running-config) du commutateur mais nous perdrions ces modifications si nous le faisions redémarrer (avec la commande reload, par exemple), sans exécuter la commande suivante :

copy running-config start-config


copy run start

ou encore (une vieille commande toujours valable) :


(pour "write").

Il s'agit là d'une configuration de base qui sécurise l'accès au commutateur et lui donne un nom d'hôte avec plus de sens. Nous pourrions encore configurer des messages qui s'affichent lors de la connexion du commutateur ainsi qu'une adresse IP qui permettrait une gestion à distance via Telnet ou SSH et encore autres choses. Ce sont là des sujets à traiter à l'avenir. A présent, cependant, je vais consacrer le reste de ce texte à l'affichage de certains paramètres du commutateur.

Note : je présente d'abord la commande complète et puis différentes formes abrégées.

show running-config

show run

sh run

Cette commande montre la configuration actuelle ou "courante" du commutateur (avec les changements que j'ai apportés surlignés en jaune) :

Building configuration...

Current configuration : 1105 bytes
! Last configuration change at 08:26:43 UTC Wed Mar 30 2011
! NVRAM config last updated at 08:27:01 UTC Wed Mar 30 2011
version 15.0
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
hostname SW1
enable secret 5 $1$w0oU$Skn9l/1DGtFUDEEr3Tay51
no aaa new-model
system mtu routing 1500
spanning-tree mode pvst
spanning-tree extend system-id
vlan internal allocation policy ascending
interface GigabitEthernet0/1
interface GigabitEthernet0/2
interface GigabitEthernet0/3
interface GigabitEthernet0/4
interface GigabitEthernet0/5
interface GigabitEthernet0/6
interface GigabitEthernet0/7
interface GigabitEthernet0/8
interface GigabitEthernet0/9
interface GigabitEthernet0/10
interface Vlan1
 ip address dhcp
ip http server
ip http secure-server
line con 0
 password 7 151D1D03507E737C041D
line vty 0 4
 password 7 10411F1651434A53202A
line vty 5 15
 password 7 10411F1651434A53202A


show start-config

show start

sh start

Si nous enregistrons nos modifications avec la commande "copy run start", les commandes "show run" and "show start" devraient afficher des données identiques.


show interfaces

sh int

Cette commande fournit des détails sur chacune des interfaces (ports) du commutateur y compris l'interface virtuelle VLAN1 et notamment son adresse IP :

Voici les détails sur l'interface GigabitEthernet0/1 :

Si nous estimons que ces détails sont surabondants, nous pouvons nous concentrer sur une interface spécifique avec ce genre de commande :

show interfaces GigabitEthernet0/1

sh int g0/1

Autre option : nous pouvons ajouter "status" pour une vision d'ensemble plus concise :

sh int status

En particulier, cet affichage nous montre si les paramètres Duplex et Speed ("vitesse" ou plutôt bande passante dans ce contexte) résultent d'une configuration automatique négociée ("auto-configuration") ou d'une configuration manuelle. Le préfixe a- indique l'auto-négociation, soit a-full et a-1000. Rappelons que les interfaces gigabit fonctionnent toujours en mode "full-duplex".


show ip interfaces

sh ip int 

Cette commande nous offre une autre perspective sur les paramètres des interfaces de notre commutateur :

Nous pouvons obtenir un affichage plus succinct avec cette commande :

sh ip int br

Et puis...

show protocols

Enfin, la commande show version fournit, entre autres, des détails sur la version du logiciel IOS, le fichier système pour IOS et le type de licence, ipbase par exemple :

Note : les captures d'écran ne montrent que les éléments que je voulais mettre en évidence. Il y en a d'autres.


En conclusion, les commandes que je viens de présenter permettent de sécuriser l'accès au commutateur et d'en voir la configuration par défaut ainsi que les quelques changements que j'y ai apportés. Il reste encore beaucoup d'autres paramètres que nous pouvons ajuster et dont certains seront traités dans des textes à venir.

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:


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.