Windows 365 or Azure Virtual Desktop: Choosing the Right Cloud PC Model

M365 FM - Windows 365 or Azure Virtual Desktop - Choosing the Right Cloud PC Model 00:00:00 Speaker: Most architects start this decision with a question which product is better? Windows three hundred sixty five or Azure Virtual Desktop? Pick one, defend it, and move on. But that question is the floor. Because the two products don't differ in the desktop, you see, they differ in who owns the control plane. That's the real choice, not a product, a management model. If you want more breakdowns like this on cloud PC decisions, subscribe to the M365 FM podcast. Today we cover cost management, scaling, networking, licensing, migration, and a decision framework you can actually use. But first, a short word from today's sponsor sponsor segment. Today's episode is supported by stellar Migrator for exchange. It's a migration tool built for the Microsoft ecosystem. It helps teams move mailboxes between exchange environments and into Microsoft three hundred sixty five. I'm mentioning it for a simple reason, not a sales pitch, because in practice, cloud PC projects never stand alone. They sit next to something else a mailbox migration, an identity cleanup, a tenant consolidation after a merger. The desktop is the visible part. The move underneath is where the weeks go. So when you plan a windows three hundred sixty five or Azure Virtual desktop rollout, ask what else is moving in the same quarter. Then check that your tooling for that move is ready. If your project touches exchange, look at what stellar Migrator can do for you. Learn what it covers, then decide if it fits. Now back to the core question. Theses two products one desktop. Two models. Open a windows three hundred sixty five cloud PC. You see a windows desktop start menu taskbar. Your apps. Now open an Azure Virtual desktop session. You see a windows desktop start menu, taskbar your apps. Same thing, same protocol family behind it. The user can't tell you which one they're on. So if the desktop looks the same, where does the difference hide in the operating model? That's where it breaks for most teams. They compare screenshots, feature tables and price sheets, and they miss the part that decides everything. Who runs the thing? After day one, let's start with windows three hundred sixty five. Windows three sixty five is a per user product. One person gets one cloud PC. You pick a size, you pay one monthly price. And that's the deal. Microsoft handles the machine life cycle. You assign it to a user and it appears. Think of it the way you think of a license. You buy it per head. That's the whole design. It's built to be simple on purpose. Azure Virtual Desktop is different. Not a little different. Structurally different. It's a platform. You build host pools. You sys session hosts. You decide whether users get personal desktops or share pooled machines running multi-session windows. You write scaling plans that start and stop machines. You build the image, you design the network, you monitor it, and you pay for all of it through your Azure bill. Compute, storage, networking, each one a line item, each one yours to watch. So here's what's actually happening with windows three sixty five. You buy an outcome, a PC for a person with Azure Virtual Desktop. You buy the parts and assemble the outcome yourself. Neither is wrong, but they assume different people. On the other end. One assumes a team that manages endpoints and wants fewer moving parts. The other assumes a team that manages infrastructure and wants control over every part. If you hand the wrong product to the wrong team, the product doesn't fail. The operation does. You've probably seen this. A platform gets bought by one group and then it lands on another group's plate. Nobody planned for it. Tickets pile up and six months later someone says, this product isn't working. It's not the product, it's the model behind it. So here's the thesis stated plainly choose the model that matches who runs the infrastructure and how work is shaped. Two parts who runs it and how work is shaped. Who runs it? Microsoft or your team. How work is shaped? Do people need steady personal desktops every day, or does demand move shift workers, seasonal teams, contractors who show up for eight weeks and leave? Those two questions will drive almost every answer in this episode. Here's how we'll work through it. Think of it as an architect's walk through seven dimensions cost management, scaling, networking, licensing, migration, and then one more. How to run either choice? Well, once it's live. Each dimension tests the same thing. Where does responsibility sit and does that fit your team? We end with a decision framework. Five questions, a simple scoring approach, and a default answer for each outcome. Then we test it against four real scenarios no product loyalty, no feature wars, just structure. But to compare these two properly, we need to know where each one came from because the origin explains the design, and the design explains everything else where each product came from. Start with Azure Virtual Desktop. It didn't appear out of nowhere. It grew out of Remote Desktop Services, the technology that has run session based desktops on Windows Server for decades. If you've ever built an RDS farm, you know the shape of it. Connection brokers, gateways, session hosts, licensing servers, a lot of servers, and a lot of care. In twenty nineteen, Microsoft took that lineage and moved the brokering pieces into Azure. It was called Windows Virtual Desktop. Then later it was renamed Azure Virtual Desktop. And the new name tells you something Azure first, desktop second. That order matters because the design started with infrastructure. The question Microsoft answered was, how do we take the hard parts of a remote desktop farm and run them as a cloud service while the customer keeps control of everything else? Control was the point. So you still build the pools, you still choose the machines, you still own the image and the network. Now look at windows three sixty five. It arrived in twenty twenty one and it asked a different question entirely not how do we host your desktop farm? But why does anyone need to know there is a farm? Windows three sixty five is software as a service. Microsoft hides the infrastructure. There's no host pool to design, no scaling plan to write, no session host to patch. You buy a PC in the same way you'd buy a seat in any other subscription product. The machine exists because a user exists. Same company. Same cloud. Opposite starting points. So why build two? Because there are two kinds of buyers. One buyer runs infrastructure. They have Azure engineers networking skills and a habit of tuning things. They want control, and they accept the work that comes with it. For them, a platform is a feature. The other buyer runs endpoints. They manage laptops, push apps through Intune, and answer help desk tickets. They don't want to run a farm. They want a PC that happens to live in the cloud. For them, a platform is a burden. Microsoft looked at both and decided one product couldn't serve them well. A platform that exposes every knob is too heavy for the endpoint team. A simple per user product that hides every knob is too limited for the infrastructure team, so it built both. That's the structural reason. Different buyers, different assumptions about who does the work. And here's what makes the comparison tricky. The overlap is real. Both run on Azure. Both deliver the desktop through remote protocols in the RDP family. Both can sit behind the same identity layer, and both can be managed with some of the same tools. A user connecting from the same laptop on the same network would have a hard time telling them apart. That's why so many teams compare them the wrong way. They see the shared plumbing and assume the products are two versions of one idea, one cheaper, one more powerful. Pick by budget. But shared plumbing is not a shared model. Think about what each product assumes when something breaks or when demand doubles, or when a manager asks why the bill changed. The answers differ because the origin differs. One was built to be assembled, the other was built to be assigned. So let's stop talking about history and open the architecture. Let's look at what each model actually exposes and what it quietly keeps from you. The control plane divide. Every remote desktop service has a control plane. It's the layer that decides who connects to what and through which door. Nobody sees it, but it's where the two products split. start with Azure Virtual Desktop. Microsoft runs three things for you the broker, which matches a user to a session host, the gateway which carries the connection in from the internet and the web access layer, the front door where users sign in and see their desktops. Those pieces are managed. You never patch them, you never size them, and you never get a call at two in the morning because one went down. That's the full list. Everything else is yours. So what does yours mean in practice? Host pools. First you decide how many, what type and how users land in them. Then the images you build, the golden image. You update it. You own what's inside it. Then scaling. The machines don't start and stop themselves until you write the plan that tells them to. Then the network the session hosts sit in your virtual network, in your subscription behind your rules, then profiles most pool designs. Lean on fslogix to roam the user's profile between machines, and you build and tune that storage and finally monitoring. Nobody watches your host pools unless you set up the eyes. Notice the pattern. Microsoft keeps the part that routes people. You keep the part that holds them. Now flip to windows three sixty five. Here Microsoft runs nearly the whole stack. The brokering the gateway, yes, but also the virtual machine itself. It creates the cloud PC. It provisions it. It handles the life cycle from first boot to reprovision to removal. You don't pick a hypervisor host, you don't see a session host. There isn't one to see. So what's left for you? Less, but not nothing. You still choose the image, whether that's a gallery image from Microsoft or a custom one you've prepared. You still own the policies, the Intune settings that decide how that cloud PC behaves and what it's allowed to do. You still own user assignment, who gets a cloud PC and which size, and you own the network, but only if you choose that path. Pick a Microsoft hosted network and even that goes away. Pick your own virtual network and you take the responsibility back along with the control. That choice is worth pausing on because it shows the same trait at a smaller scale. Every time you take control of a piece in windows three sixty five, you also take the work that comes with it. Control and labor arrive together. They always do. So line the two up in Azure Virtual Desktop. Microsoft owns the routing and you own the platform underneath. In windows three sixty five, Microsoft owns the platform and you own the settings on top, the line between theirs and yours sits in a different place. That line is what I mean by the model. Not the feature list, not the logo. The model is the answer to a plain question. When something has to be decided, built, patched, or watched, whose job is it? And this is the part teams skip. Every later decision in this episode hangs off that line. Cost depends on it because you pay for the parts you assemble. Scaling depends on it because someone has to write the rules that add and remove capacity. Networking depends on it. Security depends on it. Even migration depends on it, because moving a desktop means moving whoever was responsible for it. If the line sits where your team skills sit, the product feels easy. If it doesn't, the same product feels like a job nobody applied for. So the model isn't a footnote to the architecture. It is the architecture. Now, there's one place where this stops being abstract and becomes very concrete. Finance sees it before anyone else does, because the first time responsibility shows up as a number is on the bill. Cost models explained, fixed versus consumed. Let's start with windows three hundred sixty five, because its bill is the easier one to read. You pick a cloud PC size. That size is a bundle, a set number of virtual CPUs, a set amount of memory and a set amount of storage, two vcpus and eight gigabytes of RAM. Say with one hundred and twenty eight gigabyte disk or four Vcpus, sixteen gigabytes, and two hundred and fifty six on the disk. Each bundle has one monthly price per user. You assign it and the price attaches to the person. That's it. No second line for storage, no third line for the network path. One number per head per month. Now Azure Virtual Desktop. Here the bill breaks into parts and each part is metered on its own. Compute the virtual machines charged for the time they run. Storage the OS disks plus the file shares that hold user profiles, networking traffic that leaves Azure, and any gateways or links you build and licensing which sits underneath all of it. The right to run windows for your users comes from licenses you may already own, and the ones you don't own show up as another cost. Layer four buckets, four metres, all of them yours to watch. So both products have a price but they price different things. Windows three hundred sixty five prices as a person. Azure Virtual desktop prices a resource. One asks how many users do you have? The other asks. How much did you consume this month? And that difference isn't a flaw in either. It's the design working as intended. Take the windows three hundred sixty five price first. It's predictable by design. If you have three hundred cloud PCs at a known size, you can tell your finance team the monthly number before the quarter starts. It won't move because someone ran a heavy job on a Tuesday. It won't move because a manager forgot to shut something down. For a finance team, that's the whole value. A budget line that behaves like a subscription because it is one. Now, the Azure Virtual desktop price, it's variable by design. A machine that's off doesn't bill for compute. A pool that shrinks at night costs less at night. A team that works nine to five five days a week doesn't pay for the other hours. For a team with uneven demand, that's the whole value. You pay for what you use, and you can shape what you use. But notice the catch in each one. Predictable means you pay the same whether the user connects or not. The cloud PC is yours and the meter runs on the license, not on the clock. Variable means the bill follows your discipline, right? A good scaling plan and it falls. Skip it and machines idle at full price while nobody notices. So each model hands you a bargain, and each bargain has a price of its own. Here's where it gets misleading most cost comparisons in the wild go like this someone takes the windows three hundred sixty five list price one clean number, and sets it next to an Azure Calculator estimate for Azure Virtual Desktop. Then they compare the two totals and declare a winner. That comparison breaks and it breaks in a few places. First, the two numbers measure different things. The list price is a finished product. The calculator estimate is a sum of parts you chose with assumptions you typed in how many hours the machines run, how many users share each one, how big the profile storage is. Change one assumption and the answer moves the list price has no assumptions to change. Second, the calculator only knows what you tell it. It doesn't know about the monitoring workspace you'll add later. It doesn't know about the image pipeline or the engineer who maintains it. It prices the infrastructure and stops there. Third, the list price hides its own gap. It assumes the cloud PC is the right size and the right count. If half your users connect twice a month, that flat price is mostly paying for silence. So the honest comparison isn't price against price, it's the cost of a model against the cost of a workload. You have to know how your people actually work before either number means anything. Which brings us to the real question. Not which one is cheaper, but where does the cost curve actually cross the break even point? Start with the simplest user. One person, one desktop always on. They log in at eight, work through the day, log off at five, and do it again tomorrow. Their machine is theirs, their files, their settings. Nobody else touches it. For this user, windows three sixty five often wins on simplicity. Always. Sometimes it wins on cost two. And here's why. To give that same person a personal desktop. On Azure Virtual Desktop, you build a personal host pool, run one virtual machine per user, and pay for compute, disk, and profile storage on top. You've rebuilt the cloud PC by hand, and you've added the work of keeping it alive. So when demand is flat and personal, the flat price tends to hold its own. Now change the shape of the work. Take thirty users who all do the same job on the same apps, with no need for a machine of their own. This is where Azure Virtual Desktop pulls ahead. Pooled Multi-session windows lets many users share one virtual machine. Not one user per machine. Several. Maybe six, maybe ten, depending on the workload. Do the math on that. If one machine carries eight users, you're not paying for eight machines. You're paying for one plus a little extra headroom. The cost per user falls fast, and windows three sixty five can't do that. One person, one cloud PC, one price. There's no sharing inside the model. So what decides which side you land on utilization? That's the variable, not the product, not the logo. How hours per day, days per month, and concurrency line up against each other. Concurrency means how many people are connected at the same moment. A pool of two hundred users where only sixty are ever online together needs capacity for sixty, not two hundred. Let's walk through one example round numbers, and I want to be clear this is illustrative. These are not real Microsoft prices. Check the current price sheets before you trust any of it. Say a cloud PC of a given size costs sixty dollars per user per month flat. Now say you have one hundred users and you want to host them on Azure Virtual Desktop. In a pooled design, assume each session host costs four hundred dollars a month. If it runs around the clock and carries ten. Users assume profile, storage and other supporting pieces. Add another eight hundred dollars a month for the whole pool. If those machines run all day and all night, you need ten of them. That's four thousand dollars plus eight hundred. Call it four thousand eight hundred against six thousand for the cloud PCs closer than people expect and a bit cheaper. Now add a scaling plan. Most of those users only work business hours. Cut the runtime by half. The machine cost drops to two thousand. Add the eight hundred. Now you're at two thousand eight hundred against six thousand, and the gap keeps opening as you share more users per machine and run fewer hours. But flip it. Put one hundred users in a personal design, one machine each, always on. Now the machine cost alone is forty thousand a month, and windows three sixty five looks very cheap indeed. Same users, same desktop. The model changed the number, not the product. Now here's the cost that most teams miss. It isn't on either bill. It's labor. The pooled design that saved you three thousand dollars a month needs someone to build the host pool, write the scaling plan, maintain the image, patch it, watch the profile storage, and answer the ticket when a login takes 90s. That's engineering time. If it takes half of one engineer and that engineer costs more than three thousand a month, the savings are gone. They just moved from one column to another. Windows three sixty five hides most of that work. The flat price quietly includes it because Microsoft carries the machine lifecycle. You're paying a bit more per head and you're buying back hours, so the break even point isn't a single number. It moves with your utilization, and it moves with the cost of the people who run the thing. And that second part, the people, is where the next question sits. Because labor is a management cost and the management model is different on each side. The hidden costs nobody puts in the spreadsheet. So you've run the numbers, machines, disks, license. The spreadsheet looks clean, but the spreadsheet is a draft. The bill that shows up in month three is the real one. Start with Azure Virtual Desktop because it has the longer list. Egress first data that leaves Azure costs money. Most days that's small, but if users pull large files down to a local drive or stream video out of the session, or you replicate data between regions, it adds up quietly. Nobody budgets for it because nobody thinks of a desktop as a data export service. Then profile storage pool designs need a home for every user's profile, usually fslogix on Azure Files or Azure NetApp files profiles grow outlook caches teams data browser history. A profile that started at two gigabytes drifts to twenty, multiply by a few hundred users, and that small supporting line in your estimate stops being small. Then, monitoring Azure Virtual Desktop Insights runs on log analytics. Log analytics charges by the gigabyte ingested. Turn on every diagnostic setting, and the telemetry itself becomes a line item that can rival a few session hosts. You want the data, you just have to choose which data. Then the image pipeline. Somebody builds the golden image, somebody tests it, versions it stores it in a compute gallery, and replicates it to the regions that need it. Storage and replication cost a little. The time costs a lot. Which brings us back to the biggest hidden cost engineering hours. We covered the shape of it already. The point here is that it never shows up as a charge. It shows up as a calendar full of someone's week. Now. Windows three hundred sixty five. The hidden cost here isn't a meter. It's silence. Remember, the price attaches to the person, not the session. So a cloud PC assigned to someone who connects twice a month costs the same as one used every day. A contractor leaves and nobody removes the assignment. An employee moves roles. A pilot ends and the licenses stay. Those machines sit there. Paid for doing nothing. In most organizations, this goes unnoticed for a long time because there's no spike to catch your eye. The bill is flat. Flat bills don't set off alarms. So the first fix is simple and it's not technical. Someone has to look at the utilization data on a schedule. Otherwise the predictable price is predictably wasteful. Now both sides share another layer licensing. Neither product runs on its own price. Windows three hundred sixty five has prerequisites on the windows, and intra side Azure Virtual Desktop needs eligible licenses before the first machine boots. If your users already hold the right Microsoft three hundred sixty five or windows licenses, that layer costs you nothing new. If they don't. It lands on the project and it lands late because licensing is usually checked after the architecture is drawn. Same story with the supporting pieces. Microsoft three hundred sixty five apps. Intune defender third party agents for backup or security. Each one is licensed per user or per device, and a cloud PC or a session host counts as a device. Now, the one place where Azure Virtual Desktop gives you a way to push the cost down hard, reserved instances and savings plans. You commit to a level of Azure Compute for one or three years. In return, the hourly rate drops, sometimes by a large margin for session hosts that run on a steady baseline. That's real money. But look at what you signed, a commitment. You're now paying for that capacity, whether you use it or not, which means you have to know your baseline before you buy. How many machines are always on how many scale up only for peaks. Reserve the baseline, leave the peaks on pay as you go, reserve too much and you've rebuilt the idle cloud PC problem just with a bigger contract that takes planning, discipline, usage data, a review cadence, someone who owns the decision. The discount is only as good as the forecast behind it. Notice what every one of these hidden costs has in common. None of them is a price. They're all behavior. Who watches the meter? Who removes the idle desktop? Who trims the logs? And that leads to the next question, because someone has to do all of that watching and trimming and patching. So who actually manages these desktops? 00:19:38 Speaker: Management model. Intune versus infrastructure. Open the Intune admin center, go to devices, then windows. A windows three hundred sixty five cloud PC is sitting in that list. Same view as a laptop, same compliance state, same configuration profiles. Same app assignments. Intune doesn't treat it as a special object. It's a managed windows device that happens to live in a data center. That's a big deal for the endpoint team, because nothing about their daily work changes the policies they already wrote apply the apps they already packaged. Deploy the autopilot style habits they built for laptops carry over you. Enroll the cloud PC, scope it with a group, and it behaves. Now the other side and Azure Virtual Desktop Session host is also a windows machine, but nobody hands it to you. Finished. You have to decide how it gets built. And that decision is a project by itself. Start with the image. Someone builds it, installs the apps, locks it down, and publishes a version. Then the host pool config pool type, load balancing method, maximum sessions per host, which app groups point to which users, then registration so each session host can join the pool at all, and then management of the machine itself. Here it gets mixed. Many teams enroll session hosts in Intune. Some still use group policy because they run hybrid, join hosts and have years of gpos. They trust some run both and that overlap is where drift likes to start, because two systems can set the same value and disagree. Now add Multi-session windows. This is the addition that lets many users share one machine. It's also the reason AVD can win on cost, but it comes with conditions. Intune supports Multi-session hosts, yet the support is not identical to what you get on a single user device. Some settings apply to the machine, some apply to the user on a shared host. That split matters because one user session shouldn't change what the next person gets. Check the current support notes before you plan your policy design around it. The gaps move with each release so the endpoint tooling can reach both products. But how well it fits depends on the model underneath. Now let's talk about day two. Day one is the build. Day two is everything after. And day two is where the real cost sits. Patching first on a cloud PC. Windows update for business or your Intune update rings. Do the work just like on a laptop. One machine per user. So a bad update affects one person on a pooled host. You patch the image, test it and roll out new session hosts from it, or you patch in place and hope the hosts stay consistent. Either way, someone owns the cycle, then updates beyond windows apps, agents, drivers, the security stack. Each needs a path to the machine, and each path needs a name next to it. Then drift. A machine that was clean in March picks up a changed setting in May and a stray install in July. On a personal desktop, drift is a nuisance. On a pooled host, it's a gamble because users land on different machines and get different results. It works on host three, but not host seven is a drift ticket and then break fix when a cloud PC misbehaves. The usual answer is simple Reprovision it. Microsoft rebuilds it from the image and you move on. When a session host misbehaves, you drain it, check it, replace it, and look at why it happened. More control. More steps. Notice what this adds up to. Windows three sixty five turns desktop management into endpoint management. Azure Virtual Desktop turns it into infrastructure operations with an endpoint layer on top. And here's the part that causes trouble in most organizations. Those are two different teams. One team manages endpoints. They live in Intune entry ID and the helpdesk queue. The other team manages Azure. They live in subscriptions, virtual networks, and deployment pipelines. They sit in different parts of the org chart. They use different tools and they often don't share a roadmap. Now put a desktop product in between whichever product you pick. It pulls one of those teams to the front, and whether that team is ready decides whether the product works at all. Skills and team fit. Skills and team fit. Let's start with who each product was built for. Windows three hundred sixty five fits the endpoint team. The people who already live in Intune and entry ID. They know how to scope a policy to a group. They know how to read a compliance report. They know what a normal windows ticket looks like for them. A cloud PC is one more device type in a console they open every morning. The learning curve is short because the work is familiar. Azure Virtual Desktop fits a different crowd. It fits teams with Azure networking skills, people who can design a virtual network, peer it, route traffic through a firewall, and sort out DNS without a week of meetings. It fits teams who automate bicep Terraform pipelines that build an image and roll it out. Infrastructure as code isn't a bonus yet. It's how you keep twenty session hosts from becoming twenty different machines, so the skill sets are close to opposites. One is windows management with a cloud address, the other is cloud engineering with a windows workload. But here's what typically happens. A project gets approved. The business wants cloud desktops. A budget owner picks a product often based on a demo and a price sheet, and then the platform lands on a team that never agreed to run it. Take the endpoint team that inherits Azure Virtual Desktop. They get a host pool, a scaling plan, and a profile storage account. Nobody trained them on any of it. The first time a login takes two minutes, they don't know whether to look at the network, the image, or the file share. They guess. Guessing takes days. Now flip it. The Azure team inherits windows three hundred sixty five. They expect knobs. They find a policy console and a provisioning screen. They do fine with the build, but they're not the ones who understand app packaging update rings, or why a user's outlook keeps asking for a password. The ticket queue fills with endpoint problems, and nobody who owns the endpoint is in the room. Neither team is weak, they're misplaced, and the cost of that mismatch doesn't appear on any bill. It appears as slow fixes, tense meetings, and a quiet conclusion. Six months in that the product doesn't work. So before you pick a model, ask a plain question whose pager will this go on? Which brings us to the support model. A user opens a ticket. Three words. It's slow. That ticket sounds simple. It isn't. With windows three sixty five, the list of places to look is short. Is the cloud PC healthy? Is the user's connection quality poor is something running inside the machine. Microsoft owns the platform underneath, so the endpoint team can check the machine, check the connection, and if needed, Reprovision short path clear owner with Azure Virtual Desktop, slow could mean a dozen things an overloaded session. Host a noisy neighbor on a shared machine, a profile that takes forever to mount a network path that detours through a distant firewall. A scaling plan that started machines too late. Each of those belongs to a different skill and sometimes to a different team. So the real question isn't who supports the desktop, it's who can tell which layer is the problem. If nobody can, the ticket bounces endpoint, sends it to networking. Networking, sends it to infrastructure infrastructure sends it back with a note asking for logs. You want that route drawn before launch, not after the first. Angry email and skills matter most at one particular moment, not when everything is steady. When demand moves, a season starts, a project ramps. A merger, adds two hundred people overnight. That's when you find out whether your team can add capacity or only add licenses. So let's talk about scaling. Scaling behavior. Static versus elastic. Ask a windows three hundred sixty five admin how they add capacity. They'll tell you they don't. There's no capacity to add scaling in windows three hundred sixty five means one thing you buy a cloud PC for a person, or you remove one fifty new hires, fifty new assignments, a team shrinks by twenty and twenty come off the list. The unit is the user, not the machine, not the pool that's clean. It's also static because a cloud PC doesn't get bigger when the day gets busy, and it doesn't get smaller when the day ends, it sits at the size you picked. If a user needs more power next quarter, you change their size and that's a planned move, not a reaction. Now Azure Virtual Desktop here, scaling is a feature you configure auto scale plans start and stop session hosts based on a schedule or on load. Morning ramp up machines start before people arrive. Peak hours more hosts stay available. Evening ramp down. Hosts drain, then shut off a machine that's off doesn't bill for compute. So the plan is also a cost control and the plan has parts. You said how many hosts stay on? At minimum you set the thresholds that trigger more. You decide how long a host waits for users to log off before it stops. Each of those is a choice, and a wrong choice shows up fast. Set the ramp up too late, and the first people in wait on a cold machine set it too early and you pay for hosts nobody's using. That's the trade. Elastic means the system adapts. It also means someone had to teach it. How. Now picture a pooled host pool at the edge of a busy week. Say demand is normally forty concurrent users. Then a quarter end close pushes it to one hundred and twenty. The pool can grow to fit that peak. More session hosts start, users spread across them and the load stays level. Then the week passes and the pool shrinks back. You paid for the peak only while it lasted. Windows three hundred sixty five can't do that. To cover a peak, you'd buy a cloud PC for every person who might need one, and that cost holds even after the peak is gone. But there's a middle path, and Microsoft built it on purpose. Windows three hundred sixty five frontline. It's a version of the cloud PC made for shift workers. Instead of one dedicated machine per person. You buy cloud PCs that are shared across several users, one active user at a time, three people on three different shifts can use the same license. One logs off, the next logs in, and the machine is ready. That changes the math for the right crowd. A call center with three shifts, a retail operation with part timers. A clinic where staff rotate through a few workstations. You stop paying for a full time machine that sits idle two thirds of the day. It still keeps the simple model, though. You buy cloud PCs, you assign them, Microsoft runs them. The difference is concurrency. There are limits on how many users can be active at once against what you bought, so check the current rules before you size it. But the shape fits. Shift work far better than the standard per user license does. So now we can see where each model strains sudden growth. First, a new contract lands and you need three hundred desktops by Monday. Windows three hundred sixty five handles this with licenses and provisioning time, which is fast but not instant, and the cost lands the moment you assign. Azure Virtual Desktop handles it by adding hosts to a pool, which is fast too, but only if the image, the network and the capacity in your region were already ready. Seasonal workers. Next, a retailer hires two thousand people for six weeks per user. Pricing means paying for each one in full unless frontline fits the shift pattern. A pooled design lets you size to concurrency, not headcount. Seasonal demand favors the model that can shrink, then burst. Projects a short, heavy job that needs a lot of power for a few days. Elastic winds on cost because the compute exists only while the job runs static winds on speed of setup. Because there's nothing to build, neither model strains everywhere. Each strains where its assumption stops matching the work and scaling touches. One more thing capacity isn't only about how many machines, it's about how big each one is and how that feels to the person using it. So let's look at performance, performance, and user experience. Put two users side by side. One is on a cloud PC, one is on an Azure Virtual Desktop session host. Both are typing in word, both are on a call, and both are scrolling a spreadsheet. Ask them which is faster. They'll shrug. That's because both products use the same remote protocol family underneath the pixels travel the same way. The keystrokes come back the same way, so the base experience is close, and any gap you feel comes from somewhere else. Where the two differ is in how much you're allowed to tune. As your virtual desktop hands you choices, a lot of them, you pick the virtual machine family for each pool, you decide how many CPUs and how much memory sit behind each session. You can choose GPU enabled machines for graphics heavy work like CD, video editing, or anything that drives a 3D viewport. You pick the Azure region so the desktop sits close to the people using it or close to the data they touch. And on a pooled host, you set how many users share each machine, which decides how much power each person actually gets. That last setting is a quiet one. Pac twelve users on a host, and the average day feels fine. Then everyone opens a heavy report at ten o'clock and the host strains. You tune it down to eight per machine. The strain goes away and the cost goes up. Performance and price are the same. Dial windows three sixty five turns that dial for you and fixes it in place. You choose from a list of cloud PC sizes. Each one is a fixed bundle of CPU, memory, and storage. There's no custom shape. If the largest bundle doesn't fit a workload, you can't invent a bigger one, and the options for specialized hardware are narrower than what you can build yourself on the Azure side, check the current size and GPU options before you plan around them because the list keeps changing. But that limit has an upside. Fewer choices means fewer ways to get it wrong. A knowledge worker on a midsize cloud PC rarely needs a sizing meeting. You pick a size, assign it, and the experience is consistent from one person to the next. Simple path, less room to tune. That's the trade again. Now here's a point that gets blamed on the wrong thing latency. When a desktop feels laggy, people point at the product. As your virtual desktop is slow, the cloud PC feels sluggish. But latency isn't a product trait. It's a distance and a path. Think about what happens on every keystroke. Your input travels to the machine. The machine draws the result. The picture travels back. That round trip crosses your local network, your internet provider, and whatever route sits between you and the Azure region. A user in Lisbon connected to a desktop hosted in Virginia will feel it. A user in Lisbon connected to a desktop hosted in Western Europe won't. Same product, different geography. So region placement matters more than most feature comparisons. The same goes for the path itself. A connection that detours through a distant VPN gateway or a central firewall adds delay that no session host can fix. You can buy the biggest machine in the catalog, and a bad route will still make it feel slow. Then there's the traffic that makes this harder. Video calls teams is the usual suspect. A video call inside a remote desktop is a strange thing. The call is being rendered in the data center, compressed, sent to the user, and decompressed. If nothing is optimized, you're doing that work in the wrong place. Audio drifts. Video stutters. The user blames the desktop. The fix is offload with teams optimization. The media processing moves from the remote machine to the user's local device. The call goes more directly and the session host stops burning CPU on video. The same idea applies to other media. Redirecting multimedia playback to the local device keeps the remote machine from decoding what the endpoint could decode itself. And here's what matters for this comparison. Optimization is needed in both products. A cloud PC doesn't get a free pass on teams. You still configure it, test it, and confirm the client supports it, skip it, and either model gives you a bad call. So tuning isn't a feature of one product. It's a discipline. One model hands you more, dials. The other hides most of them. Neither one works unless someone actually checks. And every one of these experiences the keystroke delay, the call quality. The speed of a file open writes on one thing the network, which is exactly where designs tend to fail. Networking architecture where cloud PCs live. Every desktop has to live somewhere, not in the abstract, on a network with an address, a route, and a way to reach the things the user needs. And this is where the two products give you a very different starting points. Take windows three hundred sixty five first because it gives you a choice. Option one is a Microsoft hosted network. You build nothing. There's no virtual network to design, no subnet to size, no peering. To configure, Microsoft places the cloud PC on its own network and hands it to the user. You pick a region, assign the license, and the machine appears. That's why this path is fast. To start. A pilot can run in an afternoon for a team that wants to test the idea without a networking project in front of it, that's the whole appeal. But look at what you gave up. The cloud PC sits outside your network. If the user needs to reach an internal file server, an old line of business app, or anything that lives behind your firewall, there's no private path waiting for them. Internet facing services work fine. Internal ones don't. Unless you find another way in. Option two fixes that. It's called an Azure Network connection. Here you bring your own virtual network in your own Azure subscription. The cloud PC gets placed inside it. Now it can sit on the same network as your other workloads, follow your routing rules, pass through your firewall, and reach internal resources over private links, and you pay for that with work. You build the network. You size the subnet because every cloud PC takes an address, you check the DNS resolves the right names. If the cloud PC is hybrid joined, you make sure it can reach a domain controller and you keep all of it healthy. Because Microsoft runs health checks against the connection and a broken one blocks new provisioning. Same trade as before in a smaller frame. More control and more homework. Now Azure Virtual Desktop. There's no menu here. AVD always lives in your Azure subscription and always in your virtual network. Every session host is a virtual machine you own attached to a subnet you chose. Microsoft runs the broker and the gateway. The machines are yours, so network design isn't an option in AVD. It's the first job you decide the address space, you decide how many subnets and which pools go where. You decide what the session hosts can reach and what they can't, and you decide how outbound traffic leaves, whether straight to the internet or through a firewall that inspects it. Which raises the next question for both models. How does any of this connect back to what you already run? Most organizations still have something on premises application servers file shares, a database that nobody wants to touch, maybe a domain controller. The desktop in the cloud has to reach it and the path matters. You usually have two ways to build it a site to site VPN, which sends encrypted traffic over the internet. It's quick to set up and cheap to run, but the quality depends on the internet or expressroute a private line between your data center and Azure. More cost, more lead time, and steadier performance. For a design where hundreds of users open large files from an on premises share that steadiness is worth a lot. Then DNS quietly. This breaks more desktop projects than any other piece. The cloud PC or session host has to resolve internal names correctly. If it points at the wrong DNS server, the app can't find its database and the user sees an error that looks like an application problem. It isn't. It's a name that went to the wrong place. And the domain controllers. If your desktops are hybrid joined, they need a clear line to a domain controller for sign in and policy. Put that controller far away or leave the path unreliable and logins crawl. Many teams place a controller in Azure close to the desktops, so authentication doesn't cross a long link every morning. Now put all of that together and you can see why this section decides outcomes. A pilot works because the pilot is small ten users. One region may be no internal apps at all. Everything feels fine. Then the project scales. Real users show up and they need the file server, the old app, and the printer. The network that was good enough for ten people turns out to be missing half the routes. That's where pilots stall, not because the desktop failed, because the network around it was never designed for production. So the network isn't plumbing. You finish later. It's the first design decision that will either carry the project or stop it. And the network is more than a path. It's also a boundary, the line between what a desktop can touch and what it can't. A boundary like that only means something if you know who is standing on the other side of it. Which brings us to identity. 00:36:56 Speaker: An identity join types and security posture. Before a desktop can be trusted, it has to belong to something. That's what a join type decides. It tells the device who it answers to. Start with the clean option. Entra. Joined the cloud PC or session host registers directly with entry ID. No domain controller in the path sign in is cloud to cloud policy comes from Intune for a new build with modern apps. This is the shortest road and the one with the fewest parts to break. Then hybrid joined the machine joins your on premises Active Directory and also registers with entry ID. It supports group policy, Kerberos to internal servers, older apps that expect a domain. But now you're back to the dependency we just talked about. The desktop needs a line of sight to a domain controller, so the network decision and the identity decision turn out to be the same decision. And that's the legacy domain dependency. It isn't a feature, it's a leash. Many organizations pick hybrid join because one old application needs it, and then the whole desktop estate inherits the constraint. Before you accept that, ask what actually needs the domain. Sometimes it's a file share you can reach another way. Sometimes it's one app that should be fixed or retired. The joint type you pick today is the one you'll be explaining in three years. Now both products meet the same gatekeeper. Conditional access applies to windows three sixty five and to Azure Virtual Desktop. The policy engine is the same, but the places where it enforces are different with a cloud PC. You can protect the sign in to the cloud PC service itself, and you can protect the device through compliance, since Intune manages it like any other endpoint with Azure Virtual Desktop. The enforcement lands on the AVD service and on the session sign in. Those are two separate moments. A policy that covers the first doesn't automatically cover the second. Teams miss that. They write one rule test one login, and assume the door is locked everywhere. So you test both steps every time. From there, the pattern is zero trust and it's simple to say check the device. Check the person, check the session device compliance first. Is the machine healthy? Patched and managed conditional access can require a compliant device before it lets anyone in. Then multi-factor authentication. So a stolen password alone gets nobody through. Then session controls, which limit how long a sign in lasts and how often it must be proven again. Here's the part people forget the device in that first check isn't only the cloud PC. It's also the laptop or thin client the user connects from. You can require a compliant local device to reach the remote one. Otherwise, you've built a locked vault and left the key under the mat. Now the data itself. A desktop in the cloud doesn't stop data from leaving. It gives you more places to stop it. Clipboard redirection decides whether a user can copy text from the remote session to their local machine. Drive redirection decides whether local folders show up inside the session and whether files can move between them. Printer redirection, USB redirection, and the same for microphones and cameras. Each one is a setting and each one is a door. You can allow copy in, but block copy out. You can turn off drive mapping for the finance group and leave it on for it. And then there's watermarking, which stamps the user's identifier over the session. It won't stop a photo of the screen, but it makes that photo traceable for sensitive work. That deterrent counts. These controls exist on both sides. The enforcement is policy, and policy needs an owner. So why does a cloud PC often beat a laptop for regulated work? Because the data stays put on a laptop. Files live on a disk that can be lost, stolen or copied on a cloud PC. The files sit in a data center. The user sees pixels lose the laptop. Nothing is on it. Off board a contractor. The access ends in one place. For auditors, that single boundary is easy to describe and easy to prove. But the argument has a seam. It breaks the moment you allow the doors to open. If clipboard and drive redirection are on, the data walks out through the session. If users can take screenshots, print to local devices, or sign in from an unmanaged machine. The isolation is mostly theater, and a cloud PC is still a windows machine. An infected endpoint can still capture keystrokes on the way in, so the isolation isn't a property of the product. It's a result of the settings and those settings, along with who is allowed to use which product at all, are tied to a different layer. The one where an eligibility check can quietly change the whole design. Licensing licensing foundations Most architects draw the diagram first and read the license terms second. That order is backwards. Licensing decides who is allowed to use which model at all. A design that looks perfect on a whiteboard can fall apart the day someone checks eligibility. So let's lay down the foundation before we go anywhere near the traps, start with windows three hundred sixty five because the license is the product you buy a per user cloud PC license. It bundles the machine, the compute, the storage, the platform that runs it all inside that one SKU, one user, one license, one cloud PC, nothing else to meet on the Azure side for the base machine. But the license doesn't float on its own. It has prerequisites and they sit on the windows and intra side. The user needs an eligible windows license. Underneath that usually means a windows enterprise or business entitlement, often carried inside a Microsoft three hundred sixty five plan. The user also needs an identity and entry ID because that's how the cloud PC knows who it belongs to. And if you want Intune to manage the machine, as most teams do, that needs a license too. So the cloud PC price covers the machine. The rights to run windows on it come from the licenses your people should already hold. Miss one of those and the assignment fails or the bill grows a new line now Azure Virtual Desktop. Here the shape is different. Nobody tells you an AVD license. Instead, access rights come from licenses you already own. Eligible windows licenses eligible Microsoft three hundred sixty five plans that include Windows Enterprise. The user holds the right to connect, and that right is what lets the service accept them. Then you pay Azure consumption on top the machines, the disks, the profile storage, the traffic. That's the bill we walked through earlier. The license gives you permission as your charges you for the resources that use it. Two different questions. Then windows three hundred sixty five asks whether you bought the cloud PC. AVD asks whether your users are entitled to the thing you're about to build now. The entitlement that makes pool desktops possible multi-session windows ten and windows eleven. This is the addition that lets users share one virtual machine, and it's the reason a pooled design can bring the cost per user down so far. But it isn't available to everyone. It's tied to eligibility, and it runs on Azure Virtual Desktop users who hold the right Windows Enterprise licenses, or the right Microsoft three hundred sixty five plans that include them qualify. Users without those licenses don't, and you can't waive that away by calling it a technical detail. Notice how that works. The cheapest design on the table. A shared pool, only opens up if your license base already supports it, So eligibility doesn't just limit the design, it sets the price floor. Then there's the other kind of workload server based desktops. Some organizations don't want a windows client edition at all. They run Windows Server with remote desktop services because that's what their apps were built for. AVD can host those session hosts, too, but the windows client entitlement doesn't cover them. For users to connect to a Windows Server desktop, you need remote desktop services client access licenses tied to the server licensing. You already hold two licensing worlds. One connection that's a different check with a different owner. Often, the server licensing sits with another team under another agreement with its own renewal date. So here's the practical rule check license eligibility before you draw the architecture. Not during the pilot, not at procurement. First, pull a list of the people you plan to serve. Find out which Windows and Microsoft three hundred sixty five licenses each of them holds. Find out whether the Multi-session path is open to them. Find out whether server access licenses exist for the workloads that need them. Do that early, and the architecture matches what you're allowed to build. Do it late, and you redesign the thing in the middle of the project, or you buy licenses nobody budgeted for. Because licensing doesn't only set the price, it sets the boundaries. And those boundaries have edges that catch people off guard. Those are the basics. Now for the traps, licensing traps, and edge cases. Start with the one that stops multi-tenant designs. Cold hosting restrictions. Microsoft limits where certain licenses can run. You plan to host desktops for your customers on infrastructure run by a third party. The rules change. Some windows licenses can't be brought onto a shared provider's platform. Some need specific agreements. A few paths are simply closed. This hits two kinds of teams service providers who want to build a desktop offering for many customers, and internal teams who plan to host a subsidiary or a partner inside their own tenant. Both assume the license travels with the user. Sometimes it doesn't read the current product terms for your exact case and get it confirmed in writing before you design the tenant layout. Now the next one. Shared devices frontline looks like a simple deal. One license several people, one machine at a time. But the license doesn't mean unlimited users. It means one active session per cloud PC license at any given moment. The count that matters is how many people connect at the same time, not how many hold a login. So concurrency becomes the rule. You live under three shifts of ten. People can share ten licenses if they don't overlap, let a shift run late or let a hand over stretch and the eleventh person can't get in. There are also limits on how many times a licensed machine can be used inside a day or a window. Check the current terms before you sign anything. The numbers have moved before. Then there's the shared device. The user holds a shared kiosk or a front desk thin client. The windows license on that device and the license for the remote Desktop are two separate questions. Mix them up and you pay twice or you're not covered at all. Next, the apps. Some software cares which license sits behind the desktop. Microsoft three hundred sixty five apps is the classic case on a pooled host. Many users share one machine, so the apps can't activate the usual way one device per user. They need shared computer activation. That setting lets each user's license activate for the session, and it needs a plan that supports it, a plan that doesn't. Users hit activation errors or the APS drop into reduced mode. This one often arrives late, the image is built, the pool is up, and the first pilot user opens Excel to a licensing prompt. Nothing is broken in the desktop. The license just doesn't fit the model. Third party software does the same thing. Some vendors license by device, some by user, some by core. A shared machine or a cloud PC that gets rebuilt can confuse all three. Ask each vendor how their license behaves on a multi-session host before the app goes into the image. Now the one piece that can move the cost in your favor. Azure Hybrid Benefit if you already own windows licenses with software assurance or equivalent subscription rights, you can apply them to your Azure Virtual Machines. The result is a lower hourly rate. You stop paying for the windows license again inside the Azure price because you've shown you already own it on Azure Virtual Desktop. That changes the math from earlier a session host with the benefit applied costs less every hour. It runs across a large pool and across a year. The gap isn't small. It also stacks with reserved capacity, so a committed benefit applied host is one of the cheapest ways to run a steady baseline, but it only works if the entitlement is real. Applying it without the right licenses is a compliance problem, not a discount. Someone has to confirm the rights before the checkbox gets ticked. So that's the licensing picture. Eligibility sets what you can build these edge cases, set what it costs to run it, and with licensing clear, we can stop talking about the box and start talking about what goes inside it. What do people actually run on these desktops? Use case mapping. Who should get what? Forget the products for a minute. Start with the people. Because every desktop decision is really a decision about a person and what that person does between nine and five. Take the knowledge worker first analyst, consultant, project manager, someone who opens the same apps every morning and expects them to look the same as yesterday. Their desktop is personal. They pin things to the taskbar. They keep forty browser tabs open for a week. They notice when a setting changes, their demand is flat. They connect most days at similar hours for similar work. And that's the pattern. Windows three hundred sixty five was built around one person, one machine, one price, nothing to schedule, nothing to pool, nothing for the user to lose between sessions. The persistence is the product. Could you serve them on a pooled design? Yes, but you'd spend engineering effort rebuilding the feeling of a personal desktop out of shared paths, profile containers, roaming settings, a login that lands on a different host each day. You'd be working hard to imitate something the other model gives you by default. Now, the shift worker, call center agent, retail associate nurse at a rotating workstation. Their sessions are short, their apps are few, and the desktop doesn't belong to them. It belongs to the shift. The pattern here is the opposite. The machine sits idle most of the day unless somebody else is on it. Paying for a dedicated desktop per person means paying for hours nobody uses. So the question isn't which product feels nicer. It's which model charges for concurrency instead of headcount. Two answers fit a pooled Azure Virtual desktop design, where many users share a set of hosts and the pool sizes to whoever is logged in or windows three hundred sixty five frontline. If the shift pattern is predictable and you want Microsoft to keep running the machines, the deciding factor is team fit. As we saw earlier, pooled host reward a team that can tune frontline rewards, a team that wants less to tune next developers and contractors. These two groups don't look alike, but they share one need. They need a desktop that can be thrown away. A contractor arrives with a four month engagement and leaves with none of your data. A developer needs a clean environment for one project. Then once it's gone, then once another. Isolation is the requirement. Persistence is the risk. Here the choice depends on how disposable you need it to be. If each person needs their own full machine with admin rights and a custom toolset, a cloud PC gives them that in minutes and you reprovision it when the work ends. If the environment is more standardized with the same tools for everyone and nothing personal worth keeping, a pooled pool with a locked image costs less and resets cleaner. The first optimizes for speed of setup, the second optimizes for cost and consistency, and one rule applies to both keep their data off the desktop, put it in a repository or a managed share so that deleting the machine never means losing the work. Then the specialists, engineers running shaadi analysts loading datasets that need hundreds of gigabytes of memory. Video editors, researchers running simulations their workloads hit a ceiling that ordinary desktop sizes can't clear for this group. The question is simple does the product offer the hardware the work demands? As your virtual desktop sits on Azure Virtual Machines, so you can pick GPU enabled families and large memory sizes and place them in the region closest to the data. Windows three hundred sixty five offers a fixed list, and the list is narrower at the high end. Check what's available today before you commit. If the size you need isn't on it, the decision is already made, so look at the pattern across all four. None of those matches came from a preference. Flat demand and personal state point to the per user model. Idle time and shared sessions point to the pooled model or frontline. Disposable environments depend on how much control the user needs. Heavy hardware depends on what the catalog actually contains. That's the method. Describe the work first, then let the work pick the model. But some situations don't fit neatly into any persona short lived, fast moving, or messy by nature, they pull on the model in ways the standard cases don't. They deserve their own look. Contractors, mergers and temporary workforces. A new contractor starts Monday. It's Friday afternoon. Nobody has ordered a laptop. Nobody has a build slot. This is where windows three hundred sixty five shows its speed. You assign a license to the user, pick the image and the policy and the cloud PC provisions minutes. In many cases, though, the exact time varies with region and load. The contractor opens a browser, signs in, and lands on a working desktop. No shipping, no imaging station, no courier as your virtual desktop can be just as fast, but only if the groundwork is already done. The host pool has to exist. The image has to be current, the network has to reach what the contractor needs, and there has to be spare capacity with a session host ready to take another person if all of that is in place, adding the user is one group membership. If it isn't, you're building a pool on a Friday afternoon. So the difference isn't speed, it's where the work happens. Windows three hundred sixty five does it per person. At the moment you ask AVD does it once upfront and then onboarding becomes cheap. Now Offboarding. This is the half people forget when the contract ends. A cloud PC is a thing. It's an object with a license and a bill. You remove the assignment and the machine goes through a grace period before it's deleted. Until that grace period ends, you're still paying for it, and the data on it is still there, which matters. If the contractor was working with anything sensitive, someone has to confirm it's gone on a v d Offboarding is smaller. You remove the person from the app group and their access to the pool stops. No machine to delete because the machine was never theirs. The profile data sits in storage, so that needs its own clean up rule. But the compute doesn't change at all. One model removes the desktop, the other removes the permission for a workforce that turns over. Often that gap adds up to real hours or real forgotten bills. Now a different kind of temporary mergers. Two companies close a deal, legal says go. The business says go and identity says give us eighteen months, two tenants, two directories, two sets of apps, policies and email domains. Merging them is slow and everyone knows it. Meanwhile, people from company B need to reach Company A's systems on day one. A desktop in the cloud works as a bridge. Put the acquired staff on desktops that live inside the parent tenants network. They sign in with a guest or a new identity, reach the shared apps and work. Nobody has to migrate a mailbox or rebuild a laptop first. The desktop gives them a place inside the new company while the identity work finishes behind it. Either product can do this. Windows three hundred sixty five is quicker to stand up for a group of a few hundred Aivd fits. When the acquired team needs a shared pool with locked down access to a small set of apps. And when the identity merges done, you retire the bridge. That's the point it was always meant to end. Which leads to the pricing question. For all of these short lived cases, short demand tends to favor consumption pricing. If you only need desktops for six weeks, paying by the hour for pooled hosts that shut off at night beats a monthly fee per person you size to concurrency. Run the hosts while people work and stop the meter when they don't. But it doesn't always win. If the temporary group is small, say twenty people. The engineering time to build a pool can cost more than the license savings. And if each person needs a personal, persistent machine for the whole engagement, the pool saves you nothing. In those cases, a few cloud PCs for a few months are cheaper than the project. To avoid them, short lived demand favors consumption only when the setup effort is already paid for. Now, one more special case. And it isn't about people at all. It's about software that was never built for any of this. 00:53:46 Speaker: Legacy apps. Line of business systems and data. Gravity. Some applications can't move on their own. They sit next to something heavy a database, a file server with ten years of drawings, an ERP system that every screen talks to all day in small, chatty requests. The app and its data were built to live a few feet apart on the same fast network. That's data gravity. The data stays put and everything else gets pulled toward it. Now put a desktop in the cloud and put that desktop far from the data. Every click in the app triggers dozens of calls back to the database. Each call crosses a distance. A report that took three seconds in the old office now takes forty. The user says the desktop is slow. It isn't. The app is waiting on a long road. So here's the point most comparisons skip placement matters more than product windows three, sixty five, or Azure Virtual Desktop. Either one will feel broken if the session sits in the wrong region, and either one will feel fine if it sits right beside the data. That means the first question isn't which product, it's where the data lives and which Azure region is closest to it. If the database is in a West Europe data center, the desktop belongs in West Europe. If the data is still on premises, the desktop belongs in the region with the best private link back to that building. Get that wrong and nothing you tune later will save it, which also tells you something about the choice of model. If you need the desktop in a specific region on a specific virtual network with a specific route to a server, you're already leaning toward the options that give you network control. A cloud PC on your own network connection can do it. A pooled host in your own subscription can to a Microsoft hosted network with no private path home usually can't. Now, the apps themselves, before any of them goes on a cloud desktop, someone has to test whether it still works there, and that test has a few paths. The simplest is baking the app into the image. You install it on the golden image, seal it in every desktop built from that image carries it. It's fast to launch and easy to reason about, but every update means a new image, and every app in the image makes the image heavier and slower to change. The second path is Msix app attach. Here, the app lives in a separate package, stored on a share, and attaches to the session at sign in. The image stays clean. You update the app by updating the package, not the whole machine. For pooled desktops. This keeps the base image small and lets different groups see different apps from the same hosts. It does need the app to be packaged, and not every old installer survives that. The third path is a package pipeline. Instead of a person clicking through an installer, a pipeline builds, tests, and delivers the package the same way every time. Slower to set up. Far cheaper to run once you have thirty apps instead of three. So test each app on the real design in the real region against the real data. A passing result on a developer's laptop tells you nothing. And then there's the software that should never have left old client server applications, the kind built in an era when the server sat in a closet down the hall and the client assumed a wire with almost no delay. They chat constantly. They open files over network paths with hard coded names. They don't handle the slow link, and they weren't written to. Moving them to a cloud desktop alone makes them worse. Putting the desktop next to the server helps, but sometimes the honest answer is that the app and the server behind it belong together in the same place, and the desktop is the wrong thing to move first. Moving the whole stack or replacing it is the real project. A cloud PC can't fix an application that only works inside the building. Which brings up a related question if placement and proximity matter this much, what about the device in the user's hands? Do they all need a cloud desktop at all, or is there a better fit sitting on their desk already? Cloud PC versus physical PC and the alternatives. Not every user needs a cloud desktop. That sounds obvious, but after months of planning, teams often forget it. The project gains momentum. The slides say cloud first, and suddenly every laptop on the asset list becomes a migration candidate. Some of them shouldn't be a managed physical. PC is the better answer when the work depends on the hardware in front of the user. Video conferencing rooms, lab equipment on USB engineers with local GPUs, and huge data sets that are already on the disk field staff who spend half their week with no signal. A remote desktop needs a connection. Without one, it's a blank screen. It's also the better answer when the cost of change is higher than the cost of staying a laptop that's three years old, well managed in Intune with a user who never touches a legacy app, what problem are you solving there? You'd be paying a monthly fee to move a working machine into a data center. So the honest test is simple. What does the cloud desktop fix that the laptop doesn't? And here's where the answer's often very clear remote access that leans on a VPN. You know the pattern a user works from home. To reach one internal app. They connect a VPN that pulls all their traffic through a gateway sized for a tenth of the staff. Everything slows, the gateway strains support, gets calls every Monday morning, and the whole time a corporate laptop with cached data sits on a home network you don't control. A cloud PC replaces that path. The user connects to the desktop over the remote protocol, and the desktop sits on your network next to the app. Only pixels across the home internet. The heavy traffic stays inside Azure. You retire a VPN gateway, or at least shrink what it has to carry. For a company whose real problem is remote access is painful. That's the strongest case there is now. There's a middle ground. Microsoft built it on purpose windows three sixty five boot link and switch boot lets a physical device start straight into the cloud PC. The user turns on a shared laptop, signs in, and lands in their cloud desktop. Nothing personal, lives on the device, useful for shared hardware like a training room or a front desk. Link goes the other way around. The user stays on their local windows PC and connects to the cloud PC through the local taskbar. The cloud PC is one click away, but the local machine is still theirs, and switch gives the user a way to move between local and cloud desktops inside the same interface. A shortcut, a keyboard command, one machine for private work, another for the managed environment. Each of these needs supported client versions and setup steps, so check the current requirements before you plan around them. But the idea matters more than the details. The cloud desktop doesn't have to replace the device, it can sit beside it, which is why cloud PC or laptop is a false choice for most organizations. Look at any real estate, a finance team with laptops and one cloud PC for the audit system, contractors on their own hardware working inside a managed desktop shift, staff on shared thin clients, executives on personal machines, and developers on both. The question was never which one it was, which one for whom and for what. That's how a mixed estate gets designed. You match each person to the right delivery, then keep one identity layer and one policy layer under all of it. But suppose you've done that work. You've looked at the personas, the data, the network. The answer for a real group of users is cloud. Then comes the harder question how do you actually get them there? Migration path one from VDI or RDS to AVD. Most remote desktop estates are older than the people running them. A farm of session hosts, a broker, a gateway, a file server holding profiles built years ago, patched ever since, and trusted because it still works. Nobody wants to redesign it. They just want it out of the data center. So the first path is the plainest one. Lift the existing model into Azure with the least change. Same idea, same user experience, different place. Azure Virtual Desktop fits this because it's built on the same lineage. Pools session hosts shared sessions, the ideas map across so the learning curve stays short. But least change doesn't mean least thinking. It starts with assessment. Count the applications first, not the list in the spreadsheet. The list of what people actually open. Many estates carry apps that nobody has launched in two years, and each one you move costs, testing time, then profiles. How big are they? Where do they live? A profile that grew to forty gigabytes over a decade will punish a login. Then user accounts, which are easy, and then peak concurrency, which is the number that really sizes the design, not how many people exist, how many are signed in at ten o'clock on the worst day of the month? Get that last number wrong and everything downstream is wrong with it. Now profiles, because this is where migrations quietly fail. In a pooled design, the user lands on a different host each day, so their settings and files need to follow them. That's what Fslogix does. It stores the profile in a container, a virtual disk, and attaches it at sign in. The user sees the same desktop on any host. For the containers home, you have two common choices Azure files, which is simpler to run and fits most estates, or Azure NetApp files, which costs more and delivers faster, steadier performance for large or demanding profile sets. Pick based on the login experience you need not on habit. A pool of two thousand users all signing in at eight o'clock, will stress storage in a way a pilot never shows, and place the storage in the same region as the hosts. Profiles that travel across a long link make every login slow and the user will blame the desktop. Then the image, which is the part you'll live with longest. You build a gold image, one clean machine with the operating system, the base apps, the agents, and the settings every user needs. You seal it and every session host is stamped from it. That keeps the pool consistent. So a bug on one host is a bug on all of them, and a fix works the same way. Store that image in an Azure Compute Gallery. It keeps versions so you can roll forward and roll back if an update goes wrong. It also copies the image to the regions where you need it. Then comes the pipeline. Updates shouldn't be a person remoting into a template on a Sunday. A pipeline builds the new version, tests it, and publishes it. Hosts get replaced from the new image, not patched one by one. That's the habit that separates a pool that stays healthy from one that drifts. Now the cutover. Don't do it all at once. Start with a pilot. A small group chosen on purpose. Include the users who will complain because their complaints are free. Testing. Run them for a few weeks. Watch the logins, the app behavior, the support tickets. Fix what breaks, then wave one. A real slice of the business, maybe fifteen percent, with a department that tolerates some bumps, then wave two and the waves after it, each larger than the last, each with a firm start date and a clear owner. And before wave one begins right the rollback plan. Where do users go if the new pool fails? Is the old farm still running? For how long a rollback? You've never tested is a hope, not a plan. Keep the old environment alive until the last wave has been stable for a full business cycle, including that heavy month end. That's the shape of this path. Assess. Move profiles. Build the image cut over in waves. But if you ask who's actually moving, it's often not people leaving old remote desktop farms. The other direction is more common than most teams admit. Migration path two from physical PCs to windows three hundred sixty five. Here, the starting point looks different. There's no farm, no broker, no gateway, no profile server. Instead, there's a fleet of laptops. Each one is a small island. Each one is slightly different from the last. The goal isn't to lift a design into Azure, it's to change what a PC means for some of your people. So start small. Start with a segment, not the company. Pick a group that shares a shape. Maybe the contractors, maybe a department that's always on the VPN, maybe the people whose laptops are due for a refresh next quarter, because that's the moment the cloud option costs the least to try. A segment gives you a clean comparison. Same work, same apps. Same expectations. Two delivery methods. A whole company move gives you noise. Now the build. This part will feel familiar because windows three hundred sixty five cloud PCs show up in Intune like any other managed device, enrollment happens on its own. The cloud PC provisions joins and lands in your device list. No imaging station, no autopilot appointment, no courier. What you still own is everything that makes it yours the apps, the settings, the rules. So take stock of what the laptops carry today. Which apps are deployed through Intune already? Those move over with almost no effort because the cloud PC takes the same assignments. Which apps came from a local install, a USB stick, or a person who set up a laptop three years ago and left. Those are the problem. Children find them before the pilot, not during it. Then. Policy mapping. Look at the configuration profiles and compliance rules your laptops follow. Some apply cleanly. Others assume hardware that a cloud PC doesn't have, like a local TPM based check or a battery setting. Don't copy everything across and hope. Walk the list, keep what fits, and write new policy for what doesn't. Use separate groups for cloud PCs, so a change meant for laptops never lands on them by accident. Now here's the upside that surprises support teams. Cloud PCs are easy to reset if a user's desktop gets corrupted or an app install goes bad, you can reprovision it. The machine is rebuilt from the image and policy and the user gets a clean start. No shipping a laptop, no two day wait, and you can restore a cloud PC to an earlier point in time using the snapshots the service takes. So a bad update or a bad afternoon doesn't mean starting over. That changes the support conversation. The question shifts from can we fix this machine to do we need to for a help desk drowning in one off laptop problems? That's a real change in workload, but it only works if the user's data lives somewhere that survives a rebuild files in a synced folder, or a managed share not scattered across the cloud. PCs local disk set that expectation on day one. Which brings up the harder part people. A laptop works on a plane. It works in a cabin with one bar of signal. It works when the home internet drops for an hour, a cloud PC doesn't. No connection, no desktop. So have the offline conversation early and have it honestly, ask each person in the pilot how often they work without a network. Most say never and then remember the train. Some genuinely need offline access, and for them, the answer might be to keep the laptop and add the cloud PC alongside it, using the local and cloud options we covered earlier. Others will accept the trade for the speed and the access. What you can't do is surprise them. A user who finds out mid-flight that their desktop is unreachable doesn't remember the cost savings handle. Those expectations, and a move from physical PCs to windows three hundred sixty five is the gentler of the two paths one segment familiar tools and a rebuild button when things go wrong. But notice what both paths so far have in common. They go from something old to something new. The hardest migrations are the ones that cross between the two products, migrating between windows three hundred sixty five and AVD. Almost nobody picks one product and stays there. What typically happens is simple a team starts on windows three hundred sixty five because it's the fastest way to prove the idea. A few hundred users, a few weeks, no network project. It works. Then the estate grows, a call center joins, and the finance team notices that twelve hundred always on cloud PCs cost more than the pool design would have. Or the reverse. A team builds Azure Virtual Desktop because they have the skills and the pooled math looked good. Then the host pool becomes a second job. The image pipeline needs an owner. Half the users turn out to be knowledge workers who wanted a personal desktop all along. Neither team made a mistake, the workload changed, or the first read of it was wrong. The model they chose fit the demand they could see then. So the real question is how painful the switch will be. And that depends on what you build underneath. Here's the good news. The two products share more parts than the portal suggests. Start with the image. A windows eleven enterprise image, hardened and sealed, can feed both. You can build it once, store it in a compute gallery and use it for cloud PC provisioning and for session hosts. Multi-session images are their own variant, so keep that distinction clear. But the base apps, the agents and the settings travel. Then Intune policy configuration profiles, compliance rules and app assignments apply to a cloud PC the same way they apply to a managed session host with the conditions we covered earlier for Multi-session. If your policies are written against groups and not against individual machines, they move with the user and the groups themselves. Entra groups are the glue. A group that assigns a cloud PC license today can become the group that grants access to an app group. Tomorrow. Same people say membership new target, then profiles. Fslogix is a pooled desktop tool, so a cloud PC doesn't need it. But if your users data already lives in OneDrive and known folders instead of Insider Profile disk, you've done most of the portability work. The data follows the person, not the machine. Now moving a group say the finance review says one department should shift from dedicated cloud PCs to a pooled design. Don't flip everyone on a Monday. Stand up the pool first with the shared image and the same policies. Move a pilot slice. Let them work in both for a short overlap so nothing urgent is trapped on the old machine. Confirm their files and settings landed, then remove the cloud PC assignments in waves and watch the license count fall. The other direction works the same way. Build the cloud PC provisioning policy assigned by group and retire the pool once the last user has moved. Always keep a way back for one full business cycle. What makes this cheap or expensive isn't the move itself. It's the decisions you made months earlier. So design for the switch from day one. Keep images portable. Write policy against groups. Keep user data out of local disks. Name things so you can tell which delivery model a group sits on and never let one product's quirks leak into the shared layers. Do that and a switch stays on option. Skip it, and every change of mind becomes a rebuild, which also means something about where most tenants end up not on one model, on both running side by side with one set of people deciding which user belongs where. That's the hybrid estate, and it needs its own design. Running both the hybrid estate. Most tenants end up here, whether they plan for it or not. One product wins the first project, the second shows up when someone finds a workload. The first one handles badly. By the time anyone draws the picture, both are running, so the question changes. It's no longer which product, it's which users go where, and who decides. The cleanest way to answer that is by persona. We map them earlier. Now you turn the map into an assignment rule. The stable majority goes on windows three hundred sixty five knowledge workers, managers, analysts, people with flat demand and personal desktops, where the persistence is the point where the bulk of the headcount. And they're also the group that costs you the most support time if you get the experience wrong. The pooled or specialist fugue on Azure Virtual desktop shift teams sharing hosts contractors on a locked image. The GPU workloads that need a size. The cloud PC catalog doesn't carry. These are smaller groups, but they're where consumption, pricing, and network control actually pay off. Notice what that split does. It puts each model where its structure fits the work. You stop forcing one product to imitate the other. Now the part that decides whether this stays clean underneath, there should be one identity layer, one entry ID, one set of groups, one set of conditional access rules. A user is a user no matter which desktop they land on, and the people who govern access shouldn't need two mental models to do it. The groups that grant a cloud PC license and the groups that grant an app group assignment should come from the same source and follow the same naming logic. The same goes for policy one policy layer with Intune at the center written against groups instead of machines, compliance rules, app assignments, security baselines where Multisession needs its own handling, you carve out the exception and label it. You don't build a second policy universe. So the picture is simple one identity layer, one policy layer, two delivery layers on top. That sounds tidy on a slide. In practice, there's a trap waiting. It's the duplicate team. Here's what usually happens. The endpoint group owns windows three sixty five. The Azure Group owns AVD. Each builds its own images, writes its own runbooks, picks its own monitoring, and keeps its own backlog. Six months in, there are two image pipelines that differ by a few settings, two sets of naming habits, and two answers to the same security question. Nobody chose that. It grew out of the org chart. Then a user changes departments, moves from a cloud PC to a pooled host, and the handoff takes three tickets across two queues. The fix isn't merging the teams, it's sharing the parts that should never differ. One image standard that feeds both one baseline of agents and settings. One place where decisions about the user experience get made, even if two groups carry them out and one owner for the combined picture. Someone who can say yes or no when a request would pull the two sides apart. Without that owner, every exception becomes permanent. Then comes the discipline that keeps a mixed estate honest governance. You can read across both sides. Start with naming a cloud PC and a session host should tell you what they are from their names alone. Product region. Persona. Environment. If an engineer has to open the portal to learn what a machine does, the convention failed. Then tagging every resource that costs money carries the same small set of tags owner cost center, persona delivery model. Apply them with Azure policy so nobody has to remember and deny the deployments that skip them and cost reporting, which is where the whole design gets tested. Finance doesn't care about product boundaries. They want one view of what desktops cost per user, per department per month. So build that view across both cloud PC license spend on one side, Azure consumption on the other, joined by the persona and cost center tags. When the view is honest, you can see which group is overpaying for its model and you can move them. That last part matters most. A mixed estate only works if you can see it, and seeing it takes more than tags. It takes signals from the machines themselves what's running, what's idle, what's failing, and what users feel when it does. That's monitoring. Running either model well depends on it, and so does running both. 01:12:43 Speaker: Monitoring governance and operations. You can't run what you can't see. And in most states, the first sign of trouble isn't a dashboard. It's a user saying the desktop feels slow. Start with Azure Virtual Desktop. Microsoft ships a workbook called AVD insights, and it sits on top of Log Analytics session hosts, and the service send diagnostic data into a workspace. The workbook turns that into charts. You can actually read connection reliability sign in time, round trip latency, host health, who's connected and where. But the workbook only shows what the data collection sends it. So turn on the diagnostic settings for host pools, workspaces, and app groups and install the monitoring agent on every session. Host miss one pool and that pool is invisible. Nobody notices until the day it breaks. Now what do you alert on? Not everything. An alert that fires forty times a week trains people to ignore it. Pick the signals that map to a user feeling pain connection failures when they cross a threshold sign in duration. When it stretches well past your normal session, hosts that go unavailable or stop reporting host pools running hot on concurrent sessions. Because that's the moment the next person can't get in. Profile disk attach errors because a failed fslogix attach means a user lands on an empty desktop and storage latency on the profile share, which tends to rise before the complaints start. Everything else is a chart you check on a schedule, not a page at two in the morning. Windows three hundred sixty five tells its story somewhere else. Cloud PCs are devices in Intune, so the reporting lives there. You get provisioning status so you can see which assignments failed and why. You get connection and health insights plus a set of utilization signals, how often each cloud PC is used, how long since the last sign in performance indicators that show whether a machine is starved for memory or CPU. That last group matters more than it looks. A cloud PC with no sign in for forty days is a bill with nobody behind it. A cloud PC pinned at the ceiling every afternoon is a person who should be on a bigger size. Both are decisions the data makes for you if somebody reads it. So treat the reports as a work list. Idle machines get a question to the manager. Overloaded machines get a resize request and failed provisioning gets a ticket the same day. Now the other half of operations preventing the mess instead of finding it. Guardrails belong in code, as your policy can enforce rules on everything that runs in your. Subscriptions require tags on host pools and session hosts restrict VM sizes to an approved list, so nobody quietly deploys a very expensive GPU machine for a test limit. Regions require diagnostic settings, so new pools can't skip monitoring. Deny public IPS on session hosts policy catches the mistake at deployment when it costs nothing to fix. Define the host pools, scaling plans and networking as templates in Bicep or Terraform and keep them in source control. Then it changes a pull request with a reviewer instead of a person clicking through a portal, and a pool that drifts from its definition shows up as a difference. You can see cloud PCs get the same treatment, only the tools change. Provisioning policies, user settings, and the Intune rules around them can be exported and managed through graph and scripts, so that a setting isn't a memory in somebody's head. Pair that with conditional access and compliance policy, and the cloud PC side has its own guardrails built from the same habits. Then comes the rhythm tools don't run a program. Cadence does once a month review cost. Open the combined view we built and ask three plain questions. What changed since last month? Which group moved most, and is any of it unexplained? An unexplained jump is almost always a forgotten pool, An oversized host or a stack of idle cloud PCs. Once a quarter right size. Look at real utilization against what you provisioned. Shrink the hosts that never fill. Move the cloud PC users who barely connect. Resize the ones that are always maxed out and revisit the commitments because a reservation bought for last year's demand can lock in the wrong answer. That's the loop. Measure, alert, enforce, review, adjust. And once you can run either model well, the last job is to decide with a method which one goes where. Now we pull it together into one framework, the architect's decision framework. Five questions, not fifty, not a feature matrix, five questions answered in order. And each one pushes you toward a model. Question one who should own the infrastructure? Be honest here, not who could own it. Who should? If you want Microsoft to run the machines, patch the platform and keep the life cycle out of your backlog, that points to windows three hundred sixty five. If you want control over hosts, images, scaling and placement, and you accept the work that comes with it, that points to Azure Virtual Desktop control, an effort travel together. You don't get one without the other. Question two is demand flat or does it move flat? Demand means the same people connect at the same hours most days. That's a per user price doing what it was built to do. Moving demand means peaks, valleys, shifts, seasons, hours nobody uses. That's where paying by consumption and sharing hosts starts to win. Look at real connection data if you have it. Guessing. Here is how people end up paying for idle desktops. Question three what network and compliance boundary must the desktop live in? Some workloads can sit on a Microsoft hosted network and nobody cares. Others must reach a database over a private link, stay in one region or pass an audit that names the subnet. If the boundary is strict, you need the options that give you network control. That can be a cloud PC on your own connection, or a host pool in your own subscription. If the boundary is loose, the simpler path stays on the table. Question four do users need personal persistence or shared disposable sessions? A person who customizes everything and expects it untouched tomorrow wants a personal desktop. A person who opens two apps for six hours and leaves once a clean session. Persistence is a feature for the first group. For the second, it's cost and risk. Question five what skills does your team really have today? Not what you plan to hire for. What sits in the room right now? Intune and entra. Experience points one way Azure networking, automation and infrastructure as code point the other. A good design that your team can't operate is a bad design. Now, a simple way to score it. Take each question and give it a lean. Mark it to what? Windows three sixty five toward Azure Virtual Desktop or neutral. Microsoft owns it. Flat demand. Loose boundary. Personal persistence endpoint skills. Those lean one way your team owns it. Moving demand. Strict boundary shared sessions Azure skills those lean the other then count not as math as a signal but apply two rules. First question three can veto. If your boundary can't be met by one option, the score doesn't matter. Compliance wins over preference every time. Second question five can veto two if the skills aren't there and can't be hired in time, drop the model that needs them and revisit when that changes. Now read the result four or five leaning toward windows three sixty five default to windows three sixty five. It's the lighter operating model, and your inputs say it fits four or five. Leaning toward Azure Virtual Desktop. Default to AVD and budget for the engineering. It asks for a split, say three and two or lots of neutrals. Don't force a single answer. That's your hybrid estate split by persona. As we covered and score each group on its own. And one more case when the vetoes disagree with the count, trust the vetoes and write down why that note will matter in a year. When someone asks why you picked the harder path. A framework is only useful if it survives contact with a real organization with real constraints and messy answers. So let's run it against four of them. Framework in action four scenarios. Scenario one a professional services firm. Four hundred users. Consultants, analysts, a finance team, a few partners. Roles are stable. People connect most days at similar hours. Everyone wants a desktop that looks the same tomorrow. The firm has a small IT team that lives in Intune and entry ID, and nobody on it has built a host pool. Run the questions. Microsoft should own the infrastructure because the team is small. Demand is flat. The network boundary is loose. Personal persistence matters. Skills lean endpoint five for windows three sixty five, the decision is windows three sixty five with no argument. What could change it? A single audit rule that demands private network paths to a client system. If that shows up. The film moves to a cloud PC on its own network connection. Same product. Different network path. Scenario two A retail chain with a call center. Seasonal hiring shifts that swing from forty agents at six in the morning to three hundred at noon. Demand moves and it moves hard. Sessions are short. Nobody needs a personal desktop because the desktop belongs to the shift. The team has a few Azure engineers and a lot of seasonal staff who need to be live by Friday. The score leans toward Azure Virtual Desktop pooled hosts, a scaling plan that follows the shift schedule and a locked image. You pay for concurrency, not for headcount, but look at the shape of the week. If the shifts are predictable and the Azure team is thin. Windows three hundred sixty five frontline becomes a real option. Microsoft runs the machines and you skip the pool engineering. So what flips the call? Team capacity with engineers who can tune a pool, go pooled without them. Go frontline and accept a little less flexibility. Scenario three A software company, developers a rotating set of contractors and a few engineers who train models and need serious GPUs. Three personas. So three answers don't force one. Developers want full machines with admin rights and a custom toolset. Cloud PCs fit and you reprovision when a project ends. Contractors get a locked pooled desktop with a standard image where nothing personal is worth keeping. That's cheaper to run and it resets. Clean the GPU group goes on Azure Virtual Desktop because the hardware they need lives in the Azure VM catalog, and you can place it near the data. That's a hybrid estate by design with one identity layer under all of it, the thing that could change it, the GPU catalog. If the cloud PC list adds the size those engineers need, you could fold them into the simpler model. Check it every quarter scenario for a regulated organization, a health insurer say strict network isolation audit trails that name subnets and data that can't leave one region. Here. Question three decides everything. The desktop must live inside a boundary. The auditors can inspect. A Microsoft hosted network doesn't meet that. So windows three sixty five is only on the table with your own network connection, and Azure Virtual Desktop sits in your subscription by default. Now question one and question five do the real work. If the security team wants full control over hosts logging and egress and the Azure skills exist, the decision is a v D. If the team is endpoint heavy and the boundary can be met through a cloud PC on a connection you own, windows three hundred sixty five can pass the audit with less to run. Write the reasoning down. Either way, the auditor will ask what could change it. The audit scope. A new rule on session recording data, residency, or logging depth can rule out a model that passed last year. Look at what happened in all for the product name. Never decided anything. A boundary did a demand, patented, a skills gap did. And that matters because good decisions still fail in the same predictable ways. Not in the choice, but in what happens after it. Before we close, let's talk about those mistakes. Common mistakes that break cloud PC projects. Most failed projects didn't fail on technology. They failed on a decision made in the first month, and nobody went back to question it. The first one is the most common choosing by feature list. Someone builds a comparison sheet, rows for GPU support, rows for multisession, rows for auto scale green check marks on one side, a few gaps on the other. The sheet feels rigorous, but every row describes what a product can do. None of them describe who has to run it. A feature you can't operate is just a line on a page. Start with the operating model. Use the feature list later to check the details. The second mistake is timing skipping the network and identity design until after the pilot. The pilot goes well. Ten users a Microsoft hosted Network Cloud identities. Nothing to reach on premises. Everyone's happy. Then production arrives. The finance app needs a private path to a database. The domain controllers sit in a data center with no route to the new subnet. Conditional access rules block half the sign ins because nobody tested them against the session host. Now the project stalls. The pilots success looks like a mirage. Design the network and identity first. Make the pilot prove those, not just the desktop. Third, and this one belongs to AVD. Underestimating image management teams budget for the pool. They budget for the VMs, the storage, the scaling plan and they forget the image has a life of its own. Windows ships updates every month. Apps need patches. Agents need new versions. Each of those is a rebuild, a test, and a rollout. It never stops without a pipeline and an owner, the image goes stale. Hosts drift a bug that exists on three hosts but not the other nine becomes a week of confused tickets. Treat image work as a permanent job, with hours assigned to it, not as a setup task. Fourth, and this is the windows three sixty five version of the same blind spot over buying licenses for users who connect rarely. It's easy to do. Someone says. Everyone in the department gets a cloud PC. The order goes in, but usage data tells a different story. A good share of those people open the desktop twice a month, maybe less. Each one costs the same flat fee as the person who lives in it all day. A per user price punishes low usage because it can't flex. Measure first check actual sign ins. Give a cloud PC to the people who use one. For the occasional user, a shared or pooled option costs far less, and the fifth mistake sits under all the others, treating the cloud desktop as a lift and shift. Instead of a redesign, you take the old desktop, forty apps, mapped drives, logon scripts, local admin rights. You copy it into the cloud, it runs, and now you pay monthly for every bad habit you used to carry for free. The script still called servers that moved. The apps still bake in assumptions about local disks. The profile is still enormous. A desktop that was merely annoying on a laptop becomes expensive in Azure. The move is your one chance to ask what each piece is for. Drop what nobody can explain. Look at the pattern across all five. Each one is a question skipped early. Who runs it? What boundary it lives in? Who owns the update loop? Who actually uses it? What should be left behind? The tools were never the problem. The order of the questions was. Which leaves the practical part. You've heard the models, the costs, the traps. So what do you actually do on Monday morning? What to do next? A practical starting plan. Start with people, not products. Open a spreadsheet and list your personas, not job titles, patterns of work. Who connects every day and who connects twice a month. Who needs an app that only runs next to a database? Who works on a train, and who works on shared hardware at a front desk. Five or six honest groups will do. If you have forty you're describing individuals, then measure. This is the step team skip because it feels slow and the pilot feels fun. Pull real sign in data for the last ninety days. Hours per day. Days per month. Peak concurrency at the worst hour of the worst week. Pull the app inventory to mark what people actually open, not what the deployment tool says is installed. A number from the data beats a number from a manager's memory every time. Now you have something the product pages can't give you a picture of your own demand. Next comes the pilot. Here's the rule. Run one on each model with the same user group. Same people. Same apps. Same for weeks. Not windows three hundred sixty five for the friendly team and Azure Virtual Desktop for the engineers. That comparison tells you about the teams, not the models. Pick a group of thirty or forty that reflects a real persona. Give half of them one model and half the other, or run them in sequence two weeks each. If the group is small, timebox it. A pilot with no end date turns into production by accident. Nobody ever made that decision on purpose. Include the users who complain. They find the broken parts faster than any test plan while the pilot runs. Collect three kinds of evidence. Write the method down on day one so nobody changes the scoring halfway through cost first. Not the list price. The real monthly number for each model storage, networking, monitoring and the hours your team spent keeping it alive. Track those hours. Honestly, ask the engineers to log them even roughly. Then support tickets. Count them per user, per model. Read what they say. Slow logins, app failures. A reset that took five minutes versus a fix that took two days. The ticket queue is the cleanest signal you'll get of what each model costs to live with, and then satisfaction. Ask the users, short and plain. Does it feel fast? Does it behave the same each day? Would they keep it? Three questions. Beat a twenty page survey. Nobody finishes. Put the three side by side in one table per persona. Sometimes the numbers agree and the decision is easy. Sometimes cost points one way and satisfaction points the other. That's fine. That tension is the decision. Now you can see it instead of arguing about it. Then the last step, the one nobody wants to do, write it down one page. The persona, the model you chose and the reasons in plain words, the vetoes that applied the numbers from the pilot, and then the part that gives the page its value, the trigger conditions for revisiting it. If cloud PC idle rates pass a set percentage review if the pools concurrency doubles review if a new audit rule lands, review if the team gains or loses its Azure engineers review. A decision with no triggers hardens into policy. A decision with triggers stays a decision that page will save you. One day in a meeting when somebody asks why you picked this and nobody remembers. So that's the plan. Count your people. Test both models on the same users. Compare the evidence. Write down when you'll change your mind. Which brings us to the close. Conclusion. The model, not the product. Go back to where we started. The question was never which product is better? Windows three hundred sixty five and Azure Virtual Desktop give the user the same windows desktop. What they don't share is who runs the control plane and how demand behaves. Once real people start connecting flight demand, a small team and a loose boundary lean one way moving demand strict network rules and engineers who can run a platform lean the other. And most tenants in the end need both. Here's the consequence pick by product name and you inherit the wrong model. Not for a quarter. For years, the licenses, the network, the image pipeline, the team that has to run it all built around a choice nobody examined. If this episode helped you think through a cloud PC decision, leave a review on the podcast. It helps other architects find it before they sign the order. And if you want more of this, connect with me on LinkedIn. Tell me which topic should come next. One last note cloud PC projects almost always sit next to a mailbox or tenant migration. Stellar Migrator for exchange is one tool in the Microsoft ecosystem built for that kind of work. Worth a look when yours comes up. Thanks for listening.