A app de gestão que só corre a partir de um Windows, o cliente antigo da ERP que exige instalação local, o utilitário do contador que ninguém quer repetir em sessenta postos de trabalho — terreno do Remote Desktop Services (RDS): as aplicações correm no servidor e o utilizador só vê a janela, como se estivesse no próprio PC. Este guia monta um RDS num servidor Windows Server para publicar RemoteApps de apps legadas: instalação dos roles, licenciamento CAL, coleção, publicação, clientes e a ponte com o hardening de RDP já tratado aqui no kbase.

TL;DR — a montagem em 5 passos

Instalar o RDS e configurar o deployment (Server Manager ou PowerShell), activar o servidor de licenças e as CALs, criar a coleção com os grupos certos, publicar a app como RemoteApp e apontar os utilizadores ao cliente (.rdp ou web client HTML5). O RDS aceita ligações sem servidor de licenças durante um período de graça de 120 dias — não é gratuito depois.

1. Quando é que os RemoteApps fazem sentido

O caso clássico é o de sempre nas PME: uma app de gestão — ERP, cliente de faturação, software de contabilidade — que só corre em Windows, exige pastas de rede ou licenças de posto amarradas à máquina. Instalá-la em cada PC significa N instalações, N compatibilidades e N pontos de actualização. Com RemoteApp, o executável vive no Session Host: corre aí, com os seus dados na rede do servidor, e o utilizador arranca-o como se fosse uma app local — a janela aparece na barra de tarefas, funciona em vários monitores e usa controlos de janela comuns. As RemoteApps comportam-se como apps instaladas localmente: entram no menu Iniciar e na barra de tarefas e espalham-se por vários monitores.

A doc do RDS aponta este cenário entre os mais comuns: alojar aplicações legadas ou especializadas que seriam impraticáveis de instalar em muitos postos, além do acesso seguro para prestadores de serviços e colaboradores sazonais sem abrir a rede interna. Do lado técnico, o RDS é a plataforma integrada para entregar desktops e aplicações geridas aos utilizadores: centraliza o processamento no datacenter e envia para o terminal apenas a UI por RDP — o patch aplica-se uma vez, no servidor, e os dados ficam no datacenter.

Quando escolher o quê:

Cenário Escolha
Uma a três apps Win32 legadas que o negócio exige e os utilizadores têm os seus PCs RemoteApp no Session Host — publicação por app, sem tocar nos desktops dos utilizadores
Ambiente completo em remoto (várias apps + perfil + dados) para uma função inteira Desktop completo de sessão (pooled) na mesma coleção RDS
Precisam de um Windows client com perfil pessoal e aplicações de especialidade VDI pessoal/poolado — tema a parte, fora deste guia
A app já tem versão web ou SaaS Nada disto — navegador chega e o RDS não vale o esforço

Teoria — a app numa sessão multi-session do Server

O Windows Server em RDS é multi-session: utilizadores distintos têm sessões isoladas no mesmo servidor. Aplicações de gestão escritas para posto único têm frequentemente caminhos de instalação e chaves de registry por máquina — a Microsoft recomenda validar cedo o comportamento multi-session da aplicação (os caminhos e as chaves de registry por máquina assumidos dão maus resultados em multi-posto). Testa a app no Session Host antes de a publicar.

2. As peças do RDS num servidor

O RDS é composto por role services que podem distribuir-se por servidores distintos ou concentrar-se todos num único servidor. Para um deployment de RemoteApps com um servidor, as quatro peças básicas — e o RD Gateway, opcional — são estas:

Role service Função Num servidor único
RD Session Host Corre as sessões e as RemoteApps — é onde a app legada fica instalada Sim — o servidor onde as apps correm
RD Connection Broker Mantém as sessões dos utilizadores, equilibra ligações e reconecta a sessão existente Sim — obrigatório no deployment
RD Web Access Portal web e feeds com os desktops e as apps que cada utilizador pode usar Sim — para a RD Web e os ícones de lançamento
RD Licensing Emite e contabiliza as RDS CALs (obrigatório para uso legal) Sim — pode correr no próprio servidor
RD Gateway Túnel de RDP em HTTPS para ligações da internet — encapsula o RDP no HTTPS para expor menos portas Só se os utilizadores acederem de fora da rede (alternativa: VPN). O web client exige Gateway

Imprescindível num servidor único

Para RemoteApps dentro da rede (via ficheiro .rdp ou portal RD Web): RD Session Host + RD Connection Broker + RD Web Access + RD Licensing. O RD Virtualization Host (VDI) não entra nesta montagem — RemoteApp corre sobre sessões do Server, nada de Hyper-V. O web client HTML5, esse, pede normalmente um RD Gateway no deployment (além de RD Connection Broker e RD Web Access) — em Windows Server 2019+ há caminho documentado para o ligar ao Broker sem Gateway, com secção própria na doc.

3. Instalar o role RDS

Pelo Server Manager — percurso da documentação para um deployment session-based: Manage → Add Roles and Features, escolher Remote Desktop Services installation, depois Standard Deployment e Session-based desktop deployment. O assistente pede os servidores para o RD Connection Broker, o RD Web Access e o RD Session Host — num servidor único, os três são a mesma máquina — se o wizard pedir, marca o reinício automático do destino e aplica. No fim, acrescentar o servidor de licenças em Remote Desktop Services → Overview → + RD Licensing.

Pelo PowerShell — um cmdlet monta o deployment: o New-RDSessionDeployment instala o role services necessário para um deployment session-based — a doc diz à letra "Installs the required role services for session-based desktop deployment" — por isso a instalação não precisa de Install-WindowsFeature prévio. Os nomes dos roles confirmam-se na build com Get-WindowsFeature -Name RDS* (RDS-Connection-Broker, RDS-Web-Access, RDS-RD-Server, RDS-Licensing):


New-RDSessionDeployment -ConnectionBroker "SRV-RDS1.dominio.local" -WebAccessServer "SRV-RDS1.dominio.local" -SessionHost "SRV-RDS1.dominio.local"

Para acrescentar o RD Gateway (precisarás dele para o web client da secção 6), o Server Manager tem a via Remote Desktop Services → Overview → + RD Gateway. Em PowerShell é o cmdlet Add-RDServer com -Role "RDS-GATEWAY" (exemplo documentado: Add-RDServer -Server "Gateway.Contoso.com" -Role "RDS-GATEWAY" -ConnectionBroker "RDCB.Contoso.com"). E o servidor de licenças entra no deployment com Add-RDServer -Server "SRV-RDS1.dominio.local" -Role RDS-LICENSING -ConnectionBroker "SRV-RDS1.dominio.local".

4. Licenças: CAL per user vs. per device

Regra base: cada utilizador e cada dispositivo que ligar a um session host precisa de uma RDS CAL. Há dois modelos de CAL: per device (atribuída fisicamente a cada equipamento que liga) e per user (atribuída ao utilizador em Active Directory). Os dois exigem um servidor RD Licensing activo e CALs instaladas — o activation wizard liga-se à Microsoft pela porta 443 (método automático recomendado, com alternativas por browser e por telefone).

Per device Per user
Atribuição Fisicamente atribuída a cada dispositivo Atribuída a um utilizador em Active Directory
Rastreada pelo licensing server Sim — também sem integração com AD Sim — mas não funciona num workgroup
Revogação Pode revogar até 20% das CALs Não é possível revogar CALs
CAL temporária Emitida na primeira entrada do dispositivo, válida por 90 dias Não existem temporárias
Vida da CAL permanente 52-89 dias até renovar 60 dias antes de renovar, com 90 dias antes de reatribuir a outro utilizador
Sobre-alocação Bloqueada Possível — é o administrador a garantir conformidade

A regra de escolha: per device cabe onde há vários turnos a usar os mesmos computadores — per user cabe onde cada pessoa tem o seu dispositivo dedicado. Duas regras duras: em servidores sem integração com AD (workgroup) só se podem usar Per Device CALs — o Per User não é permitido, porque este precisa de Active Directory para o rastreio. As CAL per user não são impostas pelo servidor (licensing isn't enforced) — o rastreio é por relatórios do RD Licensing Manager, com a conformidade como responsabilidade do administrador.

O período de graça de 120 dias

Entre instalar o RD Session Host e configurar as CALs há uma graça de 120 dias sem servidor de licenças — terminada a graça, nenhum cliente entra em sessão sem uma RDS CAL válida emitida pelo servidor de licenças. Sem servidor de licenças activo e CALs a tempo, as sessões de utilizadores param. As sessões de administração são outra coisa — mstsc /admin liga-te a uma sessão de administração do servidor, não a servir apps a utilizadores. A graça não regressa sozinha: a reconfiguração do servidor e a activação das CALs têm de ser feitas dentro do prazo.

Configuração apontada ao deployment: no Server Manager, Remote Desktop Services → Overview → Edit Deployment Properties → RD Licensing, escolher o modo (Per User ou Per Device) e o servidor de licenças. Em PowerShell, o cmdlet confirmado é Set-RDLicenseConfiguration:


Get-RDLicenseConfiguration -ConnectionBroker "SRV-RDS1.dominio.local"
Set-RDLicenseConfiguration -LicenseServer "SRV-RDS1.dominio.local" -Mode PerUser -ConnectionBroker "SRV-RDS1.dominio.local"

Nota de compatibilidade: as CAL são por versão — CALs de uma versão anterior não servem para Session Hosts de uma versão posterior (CALs 2022 não abrem um Session Host 2025. CALs 2025 abrem versões anteriores), e o licensing server tem de ser igual ou mais recente do que as CALs que instala.

5. Coleção e publicar um RemoteApp

A coleção é a unidade que agrupa os Session Hosts e define quem lá entra. Pelo Server Manager: Remote Desktop Services → Collections → Tasks → Create Session Collection, nome (exemplo: AppsLegados), selecionar o RD Session Host, definir os User Groups — este é o controlo de visibilidade: na collection com um user group próprio, só quem lá está vê as apps — quem está fora do grupo não vê nada — e o caminho UNC do share para os user profile disks. No fim, Create. Depois publicar: dentro da coleção, RemoteApp Programs → Publish RemoteApp programs, escolher o executável e Publish.

Em PowerShell, a mesma operação com dois cmdlets. A coleção:


New-RDSessionCollection -CollectionName "AppsLegados" -SessionHost @("SRV-RDS1.dominio.local") -CollectionDescription "Apps legadas" -ConnectionBroker "SRV-RDS1.dominio.local"

E a app — o exemplo da documentação publica o Notepad com New-RDRemoteApp -CollectionName "Session Collection" -DisplayName "Notepad" -FilePath "C:\Windows\System32\Notepad.exe". Na app legada, o caminho aponta para o executável instalado no Session Host e o -UserGroups restringe quem a vê:


New-RDRemoteApp -CollectionName "AppsLegados" -DisplayName "Cliente ERP" -FilePath "C:\Apps\ERP\ERP.exe" -UserGroups "DOMINIO\UtilizadoresERP"

Instala primeiro a app legada no Session Host — é aí que ela corre. Numa coleção de sessões, os utilizadores ligam-se com contas não administrativas. Os ícones aparecem no RD Web ou nos feeds configurados nos clientes. Regra prática para começar: uma app por RemoteApp publicado, displayName claro, e os grupos de utilizadores ao mínimo antes de abrir a mais gente.

6. No cliente: .rdp e o web client HTML5

Do lado dos utilizadores há duas formas de consumir RemoteApps. A tradicional: abrir o portal RD Web (https://SRV-RDS1.dominio.local/RDWeb/), iniciar sessão com a conta de domínio e lançar a app — o portal lança-a no cliente nativo do Remote Desktop do dispositivo, em janela própria. Os ícones publicados podem também distribuir-se como ficheiros .rdp para os postos de trabalho, que abrem no mstsc.exe de qualquer Windows.

A moderna é o web client, o cliente HTML5 que corre no browser — nada de instalar, só o URL do web client que o admin distribui. Requisitos: um PC com Windows, macOS, ChromeOS ou Linux (os telemóveis não são suportados por agora) e um browser moderno como o Edge, o Chrome, o Safari ou o Firefox (v55.0 ou superior). Dentro da sessão, o web client imprime via PDF (Remote Desktop Virtual Printer), transfere ficheiros até 255 MB (Remote Desktop Virtual Drive) e copia apenas texto (única função suportada por agora).

O web client exige Gateway e CALs per user

A montagem do web client pede RD Gateway, RD Connection Broker e RD Web Access no deployment, e CALs per user em vez de per device — as per device esgotam-se com os ícones do web client. A doc ainda lista "Windows Server 2016 ou 2019" nos pré-requisitos; as versões posteriores não estão excluídas, mas o requisito documentado ainda não foi actualizado. Verifica o modo na secção 4 antes de o ligar aos utilizadores.

Instalação do web client (no servidor RD Web Access, PowerShell elevado — cmdlets do módulo RDWebClientManagement da documentação): o certificado do broker exportado como .cer, o módulo instalado da PowerShell Gallery, o pacote descarregado e o cliente publicado:


Install-Module -Name RDWebClientManagement
Install-RDWebClientPackage
Import-RDWebClientBrokerCert .\RD-Broker.cer
Publish-RDWebClientPackage -Type Production -Latest

O cliente fica acessível em https://SRV-RDS1.dominio.local/RDWeb/webclient/index.html — o nome usado no URL tem de ser o do certificado público do RD Web Access. Para redes exteriores, é o RD Gateway que faz o túnel HTTPS (TCP 443 entrada + UDP 3391). Por baixo, a regra é simples: nunca exponhas o 3389 à internet — o acesso sai pelo Gateway ou por VPN.

7. A ponte com o hardening de RDP

RDS é RDP com mais gente a dentro: os mesmos vetores de ataque e a mesma disciplina do RDP: Hardening no Windows Server — SO e Firewall aplicam-se aqui na íntegra. Em resumo, as camadas que têm de vir do artigo de hardening: NLA activo (autenticação antes da sessão existir), regras de firewall com origem restrita (o RDS não abre a porta para toda a gente), acesso exterior pelo RD Gateway no 443 ou por VPN — a própria documentação dos roles lembra que o Gateway existe para dar RDP encriptado e seguro em HTTPS (TCP 443) vindo de fora, sem abrir as portas de RDP internas — e a segmentação por user groups que este guia usa na coleção. A doc do RDS remata a ideia: as collections e os security groups ajudam a impor segmentação de privilégio mínimo.

A regra que não se negoceia

Nenhum RemoteApp compensa um 3389 aberto à internet. O caminho exterior é RD Gateway (443) ou VPN. A porta de RDP não sai do perímetro. O MFA integra-se no RD Gateway — a doc lista o suporte a conditional access e MFA — usa-o ao menos para quem entra de fora.

8. Troubleshooting básico

Os problemas apanham-se sempre no mesmo trio: licenças, sessões e visibilidade. O primeiro diagnóstico é saber o que o deployment acha da própria configuração:


Get-RDSessionCollection -ConnectionBroker "SRV-RDS1.dominio.local"
Get-RDRemoteApp -CollectionName "AppsLegados"
Get-RDLicenseConfiguration -ConnectionBroker "SRV-RDS1.dominio.local"
Sintoma Causa provável Remédio
Utilizadores não conseguem entrar e o servidor fala de graça/licenças A graça de 120 dias acabou ou as CALs não estão activas Activar o RD Licensing Manager (443), instalar as CALs e aplicar o modo com Set-RDLicenseConfiguration, e confirmar com Get-RDLicenseConfiguration
CAL per user não contam os utilizadores Em per user o licensing não é imposto e o rastreamento depende de AD Relatórios do RD Licensing Manager, e sem AD, mudar para per device (workgroup não aceita per user)
Sessões desligam-se sozinhas ao fim de X Time limits na GPO do Session Host (Session Time Limits) — as inactivas/desligadas são cortadas Verificar as políticas de Session Time Limits na GPO e os limites por coleção (ver hardening de RDP para os caminhos)
A app não aparece a um utilizador User groups da coleção ou do RemoteApp Confirmar o grupo no New-RDRemoteApp/-UserGroups ou no Publish RemoteApp do Server Manager
Web client: «unexpected server authentication certificate was received» O certificado do RD Connection Broker foi renovado e o web client ficou com o antigo Re-exportar o .cer, correr Import-RDWebClientBrokerCert e Publish-RDWebClientPackage -Type Production -Latest
Ficheiro grande não passa no web client Limite de transferência de 255 MB do Remote Desktop Virtual Drive Usar a rede normal ou um share — o web client não é canal de movimentos pesados

Para o estado das sessões dos utilizadores, o Server Manager mostra as ligações por coleção em Remote Desktop Services → Collections → <coleção> → Connections. Eventos de ligações aparecem no Event Viewer em Microsoft-Windows-TerminalServices-RemoteConnectionManager. E quando algo quebra de propósito, o log a seguir é o System do TermService — os padrões de falha de RDS (deadlock de actualização: o 20498 no RemoteConnectionManager/Admin e o 6005 do provider Winlogon no System) já foram tratados em pormenor no artigo dos updates de Setembro listado nos Artigos Relacionados.

Artigos Relacionados

Fontes Oficiais