[PART2] Nouveau mode de déploiement sous RDS 2016 : Personal Session Desktops

Lors de la [PART1], nous avons découvert le nouveau mode de déploiement introduit avec RDS 2016 : Personal Session Desktops

Now let’s setup notre infrastructure RDS (VDI) sur MS Azure :).

Comme illustré dans l’image ci-après, 3 VMs dédiées à mon future infra RDS 2016 ont été créées :

Note : depuis Windows Server 2012 et 2012 R2, le déploiement d’une infrastructure RDS requiert un domaine AD. une infrastructure AD (vLAB.com) est donc déjà en place, celle-ci est hébergée /gérée par l’unique DC nommé « DC01 ».

Les services de rôles RDS vont être répartis de la manière suivante :

• VM « RDCB01 » : fait office de Serveur Broker et Web Access Server (RDWA)
• VM « RDSH01 » : premier serveur Hôte de Session du déploiement
• VM « RDSH02 » : second serveur Hôte de Session du déploiement

Toutes mes VMs hébergées sur Azure tournent sous Windows Server 2016 Technical Preview 5

Tous les serveurs de déploiement RDS doivent être joint au domaine AD, de plus la gestion à distance (via PowerShell Windows) doit être activée sur chacun des serveurs.

HowTo : Setup(er) votre infrastructure RDS (VDI) 2016 TP 5

-Ouvrez une Session sur le serveur RDCB01 avec un compte « Domain Admin » ou équivalent (Session bureau à distance forcement vu que le serveur est dans le Cloud xD)

-Lancez Windows PowerShell en tant qu’Administrateur et saisissez les commandes suivantes :

#Pour importer le module PowerShell RemoteDesktop

Import-Module RemoteDesktop

#Pour déployer RDS sur les deux serveurs listés ci-haut

New-RDSessionDeployment -ConnectionBroker RDCB01.vLAB.com -WebAccessServer RDCB01.vLAB.com -SessionHost RDSH01.vLAB.com

#Pour ajouter le deuxième serveur RDSH « RDSH02 » au déploiement

Add-RDServer -Server RDSH02.vLAB.com -Role « RDS-RD-Server » -ConnectionBroker RDCB01.vLAB.com

#Pour créer une nouvelle Collection RDS nommée « MyVDICollection » et y ajouter les deux serveurs RDSH

Note : le paramètre –PersonalUnmanaged permet de spécifier le mode « Personal Session Desktops », quant au paramètre -GrantAdministrativePrivilege, il permet d’attribuer le droit « Administrateur local » aux utilisateurs Bureau à distance sur leur Serveur Hôte de Session Personnel.

New-RDSessionCollection -CollectionName « MyVDICollection » -ConnectionBroker RDCB01.vLAB.com -SessionHost RDSH01.vLAB.com,RDSH02.vLAB.com –PersonalUnmanaged -GrantAdministrativePrivilege

#Enfin, pour assigner (dédier) des Serveurs Hôtes de Session « Personnels » à vos users, les commandes suivantes sont utilisées. Notez que dans l’exemple suivant, le serveur RDSH01 sera assigné à l’utilisateur ‘dlanoizeley’ (David LANOIZELEY) et le serveur RDSH02 à l’utilisateur ‘hkadiri’ (Hicham KADIRI). Imaginez ça comme une infrastructure VDI « Personnelle » sur Azure :). 

Set-RDPersonalSessionDesktopAssignment -CollectionName « MyVDICollection » -ConnectionBroker RDCB01.vLAB.com -User « hkadiri » -Name RDSH01.vLAB.com
Set-RDPersonalSessionDesktopAssignment -CollectionName « MyVDICollection » -ConnectionBroker RDCB01.vLAB.com -User « dlanoizeley » -Name RDSH02.vLAB.com

What Next ?

Let’s test our VDI infrastructure 🙂

Le test suivant consiste simplement à lancer le client RDC (Remote Desktop Connection) > outil MSTSC.exe depuis ma machine locale (ou depuis n’importe quel terminal d’ailleurs : Smartphone /Tablette .. App ‘Remote Desktop’) et se connecter à mon RDSH Server dédié, disponible via le service cloud RDSH02.cloudapp.net

A bientôt

Keep in touch

Hicham.K

Publicité

[PART1] Nouveau mode de déploiement sous RDS 2016 : Personal Session Desktops

Avec Windows Server 2016 (encore sous Technical Preview 5 au moment où j’ai écrit cet article), un nouveau mode de déploiement RDS verra le jour.

Actuellement avec Windows Server 2012 et 2012 R2, deux modes de déploiement sont disponibles :

Déploiement de Bureaux basé sur une Session : mode basé sur le serveur Hôte de Session (RDSH : Remote Desktop Session Host) où chaque utilisateur distant exécute une Session sur un OS serveur partagé. Il s’agit du modèle traditionnel {Terminal Server}.

Déploiement de Bureaux basé sur une Machine Virtuelle (VM) : modèle basé sur le serveur Hôte de Virtualisation (RDVH : Remote Desktop Virtualization Host) où chaque utilisateur distant exécute un poste de travail virtuel dédié (VM dédiée : VM Personnelle ou dans un Pool de VM) qui héberge un OS Client. Il s’agit ici de l’infrastructure de poste de travail virtuel, connue aussi sous le nom VDI (Virtual Desktop Infrastructure)

Avec la sortie de Windows Server 2016 Technical Preview 2, Microsoft a introduit un nouveau mode de déploiement : Personal Session Desktops ou Server Based Personal Desktop (le nom final n’est pas encore décidé !).

Ce nouveau mode de déploiement RDS combine les deux modes de déploiement disponibles actuellement avec RDS 2012 /2012 R2 (Déploiement basé sur une Session & VM), ce qui signifie qu’avec un déploiement RDS 2016 en mode Personal Session Desktops (ou Server Based Personal Desktop), vous pouvez mettre en place une infrastructure VDI sans utilisation d’OS Client :). ce n’est pas magique ça ?

Le principe est simple, chaque utilisateur distant disposera d’un Serveur Hôte de Session dédié, ce dernier fera office d’un poste de travail virtuel comme dans une infrastructure VDI classique.

Pourquoi dédier un Serveur RDSH pour un utilisateur Bureau à distance ? la réponse est Azure (Offre Cloud de Microsoft pour la partie DaaS {Desktop-as-a–Service})

En effet, quelque soit le type /niveau d’abonnement sur Microsoft Azure, vous ne pouvez actuellement souscrire à une offre VDI dans Microsoft Azure, vu qu’aucun contrôle /gestion de l’Hyperviseur n’est possible, de plus vous ne pouvez installer /attribuer des Licences aux VMs Clients utilisées dans un scénario VDI dans Azure.

Le nouveau mode de déploiement « Personal Session Desktops » permettra donc d’utiliser une solution VDI dans Microsoft Azure via l’attribution des Serveurs Hôtes de Sessions dédiés sous forme de Poste de travail virtuels.

De plus, de nouvelles améliorations ont été apportées à la fonctionnalité « Expérience utilisateur » (Desktop-experience pour les OS en anglais).

Pour en savoir plus sur la fonctionnalité « Expérience utilisateur », consultez cet article.
Cette fonctionnalité vous permet d’avoir la couche graphique de Windows 10 ainsi que les outils de poste de travail tel que l’Outil de capture, la Table des matières, l’outil de Nettoyage de disque ou encore le Lecteur Windows Media sur vos serveurs RDSH hébergés dans le Cloud.

Notez que depuis Windows Server 2016 (TP*), la fonctionnalité « Expérience utilisateur » est installée /fournie par défaut avec l’OS Server.

Utilisée dans un scénario de déploiement « Personal Session Desktops », vous pouvez proposer à vos end users un environnement VDI (Serveur Hôte de Session dédié sous forme de poste de travail avec un look Windows 10) hébergé chez Microsoft.

---

La deuxième partie de cet article détaille la « Mise en place d’une infrastructure VDI RDS 2016 sur Microsoft Azure ».

HowTo : Afficher le nom d’utilisateur sur le Portail RD Web Access [RDS 2012 et RDS 2012 R2]

Lors de plusieurs interventions chez différents clients, le besoin suivant m’a été exprimé :

Peut-on faire apparaître le nom d’utilisateur (AD) sur le portail RD Web Access ?

Tout d’abord, il faut savoir que par défaut, tout utilisateur authentifié sur le Portail RD Web (Remote Desktop Web Access) ne voit pas apparaître son nom d’utilisateur sur celui-ci, voir l’image ci-après :

Le coin supérieur droit de cette page (fichier Default.aspx) regroupe uniquement les deux boutons : Aide & Se déconnecter

Nous allons voir à travers cet article comment personnaliser le Portail RDWeb pour afficher le nom d’utilisateur connecté à côté du bouton « Se déconnecter ».

Par défaut, l’ensemble des fichiers correspondant au Portail RDWA sont stockés dans C:\windows\web\RDWeb\Pages

Donc commencez par faire une copie de ce dossier avant de suivre les instructions détaillées ci-après.

Le but étant d’avoir un moyen de rétablir le portail RDWA en cas de mauvaise manipulation /erreur de configuration.

Comment ça marche ?

1. Editez le fichier C:\windows\web\RDWeb\Pages\Web.config
2. Localisez la ligne 52 : <system.web>
3. Copiez /collez le code suivant (en dessous de la ligne 52) :

   <compilation defaultLanguage="c#" debug="true">
     <assemblies>
       <add assembly="System.DirectoryServices, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
     </assemblies>
   </compilation>

4. Le résultat doit ressembler à celui illustré dans l’image suivante:
5. Ce code a pour but d’indiquer au serveur RDWA que nous avons besoin d’insérer un code spécifique, et plus précisément un code (.NET) depuis la DLL « System.DirectoryServices.dll »
6. Dès que le code est inséré, enregistrez et fermez le fichier Web.config
7. Maintenant, éditez le fichier C:\windows\web\RDWeb\Pages\fr-FR\Default.aspx
8. Localisez la ligne 225 : </script>
9. Copiez /collez le code suivant (avant la ligne 225) :

   private static string GetDisplayName(string strUserName)
   {
     string strLDAPPath = "LDAP://dc=vLAB,dc=Lan";
     string strFilter = string.Empty;
     
     if(strUserName.Contains("\\")){strUserName = strUserName.Substring(1 + strUserName.IndexOf("\\"));}
     strFilter = "(SAMAccountName=" + strUserName + ")";
     if(strUserName.Contains("@")){strFilter = "(UserPrincipalName=" + strUserName + ")";}
     
     System.DirectoryServices.DirectoryEntry de = new System.DirectoryServices.DirectoryEntry(strLDAPPath);
     System.DirectoryServices.DirectorySearcher ds = new System.DirectoryServices.DirectorySearcher(de);
     ds.Filter = strFilter;
     ds.PropertiesToLoad.Add("DisplayName"); 
     System.DirectoryServices.SearchResultCollection results = ds.FindAll();
     
     return (results != null && results.Count > 0) ? Uri.EscapeDataString(results[0].Properties["DisplayName"][0].ToString()) : string.Empty;
   }

10. Remplacer la valeur de LDAP://dc=vLAB,dc=Lan par le nom DNS de votre domaine AD
11. Le résultat doit ressembler à celui illustré dans l’image suivante : 
12. Le code inséré occupe les lignes 224 > 240 sur mon fichier Default.aspx
13. Localisez ensuite la ligne 248 : baseurl= »<%=SecurityElement.Escape(baseUrl.AbsoluteUri)%> »
14. Insérez la ligne de code ci-après après la ligne 248 ‘baseurl…. » :

    userdisplayname="<%=GetDisplayName(strDomainUserName)%>"

15. Le résultat doit ressembler à celui illustré dans l’image suivante : 
16. Les étapes ci-dessus permettent d’afficher le nom d’utilisateur sur la page Default.aspx uniquement. Pour faire la même chose sur les autres pages du Portail RDWA, le fichier Site.xsl doit également être modifié, pour ce faire éditez ce dernier qui se trouve dans C:\windows\web\RDWeb\Pages\Site.xsl 
17. Localisez la ligne 15 (ligne vide) et insérez le code suivant juste en dessous :

    <xsl:variable name="userdisplayname" select="/RDWAPage/@userdisplayname"/>

18. Enfin, localisez la ligne 322 (ou 323 selon la configuration du déploiement RDS 2012 /2012R2) : <xsl:value-of select= »$strings[@id = ‘SignOut’] »/>
19. Copiez /collez le code suivant juste après cette ligne :

    <xsl:if test="$userdisplayname">(
    document.write(decodeURIComponent(''));)</xsl:if>

20. Le résultat final doit ressembler à celui illustré dans l’image suivante :

Enregistrez et fermez le fichier Site.xsl et connectez-vous sur le Portail RDWA.

Enfin, constatez l’apparition du nom complet de l’utilisateur authentifié (Hicham KADIRI dans l’exemple suivant) :

J’espère que cette technique pourra vous être utile.

C’est une technique pour les [RDS Advanced users only].

Toute mauvaise manip sur les fichiers Web.config /Default.aspx /Site.xsl peut entraîner un downtime du portail RDWA

Vérifiez que vous avez bien copié /sauvegardé le dossier C:\Windows\Web\RDWeb\Pages avant d’appliquer cette procédure sur vos serveurs RDWA de prod :).

Goodluck et à bientôt.

[TOOLBOX] Policy Analyzer

Policy Analyzer est un outil magique qui vous permet de scanner /analyser et comparer l’ensemble des GPOs (Group Policies Object) locales et du domaine.
Il s’agit d’un simple exécutable, donc aucune installation n’est requise :).

Si vous êtes amenés à faire du Diagnostic /Support N3 sur AD /Windows Server /GPO, Policy Analyzer peut vous être très utile pour détecter toute mauvaise configuration d’un ou plusieurs paramètres de Stratégie de groupe ou simplement pour vous remonter des informations concernant un ou plusieurs paramétrs dupliqués (même paramètre configuré sur plusieurs GPOs avec différentes valeurs !).

Cet utilitaire vous permet également de comparer les valeurs des différents paramètres des GPOs du domaine avec celles définies au niveau des GPOs locales ou encore les valeurs de la BDR (Base De Registre), vous pouvez ainsi détecter si des incohérences /duplication ont lieu.

Le résultat d’analyse /comparaison peut ensuite être exporté vers un fichier Excel exploitable (à présenter à votre N+1 /Client).

Ci-après un exemple de rapport généré depuis Policy Analyzer :

Téléchargement

L’outil est disponible en téléchargement gratuit ici.