Proposal: Dedicated Windows “Repair Companion” Device for Automatic Deep System Recovery
I’d like to propose a new hardware‑assisted recovery solution for Windows that would dramatically improve system reliability and reduce catastrophic failures caused by deep OS corruption. Today, Windows can repair many issues on its own, but certain types of corruption — such as servicing stack failures, broken WinSxS manifests, failed migrations, or damaged bootloaders — require offline repair or manual intervention. These situations often force users into time‑consuming troubleshooting or full reinstallations. My proposal is a dedicated, consumer‑friendly “Windows Repair Companion” device that connects to a home network and provides a trusted, isolated environment for deep system repair. This would be similar in concept to enterprise out‑of‑band management, but simplified and designed for everyday users. Key Features: • A small hardware device (similar in size to a Surface Dock or streaming box) that plugs into a router or PC. • Contains a hardened, read‑only repair OS and clean Windows recovery images. • Supports automatic network boot (PXE/UEFI) when a PC detects severe corruption or cannot boot normally. • Performs offline repairs: DISM, SFC, CHKDSK, servicing stack rebuilds, WinSxS restoration, bootloader repair, and update rollback. • Provides a true “push‑button restore” experience without requiring user technical knowledge. • Could leverage existing Surface recovery technology, secure boot chains, and cloud restore infrastructure. • Offers a new potential revenue stream for Microsoft while significantly improving Windows reliability. Benefits: • Makes Windows effectively unbrickable for most users. • Eliminates many catastrophic update failures and servicing issues. • Reduces support costs and frustration for consumers and small businesses. • Provides a clean, consistent recovery path across all OEM hardware. • Bridges the gap between consumer Windows and enterprise‑grade resilience. This device would give users peace of mind and provide Microsoft with a modern, hardware‑assisted recovery model that aligns with the direction of Surface and Windows Core OS technologies. Thank you for considering this idea — I believe it could meaningfully improve the Windows experience for millions of users.
Windows App - Account Picker During Startup
Windows App is showing additional improvements to the overall VDI experience. As an Architect working for a consulting company, I have multiple clients with AVD environments I have to log into. One of the major benefits of Remote Desktop is that when opening, the window provides visibility to all signed in accounts. With Windows App, when opening the application, I'm in the most recent account. To benefit us that work in multiple environments, allow us the capability to choose which account I want to work in when opening the application. If Windows App only has one account associated, it can default to that account. But if there are two accounts present, allow the user to choose which one they want to go into at the onset.Something is preventing you from using Windows App right now.
After being auto-updated from Windows App version 2.0.327.0 to version 2.0.328.0, some of our users can't launch their Windows App anymore and get an error message says: "Something is preventing you from using Windows App right now." Since there is no way to control the update process, we could only let our desk users use MSRDC instead, as a temporary solution. For the frontline users, I could only pray that this problem will not take place until weekend. If any Microsoft person sees this post, please let the Windows App team know about this and fix this problem ASAP.Frequent AVD Deployment Failures
Since June 2024, we have experienced occasional failures in AVD deployments. While most deployments succeed through adding session hosts to the host pool, there are instances where the deployment fails. Given this situation, we would like to request a change in behavior to reduce the burden of recreating AVDs when deployment fails.
Microsoft Remote Desktop for Mac repeatedly forgets Windows 365 workspace
In the last week or so, I have repeatedly had to re-add the workspace URL for Windows 365 (the "subscription URL" collected from windows365.microsoft.com) to Microsoft Remote Desktop for Mac. The issue started with the previous version of the app, but has continued to happen about once-a-day since installing the latest version (10.9.0 build 2140) from the Mac App Store. Every time the workspace is re-added, it needs to be reauthorized by signing in via OAuth again and any custom settings for the workspace need to be reconfigured. Is this a known issue or am I the lone recipient of this particular cosmic annoyance? 😂
Remote Desktop for Mac 10.9.4 often causes spinning wheel of death when copying from Windows machine
Starting in the last version or two, I frequently get the "spinning wheel of death" after using Remote Desktop for Mac to copy from the remote Windows client. This manifests when I switch back to the mac and try to switch to Slack -- Slack will be frozen for 30 seconds to several minutes with the colorful spinning pinwheel. Many people have been experiencing this issue, both recently and in the last several years: https://techcommunity.microsoft.com/t5/azure-virtual-desktop-feedback/copy-and-paste-from-microsoft-remote-desktop-to-mac-causes/idi-p/3947326 https://techcommunity.microsoft.com/t5/azure-virtual-desktop-feedback/microsoft-remote-desktop-for-mac-copy-and-paste-works-a-while/idi-p/3930905 https://learn.microsoft.com/en-us/answers/questions/565240/microsoft-remote-desktop-freezes-constantly-apple Please look into this, it's a productivity killer. And if there's anything I can grab for you that will help (like a snapshot of a process using the Mac activity monitor) please let me know. EDIT: I just attached a sample and spindump of Slack (the macOS process that gets the spinning wheel of death after copying text on the remote windows machine).Update 'Update-AzWvdSessionHost' cmdlet
Today via the PowerShell cmdlet 'Update-AzWvdSessionHost', an administrator can assign a user to a session host without the user being assigned to the applicationgroup. This can cause some confusion to administrators if they are able to perform this task as the user will not be able to see the host in the Windows App. The suggestion would be to either put in a check which denies the assignment if the user is not associated with the applicationgroup directly or indirectly via group association. Or, update the cmdlet to also add an assignment to the application group by adding a required parameter which would assign the user to the application group. It's a small tweak but it may help with the overall stability of the Desktop.Virtualization PowerShell stack. Thanks!
Fslogix. Add a command line to release the profile.
Hello. Add a command line with arguments to be able to release frozen folders in FSlogix. If you don't want to fix the problem, let me automate it myself. In large RDS installations, constant freezes and further duplication of local_%username% folders cause problems.
Zonas de Disponibilidade no Azure: Entendendo a Diferença entre Zonas Lógicas e Físicas
O que é o mapeamento de zonas do Azure (Zona Lógica vs Zona Física) No Azure, as Zonas de Disponibilidade (AZs) são agrupamentos de datacenters fisicamente separados dentros de uma mesma região. Cada zona possui infraestrutura independente - energia, refrigeração e rede - garantindo alta disponibilidade e resiliência. Porém, há uma distinção entre: Tipo de Zona Definição Zona Lógica Identificador exibido no portal do Azure (AZ1, AZ2, AZ3). Zona Física Grupo real de datacenters. O mapeamento entre lógica e física varia por assinatura O mapeamento entre zonas lógicas e físicas não é fixo. Isso significa que: AZ1 na assinatura A pode ser fisicamente igual à AZ3 na assinatura B. Sem verificação, você pode estar executando produção e DR na mesma infraestrutura física, anulando os benefícios da separação. Esse comportamento é intencional e inspirado no modelo da AWS, que também não garante consistência entre zonas lógicas em diferentes contas. Qual o objetivo desse design? A motivação por trás desse mapeamento dinâmico é: Distribuir a carga de consumo de forma mais eficiente entre os datacenters. Evitar hotspots e garantir resiliência operacional. Permitir flexibilidade de alocação conforme a capacidade física disponível. Esse modelo ajuda a balancear o uso da infraestrutura global, sem expor diretamente a topologia física aos clientes — o que também reforça a segurança e abstração da plataforma. Essa distinção é essencial: a zona lógica AZ1 em uma assinatura pode, na prática, ser a mesma zona física que a AZ3 em outra. Sem uma verificação adequada, o cliente pode acabar executando cargas de produção e de DR (Disaster Recovery) na mesma infraestrutura física, o que anula os benefícios esperados da separação entre zonas. Exemplo prático de risco Vamos considerar o seguinte cenário de um cliente: Produção: AZ1 e AZ2 em uma assinatura A DR: AZ3 em outra assinatura B, na mesma região O cliente acredita estar distribuindo suas cargas entre três zonas distintas. No entanto, ao verificar o mapeamento real, encontra a seguinte saída: [ { "logicalZone": "1", "physicalZone": "brazilsouth-az3" }, { "logicalZone": "2", "physicalZone": "brazilsouth-az1" }, { "logicalZone": "3", "physicalZone": "brazilsouth-az2" } ] Neste exemplo, a AZ3 lógica está mapeada para a AZ2 física, que já está sendo usada na produção. Ou seja, não há separação física real. Como verificar o mapeamento de zonas? Para evitar esse problema, é essencial verificar o mapeamento entre zonas lógicas e físicas em cada assinatura. Use o seguinte comando via Azure CLI: az rest --method get \ --uri "/subscriptions/<subscription-id>/locations?api-version=2022-12-01" \ --query "value[?name=='<region-name>'].{displayName: displayName,name: name,availabilityZoneMappings: availabilityZoneMappings }" \ -o json Substitua <subscription-id> e <region-name> (ex: brazilsouth) conforme necessário. Veja abaixo um exemplo de saída obtida no meu ambiente de laboratório, onde tenho duas assinaturas. Vou executar o mapeamento de zonas entre elas para a região Brazil South. Na primeira subscription 1 temos o seguinte mapeamento. Zona lógica: 1 – Zona Física: brazilsouth-az1 Zona lógica: 2 – Zona Física: brazilsouth-az2 Zona lógica: 3 – Zona Física: brazilsouth-az3 Na segunda subscription 2 temos o seguinte mapeamento. Zona lógica: 1 – Zona Física: brazilsouth-az3 Zona lógica: 2 – Zona Física: brazilsouth-az1 Zona lógica: 3 – Zona Física: brazilsouth-az2 Resumindo: Se minha estratégia de DR envolve o uso das zonas lógicas 1 e 2 na subscription 1, pois elas estão mapeadas fisicamente para as zonas AZ1 e AZ2, então, na subscription 2 destinada ao DR, devo utilizar a zona lógica 1 — já que, nessa assinatura, ela está mapeada fisicamente para a AZ3. Boas práticas Sempre verifique o mapeamento entre zonas lógicas e físicas antes de definir sua estratégia de DR. Evite assumir que AZ1, AZ2 e AZ3 representam zonas físicas distintas entre diferentes assinaturas. Considere utilizar regiões diferentes para DR quando a separação física for um requisito crítico. Documente e compartilhe o mapeamento com sua equipe de arquitetura e operações para garantir alinhamento e evitar riscos. Referência oficial Para mais detalhes, consulte a documentação oficial da Microsoft: https://learn.microsoft.com/en-us/azure/availability-zones/az-overview Comparing AWS and Azure regions and zones - Azure Architecture Center | Microsoft Learn
Certificates are cached too aggressively in RD Web Client
We use the https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-web-client-admin (Latest version 1.0.27) Normally it works really well, but then once a year we have to update our SSL Certificates. The problem is the Web Client likes to cache the old certificate and not get the latest certificate. This results in people getting the following error: Hitting F5, Ctrl F5 does not resolve this. The following are the instructions we have to give the AVERAGE USER to get them passed it: * Press F12 to open DEVTOOLS * Press F1 to open DEVTOOLS SETTINGS * Under Networking tick Disable Cache (while DevTools is open) * On the tab, refresh the page with F5. * Close the DevTools tab Luckily these instructions more or less work for every major browser. But I think you can see that no end user should have to do anything as crazy as this. This also makes the move towards certificates with a shorter life impossible. Can this please be looked into with urgency? (Note: I know this is the Azure Virtual Desktop Feedback, but It's what the feedback button in the web client links to. If there's a better place to provide this feedback please let me know)
