Les services Bureau à distance peuvent-ils être déployés et administrés par PowerShell seul, sans domaine dans WIndows Server 2012 et 2012 R2?
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 lorsqu'il ne se trouve 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:
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.
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, à moins que Microsoft ne dépende 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 2012 R2 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:
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
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)Ajoutez les licences au serveur de licences.
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 sur 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 périphérique, valeur = 4 pour par utilisateur, nous utilisons par utilisateur)
$obj.ChangeMode(4)
Exécutez la commande suivante pour remplacer le nom de l'ordinateur par License Server (mylicenseserver 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 du 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 que vous pouvez gérer avec 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 façon laide
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 de regedit en tant qu'administrateur ne fonctionnera pas. Essaye ça:
- Obtenez PSEXEC
- Démarrer un cmd en tant qu'administrateur
- exécutez
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 gestionnaire de programme chez Microsoft dans 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 cela semble être assez autoritaire 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 était important d'avoir au moins 1 NIC configuré avec IPv6 activé. Cela était nécessaire comme bouclage pour que le serveur de licences RDS se parle, il a tenté de le résoudre via IPv6 pour ce faire (comme vu dans Pings). J'avais IPv6 désactivé sur les deux cartes réseau et cela a causé le serveur de ne pas boucler correctement.