Intune and Autopilot at Scale: What Breaks in Real Rollouts

M365 FM - Intune and Autopilot at Scale - What Breaks in Real Rollouts

00:00:00 Speaker: Ten devices work. You watch them go through autopilot, sign in, wait, desktop. Everyone's happy, so you scale up and ten thousand devices start behaving in ways nobody saw coming. If you want to understand why that happens, subscribe to this podcast. We break down why Intune and Autopilot rollouts fail after the pilot and what to do about it. Here's the claim for today. Autopilot doesn't fail because of bugs. It fails because of the model behind it. The assumption that a device is a thing you configure instead of a sequence you orchestrate. We'll walk through that in order. Enrollment paths app order the enrollment status page, update rings, troubleshooting, reporting, and the habits that keep a fleet healthy. But first, a quick note from the sponsor sponsor segment. Stellar Migrator for exchange. Device rollouts rarely happen alone in most organizations. While one team is pushing laptops through autopilot, another team is moving mailboxes. Same users, same weeks, same help desk taking the calls. And when both waves land on the same person, nobody can tell which change broke their morning. Stellar migrator for exchange is built for the mailbox side of that problem. It's a migration tool that moves mailboxes between exchange environments, including to Microsoft three hundred sixty five, and lets you plan batches and control when each one runs. That control matters. Here, you can schedule mailbox moves around your device waves instead of on top of them. Now back to the core problem. Why the pilot lies? Why the pilot lies to you. Think about where a pilot actually runs a clean network hardware. You picked yourself, users who volunteered, who know your name, and who will wait patiently when the screen sits there for twenty minutes. That's not your fleet. That's the best possible version of your fleet. And it's small. Fifty devices, maybe one hundred. What does a group that size test the happy path one route through the sequence taken fifty times with conditions you controlled. It doesn't test the distribution of failure because failure isn't one thing. It's a spread a few devices on an old firmware version, a few behind a proxy that rewrites certificates, a few users who close the lid at the wrong moment, or unplug the network cable because the screen looked frozen. Each cause is rare. None of them show up in fifty devices. Now look at what scale adds hardware models. Your pilot had two. Your fleet has eleven bought across four years from three vendors, each with its own firmware and its own driver quirks networks. Your pilot used the office your fleet signs in from branch sites, home routers, hotel WiFi and warehouses where the connection drops every few minutes. Locations, different regions, different languages, different time zones, different local rules and users. Some wait, some don't. Some restart the device halfway through because that's what people do when a screen stops moving, every one of those is variance and the pilot removed almost all of it. So here's the assumption sitting underneath most rollout plans, if it works ten times, it works ten thousand times. That assumption is broken. Not because the tools are unreliable because of arithmetic. Say your failure rate is one percent. That sounds fine. In a pilot of fifty, you expect half a failure. You might see none at all and declare victory. At ten thousand devices, one percent is one hundred devices, a hundred people with no working laptop, one hundred tickets, one hundred conversations where someone asks why the pilot went so well and one percent is the optimistic case. Many rollouts seem more. Once the second and third waves hit hardware and sites, the pilot never touched the pilot didn't lie on purpose. It answered the question you asked does the happy path work? Yes. It never claimed to answer the harder question what does the rest of the distribution look like? So how do you see that distribution? You can't find it by testing more devices on the same path. You find it by looking at the path itself. Every step the device takes, every handoff, every dependency, and every place where one device in one hundred might go wrong. That means you have to see the sequence. The sequence nobody draws. Ask a team to draw their autopilot process on a whiteboard. Most of them draw one box. It says autopilot, maybe an arrow to a second box that says desktop. That's the problem. Autopilot isn't a feature you switch on. It's a chain of events, and each one depends on the one before it. If a link breaks, the chain doesn't bend. It stops. So let's draw it slowly because the order matters. First, the hardware hash, a fingerprint of the device pulled from the machine itself, then registration where that fingerprint is uploaded to your tenant, then profile assignment where the tenant decides what this device should become. Then the device powers on and it needs a network. Then it joins entra, then it enrolls into Intune as a managed device. Then the enrollment status page starts and the device pulls policies, then apps. And only after all of that does a person see a sign in screen. They can actually use ten links, ten places where something can go quietly wrong. Now look at who owns each one. The hardware hash often belongs to a procurement team or a vendor, or whoever unboxed the device. Registration belongs to whoever has the right admin role that week. Profile assignment belongs to the endpoint team. The network belongs to the network team who may not know autopilot exists. Intra join belongs to the identity team. Enrollment and policy belong to endpoint again, but maybe a different person. Apps belong to whoever packaged them who may have left the company six or seven owners, one user waiting at a screen and each link runs on its own. Clock registration can take minutes or hours. Group membership updates on its own. Schedule a network request times out in seconds. An app install runs for as long as it runs. Nothing in the chain waits politely for the slowest part to finish unless you told it to. Each link also fails in its own way. A bad hash Looks like nothing happens. A bad network looks like a spinner. A bad join looks like an error code. A bad app looks like a screen stuck at sixty percent. Same user, same complaint. Four different causes. So here's what typically happens. Every team owns one link. They test their link. It works, and they assume the others do too. The identity team checked the Join the Endpoint team checked the profile. The packaging team checked the app. Everyone is right about their own piece, and the device still doesn't reach the desktop because no one owns the sequence. That's where it breaks, not inside any single link in the handoffs between them. So I want to give you a simple way to hold this in your head. Three words event, reasoning, orchestration, event is what happens. The device boots, the hash gets matched. The join request goes out. These are facts you can observe. Reasoning is why the next thing happens. The tenant sees a matching hash, so it looks for an assigned profile. The profile says join entra. So the device asks for a token. Each step follows from the one before, and each step has a rule behind it. Orchestration is the part nobody does. It's deciding the order on purpose which events must finish before the next one starts. Who watches each hand off? What happens when one link runs late? Most rollouts have plenty of events. Some have reasoning buried in documentation. Almost none have orchestration. And this is the model problem showing up in a small way. If you think of a device as something you configure, you list settings. If you think of it as a sequence, you list dependencies, owners, and timing. Those are very different documents. One of them tells you what the device should look like when it's finished. The other tells you what has to be true at every moment on the way there. So let's walk the chain from the beginning, because the first link is where a device enters your system at all and there's more than one door. Enrollment paths. Choosing the door. Four doors into autopilot. User driven. Self deploying. Pre-provisioning. Most people still call it white glove and existing devices. The ones already in the field that you bring in without wiping them. Each one answers a different question who touches the device and when? Start with user driven. The device ships to a person or to a desk. They open the box, connect to a network, and sign in with their work account. The device learns who it belongs to at that moment. That's the appeal. Nobody in it has to handle it. The cost is that every setup step now runs in front of the user, on their network, on their time. If something is slow, they watch it be slow. Self-deploying flips that no user signs in at all. The device boots, reaches the cloud, joins and configures itself with no one attached to it. That works for kiosks, shared machines, and anything that belongs to a place instead of a person. The trade is that you give up user context. No user means no user targeted policies, no personal apps, and a stricter hardware requirement because the device has to prove what it is on its own. Pre-provisioning moves the hard part. Earlier, a technician or a partner in a warehouse runs the device side setup before it ever reaches the user. The heavy apps and policies land first. When the user finally gets it, they only do the last part less waiting for them, more work and more responsibility for whoever runs that first phase and existing devices. That's the door people forget machines already deployed joined the old way that you want under Intune without a reset. It's a migration path, not a new device path. And it has its own rules about what carries over and what doesn't. So here's the pattern. Every door trades control for speed or the reverse. User driven is fast to start and hard to control. Pre-provisioning is slow to start and easy to control. Self-deploying is very controlled, but only for a narrow kind of device. There's no door that gives you both. That's why the real decision isn't. Which feature do we turn on? It's a question about people who will physically or digitally touch this device before it's useful, and at what point in the sequence. Answer that and the path mostly picks itself, but in reality, most teams don't ask it. What typically happens is this they build one path, usually user driven, because it's the one in the quickstart guide. It works in the pilot, so it becomes the standard, and then it gets pointed at every kind of device in the company. That's where it breaks. A warehouse scanner doesn't have a person at a desk with fast Wi-Fi. A reception kiosk doesn't have a user to sign in. A salesperson who ships a laptop to a customer site doesn't want to sit through forty minutes of setup in a hotel room. One path, three very different populations, and the same failure ticket opened over and over to map the doors to the people, office staff, the ones with a desk and a stable network can often take user driven. It's simple and the wait is tolerable. If the setup is heavy, Pre-provisioning gives them a faster first day. Shared devices. The ones that rotate between users on a shift tend to fit self deploying or a shared device profile. The device belongs to the location, not the person. Kiosks are the cleanest case for self deploying. Fixed purpose. No user, no personal data. Configure the sequence once and let it run. Field workers are the hard one. Unpredictable networks. No it nearby. No patience for a long first boot. This is where pre-provisioning earns its cost. Do the long part somewhere controlled and ship them a device that's nearly done for populations, often three or four different doors. That's not extra complexity. It's the actual shape of your fleet drawn honestly. And once you've picked a door, a new question shows up right behind it because no path works unless the device already exists in your tenant. With an identity, the cloud can recognize hardware, hash registration, and identity drift. Autopilot can't act on a device it doesn't know. So before any door opens, the device needs a record in your tenant. That record is built from the hardware hash, a long string pulled from the machine itself, made from details like the serial number, the hardware makeup, and the identifiers inside it. The cloud reads that string and says, I know this one. Where does the hash come from? Three places. First, the manufacturer. Many OEMs can register devices for you at the point of sale, so the record exists before the box ships. Second, a reseller or partner. They do the same thing on your behalf, usually through a portal and a purchase order. Third manual harvesting someone runs a script on a machine that's already in hand, exports a file and uploads it by hand. Each source has its own timing and its own quality. The vendor path is clean when it works, but it depends on the order being tagged correctly at purchase. The partner path depends on a person remembering to submit. The manual path depends on a person remembering everything. And here's what typically happens. Records pile up from all three over years and nobody reconciles them. You get duplicates. The same serial number shows up twice, once from the vendor and once from a manual upload someone did just to be safe. You get stale records devices that were retired and recycled two years ago, still sitting in the list with a profile attached, and you get wrongly tagged records where the device was registered with the wrong label, so it quietly lands in the wrong place. None of these throw an error. They just sit there looking fine. Now add reuse because fleets don't stay still. A laptop comes back from an employee who left it, wipes it, hands it to someone new, and expects the sequence to start clean. Often it does, but sometimes the old record still points to the old purpose, and the device behaves like the person who had it last. Then there's hardware repair. A technician swaps the motherboard to the user. It's the same laptop, same lid, same sticker, same asset tag to the cloud. It's a different machine because the hash was built from components that just changed. The old record now describes a device that no longer exists, and the real device has no record at all. That's identity drift. The thing in your hand slowly stops matching the thing in your tenant, and it's easy to miss because every individual piece looks reasonable. The device powers on the record exists. They just don't point at each other anymore. So how does the cloud decide what a registered device should become? Mostly through group tags. A group tag is a short label you attach to the record. It looks small, almost like a note, but it's the real routing mechanism. Dynamic groups read that tag and membership in those groups decides which deployment profile the device gets. Tag its sales, and it falls into the sales group tag at kiosk and it falls into the kiosk group tag it wrong or forget to tag it and it falls nowhere. So the tag isn't metadata, it's an instruction. And because it's just text typed by whoever registered the device, it's one of the easiest places for the sequence to go wrong a capital letter, a trailing space, a tag spelled the old way after the naming convention changed. Each one means a device that matches no rule. The moment this breaks is when the device exists, but nothing is assigned to it. Picture that from the user's side they unbox the laptop. They connect to WiFi. They expect the setup experience. Instead, they see the ordinary windows setup, the consumer version, asking them to create a personal account. Nothing in the sequence ever started because as far as the tenant is concerned, no one told this device what it was supposed to be. No error, no log entry that says your tag was wrong. Just absence. That's why registration deserves an owner, not as a one time import, but as a record. You check against reality. Do the serial numbers in the tenant match the devices you actually have? Do the tags match your current naming? Are retired devices removed because registration only answers one question does the cloud know this device exists? It doesn't answer the harder one. Does the cloud know what this device is supposed to become? That second answer lives in the deployment profile, and getting a device to that profile depends on a clock that most teams assume runs faster than it does. Deployment profiles and dynamic group delays. A deployment profile is a set of instructions. Join. Enter. Skip these screens. Name the device this way. Set the language, the region, the user's account type, but the profile doesn't attach to the device directly. It attaches to a group and the device only gets the profile if it's a member of that group. So the chain looks like this. The record has a tag. A dynamic group reads the tag. The group adds the device as a member. The profile sees the member and applies three hops and the last two happen on the tenant's schedule, not yours. Here's the assumption that gets teams in trouble. They think dynamic groups update instantly. They don't. Membership is processed in the background. Sometimes it lands in a few minutes. Sometimes it takes much longer, especially when the tenant has a lot of dynamic groups or when someone just changed a rule and the whole group is being recalculated. There's no promise that a device registered at nine is a member at nine oh five, and that's fine until the device is already powered on. Picture the timing. Someone uploads a batch of hashes in the morning, they tag them, and they ship a few laptops that same afternoon. Because the users are waiting, the laptops arrive, the user connects to the network and starts set up, but the group hasn't caught up. The tenant looks at the device and says, no profile here. So the user gets the regular windows setup. Personal account prompts no company branding, no sequence at all. That's a race condition. Two things are running at the same time, and the outcome depends on which one finishes first, the device boots or the group updates. When the group wins, everything works. When the device wins, you get a ticket and it's maddening to diagnose because it's not consistent. Half the batch works, half doesn't. Then you check. An hour later, every device shows the right group and the right profile, and you can't reproduce anything. The evidence disappeared because the delay itself went away. The usual fix is a quiet one. Someone resets the device and tries again. It works the second time, nobody writes down why. Now suppose the timing is fine. The profile applies. There's still a second set of surprises, and they live inside the profile settings. Naming templates. For one, you set a pattern so every device gets a name like the company prefix plus the serial number. Sounds simple, but computer names have length limits, and serial numbers on some models are long, the template gets cut short, or the name fails, or two devices from different vendors end up looking unrelated even though you meant them to match. Nobody notices until someone searches for a machine by name and finds nothing. Language and region. For another, the profile can set both, or it can let the user choose. If you leave it open on a fleet that spans countries, a user in one country can end up with the wrong keyboard layout and the wrong date format, and not know how to fix it. If you force it, you can give a user in a different country a language they can't read on the first screen. And then there's the skip settings. Hide the privacy screens. Skip the license terms. Hide the change account options. Each one removes the screen the user would have seen. That's good for speed, but it also removes the user's ability to correct a mistake. If the device is going to the wrong person, there's no screen left where anyone can stop it. None of these are bugs. Everyone is a setting doing exactly what you told it to. That's the pattern across this whole link of the chain. The behavior is correct. The assumptions behind it are wrong. So where does this knowledge belong? Not in a hallway conversation. Not in the head of the one admin who was there when it broke. It belongs in the runbook. Write it down as timing. How long after registration do we wait before shipping a device? How do we check that the group has the device before it leaves the building? Who confirms the profile is assigned and where do they look? What's the rule for the naming template and who approves the change to it? Those are small questions, but they turn a race into a checklist. The delay doesn't go away. You just stop betting against it. Because even when the device is registered, tagged, grouped, and assigned a profile, nothing has happened yet. The instructions are sitting in the cloud. The device is still a box on a desk, and to follow any of them, it first has to reach the cloud.

00:16:34 Speaker: Does network reality, the quiet cause of most failures, most autopilot failures that look like Intune problems are network problems. Not all of them, but more than anyone expects. And the reason is simple the device reaches out to the cloud many times during setup, and every one of those requests has to get through whatever sits between the machine and the internet. On a lab network, nothing sits there on a real one. A lot does start with the proxy. Many companies route traffic through one, and the device has to know how to talk to it before any user has signed in. If the proxy needs a login or a setting that only arrives with policy, the device can't reach the very service that would send it. That policy. It's a loop with no way in. Then SSL inspection. The firewall opens encrypted traffic, reads it, and resigns it with its own certificate. A fresh device has never heard of that certificate, so it looks at the response and decides something is wrong. The connection drops from the user's side. The screen just stays on. Please wait. And firewalls. Generally, someone at some point wrote a rule that blocks traffic they didn't recognize. Autopilot traffic looks unfamiliar, so it got caught. Then the captive portal. the page that asks you to accept terms before the wi fi works. A person sees it and clicks a device at first, but sees nothing because there's no browser yet. It sits there, connected with no actual internet. Now here's where teams get it wrong. There's a list of endpoints, autopilot needs published, specific and long names for the enrollment service, the entry sign in, the update delivery, the app downloads the time service. But in reality, what gets allowed is usually a shorter list. Someone opened the main Microsoft addresses, tested a device, saw it work, and closed the ticket. The device got through the first few steps. The missing endpoints only matter later when a specific app downloads or a specific policy applies, or a specific check runs so the failure doesn't show up at the start, it shows up at sixty percent on one device model in one building. That's the difference between the endpoints the vendor requires and the endpoints someone allowed. They overlap. They're not the same list, and nobody owns the gap between them because the network team never saw the requirements, and the endpoint team never saw the firewall. Now move the device. Not every first boot happens in your building. Someone ships a laptop to a new hire. They plug it in at home or at a hotel or at a customer site. They connect to guest WiFi. The kind with a splash page and a time limit. The device has no way to accept that page. Provisioning starts, stalls and then quietly fails when the connection resets halfway through a long download. Even at home, it's not clean. A cheap router, a crowded signal, a kid streaming in the next room, autopilot downloads a lot and a weak connection turns a twenty minute setup into two hours or into a timeout and the VPN. Many companies assume the user will connect to it, but at first boot, there's no VPN client yet. It's one of the apps that's still waiting to be installed, so the device is trying to reach internal resources through a tunnel that doesn't exist, and the sequence waits for something that can't arrive until later. One more layer and it's the quietest one. Time certificates only work inside a window of dates. The device checks the clock to see whether a certificate is valid. If that clock is wrong, even by a little, everything built on trust starts to fail. Sign and tokens get rejected. Secure connections refuse to open, and a fresh device straight from a shelf where the battery ran flat, can wake up thinking it's the wrong day. The error says certificate problem. The cause is a clock. Two different layers, one confusing message. So what do you do with all this? You treat the network as part of the sequence, not as the ground it stands on. Test first boot from a guest network. Test it from a home connection. Test it behind the real proxy. With the real inspection turned on, compare the firewall rules against the full published list, line by line. Because when the device can't reach the cloud, nothing after that step matters. No profile, no policy, no app. But suppose the network is clean, the device is online, it's reached the service, and it's ready for the next decision. Who does this device belong to? Join types. Enter, join, hybrid join and the cost of hybrid. Two ways to answer that question cloud only or Hybrid cloud only join is clean. The device joins enter directly. It talks to the cloud. The cloud talks back and nothing in your building gets involved. A laptop on a kitchen table in another country behaves the same as one in your head office. One boss and the boss lives in the cloud. Hybrid join is different. It's a bridge. The device joins your on premises active directory first, then gets registered with entra two. So it exists in two directories at once. Companies pick this because they still have things that depend on the old world file shares that authenticate with domain credentials. Apps that read group policies, servers that only trust, machines they can see in ad. That's a real reason, but a bridge needs support at both ends. Here's what hybrid requires, and the list runs longer than most people expect. The device needs line of sight to a domain controller, not eventually. During setup, a laptop at a home kitchen table with no VPN can't see your domain controller and the join can't finish. Same VPN problem from the network section. Now sitting inside the identity step. Then there's the Intune connector, a piece of software on a server in your environment that creates the computer object in AD on the device's behalf. Without it, the cloud has no way to touch your directory. That server has to be up, patched, and able to reach both sides, and the OU planning the connector has to know which organizational unit gets the new computer object. Pick the wrong one or one with a stray policy attached, and the device lands somewhere with settings nobody intended. Pick one the service account can't write to and the object never gets created. Which brings up the failure that shows up more than any other. The connector service account passwords expire. Permissions get trimmed during a security cleanup, someone renames an OU or moves it, and the account loses its rights without anyone noticing. The connector keeps running so the server looks healthy, but every join request quietly fails behind it, and the symptom lands on the user. A device that sits at the join step then throws an error code that says almost nothing about add permissions. That's the pattern. Hybrid doesn't add one new thing that can break. It adds a whole second chain next to the first one a domain controller, a network path, a connector, a service account, an OU, a sync cycle between the two directories. Why hybrid doubles? The number of things that can break is simple arithmetic. Every link in the cloud only chain still exists, and now there's a matching set on premises owned by different people running on different clocks with different ideas of what counts as healthy. So the real question isn't which model is better, it's why you're choosing one. Choose hybrid for dependency reasons. A specific app that needs a domain joined machine. A specific service that checks. Add a specific policy you can't replace yet, right? The dependency down with the name next to it. Then ask what it would take to remove it. Don't choose hybrid out of habit because that's what usually happens. The company already has Add. Everyone already knows how to join a machine to it, so hybrid becomes the default and nobody asks whether the dependency still exists. Years later, the dependency is gone and the fleet is still paying for a bridge that doesn't lead anywhere. If you can go cloud only for a population, do it for that population first. Keep hybrid only where something real is holding it in place. Either way, the device now has an identity. It belongs to someone, it's registered and it's about to be told what to install. And that's where enrollment moves into the part. Everyone fears the enrollment status page. What it actually does. Most people call it the progress screen. That's the first mistake. The enrollment status page isn't there to show progress. It's there to hold the door shut, a gate that stays closed until the things you marked as required are finished. The percentage bar and the little list of steps are a courtesy painted on top of a lock. Once you see it as a lock, a lot of confusing behavior starts to make sense. So what is it guarding a device that's still being built. Policies are landing, certificates are arriving. Apps are installing. If the user got to the desktop in the middle of that, they'd be working on a machine that isn't ready. No security agent yet, no VPN client, no mapped drives. So the page says wait here until the setup is done. Then you can go that way. It happens in two phases. First, the device phase. This runs before anyone signs in the device, identifies itself, joins, and pulls everything that belongs to the machine, not the person. Device targeted policies. Device. Targeted apps. Certificates. Security tooling. This is the part that happens even on a kiosk with no user at all. Then the user phase. It starts after the person signs in and handles everything tied to them, their apps, their profile settings, their user targeted policies, two phases, two sets of things to wait for, and two separate chances to get stuck. Here's where it gets sharper. Teams often don't know which phase an item belongs to. They assign an app to a user group and expect it to install during setup, but the device phase is already over by the time the user shows up so the app lands later in the user phase or after the gate has opened. Same app, different timing depending on a targeting choice someone made months ago. Now the important part the gate blocks the user, not softly. It really does. Until every item you marked as required finishes. The person can't move forward. They can't skip it. They can't open a browser. They can't check their email on their phone and come back. They're standing in front of a screen that says working on it. And that's why one slow app turns into a rollout problem. Think about what the page can't tell you. It doesn't say why something is slow. It doesn't separate a download that's crawling from an installer that's hung from a policy that never arrived. It just shows the same screen at the same percentage for as long as it takes. So to the user, every delay looks identical, the bar isn't moving, therefore it's broken. And to the help desk, which only gets the phone call. A large app on a slow connection is indistinguishable from a real failure. That's the trap. The page makes patients look like a malfunction, and people respond the way people do. They wait ten minutes, then they press the power button. Then they try again and start the whole sequence from the top. Which brings us to the timer. The enrollment status page has a timeout a number of minutes. You choose. If the required items aren't done by then, the page gives up waiting and does something else. What it does depends on how you set it. You can let the user continue anyway. You can show an error and let them reset the device, or you can block them completely and leave them with nothing but a failure message. Each choice has a price. Let them continue and they get a device that's only partly built, missing apps, missing policies, and no clear sign of what's absent. Show the error with a reset and you've turned a slow install into a restart from scratch. Block them entirely and you've guaranteed a ticket, and the default timeout is shorter than many teams assume. It was tuned for a lean setup pile on a dozen required apps, a few big installers, and a slow branch connection, and the timer expires before the work could ever have finished. So the timeout isn't measuring failure, it's measuring whether your sequence fits inside a number someone picked. But notice what all of this depends on. The gate itself is simple. It waits for a list, and the list is whatever you put on it. A page that waits for ten small things behaves nothing like a page that waits for forty large ones. The gate only matters because of what you put behind it. ESP failures and the anatomy of a timeout. Every ESP failure starts the same way a screen stops moving, and that screen tells you exactly which stage it stopped in. Most teams ignore this clue, but it's the first useful piece of information you have. Stuck at identifying the device is trying to figure out who it is and which profile applies. This points back to the earlier links the record, the group, the network. Nothing has been installed yet, so the page has nothing to wait on except a conversation that never finished. Stuck at device setup, the machine is joined and enrolled, and now it's pulling everything that belongs to the device policies, certificates, the apps you marked as required. This is the longest stage, and it's where most users give up stuck at account setup the user has signed in and the page is waiting on everything tied to them. Fewer items usually, but they depend on the user's token, their license, and the device phase. Having actually finished three labels, three different places to look, but the user reports all three the same way it's frozen. Now let's talk about the timeout. When the timer runs out, the page shows an error and that error feels like the answer. It says set up failed or it says something took too long. So the team starts asking what went wrong? At the moment of the timeout, that's the wrong question to ask. A timeout isn't a cause. It's a symptom. It tells you the sequence didn't finish inside a certain number of minutes, but it says nothing about why the download could have been slow and an installer could have hung a policy could have never arrived. All three end with the same message at the same minute, so the real work starts before the timeout, not at it. What was the page waiting on when time ran out? Which item was last to report in? That's the thread you need to pull. And here's where a quiet mistake lives. ESP waits on the items you assigned, not the items you intended. Those sound the same, but they aren't. You might believe the page is tracking five apps the five you cared about, but the page tracks whatever is actually targeted to that device or user and marked as blocking. Over time, the list grows. Someone adds a required app for one team. Another person assigns a tool to a broad group because it was faster than building a new one. A security agent gets pushed to all devices and nobody mentions it. Now the page is waiting on fifteen things, and the person who built the profile thinks it's waiting on five. The reverse happens too. You expected an app to install during setup, but it wasn't set as blocking or it was targeted to the wrong phase, so the gate opens without it, the user lands on the desktop and the app shows up twenty minutes later. Nobody can say why it wasn't there at first. Both cases have the same root cause. The intended list lives in someone's head, the assigned list lives in the tenant, and only one of them controls the gate. Then there's the error code. When something does fail, you get a code a hex number, usually with a short message, and it feels precise. So the team searches it, finds a page, and starts fixing what the page describes. But the code often points to the layer where the failure was noticed, not the layer where it began. A certificate error might be a wrong clock. A policy error might be a blocked endpoint. An app error might be a dependency that never installed. The code names the surface, but the cause sits underneath. You can spend a whole afternoon fixing the thing the code describes, and the device still fails the same way. And meanwhile, the user is doing what users always do. The bar isn't moving, so they wait. Then they press the power button. Then, depending on the profile, the device either resumes where it stopped or begins again. If it begins again, the clock resets. The apps that finished may reinstall, and the sequence you're trying to diagnose is now a completely different sequence. Some try a second device, some call the helpdesk, some unplug the network cable because the screen looks stuck on a download. Each action changes the evidence, so by the time a technician looks at it, the original failure has been overwritten by three retries. Notice the pattern though, when you trace these stalls back, most don't end at a bad policy or a bad certificate. They end at the same place the page was waiting on an app, and something about that app or the order it ran in held the whole gate shut. App deployment order. The dependency problem. App deployment order. The dependency problem. Intune doesn't understand your dependencies. Not unless you tell it you know the VPN client needs a runtime first. You know the security agent should land before anything touches the network. You know, the line of business tool needs the VPN to reach its server. All of that lives in your head or in a document. Nobody opens. The tenant sees a list of apps assigned to a device, a list, no order, no reasons. And that's the flaw. People assume that if they assign things in a sensible sequence, they'll install. In that sequence, they won't. Installation order is not assignment order. When you assign an app, you're telling the tenant what should exist on the device. You're not telling it when or after what. The device checks in, pulls the list, and starts working through it. Some apps run side by side, some wait their turn. Which ones go first can change from one device to the next depending on download speed, size, and how the management agent decides to batch them. So the same assignment can produce two different outcomes on two identical laptops. One got lucky, one didn't. Now add the fact that apps aren't one kind of thing. Win32 apps are the heavy lifters. Packaged installers with detection rules, return codes, and install commands. Line of business apps are usually a single MSI or Ms. EXE file you upload yourself. Store apps come from a catalog and update on their own schedule. Then there are the mixed installers, the ones that wrap an MSI inside an XC that launches a second installer, which quietly downloads something else. Each type runs through a different path on the device. Each report status differently, and each has its own idea of what finished means. So when you put them on one list, you're not stacking similar things. You're stacking four different mechanisms and hoping they cooperate. Then comes the part that causes most of the damage. Prerequisites. A runtime that three other apps need. A VPN client that has to be running before the first sign in tries to reach an internal server. A security agent that must be present before the compliance check runs or the device lands as non-compliant on day one and gets blocked from email. None of these are exotic. They're ordinary building blocks, but if the app that needs them installs first, it fails. Or worse, it installs, looks fine and breaks the first time someone opens it and the failure shows up somewhere else. The runtime was missing, but the error appears in the app that needed it in a different phase on a different day. So what tools do you actually have? Two dependencies and a dependency says install this app. Only after that one is present. You attach the prerequisite to the app that needs it, and Intune installs the prerequisite first. That's the closest thing to real ordering the platform gives you super sedans, handles replacement. It says this new version takes the place of that old one. The old app gets updated or removed, and the new one lands. It keeps you from carrying three versions of the same tool across the fleet. Both are useful. Both have limits. Dependencies only work with Win32 apps, your store apps, and your line of business installers can't be part of the chain. The relationships also stay shallow. In practice, a chain of four or five dependencies gets hard to read and harder to debug, because a failure at the bottom of the chain stops everything above it without saying why, and a dependency only controls order. It doesn't promise the prerequisite is healthy, just that it ran. Supersede has its own edge cases. Remove the old version at the wrong moment and you break something that was still in use. Skip the uninstall and you get two versions fighting over the same file association. So these tools help. They don't replace knowing your own sequence because even with the order, right? There's a second problem waiting behind it. Apps don't only depend on each other, they compete. Every installer wants the same things at the same moment. Bandwidth, disk, CPU, a reboot, a lock on the same installation engine.

00:33:17 Speaker: Or Win32 app failures, detection rules, and silent installs. Competing for the same resources is only half the story. A lot of app failures have nothing to do with order at all. The app itself was packaged badly, and the tenant is just reporting what it sees. Start with the detection rule. It's the one line that tells Intune whether an app is installed, a file path, a registry key, a version number. After the installer runs, the device checks that rule and the answer decides everything. If the rule is wrong in one direction, you get an endless loop. The app installs fine, but the rule looks in the wrong place. The device checks, finds nothing, and installs it again. Then again, users see the same installer pop up every hour, logs filled with success messages that the system doesn't believe. If it's wrong in the other direction, you get false success. The rule checks for a folder that an old version or a failed install already left behind. The device says it's installed. When it isn't. The page opens the gate, the user lands on the desktop, and the app isn't there. Same mistake, two opposite symptoms and both look like an Intune problem. Then there's the silent install. Every Win32 package needs a command that runs without asking anyone a question. Nobody's sitting there to click next. So you add a switch like a quiet flag and test it once. But many installers don't honor it. The switch works on version four and gets ignored on version five. Or it hides the main window and still opens a license prompt, a driver warning, or a small dialog behind everything else on your test machine. You'd see it and click through on a device in setup, nobody sees it, so the install waits for as long as the timeout allows. That's a silent install that isn't silent. The command returns nothing. The page shows sixty percent, and the real answer is a dialog box on a screen no one can reach. Next context Win32 apps install either as the system or as the user, and the choice changes what the installer can do. Install a system and the app can write to protected places, add services, and reach machine wide settings, but it can't see the user's profile, their drives, or their registry. Install as user. And it can touch the profile, but it may not have the rights to install anything big. Here's what typically happens the package works perfectly when an admin double clicks it because an admin has both, then it runs under the system account during setup, and it quietly fails to find a folder that only exists once someone signs in. The error says file not found. The causes the context. Return codes matter just as much. When an installer finishes it hands back. A number zero usually means success. Others mean success with a reboot needed or a reboot already pending, or a heart failure. Intune has a table for these, and you can add your own. If the table doesn't match what your installer actually returns, the tenant misreads the result. An installer that says done restart required gets logged as a failure, one that crashes with an odd code, gets logged as fine, and reboot behavior stacks on top. If the app asks for a restart in the middle of setup, you can end up with a device that reboots into a sequence that's now halfway through something else. So how do you stop this? Mostly with discipline. And the first rule is where you test test on a clean device, a fresh image, nothing installed, no tweaks, not your own machine. Where the runtime was installed years ago. The proxy is set and your account has rights. Nobody else has. A tuned machine hides every missing prerequisite. A clean one finds them in the first run, tested the way the fleet will meet it under the system account, with no user signed in on a normal network. If it passes there, the package is probably sound, but a sound package can still fail. Sometimes the app is perfect and what breaks it is everything the tenant wraps around it. Policies pushed from other places, settings that overlap, rules that quietly cancel each other out, policy conflicts and configuration sprawl say the app is perfect package clean detected, right installed silently. It can still fail, and the reason sits outside the app because a windows device in Intune doesn't take settings from one place, it takes them from several at the same time. Configuration profiles the older template based ones. The settings catalog the newer way where you pick individual settings from a long list. Security baselines, which push hundreds of settings in one package and underneath it all, sometimes legacy group policy still arriving from a domain on a hybrid machine for sources, one device and a lot of overlap. Take something small the screen lock timeout a baseline sets it to five minutes. A profile someone built last year sets it to fifteen. A group policy object from the old days sets it to ten. Three owners, three answers, one setting. So which one wins? Here's where it gets uncomfortable. Intune doesn't tell you, not in plain words. What you get is a status pending because the device hasn't confirmed the setting applied or error. Because two profiles asked for different values and the device couldn't satisfy both or conflict on a good day. That's the whole message. It never says this baseline disagrees with that profile. And here's the one that lost the status shows the symptom on the device. The explanation lives somewhere. You have to dig for setting by setting profile, by profile and pending is the worst of them. It can mean the device hasn't checked in. It can mean the setting failed quietly. It can mean it's waiting on a reboot. Same word. Three different problems now precedence which source outranks which by default it isn't obvious. Group policy and MDM settings have their own rule for who wins on a hybrid device, and it depends on the setting. Most people never look at. Within Intune itself, there's no ranking between profiles, two profiles that set the same value differently. Don't queue up politely. They collide, and when they collide, the device often applies neither. So the order you expect newest wins or strictest wins doesn't exist unless you build it. Priority is something you design on purpose. The platform won't do it for you. Which leads to the question of how a tenant ends up like this. Nobody sets out to create a mess. It grows one reasonable decision at a time. An incident happens. Printing breaks for the finance team. Someone finds the setting and the fastest fix is a new profile scoped to finance that turns it on. Ticket closed. Nobody checks whether an existing profile already touched that setting. A month later, a security review asks for stricter sign in rules, a new profile, then a new region joins the company and needs different language settings a new profile. Then a vendor recommends a tweak for a driver. Another one. Every incident adds a profile and nothing ever removes one, because removing a profile feels risky and keeping it feels free. After two years, you have one hundred and fifty profiles. Names like test two, finance, Fix Temp, Do Not Delete and New policy one. Nobody remembers why half of them exist. Nobody dares to touch them because nobody knows what breaks. That's configuration sprawl And it isn't a configuration problem. It's a memory problem. The tenant remembers every fix and forgets every reason. So what replaces it? One rule, one setting, one owner. Every setting that matters gets set in exactly one place. One profile. One baseline. One source. If screen lock timeout lives in the baseline, it doesn't appear anywhere else. If a team needs an exception, you don't add a second profile that fights the first. You change the owner or you scope the owner differently. And owner means two things the place that sets the value and the person who answers for it. When something conflicts, there should be one name to ask, not one hundred and forty. It takes work upfront. You audit what exists, find the overlaps, and pick a winner for each. But it turns a conflict from a mystery into a lookup, and that discipline matters more as the fleet changes shape. A tenant full of identical laptops can survive some sprawl, a tenant full of different devices, different roles, different ways of enrolling can't. Every new kind of device multiplies the places where settings can collide. Pre-provisioning and shared hardware scenarios. So far, every failure we've covered lands on the person holding the laptop. Pre-provisioning changes who that person is. Microsoft calls it Pre-provisioning. Most people still say white glove. The idea is simple a technician runs the device phase of setup before the user ever sees the box. The heavy part, the device policies, the certificates, the big required apps finishes at a desk. The user only does the account phase, which is short, and that moves the failure not away just sideways. A stalled install used to be a new hire staring at a frozen screen on their first morning. Now it's a technician staring at the same screen on a Tuesday afternoon with a spare device within reach and a ticket queue they control. That's a better place to fail. The audience is smaller, the stakes are lower, and nobody's first impression of the company is a progress bar. Now, where does that technician work? Often not in your building at all. Many companies hand this step to a partner or the manufacturer. A warehouse somewhere receives the hardware. A worker scans each device, connects it to a wired network, and starts the pre-provisioning flow. Hundreds of laptops, one after another, on a shelf with an Ethernet cable. What actually happens there is more fragile than the brochure suggests. The warehouse network is its own network with its own proxy and its own firewall rules. You're carefully tested endpoint list may not exist on that side of the wall. The worker follows a checklist, and when a device stalls, the checklist usually says reset and retry. So a hung installer gets quietly retried until it passes and nobody writes down that it hung. Then the device is ship. They sit in a truck, then in a drawer, then on a desk. And here's a detail people forget. The work was done at one moment and the user signs in at another. Weeks can pass. Policies have changed. Apps have new versions. The device face finished against a tenant that no longer exists in that exact shape. Now the hardware limits Pre-provisioning doesn't only need the network, it needs the TPM. The TPM is a security chip on the motherboard. During Pre-provisioning, the device proves to the cloud that it has a real working one. That proof is called attestation. It's what stops someone from faking a device's identity, and it fails more than anyone expects. Older hardware ships with TPM that's the wrong version or turned off in firmware. Some models need a firmware update before attestation works. Virtual machines can't do it at all, which wrecks lab testing and the error when it comes is vague. A code that says attestation failed with nothing about which chip, which setting, or which model. So you find out one device at a time, usually on the third model in a purchase order. There's a second mode worth knowing built for a different problem. Self-deploying. In Self-deploying mode, no user signs in at all. The device enrolls itself, applies its policies, and lands ready. That's exactly what you want for kiosks, digital signs, and shared machines on a factory floor. Nobody owns them, so nobody should have to log in to build them. But it asks more of the hardware. TPM attestation is required with no workaround and with no user, there's nobody to notice a stall a kiosk can sit at setting up for hours in a back room while everyone assumes it's fine. So when does all this actually help? Pre-provisioning saves hours when the device phase is long, when users are remote, and when the first day matters, a forty minute install moves off the user's clock and onto the technicians. It hides problems when the technicians environment is cleaner than the real one. A device that passes on a warehouse Ethernet cable proves nothing about a home router. The failure didn't disappear. It's just waiting at the user's door instead. Either way, the device is built and that happens once. Windows won't sit still after that because the updates start the same day. Update rings the rollout inside the rollout updates are a second deployment, same fleet, same risk, and almost nobody treats them that way. The two for this is Windows Update for business. It doesn't push patches by hand. It lets you set rules and each device follows them on its own. Those rules come in three parts rings, deferrals, and deadlines. A ring is a group of devices that gets the same update settings. A deferral is a delay. You tell the ring to wait a number of days before it offers an update. A deadline is the point where waiting ends. After that date, the device installs and restarts whether the user likes it or not, so the pattern is simple. Early rings get the update first. Later rings. Wait. If the update breaks something, you find out on a few hundred machines. Not on all of them. But first you have to know what you're delaying. Windows doesn't ship one kind of update. Quality updates are the monthly fixes, security patches, bug fixes, small changes. They arrive often, and they're the ones you can't ignore for long. Feature updates are the big ones. A new version of windows. Once a year, they change settings, move menus, and replace system files. A feature update is closer to a reinstall than a patch than there are drivers, firmware, and hardware. Drivers can arrive through the same channel and they're the quiet troublemakers. A bad driver doesn't crash the update. It crashes one hardware model a week later, and the error says nothing about an update at all. Three types, three risk levels. Yet many tenants give them one schedule, same delay, same deadline, same ring, a small monthly patch, and a full operating system upgrade treated as equals. So how should the rings look? Start small. A test ring, maybe fifty devices. Mostly it. They take updates almost right away and their job is to break first. Next, a pilot ring a few hundred devices a little later with real users doing real work. Then the broad ring. The bulk of the fleet, which waits until the early rings have proven the update is safe and last. A final ring for the machines you're most afraid of. Executive laptops, machines that run a plant, anything where a bad restart costs real money for rings, each one a gate for the next. Now, here's the mistake that shows up in nearly every tenant. All the rings contain the same kind of user. Someone builds the test ring from the IT department, then fills the pilot ring from the people who volunteered. Those people are the same type technical patient running the same laptop model on the office network with the same short list of apps. So the update passes through two rings and nothing breaks. Then it reaches the broad ring and it meets a finance team with a legacy plugin, a field crew on a different driver, and a warehouse running ten year old scanners. The failures were always there. The rings just never contained anything that could trigger them. A ring that doesn't look like the fleet isn't a safety net. It's a rehearsal for a different audience. So build rings from various different hardware models, different sites, different apps, different kinds of network. A small ring that mirrors the fleet's mess will catch more than a large ring that mirrors your own desk. Which raises the real question what decides when an update moves from one ring to the next? Usually a calendar fourteen days passed, so the next ring opens. That's a timer, not a decision. The better gate is evidence in store success rates, restart failures, crash reports support tickets that mention the update. Real telemetry from the ring you just finished checked before the next one starts. If the numbers look normal, the gate opens. If they don't, it stays shut and the rest of the fleet never sees the problem. But that only works if you can read the numbers. A ring that passes silently looks exactly like a ring that failed silently. Both show no tickets for a while. Rings only protect you if you can see what happens inside them. Update failures, reboots, deadlines, and user trust updates don't fail loudly. They fail in the middle of a meeting. Picture a deadline. You set it to seven days after an update becomes available, and on day seven, the device installs and restarts. It doesn't ask if now is a good time. It has no idea someone is sharing a screen with a customer. The laptop just counts the days, reaches the limit, and reboots. That's what a deadline is. A promise to the fleet that waiting ends. But the user never saw the promise, so to them it feels like the machine turned on them. Two settings soften this, and most tenants set neither on purpose. Active hours tell windows when a person is probably working during that window, the device won't restart on its own. Set them to the real work day and most restarts happen at night. Leave the default and you get a laptop that guesses grace periods work differently. They add time after the deadline passes. The update installs, but the forced restart waits a set number of hours so the user can save work and pick the moment. A short grace period costs you a little speed. No grace period costs you a lost document, so the user knows a restart is coming and has a say in when. That's the whole difference. Now the failures that have nothing to do with timing. Some updates simply don't install and the reasons are boring. Disk space comes first. A feature update needs many gigabytes free for the new files and for a copy of the old system, in case it has to roll back a machine with a nearly full drive. Downloads the update, starts the install and fails at sixty percent. Then it tries again the next night and again drivers come second. An old driver doesn't match the new version of windows, and the update refuses to continue. Rather than break the hardware, some devices get blocked outright and they sit on an old build for months while nobody notices because nothing is reporting an error. They just aren't moving. Blocked services come third. Update delivery depends on a few background services and on network paths to the update servers. A security tool that disables one of them, or a firewall rule that drops the download leaves the device stuck. It checks for updates, finds nothing it can reach, and reports that it's fine. Three causes none of them in the update itself. The patch was good, the device wasn't ready for it, but sometimes you can't wait for the rings. A serious vulnerability is being used in attacks right now. Your normal schedule says the broad ring gets the fix in two weeks. Two weeks is too long. That's what expedite policies are for and expedite policy. Tells devices to install a specific quality update as fast as possible. Skipping the deferral. You said it works on the next check in and restarts sooner than your normal rules would allow. Use it rarely. It overrides the safety you built. An expedited update goes to everyone you target with none of the ring evidence you'd normally gather first, so save it for real threats. Target it carefully, and tell people in advance that a restart is coming. Using it for convenience turns a safety valve into a habit. Because here's what all of this protects. Trust ten updates installed in the background without anyone noticing. Nobody thanks it for those. Then one restart wipes out an unsaved presentation. That's the one people remember. They tell their team about it and they remember the word update the next time it appears on screen and that memory changes behavior. People start postponing everything, closing the restart prompts, and keeping laptops asleep so updates can't run. The fleet falls behind on patches, which is the exact outcome the rings were built to prevent. One bad reboot costs more than ten. Good updates can earn back. So when failures do happen and they will, the first instinct is to open the logs and start reading. That instinct sends most teams in the wrong direction. Before you look at any evidence, you have to know where to look. Troubleshooting method start with the layer, not the error. A ticket arrives. Autopilot failed on my laptop. Most engineers open a log or search the error code or ask the user to try again. All three skip a step before any of that one question which layer broke? There are four identity network policy. Application identity is who the device is and who the user is. The hardware record, the group tag. The join the token. The license. If this layer fails, the device can't prove it belongs to anyone. Nothing else gets a turn. Network is whether the device can reach what it needs, when it needs it. Endpoints. Proxies. DNS time certificates on the wire. This layer fails quietly. A device that can't reach the cloud can't always tell you why. Policy is what the tenant told the device to become. Profiles. Baselines. Compliance rules. The gate settings on the enrollment page. When this layer fails, the device is reachable and known, but it's been given instructions it can't follow or two sets that disagree. Application is the software itself. The package. The detection rule. The install order. The dependency. This layer fails loudly in logs and that's the trap. It draws the eye away from the layers underneath four layers. Every ticket in this whole series lands in one of them. And here's the discipline. Name the layer first, then read the log, not the other way around. Why does the order matter? Because the log is large and it's full of things that look like problems. A device and setup writes warnings all the time. A retry that eventually works. A setting that wasn't ready yet. If you open the log without a theory, you'll find something red and you'll decide it's the cause. Often it isn't. It's noise that happened to be near the failure. A layer gives you a question to ask the log network. Then you look for failed connections and certificate errors and you ignore the app messages identity. You look at the join and the token. The log stops being a wall of text. It becomes an answer to a specific question. Now. Why do teams chase error codes instead? Because a code feels like progress. It's a number. You can search it. A page comes back with a title and a fix that feels like an answer. But as we saw with the timeout, a code often names where the failure was noticed, not where it started. Treat it as a pointer to a layer, never as the diagnosis itself. A certificate error points at the network or the clock. A policy error might be a blocked endpoint. Read the code as a clue about which layer to inspect. So here's a triage order that works on almost every ticket. First identity does the device exist in autopilot with the right group tag? And is a profile assigned? It's the cheapest check and it eliminates the most second network. Where was the device when it failed? What network? What proxy was a VPN needed? Could it reach the enrollment services at all? Third policy did the device enroll and start pulling settings? Is anything pending in conflict or blocking the gate? Fourth application which app was the page waiting on when it stopped and did that app's own rules behave, or is it in that order because each layer sits on top of the one before it? A broken app can't be the cause. If the device never reached the cloud, then one more step that almost nobody does right the layer down on the ticket. One word identity, network policy or application. It takes five seconds and after a few months it becomes the most useful data you own. You can count them sixty percent network. Then your problem isn't in tune. It's your branch connectivity, a cluster of identity failures. After every hardware order, your registration process is leaking. The tickets stop being individual events. They start showing a shape. Without that label, every failure is new. With it, the same failures keep introducing themselves, but a layer is only a direction. You still have to prove it. That takes evidence and the question is which evidence to collect first.

00:52:51 Speaker: Logs and evidence. What to collect first. You've named the layer. Now you need proof. And the first thing to know is where the proof lives on the device itself. Not in the portal. The portal shows you what the tenant believes happened. The device holds what actually happened. Start with the collection built into Intune from the device page in the admin center, you can request diagnostics. The tenant asks the device to bundle its own logs and upload them. No one has to walk over with a USB stick. You wait a few minutes, then download a zip file inside that zip. The most useful pieces come from the Intune management extension. That's the agent on the device that handles Win32 apps and scripts. Its logs record every app it saw, every detection rule it ran, every install command it launched, and every return code that came back. If your triage pointed at the application layer, this is where the answer sits. Written in order with timestamps. So you read it the way you'd read a receipt. Which app started at what time, how long it ran, what the detection rule said afterward, a gap of forty minutes between two lines tells you more than any error message, but the extension only covers apps and scripts. Enrollment itself leaves its trail somewhere else. That place is event viewer. The paths are buried and nobody remembers them, so write them down. Under Applications and services logs, then Microsoft, then windows, you'll find the provisioning diagnostics log. That one records the provisioning packages and the early stages of setup. Next to it sits the Device Management Enterprise Diagnostics log that shows the enrollment conversation itself. Policies arriving. Settings being applied. Errors when a setting can't be accepted. Two logs, two questions. Provisioning tells you how the device got started. The enterprise diagnostics log tells you what the tenant said to it after that, for an identity or policy failure, these two usually settle the argument. Now, two views that save time and that most teams skip because they look like decoration. The first is the autopilot diagnostics page. On the device, you can open a view that lists the profile it received, the deployment mode, the join type, and the phases it passed through. It's a short answer to a long question. What did this device think it was supposed to become? When that doesn't match what you assigned, you found an identity problem in about 30s. The second is the ESP diagnostic view. It lists every item the enrollment page was waiting on and the state of each one installed failed. Still in progress. Remember the gap between the apps you intended and the apps you assigned? This is where that gap shows up. In writing, you'll see fifteen items where you expected five and one of them stuck. Both can be pulled with a keyboard shortcut during setup or exported afterward. Use them first. They're quick, and they tell you where to point the heavier tools. Now, a decision that sounds small and isn't. Do you collect from the stuck device, or do you try to recreate the problem? Collect from the stuck device? Always if you can. Recreating the problem feels attractive a clean device, a controlled network, a technician watching. But a recreation is a different sequence. The hardware differs, the network differs, the timing differs. If the failure doesn't repeat, you've learned nothing. And if it fails differently, you've learned the wrong thing. Worse, you've now spent an hour confirming that your lab works. The stuck device is the only witness to the original event, and it's perishable. A retry overwrites, logs a reset, wipes them. A user who restarts the machine erases the state. You need it. So tell the person at the other end before anything else. Don't restart it. Don't reset it. Don't try again. Then collect. Once you have the evidence, don't let it vanish into someone's downloads folder. Attach it to the ticket, the logs, the layer you named, and one sentence on what you found. Not in a chat message, not on a personal drive in the ticket where the next engineer will look because staff change. The person who solved this exact failure last spring may be gone and their memory went with them. A ticket with logs attached is a case file. A ticket that says fixed restarted is a gap. Months later, when the same failure returns on a different model, someone can search, compare and see it's the same thing. That's how individual fixes turn into a pattern, but only on the scale of one machine at a time. Logs explain one device. They can't tell you whether that device is an accident or the first of many. For that, you need to look at the fleet reporting that shows trouble before users do. Start with what the portal already gives you three reports built in, and most teams only open them after something's already broken. The Autopilot deployment report lists every device that went through the process, who got it, which profile it used, how long it took and whether it finished the enrollment failure report narrows that down to the ones that didn't with the stage and the error code attached. An app install status shows per app how many devices succeeded, failed, or are still waiting. Three views of the same event. Each one answers a different question. The deployment report asks how long the failure report asks where app status asks which one and when you read them together, a pattern can show up that no single ticket could show you forty failures at the device setup stage, all on one hardware model, all on one app. That's not forty problems. That's one. But there's another report most teams trust too much. Compliance compliance state looks like health. A device is either compliant or it isn't green or red, and the percentage sits right on the dashboard. So leaders read it as a fitness score for the fleet. Here's the problem. It's a lagging signal. By the time a device shows as non-compliant, something already broke and it broke days ago. The check in has to happen. The evaluation has to run. The result has to sync back. Meanwhile, the user has been working on a broken machine or giving up on it, or calling the help desk. Worse. Compliance only measures what you chose to test. A device can pass every rule and still have taken ninety minutes to build, and arrived with half its apps missing. Green tells you the rules were met. It says nothing about the experience. So where do trends come from? From keeping the data. The portal reports are mostly snapshots, and they only reach back a short time. If you want to see a month or compare this wave to the last one, you have to send that data somewhere that remembers. That's what log analytics is for. You root your device in enrollment data into a workspace. It stores it. As long as you decide, then you query it. How many failures per week, which models fail most, which sites, which stage workbooks sit. On top of that, they turn the queries into charts you can open without writing anything and share with people who'd never touch a query. A manager can look at one page and see the shape of the fleet. It costs a little to set up and it costs storage, but it's the difference between it feels worse lately and failures doubled in the week the new model arrived. Now the metric. Most teams skip time to productive desktop. Not time to enroll, not time to finish the page. The time from the moment a user presses the power button to the moment they can actually do their job with their apps, their files, and a working sign in. That's the number the user feels. You can build a rough version from the data you already have. Take the start of the autopilot process and the end of the account phase. Add the minutes that follow until the last required app lands. It's not perfect, but a rough number you track beats a perfect one you don't have, and it's honest. A fleet can show a ninety eight percent success rate while the median user waits two hours. Both are true. Only one of them is a problem you'd hear about from people. Which brings up how to show any of this. A dashboard that shows today's total tells you very little. Eight percent failure. Is that bad? You can't tell. It depends on what it was yesterday and last week and before the last change. So show change over time. A line, not a number. Failures per day plotted across weeks with your own changes marked on it. The new app, the updated profile, the second hardware wave. When the line bends, you can see what it bent next to. Snapshots tell you where you are. Lines tell you which way you're moving, and that's the part you can act on, but you can build all of it perfectly and still have nothing happen. A chart nobody opens is the same as no chart. The data is there. The trend is climbing and the only thing missing is a person whose job is to look at it on a Monday morning and ask what changed? Operational habits. Who owns the fleet daily? So who reads the report on Monday morning? In most organizations, the honest answer is whoever notices. Which means nobody until a ticket forces the question. A healthy fleet doesn't come from a better portal. It comes from a small set of checks that happen on a schedule written down with a name next to each one. Start with the daily check. It should take fifteen minutes, not two hours. Did any devices fail enrollment overnight? Did any app show a spike in install failures? Is anything stuck in pending longer than it should be? Three questions. Three numbers. One person. If all three look normal, the check ends. That's the point. Then the weekly check, which goes a level deeper trendlines instead of totals. Which hardware model is drifting? Which site has slower builds than last week? Which update ring is about to open, and what the evidence from the last ring says. This one gets thirty minutes and a recurring calendar slot because a check that isn't on a calendar gets skipped. The first busy week and written down matters more than it sounds. A checklist in a shared page with the exact report to open, and the exact number that counts as a problem. Not look at app status, rather open app install status, sort by failed. Anything over two percent gets a ticket. A new engineer should be able to run it on their first day. Now ownership because one person watching everything is one person who watches nothing closely split it by layer of work. Someone owns enrollment hardware hashes, group tags, profiles, the first boot experience someone owns apps, packaging, detection rules order, and the install status report. Someone owns updates, the rings, the deadlines, the evidence between them and someone owns compliance, the rules, the exceptions, and the reasons a device gets blocked. For owners on a small team, one human may wear all four hats and that's fine. What matters is that each hat has a name on it, so a failure in apps doesn't get argued about for an hour before anyone picks it up. When something breaks. The first question is whose is this? And the answer should take five seconds. But owners also create a risk. Each one starts changing things and the changes land on the same fleet. So give changes a window, a fixed time. When profile and app changes go out, say Tuesday and Thursday mornings. Not whenever someone finishes typing. People get used to it. Support knows when to expect noise, and nothing ships on a Friday afternoon, which is a rule everyone agrees with and half the industry breaks. Every change in that window carries a rollback. Note one line written before the change goes out. If this app breaks, remove the assignment and restore the previous version. If this profile conflicts, unassign it from the pilot group and revert the setting. It sounds like paperwork. It's actually what turns a bad afternoon into a ten minute reversal, because the person fixing it at four o'clock doesn't have to remember what the person who made the change was thinking at ten. And here's the shift that connects this to everything earlier. A change to a profile or an app isn't an edit. It's a small deployment, so it gets its own ring. Assign it to the test group first, then the pilot, then everyone else. Watch the numbers between each step the same way you'd watch an update. A new security baseline pushed to the whole fleet at once, is the same mistake as a feature update, pushed to the whole fleet at once, only quieter because it doesn't look like a rollout. Most outages in a managed fleet don't come from Microsoft. They come from an engineer making a reasonable change to everyone at the same time. Now, none of this is exciting and that's the part people resist. There's no clever trick here. It's the same checks, the same windows, the same notes, week after week. The team that does this for a year sees problems while they're still small and fixes them before anyone files a ticket. The team that skips it spends the year in firefighting and calls it experience. The habit that keeps the fleet healthy is boring. Repetition, nothing more. But boring. Repetition has a condition. It only works if there's something stable to repeat against a checklist on a tenant where nobody knows which group does what, where profile names mean nothing, and where old assignments pile up forever, that turns into a daily exercise in confusion. The habits don't fail because people stop caring. They fail because the structure underneath them is messy. Governance groups naming and assignment hygiene start with groups. They are the plumbing under almost everything we've covered, and most tenants build them the way they build sprawl, one at a time. Whenever a request comes in, there's a cleaner split device groups carry the provisioning side. They decide which autopilot profile a machine gets, which enrollment page settings apply, which hardware gets which treatment they're based on, what the device is. User groups carry the app side. They decide who gets the finance tool, who gets the design software, who gets the VPN client. They're based on what the person does. Why keep them apart? Because the device and the user change on different clocks. A laptop gets reassigned to a new hire, and the apps should follow the person, not the hardware. A person changes departments, and the provisioning rules for their old machine shouldn't care. Mix the two into one group and every move creates a small mess. Nobody can see. Now the names open any tenant that's three years old and you'll find them. Test two finance fix new group one. Each one meant something to the person who typed it on the day they typed it. A good name explains itself without a lookup, without asking a colleague. You read it and you know what it's for, who it targets and what it touches. Something like dev. AP Corp win eleven tells you. Device group. Autopilot. Corporate. Windows eleven. The convention doesn't have to be clever. It has to be boring and followed by everyone. Put the type first, the purpose second, the scope third. Then write the pattern down where new people will actually find it. Here's what typically happens next, though a new requirement arrives only the laptops in Germany, only devices with a specific disk size. Only machines running the older build. And the quick answer is another group. Each of those groups is cheap to create and expensive to keep. A hundred groups means a hundred places where membership can drift. And one hundred answers to the question why is this device in here? Assignment filters change that math. A filter sits on the assignment itself. You keep one group and the filter narrows it at the moment of delivery. Operating system version. Manufacturer model ownership type. The profile goes to one group and the filter decides which devices inside it actually receive it. Instead of three groups for three conditions, you get one group and three small rules you can read in a row and filters have a bonus. You can preview what a filter matches before you apply it. A group makes you wait and see. Next, clean up because even a clean tenant rots. Devices get retired and their records stay behind. A laptop is reimaged registered twice and the old entry lingers. People leave and their groups keep their names. Profiles get replaced and the old ones sit unassigned harmless until someone assigns them by accident. All of this adds noise, and noise hides the real failures, so schedule the clean up. Quarterly is enough for most teams. Look for devices that haven't checked in for ninety days. Find profiles and apps with no assignments. Find groups with no members or members nobody can explain. Archive first, delete after a grace period and write the date on the checklist. Because cleanup that depends on someone feeling motivated never happens. Now step back because all of this points at one flaw. The model behind most tenants says a tenant is a pile of settings. You add one, then another, and the pile grows. If something's wrong, you add a setting to cover it. Nobody asks whether the pile still makes sense as a whole, but a tenant isn't a pile. It's a system. Groups feed profiles, profiles, feed devices. Devices, feed reports a change in one place moves something in another, and a system needs a design with named parts. Clear boundaries and an owner for each one. Without that, every new setting works against the ones before it. So the real work of governance is structural. Fewer groups with clear jobs. Names that carry meaning. Filters in place of duplicates. Clean up on a calendar. Yet even a well-built structure fails if people are afraid to touch it. If every edit feels like it might bring something down, nobody edits and the structure freezes into the same mess it was meant to prevent. Governance only works if people can change things safely. Testing and change control without slowing down. Safe change needs a place to be wrong first. That means a permanent test environment, ideally a separate test tenant with its own groups, its own profiles, and its own enrollment setup. Nothing in it touches production. If a tenant is too much to run a dedicated test string, inside production is the fallback. A small group of devices that always receives every change first, and whose only job is to find out what breaks the word that matters is permanent. A test setup that gets built for one project and torn down after is a one time rehearsal. A permanent one drifts alongside production, so it keeps telling the truth and it keeps its history. So when something behaves oddly, you can compare against a baseline that was never touched for the sake of a demo. But a test environment only helps if the device is inside it. Look like the fleet. We've seen what happens when rings hold one kind of user. The same goes for hardware. A test ring made of the newest laptop model proves the change. Works on the newest laptop model, so test the golden path on real hardware. Pick one device from every model you actually own. Run the full sequence from power button to productive desktop the way a user would. Registration profile network join the enrollment page apps first sign in, then repeat on the oldest model in the fleet because that's where firmware is stale and drivers are strange. Virtual machines are fine for a quick check, but they can't prove TPM behavior, and they can't prove how a specific disk or network card acts. A short list of real devices beats a long list of virtual ones ten models one afternoon, one written result for each. Now the part that always gets pushed to later documentation treated as part of the change, not the clean up after it. When someone ships a new app or a new profile, the change isn't done until three things are written down. What it does, who owns it, how to undo it. That's five lines and it takes ten minutes. While the details are still fresh. Written next month, it takes an hour and a half of it is guessing. Put those notes where the change lives in the ticket, in the profile description, in the app notes. Anywhere. A tired engineer will find them at four in the afternoon when something has gone wrong and the author is on leave. And that brings up rollback, which deserves its own plan for each kind of change. For apps, a rollback means removing the assignment or reassigning the previous version and knowing what happens on devices that already installed the bad one. Does the old version overwrite it? Does it need an uninstall? First check before you need it. For profiles, it means assigning from the broad group and confirming the setting actually reverts. Some settings stay changed after a profile is removed, others snap back. You want to know which in the test string before you find out. In production for update rings, it means pausing. Most update controls have a pause setting. You should know where it sits and who's allowed to press it. An update that's already installed is harder to undo than one that hasn't arrived yet. Each plan should be short enough to read in a minute. If it needs a meeting, it isn't a plan. Now, the obvious objection. All of this sounds slow. It isn't. If you do it right, the speed doesn't come from skipping checks. It comes from making each change small. A tiny change tested on a handful of devices with an undo note can ship in an afternoon. A giant change bundling, six edits and a new app needs a week of nervous review because nobody can say which part might fail. Small changes are fast because they're easy to reason about. When one breaks, you know exactly which one when it needs reversing. There's only one thing to reverse. The teams that move quickly aren't the ones that test less. They are the ones that never let a change get big enough to be scary. But here's what makes all of this. Hard processes get designed in calm weeks, and they're used in bad ones. A deadline lands, an executive needs a fix and the test ring gets skipped just this once. Good process under pressure tends to break in the same ways at the same points in almost every organization. So instead of another checklist, it helps to look at the pattern of how a real rollout goes sideways over time.

01:10:31 Speaker: In a case pattern. The rollout that stalled at month three. In most organizations, the first one thousand devices go well, not perfectly, but well enough. The team builds the profiles, packages the apps and ships laptops to head office, and two or three nearby sites. The same hardware order, the same network, the same kind of user. Tickets trickle in, get fixed and get closed. Leadership sees a smooth start and somebody says the word success in a meeting. Month two looks the same. Then month three arrives with the second wave, and the second wave is a different fleet, a newer hardware model. Because the first order sold out a batch from a different supplier shipped with older firmware, four regional offices, each with its own internet provider and its own idea of what a firewall should block. A warehouse site where the only network is a shared guest connection. Nothing about this was a secret. It was all in the project plan under a line that said phase two. The sequence is the same one we've been walking through, but now every link runs through conditions the pilot never touched. So the numbers move in the first wave about one device in one hundred needed a hand. That's the failure rate the team had learned to live with by week three of the second wave. It's closer to eight in one hundred. Eight percent sounds small. Run it on a wave of two thousand devices, and it's one hundred and sixty people who didn't get a working laptop on day one. Some are new hires, some are remote with no office to walk into. Each one needs a technician to read logs, build a replacement, or ship a box back and forth. And here's the detail that makes this pattern so hard to catch. The tickets come first. The help desk feels it on Monday. More calls about stuck screens, missing apps, laptops that just sit there. Engineers start mentioning it in chat. Someone says it feels worse lately, but the dashboard still looks fine. Compliance is mostly green. The deployment report only counts devices that finished, so the ones that gave up and got replaced barely register. The portal says everything is normal while the phone says otherwise. Which means the team spends two weeks arguing about whether there's a problem at all. One side points at the ticket queue, the other points at the reports. Both are right. They're measuring different things, and only one of them was built to catch trouble early. So the team does what teams do. They look for what changed. A new windows build. A recent app update. Someone touched a profile last Thursday. They chase each theory for a day or two, and each one turns up a small finding that doesn't explain eight percent. Then they sort the failures by hardware model, by site and by network, and the picture clears up. The failures weren't random. They clustered one model with a firmware quirk that broke the attestation. Step two sites whose proxy blocked an enrollment endpoint. A warehouse where the guest network dropped sessions after ten minutes right in the middle of a large app download. None of those causes was new. The firmware had always been old. The proxy had always blocked that endpoint. The guest network had always dropped sessions. These conditions were sitting in the fleet from the first day. The first wave simply never ran into them because the first wave didn't include them. That's the root cause in nearly every stalled rollout. Not a new bug, not a bad update. Unmanaged variants that was always there, waiting for a device that would find it. And the team couldn't see it earlier because nobody had a list of what varied, no inventory of models and firmware, no map of sites and networks, no record of which conditions had actually been tested. The pilot proved the sequence worked under one set of conditions, and everyone quietly treated it as proof for all of them. So the lesson isn't that month three is dangerous. Month three is just when the fleet finally shows you the full distribution, and a story like this one is useful for exactly one reason. It shows the pattern. The same pattern leaders can act on. If it's laid out in a structure they can read in one sitting. Executive view. What to measure and what to fund. If you lead the people who run this, you don't need the logs. You need three numbers. The first is time to. First productive login, not time to finish enrollment. The minutes between a user opening the box and doing real work. It's the one number every employee feels, and it turns a technical process into a business outcome. A new hire who waits two hours on day one doesn't blame a time out. They blame the company. The second is support ticket volume and specifically the share that comes from setup and updates. That's your cost signal. Every stalled laptop is a technician's hour plus a shipped replacement, plus a person who isn't working. Count it, put a price on it, then watch the line because as we saw in the month, three pattern tickets move before any dashboard does. The third is refresh cycle cost. What does it cost per device to take a laptop from the dock to a working desk? Hardware is the visible part. The hidden part is labor, retries and rework. When that number drops, the refresh gets cheaper and people stop delaying it. Now, the question leaders always ask, do we need a different license or a better tier or another tool? Almost never. The license gets you the capability. It doesn't get you the result. Two companies can own the identical subscription, and one builds in forty minutes while the other needs a day. The difference is people and process. Who packages the apps. Who tests on real hardware? Who reads the report on Monday? Who owns each link in the sequence? Autopilot success is a staffing question and a discipline question. You can't buy it by upgrading a plan which brings up where the money should actually go. It goes to the unglamorous parts. Nobody gets promoted for them and they decide almost everything. Packaging comes first. Someone has to build each app properly with a real detection rule, a clean silent install, and a tested uninstall that's skilled slow work and underfunded teams rush it. The cost shows up later as a stalled enrollment page testing comes second. A permanent test ring, a shelf of real hardware, and time to run the full path on every model. It looks like overhead until the first change that would have hit ten thousand devices and hit fifty instead. Reporting comes third. The workspace, the workbooks, the person with thirty minutes a week to read them cheap, and almost always skipped. These three share a trait. When they work, nothing happens. No incident, no escalation, no story. So they're the first things cut in a tight year and the first things blamed in a bad one. So frame the risk in terms leaders already use. Delayed refreshes are the first cost. When setup is painful, teams postpone replacing old machines. Old machines are slower, less secure and more expensive to keep alive, and the delay compounds every quarter. Security exposure is the second a fleet that falls behind on patches because people keep postponing restarts carries open vulnerabilities for weeks. Devices that never finish enrolling may also never receive the protections you assume they have, and user trust is the third, which is the hardest to measure and the slowest to recover. Once employees expect the laptop process to fail, they work around it. They keep personal devices, avoid updates, and skip the help desk. Every workaround is a gap in your control. So what should a leader ask every quarter? Which layer caused most of our failures last quarter, and what did we change because of it? What's our median time to productive desktop and is it rising or falling? Which hardware models and sites fail most often. When did we last test on our oldest device? Who reads the enrollment report and what did they find this week? And if this team lost its best engineer tomorrow, what would still be written down? Those six questions cost nothing. The answers tell you whether you're running a system or hoping. Notice what they have in common. None. Ask about a feature. All of them ask about a sequence and who watches it. That's the thread through everything we've covered. So before we close, it's worth compressing the whole thing into one short model you can carry out of the room. The new model. From configuring devices to orchestrating sequences. Here's the old model stated plainly a device is a thing. You configure it, you pick the settings, assign the apps, and push the policies. Then you hope the settings hold. That's the assumption underneath most rollouts. It treats the laptop like a finished object you shape once. If it comes out wrong, you adjust the shape and try again, but a device doesn't arrive configured. It arrives as a sequence registration network. Join the enrollment page. Policies apps first sign in each step depends on the one before it, and each has its own owner and its own way of failing. Configuring a device is what you do at the end. It isn't what you're managing. So the new model is simple to say and harder to run. Design the sequence. Observe each link. Own each outcome. Design means you draw it not in your head, on paper, with every link named. What has to be true before this step runs? What does it hand to the next one? Where can it wait and where can it not? Observe means every link produces a signal you can read, not just the last one. If the only thing you see is device ready or device failed, you've lost the whole middle, which is where the answer lives. Own means a name sits next to each link, not a team, a person. When something stalls, nobody asks whose it is. Now. One idea ties the sequence together. Context at first boot. Think about what's true in the first minute of a device's life. It has no history, no user profile, nothing cached. And in that minute, the tenant has to answer three questions who is this user? What is this device and what must be ready before this person can start work? Every failure we've covered is a failure to answer one of those. A wrong group tag means the device was never told what it is. A missing license means the user was never told who they are. An app that lands late means the ready list was wrong. The sequence exists to deliver that context in order before the person ever touches the keyboard. Old thinking starts from navigation menu settings. A long list of things to tweak. New thinking starts from context. Decide what the device needs to know at first boot, then build backward from there. Next rings. We spend time on update rings and then saw the same logic apply to profiles and apps. Here's the shift. Small rings aren't an update feature. They're how every change should travel. A new profile goes to the test ring. First, a new app goes to a pilot, then wider. A feature update moves through four gates. Each ring is a small deployment with its own evidence, and the next ring only opens when the last one looks healthy. Notice what that does. It turns the fleet into its own early warning system. The failure shows up on a few devices while it's still cheap, instead of on all of them. And that leads to the last part of the model how you treat failure. In the old model, a failure is an exception. Something went wrong. So someone fixes the device and moves on. The ticket closes. Nothing is learned in the new model. Failure is data. Every stalled enrolment tells you which layer broke on which model at which site. Name the layer. Attach the logs. Count them over time. Then the failure. Stop being surprises and start being a map of where your sequence is weak. Which is why the fleet that fails a little and records it carefully ends up healthier than the fleet that reports no problems and checks nothing. So the practical question isn't which setting to change? It's what you do next, starting now. Conclusion. What to do on Monday. Start with a blank page. Draw the sequence of your current rollout link by link from hardware hash to first sign in, then put one name beside each link. If a link has no name, you just found your first problem. Next, look back at last quarter. Pick the layer that caused the most failures identity, network policy or application. Don't fix the device. Fix the model behind it. The assumption that. Let that failure happen again and again. And if this changed how you think about Intune and Autopilot rollouts, leave a review of this podcast. It helps more endpoint teams find it. Then connect with me, Mirko Peters on LinkedIn and tell me which topic to take apart next. Because the pilot always works and the fleet always tells the truth.