Articles Tagués ‘Windows Server 2012’

Bonjour tout le monde,

Aujourd’hui, j’aimerais partager avec vous une astuce concernant Windows PowerShell.

Lors d’une intervention, la question suivante m’a été posée :

Comment cacher la console Windows PowerShell lors de l’exécution d’un script ?

La réponse est la suivante:

PowerShell.exe -WindowStyle Hidden -File D:\MonScriptPS.ps1

Lancez donc Windows PowerShell (en tant qu’Admin) et saisissez la commande ci-dessus en remplaçant D:\MonScriptPS.ps1 par le chemin de votre Script PowerShell.

Si toutefois vous n’avez pas le contrôle sur la manière dont le script est lancé /appelé, vous pouvez rajouter la ligne de code suivante au début de votre script.

Add-Type -Name win -MemberDefinition ‘[DllImport(« user32.dll »)] public static extern bool ShowWindow(int handle, int state);’ -Namespace native [native.win]::ShowWindow(([System.Diagnostics.Process]::GetCurrentProcess() | Get-Process).MainWindowHandle,0)

Save, Run and Enjoy :).

Publicités

S’applique à : RDS 2012 et RDS 2012 R2

Introduction

La solution RDS (Remote Desktop Services) appelée aussi Services Bureau à distance permet la publication et l’accès à trois ressources, à savoir :

Programmes RemoteApp (Applications Transparentes)

Bureaux Windows

Bureaux virtuel (VDI : Virtual Desktop Infrastructure) : nécessite l’hyperviseur « Hyper-V »

Depuis Windows Server 2012 et 2012 R2, Microsoft a introduit un nouveau élément dans l’infrastructure RDS, il s’agit des « Collection ».

Une Collection RDS permet de regrouper les serveurs Hôtes de Session Bureau à distance (RDSH : Remote Desktop Session Host) en fermes séparées

Nous distinguons deux types de Collection RDS :

  • Collection de Sessions
  • Collection de Bureaux Virtuels

Note : la Collection de Bureaux Virtuels n’est pas traitée dans cet article

Les collections de Sessions peuvent héberger 2 types de ressources :

  • Bureau à distance
  • Programme RemoteApp

Note importante : une Collection de Session ne peut héberger les deux types de ressources à la fois, e.i : publier Microsoft Office 2013 et le Bureau Windows d’un Serveur distant sur la même Collection de Session. Il faudrait donc prévoir une Collection par type de ressource à publier, e.i : une Collection pour RemoteApp et une autre pour les Bureau Windows 

En revanche, une solution de contournement existe, celle-ci consiste simplement à modifier la valeur d’une sous-clé au niveau du BDR (Base De Registre).

Notez qu’il s’agit d’une méthode non supportée par l’éditeur et qui ne doit être appliquée sur les environnements de production, mais uniquement sur les environnements de « Test & Dev ».

HowTo : Publier vos RemoteApps & Bureaux Windows sur la même Collection de Session

Une Collection de Session nommée « MesApps&Desktop » est utilisée dans l’exemple suivant.

Note : la Liste des Collections peut être obtenue via la Cmd-let : Get-RDSessionCollection

1

Un Groupe de sécurité AD nommé « RDSUsers » est défini dans les propriétés de cette Collection. Les membres de ce groupe ont actuellement accès aux RemoteApp publiés, voir images suivantes :

2

Comme illustré sur l’image ci-dessus, le type de ressources défini sur la Collection est « Programmes RemoteApp », cela est normal vu que les seules ressources publiées sont des Programmes publiés, dans l’exemple suivant, l’utilisateur « John DEO > login : jdeo » faisant parti du groupe AD « RDSUsers » s’authentifie sur le Portail RDWeb :

3

Pour publier des Bureaux Windows sur la même Collection, deux options s’offrent à vous.

#Méthode1

Vous pouvez simplement publier le client RDC (Remote Desktop Connection) qui correspond à l’outil MSTSC.exe et configurez ensuite un paramètre de ligne de commande dans les propriétés ce celui-ci, voir instructions suivantes pour en savoir plus :

  • Lancez le Gestionnaire de Serveur, cliquez sur « Services Bureau à distance » et sélectionnez votre Collection
  • Sous « PROGRAMMES REMOTEAPP« , cliquez sur « TACHES » et ensuite sur « Publier des programmes RemoteApp« 

4

  • L’assistant de publication de Programmes RemoteApp apparaît, localisez et cochez « Connexion Bureau à distance » et cliquez sur « Suivant » pour continuer

5

  • Enfin cliquez sur « Publier » et ensuite sur « Fermer » pour fermer l’assistant
  • Le Programme RemoteApp « MSTSC » vient d’être publié, faites un clic-droit dessus et sélectionnez « Modifier les propriétés » :

6

  • Sous « Général« , renommez le nom du Programme RemoteApp en spécifiant le nom de votre serveur distant (LABSRV01 dans l’exemple suivant)
  • Sous « Paramètres« , cochez « Toujours utiliser les arguments de ligne de commande suivants » et saisissez : /V:FQDN_Server_Distant (/V:LABSRV01.vLAB.lan dans l’exemple suivant). Enfin cliquez sur « OK » pour valider et fermer l’assistant.

7

Note importante : vous devez publier autant de client « MSTSC’ que de Bureaux Windows à publier. De plus, chaque Client MSTSC publié doit être configuré avec un serveur spécifique via « Propriétés > Paramètres »

  • Enfin, un test final est effectué depuis IE sous une Session Windows ouverte par l’utilisateur John DEO « jdeo » sur un poste Client Windows 8.1 intégré dans le domaine vLAB.lan :

8

  • Comme vous pouvez le constater, l’icône « LABSRV01 » apparaît désormais depuis l’espace RDWeb de l’utilisateur « jdeo », il suffit donc de cliquer dessus pour lancer une Connexion Bureau à distance sur le serveur distant « LABSRV01.vLAB.lan ».

Vous aurez donc publié les deux ressources « RemoteApp & Bureaux Windows » sur une seule et même Collection de Session RDS :).

#Méthode2

La deuxième méthode consiste à modifier la valeur suivante au niveau du Registre :

Nom de la Valeur : ShowInPortal

Chemin : HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\<collection>\RemoteDesktops\<collection>

<collection> : représente le nom de la Collection de Session créée sur votre environnement RDS.

9

Par défaut, les données de la valeur « ShowInPortal » sont définies à 0 (Ne pas afficher sur le Portail RDWeb)

Pour afficher le raccourcis « MSTSC » qui permet de lancer le « Bureau Windows » du Serveur distant sur lequel la Collection est créée, il suffit de changer les données de la valeur « ShowInPortal » à 1 (Afficher sur le Portail RDWeb)

Le résultat est le suivant (Actualisation du Portail RDWeb depuis la Session Windows de l’utilisateur « jdeo » :

10

Bonus 🙂

Un script Bat(ch) est également mis à votre disposition en téléchargement gratuit sur la Gallery TechNet.

Il est basé sur l’outil en ligne de commande « REG.exe » et permet de modifier la valeur « ShowInPortal » et la positionner à 1.

Ce script est téléchargeable ici :

Download-logo

 

S’applique à : RDS Windows Server 2012 et 2012 R2

Introduction

La gestion des profils utilisateurs dans un environnement RDS préoccupe la plus part des IT en charge de la gestion d’une infrastructure RDS.

Si vous n’utilisez pas de solutions tierces pour gérer les données et paramètres des utilisateurs RDS, vous avez plus de chance d’avoir des problèmes liés à ceux-ci.

Les profils « Itinérants » représente la solution classique que nous étions tous amenés à mettre en place pour la persistance des données de profils utilisateurs du réseau, vous avez probablement essayé de l’implémenter pour un environnement RDS et constaté que celle-ci ne répond pas vraiment au besoin du fait que les profils utilisateurs RDS ne fonctionnent pas de la même manière que les profils des utilisateurs standards du domaine.

Le géant américain a enfin compris la problématique et besoins des clients en matière de gestion de profils utilisateurs RDS et a introduit une nouvelle solution qui s’intègre directement avec le rôle RDS 2012 et 2012, et ce pour les deux scénarios de déploiement : Session & VDI.

Il s’agit de « UPD : User Profils Disks », cette fonctionnalité permet de stocker d’une manière centralisée les données des utilisateurs et des applications dans un seul disque virtuel (VHDx) dédié à chaque profil utilisateur.

Quand un utilisateur distant ouvre une Session sur un serveur RDSH ou lance un Programme RemoteApp, son disque de profil associé est attaché à sa session, il est ensuite détaché lors de la fermeture de sa session, avec ce processus, aucune donnée n’est copiée à l’ouverture et fermeture de la session, ce qui permet d’éviter les erreurs de récupération et synchronisation connues avec les Profils Itinérants.

Prérequis

L’activation des UPDs nécessite les deux éléments suivants :

  • Collection RDS (de Sessions ou de Bureaux Virtuels)
  • Un Partage par Collection (de Sessions ou de Bureaux Virtuels)

En effet, la fonctionnalité UPD peut être activée et configurée au niveau d’une Collection RDS, le stockage des données de profils utilisateurs RDS nécessite un espace de stockage (Partage Réseau, Espace de stockage partagé …)

HowTo : Activer la fonctionnalité UPD dans un environnement RDS 2012 /2012 R2

Suivez les instructions suivantes pour activer et configurer la persistance des données de profils RDS via UPD.

Note : dans l’exemple suivant, la fonctionnalité UPD sera activée au niveau d’une Collection de Session appelée « MesApps », de plus les VHDx associés aux profils utilisateurs RDS seront stockés sur un Partage hébergé sur un DC nommé « LABDC1 » :

  • Un dossier partagé doit être créé avec les informations suivantes :
    • Nom du dossier  : UPD_Utilisateurs
    • Nom du Partage  : UPD_Utilisateurs
    • Permissions Partage : Tout le monde | Lecture (permission par défaut)

UPD_1

  • Le Gestionnaire de Serveur doit être lancé depuis un serveur regroupant les 3 services de rôles RDSH – RDCB – RDWA (Remote Desktop « Session Host – Connection Broker – Web Access »)
  • La Collection « MesApps» est sélectionnée dans notre exemple et ses Propriétés sont éditées depuis le Menu « TÂCHES »
  • Cliquez ensuite sur « Disques de profil utilisateur» et cochez la case « Activer les disques de profil utilisateur », spécifiez ensuite le chemin UNC du dossier partagé créé précédemment, \\LABDC1\UPD_Utilisateurs dans notre exemple. Comme illustré dans l’image ci-après, nous allons limiter la taille des disques (VHDx) de profil utilisateur à 5Go par profil :

UPD_2

Note : Si vous rajoutez des serveurs RDSH supplémentaires dans le déploiement, l’assistant configure automatiquement leurs droits d’accès (Partage & permissions NTFS) au niveau du partage spécifié sur les UPDs, aucune action de votre part n’est donc requise.

  • Cliquez sur « Appliquer » et ensuite « OK ». L’assistant prend en charge les informations de configuration spécifiées et apporte les changements suivants :
    • Crée un disque virtuel « modèle» sur le partage spécifié : UVHD-template.vhdx
    • Positionne le droit « Control total» pour l’ensemble des serveurs RDSH de la Collection sur le partage spécifié et ce au niveau des Permission de partage et NTFS (Sécurité). Dans l’exemple suivant, la Collection de Session « MesApps » regroupe deux serveurs Hôtes de Session (LABRDSH1 & LABRDSH2) :

UPD_3

UPD_4

  • Ouvrez une Session Bureau à distance ou lancez un Programme RemoteApp hébergé sur la Collection « MesApps» et constatez l’apparition de votre disque de profil sur le partage \\LABDC1\UPD_Utilisateurs. le nom du disque généré porte le nom « UVHD » suivi de – et un numéro alphanumérique qui correspond au SID (Security IDentifier) de votre compte utilisateur Active Directory :

UPD_5

  • Notez que les disques virtuels de profil utilisateurs peuvent être montés sur l’Exploration Windows, cela peut vous être utile si vous souhaitez déposer ou récupérer des données directement sur le profil RDS d’un utilisateur distant.

UPD_6

Depuis Windows Server 2012 et 2012 R2, Microsoft a simplifié la gestion et l’administration de la solution RDS (Remote Desktop Services) en introduisant une seule console de gestion intégrée désormais dans le Gestionnaire de Serveur.

En revanche, si vous gérez une infrastructure RDS 2012 ou 2012 R2 assez important (plusieurs serveurs Brokers, Web Accès, Hôte de Session …), votre déploiement RDS peut rapidement devenir complexe si un problème parvient sur un ou plusieurs composants lié à celui-ci (réseau, stockage, Active Directory, Base de données SQL, DNS …).

Diagnostiquer plusieurs centaines voire des milliers de journaux d’événements remontés par les différents serveurs du déploiement pour trouver la « Rootcause » exacte du problème nécessite des fois plusieurs heures voire plusieurs jours de travail.

RDS étant un service généralement critique pour l’entreprise, un « Downtime » de quelques minutes ou quelques heures peut bloquer tout un service /département ou toute l’entreprise dans son intégralité.

Le géant américain a pensé à nous, les « RDS Guys 😀 » et nous propose désormais un outil de diagnostic gratuit dédié pour le rôle RDS, il s’agit de l’outil « RDS Diagnostic Tool« , disponible en téléchargement ici.

Notez que l’outil « RDS Diagnostic Tool » supporte uniquement sur Windows Server 2012 et 2012 R2.

Important : une fois téléchargé, l’outil RDS Diagnostic Tool doit être exécuté sur le Service Broker des Services Bureau à distance (RDCB : Remote Desktop Connection Broker).

Une fois installé et exécuté, l’outil ressemble à l’image ci-après :

RDSDiagTool

Comme illustré dans l’image ci-après, l’outil est organisé en 6 Onglets :

RDSDiagToolOnglets

-L’onglet « Collections » liste et détaille les informations sur l’ensemble des Collections de Sessions et/ou Bureaux Virtuels du déploiement RDS, il détaille également les informations sur les ressources publiées (Programmes RemoteApp – Bureaux Windows publiés – Postes de travail virtuels).

-L’onglet « Virtual Machines » regroupe toutes les informations liées aux ordinateurs virtuels (VMs) hébergés sur le(s) hôte(s) Hyper-V faisant office de Serveur(s) Hôte(s) de Virtualisation des Services Bureau à distance (RDVH : Remote Desktop Virtualization Host).

-L’onglet  « Provisioning » affiche toutes les informations liés aux travaux de Provisioning et leur statut : en cours d’exécution – réussi, echoué. Ces Jobs sont exécutés par le Service Broker

Après exécution de l’outil RDS Diagnostic Tool, celui-ci liste tous les travaux de Provisioning, si un Job est sélectionné, l’outil vous affiche un rapport détaillé sur le volet droit incluant l’utilisation et toutes les activités de connexions de ce travail de Provisioning, enfin notez que les événements sont collectés à partir de tous les serveurs Hôtes de Virtualisation ainsi que les serveurs Brokers.

-L’onglet « Connections » vous permet d’afficher toutes les connexions établies « Par un Utilisateur spécifique » OU « Sur un Serveur d’Hôte de Session spécifique ».

Il affiche également toutes les informations dont vous avez besoin pour « Tracker » les connexions Bureau à distance : Date/Heure de connexions – Statut de connexion (réussie, échouée, annulée,) – Type de Connexion – Nom de la Collection hébergeant la ressource à laquelle l’utilisateur s’est connecté – Type de ressource – GUID de Connexion ..

Important : l’outil RDS Diagnostic Tool permet d’afficher les 300 dernières connexions uniquement.

Dans l’exemple suivant, nous allons lister les connexions établies sur le serveur Hôte de Session nommé « LABRDSH1 », et ce en saisissant ce nom NetBios dans la zone de texte et en cliquant sur le bouton « Start » :

RDSDiagTool2

-L’onglet « Database » vous permet de visualiser le contenu de la base de données utilisée par les Serveurs Brokers en mode HA (Haute Disponibilité), il suffit de cliquer sur le bouton « Display » pour collecter et lister toutes les informations de la base de données dans la zone de texte, voir image ci-après :

RDSDiagTool1

-L’onglet « Events & Traces » regroupe toutes les informations de traçabilité et journaux d’événements liés aux services de rôles RDS.

Les informations affichées sont collectées et remontées par le(s) Serveur(s) Broker(s) et l’outil « Observateur d’événements »

Cliquez « Start » pour commencer la collecte d’informations :

RDSDiagTool3

Comme illustré dans l’image ci-dessus, après exécution, l’outil ouvre automatiquement le dossier %SYSTEMDRIVE%\Programmes\Microsoft IT\Microsoft RDV Diagnostic Tool (Beta), ce dernier contient un fichier log (txt) contenant toutes les informations collectées, il qui peut être exploité et intégré dans un fichier .CSV ou un tableur excel pour une présentation à votre client ou direction.

======================================================================

Extrait de l’eBook « RDS Windows Server 2012 R2 – Guide du Consultant« , disponible chez :

YouScribe.com : format « eBook »

Amazon.fr         : format « Papier :: Broché »

Hi All,

Une nouvelle version de l’outil magique RDCMan (Remote Desktop Connection Manager) est disponible, il s’agit de la version 2.7 supportant désormais les OS (Clients & Server) suivants :

OS Client : Windows 7 – Windows 8 – Windows 8.1 – Windows 10 Technical Preview

OS Server : Windows Server 2008 – Windows Server 2008 R2 – Windows Server 2012 – Windows Server 2012 R2 – Windows Server Technical Preview

(suite…)

Durant l’installation de Windows Server 2008 et 2008 R2, vous pouvez choisir entre une installation Minimale « Mode Core » et une installation Complète « Mode GUI » (voir image ci-après), mais aucune conversion ni basculement entre les deux modes n’est possible; le passage du mode Core au mode GUI nécessite une réinstallation complète « from scratch » de Windows Server 2008 ou 2008 R2.

IMG27

Ce n’est plus le cas sous Windows Server 2012 ou 2012 R2, en effet parmi les nouveautés les plus intéressantes de cette dernière version « majeure »  de Windows Server est la possibilité de basculer entre les deux modes « Core <=> GUI ».

C’est vrai que durant l’installation de Windows Server 2012 ou 2012 R2 (selon les sources d’installation), vous êtes invité à choisir entre les mêmes 2 options d’installation « Core : Installation minimale  » ou « GUI : Serveur avec une interface graphique utilisateur », comme montré ci-après

IMG26

En revanche, une fois déployé, Windows Server 2012 ou 2012 R2 intègre 2 fonctionnalités optionnelles (voir tableau ci-après) que vous pouvez installer ou désinstaller pour basculer entre le mode « Core » et le mode « GUI ».

Nom de la fonctionnalité Windows

Nom du package Description

Outils et infrastructure de gestion graphique

Server-Gui-Mgmt-Infra

Cette fonctionnalité fournit l’interface minimale de serveur et les outils de gestion de serveur comme le « Gestionnaire de serveur »,  toutes les consoles de gestion Microsoft (MMC), Windows PowerShell ISE, …
Shell graphique du serveur  Server-Gui-Shell  Cette fonctionnalité dépend de la première fonctionnalité et et fournit le reste des interfaces graphiques incluant les fonctionnalités du Panneau de configuration et Windows Explorer.

De plus, un nouveau mode est introduit : MSI pour Minimal Server Interface, ce qui peut être traduit en Français par : Interface de Serveur Minimal. 
Il s’agit d’un mode intermédiaire entre le mode « Core » et le mode « GUI », en effet le mode MSI est tout simplement une installation « Core » avec une couche graphique incluant :

Le gestionnaire de serveur
Toutes les consoles MMC
L’environnement d’écriture de script intégré (PowerShell ISE)
Certains outils du Panneau de configuration

Généralement pour basculer du mode « Core » au mode « MSI’ il suffit d’ajouter le package « Server-GUI-Mgmt-Infra » ce qui correspond à la fonctionnalité : Outils et infrastructure de gestion graphique (mode MSI)

Pour basculer vers le mode « GUI » depuis un mode « Core », un package est à ajouter en plus de Server-GUI-Mgmt-Infra, il s’agit Server-GUI-Shell qui correspond à la fonctionnalité : Shell graphique de serveur (mode GUI)

Notez qu’il y’a une dépendance entre les deux packages.

En gros, pour basculer entre les trois modes, il suffit d’ajouter ou supprimer une ou les deux fonctionnalités (en utilisant leurs noms de packages précédé de la cmdlette PowerShell Add-WindowsFeature ou Remove-WindowsFeature).

Pour vous faciliter la vie et simplifier cette procédure de conversion, j’ai développé un script PowerShell, téléchargeable gratuitement ici

Il suffit de l’exécuter et choisir un numero d’option pour basculer d’un mode à un autre (comme SConfig.exe)

Notez que la stratégie d’exécution doit être « Unrestricted » pour éviter tout blocage d’exécution du script.

Voir instructions ci-après pour utiliser correctement ce script :

  1. Clic droit sur le script > Exécuter avec PowerShell

PS

 

  1. Si la stratégie d’exécution est autre que « Unrestricted » (RemoteSigned par exemple), le message d’avertissement suivant s’affiche :

  1. Il suffit de saisir Oui ou O pour confirmer l’exécution du script

  2. Une fois exécuté, le menu suivant s’affiche

  1. Il faut saisir un numéro d’option (selon le mode depuis et vers lequel vous voulez switcher), veillez à bien saisir un numero d’option entre 1 à 4, si vous choisissez un numéro autre que 1,2,3 ou 4, le message d’avertissement suivant s’affiche :

  1. Dans l’exemple suivant, je vais convertir mon installation Windows Server 2012 R2 avec interface graphique utilisateur vers le mode « Core », donc option 4

  1. Windows PowerShell collecte les données nécessaires (vérification disponibilité du package et installation), dès que l’opération est terminée, un redémarrage est requis pour que la conversion soit prise en compte, vous êtes avertis d’ailleurs

  1. Il suffit de saisir Oui ou O pour redémarrer votre serveur

  2. Une phase de configuration des fonctionnalités (Server-GUI-Mgmt-Infra ou Server-GUI-Shell ou les deux) est effectuée avant et après le redémarrage

  1. Après le redémarrage et l’ouverture de session sur le serveur, vous pouvez constater que l’installation complète est convertie à une installation minimale