Terminal Services 2008 - erro 4105 (problema de servidor de licenciamento)

Question

Aqui está o resumo no servidor:

• Server 2008 Standard sendo executado como um servidor membro em um domínio do Server 2003
• Executando os Serviços de Terminal para 5 usuários que precisam acessar um aplicativo POS usando o RemoteApp
• Executando seu próprio servidor de licenciamento:
  • 5 TS CALs por usuário instaladas
  • A "Revisão de configuração" me dá um splat reclamando que o servidor de licenciamento não está instalado em um DC.
  • O servidor é membro do grupo "Servidores de licenças do Terminal Server" no AD
  • Ele não parece estar distribuindo licenças, embora os usuários possam fazer login.

Eu recebo o seguinte erro quando os usuários fazem login:

The Terminal Services license server cannot update the license attributes for user "[username]" in the Active Directory Domain "[domainname]". Ensure that the computer account for the license server is a member of Terminal Server License Servers group in Active Directory domain "[domainname]". If the license server is installed on a domain controller, the Network Service account also needs to be a member of the Terminal Server License Servers group. If the license server is installed on a domain controller, after you have added the appropriate accounts to the Terminal Server License Servers group, you must restart the Terminal Services Licensing service to track or report the usage of TS Per User CALs. Win32 error code: 0x80070005

Isso parece estar causando alguns problemas com os usuários do RemoteApp. A sessão parece desconectar e depois deixar uma tela completamente preta no sistema. Eles não podem fechar a tela preta - preciso desconectá-los remotamente usando o Gerenciador de serviços de terminal. Também os obriga a carregar o RemoteApp na janela "Show Details" que mostra quando o usuário está logando no Terminal Server (isso é difícil de descrever - eu vou pegar um screenshot se alguém precisar de um).

Li este tópico e este no technet, e ambos os pontos para as seguintes chaves de segurança:

• msTSExpireDate
• msTSLicenseVersion
• msTSManagingLS

Pesquisei alto e baixo para encontrar essas chaves para que o servidor de licenciamento possa licenciar adequadamente os usuários, mas não os encontro em nenhum lugar. Estou selecionando minha UO para minhas contas de usuário e tentando alterar a segurança lá, mas não consigo encontrar as chaves para alterar.

Este domínio foi atualizado para o Server 2003 do Server 2000, por isso talvez as teclas não estejam lá. Algumas pessoas mencionaram fazer adprep a partir da máquina do Server 2008 para gravar as chaves de segurança corretas para os usuários, mas isso causaria problemas com meus controladores de domínio existentes do Server 2003? Eu não pretendo atualizar meus controladores de domínio para o Server 2008 até o final do ano.

Alguém sabe como posso adicionar as chaves de segurança manualmente aos 5 usuários que estão usando este servidor de terminal? Há mais alguma coisa que eu possa fazer para corrigir isso?

Obrigado!

EDIT: Gostaria especificamente de saber se a execução do adprep a partir de um MEMBER SERVER do Server 2008 em um domínio do Server 2003 corrigirá isso ou causará outros problemas. Alguém tem alguma ideia?

    

Answer 1

De acordo com este link e esta , os atributos que você mencionou foram apresentados pela primeira vez com o Windows Server 2008; Portanto, sim, atualizar o esquema do AD para o nível de 2008 deve corrigir o problema.

É uma operação totalmente segura, mesmo que você não planeje adicionar nenhum DC 2008 ao domínio em breve. Apenas certifique-se de que todos os seus DCs estejam on-line, a replicação está funcionando corretamente, o DC que mantém a função de Mestre de Esquema está acessível e você tem direitos de Administração de Empresas e Administração de Esquemas.

BTW, você deve executar o ADPREP em um de seus controladores de domínio existentes em 2003 , não em um servidor membro de 2008.

    

Answer 2

adprep, atualização de esquema, etc não resolveria seu problema, eu acho. atualizar o esquema não é prob, porque você teria que fazer isso também se novos dcs entrarem.

no meu caso eu tenho nativo 2008 r2, com certeza migrou de 2000 para 2003, para 2008 r2, e também 2008 r2 ts, ts lic, tudo nazive em 2008 r2.

mas mesmo efeito. não vejo nenhum problema no ambiente real, mas também registrando essas informações no servidor de licença ts.

então, se você procurar mais em sua infraestrutura, você vai ver isso - conta de usuário recém-criada - algumas de suas contas tem os vários atributos msTS.

na verdade, vejo que todas as contas de usuário nas unidades organizacionais com os atributos ausentes estão nos mesmos grupos. Mesma OU. então eu acho que esse problema ocorre em unidades orgânicas criadas por nós, onde existe um problema, tal falta de direitos herdados, falta de configuração de segurança.

estou testando este agora.

o que eu quero dizer para todos:

seu sistema neste ambiente de erro não precisa ser atualizado, adprep, schemaprep etc. observe a configuração de segurança em seus objetos de usuário.

mathias rühn - kopyczynski

adicione: A solução era conceder direitos de segurança aos objetos do usuário que não tinham os três atributos msTS: Leia e "servidor de licenças WRITE Terminal Server" para o grupo terminal-licenseserver.

se você fizer logon novamente na área de trabalho remota ou no citrix, os três atributos serão criados no usuário específico e preenchido com informações.

também o recém-criado ous tinha o problema em uma de minhas infraestruturas. Eu tive que fazer manualmente esta configuração no segundo nível ous.

    

Answer 3

As "chaves de segurança" mencionadas parecem ser atributos LDAP (não estou familiarizado com essas chaves, mas seguem a convenção de nomenclatura padrão), portanto, é necessário usar o adsiedit.msc (disponível no Windows Server 2003 Resource Kit ) para chegar até eles .

A atualização do esquema via adprep é uma boa ideia. Além de trazer esses atributos, ele dará ao novo esquema uma cama no período anterior à sua mudança para os DCs de 2008. Como o Massimo disse, é uma operação segura, mas certifique-se de ter um backup viável do seu AD antes de executá-lo (e também que você saiba que pode restaurar a partir dele!) Caso receba um falha de energia ou algo mais desagradável acontece a meio caminho.

Assim como a atualização do esquema - você moveu a caixa TS para uma nova UO a qualquer momento? Vários serviços do MS ficam insatisfeitos quando você faz isso e, se você não tiver reiniciado os serviços ou reinicializado a caixa, pode causar um comportamento errático. Eu consideraria uma boa prática geral reiniciar todos os serviços que interagem com o AD após uma operação de movimentação do computador.