Windows Server 2008 R2 a permis le déploiement de Terminal Server (services Bureau à distance) sans domaine et sans insistance sur les domaines. Cela a été très utile, en particulier pour les déploiements virtuels ou cloud autonomes d'un serveur géré à distance pour un client distant qui n'a ni besoin ni désir de fonctionnalités ActiveDirectory ou de domaine.

Cela est devenu de plus en plus difficile, car Microsoft restreint de plus en plus ses technologies dans chaque version de Windows. Avec Windows Server 2012, la configuration des licences pour les services Bureau à distance est plus difficile quand elle n'est pas sur un domaine, mais reste possible. Avec Windows Server 2012 R2 (au moins dans l'aperçu), les obstacles sont désormais sévères:

1. L'Assistant Ajout / Suppression de rôles et de fonctionnalités dans Windows Server 2012 R2 dispose d'un mode de déploiement RDS spécial qui a une règle qui dit que si vous n'êtes pas sur un domaine que vous ne pouvez pas déployer. Il vous dit de créer ou de rejoindre un domaine en premier. Bien entendu, cela entre en conflit direct avec le fait qu'un contrôleur de domaine Active Directory ne doit pas être la même machine qu'une machine serveur de terminaux. La technologie de Microsoft n'est donc pas tant un système d'exploitation cloud qu'un cluster de nœuds indésirables, nécessaire pour prendre en charge la seule machine que je VEUX réellement déployer. C'est dégoûtant, et j'essaie donc de trouver une solution de contournement.

2. Cependant, si vous ignorez cet assistant et allez simplement cocher les cases de l'assistant principal des rôles / fonctionnalités, vous pouvez déployer les fonctionnalités, mais l'interface utilisateur n'est pas là pour les configurer, et lorsque vous revenez à la page de configuration RDS sur l'assistant de rôles , vous obtenez un message indiquant que vous ne pouvez pas administrer votre système de services Bureau à distance lorsque vous êtes connecté en tant qu'administrateur de l'ordinateur local, car bien que vous ayez tous les privilèges d'administrateur que vous pourriez avoir (dans votre système basé sur un groupe de travail), l'interface utilisateur de configuration RDS sera n'acceptez pas ces informations d'identification et laissez-vous continuer.

Ma question en bref est, puis-je encore en quelque sorte, obtenir le résultat final suivant:

• Je dois autoriser 10 à 20 utilisateurs par système à avoir une session RDS (TS).
• Je n'ai besoin d'aucune des options RDS des pantalons fantaisie, sauf si Microsoft dépend en quelque sorte de ces fonctionnalités. Je crois que j'ai besoin de "l'hôte de session RDS" car c'est le courage de "Terminal Server". Microsoft dit qu'il s'agit d'un «bureau Windows complet pour le client des services Bureau à distance.
• J'ai besoin de configurer les licences afin que la période de grâce n'expire pas, laissant mon RDS non fonctionnel, donc cela signifie probablement que j'ai besoin d'un moyen de configurer les licences d'accès client TS.

Si tout ce qui précède pouvait techniquement être fait avec l'utilisation judicieuse de PowerShell, je suis même prêt à envisager de développer tous les scripts PowerShell dont j'aurais besoin pour faire ce qui précède. Je ne demande pas à quelqu'un de l'écrire pour moi. Ce que je demande, est-ce que quelqu'un sait s'il y a un obstacle technique à ce que je veux faire ci-dessus, autre que la paralysie délibérée de l'interface utilisateur de R2 2012 pour les utilisateurs du groupe de travail? Les technologies sous-jacentes fonctionneraient-elles toutes si je les manipulais et les contrôlais à partir d'un script PowerShell?

De toute évidence, une réponse de 1 mot Oui ou Non n'est utile à personne, donc la question est vraiment, oui ou non, et pourquoi? Dans le cas où la réponse est oui, alors comment.

Je me suis retrouvé dans le même scénario que toi. Le déploiement de Remote Desktop sur une boîte Server 2012 autonome est assez difficile, car les gars de Microsoft ne vous permettent pas d'exécuter cela sur un réseau sans domaine et si vous le faites, vous ne pouvez pas gérer tous les paramètres.

Ainsi, vous pouvez installer une boîte basée sur un groupe de travail et faire fonctionner les rôles Bureau à distance. Nous devons également installer les fonctionnalités de licence de bureau à distance sur la même machine. Mais, une fois à ce stade, même si vous disposez de licences d'accès client RDS appropriées sur le serveur, lorsque l'utilisateur se connecte, le message indique que la période d'essai est activée.

J'ai finalement réussi à le faire fonctionner, au moins quelque chose comme les bons vieux services Terminal Server que nous connaissions. Cela fonctionne pour moi sur deux machines de production de petits clients qui ont besoin de RDS mais ne peuvent pas se permettre d'avoir deux serveurs sur leur réseau.

Et c'est parti:

1. Installez les licences de bureau à distance et les services de rôle hôte de session de bureau à distance en procédant comme suit:

   • Ouvrez le Gestionnaire de serveur
   • Cliquez sur Gérer et sélectionnez Ajouter des rôles et des fonctionnalités
   • Sélectionnez l'installation basée sur les rôles ou basée sur les fonctionnalités
   • Sous Services Bureau à distance, choisissez Licence Bureau à distance et services de rôle Hôte de session Bureau à distance.
   • Procéder à l'installation

2. Ajoutez le serveur de licences au groupe de serveurs de licences Terminal Server et redémarrez le service Bureau à distance (vous pouvez utiliser licmgr.exe)

3. Ajoutez les licences au serveur de licences.

4. Configurez le rôle Hôte de session Bureau à distance avec pour utiliser le serveur de licences Bureau à distance local. Suivez ces étapes:

   • Ouvrez PowerShell en tant qu'administrateur
   • Tapez la commande suivante à l'invite PS et appuyez sur Entrée:

$obj = gwmi -namespace "Root/CIMV2/TerminalServices" Win32_TerminalServiceSetting

Exécutez la commande suivante pour définir le mode de licence (Remarque: valeur = 2 pour par appareil, valeur = 4 pour par utilisateur, nous utilisons par utilisateur)

$obj.ChangeMode(4)

Exécutez la commande suivante pour remplacer mylicenseserverle nom de l'ordinateur par License Server ( est le nom de votre serveur):

$obj.SetSpecifiedLicenseServerList("mylicenseserver")

Exécutez la commande suivante pour vérifier les paramètres configurés à l'aide des étapes mentionnées ci-dessus:

$obj.GetSpecifiedLicenseServerList()

Vous devriez voir le nom du serveur dans la sortie.

Une fois cela fait, redémarrez le système et connectez-vous avec n'importe quel utilisateur (si vous utilisez un groupe de travail, vous savez que vos utilisateurs doivent faire partie de Remote Desktop Users) et le message de la période d'essai disparaîtra.

Source de tout ce gâchis: http://support.microsoft.com/kb/2833839

Gérer avec Powershell

Il y a quelques choses avec lesquelles vous pouvez gérer Powershell. Pour voir les commandes, essayez:

import-module RemoteDesktop get-command -module RemoteDesktop

Il existe une liste de commandes que vous pouvez exécuter via Powershell pour gérer votre box. Cependant, j'en ai essayé quelques-uns, mais certains d'entre eux nécessitent que vous ayez installé des fonctionnalités supplémentaires, qui ne peuvent pas être déployées dans le scénario dont nous parlons.

La vilaine façon

Si aucun des éléments ci-dessus ne fonctionne pour vous, il existe un moyen de réinitialiser le délai de grâce aux 120 premiers jours. Bien sûr, je ne recommande pas de le faire, car l'utilisateur continuera de remarquer le message. Bien sûr, vous devrez acheter des licences appropriées.

Pour réinitialiser le compteur, supprimez simplement cette clé de registre:

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Grace Period

Bien sûr, vous aurez besoin de privilèges supplémentaires pour ce faire, l'exécution en regedittant qu'administrateur ne fonctionnera pas. Essaye ça:

• Obtenez PSEXEC
• Démarrer un cmd en tant qu'administrateur
• courir psexec -s -i regedit.exe
• supprimer la clé souhaitée
• redémarrer

J'espère que cela fonctionnera pour vous. Si vous faites des progrès avec Powershell et RDS, faites-le nous savoir.

Comme je mettais en place un environnement dans un laboratoire pour essayer cela (un simple déploiement RDS sans domaine), j'ai trouvé la réponse à votre question, bien que ce ne soit pas celle que vous souhaitez entendre.

RDS dans [Server 2012 et 2012 R2] nécessite que tous ses serveurs soient ajoutés à un domaine . Cela, selon un responsable de programme chez Microsoft de l'équipe de virtualisation de bureau à distance, qui a écrit l'article de blog MSDN lié, Configuration d'un nouveau déploiement de services de bureau à distance à l'aide de Windows PowerShell.

Donc, désolé que ce ne soit pas la réponse que vous vouliez, mais elle semble faire autorité pour moi. Vous ne pouvez pas faire ce que vous voulez, car Microsoft a décidé de faire de l'appartenance à un domaine une exigence technique pour les serveurs RDS dans Server 2012 et 2012 R2.

J'ai trouvé pendant le test qu'il est important d'avoir au moins 1 carte réseau configurée avec IPv6 activé. Cela était nécessaire car le bouclage pour que le serveur de licences RDS se parle à lui-même qu'il tentait de résoudre via IPv6 pour le faire (comme vu dans Pings). J'avais IPv6 désactivé sur les deux cartes réseau, ce qui empêchait le serveur de boucler correctement.