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:
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, 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.