Eu não tenho uma resposta para o bit "recursos e vídeos" além de direcioná-lo para site da Microsoft e sugerimos que você leia a documentação a>.
Para falar com suas dúvidas, porém:
-
Geralmente, a funcionalidade RemoteApp é usada para fornecer a "aparência" de um aplicativo nativo executado na sessão do Windows "thick client" tradicional do usuário. Usei a funcionalidade RemoteApp para, por exemplo, entregar um aplicativo de "banco de dados de arquivos compartilhados" aos clientes por meio de uma WAN. O aplicativo não poderia funcionar através de uma WAN por causa de sua "arquitetura" de "banco de dados", mas, como o uso da funcionalidade RemoteApp permitia que o aplicativo aparecesse para usuários remotos como um aplicativo nativo Computador cliente Windows.
Se você está pensando em fornecer um ou mais aplicativos específicos para usuários com clientes Windows existentes, usar o RemoteApp pode ser o caminho a ser seguido. Se você estiver olhando para usar dispositivos do tipo thin client ou não quiser que os usuários tenham uma experiência de "computador local", o RemoteApp provavelmente não é para você.
-
A Microsoft tem documentação sobre a funcionalidade do Gateway TS que funciona muito bem. O TS Gateway é, basicamente, um aplicativo para proxy do protocolo Remote Desktop / TS via HTTPS. Isso permite que seus usuários se conectem a sessões TS (hospedadas por um servidor dedicado ou, como é o caso do Windows Small Business Server, por exemplo, seus desktops dedicados) por meio de uma rede pública não confiável. A maioria dos desafios relacionados à implantação do TS Gateway, na minha experiência, veio da falta de compreensão dos requisitos da PKI. Usar certificados autoassinados com o TS Gateway sem implantar o certificado raiz da CA em todos os clientes, por exemplo, é uma receita para a frustração.
-
Eu preencherei isso se você puder me dizer o que você quer dizer com "SAV"? Este não é um acrônimo com o qual estou familiarizado em referência aos Serviços de Terminal.
-
Parece que você está falando sobre a entrega do Microsoft Outlook via Terminal Services e deseja saber se deve configurar os perfis MAPI dos usuários para usar o Modo Cache do Exchange. Se isso não for preciso, me avise.
Usar o Modo Cache do Exchange (arquivos OST) geralmente é uma boa ideia por motivos de desempenho do Exchange Server, desde que o OST do usuário não precise ser reconstruído repetidas vezes. O OST é armazenado na parte "Local" do usuário do seu perfil de usuário. No caso de um ambiente dos Serviços de Terminal, se o usuário estiver se conectando a um dos muitos computadores do Terminal Server em um "farm", o usuário poderá acabar recebendo uma parte local diferente de seu perfil em cada logon e você pode acabar causando muito de excesso de tráfego para o Exchange reconstruir / atualizar arquivos OST. Se os usuários estiverem se conectando ao mesmo computador do Terminal Server para cada sessão, o uso do Modo Cache do Exchange não deverá apresentar um problema, pois a parte local do perfil do usuário persistirá entre os logons.
-
Não há computadores "BDC" no Active Directory. Você realmente quer dizer, eu acho, "Devemos tornar o computador do Terminal Server um controlador de domínio?" Em geral você não deveria. Computadores de controlador de domínio executam uma função muito crítica de segurança e permitindo que usuários gerais executem código neles, você corre o risco. Claro - se o sistema fosse livre de bugs, não haveria risco algum. Nenhum software é livre de bugs, e vale a pena empregar uma estratégia de defesa profunda que inclui não permitir que os usuários executem código arbitrário em computadores com Controladores de Domínio.
-
Se os computadores com Windows XP tiverem a versão do cliente dos Serviços de Terminal carregada com o Windows XP Service Pack 2 ou mais recente (e você realmente deve executar o SP3 mesmo assim) não terá problemas ao usar o RemoteApp no Windows XP clientes.