Microsoft Remote Desktop for Mac - Copy and paste works a while then fails
Using Mac OS X 12.6.8 and Remote Desktop 10.9.2. Beginning two versions back (10.9.0?), copy and paste works for a while after launching RD, but it eventually fails when copying from the remote machine to the local Mac. The failure manifests as a spinning beach ball in the application I'm pasting into. The paste operation eventually times out, but the quickest way to recover is to quit Remote Desktop and start the whole operation over again with the copy.
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).AI-900: Microsoft Azure AI Fundamentals Study Guide
This comprehensive study guide provides a thorough overview of the topics covered in the Microsoft Azure AI Fundamentals (AI-900) exam, including Artificial Intelligence workloads, fundamental principles of machine learning, computer vision and natural language processing workloads. Learn about the exam's intended audience, how to earn the certification, and the skills measured as of April 2022. Discover the important considerations for responsible AI, the capabilities of Azure Machine Learning Studio and more. Get ready to demonstrate your knowledge of AI and ML concepts and related Microsoft Azure services with this helpful study guide.
Microsoft RDP client with macOS Sonoma experiences audio input disconnects
I'm having issues after upgrading to Mac OS Sonoma with audio disconnecting when using MS RDP to access a Windows PC and use Teams. When I initially connect to Teams, audio input and audio output is working correctly. After a few minutes, Teams will report audio device microphone is disconnected or not working and then no-one can hear me speak. I can still hear them, but they can't hear me. If I leave the meeting and re-join it works again for a few minutes and then the same issue happens again. Please fix ASAP.
Workspace is deleted each time MS Remote Desktop quits
Currently I'm working with MS Remote Desktop for macOS Beta 10.9.2 (2147) to use customer workspace. I've left all preferences at default and only configured the workspace user. Each time I quit the app the workspace is deleted and I have to set up again. With previous (beta) versions (i.e. 10.9.0) I did not have similar problems.
Support Live Session Migration for Windows 11 Enterprise Multi-Session AVD Hosts
Description Azure Virtual Desktop administrators regularly encounter maintenance scenarios where a Windows 11 Enterprise Multi-Session session host must be removed from service to apply urgent patches, investigate platform issues, replace a host, or perform emergency maintenance. The current approach requires placing the session host into drain mode and waiting for active user sessions to disconnect or forcing user logoff, which can disrupt productivity and user experience. It would be valuable if Azure Virtual Desktop supported live migration of active user sessions between Windows 11 Enterprise Multi-Session hosts within the same host pool, similar to the way virtual machine live migration minimises downtime during infrastructure maintenance. This capability would allow administrators to move active sessions from one session host to another without requiring user disconnection or application interruption. This feature would provide significant operational benefits, including: Reduced user disruption during planned and emergency maintenance. Faster remediation of unhealthy or degraded session hosts. Improved patching and update operations. Reduced dependency on large maintenance windows. Improved service availability for business-critical AVD environments. Better support for future hot patching and rolling maintenance scenarios. While Windows 11 Enterprise Multi-Session differs significantly from Windows Server and traditional VM live migration technologies, the ability to seamlessly relocate active user sessions between healthy hosts in a host pool would be a major enhancement for enterprise Azure Virtual Desktop deployments operating at scale.Azure Front Door: Resiliency Series â Part 3: Tenant isolation
Abhishek Tiwari, Vice President of Engineering, Azure Networking Amit Srivastava, Partner Director of PM, Azure Networking Varun Chawla, Partner Director of Engineering, Azure Networking Azure Front Door serves hundreds of thousands of tenants from hundreds of edge locations, densely sharing the globally distributed edge fleet. That density is exactly what allows us to deliver global scale, performance, and cost efficiency. It also means that, without strong isolation, a single tenantâs incompatible configuration or anomalous traffic can, in the worst case, affect many other tenants. The October 2025 incidents reinforced how important it is to contain this class of risk. Our goal for this tenant isolation is simple to state and hard to achieve: no single tenantâs configuration or traffic should be able to impact any other tenant. In Part 1 of our three part mini blog series, we outlined our fourâpillar strategy for improving the resiliency of Azure Front Door: configuration resiliency, data plane resiliency, tenant isolation, and accelerated Recovery Time Objective (RTO). Part 1 detailed how we would make configuration propagation safer and how the data plane keeps serving from a âlastâknownâgoodâ (LKG) configuration, even if an incompatible configuration change is propagated to the data plane. Part 2 turned to recovery, showing how we bring the system back to full operation in an accelerated, predictable, and in a bounded timeframe. In this final part, we turn to the tenant isolation pillar that ensures that any single tenant configuration or traffic issues are limited in scope to that tenant alone and do not impact other tenants. We will also show how Azure Front Door achieves single-tenant containment through configuration isolation, lazy loading, and a micro-cellular layered ingress-sharding architecture. Repair status: all outstanding items now complete Before we dive into tenant isolation, here is a final update on the overall repair items from the two October 2025 incidents (you can review the details in our Azure Incident Retrospective sessions for the October 9th and October 29th incidents). We are pleased to report that all outstanding work across every pillar is now complete and fully deployed in production â including the tenant isolation work described in this post. With these safeguards in place, we have also returned configuration propagation latency to preâincident levels while keeping platform stability our top priority. In the table below, âCompletedâ means broadly deployed in production. Learning category Goal Repairs Status Safe customer configuration deployment Incompatible configuration never propagates beyond âEUAP or canary regionsâ Control plane and data plane defect fixes; forced synchronous configuration processing; additional stages with extended bake time; early detection of crash state Completed Data plane resiliency Configuration processing cannot impact data plane availability Manage dataâplane lifecycle to prevent outages caused by configurationâprocessing defects; isolated workâprocess in every data plane server to process and load the configuration Completed 100% Azure Front Door resiliency posture for Microsoft internal services Microsoft operates an isolated, independent Active/Active fleet with automatic failover for critical Azure services Phase 1: onboarded critical services batch impacted on Oct 29th outage running on a dayâold configuration; Phase 2: automation & hardening of operations, autoâfailover and selfâmanagement of onboarding for additional services Completed Recovery improvements Data plane crash recovery in under 10 minutes Data plane bootâup time optimized via local cache; recovery time accelerated to under 10 minutes Completed Tenant isolation No configuration or traffic regression can impact other tenants Microâcellular Azure Front Door with ingress layered shards Completed Why isolation at edge scale is deceptively hard Traditional isolation techniques such as dedicating separate hardware to each tenant or running every tenant inside its own virtual machine are impractical at the edge. Edge sites are constrained on space, power, and capacity. The entire premise of a modern, multi-tenant application delivery platform is that any tenant can be served from any site closest to the user. We cannot simply partition hundreds of thousands of tenants onto dedicated machines without giving up either proximity, scale, or the efficiency that make the edge fast and cost efficient. Isolation therefore, must be achieved in software, inside a multi-tenant fleet. What we already do today Azure Front Door already includes several layers of tenant isolation and partitioning. However, the incidents in October clearly highlighted that these techniques were not enough. Prior to the incidents, our protection mechanisms included: Infrastructure partitioning. Edge sites were organized into physically isolated primary and fallback traffic rings. Noisyâneighbor protection. Fairâshare resource allocation, rate limiting, and anomaly-based load protection kept any single tenant from monopolizing shared resources such as CPU, memory, or network bandwidth on an Azure Front Door server. Circuit breakers. Circuit breakers shed costly work first and can disable a risky perâtenant feature before it exhausts shared resources on a server. Realâtime crash protection. A crashâanalysis system correlates crash signatures across machines and can pinpoint and block crash patterns caused by tenant IPs or traffic patterns. While these protections are valuable, many of them are reactive and proved insufficient during the October incidents. The next generation of isolation makes singleâtenant containment a fundamental part of the platform which governs how configurations are loaded, and how traffic is served. Configuration isolation: loading only what is needed Part 2 introduced âlazy loadingâ as a recovery optimization technique. It is also an important configurationâisolation mechanism. Historically, every worker on every edge server had to be ready to serve any tenant, which meant each worker loaded a large set of tenant configurations. A single incompatible configuration could therefore ripple across many workers. With lazy loading, a worker loads a tenantâs configuration and its TLS certificates only when it actually receives traffic for that tenant. The practical consequence for isolation is powerful: a faulty configuration can only affect the workers that have loaded that specific tenant, never the entire server or fleet. Combined with perâtenant validation on load, and the Food Taster safeguard from Part 1 (a sacrificial process that pretests every configuration change in isolation), configuration problems are caught early and contained to the smallest possible footprint. Figure 1: With lazy loading, an incompatible configuration is contained to the workers serving that tenant, instead of poisoning the whole server. Tenant isolation: a micro-cellular, layered ingress sharding architecture Configuration isolation limits the blast radius of an incompatible configuration. Traffic isolation addresses the other half of the problem: a tenant whose anomalous traffic incident, like a sudden surge, a pathological request pattern, or malicious activity, could degrade a shared worker. Our approach is a microâcellular architecture that combines multiple concepts working together. Workerâprocess isolation. Each edge server already runs many independent worker processes. Instead of letting every worker serve every tenant, we assign tenants to specific groups of workers. Those worker group (shards) become the unit of isolation: if a tenant destabilizes its shard, the impact is contained to that shardâs workers while the rest of the server keeps serving normally. Ingress sharding. Rather than a handful of fixed shards, we compose shards from overlapping subsets of a serverâs workers. Even a modest number of workers can be combined into an enormous number of distinct, overlapping shards â giving us a very large number of fineâgrained fault domains without dedicating hardware to every tenant. Figure 2: Tenants are randomly assigned to different shards on each server (layer). Even when a good tenant shares the noisy tenantâs shard on one layer, routing steers its traffic to healthy shards on the others. Multiâlayer ingress sharding. This is where âlayeredâ comes in. Each edge server is treated as an independent layer, and each tenant is assigned to a different, randomly chosen shard on every server. Because assignments are independent from one server to the next, two tenants that happen to share a shard on one server are extremely unlikely to share a shard again on another server. The chance of any good tenant repeatedly colliding with a noisy tenant across many servers becomes vanishingly small. Intelligent ingress routing. Tying it together is a routing layer that terminates each incoming connection, identifies the tenant, and steers the request to that tenantâs assigned, healthy shard. If a shard is unhealthy or saturated, traffic is directed to the tenantâs healthy shards on other layers. Figure 3: Intelligent Ingress Routing The combined effect is that when a noisy tenant overwhelms or crashes its shard on one server, only that shard is affected. Because every other tenant is spread across a different, randomized set of shards, they continue to find healthy paths, and the routing layer moves their traffic accordingly. A worst-case availability problem is downgraded to, at most, a small and redistributable capacity problem, that the routing layer smooths over. An in-depth technical analysis of layered ingress sharding is available here for reference. Shrinking the blast radius Taken together, these mechanisms fundamentally change the shape of failure. In a uniform, fully shared fleet, an incompatible tenant can, in the worst case, affect a large share of the tenants on a machine, in an edge location, or beyond. With configuration isolation and layered ingress sharding, the same failure is confined to a subset of workers serving the offending tenant. Our target for this tenant isolation pillar is effectively singleâtenant containment: a configuration or traffic anomaly caused by one tenant should never cause issues to any other tenants. Figure 4: From a shared fleet where a single tenant can affect many, to microâcellular shards that confine impact to the offending tenant. Validating isolation in practice As with our recovery work, we donât simply design these boundaries and assume they hold, we test them. Through deliberate faultâinjections, we have pushed noisy and faulty tenants into the system and confirmed that impact stayed contained to the offending shard, that healthy tenants kept serving, and that the routing layer steered around unhealthy shards as intended. This turns isolation from a design claim into a well-drilled, and repeatable outcome. Closing This post concludes our three-part mini blog series on Azure Front Door resiliency. We have shared how we are making configuration propagation safer (Part 1), recovering faster when failures do occur (Part 2), and containing the blast radius stemming from any single tenant through configuration isolation and a microâcellular, layeredâsharding architecture (Part 3). Resiliency, however, is not a project with an end date. It is an ongoing commitment. While this series concludes the blog series of our response to the October 2025 incidents, our investments in Azure Front Doorâs resiliency, isolation, and recovery will continue. As we make further improvements, we will keep sharing them with you. We deeply value our customersâ trust in Azure Front Door. We remain committed to exceeding expectations for security, reliability, and transparency.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
