What Is WIP? Windows Information Protection User Scope

by David | Sep 22, 2026 | Intune

Someone opened their Entra mobility blade and saw a setting called WIP user scope sitting next to MDM user scope. They asked me what it did. Fair question. The honest answer is a little sad. It's not much anymore. So what is WIP, why is that scope still staring at you, and should you touch it? Lets sort it out.

What is WIP?

WIP stands for Windows Information Protection. It's a lightweight, built-in Windows feature that separates corporate data from personal data on the same device. The goal was simple. Let people use one laptop for work and life without leaking company files into personal apps. No switching profiles or environments all day.

Under the hood, WIP tags and encrypts enterprise data and watches how apps move it around. It can also wipe just the company data off a personal device. The personal photos and apps stay untouched. That selective wipe was the party trick everyone liked.

The name it used to have

Before it was WIP, Microsoft called it Enterprise Data Protection, or EDP. You'll still trip over the old name in the plumbing. The configuration service provider that drives it is literally named EnterpriseDataProtection, and app resource files reference EDPAUTOPROTECTION. Same feature, older label.

The scope setting has its own naming history too. That blade in Entra used to be called Mobility (MDM and WIP). Microsoft later renamed it to Mobility (MDM and MAM), so depending on when your tenant was born, you might see either.

So what is the WIP user scope, specifically?

The WIP user scope decides which users get WIP autoenrollment applied to their Windows devices. It lives right next to MDM user scope in the same blade, and it takes the same three values.

• None, nobody gets WIP autoenrollment.
• Some, only members of the Entra groups you pick.
• All, every licensed user.

To find it: Microsoft Entra admin center > Mobility (MDM and MAM) > Microsoft Intune. WIP user scope sits in the same pane as MDM user scope. The idea was a split. MDM user scope enrolled the whole device. The WIP scope let you manage just the Windows apps and their data, no full enrollment needed.

Key features worth knowing

• Data separation without profile switching. Corporate and personal data live side by side, tagged behind the scenes.
• Encryption and selective wipe. Company data gets encrypted, and you can pull just the company data off a personal device on unenroll.
• Enlightened versus unenlightened apps. Enlightened apps know the difference between work and personal data. Unenlightened apps get treated as all-or-nothing.
• Two enrollment states. With enrollment means MDM manages the whole device. Without enrollment, called MAM, managed only the apps. The without-enrollment path is now deprecated, so you cant create new unenrolled WIP policies.

The four protection modes

This is the part that actually decides how WIP feels to your users. A WIP policy runs in one of four modes, from strict to off.

Microsoft's own advice was to start in Silent or Allow Overrides, confirm your protected app list is right, and only then tighten to Block. Jump straight to Block on day one and you'll spend the week fielding tickets from people whose normal work suddenly got denied.

Phones, laptops, and where WIP actually applied

WIP was always Windows only. It never ran on an iPhone or an Android device. If someone says they put WIP on their team's iPhones, they're confused. They mean App Protection Policies, the separate MAM feature for iOS and Android. Here's the honest matrix.

The part you cant skip: WIP is deprecated

Microsoft announced the sunset of WIP in July 2022. It still works on supported Windows versions, but it gets no new features. Microsoft removed it entirely starting in Windows 11 version 24H2. The without-enrollment flavor is already gone for new policies.

For anything new, Microsoft points you at Microsoft Purview Information Protection and Purview Data Loss Prevention, including Endpoint DLP. That's the modern path, and it's where the same data-separation job now lives. If you want the deeper story on what Purview can and cant see, I wrote about that in does Intune monitor your activity.

Putting it together

WIP is Windows Information Protection, formerly Enterprise Data Protection, and the WIP user scope in Entra just controlled which Windows users it autoenrolled. It ran in four modes from Block to Off, and it only ever touched Windows. For phones you were always using App Protection Policies instead. It's deprecated now, gone in Windows 11 24H2, and Purview DLP is the replacement. If you still see the scope in your tenant, leave it at None unless you have a specific legacy reason. Put your energy into the MAM and DLP tools that are still alive.

What can we learn as a person

The four protection modes stuck with me, because they're really a scale of how rigid you're willing to be. Block never bends. It stops everything it doesn't like, and users route around it or revolt. Off bends so completely it holds nothing up. The modes that actually worked in the real world were the ones in the middle, the ones that gave a little.

Skyscrapers do this on purpose. A tall building is engineered to sway in the wind, sometimes a few feet at the top. If it stood perfectly rigid, the force of the sky pushing on it would crack it and bring it down. The sway is not weakness. The sway is the whole reason it stays standing.

I've been Block mode with people I love. Firm on every rule, no override, and it didnt make me strong, it just made me brittle and made them route around me. But I've also been Off, so flexible about everything that I stopped holding anything up, myself included. The trick I'm still learning is the sway. Enough give to survive the pressure, enough spine to not fall over. So where in your life are you running in Block mode when the wind is asking you to sway a little?

Further reading

• Deprecated features for Windows client (WIP sunset)
• EnterpriseDataProtection CSP
• Learn about Microsoft Purview Data Loss Prevention
• Learn about Endpoint DLP

Android Enterprise Management Types, Without the Acronym Soup

by David | Sep 15, 2026 | Intune

A manager walked over to my desk holding a brand new Android phone and asked me to "put it in the business manager." I knew what they meant, sort of, but that phrase does not map to any single button in Intune. Android has a whole family of ways to run a device, and the words people use for them are a mess. Business manager, work profile, kiosk, COPE, COSU, fully managed. So lets untangle the Android Enterprise management types, figure out what each one actually does to a phone, and how you pick the right one before you hand hardware to a human.

First, the thing everyone calls "the business manager"

When someone says business manager, they almost always mean Managed Google Play. It is Google's enterprise app store, and it is the connection that makes every other Android option possible. You link your Intune tenant to a managed Google Play account once. After that, Intune can push apps, enforce policy, and enroll corporate devices.

You set it up under Devices > Enrollment > Android tab > Managed Google Play. As of August 2024 you can bind it with your Microsoft Entra account instead of a throwaway Gmail address, and that is the path Microsoft now recommends. The moment you connect, Intune drops five helper apps into your console automatically. Intune, Authenticator, Company Portal, Managed Home Screen, and Microsoft Launcher. You did not add them. They just show up because the plumbing needs them.

The Android Enterprise management types, in plain English

There are four live options, and they split cleanly on one question. Who owns the phone, and does the person get a personal side? Here is each one without the acronym soup.

• Personally owned work profile (BYOD). The employee owns the phone. Android creates a separate, walled-off work profile with its own apps and its own briefcase badge. You manage that container. You never touch their photos, their texts, or their personal apps.
• Corporate-owned work profile (COPE). The company owns the phone, but you still give the person a real personal space. You get more control than BYOD, they still get a private life on the device. This is the "here is your work phone, but check your kid's soccer schedule on it too" option.
• Fully managed (COBO). The company owns it and it is a work device, full stop. No personal profile. You control the whole phone, top to bottom.
• Dedicated (COSU). The company owns it and no single person owns it. Think kiosk, scanner, digital signage, a tablet bolted to a wall. It usually locks to one app or a small set of apps. Nobody signs in with their own identity.

There is a fifth name you will still hear, Android device administrator, or DA. That was the old way, before work profiles existed. Microsoft deprecated it, and it no longer works on devices that have Google Mobile Services. If someone hands you a DA setup, treat it as legacy and plan your move off it.

One table to keep them straight

Personally owned work profile, the polite one

BYOD work profile is the option that respects the line between work and life. Android literally builds a second sandbox on the phone. Work apps go in there with a little badge. Your management stops at the edge of that sandbox. You can wipe the work profile clean and the person keeps every personal thing untouched.

This is the sweet spot for staff who already have a phone they love and do not want a second one in their pocket. It also pairs well with app protection policies if you want to go even lighter. I wrote about that split in Intune devices vs app policies if you are weighing full enrollment against just protecting the apps.

Corporate-owned work profile, the balanced one

COPE is for company hardware that you still want to feel humane. The org owns the phone, so you get stronger controls than BYOD, including tougher password rules. The employee still gets a private profile for personal apps and accounts. It is a good middle path when you are buying the phones but you do not want to run a police state.

One catch worth knowing up front. On COPE devices running newer Android, factory reset protection can require the original Google account after a reset. Plan your reprovisioning so you are not locked out of your own fleet.

Fully managed, the total one

Fully managed, or COBO, is a corporate phone assigned to one person with no personal side. You own the whole device and the whole experience. By default the user cannot install anything outside your approved apps, and they cannot remove what you require. You can open the door to the full Play Store if you want, but the default is locked down.

Reach for this when the phone is a work tool and only a work tool. Field techs, drivers, frontline staff who get a device for the job and nothing else.

Dedicated devices, the kiosk one

Dedicated, or COSU, is the type with no human owner. The device is the point, not the person. It usually pins to a single app or a small locked set through the Managed Home Screen. A checkout tablet, a warehouse scanner, a check-in kiosk, a screen showing a dashboard all day.

If you run these on rugged hardware, I have gone deep on that world in enrolling Zebra scanners into Intune and Zebra kiosk mode. Same COSU idea, real device warts and all.

How you actually get devices enrolled

Picking a management type is half the job. The other half is provisioning. For the corporate types, the common enrollment paths are:

• QR code. Factory reset the device, tap the first screen a few times to open the reader, scan the profile. Best for small batches.
• Google Zero Touch. Buy from an authorized reseller and provisioning starts the instant the user powers on. Best for scale.
• Samsung Knox Mobile Enrollment. The Samsung equivalent of zero touch for Knox devices.
• Token entry. On the Google sign-in screen you type afw#setup instead of an email, then enter a token. Handy when QR and NFC are off the table.

BYOD work profile is the odd one out. It needs no factory reset. The person installs Company Portal, signs in, and Android builds the work profile in place. That single difference drives a lot of real world decisions.

The factory reset line you cannot ignore

Here is the single fact that trips people up most. Converting a phone into a corporate mode wipes it. You cannot bolt COPE, fully managed, or dedicated onto a phone that already has stuff on it. It has to start clean. BYOD is the exception, because the work profile is added, not baked in.

Blocking the types you do not want

You do not have to allow everything. Enrollment restrictions let you decide which Android flavors are even permitted. Under Devices > Enrollment > Device platform restriction, you can allow or block the Android platform, block specific manufacturers, set OS version ranges, and block personally owned devices entirely. If your org is corporate-only, turn personal ownership off and BYOD stops at the door.

Putting it together

The Android Enterprise management types come down to two questions. Who owns the phone, and does the person deserve a personal side. Personal phone, use BYOD work profile. Company phone people also live on, use COPE. Pure work phone, go fully managed. No owner at all, go dedicated. Managed Google Play is the connection under all of it, corporate modes need a clean device first, and enrollment restrictions let you slam the door on anything you did not choose. Get those four calls right and the rest of Android management gets a lot quieter.

What can we learn as a person

The factory reset rule stuck with me. To turn a phone into a fully managed or corporate device, you cannot just layer the new rules on top of the old mess. The phone has to be wiped first. A clean slate is not optional. It is the entry fee for becoming something different.

People are not so different. I have tried to bolt a big life change onto a life I never cleared out first. New habit, same old clutter underneath. New boundary, same old patterns still running in the background. It usually failed, and it failed for the same reason a corporate profile fails on a dirty device. There was too much left over to build cleanly on top of.

BYOD is the gentler truth on the other side. Some changes really are additive. You can keep your whole self and just build a small walled space for the new thing, and it coexists fine. The hard part is honesty about which kind of change you are facing. Some things you can add to who you already are. Some things need you to wipe the slate and start clean, even though it costs you everything that was already on there. So which change in your life are you trying to bolt on, when what it actually needs is a reset?

Further reading

• Android Enterprise overview (Microsoft Learn)
• Connect Intune to your managed Google Play account
• Enroll dedicated, fully managed, and corporate work profile devices
• Create device platform restrictions

Group Policy to Intune: Migrating Settings to the Settings Catalog

by David | Sep 8, 2026 | Intune

A client asked me if he could just export his Group Policy Objects and import them into Intune in an afternoon. I wish. Twenty years of GPOs do not lift and shift into the cloud in one clean drag and drop. But moving from Group Policy to Intune is a lot less painful than most admins expect, because Microsoft built a tool that does the boring analysis for you. Let me walk through it.

If you're pushing devices toward cloud management and want to cut the on-prem cord, this is where you start.

Why Group Policy to Intune isnt a straight copy and paste

Group Policy and Intune deliver settings in completely different ways. A GPO reaches a domain-joined machine through SYSVOL and LDAP, on your network, over a trust. Intune reaches a device through MDM configuration service providers, over the internet, with no domain required.

The good news is that Intune already has many of the same settings your GPOs do. They live in the Settings Catalog, a giant searchable list of everything Intune can configure. So a lot of your policy does translate. It just moves into a new home built for cloud-native Windows instead of a domain controller.

The tool that does the heavy lifting: Group Policy analytics

Group Policy analytics is a feature inside Intune that reads your actual GPOs and tells you what will carry over. It imports a GPO, checks each setting against what MDM supports, and reports a percentage. No guessing which settings have a cloud equivalent.

Step one: export the GPO as XML

1. On a machine with the tools, open the Group Policy Management console (GPMC.msc).
2. Expand your domain, then Group Policy Objects.
3. Right-click the GPO you want and choose Save Report.
4. Set Save as type to XML File and save it somewhere easy to find.

Keep each file under 4 MB. If a single GPO is bigger than that, trim its settings or split it before you export.

Step two: import it into Intune

1. In the Intune admin center, go to Devices > Manage devices > Group Policy analytics.
2. Select Import, pick your XML file, and choose a scope tag if you use them.
3. Select Next, then Create. Intune analyzes the file automatically.

Once the analysis finishes, each GPO shows an MDM Support percentage. That number is the share of its settings that have a matching setting in Intune. Select the percentage to drill into the individual settings and see exactly which ones map and which ones dont.

Read the migration readiness report

Before you migrate anything, look at the readiness report. Go to Reports > Device management > Group policy analytics. It sorts every setting into three buckets.

• Ready for migration, the setting has a match in Intune and can move straight over.
• Not supported, no MDM equivalent exists, so this one stays behind or needs a different approach.
• Deprecated, the setting targets old Windows or old Edge versions nobody runs anymore.

This report is the honest conversation about your environment. That deprecated bucket is usually bigger than people want to admit, and every setting in it is one you get to stop carrying.

Migrate the settings into a Settings Catalog policy

Now the actual move. Back in Group Policy analytics, you turn supported settings into a real Intune policy.

1. In Devices > Manage devices > Group Policy analytics, check the Migrate box next to the GPO you want.
2. Select Migrate to see every setting inside it.
3. On the Settings to migrate tab, check the specific settings you want in the new policy.
4. Review the values, name the profile something clear like "Windows: Imported Edge GPOs," and assign it to a group.
5. Select Create. The new Settings Catalog policy shows up under Devices > Configuration.

One nice touch. If two of your GPOs set the same thing to different values, the tool catches the conflict right there and makes you pick a winner before it lets you continue. Thats a problem you'd normally only find months later when a machine behaves weird.

What wont come across cleanly

Set expectations before you start, because a few things need a different plan.

• Domain-dependent settings. Anything that assumes a domain controller on the network doesnt make sense on a cloud-native device.
• Group Policy Preferences. Drive maps, logon scripts, and printer mappings dont map one to one. Use Intune's own features for those instead.
• Non-English and non-ADMX settings. The analytics percentage only reads non-ADMX settings in English, so the number can be off for other languages.
• Security settings. Many belong in compliance policies or security baselines, not the Settings Catalog.

Do not migrate all your settings just because you can. Review each one. After the policy lands, confirm it applied by checking which policies are on the device, the same way you'd check any other Intune profile.

Putting it together

Migrating Group Policy to Intune is really four moves. Export your GPOs as XML, import them into Group Policy analytics, read the readiness report to see what actually translates, then migrate the supported settings into a Settings Catalog policy. Start with one well-scoped GPO like your Edge settings, pilot it against a small group, and prove it works before you touch the big ones. The tool removes the guesswork. Your job is deciding what deserves to come with you.

What can we learn as a person

The readiness report is the part I keep thinking about. It looks at everything you built over the years and quietly sorts it into three piles. This still works. This has no place where you're going. And this one is just deprecated, left over from a version of the environment that doesnt exist anymore.

I moved into a new chapter recently, and I tried to carry my whole old config with me. Every habit, every defense, every rule I wrote for a domain I dont live in anymore. Some of it translated fine. A lot of it was deprecated and I just hadnt run the report to notice. The healthiest thing wasnt migrating everything faster. It was being honest about what no longer applied.

So if you ran a readiness report on the settings you carry day to day, what would land in the deprecated pile? And what are you still enforcing out of habit that the new version of your life doesnt even support?

Further reading

• Import and analyze your on-premises GPOs using Group Policy analytics
• Create a Settings Catalog policy using your imported GPOs
• Use the settings catalog to configure settings
• Configuration service provider (CSP) reference

iOS/iPadOS Enrollment Methods in Intune, Bulk and Single

by David | Sep 1, 2026 | Intune

A box of 40 new iPads landed on my desk the same morning a user emailed asking to get her personal iPhone on work email. Two devices, two completely different jobs. You do not enroll a pallet of company iPads the same way you onboard one person's phone, and picking the wrong path means wiping and starting over. So here are the iOS/iPadOS enrollment methods in Intune, which ones are built for bulk, which are single shot, and who each one is actually for.

Before anything: the Apple push certificate

Nothing Apple enrolls without an Apple MDM Push certificate. It's the handshake between your tenant and Apple's push service, and every single method below depends on it.

Set it up under Intune admin center > Devices > Enrollment > Apple > Apple MDM Push certificate. Two gotchas that bite people. Use a dedicated service Apple ID, not a real person's account, because whoever owns it is now load-bearing forever. And it expires every year. If that certificate lapses, every iOS and iPadOS device you manage silently falls out of management at once, and there's no quick undo.

Quick answer on WIP, MDM, and MAM

People ask whether these methods set up WIP, MDM, or both. Short version: WIP doesn't exist on Apple. Windows Information Protection is a Windows only feature, so no iOS enrollment method touches it. On Apple you have two lanes instead. MDM means the device is enrolled and managed. MAM means App Protection Policies protect the work data inside apps without enrolling the device at all. Every method here lands in the MDM lane, except plain App Protection Policies, which is the MAM lane for personal phones you never enroll.

Single-shot methods, mostly for personal devices

These are one device at a time, driven by the user, and they lean toward bring your own device.

Device enrollment with the Company Portal

The classic path. The user installs the Intune Company Portal from the App Store, signs in, and follows the prompts to install a management profile.

1. User installs Company Portal and signs in with their work account.
2. Company Portal walks them through downloading the management profile.
3. They open Settings, and here's the gotcha, they must manually tap to install the profile under General > VPN & Device Management. iOS will not auto-install it.
4. The device checks in and policies apply.

This gives the device user affinity, so it ties to a person and gets their apps and email. It's not supervised, so you get the smaller set of controls Apple allows on user-owned devices.

Web-based device enrollment

The newer BYOD path. The user starts enrollment in Safari instead of leaning entirely on the Company Portal app up front. You turn it on under Devices > Enrollment > Enrollment types by creating an enrollment type profile and assigning it to a group. Same result as Company Portal enrollment, user affinity and MDM, just a slightly smoother start. They still need Company Portal afterward to get to company apps.

Account-driven user enrollment

This is the privacy-first BYOD option, and it replaced the old profile-based user enrollment. It uses a Managed Apple ID alongside the person's personal Apple ID, and it only manages the work side. You cant wipe the whole phone or see personal apps, which is exactly what nervous employees want to hear.

It needs a few things lined up first. Apple Business Manager, federation between Managed Apple IDs and Microsoft Entra, and iOS 15 or later. Configure it under Devices > Enrollment > Enrollment types. Use this when people balk at full device enrollment on a phone they paid for.

Bulk methods, built for corporate devices

These are how you handle a pallet of company hardware without touching each screen by hand.

Automated Device Enrollment, the big one

Automated Device Enrollment, or ADE, used to be called DEP. This is the zero-touch method. A device enrolls the moment it's turned on and connects to Wi-Fi during Setup Assistant, before a user ever gets it. It supervises the device, which unlocks the full set of restrictions, and it scales to thousands.

1. In Apple Business Manager, connect your organization to Intune and assign your devices to the Intune MDM server.
2. In Intune, go to Devices > Enrollment > Enrollment program tokens and upload your ABM token.
3. Sync, so Intune pulls in the device serial numbers Apple assigned to you.
4. Create an enrollment profile that defines the Setup Assistant experience and whether the device gets user affinity.
5. Assign the profile to your devices. Next time they wipe and boot, they enroll on their own.

The gotcha is upstream. A device can only use ADE if it lives in Apple Business Manager, which means you bought it through Apple or an authorized reseller, or you added it manually with Apple Configurator. The token also expires yearly, so put a reminder on it just like the push certificate.

Apple Configurator

When devices arent in Apple Business Manager, Apple Configurator is the fallback. It runs on a Mac and you plug the iOS devices in over USB. It comes in two flavors, and the difference matters.

• Setup Assistant with modern authentication. Supervises the device, gives it user affinity, and the user signs in. Good for corporate devices going to a specific person.
• Direct enrollment. No user affinity, no Company Portal, and the device isnt wiped. Built for shared corporate devices that nobody personally owns, like a pool of loaner iPads.

The honest gotcha is that Configurator means a Mac, cables, and hands on every device. Fine for a drawer of iPads. Miserable for a thousand.

iOS/iPadOS enrollment methods matrix: who each is for

Blocking what you don't want

Enrollment methods decide how devices come in. Enrollment restrictions decide which ones you let in at all. Under Devices > Enrollment, device platform restrictions can block personal iOS devices while allowing corporate ones, and device limit restrictions cap how many devices one person can enroll. Set these before you open the gates, not after.

Putting it together

That covers the iOS/iPadOS enrollment methods worth knowing. Pick the method by who owns the device and how many you have. Corporate hardware at scale goes through Automated Device Enrollment, full stop. Corporate devices that never made it into Apple Business Manager fall back to Apple Configurator. A personal phone that just needs email is Company Portal or web-based enrollment, or account-driven user enrollment when the person wants their privacy protected. And if you only care about the work data and not the device, skip enrollment and use App Protection Policies. Whatever you choose, set your enrollment restrictions first and never let that Apple push certificate expire.

What can we learn as a person

The push certificate is the part that stuck with me. One quiet certificate sits under all of it. You set it once, you forget it, and it just works for a year while you handle louder problems. Then it lapses, and every device you thought you had a handle on silently stops listening to you, all at once, and you didnt even feel it happen.

I have certificates like that in my own life. The quiet standing thing that holds everything else up. Sleep. A weekly call with someone who matters. The half hour that keeps me sane. None of it screams for attention, so it's the first thing I let expire when the box of iPads lands on the desk. And then one day everything I was managing just quietly disconnects, and I finally look down and realize the cert lapsed months ago.

So what's the quiet certificate holding up your whole setup right now, the one you keep meaning to renew? And when does it expire?

Further reading

• Enroll devices in Microsoft Intune
• Automatically enroll iOS/iPadOS devices with Automated Device Enrollment
• Walkthrough of the Microsoft Intune admin center
• Set up Intune enrollment and restrictions

Intune Zero Touch Deployment

by David | Aug 12, 2026 | Intune

Ordered a new laptop for a remote hire last month. Dell shipped it straight to her apartment. She opened the box, connected to Wi-Fi, and signed in. I never touched the machine. Nobody on my team ever touched the machine. That whole flow is Intune zero touch deployment, and its worth actually explaining how it works instead of just saying "Autopilot handles it."

What Intune zero touch deployment actually means

Zero touch deployment means nobody in IT ever physically handles the device. No imaging. No unboxing at the office. The manufacturer ships it directly to wherever it needs to go, often straight to the employee's house. Windows Autopilot makes this possible, but Autopilot alone isnt the whole story. The real trick is getting the device pre registered before it ever leaves the warehouse.

The hardware hash is the whole trick

Every Windows device generates a hardware hash, a fingerprint built from its manufacturer, model, and serial number. Intune needs that hash registered to your tenant before Autopilot can recognize the device. Normally someone has to boot the machine and run a PowerShell script to grab it.

OEM registration skips that step entirely. Dell, HP, Lenovo, and most major manufacturers generate the hash at the factory. They register it directly with Microsoft on your behalf, before the box ever ships. Thats the actual mechanism behind zero touch deployment. The hash exists before the device does.

Setting up drop shipping with Dell

Before Dell can register a single device for you, someone at Dell needs your permission. This step trips people up more than anything else in the whole process.

Granting Dell authorization

Dell emails a unique authorization link to your organization. A Global Administrator signs into the Microsoft 365 admin center using a cloud native account, something like yourcompany.onmicrosoft.com. That admin opens the link, checks a consent box, and selects Accept. Authorization happens instantly once they do.

Notice this requires Global Administrator, not just an Intune admin role. Thats a genuinely high privileged role, so dont hand this task to just anyone. Also worth knowing, once you authorize an OEM this way, you cant remove them yourself later. Revoking access means emailing Microsoft's support alias directly.

What happens after authorization

Once authorized, Dell registers every device you order automatically. No CSV files. No PowerShell scripts. No IT person unboxing anything first. The hash gets written to Microsoft's Autopilot database and tied to your tenant, all before the device ships. Dell never gets access to your actual tenant, they're only writing to Microsoft's registration database on your behalf.

What still needs setting up on your end

Registration only gets the device recognized. You still need a deployment profile assigned to whatever group that device lands in, defining things like deployment mode and whether the Enrollment Status Page blocks device use until apps finish installing. Ive covered building that profile in detail elsewhere, so I wont repeat all of it here. Just know registration and the profile are two separate steps, and skipping the profile means the device boots to a normal, unmanaged Windows setup instead of your branded OOBE.

The actual drop ship workflow

1. Authorize Dell once, using a Global Administrator account
2. Build your Autopilot deployment profile and Enrollment Status Page ahead of time
3. Order the laptop through Dell, specifying your tenant during the order
4. Dell registers the hash and ships straight to the new hire's address
5. The employee opens the box, connects to Wi-Fi, and signs in
6. Windows Autopilot takes over from there, joining Entra ID and enrolling in Intune automatically

Nobody on your team touches a single cable in that entire sequence.

Gotchas worth knowing before you rely on this

• Confirm your reseller or Dell account rep actually supports OEM registration for your specific device line, not every SKU qualifies
• Double check the tenant ID gets attached correctly at order time, a wrong tenant ID means the device registers somewhere other than your organization
• Build and test your deployment profile before the first real shipment goes out, dont let a new hire be your test case
• Remember you cant self service remove OEM authorization later, so get the right admin to grant it in the first place

Putting it together

Intune zero touch deployment is really two things stacked together. Dell registers the hardware hash before the device ships, and your Autopilot deployment profile tells that device what to do the moment it powers on. Get the authorization done once, get your profile built and tested, and every laptop after that ships straight to whoever needs it without IT ever unboxing a single machine.

What can we learn as a person

What gets me about OEM authorization is that you're trusting a company you'll never actually talk to with a piece of your process. Some person at Dell you'll never meet handles a step that used to require your own hands on the keyboard. And once you grant that trust, you cant even take it back yourself, you have to ask Microsoft to do it for you.

Honestly, a lot of life runs the same way. We hand pieces of our process to people we'll never meet, a pharmacist filling a prescription, an engineer who built the bridge we drive over, a stranger raising our kid's classmate. We dont personally verify most of it. We just trust the registration happened correctly somewhere upstream.

What's a piece of your life running on trust you never actually verified? And has it been working out fine anyway?

Further reading

• OEM registration for Windows Autopilot
• Windows Autopilot customer consent
• Windows Autopilot registration overview
• Configure Windows Autopilot profiles
• Manual registration overview

Microsoft Entra Connect: A Simple Setup and Hardening Guide

by David | Aug 5, 2026 | Intune

I used to work in an environment where the help desk admin spent half their day resetting passwords twice. Once in Active Directory, and then again in Office 365. If they forgot the second reset, the user could not sign in to their email, and the phone would ring. It was a miserable, repetitive cycle that drove everyone crazy. We eventually installed Microsoft Entra Connect to sync the directories, and the help desk team almost cried tears of joy.

Ok, so here is the deal with Microsoft Entra Connect. It is the sync engine that bridges your on-premises Active Directory with Microsoft Entra ID. Today we will build a simple setup guide. We will walk through how to install it, configure permissions, enable writeback, and harden the server so bad actors cannot compromise your domain.

A simple setup guide for Microsoft Entra Connect

To start, download the latest version of the installer from the Microsoft Entra admin center. Before you double-click the file, make sure your server runs TLS 1.2. Microsoft enforces TLS 1.2 for all sync connections now, and the installation will fail if you do not enable this protocol on the server first.

Once you verify your server meets the prerequisites, run the installer:

• Accept the license terms on the welcome screen.
• Choose the Use express settings option. Express settings configure password hash synchronization by default, which works perfectly for a single Active Directory forest.
• Enter your Entra tenant credentials. You must use an account with the Hybrid Identity Administrator or Global Administrator role.
• Enter your on-premises Active Directory Enterprise Admin credentials. The installer needs this level of access to create the dedicated sync account in your domain.
• Review the configuration on the ready screen, check the box to start synchronization, and click Install.

Minimum permissions for the Entra Connect user

During the express installation, the wizard automatically creates a user account starting with MSOL_ in your on-premises Active Directory. Microsoft configures this account with the exact permissions needed to read your directory. If you want to use custom settings or pre-create this account, you must configure the permissions yourself.

The sync account needs these minimum permissions at the root of your domain directory:

• Replicating Directory Changes. This permission allows the sync service to read changes from your Active Directory domain.
• Replicating Directory Changes All. The service account needs this permission to sync password hashes from your domain controllers.

If you enable writeback features later, you must grant write permissions to this account. For example, password writeback requires the account to have Reset Password, Change Password, and Write permissions on the lockoutTime and pwdLastSet attributes for all user objects in your sync scope. You can read the official Microsoft Entra Connect permission guide on Microsoft Learn to see the full list of attribute requirements.

Hardening the Entra Connect server and user access

Microsoft Entra Connect holds the keys to your entire hybrid identity kingdom. If an attacker compromises this server, they can sync malicious changes to the cloud or extract password hashes from your on-premises domain. Hardening this server is not optional.

First, install Entra Connect on a dedicated member server. You must never install this software on a Domain Controller. Installing it on a member server reduces the attack surface and prevents easy privilege escalation if someone gains local admin access to the sync box.

Second, restrict local administrative access. Only allow trusted domain administrators to log in to the sync server. The installer creates a local group called ADSyncAdmins on the server. Make sure you only place authorized users in this group, as anyone in it can modify the synchronization rules and configurations.

Third, secure the synchronization user account. The MSOL_ account does not need domain administrator rights. Do not add this account to the Domain Admins or Enterprise Admins groups. Microsoft restricts access to the sync credentials by default, but you should also monitor the account logs for any unexpected sign-in attempts. You can learn more about securing these configurations in the Microsoft Entra Connect sync hardening guide on Microsoft Learn.

Enabling writeback features

A simple setup guide usually stops at one-way synchronization, where changes only flow from AD to the cloud. But you will want to enable writeback features to make the system truly useful. The most popular option is Password Writeback, which works with Self-Service Password Reset.

To enable Password Writeback:

• Launch the Microsoft Entra Connect wizard from your server desktop.
• Click Configure and select Customize synchronization options.
• Enter your Hybrid Identity Administrator credentials to authenticate.
• Proceed through the screens to the Optional Features page.
• Check the box for Password writeback and click Next to apply the change.

Once you turn on this setting in the wizard, go to the Microsoft Entra admin center. Navigate to Protection, click Password reset, and select On-premises integration. Make sure you enable the option to write back passwords to your on-premises directory. This setup allows users to reset their own passwords in Microsoft 365, and the service will update their Active Directory password in real time.

What can we learn as a person

Managing a network without synchronization is exhausting. You push changes to one database, then copy them manually to another, hoping the two systems stay in alignment. If you do not set up writeback, information only flows one way, and the cloud never talks back to your local server. Honestly, our personal lives run into the same problem when we isolate ourselves. We try to handle every project, stress, and anxiety in our own heads without letting anyone else in. Operating in a one-way sync means you carry the entire load alone, and eventually, the systems fall out of alignment.

But the thing is, we need writeback. We must escrow our keys. A few trusted relationships can act as our on-premises integration, allowing support to flow back into our lives when the pressure builds up in our heads. Trying to run everything yourself only leads to a crash. Who acts as your writeback connection? Which person do you allow to push support and feedback back into your life when things get heavy?