Déploiement d’une application Windows 8 (Interface Moderne) en entreprise

Artikel
08/06/2013

Table des matières

Etapes pour le déploiement d’une application.

Création d’un package.

Création du package : Utilisation de MAKEAPPX.EXE.

Signature du package : Utilisation de SIGNTOOL.EXE, MAKECERT.EXE et PVK2PFX.EXE.

Déploiement du package.

Installation du certificat : Utilisation de CERTUTIL.EXE.

Déploiement du package via script Powershell

Activation des appareils avec une clé de sideloading.

Conclusion.

Windows 8 est désormais disponible depuis quelques mois, et c’est vrai que nous avons concentré pas mal d’efforts sur les applications grand publique installables à partir du Windows Store. Dans cet article, nous souhaitons approfondir les différentes étapes à suivre pour déployer une application d’entreprise sans passer par le Windows Store. Bien que la majorité des détails illustrés ici ne sont pas nécessaire à connaitre pour pouvoir déployer une application Windows 8, il nous semblait judicieux de vous en donner la teneur, afin que vous soyez à même de mieux comprendre ce que des logiciels d’administration tels que Windows Intune, ou SCCM 2012, ont besoin comme ressources et informations pour déployer correctement une application Windows 8. Enfin, si vous utilisez d’autres solutions logicielles, vous pourrez utiliser le modèle de script Powershell décrit dans cet article pour déployer vos applications.

Je vous conseille d’ailleurs la lecture de l’excellent blog de mon collègue Pascal Sauliere. Sideloading : Installer des applications modernes sur Windows 8 et Windows RT

Etapes pour le déploiement d’une application.

Pour qu’un déploiement d’une application Windows 8 (Interface Moderne) se passe correctement, il faut suivre 3 étapes indispensables.

1. Créer un package qui contiendra les fichiers nécessaires au bon fonctionnement de l’application.

2. Signer ce package avec un certificat valide.

3. Préparer le poste cible, afin que l’application puisse se déployer correctement.

o Déployer le certificat

o Déployer une licence pour les applications ou clé de sideloading . Comme nous le verrons par la suite, selon les cas, il sera nécessaire ou pas d’acquérir cette clé de sideloading.

Note : Nous précisons interface moderne, par opposition à des applications Windows 8 de bureau, qui s’installent de manière traditionnelle et qui ne rentrent pas dans le cadre de cet article.

Création d’un package

Comme indiqué dans la documentation Packages et déploiement d’applications (applications du Windows Store), un package, est un conteneur ayant l’extension .appx, incluant les fichiers de l’application et les dépendances. Il est basé sur la norme OPC, norme utilisé entre autre par les applications Office. Pour notre compréhension, nous avons seulement besoin de retenir que ce package n’est ni plus ni moins qu’un fichier zippé.

Note : en le renommant avec extension .zip, vous avez accès directement à son contenu.

Pour créer un package, vous avez 3 solutions.

· En utilisant des APIS C++ dont vous trouverez la documentation ici.

· En utilisant directement Visual Studio 2012
https://msdn.microsoft.com/fr-fr/library/hh454036.aspx
https://msdn.microsoft.com/fr-fr/library/hh975357.aspx

· En utilisant des outils du Kit de développement Windows 8.

Note : Dans cet article nous détaillons les étapes nécessaires à la création et à la signature d’un package pour qu’il puisse s’installer correctement. Néanmoins, sachez qu’il n’est pas forcément nécessaire de le faire, car Visual Studio 2012 peut créer et signer ce package automatiquement.

Création du package : Utilisation de MAKEAPPX.EXE.

On considère que vous avez déjà créé et compilé l’application. Vous devez donc vous retrouver avec une arborescence comme sur la figure suivante :

Néanmoins dans cette arborescence, il manque un élément qui décrit l’identité de l’application, l’OS sur lequel tourne l’application, les ressources de l’application, les capacités de l’application, ainsi que les dépendances de l’application. Cet élément, est le fichier manifeste AppxManifest.xml qui est essentiel pour la création du package.

<?xml version="1.0" encoding="utf-8"?>
<Identity Name="b5c68d7e-ad25-40ea-b70e-667e7fb08c4d" Publisher="CN=ericv" Version="1.0.0.0" ProcessorArchitecture="neutral" />
<Properties>
<DisplayName>TestDeploiement</DisplayName>
<PublisherDisplayName>ericv</PublisherDisplayName>
<Logo>Assets\StoreLogo.png</Logo>
</Properties>
<Prerequisites>
<OSMinVersion>6.2.1</OSMinVersion>
<OSMaxVersionTested>6.2.1</OSMaxVersionTested>
</Prerequisites>
<Resources>
<Resource Language="EN-US" />
</Resources>
<Applications>
<Application Id="App" Executable="TestDeploiement.exe" EntryPoint="TestDeploiement.App">
<VisualElements DisplayName="TestDeploiement" Logo="Assets\Logo.png" SmallLogo="Assets\SmallLogo.png" Description="TestDeploiement" ForegroundText="light" BackgroundColor="#464646">
<DefaultTile ShowName="allLogos" />
<SplashScreen Image="Assets\SplashScreen.png" />
</VisualElements>
</Application>
</Applications>
<Capabilities>
<Capability Name="internetClient" />
</Capabilities>
<build:Metadata>
<build:Item Name="TargetFrameworkMoniker" Value=".NETCore,Version=v4.5" />
<build:Item Name="VisualStudio" Version="11.0" />
<build:Item Name="OperatingSystem" Version="6.2.9200.16384 (win8_rtm.120725-1247)" />
<build:Item Name="Microsoft.Build.AppxPackage.dll" Version="11.0.50727.1" />
<build:Item Name="Microsoft.Windows.UI.Xaml.Build.Tasks.dll" Version="11.0.50727.1" />
<build:Item Name="MakePri.exe" Version="6.2.9200.16384 (win8_rtm.120725-1247)" />
</build:Metadata>
</Package>

Remarque : Nous reviendrons plus tard sur la propriété de Publisher="CN=ericv" , car elle aura son importance lors de la signature de l’application.

Vous pouvez construire manuellement ce fichier en suivant les instructions dans l’aide en ligne How to create a package manifest manually, néanmoins dans un 1^er temps il est plus judicieux de le récupérer à partir du répertoire \bin\release. En effet, après compilation de l’application, Visual Studio 2012 le génère automatiquement. Copiez-le alors dans l’arborescence de votre projet, comme indiqué sur la figure suivante :

Pour créer un package de l’application, il faut utiliser l’outil MAKEAPPX.EXE de la manière suivante :

& '..\Program Files (x86)\Windows Kits\8.0\bin\x86\makeappx.exe' pack /v /h SHA256 /d "C:\temp\manuel" /p TestDeploiement.appx

Remarque : Nous utilisons dans cet article, des scripts Powershell pour exécuter nos commandes.

pack : Permet de créer un package (par opposition à la commande unpack, qui permet de dé zipper)

/v : affiche les messages (verbose)

/h : Créé un fichier Block Map (AppxBlockMap.xml) qui contient un hash SHA256 de tous les fichiers contenus dans le répertoire. Le fait de hacher les fichiers, empêchera quiconque d’altérer le package. Ici nous utilisons SHA256, mais il possible d’utiliser d’autres algorithmes (SHA384, SHA512).
Note : Retenez bien l’algorithme de hachage que vous utilisez, car il faudra le reprendre pour le certificat, ainsi que pour la signature du package.

/d : Chemin d’accès l’arborescence des fichiers

/p : Non du fichier appx de destination.

Note : Pour de plus amples informations sur les paramètres et l’utilisation de MAKEAPPX, reportez-vous à l’aide en ligne: https://msdn.microsoft.com/en-us/library/windows/desktop/hh446767(v=vs.85).aspx

Le fichier TestDeploiement.appx, est créé et en le dé-zippant comme nous pouvons le voir sur la figure suivante :

MAKEAPPX a créé un fichier AppxBlockMap.xml qu’il a inclus dans le package. Ce fichier contient la liste des fichiers qui ont été hachés.

<BlockMap xmlns="https://schemas.microsoft.com/appx/2010/blockmap"
HashMethod="https://www.w3.org/2001/04/xmlenc#sha256">
<File Name="Assets\DarkGray.png" Size="560" LfhSize="49">
<Block Hash="U4fpsAY9b4tSDh0bv0V0bXG/CNdjhP6wqQBd5Qa/nUI="/>
</File>
<File Name="Assets\LightGray.png" Size="560" LfhSize="50">
<Block Hash="DV0Yg6Jx0cm9SpEe3WvEeOEpiKnTQPPNMdQ8rExT2cE="/>
</File>
<File Name="Assets\MediumGray.png" Size="561" LfhSize="51">
<Block Hash="C8gMoc/xDtxoIJOG04Vw/EcxxvqtugqB54lCl3vsUco="/>
</File>
<File Name="Assets\Logo.png" Size="801" LfhSize="45">
<Block Hash="VL6ArkjkJC1WFwJI5zD/rGCigo0HJgoEjirA/WI4YjQ="/>
</File>
<File Name="Assets\SmallLogo.png" Size="329" LfhSize="50">
<Block Hash="NoVfu8bClyI81EmmfQL5yXbdPkMsmQW0/8avjx7sR6k="/>
</File>
<File Name="Assets\SplashScreen.png" Size="2146" LfhSize="53">
<Block Hash="Hbz7CYy7sz2pSm9MKPLegtlySyhUtVmaefln93bw/jY="/>
</File>
<File Name="Assets\StoreLogo.png" Size="429" LfhSize="50">
<Block Hash="3IJfy5T/YdOzk2jCfTEb33RzDl6pJERy5b/lEaEiS0M="/>
</File>
<File Name="Common\StandardStyles.xaml" Size="119067" LfhSize="56">
<Block Hash="Q03txv1/VSMxbYtxUBObzX4ZBYb6zIAU1Cj8nCPvo7U=" Size="5206"/>
<Block Hash="91O3FnJf9yOWG5zuBHiJS/OewSKS80AAylVNBMWENbI=" Size="4383"/>
</File>
<File Name="App.xaml" Size="926" LfhSize="38">
<Block Hash="n+b5r2Rxv1vGwQ57fzziYTkGx9RhenbyCFAcrVFJMt8=" Size="370"/>
</File>
<File Name="GroupDetailPage.xaml" Size="7675" LfhSize="50">
<Block Hash="bhYCLR56sIQNyEv9K8BI3o/YK97VFVdMFxlRk1gb7Qc=" Size="1770"/>
</File>
<File Name="GroupedItemsPage.xaml" Size="9233" LfhSize="51">
<Block Hash="yO5Sa/SVI7Fqa9dgqDjkW2zy0JTNzaJJCiKURC/BPd8=" Size="1934"/>
</File>
<File Name="ItemDetailPage.xaml" Size="10986" LfhSize="49">
<Block Hash="z5U+e+hHIGqsBOyYlVvFYLrO+Nk5URj9Dbiyylxn6oo=" Size="2216"/>
</File>
<File Name="DataModel\SampleDataSource.cs" Size="30555" LfhSize="59">
<Block Hash="FtFQmlKIL4x+vTBuVUSBSAcZIlzs+bcgCBsDu9MjNiQ=" Size="3471"/>
</File>
<File Name="TestDeploiement.pdb" Size="118272" LfhSize="49">
<Block Hash="PQUVHs5sUJAUaw9cj290Zer4izUz7gZiM73Dwc9pieI=" Size="12884"/>
<Block Hash="1LzNNNR0EWMBPh4wLPD2371f5pHMDS9J70c/vO/ro6w=" Size="14084"/>
</File>
<File Name="TestDeploiement.exe" Size="52736" LfhSize="49">
<Block Hash="js9b7xhjwvJq7EnEoSDLHGVHes2Of+8NIVVlOFmsxvE=" Size="21944"/>
</File>
<File Name="resources.pri" Size="2608" LfhSize="43">
<Block Hash="H+N2TIRqlaCDzwWwmH/tYLu0nLQA201cAVsHvh0yOeQ=" Size="767"/>
</File>
<File Name="AppxManifest.xml" Size="2116" LfhSize="46">
<Block Hash="aZ6ujWLP7cPC5HIaRkITZYJRyGaHyFqslmlt/g72j7Y=" Size="970"/>
</File>
</BlockMap>

Signature du package : Utilisation de SIGNTOOL.EXE, MAKECERT.EXE et PVK2PFX.EXE

Une fois le package créé, il faut le signer, deux cas de figure s’offrent à vous :

· Vous n’avez pas de certificat valide, dans ce cas il faudra créer un certificat auto signé à des fins de tests.

· Vous avez un certificat valide d’entreprise, cas que nous traiterons par la suite, car il faudra alors modifier la propriété Publisher dans le fichier manifeste.

Pour notre démonstration à des fins de tests, nous allons créer un certificat auto-signé à l’aide de l’outil MAKECERT.EXE.

Note : Encore une fois cet outil n’est à utiliser qu’à des fins de tests, dans une organisation digne de confiance, il vous faudra impérativement utiliser un certificat valide et non auto-signé.

& '..\Program Files (x86)\Windows Kits\8.0\bin\x86\makecert.exe' -a SHA256 -n CN=ericv /r /sv testDeploiement.pvk /h 0 /eku "1.3.6.1.5.5.7.3.3" /e "05/17/2013" TestDeploiement.cer

MAKECERT demande un mot de passe afin de protéger efficacement la clé privée. Pour notre exemple nous choisirons "TestDeploiement!"

ré-utilisez le même mot de passe.

Plusieurs choses à noter :

· Il faut utiliser le même algorithme de hachage que celui utilisé pour la création du package /a SHA256

· Il faut utiliser le même nom de Publisher que celui indiqué dans le manifeste –n CN=ericv

· Pour le paramètre /eku, il faut utiliser au minimum la suite 1.3.6.1.5.5.7.3.3, qui indique que le certificat sera utilisé pour de la signature de code.

· Il faut définir une date de validité du certificat /e.
Pour ce dernier paramètre, évitez de mettre une date de validité trop longue.

Note : Pour plus d’informations sur MAKECERT reportez-vous à l’aide en ligne. https://msdn.microsoft.com/fr-fr/library/bfsktky3(v=VS.80).aspx et pour création d’un certificat auto signé c’est ici. https://msdn.microsoft.com/fr-fr/library/windows/desktop/jj835832(v=vs.85).aspx

Néanmoins, pour signer le package, le certificat seul ne suffit pas, il faut un fichier au format .pfx (Personal Information Exchange) qui contiendra les clés privée et publique. Pour créer ce fichier nous allons utiliser l’utilitaire PVK2PFX qui prend en entrée le fichier TestDeploiement.pvk et TestDeploiement.cer que nous venons de créer, en précisant le même mot de passe à l’aide du paramètre /pi, et en sortie le fichier TestDeploiement.pfx.

& '..\Program Files (x86)\Windows Kits\8.0\bin\x86\pvk2pfx.exe' /pvk TestDeploiement.pvk /pi TestDeploiement! /spc TestDeploiement.cer /pfx TestDeploiement.pfx

Enfin nous allons signer le package avec l’outil SIGNTOOL qui prend en entrée le fichier TestDeploiement.pfx.

& '..\Program Files (x86)\Windows Kits\8.0\bin\x86\signtool.exe' sign /a /v /fd SHA256 /f TestDeploiement.pfx /p TestDeploiement! TestDeploiement.appx

The following certificate was selected:

Issued to: ericv

Issued by: ericv

Expires: Fri May 17 00:00:00 2013

SHA1 hash: 2394E7E30496BB2C06FE2A1BAC3DF8DEDDB2CCF8

Done Adding Additional Store

Successfully signed: TestDeploiement.appx

Number of files successfully Signed: 1

Number of warnings: 0

Number of errors: 0

A noter, que nous utilisons une nouvelle fois le même algorithme de hachage SHA256, et que nous précisons encore une fois le mot de passe /p TestDeploiement!
D’autre part SIGNTOOL possède un autre paramètre /u (non utilisé ici), et qui permet de spécifier l’utilisation avancée de la clé (eku). Par défaut eku est à Signature du code (1.3.6.1.5.5.7.3.3), nous n’avons donc pas besoin de le préciser dans la commande.

Note : Si vous obtenez l’erreur suivante avec SIGNTOOL, vérifiez la date de validité de votre certificat.

signtool.exe : SignTool Error: No certificates were found that met all the given criteria.

Au caractère Ligne:8 : 1

+ & '..\Program Files (x86)\Windows Kits\8.0\bin\x86\signtool.exe' sign /a /v /fd ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : NotSpecified: (SignTool Error:...given criteria.:String) [], RemoteException

+ FullyQualifiedErrorId : NativeCommandError

Note : Pour de plus amples information sur SIGNTOOL, reportez-vous à la documentation en ligne.
https://msdn.microsoft.com/fr-fr/library/8s9b9yaz%28v=VS.80%29.aspx

SIGNTOOL a ajouté le fichier AppxSignature.p7x de signature numérique au package comme illustré sur la figure suivante :

Note : Pour en savoir plus sur le contenu du package signé vous pouvez consulter l’aide en ligne. https://msdn.microsoft.com/fr-fr/library/windows/apps/hh464929.aspx

Si vous avez déjà un certificat valide d’entreprise, il n’est bien évidement pas nécessaire de créer le certificat, et seule les étapes de création et de signature du package seront obligatoire. Mais vous devrez être attentif à bien indiquer dans le manifeste au niveau de la propriété Publisher, la bonne chaine de caractères.

Par exemple Publisher=OID.0.9.120.167788.100.1.1=2536363, CN=MASOCIETE, OU=MASOCIETE. (Cette chaine provient de votre certificat, ici elle est bidon)
Si tel n’est pas le cas, lors de la signature vous obtiendrez une erreur du type signtool error 0x8007000b

Note : ¨ Pour déboguer cette erreur, il vous suffit d’aller voir dans le journal des évènements.
Journaux des applications et des services\Microsoft\Windows\AppxPackagingOM\
l’erreur qui est générée. Elle devrait vous donner la bonne chaine du Publisher.
En règle générale, SIGNTOOL, logue toutes ces erreurs dans ce journal. Pour de plus amples informations sur la manière de résoudre des problèmes, reportez-vous à la section How to troubleshoot app package signature errors

Remarque : Si vous ne souhaitez pas manipuler les outils du SDK pour créer et signer le package de l’application avec votre certificat d’entreprise, vous pouvez utiliser directement Visual Studio 2012 en lui précisant le certificat à utiliser.

1. En indiquant directement dans Visual Studio 2012, qu’il faut utiliser votre certificat.

2. Puis créer le package et la signature automatiquement

Déploiement du package

Il existe 3 manières de déployer une application Windows 8.

· Via script Powershell, comme nous le détaillerons ici

· Via Microsoft SCCM 2012 SP1

· Via Microsoft Windows Intune

Note : En fait, il existe d’autres méthodes de déploiement de package via l’outil de gestion et maintenance des images de déploiement, ou même via InstallShield, mais que nous n’aborderons pas dans cet article.

Installation du certificat : Utilisation de CERTUTIL.EXE

Avant de déployer notre package, il faut installer le certificat. Soit vous utilisez un certificat d’entreprise, dans ce cas-là, il y a de fortes chances pour qu’il soit déjà installé sur votre poste d’entreprise via des stratégies de groupe mis en place par votre IT interne, soit l’installer à l’aide de l’outil CERTUTIL.EXE.

certutil -addstore trustedpeople .\TestDeploiement.cer

trustedpeople "Personnes autorisées"
La signature correspond à la clé publiquet d
Le certificat "CN=ericv" a été ajouté au magasin.

CertUtil: -addstore La commande s’est terminée correctement.

Pour vérifier si le certificat est dans le bon magasin, lancez l’outil CERTMGR.EXE, choisissez le magasin Personnes autorisées, comme indiqué sur la figure suivante :
On voit bien ici que le certificat auto signé, délivré à ericv par ericv, sa date d’expiration et l’eku (Enhanced Key usage), qui est bien sur signature de code.

Note : Pour de plus amples informations sur les certificats, reportez-vous à l’aide en ligne https://technet.microsoft.com/en-us/library/cc700805.aspx

Déploiement du package via script Powershell

Pour déployer l’application, nous utiliserons la commande Powershell Add-AppxPackage

Add-AppxPackage .\TestDeploiement.appx

Le déploiement est réussi, mais la question essentielle qui se pose, est-ce que l’installation réussira sur toutes les configurations ?

Cela dépend de certains facteurs que nous allons détailler maintenant.

Dans notre cas de figure, nous sommes sur un poste du développeur, c’est-à-dire que Visual Studio 2012 est installé, et particularité, pour développer des applications Windows 8 (Interface Moderne), il demande une clé de licence développeur. Cette clé est obtenue en se connectant avec un Compte Microsoft. Comme illustré sur la figure suivante :

Clé de licence développeur renouvelable tous les mois.

Note : Le Compte Microsoft qui n’est ni plus ni moins qu’un LIVE ID, que nous mentionnons plus haut n’est pas le compte développeur qui est nécessaire pour le déploiement via le Windows Store. Ce Compte Microsoft, est uniquement nécessaire pour développer des applications Windows 8 avec Visual Studio 2012, mais n’est pas nécessaire pour le déploiement d’une application d’entreprise. Il n’est à utiliser qu’a des fins de tests.
Pour résumé. Le Compte Microsoft est nécessaire pour développer des applications Windows 8 Interface Moderne, le Compte Développeur est nécessaire pour pouvoir publier des applications dans le Windows Store.

Le déploiement de l’application aboutit car la commande Add-AppxPackage se base sur cette clé de licence développeur pour déployer l’application.
Si vous souhaitez tester votre déploiement sur d’autres postes qui ne possèderaient pas une licence développeur, vous pouvez à l’aide de la commande Show-WindowsDeveloperLicenseRegistration, en demander une et en entrant vos informations de compte Microsoft.

Remarque : Si vous avez créé le package avec Visual Studio 2012, comme nous l’avons déjà vu plus haut, Visual Studio créé également un script d’installation Powershell (Add-AppDevPackage.ps1) que vous pouvez utiliser pour tester le déploiement de l’application sur d’autres postes. Si la licence développeur n’existe pas sur le poste cible, il vous la demandera automatiquement. D’ailleurs, en analysant ce script vous retrouverez certaines étapes de cet article.

Le script Add-AppDevPackage.ps1 :

· Vérifie si le package est bien signé. (Get-AuthenticodeSignature)

· Test la présence du certificat dans le répertoire courant et vérifie son format, sa date d’expiration et la signature de code pour l’eku.

· Vérifie que le package a bien été signé avec ce certificat. (Get-PfxCertificate).

· Vérifie que le certificat développeur est bien présent (Get-WindowsDeveloperLicence), si non demande à l’utilisateur de l’obtenir (Show-windowsDeveloperLicenseRegistration)

· Enfin, installe le package (Add-appxPackage).

Il existe d’autres commandes powershell que vous pouvez utiliser, pour tester et débuguer le déploiement d’un package.
Get-AppxLastError pour obtenir la liste des erreurs lors du déploiement
Get-AppxLog, pour obtenir le log du déploiement d’un package
Remove-AppxPackage, pour désinstaller un package

Note : Vous pouvez utiliser l’outil powershell_ise.exe, éditeur de script PowerShell pour écrire, déboguer ou exécuter des commandes Powershell.

Cette clé de licence développeur est à utiliser lorsque vous souhaitez, non pas tester le déploiement, mais tester si l’application fonctionne correctement sur tous types de configurations. Elle fausse totalement le déploiement de l’application en entreprise, il est donc judicieux de s’assurer qu’elle ne soit plus présente sur les postes cibles.

Sur notre poste de développement, nous allons donc la retirer à l’aide de la commande Unregister-WindowsDeveloperLicense.

Notre poste se retrouve alors vierge de toute licence, néanmoins, il faut au préalable désinstaller l’ancienne installation de notre package, soit vous le faite manuellement, soit vous utilisez la commande suivante :

Get-AppxPackage -name b5c68d7e-ad25-40ea-b70e-667e7fb08c4d | Remove-AppxPackage

Ou le GUID correspond au nom de l’application que l’on retrouve dans le fichier manifeste à la propriété Identity
<Identity Name="b5c68d7e-ad25-40ea-b70e-667e7fb08c4d"…

Ensuite on relance le déploiement avec la commande Add-AppxPackage, qui réussit, car notre poste dispose des caractéristiques suivantes :

· C’est un poste Windows 8 Entreprise
· Il est inscrit dans le domaine de l’entreprise
· La stratégie de groupe Autoriser l’installation des applications approuvées, est activée, comme indiqué sur la figure suivante :

Ce dernier cas de figure est le plus simple, car le poste est inscrit et géré par l’entreprise. En effet, Windows 8 Entreprise inscrit dans un domaine, possède des fonctionnalités internes qui permettent de déployer les applications sans obtenir de clé de sideloading.

Activation des appareils avec une clé de sideloading
Mais quand est-il lorsque le poste n’est pas un inscrit dans un domaine et que nos appareils n’utilisent pas Windows 8 Entreprise ?

Si nous essayons de déployer notre package sur des appareils Windows RT, Windows 8 Pro, et Windows 8 Entreprise hors domaine, la commande Add-AppxPackage retournera une erreur.

Le message est explicite , il vous faut une licence valide, c’est-à-dire une clé de Sideloading pour activer vos appareils.

L’obtention d’une telle clé est hors scope, néanmoins, je vous encourage à télécharger le document Volume Licensing Guide for Windows 8 and Windows RT si vous souhaitez en savoir plus.
Pour obtenir des clés de SideLoading vous pouvez également allez à la section Product Activation Key Information

Une fois que vous avez en poche cette fameuse clé de sideloading, qui permet d’activer l’appareil et ceci pour toutes les applications Windows 8 (Interface Moderne) qui y seront déployées, il faut la déployer.

Pour c faire nous allons utiliser l’outil SLMGR.EXE

Une 1^ere fois avec le paramètre /ipk avec la clé elle-même.

slmgr /ipk <Clé de licence>

Une seconde fois avec le paramètre /ato et un numéro d’identification unique qui sera toujours le même afin d‘activer la licence.

slmgr /ato ec67814b-30e6-4a50-bf7b-d55daf729d1e

Ensuite, vous pouvez déployer l’application normalement.

Conclusion

Comme vous pouvez le constater, il est possible de déployer des applications Windows 8 sans passer par le Windows Store, il suffit alors de créer un script Powershell adéquate et l’utiliser avec vos propres méthodes de déploiements.

Néanmoins, Microsoft propose des logiciels d’administration, tels que Windows Intune, ou SCCM 2012 SP1, qui vous aiderons :

· A déployer facilement vos packages d’applications, qu’elle que soit leur méthode de création, que ce soit à l’aide d’outils du Kit de développement Windows 8 comme nous venons le voir, ou tout simplement à l’aide de Visual Studio 2012.

· A mettre à disposition aux utilisateurs les applications, via un Store privé d’entreprise.

En résumé, avant de déployer son application d’entreprise, il suffit de vérifier :

· Que le package est bien valide.

· Que le package est bien signé avec le bon certificat.

· Que le certificat est bien déployé sur les postes clients.

· Que vous avez besoin ou pas de clés de sideloading.

Eric Vernié