Windows App vs Cliente de Área de Trabalho Remota

Introdução

A Microsoft reorganizou seu portfólio de clientes de desktop remoto em torno do Windows App. O Cliente de Desktop Remoto da Microsoft baseado em MSI para Windows, também conhecido como MSRDC, atingiu o fim do suporte para ambientes de nuvem pública em 27 de março de 2026.

No entanto, o aplicativo do Windows não substitui todas as ferramentas de acesso remoto da Microsoft. As equipes de TI ainda devem distinguir entre desktops em nuvem, Serviços de Área de Trabalho Remota e conexões RDP diretas antes de mudar sua estratégia de clientes.

Qual produto Microsoft Remote Desktop você está usando?

sobreposição da Microsoft acesso remoto os nomes dos produtos são uma das principais razões pelas quais este assunto pode ser confuso. Antes de planejar uma migração, os administradores devem identificar cada cliente pela sua fonte de instalação, executável e tipo de conexão pretendido, em vez de confiar apenas no nome exibido para os usuários.

Aplicativo do Windows

O aplicativo Windows é o cliente unificado da Microsoft para Azure Virtual Desktop, Windows 365, Microsoft Dev Box e serviços de Remote Desktop ou conexões diretas de PC selecionadas. Está disponível no Windows, macOS, iOS e iPadOS, Android e Chrome OS, navegadores da web e Meta Quest, embora os recursos e funcionalidades disponíveis variem entre as plataformas.

Cliente de Área de Trabalho Remota da Microsoft para Windows

A aplicação MSI autônoma, também conhecida como MSRDC, foi projetada principalmente para conectar endpoints Windows a desktops em nuvem da Microsoft. Apesar de seu nome amplo, não foi destinada a ser um cliente de uso geral para feeds convencionais de Serviços de Área de Trabalho Remota ou conexões diretas de PC remoto.

Suporte para o cliente MSI terminou em ambientes de nuvem pública da Microsoft em 27 de março de 2026 Extensões temporárias permanecem em vigor para certos ambientes de nuvem soberana e Azure Virtual Desktop legados, portanto, os administradores devem confirmar o ambiente antes de removê-lo.

Aplicativo de Área de Trabalho Remota para Windows

O aplicativo Remote Desktop distribuído através da Microsoft Store era um produto separado que suportava recursos de nuvem, Remote Desktop Services e conexões diretas de PC. Ele atingiu o fim do suporte em 27 de maio de 2025 e não está mais disponível para novas instalações.

A Microsoft bloqueou posteriormente suas conexões com o Azure Virtual Desktop, Windows 365 e Microsoft Dev Box em 30 de setembro de 2025. Os Serviços de Área de Trabalho Remota e as conexões diretas de PC não foram incluídos nessa restrição, embora o aplicativo em si não fosse mais parte da estratégia de cliente de longo prazo da Microsoft.

Conexão de Área de Trabalho Remota, ou MSTSC

Conexão de Área de Trabalho Remota é o cliente clássico do Windows lançado através do mstsc.exe. Ele está embutido no Windows e se conecta diretamente a computadores remotos, máquinas virtuais e ambientes do Windows Server.

MSTSC é separado tanto do aplicativo Microsoft Store aposentado quanto do cliente MSI não suportado. A Microsoft continua a identificá-lo como a opção do Windows geralmente disponível para acesso remoto direto ao PC.

Qual é a linha do tempo de fim de suporte do cliente Microsoft Remote Desktop?

A transição ocorreu em etapas, portanto, as equipes de TI não devem tratá-la como um único evento de aposentadoria.

Data	Alterar	Impacto operacional
27 de maio de 2025	Aplicativo Remote Desktop da Microsoft Store chegou ao fim do suporte	Novas instalações não estavam mais disponíveis
30 de setembro de 2025	As conexões do aplicativo da loja na nuvem foram bloqueadas	Os usuários do Cloud tiveram que migrar para o aplicativo do Windows.
27 de março de 2026	Cliente MSI e cliente web legado chegaram ao fim do suporte em nuvens públicas	Usuários de nuvem pública devem usar o aplicativo Windows
28 de setembro de 2026	O suporte MSI estendido termina para o Azure Government, Azure operado pela 21Vianet e AVD Classic.	Esses ambientes precisam de seu próprio cronograma de migração

De acordo com o Microsoft Learn, a Microsoft não anunciou a mesma data de término do cliente web para o Azure Government ou o Azure operado pela 21Vianet. Os administradores devem confirmar o ambiente de nuvem de cada pool de hosts antes de aplicar o cronograma da nuvem pública.

Um cliente instalado pode continuar a ser iniciado após o término do suporte, mas as organizações não devem assumir compatibilidade contínua, serviços de segurança ou acesso confiável.

Windows App vs Cliente de Área de Trabalho Remota: Comparação

A tabela a seguir compara o Windows App com o cliente MSI autônomo.

Capacidade	Aplicativo do Windows	MSI Cliente de Área de Trabalho Remota
Função principal	Acesso unificado à nuvem Microsoft e recursos remotos suportados	Acesso legado a desktops em nuvem da Microsoft
Azure Virtual Desktop	Suportado	Não suportado em nuvens públicas desde 27 de março de 2026
Windows 365	Suportado	Não suportado em nuvens públicas desde 27 de março de 2026
Microsoft Dev Box	Suportado	Não suportado em nuvens públicas desde 27 de março de 2026
Feed RDS no Windows	Não suportado	Não suportado
Acesso remoto direto ao PC no Windows	Prévia	Não suportado
Acesso pelo navegador	recursos de nuvem da Microsoft	Cliente web legado não suportado em nuvens públicas
Plataformas	Windows, macOS, móvel, web e Meta Quest	Apenas Windows
Experiência da conta	Múltiplas contas de trabalho ou escola	Experiência anterior
direção da Microsoft	Cliente estratégico atual	Cliente legado

A matriz de recursos de aplicativos do Windows do Microsoft Learn também mostra as diferenças de plataforma em exibição, redirecionamento, autenticação, segurança e capacidades de rede. Teste o endpoint e a carga de trabalho reais em vez de confiar apenas no suporte a nível de produto.

O que o aplicativo Windows faz melhor?

O aplicativo Windows é mais do que uma versão renomeada do cliente de Área de Trabalho Remota anterior. A Microsoft o projetou para fornecer uma experiência de acesso comum para desktops em nuvem, PCs em nuvem, Dev Boxes e recursos remotos selecionados em várias plataformas de endpoint.

Uma Interface para Recursos de Nuvem da Microsoft

O aplicativo do Windows reúne recursos de Azure Virtual Desktop, PCs em nuvem do Windows 365 e Microsoft Dev Boxes em uma única interface. Os usuários podem pesquisar recursos, marcar desktops ou aplicativos frequentemente usados como favoritos e alternar entre contas de trabalho ou escolares.

Essa abordagem pode simplificar o acesso para consultores, administradores e provedores de serviços gerenciados que trabalham em vários locatários do Microsoft Entra. Também reduz a necessidade de manter um fluxo de trabalho de usuário diferente para cada serviço de nuvem da Microsoft.

Acesso Multiplataforma e Recursos Modernos

O aplicativo Windows está disponível nas principais plataformas de desktop e mobile, bem como através de navegadores da web suportados. Dependendo do endpoint e do serviço remoto, ele pode fornecer resolução dinâmica, suporte a múltiplos monitores, suporte a exibição externa, otimização de mídia do Microsoft Teams e redirecionamento para câmeras, áudio, armazenamento e impressoras.

No entanto, essas capacidades são não é idêntico em todas as plataformas O suporte a múltiplos monitores, recursos do navegador e redirecionamento de periféricos podem variar entre Windows, macOS, dispositivos móveis e clientes da web, portanto, os administradores devem testar o cenário completo do usuário em vez de assumir paridade total de recursos.

Implantação mais simples em dispositivos Windows gerenciados

As organizações podem implantar o aplicativo Windows em endpoints Windows gerenciados por meio do Microsoft Intune usando o modelo de aplicativo da Microsoft Store. Isso pode simplificar a instalação e as atualizações em comparação com a manutenção de um processo separado de empacotamento MSI e atualização.

A implantação centralizada não elimina a necessidade de testes de compatibilidade. O aplicativo do Windows pode ser instalado com sucesso, enquanto ainda carece de um tipo de conexão, recurso de exibição ou capacidade de redirecionamento exigida por um grupo específico de usuários.

Onde o aplicativo Windows não substitui os clientes RDP tradicionais?

O aplicativo Windows é o sucessor suportado para desktops públicos da Microsoft na nuvem, mas não substitui todos os fluxos de trabalho do Protocolo de Área de Trabalho Remota ou dos Serviços de Área de Trabalho Remota. Suas capacidades ainda dependem da plataforma de endpoint, do recurso remoto e da forma como esse recurso é publicado.

Serviços de Área de Trabalho Remota no Windows

A matriz de plataformas atual da Microsoft não suporta assinaturas de Serviços de Área de Trabalho Remota através do aplicativo Windows no Windows ou em um navegador. O acesso RDS está disponível através do aplicativo Windows no macOS, iOS e iPadOS, Android e Chrome OS, e Meta Quest.

Essa limitação afeta organizações que utilizam Hosts de Sessão RD locais, coleções RemoteApp, Acesso RD Web, Gateway RD ou fazendas RDS tradicionais do Windows Server. Dependendo da arquitetura, os administradores ainda podem precisar do MSTSC, RemoteApp e Conexões de Desktop ou outro cliente e gateway mantidos.

Conexões Remotas Diretas de PC

O acesso remoto direto ao PC continua sendo um recurso de pré-visualização no aplicativo do Windows. Quando as organizações precisam de um cliente Microsoft geralmente disponível para Windows, a Microsoft continua a recomendar o aplicativo de Conexão de Área de Trabalho Remota integrado.

Usuários que se conectam a estações de trabalho físicas, máquinas virtuais ou sistemas Windows Server, portanto, não precisam substituir o MSTSC simplesmente porque o suporte para o cliente MSI em nuvem foi encerrado. Os dois aplicativos atendem a diferentes tipos de conexão.

Acesso ao Navegador para Recursos Auto-Hospedados

A experiência da web do aplicativo Windows suporta Azure Virtual Desktop, Windows 365 e Microsoft Dev Box. Atualmente, não oferece acesso baseado em navegador a PCs remotos diretos ou ambientes convencionais de Serviços de Área de Trabalho Remota.

Organizações que precisam de acesso via navegador a aplicativos ou desktops Windows auto-hospedados requerem outro método de entrega. Um gateway de acesso remoto HTML5 ou a plataforma de publicação de aplicativos pode fornecer esse acesso sem exigir que os usuários instalem um cliente nativo.

Contas Microsoft Pessoais

O aplicativo do Windows requer uma conta de trabalho ou escola da Microsoft quando os usuários fazem login para acessar os recursos de nuvem da Microsoft. Uma conta pessoal da Microsoft não pode normalmente ser usada para esse processo de login padrão.

Os usuários ainda podem adicionar um PC remoto direto sem fazer login no aplicativo do Windows em plataformas que suportam esse tipo de conexão. Nesse caso, a autenticação ocorre contra o computador remoto em vez de através da conta na nuvem do aplicativo do Windows.

Windows App vs MSTSC: Qual Você Deve Usar?

O aplicativo Windows e o MSTSC resolvem problemas de acesso diferentes. O aplicativo Windows descobre recursos atribuídos por meio de serviços de nuvem da Microsoft, enquanto o MSTSC se conecta diretamente a um nome de host conhecido, nome de domínio totalmente qualificado ou endereço IP.

A escolha também depende de como o recurso remoto é gerenciado. O Windows App apresenta desktops e aplicativos atribuídos por meio de uma conta Microsoft Entra, enquanto o MSTSC depende dos detalhes de conexão inseridos pelo usuário ou armazenados em um arquivo .rdp.

Use o aplicativo do Windows quando	Use MSTSC quando
Os usuários se conectam ao Azure Virtual Desktop	Os usuários se conectam diretamente a um host Windows
Usuários acessam PCs Windows 365 Cloud	Administradores gerenciam sistemas Windows Server
Desenvolvedores usam Microsoft Dev Box	Os arquivos .rdp existentes continuam sendo importantes
Os usuários alternam entre locatários do Microsoft Entra	Um cliente RDP direto geralmente disponível é necessário

A mudança de suporte em março de 2026 diz respeito ao Cliente de Área de Trabalho Remota da Microsoft baseado em MSI, utilizado com recursos de nuvem da Microsoft. Isso não marca o fim do Protocolo de Área de Trabalho Remota, Serviços de Área de Trabalho Remota ou MSTSC.

As organizações podem, portanto, continuar usando ambas as ferramentas. O aplicativo do Windows pode atender usuários de desktop em nuvem, enquanto o MSTSC continua disponível para conexões diretas de estações de trabalho e servidores. As equipes de TI devem documentar qual cliente se aplica a cada recurso. Instruções claras ajudam os usuários a evitar abrir o aplicativo errado quando vários métodos de acesso remoto coexistem.

Como migrar do Cliente de Área de Trabalho Remota para o Aplicativo do Windows?

Uma migração confiável deve começar com as conexões nas quais os usuários confiam, em vez dos nomes das aplicações instaladas em seus dispositivos. Essa abordagem ajuda as equipes de TI a mover cargas de trabalho da nuvem da Microsoft sem interromper inadvertidamente o acesso direto RDP, Remote Desktop Services ou baseado em navegador.

Identificar Clientes Instalados

Comece inventariando o Cliente de Área de Trabalho Remota baseado em MSI, o antigo aplicativo da Microsoft Store, MSTSC, clientes de navegador, ferramentas RDP de terceiros e portais HTML5. As aplicações MSI e Store podem aparecer sob o nome "Área de Trabalho Remota", portanto, a fonte de implantação, o identificador do pacote e o caminho executável fornecem uma maneira mais confiável de distingui-los.

Esse inventário também deve mostrar quais usuários e dispositivos ainda dependem de cada aplicativo. Sem essa informação, as equipes de TI podem remover um cliente que continua a suportar uma conexão importante não baseada em nuvem.

Classificar Recursos Remotos

Mapeie cada conexão para o recurso que realmente alcança, como Azure Virtual Desktop, Windows 365, Microsoft Dev Box, Remote Desktop Services, um PC individual, Windows Server, um aplicativo publicado ou um espaço de trabalho baseado em navegador.

Essa classificação separa os recursos que pertencem à migração do aplicativo Windows daqueles que precisam de outra estratégia de cliente. Também ajuda a identificar usuários que dependem de vários tipos de conexão e podem precisar manter mais de uma ferramenta de acesso.

Mover Usuários da Nuvem Pública

Usuários acessando Azure Virtual Desktop, Windows 365 ou Microsoft Dev Box em ambientes de nuvem pública da Microsoft devem ser movidos para o Windows App. Durante a validação, confirme se os recursos atribuídos aparecem corretamente e se a autenticação do Microsoft Entra, o Acesso Condicional, o acesso à rede e o single sign-on se comportam conforme o esperado.

Os testes também devem abranger o uso da área de transferência, impressão, armazenamento, áudio, câmeras e qualquer outra redirecionamento necessário. Um desktop que inicia com sucesso pode ainda falhar em fornecer a experiência de trabalho completa que o usuário precisa.

Perfis de Representantes Piloto

Os grupos piloto devem refletir os requisitos técnicos em vez de incluir apenas um pequeno número de usuários de um único departamento. Inclua pessoas que usam vários monitores, impressoras, scanners, webcams, chamadas do Microsoft Teams, ferramentas de acessibilidade, várias contas organizacionais ou caminhos de rede restritos.

Windows, macOS, dispositivos móveis e navegadores devem ser testados separadamente porque os recursos do aplicativo Windows variam de acordo com a plataforma. Um piloto bem-sucedido do Windows 11 não valida automaticamente outro sistema operacional ou método de acesso.

Implantar aplicativo Windows centralmente

Use o Microsoft Intune ou outra plataforma de gerenciamento de aplicativos para criar atribuições separadas de piloto e produção. Defina o direcionamento, a propriedade de atualização, as regras de detecção, as comunicações de suporte e as condições que devem ser atendidas antes de remover o cliente MSI.

Um período temporário de coexistência dá às equipes de suporte tempo para validar o novo fluxo de trabalho e fornece aos usuários uma alternativa durante a migração. O cliente legado deve ser removido apenas depois que todos os recursos de nuvem necessários e o perfil do usuário tiverem passado nos testes.

Preservar Caminhos de Acesso Não Nuvem

Mantenha procedimentos documentados para PCs remotos diretos, administração do Windows Server, RDS local, feeds do RemoteApp, RD Gateway, ambientes de nuvem soberana e acesso de emergência. Esses fluxos de trabalho não devem ser removidos simplesmente porque o cliente MSI atingiu o fim do suporte para os serviços de nuvem pública da Microsoft.

Onde os usuários precisam apenas de um aplicativo de negócios, publicando um aplicativo do Windows pode também oferecer uma experiência mais focada do que apresentar um desktop remoto completo O método de acesso apropriado deve corresponder ao recurso em vez de seguir uma única política de cliente para cada caso de uso.

Atualizar Documentação

Instruções para o usuário devem nomear o aplicativo e o destino exatos em vez de dizer aos usuários para "abrir o Remote Desktop." Por exemplo, a documentação pode direcionar os usuários a abrir o aplicativo Windows para um PC na nuvem Windows 365, Conexão de Área de Trabalho Remota para um servidor ou um portal da web para um aplicativo de contabilidade publicado.

Nomenclatura clara reduz solicitações ao suporte técnico e facilita a distinção entre problemas do cliente e questões de host, identidade ou rede. As equipes de suporte também devem registrar nomes de pacotes, capturas de tela e procedimentos de escalonamento para cada método de conexão aprovado.

Qual Cliente de Área de Trabalho Remota Você Deve Usar em 2026?

O cliente apropriado depende do recurso remoto, sistema operacional do endpoint e modelo de gerenciamento. O aplicativo Windows é a opção principal para Azure Virtual Desktop, Windows 365 e Microsoft Dev Box, enquanto o MSTSC continua relevante para conexões diretas a PCs e servidores Windows.

Serviços tradicionais de Área de Trabalho Remota, RemoteApp e ambientes baseados em navegador requerem uma avaliação separada. Dependendo da arquitetura, as organizações podem precisar de um cliente RDS existente, um gateway HTML5 ou uma plataforma de entrega de aplicativos juntamente com o Windows App.

Requisito	Abordagem recomendada
Azure Virtual Desktop, Windows 365 ou Microsoft Dev Box	Aplicativo do Windows
Acesso remoto direto a PC ou servidor Windows a partir do Windows	MSTSC
Feed RDS tradicional do Windows	Fluxo de trabalho RDS suportado existente
Acesso remoto direto ao PC a partir do macOS, iOS ou Android	Aplicativo do Windows
Acesso ao navegador para desktops da nuvem da Microsoft	Experiência web do aplicativo Windows
Acesso ao navegador para recursos Windows auto-hospedados	Gateway HTML5 dedicado

A escolha final deve refletir o fluxo de trabalho de conexão completo, em vez do nome do cliente. As organizações podem precisar manter vários métodos de acesso quando desktops em nuvem da Microsoft, administração direta de servidores, RDS local e aplicativos Windows publicados coexistem.

Por que escolher o Acesso Remoto TSplus?

TSplus Acesso Remoto dá às organizações uma maneira prática de publicar aplicativos Windows e desktops completos a partir de seus próprios servidores. Os usuários podem se conectar através de um cliente RDP padrão ou um portal web HTML5, enquanto as equipes de TI mantêm o controle sobre a hospedagem, políticas de acesso, sessões simultâneas e a experiência geral do usuário.

Para empresas que não precisam da complexidade ou da estrutura de custos de uma plataforma de desktop em nuvem completa, nossa solução oferece uma alternativa mais focada. Ela suporta entrega segura de aplicativos, acesso baseado em navegador e administração centralizada, tornando-se bem adequada para PMEs, fornecedores de software e equipes de TI que desejam estender o acesso a ambientes Windows existentes.

Conclusão

O aplicativo Windows é o sucessor suportado pela Microsoft para Azure Virtual Desktop, Windows 365 e Microsoft Dev Box, mas não é uma substituição universal para todos os fluxos de trabalho de Remote Desktop. As equipes de TI devem migrar recursos em nuvem, reter clientes adequados para RDP e RDS diretos e testar recursos específicos da plataforma antes de remover caminhos de acesso legados.