Bonjour à tous !

Aujourd'hui voici un court billet pour les personnes travaillant sous Windows Server Core.

Contexte :

Vous travaillez sur Windows Server Core, donc sans aucune GUI installée.

Vous êtes connecté au serveur à travers une connexion RDP.

Pour une raison X ou Y, au cours de votre session de travail, vous fermez malencontreusement votre invite de commande ou console PowerShell et vous n'avez plus aucun moyen de l'ouvrir !

Problématique :

Habituellement, le seul moyen de relancer une invite de commande ou une console Powershell est de passer par le Gestionnaire des tâches, qui peut s'ouvrir à l'aide la commande Ctrl+Alt+Suppr.

Si vous accéder au serveur en utilisant une connection à distance avec un rebond, la commande Ctrl+Alt+Suppr n'est pas prise en compte au sein du dernier bureau à distance ouvert, donc vous ne pouvez pas ouvrir le Gestionnaire des tâches via le raccourci habituel.

Solution :

Il existe cepandant un raccourci afin d'ouvrir le Gestionnaire des tâches, qui est Ctrl+Shift+Escape

Ensuite, il suffit de cliquer sur le menu File puis sur Run New Task afin de relancer au choix l'exécutable correspondant à la console Invite de commande ou à la console Powershell.

Bonus :

Voici la liste des consoles toujours accéssibles sous Windows Server Core et celles qui ne le sont plus :

 A bientôt,

Lancer un script Powershell via le planificateur de tâches ne pose aucun problème, en revanche si ce dernier souhaite utiliser Excel (par l'intermédiaire de la commande "new-object -comobject excel.application") on peut rencontrer un problème.

Je dis "on peut" car cela fonctionne si l'on a pas coché la case "Run Whether user is logged on or not", en revanche si cette dernière est cochée, Excel ne sera pas en mesure d'enregistrer le fichier.

Pourquoi ?

Par défaut l'application Excel s'exécute avec le compte "Utilisateur exécutant (The Launching User)", mais si j'utilise une tâche planifiée qui ne nécessite pas que je sois connecté Excel ne parvient pas a déterminer qui fait appel à lui.

Que Faire ?

Simplement en déclarant qui  exécute l'application Excel via la MMC -> Services des composants.

Je vous renvoie au point 2 (Gestion de l'Excel distant) de mon précédent article : [Powershell] Ecrire dans un Excel distant.

Le rançongiciel Petya est apparu fin juin en Ukraine pour ensuite se propager rapidement partout dans le monde.

Il s’agirait d’une variante de WannaCrypt qui était apparu en début d’année.

Se protéger

Si vous n’avez pas encore été infectée, vous devez vérifier que vos postes disposent des dernières mises à jour et de les installer si ce n’est pas le cas.

Pour agir rapidement vous pouvez installer uniquement la KB qui correspond à votre système d’exploitation en regardant la liste sur cette article https://blog.piservices.fr/post/2017/05/30/securite-kb-pour-wanna-cry et de se rendre sur le catalogue de Microsoft pour le télécharger http://www.catalog.update.microsoft.com/home.aspx.

Vérifier avec WSUS

Si vous disposez d’un serveur WSUS vous pouvez vérifier depuis la console si votre parc informatique est protégé. Pour se faire il faut se rendre dans l’onglet Updates -> Security Updates -> Search

Dans la fenêtre qui apparaît vous devez rentrer la KB souhaitez par exemple : 4012212

Lorsque vous regardé le report de la KB (en double cliquant dessus) vous verrez :

• La description de la KB
• Les groupes qui approuvent cette KB
• L’état de déploiement par rapport à vos machines

Microsoft a également sorti un script qui permet de savoir si votre machine dispose du patch ou non. Le seul prérequis est de disposer au minimum de Windows PowerShell 2.0. https://support.microsoft.com/fr-be/help/4023262/how-to-verify-that-ms17-010-is-installed

Voici le script :

[reflection.assembly]::LoadWithPartialName("System.Version")
$os = Get-WmiObject -class Win32_OperatingSystem
$osName = $os.Caption
$s = "%systemroot%\system32\drivers\srv.sys"
$v = [System.Environment]::ExpandEnvironmentVariables($s)
If (Test-Path "$v")     {     Try         {         $versionInfo = (Get-Item $v).VersionInfo         $versionString = "$($versionInfo.FileMajorPart).$($versionInfo.FileMinorPart).$($versionInfo.FileBuildPart).$($versionInfo.FilePrivatePart)"         $fileVersion = New-Object System.Version($versionString)         }     Catch         {         Write-Host "Unable to retrieve file version info, please verify vulnerability state manually." -ForegroundColor Yellow         Return         }     }
Else     {     Write-Host "Srv.sys does not exist, please verify vulnerability state manually." -ForegroundColor Yellow     Return     }
if ($osName.Contains("Vista") -or ($osName.Contains("2008") -and -not $osName.Contains("R2")))     {     if ($versionString.Split('.')[3][0] -eq "1")         {         $currentOS = "$osName GDR"         $expectedVersion = New-Object System.Version("6.0.6002.19743")         }      elseif ($versionString.Split('.')[3][0] -eq "2")         {         $currentOS = "$osName LDR"         $expectedVersion = New-Object System.Version("6.0.6002.24067")         }     else         {         $currentOS = "$osName"         $expectedVersion = New-Object System.Version("9.9.9999.99999")         }     }
elseif ($osName.Contains("Windows 7") -or ($osName.Contains("2008 R2")))     {     $currentOS = "$osName LDR"     $expectedVersion = New-Object System.Version("6.1.7601.23689")     }
elseif ($osName.Contains("Windows 8.1") -or $osName.Contains("2012 R2"))     {     $currentOS = "$osName LDR"     $expectedVersion = New-Object System.Version("6.3.9600.18604")     }
elseif ($osName.Contains("Windows 8") -or $osName.Contains("2012"))     {     $currentOS = "$osName LDR"     $expectedVersion = New-Object System.Version("6.2.9200.22099")     }
elseif ($osName.Contains("Windows 10"))     {     if ($os.BuildNumber -eq "10240")         {         $currentOS = "$osName TH1"         $expectedVersion = New-Object System.Version("10.0.10240.17319")         }     elseif ($os.BuildNumber -eq "10586")         {         $currentOS = "$osName TH2"         $expectedVersion = New-Object System.Version("10.0.10586.839")         }     elseif ($os.BuildNumber -eq "14393")         {         $currentOS = "$($osName) RS1"         $expectedVersion = New-Object System.Version("10.0.14393.953")         }     elseif ($os.BuildNumber -eq "15063")         {         $currentOS = "$osName RS2"         "No need to Patch. RS2 is released as patched. "         return         }     }
elseif ($osName.Contains("2016"))     {     $currentOS = "$osName"     $expectedVersion = New-Object System.Version("10.0.14393.953")     }
elseif ($osName.Contains("Windows XP"))     {     $currentOS = "$osName"     $expectedVersion = New-Object System.Version("5.1.2600.7208")     }
elseif ($osName.Contains("Server 2003"))     {     $currentOS = "$osName"     $expectedVersion = New-Object System.Version("5.2.3790.6021")     }
else     {     Write-Host "Unable to determine OS applicability, please verify vulnerability state manually." -ForegroundColor Yellow     $currentOS = "$osName"     $expectedVersion = New-Object System.Version("9.9.9999.99999")     }
Write-Host "`n`nCurrent OS: $currentOS (Build Number $($os.BuildNumber))" -ForegroundColor Cyan
Write-Host "`nExpected Version of srv.sys: $($expectedVersion.ToString())" -ForegroundColor Cyan
Write-Host "`nActual Version of srv.sys: $($fileVersion.ToString())" -ForegroundColor Cyan
If ($($fileVersion.CompareTo($expectedVersion)) -lt 0)     {     Write-Host "`n`n"     Write-Host "System is NOT Patched" -ForegroundColor Red     }
Else     {     Write-Host "`n`n"     Write-Host "System is Patched" -ForegroundColor Green     }
#

Voici le résultat de se script exécuté sur un poste patché et non patché.

Information :

Si vous êtes déjà touché par le rançongiciel, la première chose à faire est d’isoler tous les équipements identifiés comme étant contaminés en les débranchant du réseau afin de contenir l’action du programme. De plus vous devez si possible mettre en veille prolongé la machine ou de la mettre hors tension pour arrêter l’action du programme et de ne surtout pas payer la rançon.

Vous pouvez lire également deux notes de l’Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI) qui permet de savoir quelle attitude adopter avant et après une attaque rançongiciel.

http://www.cert.ssi.gouv.fr/site/CERTFR-2017-INF-001/CERTFR-2017-INF-001.html

http://www.ssi.gouv.fr/actualite/alerte-campagne-de-rancongiciel-3/

Suite à l'attaque du virus Wanna Cry, tout le monde a souhaité corriger la faille de sécurité au plus vite.

Avec tout ce qu'on a pu lire ou trouver sur internet on ne sait plus vraiment qui fait quoi et si nous sommes réellement protégé.

Liste des KB de Sécurité

Voici la liste des KB de sécurité couvrants la faille (pour information les KB se remplacent d'un mois à l'autre : exemple la KB du mois d'avril remplace celle de Mars):

1. Pour Windows XP, Vista, 8, Windows Server 2003 et 2008 : 
   1. Mars 2017
      1. KB4012598
2. Pour Windows 7 SP1 et Windows Server 2008 R2 SP1:
   1. Mars 2017
      1. Security only update : KB4012212
      2. Monthly Rollup : KB4012215
      3. Preview of Monthly Rollup : KB4012218
   2. Avril 2017
      1. Security only update : KB4015546
      2. Monthly Rollup : KB4015549
      3. Preview of Monthly Rollup : KB4015552
   3. Mai 2017
      1. Security only update : KB4019263
      2. Monthly Rollup : KB4019264
      3. Preview of Monthly Rollup : KB4019265
3. Pour Windows Server 2012 :
   1. Mars 2017
      1. Security only update : KB4012214
      2. Monthly Rollup : KB4012217
      3. Preview of Monthly Rollup : KB4012220
   2. Avril 2017
      1. Security only update : KB4015548
      2. Monthly Rollup : KB4015551
      3. Preview of Monthly Rollup : KB4015554
   3. Mai 2017
      1. Security only update : KB4019214
      2. Monthly Rollup : KB4019216
      3. Preview of Monthly Rollup : KB4019218
4. Pour Windows 8.1 et Windows 2012 R2 :
   1. Mars 2017
      1. Security only update : KB4012213
      2. Monthly Rollup : KB4012216
      3. Preview of Monthly Rollup : KB4012219
   2. Avril 2017
      1. Security only update : KB4015547
      2. Monthly Rollup : KB4015550
      3. Preview of Monthly Rollup : KB4015553
   3. Mai 2017
      1. Security only update : KB4019213
      2. Monthly Rollup : KB4019215
      3. Preview of Monthly Rollup : KB4019217
5. Pour Windows 10 (Release 1511) :
   1. Mars 2017
      1. KB4013198
      2. KB4016636
   2. Avril 2017
      1. KB4015219
   3. Mai 2017
      1. KB4019473
6. Pour Windows 10 (Release 1607) :
   1. Mars 2017 
      1. KB4013429
      2. KB4015438
      3. KB4016635
   2. Avril 2017
      
      1. KB4015217
   3. Mai 2017
      
      1. KB4019472
      2. KB4023680
7. Pour Windows 10 LTSB : 
   1. Mars 2017 
      1. KB4012606
      2. KB4016637
   2. Avril 2017
      
      1. KB4015221
   3. Mai 2017
      
      1. KB4019474

En espérant que cela pourra vous servir.

Pour télécharger les KB : http://www.catalog.update.microsoft.com/home.aspx

Lors du déploiement du Rôle RDS sur Windows Server 2012 R2, il se peut que vous rencontriez l'erreur suivante :

"Le serveur est en attente de redémarrage et doit être redémarré."

Cette erreur se présente lorsque si vous avez récemment passé une mise à jour ou installer un rôle ou une fonctionnalité sans redémarrer.

Si même après avoir redémarré cela ne change rien, vérifier si la clé de registre suivante existe :

"HKLM\System\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations"

Si elle existe faites un backup de votre registre, puis supprimez la clé.

Normalement vous pouvez maintenant installer le Rôle RDS sans soucis. 

Attention ne s'applique qu'à partir de  Windows Server 2012 et Windows 8.

Comment connaitre rapidement les configurations DHCP du domaine? Eh bien, avec Powershell.

Lister les serveurs DHCP du domaine:

Pour lister les serveurs DHCP du domaine vous pouvez utiliser la commande:

Get-DhcpServerInDC

Cette commande vous retournera par défaut :

1. l'adresse IP du ou des serveurs
2. Le nom Dns du ou des serveurs

Lister les scopes DHCP:

Pour lister les scopes DHCP et leurs configurations vous pouvez utiliser la commande suivante:

Get-DhcpServerv4Scope

Par défaut cette commande vous retournera les éléments suivants:

1. L'étendue
2. Le masque sous réseau
3. Le Nom du scope
4. L'état (Actif ou Inactif)
5. L'adresse IP de début
6. L'adresse IP de fin
7. La durée des baux

Bien sur il est possible de récupérer d'autres informations si vous le souhaitez.

Obtenir des informations sur les scopes:

Pour obtenir des informations sur l'utilisation des scopes vous pouvez utiliser la commande suivante:

Get-DhcpServerv4ScopeStatistics

Cette commande retourne :

1. L'étendue
2. Le nombre d'adresses libres
3. Le nombre d'adresses utilisées
4. Le pourcentage d'utilisation
5. Le nombre d'adresses réservées
6. Le nombre d'adresses en attente de distribution (normalement 0)
7. Le nom de l'étendue globale

Peut on scripter tout ça?

Il vous est possible d'exécuter toutes ces commandes à distance via "invoke-command" ou "Enter-PSSession" sauf la commande "Get-DhcpServerInDC".

Donc il est possible de scripter toutes ces commandes et avoir une belle extraction sans se connecter au serveur à condition de déjà posséder la résultante de  "Get-DhcpServerInDC".

Sinon vous pouvez aussi exécuter un script depuis le serveur, mais bon ça, c'est quand même moins "Secure".

Plus d'informations sur : 

https://technet.microsoft.com/library/jj590751(v=wps.620).aspx

Bonjour à tous !

L'article d'aujourd'hui rentre dans la catégorie "trucs et astuces", mais de celles qui vous feront gagner beaucoup de temps.

En effet, l'installation de la fonctionnalité .NET Framework version 3.5 sous Windows Server 2012 R2 n'a jamais été une sinécure.

La faute en revient à la fonctionnalité Features on Demand introduite avec Windows Server 2012. Afin de rentre le dossier d'installation de Windows Server 2012 moins volumineux, Microsoft a décidé que les fichiers nécessaires pour installer les rôles et fonctionnalités de Windows Server ne seraient plus présents en totalité sur le disque dur local de l'OS. En conséquence, l'installation de certaines fonctionnalités requiert une source externe (ISO ou ressources sur le réseau) et la fonctionnalité .NET Framework 3.5 en fait partie.

La méthode classique

Concrètement, cela se traduit par un chemin à renseigner vers les sources externes Windows Server lors de l'installation de la fonctionnalité .NET 3.5 au sein du Gestionnaire de Serveur.

Ces sources peuvent être une ISO que vous aurez préalablement monté ou des fichiers stockés sur une ressource réseau.

Si vous ne précisez rien dans le chemin des sources, le Gestionnaire de Serveur utilisera Windows Update comme moyen pour télécharger les sources manquantes.

Et c'est là "tout le sel de l'opération", à savoir que si le serveur est managé par un WSUS, le téléchargement des sources externes via Windows Update n'est pas possible et si vous n'avez pas l'ISO Windows Server sous la main, il vous faudra la transférer et vous n'avez peut être pas le temps, ni la bande passante pour envoyer 4,6 Go !

Heureusement, il existe une alternative.

La méthode Windows Update

La méthode suivante vise à permettre le téléchargement des sources manquantes directement via Windows Update, même si le serveur est dans le périmètre de gestion d'un serveur WSUS.

Nous allons donner ici la méthode "unitaire" pour passer la modification, mais celle-ci est très facilement adaptable en GPO.

1) Pour se faire, ouvrez la console GPEdit.msc sur la machine concernée.

2) Allez dans Computer Configuration -> Administrative Templates -> System

3) Allez à l’option Specify settings for optional component installation and component repair.

4) Passez le paramètre à Enabled si celui-ci est à Disabled ou Not Configured.

5) Cochez l'option Contact Windows Update directly to download repair content instead if Windows Server Update Services (WSUS). Cliquez sur Apply pour valider la modification.

6) Passez la commande GPUpdate /force dans une invite de commande afin que le poste prenne en compte la modification dans ses paramètres de mise à jour.

7) Relancez l'installation de la fonctionnalité .NET Framework 3.5 depuis le Gestionnaire de Serveur, en laissant l'Alternate File Path vide. L'installation devrait désormais être fonctionnelle.

Dans le cadre de la gestion des certificats dans Active Directory, il arrive que l’on retrouve des valeurs de ce type pour les attributs UserCertificate ou CaCertificate:

Ce type de champ est difficilement lisible et cela peut donc complexifier la tâche lorsque l’on veut supprimer un certificat déployé en doublon, ou tout simplement un certificat avec des informations erronées.

Pour rapidement différencier les certificats il suffit de suivre les étapes suivantes:

Copier le contenu Hexadécimal dans un fichier texte :

Exécuter la commande suivante :

Certutil –decodehex C:\Temp\HexValue.txt C:\Temp\OutputCert.cer

Le résultat de la commande est un fichier .cer que l’on peut ouvrir et qui contiendra les attributs du certificat de manière lisible, ces opérations doivent être répétées sur les différentes entrées pour chaque certificat à identifier.

Contexte

Le problème décrit ci-dessous a été rencontré dans le cadre d'une infrastructure DirectAccess sous Windows Server 2012 R2. Celui-ci peut se produire lorsque l'authentification forte (par carte à puce ou OTP) est activée avec des clients Windows 7.

Problème rencontré

Lorsque des lecteurs réseaux sont montés à l'ouverture de la session, cela peut empêcher cette dernière de s'ouvrir correctement et laisser l'utilisateur bloqué sur la page de “Bienvenue” pendant plusieurs minutes voir plusieurs dizaines de minutes.

Analyse

Pour rappel, la connectivité DirectAccess est composée de deux tunnels :

• Le tunnel infrastructure utilisé notamment pour l'authentification et les stratégies de groupes.
• Le tunnel utilisateur qui permet d'accéder à des ressources d'entreprise (partages, applications, site web) en fonction des autorisations de la personne connectée.

Ce problème est une conséquence de l'activation de l'authentification forte. En effet, tant que cette dernière n'a pas eu lieu, le tunnel utilisateur n’est pas créé. Les lecteurs réseaux étant des ressources liés à l’utilisateur, elles sont accédées par ce tunnel. Le système d’exploitation tente de monter les lecteurs réseaux et il faut attendre un timeout de cette opération avant que la session ne s’ouvre.

Solution

Toutes les solutions présentées ici sont des contournements permettant d'éviter le problème mais présentant toutes des inconvénients (à voir selon le cas, celle qui est le plus acceptable pour vous).

1/ Authentification forte pendant l'ouverture de session

Demander l’authentification forte lors de l’ouverture de session permet de déclencher la création du tunnel utilisateur. Ainsi, les lecteurs réseaux peuvent être montés. Cependant, cette méthode implique deux inconvénients :

• Elle ne fonctionne que lorsque la méthode d’authentification forte utilisée est la carte à puce. En cas d’usage d’un OTP, cela ne peut être opérationnelle puisque DirectAccess à un processus propre pour gérer ce type d’authentification décorrélé de celui de l’ouverture de session. Pour plus d’informations, je vous invite à lire cet article : https://blog.piservices.fr/post/2015/11/23/DirectAccess-Deploiement-de-lauthentification-forte
• L’utilisateur est obligé de s’authentifier sur son poste client avec l’authentification. Cela dégrade l’expérience utilisateur lorsque l’on se trouve en entreprise et qu’on ne souhaite donc pas utiliser DirecAccess.

2/ Logon Script

Les lecteurs réseaux sont parfois mappés par un script s'exécutant après l'ouverture de session (logon script). Pour que cette solution soit fonctionnelle, il suffit d'intégrer un test vérifiant que la connectivité DirectAccess est montée et de boucler dessus tant que ce n'est pas le cas. Cela peut être fait en validant l'accès à une ressource d'entreprise comme un partage ou l'url du serveur NLS de DirectAccess. Cependant cette solution présente l'inconvénient de devoir parfois laisser un script tourner continuellement.

3/ Management servers

L’une des autres possibilités est d’ajouter les serveurs de fichiers utilisés par ces lecteurs réseaux dans la liste des serveurs de management. Ainsi, l’accès à ceux-ci se fait via le tunnel infrastructure qui ne nécessite pas d’authentification forte et qui est monté dès le démarrage de l’ordinateur avant l’ouverture de session (si une connexion à internet est disponible). Cependant, cette méthode est contraire à la volonté de sécuriser les accès aux ressources d’entreprise avec de l’authentification forte. En effet, si l’utilisateur ouvre une session, il pourra accéder aux serveurs de fichiers sans authentification forte et par rebond à d’autres serveurs. Cette solution affaiblit donc la sécurité de l’infrastructure.

Si toutefois vous souhaitez implémenter cette solution, il suffit de lancer la console de gestion DirectAccess et de se rendre dans la configuration du serveur ou du cluster via le menu éponyme. Ensuite, il faut cliquer sur le bouton “Edit” de l’étape 3 de l’assistant de configuration.

Dans l’onglet “Management”, il faut indiquer les noms DNS des serveurs de fichiers (les IP ne peuvent être indiquées que si vos serveurs communiquent en IPv6). Vous pouvez ensuite cliquer sur le bouton “Finish”.

N’oubliez pas de mettre à jour les stratégies de groupe en cliquant sur le bandeau qui apparait en bas de la console de gestion DirectAccess. Enfin, il faut récupérer cette nouvelle version des GPOs DirectAccess sur vos postes clients (via la commande “gpupdate” par exemple).

4/ Déclenchement de la connectivité DirectAccess après le logon

Le démarrage d'un des services requis pour la connectivité DirectAccess après l'ouverture de session permet de corriger le phénomène. Le service IP Helper (iphlpsvc) permettant notamment de générer les interfaces de transitions IPv4/IPv6 est l'un deux. En effet, aucun tunnel dédié à DirectAccess n'existera tant que ce service n'est pas démarré. Ainsi, le client ne tentera pas de monter les lecteurs réseaux. Néanmoins, via cette méthode, le tunnel infrastructure n'existe pas non plus tant que l'utilisateur n'est pas connecté. Ainsi, un utilisateur qui se connecte pour la première fois sur un ordinateur ne pourra le faire via DirectAccess. Aussi, les patchs ne pourront être récupérés et les stratégies de groupes ne seront pas mises à jour tant qu'un utilisateur n'a pas ouvert de session. Si toutefois vous souhaitez réaliser cette manipulation, il suffit de créer une stratégie de groupe avec les paramètres ci-dessous.

Dans “Computer Configuration / Preferences / Services”, il faut changer le mode de démarrage du service IP Helper afin qu'il démarre manuellement.

Dans “Configuration / Preferences / Scheduled Tasks”, il faut créer une tâche planifiée lancée par le compte “SYSTEM”.

On définit l'exécution de celle-ci à l'ouverture de session.

Enfin, on indique qu'il faut lancer le service IP Helper via la commande “net start”.

Aussi, il est nécessaire de gérer le cas d'un utilisateur qui ferme sa session afin de ne pas rencontrer le problème lors de la prochaine ouverture de session. Pour cela, il faut créer une seconde tâche se déclenchant à la fermeture de session.

Celle-ci est quasiment identique en dehors de la commande exécutée (“net stop”) et du déclencheur. Ce dernier est paramétré pour détecter l'événement 4647 du journal d'événements Sécurité. Celui-ci correspond à une demande de fermeture de session par l'utilisateur.

Enfin, cet évènement n'est pas généré par défaut. Pour l'obtenir, il faut activer l'audit sur la catégorie “Logoff”. Cette opération s'effectue par stratégie de groupe dans “Computer Configuration / Policies / Windows Settings / Security Settings / Advanced Audit Policy Configuration / Audit Policies”.

Bonjour,

Ce guide fait suite à mon post sur la création d’une collection RDS avec équilibrage de charge sous Windows serveur 2012 R2.

Nous allons voir comment installer le rôle licensing RDS et mettre une GPO basique pour configurer le(s) serveurs(s) host RDS avec ces informations.

Installation du rôle licensing

 Sur la page Overview des services RDS, cliquez sur le plus au dessus de RD Licensing

L’assistant vous demande quel(s) serveur(s) hébergera le rôle. Nous allons ici choisir le serveur qui héberge déjà les rôles Broker et Web (voir post précédent) car aucun des trois n’est très consommateurs de ressources machine et on peut donc les regrouper sur une architecture de petite taille.

Il faudra ensuite ajouter vos licences TS dans la console (Ici mon poste à une CAL temporaire)

Création d’une GPO pour configurer les serveurs host RDS

Afin de ne pas avoir à passer sur chaque serveur nous allons mettre une GPO sur les serveurs avec le rôle host.

J’ai créé une GPO nommée GPO_WRK_RDS_CONFIG et je l’ai placée dans l’OU AD réservée à mes serveurs RDS (tout rôles).

Le filtre de sécurité limite l’application à mes serveurs host RDS.

Nous allons maintenant voir les paramètres obligatoires et intéressants à mettre en place (tout ce qui suit est à adapter à vos besoins car nous).

Tout les paramètres sont dans la partie ordinateur de la stratégie.

Il faut en premier ce rendre dans : “Policies/Administrative Templates/Windows Components/Remote Desktop Services/Remote Desktop Session Host”

Dans la partie “Licensing” :

Les paramètres suivants sont nécessaire pour la bonne configuration de l’infrastructure RDS.

Nous allons renseigner dans la 1ère ligne le nom complet du serveur hébergeant le rôle licensing (dans notre cas LAB-BRDS-02T.labo-pis.dom).

Dans le 3ème, nous spécifions le type de licence utiliser (soit par device, soit par user).

 

Dans la partie “redirection d’imprimante” :

Nous pouvons gérer la redirection des imprimantes clients dans les sessions remote desktop.

Dans le cas de ma dernière expérience il était nécessaire de la bloquer car nous avions des imprimantes installés sur les serveurs et les redirections prêtaient à confusion.

 

Dans le partie “Device and Resource Redirection” :

Nous allons ici bloquer la redirection audio et vidéo, la redirection de l’enregistrement audio, nous autorisons la redirection du port COM (car elle nous est nécessaire pour notre client dans mon cas).

Nous pouvons aussi gérer le presse-papier et d’autres options.

 

 Dans la partie “Session Time Limit” :

Nous allons mettre une durée de vie maximale aux sessions déconnectées.

Nous avons maintenant une collection de serveurs RDS Windows Server 2012 R2 fonctionnelle.