O Windows Server 2008 R2 permitiu a implantação do Terminal Server (Serviços de Área de Trabalho Remota) sem um domínio e sem insistência nos domínios. Isso foi muito útil, especialmente para implantações autônomas virtuais ou na nuvem de um servidor gerenciado remotamente para um cliente remoto que não precisa ou deseja nenhum recurso do ActiveDirectory ou do Domínio.
Isso se tornou cada vez mais difícil, pois a Microsoft restringe cada vez mais suas tecnologias a cada versão do Windows. Com o Windows Server 2012, a configuração do licenciamento para os Serviços de Área de Trabalho Remota é mais difícil quando não está em um domínio, mas é possível ainda. Com o Windows Server 2012 R2 (pelo menos na visualização), as barreiras agora são severas:
O assistente Adicionar / Remover Funções e Recursos no Windows Server 2012 R2 possui um modo de implantação especial do RDS que possui uma regra que diz que, se você não estiver em um domínio, não poderá implantar. Ele diz para você criar ou ingressar em um domínio primeiro. Obviamente, isso entra em conflito direto com o fato de que um controlador de domínio do Active Directory não deve ser a mesma máquina que uma máquina de servidor de terminal. Portanto, a tecnologia da Microsoft não é tanto um sistema operacional de nuvem como um cluster de nós indesejados, necessários para suportar a única máquina que eu realmente quero implantar. Isso é nojento e, portanto, estou tentando encontrar uma solução alternativa.
No entanto, se você pular esse assistente e apenas marcar as caixas de seleção no assistente de Funções / Recursos principal, poderá implantar os recursos, mas a interface do usuário não existe para configurá-los e quando você voltar à página de configuração do RDS no assistente de funções , você receberá uma mensagem informando que não pode administrar o sistema dos Serviços de Área de Trabalho Remota quando estiver logado como Administrador de Computador Local, porque, embora você tenha todos os privilégios de administrador que você poderia ter (no sistema baseado em grupo de trabalho), a interface de configuração do RDS será não aceite essas credenciais e deixe-o continuar.
Em resumo, minha pergunta é: ainda posso obter o seguinte resultado final:
- Preciso permitir que 10 a 20 usuários por sistema tenham uma sessão RDS (TS).
- Não preciso de nenhuma das opções sofisticadas de RDS para calças, a menos que a Microsoft dependa de alguma forma desses recursos. Acredito que preciso do "RDS Session Host", pois esse é o ponto mais importante do "Terminal Server". A Microsoft diz que é "a área de trabalho completa do Windows para o cliente dos Serviços de Área de Trabalho Remota.
- Preciso configurar o licenciamento para que o Período de Carência não expire, deixando meu RDS não funcional, portanto, isso provavelmente significa que preciso de uma maneira de configurar TS CALs.
Se tudo o que foi dito acima puder ser tecnicamente feito com o uso criterioso do PowerShell, eu estou preparado para considerar o desenvolvimento de todos os scripts do PowerShell que eu precisaria fazer acima. Não estou pedindo a alguém que escreva isso para mim. O que estou perguntando é: alguém sabe se existe algum impedimento técnico ao que eu quero fazer acima, além do impedimento deliberado da interface do usuário 2012 R2 para usuários do grupo de trabalho? As tecnologias subjacentes ainda funcionariam se eu as manipulasse e controlasse a partir de um script do PowerShell?
Obviamente, uma resposta de 1 palavra Sim ou Não não é útil para ninguém, então a pergunta é realmente, sim ou não, e por quê? No caso, a resposta é Sim, então como.