Caminhos de perfil de usuário em sessões do RemoteApp

Question

Eu tento configurar um farm de serviços de terminal, atendendo a alguns dos nossos aplicativos de LOB. O objetivo principal é usá-los como RemoteApps através do Terminal Services Gateway para os usuários, que estão em algum lugar longe da sede. Não tenho grandes problemas em configurar um farm, um serviço da web e o gateway. Minha dor de cabeça agora é sobre perfis de usuários.

Imagine que você execute o aplicativo do Excel como um RemoteApp a partir da rede externa. Em seguida, você clica em "Salvar" e, por padrão, obtém o caminho de documentos do perfil no TS-Server. Os usuários não entenderão que não são locais, salvem o arquivo e, depois de algum tempo, descobrem que ele está "perdido". Infelizmente, não usamos perfis de roaming em toda a organização, por isso não é o caminho a percorrer. Além disso, o usuário na rede externa não terá acesso a eles. Portanto, a única maneira é usar perfis locais nas máquinas dos usuários para armazenar os resultados de seus trabalhos.

Estou tentando fazer com que funcione - o GPO faz algumas coisas. Ele executa comandos simples:

net use x: \tsclient\c
md x:\ts_remote

Eu uso o caminho x: \ ts_remote, porque o usuário chamado "John_Woo" em nossa rede corporativa pode ser nomeado apenas "Usuário" em sua máquina local privada, não ingressada no domínio, portanto não posso usar o usuário padrão C : \ Documents and Settings \% username%. Então eu estou lançando um pequeno script:

Dim WSHShell
Set WSHShell = CreateObject("WScript.Shell")
WSHShell.RegWrite "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Personal", "X:\ts_remote"
WSHShell.RegWrite "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\My Pictures", "X:\ts_remote"
WSHShell.RegWrite "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Desktop", "X:\ts_remote"

Embora de alguma forma funcione, eu realmente não gosto da minha configuração. O primeiro grande problema é que X: disk (o usuário C :) às vezes não é mapeado por algum motivo estranho. Ou ele é mapeado, mas em algum estado "off-line" e é ativado apenas quando você clica nele. A segunda coisa - mapeada X: funciona às vezes extremamente lenta! Quero dizer, um desempenho muito ruim, pode levar de 15 a 20 segundos para abrir a caixa de diálogo Salvar e, em seguida, cerca de duas vezes mais para realmente salvar a planilha vazia do Excel.

O mais estranho é que às vezes os mapas, às vezes não. Às vezes funciona rápido, mas de novo - não entendo as razões, quando fica muito lento. Isso não é problema de rede ou desempenho do servidor. Minha principal questão é: Alguém tem alguns conselhos e práticas, redirecionando os caminhos do perfil para os discos do cliente? Talvez eu não esteja indo no caminho certo. Obrigado.

    

Answer 1

Não me surpreende que você esteja com problemas para mapear os compartilhamentos no cliente. As conexões WAN parecem rápidas até o ponto em que você executa o tráfego SMB sobre elas e, em seguida, elas ficam mais lentas.

Se você precisa ter acesso às unidades nos PCs de seus usuários, que tal usar os recursos de mapeamento de unidades locais no TS. Tenha em mente que você está expondo seu servidor a todos os vírus e malwares nos PCs remotos.

Eu não tenho uma resposta muito boa para este problema, exceto para a educação do usuário e isso é um dos oxímomos de TI padrão. Você poderia usar algum outro mecanismo para os usuários obterem arquivos armazenados nos servidores do escritório? Uma interface web, possivelmente, ou rsync?

JR

    

Answer 2

Vou repetir o que John Rennie já disse: você nunca conseguirá o que está tentando fazer para ser confiável. Você está tentando reutilizar funcionalidades que não foram projetadas para o que você está usando. Você já tentou esse caminho, descobriu que isso leva a um beco sem saída e agora é hora de se virar e procurar uma solução diferente.

Várias vezes na minha carreira eu me deparei com soluções altamente insatisfatórias que foram postas em prática porque "elas só querem que funcione" (como você colocou em seu comentário para John Rennie). Há uma tentativa de atender aos requisitos e expectativas dos usuários e, em seguida, há uma inclinação contra os moinhos de vento. Se a gerência pedisse para você reverter o fluxo de tempo, ou exceder a velocidade da luz, você riria deles. A menos que você escreva código para resolver o seu problema, tentar "mudar as regras" de como funciona um software existente é como tentar reescrever as leis da física. Pode haver alguns hacks que "mais ou menos" funcionam, mas fundamentalmente o software funciona como se fosse projetado para funcionar.

O desempenho errático que você está vendo é porque você está tentando usar um recurso de maneira que ele não foi projetado para ser usado, e porque o "clima" temporário da rede entre o computador cliente e o computador servidor está afetando a transferência velocidades e latência. Eu não posso imaginar que a extensão do protocolo "client drive mapping" para o RDP seja realmente indulgente com conectividade de rede duvidosa.

A meu ver, você deseja "Perfis de usuários móveis dos serviços de terminal" (procure na guia "Serviços de terminal" das propriedades de um usuário do Active Directory). Se você precisar que esses arquivos sejam acessíveis a aplicativos em execução localmente em comptuers de clientes, será necessário expor esses arquivos para os clientes, por meio de uma VPN ou por meio de algo como o WebDAV sobre SSL.

Embora eu entenda que seus "superiores" gostariam que as coisas "simplesmente funcionassem", há um limite para o que você pode fazer sem gastar muito dinheiro por softwares personalizados.