Windows 10 just been released a month ago. Because I do not have enough time to actively participate to the insider phase, I did not yet tested with DirectAccess. Off course, it’s working. But there are a few changes some good, one bad. Let’s start with the bad one. My old friend Network Access Protection passed away.

If you have a look at the DirectAccess Unsupported Configurations, Network Access Protection was deprecated since Windows Server 2012 R2.

It was still included in Windows 7 / 8.1, but in Windows Server 2012 R2, it was the last Microsoft operating system that included Network Access Protection. If you have a look at your Windows 10 computer (Enterprise SKU off course), you will discover that’s true, the Network Access Control agent no longer exists.

And it’s the same on DirectAccess gateway. Even if we are on Technical Preview Stage, NAP integration with DirectAccess was removed. The Network Access Protection Checkbox was removed.

Why Microsoft removed Network Access Protection?

• It was an old approach

Do you have an idea when NAP was introduced? With Windows Vista and Windows XP SP3. So more than a decade. During this decade many things changed. Something called Cloud emerged.

• It was designed to protect LAN

Network Access Protection was designed du protect corporate networks from rogue computers and unsecured computers. At cloud era we need compliance enforcement anywhere.

• Compliance definition changed

With NAP, compliance expression was limited to five criteria configured to true of false. Developing complex compliances policy was not easy. Even if we were able to extend with Desired Configuration Manager from SCCM, we were limited to Windows Devices

• It was limited to Windows devices

At Vista time, company had very limited choices for devices. Vista introduced the first generation of tablets. Today we are at the BYOD era. Company must be able to manage any device, from Microsoft to IOS and even Android. Yes some partners were able to manage MACOS & Linux, but it’s not built-in.

• It was complex to setup

That was the pain point. NAP was a combination of multiples technologies. If perfectly assembled, it was working like a charm.

How can we manage compliance with Windows 10 devices?

• At the cloud era, response is simple : Windows Intune. We cannot rely on MDM capabilities provided by Office 365 because it does not include Windows devices
• With Windows Intune we have the Extensible Windows PC Devices Configuration Settings that allow to perform WMI check and even registry key checks. We were not able to achieve this with Network Access Protection without DCM.
• We can use App Compliance policies to restrict access to application (was very difficult to achieve with Network Access Protection)
• We can use Selective Wipe to managed stolen DirectAccess enabled devices

Yes Windows Intune is not built-in Windows 10 Operating system generation, but things changed so much since introduction of Windows Vista.

RIP Network Access Protection, miss you.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

La liste des rôles a été longue, il n’en reste plus qu’un. Ça veut pas dire pour autant que c’est déjà la fin de la séance de torture, bien au contraire. Allons y. Last but not least, le rôle Publisher. Tout comme pour le rôle Front-end, il est exposé sur Internet, à ce titre, il méritait une zone réseau dédiée sur ma maquette. La bonne pratique est bien entendu de ne pas exposer ce rôle directement sur Internet mais d’utiliser des solutions de type reverse-Proxy pour l’exposer.

Pour rappel, c’est grâce à ce rôle que nos futurs locataires vont pouvoir venir déposer le futur contenu de leurs sites web. D’un point de vue sécurité, le contenu de tous les sites Web de nos locataires ne sont pas directement exposés sur Internet. Avant de rentrer dans la configuration du rôle, quelques subtilités. Mes instances du rôle Web-Publisher seront accessible depuis Internet via le nom webpublisher.windowsazurepack.fr mais aussi via les alias (CNAME) suivants :

• Publish.Windowsazurepack.fr  (avant UR7)
• Ftp.Windowsazurepack.Fr
• *.scm.WindowsAzurePack.Fr (depuis UR7)

Note : Depuis L’UR7, L’URL de publication de WebDeploy a été modifiée poursite.scm.domain.com.  J’ai donc ajouté l’URL supplémentaire mais pas supprimé l’ancienne.

Donc au final, mes instances du rôle Web-Publisher seront accessibles sous trois noms :

• Webpublisher.Windowsazurepack.fr
• Publish.windowsazurepack.fr
• ftp.windowsazurepack.fr

C’est nécessaire pour supporter les multiples protocoles d’accès. Vu que ce rôle est visible depuis Internet, il est logique qu’on sécurise les communications. Nous avons donc besoin d’un certificat qui réponde au nom Webpublisher.Windowsazurepack.fr mais aussi aux deux autres noms. Le certificat a été délivré par une autorité de certification publique. Pour vérification, l’attribut DNSNameList contient bien les noms indiqués :

Get-ChildItem Cert:\localMachine\My | Where {$_.Subjectname -eq « cn=webpublisher.windowsazurepack.fr »} | Select Subject, DNSNameList

Note : Attention à bien avoir demandé un certificat pour lequel nous pourrons bien exporter la clé privée. Le certificat devant être mis en place sur toutes les instances du rôle Web-Publisher ainsi que mis à disposition de Windows Azure Pack.

Nous en avons fini avec les prérequis, passons à la configuration de notre serveur. Il y a un peu moins de travail que pour les autres :

• Socle : Windows Server 2012 R2 de préférence raccordé au domaine
• Rôles & Fonctionnalités : Framework Dot.Net 3.5.1 installé (attention, y a un piège)
• UAC : Désactivé
• Compte WAP\FT-WAP-WEB01 membre du groupe local administrators
• Le certificat SAN importé dans le magasin personnel de l’ordinateur
• Quelques règles de pare-feu entrantes :
  • Protocole « Windows Management Instrumentation (WMI-In) »
  • Protocole WINRM (HTTP TCP 5985)
  • Protocole WINRM (HTTPS TCP 5986)
  • Protocole Web Farm Framework Agent (TCP 8173)
  • Protocole FTP
  • Protocole WebDeploy TCP 443/TCP 8172

Comme pour les autres rôles, nous allons réaliser le déploiement depuis la console Windows Azure pack Web Sites et demander le déploiement de notre première instance du rôle Publisher.

Le processus commence par installer l’ensemble des composants nécessaires à son bon fonctionnement du rôle Web-Publisher. Comme pour les rôles précédents, la liste des composants à installer est mise à disposition par le contrôleur ainsi que le contenu.

Note : Le processus d’installation va automatiquement redémarrer le serveur pour finaliser l’installation.

On a achevé la mise en place de tous les rôles de l’infrastructure Web Sites, on peut donc passer à l’intégration avec Windows Azure Pack?

La séance est presque terminée. C’était le dernier rôle. Normalement, tous devrait répondre présent.

Get-WebSitesServer | Select Name, Role, Status, PlateformVersion | Format-Table -AutoSize

On peut facilement s’en assurer avec le Best Practice Analyzer dédié à l’architecture Web Sites. Commencez par installer le Microsoft Baseline Configuration Analyzer 2.0 sur le contrôleur de l’architecture Web Sites ainsi que le package correspondant à l’architecture Web Sites. Dans l’illustration ci-dessous, on constate deux points :

• Je n’ai qu’une seule instance du rôle contrôleur. C’est effectivement critique car sans elle, y a plus de pilote dans l’avion. C’est assez simple d’ajouter une instance secondaire pour ce rôles.
• Je n’ai pas nécessairement de multiples instances pour les autres rôles. j’ai donc des domaines de panne dans mon infrastructure.

Nous en avons fini avec la mise en place de l’infrastructure Web Sites. Il est temps de la connecter à notre infrastructure Windows Azure Pack. Ce sera pour le prochain billet.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Dans les “Resources Providers » de Windows Azure Pack, s’il y en a un qui mérite qu’on y passe du temps, c’est Web Sites. C’est un univers à part entière, un vrai jeu de Lego. En plus, c’est le Resource Provider qui a le plus évolué dans Windows Azure Pack puisque nous en sommes à la version 2.0 Update 6 et qu’il continue d’évoluer en permanence. On trouve déjà bon nombre d’excellents billets décrivant la mise en œuvre de l’architecture Web Sites. Cependant, la mise en œuvre a bien changé avec le passage à la version 2. C’est pour cette raison que j’ai décidé de blogger sur le sujet.

Le grand changement, c’est sa mise en œuvre qui a été simplifiée avec l’introduction de la console d’administration Windows Azure Pack Web Sites. C’est une bonne vieille console MMC. Les principaux changements apportés par cette version de Web Sites sont :

• La désactivation de SSL v3 (sécurité oblige)
• La prise en charge des Web Jobs pour exécuter des tâches sur les Web-Worker (comme son grand frère Microsoft Azure)
• Intégration du production/staging site slots (comme son grand frère Microsoft Azure)
• Prise en compte du module IIS HttpPlatformHandler pour permettre à des applications tel que Java d’écouter directement sur HTTP

Vu que l’architecture est un peu compliquée, on va prendre le temps de la détailler avant de rentrer dans le vif du sujet. Commençons par la « Big-Picture ». Ci-dessous une illustration du Technet que l’on va utiliser pour décoder un peu la bête.

Première remarque, pas une seule trace de Windows Azure Pack. C’est normal. On y viendra plus tard. Pour commencer, Windows Azure Pack Web Sites, c’est pas un simple serveur web IIS posé dans un coin. C’est une architecture complète pour de l’hébergement de sites Web / Web Services hautement disponible, multi-tenant proposant plusieurs classes d’hébergement partagé ou dédié. Pour le locataires les services proposés sont relativement proches de ceux proposés dans Microsoft Azure (je dis bien relativement proche), le tout en offrant accès à tout ce qu’on peut héberger sur IIS. La liste est longue, trop longue. Ce billet est le premier d’une série à part entière sur cette architecture. Maintenant que les présentations sont faites, entrons dans le vif du sujet. On dénombre les rôles suivants :

• Controller Server(s)
• Management Server(s)
• Runtime DB Server(S)
• File Server Server(s)
• Front-End Server(s)
• Web Worker Server(s)
• Publisher Server(s)

Première remarque, ça fait du monde à caser sur ma plateforme. Ça tombe bien, en attendant Microsoft Azure Stack, j’avais rien à décortiquer cet été. Seconde remarque, on ne peut pas co-localiser plusieurs rôles sur un même serveur. Il y a des raisons techniques mais aussi des considérations sécurité dont il faut tenir compte. Conclusion, vous pouvez déjà provisionner six nouveaux serveurs sur votre architecture Windows Azure Pack, le double si on veut gérer les domaines de panne et un peu plus si la scalabilité et la performance sont au programme. Tous ces serveurs seront raccordés au domaine pour des raisons de simplicité de mise en œuvre et d’administration. Cependant, il est tout à fait possible de mettre en œuvre une architecture Websites avec des hôtes en workgroup. C’est juste plus compliqué à administrer.

Note : Si on veut pouvoir proposer le mécanisme d’authentification AD dans une infrastructure Web Sites, il est obligatoire que les instances du rôle Web Worker soient installées sur des serveurs membres du même domaine Active Directory : Enable Windows Authentication for Windows Azure Pack: Web Sites.

Commençons avec le rôle le plus simple et le premier que nous allons installer : Le rôle Controller. Il va lui jouer le rôle de chef d’orchestre de l’infrastructure Web Sites, organiser le déploiement de tous les rôles et assurer la mise à niveau / réparation de tous les rôles déployés. C’est aussi lui qui sera chargé de réaliser le provisioning des sites web pour le compte des locataires. Une seule instance de ce rôle suffit dans un POC. Par contre, en environnement de production, il faudra au moins en avoir deux, sachant qu’un seul est actif à l’instant T.

Le Management Server. C’est lui qui héberge les Web Services qui vont s’interfacer avec Windows Azure Pack (AdminAPI, Monitoring API, Usage API). La recommandation est d’installer ce rôle sur un / plusieurs serveurs dédiés si on veut la haute disponibilité. Ce rôle est l’interface avec Windows Azure Pack et ses API. Ne pensez même pas co-localiser ce rôle sur votre plateforme Windows Azure Pack, le résultat sera désastreux pour ce dernier.

Le Runtime DB , c’est une instance SQL dédiée qui peut être configurée en « Always On » pour assurer la haute disponibilité du rôle. C’est donc cette base de données qui va contenir toutes les informations à l’architecture Websites ainsi qu’aux sites web hébergés pour les locataires. Dans le contexte de ma maquette, j’ai hébergé cette base de données sur le serveur SQL de mon infrastructure Windows Azure Pack. C’est le seul rôle que l’on puisse mutualiser en fait.

Le rôle File server sert à stocker le contenu des Web Sites qui seront mis en place. Là où cela devient marrant, c’est que ce n’est pas sur ce serveur que les locataires viendront déposer le contenu de leurs futurs sites web. Pour cela on dispose du rôle Publisher.

Le rôle Publisher sera exposé sur Internet et fournira aux locataires plusieurs moyens (FTP, Visual Studio, Web Matrix, … ) pour déposer le contenu qui devra être mis à disposition sur le web Sites du locataire. Lorsque l’architecture Web Sites aura assigné un site IIS à un locataire, le rôle Web-Worker provisionnera le site web avec le package disponible sur le rôle File-Server. C’est WebDeploy qui sera utilisé pour cette tâche.

On parle de Web Sites, pourtant jusqu’à maintenant, on n’en voit pas beaucoup la couleur. Entrons dans le vif du sujet avec le Web Worker Role. C’est lui qui va héberger les sites Webs de nos locataires. On distinguera deux types d’instances proposant chacune plusieurs classes de performance :

• Dedicated
• Shared

Il ne nous en reste plus qu’un, le rôle Front-End. Nos instances du Web Worker Role ne sont pas directement exposées sur Internet mais au travers du rôle Front-End. C’est lui qui va être chargé de router les requêtes vers la bonne instance du Web Worker Rôle et donc le bon site web. C’est Application Request Routing qui assure cette fonction.

Voilà pour la théorie. Pour la pratique. J’ai déployé mes nouveaux serveurs dans mon infrastructure Windows Azure Pack tel qu’illustré ci-dessous :

Pour la répartition, c’est segmenté en deux grandes familles :

• Les rôles « infrastructure » de l’architecture Web Sites
  • Les instances du rôle Web-Front exposées sur Internet ou via Reverse Proxy
  • Les instances du rôle Web-Publish exposés sur Internet ou via Reverse Proxy
  • Les instances du rôle File-Server qui elles n’ont absolument pas besoin d’être exposées sur Internet
• Les rôles « Tenant » de l’architecture utilisés par nos futurs locataires
  • Les instances du rôle Web Worker Shared qui n’ont pas besoin d’être exposées sur internet
  • Les instances du rôle Web Worker Dedicated qui n’ont pas besoin d’être exposées sur internet

Normalement, à ce stade, j’ai perdu personne, mais c’est maintenant que cela se complique. L’architecture Web Sites est à la fois complexe et très riche. On ne pourra donc pas tout traiter en un seul billet. Voilà la liste des réjouissances prochaines :

• Architecture Windows Azure Pack WebSites – Etape n°1 : Mise en place des rôles Controller, Management, File Server
• Architecture Windows Azure Pack WebSites – Etape n°2 : Mise en place du rôle Front-End
• Architecture Windows Azure Pack WebSites – Etape n°3 : Mise en place du rôle Web-Worker
• Architecture Windows Azure Pack WebSites – Etape n°4 : Mise en place du rôle Publisher
• Architecture Windows Azure Pack WebSites – Etape n°5 : Intégration avec Windows Azure Pack
• Architecture Windows Azure Pack Web Sites – Etape n°6 : Mise à disposition des Web Sites aux locataires
• Architecture Windows Azure Pack Web Sites – Etape n°7 : Expérience utilisateur des Web Sites
• Architecture Windows Azure Pack Web Sites – Bonus Track

Prêt pour une nouvelle séance de torture? Pour vous mettre dans l’ambiance, un peu de réseau. Les fans de la segmentation réseau à outrance vous pouvoir se faire plaisir ou mal, c’est selon.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Vous pouvez le dire maintenant, le module Powershell MgmtSvcAdmin de Windows Azure Pack vous manquait. Jusqu’à maintenant, on a très peu vu l’intégration entre Windows Azure Pack et l’architecture Web Sites, tout au plus, on sait qu’il y a un nouveau Resource Provider dans la place. Allons explorer ce nouveau Resource Provider. Notre locataire a souscrit à un nouveau plan /abonnement au sens Windows Azure Pack. Pour ceux qui m’ont déjà accompagné dans l’exploration du Resource Provider SQL Server, c’est quelque chose que l’on peut suivre en PowerShell. Pour cela une étape obligatoire : La négociation d’un token. Ça pourrait être simple, mais mon infrastructure Windows Azure Pack utilise ADFS comme fournisseur d’identité pour le portail des administrateurs. En premier lieu, il nous faut un objet PSCredential.

Import-Module MgmtSvcAdmin

$Securepassword = ConvertTo-SecureString -String « ******** » -AsPlainText -Force

$Cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList « Administrator », $Securepassword

Ensuite, il nous faut identifier l’URL des Websites AdminAPI et WindowsAuthSite. Ce sont des informations que l’on va extraire de la base de données de Windows Azure Pack à l’aide de la commande Powershell Get-MgmtSvcFqdn.

$AdminAPIInfos = Get-MgmtSvcFqdn -Namespace adminapi -Server SQL.WindowsAzurePack.lan

$AdminUri =  » https://$($AdminAPIInfos.FullyQualifiedDomainName):$($AdminAPIInfos.Port) »

$WindowsAuthSiteInfos = Get-MgmtSvcFqdn -Namespace WindowsAuthSite -Server SQL.WindowsAzurePack.lan

$WindowsAuthSiteUri =  » https://$($WindowsAuthSiteInfos.FullyQualifiedDomainName):$($WindowsAuthSiteInfos.Port)« 

Enfin, y a plus qu’à demander un token à l’aide de la commande Get-MgmtSvcToken.

$token = Get-MgmtSvcToken -Type Windows -AuthenticationSite $WindowsAuthSiteUri -ClientRealm « http://azureservices/AdminSite » -User $cred

$token

Au final, ça donne ça.

Jusque-là, c’est du réchauffé, pas de quoi transpirer. Rentrons dans le vif du sujet avec l’extraction de la liste des plans / abonnement et identifier celui qui nous intéresse avec la commande Get-MgmtsvcPlan. C’est le Plan « Web Sites Cloud » qui nous intéresse.

$Plans = Get-MgmtSvcPlan -AdminUri $AdminURI -Token $token

$Plans | Select DisplayName, State, ServiceQuotas

$WebSitePlan = Get-MgmtSvcPlan -AdminUri $AdminURI -Token $token -DisplayName « Web Sites Cloud »

$WebSitePlan

On a retrouvé le plan, voyons voir les souscriptions pour ce plan / abonnement. La recherche est facilitée car mon locataire est mon premier client, pas besoin de filtrer. C’est une souscription à un plan que nous allons rechercher avec la commande Get-MgmtSvcSubscription.

$Subscription = Get-MgmtSvcSubscription -AdminUri $AdminApiUrl -Token $token | Where {$_.SubscriptionName -eq « Web Sites Cloud »}

$Subscription

$Subscription.Services

Donc, je consomme un abonnement qui me propose trois services, c’est « WebSpaces » qui va nous intéresser. Allons collecter la mesure des usages de notre locataire avec la commande Get-MgmtsvcSubscriptionUsage pour l’identifiant de souscription que nous venons de trouver. On va stocker le résultat dans la variable $WebUsages avant de la mettre en page et tada :

Get-MgmtSvcSubscriptionUsage -AdminUri $AdminApiUri -SubscriptionID $subscription.SubscriptionID -Token $token

$Webusages = Get-MgmtSvcSubscriptionUsage -AdminUri $AdminApiUri -SubscriptionID $subscription.SubscriptionID -Token $token | Where {$_.ServiceDisplayName -eq « Web Site Cloud »}

$Webusages.Usages | Format-Table

Ça vous rappelle rien? C’est la liste des critères que l’on a vu lors de la configuration du plan / Abonnement. Tout de suite, on sait ce que mon locataire consomme :

• Un site en niveau de service Intro
• Deux sites en niveau de service basic
• Aucun contenu stocké pour ces sites web

Passons du côté du obscur dans l’architecture Web Sites. Le module, on le connait déjà : WebSitesDev. La commande, c’est Get-WebSitesSubscription avec en paramètre l’identifiant de la souscription issu de Windows Azure Pack. C’est l’identifiant de la souscription qui permet de faire le lien entre les deux architectures.

La subtilité, c’est de bien comprendre le formatage de l’attribut SelfLink contenant la référence à la souscription. On retrouve ainsi la liste des sites web associés à la souscription de notre utilisateur.

En filtrant un peu plus fin, on arrive même à retrouver toutes les informations relatives à un site web en particulier au sein de la souscription.

Cette fois-ci, c’est réellement la fin de cette séance de torture. Mais ne vous inquiétez pas, il reste encore de quoi faire dans Windows Azure Pack en attendant Windows Azure Stack. A bientôt.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Si seulement c’était la fin de cette série d’article, … Tant qu’on a pas de locataire qui puisse souscrire à notre plan et consommer nos services, c’est comme si on avait rien fait. Voyons donc les possibilités offertes à nos locataires. Déjà, ils faut qu’ils souscrivent à notre nouveau plan / abonnement. Dans le portail des locataires, le nœud « My Account » va permettre à notre locataire de demander à s’abonner à un nouveau plan avec le lien « Add Plan ».

Note : Si on avait associé le Resource Provider de l’architecture Web Sites à un plan / abonnement déjà souscrit par notre locataire, aurait déjà la possibilité de consommer nos nouveaux services immédiatement.

Dans la liste des plans / Abonnement, y a plus qu’à souscrire et patienter quelques secondes.

Si le certificat auto-signe associé au site web de management du rôle Management de l’architecture Web Sites a bien été remplacé par un certificat reconnu par notre infrastructure Windows Azure Pack, alors on devrait obtenir le résultat ci-dessous après quelques secondes. Le certificat-auto-signé mis en place dans l’infrastructure Web Sites n’est pas reconnu par notre infrastructure Windows Azure Pack.

Le premier choix offert à notre locataire, c’est de créer un simple site web vide. Le seul paramètre attendu, c’est un nom unique dans la zone DNS .websites.Windowsazurepack.Fr. Jusque-là, cela ressemble beaucoup à Azure Web Sites.

Quelques secondes plus tard, on peut tenter de se connecter et effectivement, le site web est opérationnel, manque plus que du contenu.

Notre locataire peut aussi demander la création d’un site web Custom. C’est-à-dire que notre site Web va être capable de consommer une ressource de type base de données. Le Site Web disposera donc d’une « connection string » contenant toutes les informations pour accéder à la base de données (SQL /MySQL). Dans l’illustration ci-dessous, notre locataire a retenu d’utiliser la base de données qu’il avait précédemment provisionnée via le Resource Provider Resource Provider SQL Server.

Et enfin, la partie PaaS, à savoir la Web App Gallery. Vu tout ce qui avait été téléchargé lors de l’installation de l’architecture Web Sites, il fallait bien que cela serve. La Web App Gallery propose pas mal de choix.

Selon le template qu’on va sélectionner, le locataire devra fournir plus ou moins d’informations.

Le portail dédié au locataire permet bien entendu de gérer les Web Sites mis en place. Prenons le cas du dernier créé.

L’onglet « Dashboard » nous fait rentrer dans le détail. La première chose dont le locataire a besoin, c’est de récupérer le Publish Profile. Sur le même principe que le service PaaS Web Sites de Microsoft Azure, c’est un fichier contenant les credentials pour accéder à notre Web sites. A noter que si on utilise l’option « Setup Deployment Credentials », il va de soi qu’il faudra actualiser la configuration de son outil de publication. Selon les caractéristiques de l’abonnement souscrit par le locataire, le site web consomme plus ou moins des différentes ressources mesurées. C’est à ce niveau qu’on peut gérer la notion de « Custom Domain », pour faire comme le grand frère Microsoft Azure, à savoir référencer un nom de domaine public.

Dans l’onglet « Monitor », l’infrastructure Web Sites collecte les compteurs de performance et les mets à disposition de Windows Azure Pack.

Note : Je fais l’impasse sur la notion de Web Jobs. L’idée générale est de permettre d’exécuter des exécutables ou des scripts directement depuis le site web. C’est une fonctionnalité apportée par la version 2.0 Update Rollup 6 de l’architecture Web Sites.

Dans l’onglet « configure », on a beaucoup de choses à dire. Si on héberge des applications Web, on a donc des Framework disponibles (ASP, PHP, …). A nous de choisir notre version. Si l’architecture Web Sites le supporte, le locataire peut activer l’authentification intégrée Windows au niveau de son site web IIS (implique des Web-Worker rôle raccordés à un domaine). Après, la liste des options disponibles est longue comme le bras :

• Activation de la prise en charge des Custom Application Pool Identity
• Choix de l’architecture de la plateforme (X86/X64)
• Configuration du certificat utilisé pour le SSL (SNI)
• Configuration du nom de domaine custom associé au site web
• Prise en charge de la journalisation IIS
• Journalisation des accès avec le module Failed Request Tracing
• Configuration des documents par défaut
• Gestion des virtual directories.

Note : Certaines fonctionnalités ne sont pas disponible car pas autorisée dans le niveau de service ou tout simplement pas autorisées au niveau de l’abonnement souscrit par le locataire.

Dans l’onglet « Scale » on retrouve la notion de niveaux de services que nous avons configurés dans le billet Architecture Windows Azure Pack Web Sites – Etape n°6 : Mise à disposition des Web Sites aux locataires. Si on ne précise rien, notre site web est créé avec le niveau de service le plus bas. Comme avec son grand frère Microsoft Azure, on peut changer le niveau de service à la volée ainsi que le nombre d’instances. La multiplication des instances permet de gérer la montée en charge de notre site web mais aussi faire face à l’indisponibilité d’une instance. D’un point de vue technique, l’architecture Web Sites déploie le même package Web Deploy sur plusieurs instances du rôle Web-Worker et configure le module Application Request Routing présent sur le rôle Front-End de l’architecture pour router le trafic vers les instances.

Note : contrairement à Microsoft Azure, il n’y a pas encore de fonctionnalité auto-scale dans l’architecture Web Sites.

Overdose d’interface graphique? Il vous faut un fix? Pas de problème, on va repasser Dev-Ops et redescendre sous la moquette. Allons voir ce qu’on peut faire notre locataire en Powershell. Il a déjà tout ce qu’il faut puisque c’est le module Azure que nous allons utiliser. Plus précisément, les commandes contenant la chaine de caractères ‘*WaPackWebSite*’.

Import-Module Azure

Get-Command ‘*WaPackWebsite*’

Notre locataire disposant déjà d’un abonnement opérationnel, une simple exécution de la commande Get-WaPackWebSite permet de connaitre la liste des Web sites qu’il a provisionné ainsi que leur état.

Maintenant, un peu plus tricky avec la création d’un Web Sites. Tout ce dont on a besoin, c’est le Datacenter de destination. Comme pour son grand frère, on peut choisir le Datacenter de déploiement. Dans Windows Azure Pack aussi. C’est juste que ma plateforme n’est pas assez grande pour jouer à cela. Une simple exécution de la commande Get-WapackWebSiteLocation qui me retourne le nom du Datacenter par défaut. Après, c’est juste un petit New-WapackWebSite pour créer un nouveau site web.

Je vous laisse explorer le reste. Ça a pris pas mal de temps mais on a vu les grandes fonctionnalités de l’architecture Web Sites. Pourtant, il reste plein de choses à voir (support des Custom Domain, Prise en charge SSL avec SNI, support d’IPv6 , …). Pourtant, il reste un gout d’inachevé. Vous trouvez aussi que la séance de torture manque cruellement de Windows Azure Pack qui brule et de PowerShell qui pique? Pas de problème, y a un billet Bonus Track rien que pour vous, garanti sans interface graphique qui arrive bientôt.

Alors reviendrez-vous dans la salle de torture?

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)