Lorsque vous souhaitez "publier" des bureaux et/ou des programmes RemoteApp, vous devez le faire via un système de collections.
Comme vous le verrez plus tard, vous avez aussi la possibilité de stocker les données utilisateurs dans des disques de profils utilisateurs pour que vos utilisateurs puissent retrouver leurs documents lors de leurs prochaines connexions.
Etant donné qu'une collection regroupe un ou plusieurs serveurs hôtes de sessions, ceux-ci devront être identiques pour que l'expérience utilisateur soit optimale et pour éviter divers bugs dus à des versions différentes du système d'exploitation ou des programmes RemoteApp publiés via cette collection.
Si vous possédez plusieurs serveurs avec différents systèmes d'exploitation, vous devrez les mettre dans différentes collections.
Ce qui veut aussi dire que les disques de profils utilisateurs devront être gérés PAR collection pour éviter qu'un fichier ne fasse référence à un programme qui n'existe pas sur le serveur cible.
Pour ce tutoriel, nous avons créé un dossier "users_data" sur notre serveur Active Directory.
Faites un clic droit "Propriétés" sur celui-ci, puis allez dans l'onglet "Partage" et cliquez sur "Partager".
Inutile de changer les autorisations sur ce partage, car c'est votre serveur RDS qui les modifiera automatiquement lors de la création de la collection.
Cliquez sur Partager.
Voilà, votre dossier est partagé.
Dans l'onglet "Partage", vous voyez un chemin réseau.
C'est ce chemin que vous devrez indiquer un peu plus tard lorsque vous créerez votre collection de bureaux ou de programmes RemoteApp.
Pour créer votre première collection, vous pouvez allez dans "Services Bureau à distance -> Vue d'ensemble", puis cliquez sur le lien "3. Créer des collections de sessions" situé en dessous de "Déploiement de bureaux basés sur une session".
OU alors, allez dans "Collections", puis cliquez sur "Tâches -> Créer une collection de sessions".
L'assistant "Créer une collection" s'affiche.
Indiquez un nom pour votre collection.
Dans notre cas : Bureau WS 2012
Sélectionnez les serveurs hôtes qui seront utilisés pour cette collection.
Dans notre cas, nous ne possédons qu'un seul serveur.
Ajouter les groupes d'utilisateurs qui pourront accéder à ces bureaux.
Dans ce tutoriel, nous autoriserons tous les utilisateurs du domaine.
Néanmoins, en production, vous devriez créer des groupes spéciaux pour autoriser uniquement les utilisateurs qui peuvent accéder à ces bureaux.
En effet, légalement, vous devrez acheter autant de licences que de personnes autorisées à utiliser ces bureaux et non en fonction du nombre de personnes qui utiliseront réellement ces bureaux.
Etant donné que les utilisateurs risquent de se connecter sur des serveurs différents faisant partie d'une même collection, Microsoft a créé la fonctionnalité : Disques de profils utilisateurs.
Cela permet à vos utilisateurs de retrouver leurs données, même s'ils se connectent de manière transparente sur un des autres serveurs de votre collection.
Un résumé s'affiche.
Cliquez sur Créer.
Patientez pendant la création de la collection.
Une fois la collection créée, cliquez sur Fermer.
Dans la section "Services Bureau à distance" du gestionnaire de serveur, vous trouverez votre nouvelle collection : Bureau WS 2012.
Notez que lorsque vous sélectionnez "Collections", vous voyez toutes les connexions de vos utilisateurs.
Mais si vous sélectionnez une collection spécifique, vous ne verrez que les connexions pour cette collection.
Comme vous pouvez le voir, par défaut, le type de ressources est : Bureau à distance.
Dans la section "Programmes RemoteApp", vous verrez aussi ces messages :
Plain Text
Bureau à distance est publié pour les utilisateurs de la collection. La publication de programmes RemoteApp annule la publication du Bureau à distance.
Nos utilisateurs peuvent donc accéder à distance à une session qui sera ouverte sur notre serveur hôte de sessions sous Windows Server 2012.
Néanmoins, actuellement, si vous tentez d'accéder à l'accès web de votre serveur RDS, vous verrez qu'il y a un problème de certificat.
Cela est simplement dû au fait qu'il s'agit par défaut d'un certificat auto-signé. Il est donc normal qu'il n'émane pas d'une autorité de certification approuvée (de confiance) étant donné que le serveur se l'est automatiquement délivré.
Windows Server 7/6/2019
Windows Server 8/3/2019
Windows Server 22/3/2019
Windows Server 16/6/2019
Contenu épinglé
Contact
® InformatiWeb-Pro.net - InformatiWeb.net 2008-2022 - © Lionel Eppe - Tous droits réservés.
Toute reproduction totale ou partielle de ce site est interdite et constituerait une contrefaçon sanctionnée par les articles L.335-2 et suivants du Code de la propriété intellectuelle.
Pas de commentaire