6475606961

Un site utilisant WordPress

By

Quelles URLs à authoriser pour acceder au Store Applicatif Windows

Apres quelques mois d’absence sur ce blog, mais une présence plus régulière sur mon blog « linked In Pulse » , j’ai décider de pousser une petit billet rapide et j’espère pratique sur la liste des urls qu’il faudrait autoriser sur un proxy web pour permettre à des machines Windows 10 d’utiliser le store public et de mettre à jour ces applications.

Nous sommes donc dans un contexte ou de fortes restrictions sont en place sur les Urls de navigation autorisées par l’IT pour les employés de l’entreprise.

La question me vient de temps en temps d’entreprises du secteur bancaire par exemple et la réponse n’est pas forcement simple car les articles officiels sur le sujet sont un peu ancien et Microsoft n’est pas très moteur sur ce genre de publication … Tout simple parce que publier ce type d’information implique ensuite des contraintes de maintenance lorsque des modifications interviennent.

Un autre point gênant pour mes clients : Cette liste officielle utilise beaucoup de « wildcard » comme *.microsoft.com par exemple. Essayons de voir si l’on ne peux pas affiner tout cela.

Pour info voici une de ces « KB officielle » :
713-286-3818

Comme vous le voyez à son titre, elle n’est plus toute jeune 🙂 mais nous allons nous en servir comme base.
La méthode que je propose va consister à :

  • Partir de la base officielle
  • Filtrer par bon sens
  • Etendre par analyse réseau
  • … Tester en grandeur nature (lors d’un update de ce billet)

Voici donc une premiere liste issue de la KB.

account.live.com
clientconfig.passport.net
wustat.windows.com
*.windowsupdate.com
*.wns.windows.com
*.hotmail.com
*.outlook.com
*.microsoft.com
*.msftncsi.com/ncsi.txt

Quelques remarques :
La dernière URL à changé depuis Windows 10 Anniversary. C’est maintenant www.msftconnecttest.com/connecttest.txt qu’il faut utiliser.
*.wns.windows.com est utilisé pour les notifications par « Toast » des applications. Je propose de nous en passer car notre objectif est juste de pouvoir lancer l’application Store et lui permettre de mettre à jour nos Apps.
wustat.windows.com et *.windowsupdate.com concernent Windows Update. Très important pour d’autres briques de la machine. Je garderais juste la deuxième.
Si vos accès s’effectuent au travers d’une identité « tenant » uniquement (pas d’identité publique MSA), je suggère alors de retirer *.hotmail.com et *.outlook.com et autres URLs live et passeport.

Finalement d’autres sources suggèrent les URLs suivantes:

login.windows.net
account.live.com
businessstore.microsoft.com

Notre nouvelle liste serait :

• login.live.com
• login.windows.net
• clientconfig.passport.net
• *.windowsupdate.com
• businessstore.microsoft.com
• www.msftconnecttest.com/connecttest.txt

… Et *.microsoft.com

Cette dernière est beaucoup trop large pour beaucoup de mes clients « paranoiac » :-).
Essayons d’affiner cela à l’aide d’un analyseur réseau, et peut être que nous trouverons aussi d’autres URLs non listées pas la KB.

Le test que j’ai lancé est simple. L’outil d’analyse réseau en mode capture, je lance l’application du Store et je demande une mise à jour des applications de la machine.

Voici ce que j’ai obtenu

• storeedgefd.dsx.mp.microsoft.com
• store-images.s-microsoft.com
• store-images.microsoft.com
• musicdelivey-ssl.xboxlive.com
• setting-ssl.xboxlive.com
• collections.md.mp.microsoft.com

Je propose de nous passer de toutes les URL xboxlive.com

Proposition finale:

Voici ce que pourrais être la liste a final :

• login.windows.net
• *.windowsupdate.com
• businessstore.microsoft.com
• storeedgefd.dsx.mp.microsoft.com
• store-images.s-microsoft.com
• store-images.microsoft.com
• collections.md.mp.microsoft.com
• www.msftconnecttest.com/connecttest.txt

*************************************
UPDATE Suite test en situation réelle
*************************************

J’ai eu l’occasion de tester la liste ci dessus dans un contexte réelle. A savoir, une Surface Hub connectée derrière un proxy filtrant. La configuration du proxy était de tout blocker, sauf la dite liste d’Url.
Sur cette base l’application du Store se lance bien … Mais au fur et à mesure que l’on avance dans des tests de download de nouvelles Apps ou de mises à jour, d’autres URLs se sont alors présentées au filtre du proxy.

Voici donc une version mise à jour, basée sur ces tests réels:


• login.windows.net
• *.windowsupdate.com
• businessstore.microsoft.com
• storeedgefd.dsx.mp.microsoft.com
• store-images.s-microsoft.com
• store-images.microsoft.com
• collections.md.mp.microsoft.com
• www.msftconnecttest.com/connecttest.txt
• displaycatalog.mp.microsoft.com
• purchase.mp.microsoft.com
• *.delivery.mp.microsoft.com
• licensing.mp.microsoft.com

A ceci s’ajoutera quelques URLs supplémentaires suivant que l’on utilise un compte Microsoft (MSA) ou un compte tenant (Store for Business) pour s’authentifier auprès du Store. A noter que les deux peuvent coexister et dans ce cas il faudra ajouter les deux listes d’url au proxy.

MSA


• Login.live.com
• auth.gfx.ms
• User.storage.live.com (pour afficher l’icone de l’utilisateur)

Tenant ID


• secure.aadcdn.microsoftonline-p.com
• portal.manage.microsoft.com
• enterpriseregistration.windows.net

Finalement, je porte votre attention sur 3 points.

  • Ce billet n’engage que moi et non Microsoft.
  • Il peut encore persister des oublis ou des cas non testés (Tenant Id avec connexion ADFS par exemple) … Mais globalement les résultats de nos tests ont montrés une Hub fonctionnelle concernant sa gestion d’application au travers du Store
  • Plus on devient précis dans les URLs, plus la liste s’agrandi … Et c’est normal 🙂

That's All Folks

Stef

By

Mise à jour du Firmware de la Surface Dock

Nous avons finalement mise en ligne la dernière version de la mise à jour de Surface Dock. Si vous l’attendiez impatiemment je vous conseille de cliquer sur ce lien ( 514-470-3113 ) et de l’installer sans lire le reste de ce billet :-).

L’outil qui nous intéresse est « SurfaceDockUpdater.msi » … Sélectionnez le cliquez « Next » pour démarrer le téléchargement.

Lorsque vous aurez récupéré le MSI lancez son installation …

Note: Si vous aviez déjà installé l'outil dans une version précédente, vous devez le désinstaller au préalable.

… Rebootez la machine

2.0.22 est la version de l’outil qui devrait apparaître dans la liste des programmes installés.

Voila, vous avez maintenant devant vous une machine capable de mettre a jour le firmware de toutes les Surfaces Dock que vous y connecterez. Cette nouvelle version de Firmware est cumulative. cela veut dire qu’elle inclues la première version que nous avions sorti en Avril dernier qui adressait spécifiquement des problématiques de qualité sur le signal vidéo. Dans cette version le focus porte sur le hub USB intégré au dock. Si par exemple vous observiez des déconnexions aléatoires sur votre connexion Ethernet, vous allez très certainement bénéficier de ce nouveau Firmware.

Alors comment opérer une mise à jour ?
======================================

Lancez le « Surface Dock Updater » et il va vous guider au travers d’un assistant sur les quelques manipulations physiques nécessaires pour mettre à jour une Surface Dock ( principalement une connexions / déconnexions du câble Surflink ).

A AUCUN MOMENT VOUS NE DEVEZ RETIRER LE CABLE D’ALIMENTATION DU DOCK.

Il n’y a pas de raison que cela arrive et ce message est rappelé lors du processus de mise à jour mais au cas ou je préfère le rappeler.
Le processus dure une dizaine de minutes par Dock et l’outil vous indiquera en première étape si le dock possède la dernière version du firmware. Si c’est le cas passez au dock suivant 🙂

Un point important que j’aimerais souligner est que le « Surface Dock Updater » est le seul moyen disponible pour appliquer cette nouvelle version du Firmware sur un Surface Dock … Et il n’y a aucun moyen d’éviter l’assistant graphique. Ce fut une décision délibérée prise par le groupe produit pour limiter au maximum les risques de transformer votre Dock en cale pour armoire 🙂

Plus d’infos (en anglais) sur l’outil de mise à jour de la Surface Dock sur : /technet.microsoft.com/en-us/itpro/surface/surface-dock-updater

Pour finir voici une "side note" reçu du groupe produit en même temps que la notification de publication de l'outil.

Surface Pro 4 and Surface Book devices will not be able to PXE boot from docks with this new firmware unless they have UEFI version * 1281.768.0 (August) or later

Cela peut être un problème dans certain cas de figure et je vais essayer de publier rapidement un article expliquant comment mettre à jour le firmware d'une Surface à l'aide d'une clé WinPE.
That's All Folks

Stef

By

732-429-7192

Premier Billet de la rentrée 🙂 … Je vous propose d’évoquer la gestion de l’UEFI sur Surface 3.

Même si nous avons arrêté la production des Surfaces 3, elles demeurent utilisées chez pas mal de clients. Une demande récurrente que j’avais lors de projets de déploiement pour ce modèle, était d’avoir la possibilité de gérer leur UEFI comme nous le faisons avec leurs « grandes sœurs » les Surface Pro 3.

Cette demande à été remontée et finalement prise en compte. Le groupe produit n’as pas eu à réécrire un nouvel outil pour cela. L’action fut de modifier l’UEFI des Surface 3 pour qu’il expose les APIs dont se sert l’outil d’administration des Surfaces Pro 3. Pour info sur ces modèles (S3,SP3), l’UEFI n’est pas propriétaire Microsoft comme sur la Pro 4 ou la Book. Les modifications demandent donc beaucoup plus de temps et de validation. C’est d’ailleurs la raison principale de l’écriture d’un UEFI propriétaire sur la nouvelle génération de Surfaces.

Pour en revenir au sujet du billet, nous avons produit une mise à jour de l’UEFI des Surface 3 cet été spécialement pour cela. La version embarquant les API compatibles est v1.51116.178.0 ( Détail sur l’historique des mises à jours ici : /www.microsoft.com/surface/en-us/support/install-update-activate/surface-3-update-history?os=windows-10
)

Vous obtenez la version de votre UEFI en tapant la commande suivante dans une fenêtre Powershell:

gwmi win32_pnpsigneddriver |select devicename,driverversion |where-object { $_.devicename –like   « *Surface*UEFI » }

Une fois ceci vérifié, il faut télécharger l’outil de gestion de gestion de l’UEFI depuis la page de téléchargement des drivers pour votre Surface. Par exemple ici pour une Surface 3 Wifi mais l’outil reste le même quelque soit le type de machine ( Wifi/LTE )

Attention, si vous aviez déjà téléchargé l’outil pour la Surface Pro 3, téléchargez le de nouveau pour gérer vos Surfaces 3 car la vérification des modèles compatibles a été mise à jour depuis peu

L’outil se présente sous la forme d’un MSI a installer sur la machine que l’on veut administrer. Il est identique à celui de la Surface Pro 3 dans son fonctionnement et le Blog 256-664-2098 donne une bonne description de ce que l’on faire avec.

En ce qui nous concerne, nous allons juste vérifier rapidement que l’outil s’est bien installé

Pour cela on utilise 2 commandes dans une fenêtre Powershell lancée avec élévation de privilèges:

  1. Chargement de l’assembly de l’outil

    [System.Reflection.Assembly]::Load(“SurfaceUefiManager, Version=1.0.5483.22783, Culture=neutral, PublicKeyToken=20606f4b5276c705”)

  2. Envoi de la commande de recuperation de tous les parametre sans formatage

    [Microsoft.Surface.FirmwareOption]::All()

Un article donnant plus de détails sur l’utilisation de l’outil est aussi disponible sur le blog officiel de l’équipe Surface. Meme s’il parle de Surface Pro 3 cela s’applique donc maintenant aussi aux Surface 3. Vous le trouvez (629) 802-3088

Voila, en espérant que ce billet vous aidera à mieux intégrer vos « legacy Surface » dans votre IT. Notez bien que pour les Surface de nouvelle génération (Pro4/Book et suivantes :-)) la gestion s’effectue au travers outil dont l’approche est différent et je vous conseille de consulter le billet que j’ai écrit fin juin pour en savoir plus.

That's All Folks

Stef