The ticket says the app won't install. That is the whole ticket. No error message, sometimes no app name, just one sad sentence and a user who needs it working before their 2 o'clock. Most failed installs come down to a short list of boring causes. Basic troubleshooting clears most of them before anyone needs to escalate.
This is that list, in the order I would check it.
Get the exact error first
Basic troubleshooting starts with the words on the screen. "It failed" is not an error. "This app can't run on your PC" is an error, and it points to a completely different fix than "Another installation is already in progress." Ask the user for a screenshot. If they closed the window, have them run it again while you watch.
Then ask a few questions:
What app, and what version?
Where did the installer come from? The vendor's website, an email, a USB drive, the Company Portal?
What exactly did the screen say? Was there a number, like 1603?
Has it ever worked on this computer, or on anyone else's?
If the same installer works on the computer next to it, the problem lives on this machine. If it fails everywhere, the problem is the installer, and you can stop poking at the user's laptop.
Blocked files
Windows keeps track of where a file came from. When you download something from the internet or save it out of an email, Windows tags it as coming from another computer. Microsoft calls this the Mark of the Web. Most installers still run with that tag. Some throw a warning, and some quietly refuse to start.
The first thing you usually see is a blue box that says Windows protected your PC. That box comes from Microsoft Defender SmartScreen, and it shows up when Windows does not recognize the app yet. Clicking More info shows a Run anyway button. Only use it when you know the file came from the real vendor site or your company's own file share. If you are not sure where the file came from, stop there and ask.
How to unblock a file
Right-click the installer file and pick Properties.
Stay on the General tab and look at the bottom of the window.
If you see "This file came from another computer and might be blocked to help protect this computer," check the Unblock box.
Click Apply, then OK.
Run the installer again.
The Unblock checkbox at the bottom of a file's Properties window. This example is a Word file, but installers show the same box. Source: Microsoft Learn.
No Unblock box means the file is not tagged, and you can move on. If the installer came inside a zip file, unblock the zip before you extract it. Otherwise every file inside picks up the tag too. PowerShell can do it in one line:
Sometimes Windows Security or your antivirus grabs the installer and quarantines it. The file just vanishes, or the install dies halfway through. Check Windows Security > Virus & threat protection > Protection history. If the installer shows up there, do not restore it yourself. Send it to whoever owns security, because sometimes the antivirus is right.
Newer Windows 11 computers may also have Smart App Control turned on. It stops apps that Microsoft does not recognize and that do not carry a trusted signature. You can see its status under Windows Security > App & browser control. Do not turn it off to get one app working. Escalate it.
The wrong version for the computer
Most apps get built for a specific kind of Windows. Grab the wrong one and the installer either refuses to start or says This app can't run on your PC. Two things to check here: the processor type and the Windows version.
32-bit, 64-bit, and ARM
Go to Settings > System > About and look at System type under Device specifications. You will see something like 64-bit operating system, x64-based processor. Here is what those words mean for installers:
x64 is the normal 64-bit Windows that most business computers run. It runs x64 apps and older 32-bit apps.
x86 means 32-bit. A 32-bit copy of Windows cannot run 64-bit apps at all. Windows 11 only comes in 64-bit, so you will only see this on older Windows 10 machines.
ARM64 means an ARM processor, like the Snapdragon chips in some newer Surface and Copilot+ laptops. Windows 11 on ARM runs most normal apps through emulation, but drivers do not emulate. VPN clients, antivirus agents, and printer drivers often need their own ARM64 version.
When you download, match the file to the system type. Vendors usually put x64, x86, or ARM64 right in the file name or on the download page.
Windows version and S mode
Some apps need a minimum version of Windows. Press Windows key + R, type winver, and press Enter. The window that opens shows the version and build number. Compare that to the system requirements on the vendor's site.
Then there is S mode. A computer in S mode only runs apps from the Microsoft Store, so regular .exe and .msi installers will not run. Check Settings > System > Activation. If the edition name ends in S mode, that is your answer. Switching out of S mode is a one-way trip, so get approval before you do it.
No admin rights
Most installers want to write to C:\Program Files, and that takes admin rights. On a standard account, the installer pops up a User Account Control box asking for an admin username and password. If the user does not have one, the install stops right there.
Do not hand the user an admin password to get past this. Use whatever your company already uses to install apps for people. That might be the Company Portal, a remote session where you enter your own admin account, or a request to the team that packages apps. Some installers offer a "just for me" option that installs into the user's profile with no admin needed. Those can be fine, but check your company's policy first.
Error 1625 reads This installation is forbidden by system policy. That means a policy on the computer blocked it on purpose. Do not try to work around it. Escalate it.
Something else is already installing
Windows Installer can only run one install at a time. If something else is mid-install, the new one fails with error 1618, Another installation is already in progress. The something else is usually Windows Update, a silent install your company pushed, or an earlier attempt that hung.
Open Settings > Windows Update and look for anything installing or waiting on a restart. Give it a few minutes. If nothing changes, restart the computer and try again. A restart clears most stuck installs and finishes updates that were waiting on a reboot.
While we are on reboots, two codes look like failures and are not. 3010 means the install worked and needs a restart to finish. 1641 means the installer kicked off that restart itself. Both count as success. Restart the machine and test the app before you call it broken.
An old version is in the way
Error 1638 says another version of this product is already installed. That one is at least honest. Other times the old version is half removed, or a failed install left pieces behind, and the new install trips over them.
Go to Settings > Apps > Installed apps.
Search for the app name.
Click the three dots next to it and pick Uninstall.
Restart the computer.
Run the new installer again.
If the old version refuses to uninstall, or it is not in the list but the installer still complains, escalate. Cleaning leftover registry entries by hand can break other apps, so leave that to whoever has a test machine.
Missing pieces and full disks
Some apps need other software in place first. The classic one is an error saying VCRUNTIME140.dll was not found, or MSVCP140.dll is missing. Those files come from the Microsoft Visual C++ Redistributable. Download it from Microsoft's own site, never from a random DLL download site, install it, and try the app again.
Older apps sometimes need .NET Framework 3.5. Go to Control Panel > Programs > Turn Windows features on or off, check .NET Framework 3.5, and click OK. Windows downloads the files for this from Windows Update. If that download fails, the computer probably is not allowed to reach Windows Update directly, and you should escalate.
And check disk space under Settings > System > Storage. An installer that runs out of room halfway through can fail with a generic error that never mentions space at all.
Where the real error hides
When the screen only says the install failed, the logs usually say why.
Event Viewer
Press Windows key + R, type eventvwr.msc, and press Enter.
Go to Windows Logs > Application.
Click Filter Current Log on the right side.
In Event sources, pick MsiInstaller and click OK.
Look at the entries from the time the install failed. MSI installs write a line with the product name and an error status number. That number goes in your ticket.
A detailed install log
If the installer is an .msi file, you can make it write a detailed log. Open Command Prompt as admin and run this, swapping in your own paths:
The log will be long and ugly. Open it in Notepad and search for Return value 3. The lines just above it usually show what broke.
Here are the codes you will see the most:
Code
What it means
What to try
1603
A fatal error happened during the install. This is the generic one.
Read the log. Admin rights, a pending restart, and an old version are common causes.
1618
Another install is already running.
Wait, then restart the computer.
1619
The installer package could not be opened.
Download it again, or copy it to the computer instead of running it from a network share.
1625
System policy blocked the install.
Escalate.
1633
The package does not support this platform.
Get the right x64, x86, or ARM64 version.
1638
Another version is already installed.
Uninstall the old version first.
3010
Success, but a restart is needed.
Restart and test.
When Intune does the installing
In a lot of companies, users never run installers at all. Microsoft Intune pushes the app, or the user picks it from the Company Portal. Everything above still applies. You just look in different places.
On the computer
Open the Company Portal and check the app's status. If it failed or sits on pending, force a check-in. Go to Settings > Accounts > Access work or school, click the work account, click Info, and click Sync. Give it a few minutes.
Win32 apps from Intune install through the Intune Management Extension. Its logs live in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. AppWorkload.log is the main one for apps. It covers app check-ins, installs, applicability, and detection. CMTrace makes these logs much easier to read, but Notepad works in a pinch.
The Intune Management Extension log folder on a Windows device. AppWorkload is the one to open for app installs. Source: Microsoft Learn.
If nothing seems to happen at all, open services.msc and restart the Microsoft Intune Management Extension service. That kicks off a fresh check for apps.
In the Intune admin center
If you have access to the Microsoft Intune admin center, you can see the same failure from the admin side:
Intune admin center > Troubleshooting + support > Troubleshoot
Click Select user, search for the user, and click Select.
Pick the device from the Devices list.
Click Managed Apps.
Click any app with a failed installation status to see the installation details and the error code.
Managed Apps in the Intune troubleshooting pane, with a failed app's installation details and error code on the right. Source: Microsoft Learn.
To see one app across every device, go to Apps > All Apps, pick the app, and open Device install status under Monitor. For Win32 apps, the installation details pane also has a Collect logs option that pulls the logs off the device for you.
If a Win32 app installs as the user and the installer needs admin rights, it fails every time, because a standard user does not have those rights. That gets fixed in how the app is packaged, not on the laptop.
The basic troubleshooting checklist
None of this is fancy. Basic troubleshooting is mostly asking good questions and checking the boring stuff in the same order every time. Work it top to bottom:
Get the exact error message and a screenshot.
Find out where the installer came from, and whether it works on another computer.
Check the file's Properties for an Unblock box, and check Protection history.
Confirm the system type and Windows version match the app, and that the computer is not in S mode.
Run the install with admin rights through your company's normal process.
Restart the computer and try again.
Remove any old version, restart, and reinstall.
Check disk space and prerequisites like Visual C++ and .NET Framework 3.5.
Pull the error code from Event Viewer or the install log.
For Intune apps, check the Company Portal, sync, and read AppWorkload.log.
If you escalate, put the app name and version, the exact error and code, the system type, the Windows version, and what you already tried in the ticket.
What can we learn as a person
Error 1618 is the one I think about outside of work. Windows can only run one installer at a time. If something is still installing, the next thing waits or it fails. Double clicking harder does not help.
I do this to myself all the time. I start a new routine and a new project in the same week, while the last thing is still half installed, and then I wonder why nothing finishes. And when something does finish, I skip the restart. Error 3010 means the install worked and just needs a reboot before it takes. I keep forgetting that rest is part of finishing.
So what is still installing in you right now? And what are you trying to start on top of it before it is done?
Autopilot used to mean one thing. Grab the hardware hash, upload it, build a profile, and watch the Enrollment Status Page crawl. Now there is a second Autopilot, and Microsoft calls it a re-architecture. Autopilot device preparation skips the hardware hash and the Enrollment Status Page, but it also skips a few things you might be counting on.
Device preparation does not do pre-provisioning, self-deploying mode, Autopilot Reset, hybrid join, co-management, or Windows 10. It also cannot hold the user at setup until their user-based settings finish. Microsoft describes it as simpler and faster but less feature rich.
Which one should you use?
If your devices are cloud only and run Windows 11, device preparation is the easier road. If you need hybrid join, kiosks with self-deploying mode, or pre-provisioning, stay on classic. Both can live in the same tenant, but a single device only runs one of them. Your existing classic profiles do not need to move.
Watch out for devices that already have a hardware hash uploaded. A registered device runs the classic profile, not device preparation. To switch one over, deregister it from classic Autopilot first.
Set up Autopilot device preparation
Step 1: The device group
Device preparation drops each new device into a group during setup. Create a security group in Groups > New group with Membership type set to Assigned and Microsoft Entra roles can be assigned to the group set to No. Under Owners, add Intune Provisioning Client. In some tenants it shows up as Intune Autopilot ConfidentialClient. If it is missing entirely, create it with Microsoft Graph PowerShell:
Intune admin center > Devices > Device onboarding > Enrollment, on the Windows tab.
Under Windows Autopilot device preparation, open Device preparation policies and click Create, then User Driven.
On Device group, pick the group from Step 1.
On Configuration settings, set the options below and pick the apps and scripts to install during setup.
On Assignments, pick the group of users who will set up devices.
Review + create.
Join type: Microsoft Entra joined.
User account type: Standard User or Administrator. Standard User keeps people from becoming local admins.
Minutes allowed before showing installation error: Anywhere from 15 to 720.
Custom error message, Allow users to skip setup after multiple attempts, and Show link to diagnostics: These control what the user sees when it fails.
Apps and scripts you pick here must also be assigned to the device group and set to install in the System context. Anything else assigned to that device group installs after the user reaches the desktop. If you have more than one policy, drag them into order. The lowest number wins.
Device preparation shows this progress screen instead of the Enrollment Status Page. Source: Microsoft Learn.
If a user sees the classic Enrollment Status Page instead of this screen, the device is running classic Autopilot, not device preparation.
Classic pre-provisioning
Pre-provisioning, which used to be called White Glove, lets IT or a partner run the slow device part of setup ahead of time. The user's part on day one gets much shorter.
Pre-provisioning moves most of the setup work from the user to IT or a partner. Source: Microsoft Learn.
It needs a physical device with a TPM 2.0 chip, because virtual machines are not supported. It also needs Windows Pro, Enterprise, or Education, an Enrollment Status Page assigned to the device, and Allow pre-provisioned deployment set to Yes in the deployment profile. Use a network cable if you can. Wi-Fi forces extra region and keyboard screens.
The technician steps
Power on the device and wait for the work or school sign-in screen.
Press the Windows key five times.
Choose Pre-provision with Windows Autopilot and click Next.
Check the organization, profile, and assigned user, then click Provision.
Wait while the device part of setup runs.
On success, click Reseal and box it up. On failure, pick Retry or Reset, and press Ctrl+Shift+D to export logs first.
The technician phase installs everything aimed at the device, plus device-context apps aimed at the assigned user. The user phase installs the rest. Error 0x80180005 means someone tried to pre-provision with a profile that does not allow it.
Device name templates
Classic deployment profiles have an Apply device name template setting. Names can be 15 characters at most, use letters, numbers, and hyphens, and cannot be all numbers. %SERIAL% adds the serial number, and %RAND:x% adds x random digits, so HQ-%RAND:5% gives you something like HQ-48213. Templates only work with Entra join. Hybrid profiles only let you set a prefix.
Troubleshooting Autopilot
Start with the reports. Devices > Monitor > Windows Autopilot device preparation deployments shows each phase and each app for device preparation. Devices > Monitor > Windows Autopilot deployment status covers classic Autopilot.
On the device during setup, Ctrl+Shift+D opens the diagnostics page on Windows 11. For classic Autopilot, the Enrollment Status Page has to allow it first. Shift+F10 opens a command prompt, where this command bundles the Autopilot logs:
Intune can also grab logs on its own when Autopilot fails. That setting lives under Tenant administration > Device diagnostics, and the logs show up on the device page under Diagnostics.
The Device diagnostics page, including the option to capture logs automatically when Autopilot fails. Source: Microsoft Learn.
Common problems
The device preparation screen never shows up: The device has a hardware hash registered, the user is not in the policy's user group, the policy has no device group, or Windows is too old.
Apps show Skipped: They are not assigned to the device group or are not set to install in the System context.
The device group will not save or shows 0 groups: Intune Provisioning Client is not an owner of the group.
Classic event 807 or 815 in the Autopilot event log: The device is not registered, or it has no profile assigned.
Error 0x800705B4: A timeout, often a device without TPM 2.0 or a virtual machine.
Error 0x80180014: A device that went through self-deploying or pre-provisioning is being reused. Unblock it from the Windows Autopilot devices list or delete its record.
The Autopilot event log is in Event Viewer under Applications and Services Logs > Microsoft > Windows > ModernDeployment-Diagnostics-Provider > Autopilot.
Picking your Autopilot path
Use Autopilot device preparation for new cloud-only Windows 11 devices and keep classic Autopilot for hybrid join, kiosks, and pre-provisioning. Build the device group with the right owner first, keep setup apps to the ones people need on day one, and check the deployment report after your first few devices.
What can we learn as a person
Pre-provisioning exists because nobody wants to watch apps install on their first morning. IT does the heavy part ahead of time, reseals the box, and the user's part is short.
I do not pre-provision anything. Every Monday starts from bare metal. No lunch packed and no idea what the first task is, and then I wonder why the first two hours feel like an Enrollment Status Page that never finishes.
What could you pre-provision for future you tonight? And what is one thing you could reseal and hand to tomorrow already done?
A laptop left in a cab is an embarrassing day. An unencrypted laptop left in a cab is a breach notification. An Intune BitLocker policy encrypts every Windows drive without asking the user anything, stores the recovery key where the helpdesk can find it, and tells you which machines are not encrypted yet.
I covered where to find BitLocker keys before. This post is about building the policy so those keys exist in the first place.
Create the BitLocker policy
Intune admin center > Endpoint security > Disk encryption
Click Create Policy, set Platform to Windows and Profile to BitLocker, then click Create.
Name it, set the settings below, and assign it to a device group.
Most BitLocker settings only apply the first time a drive gets encrypted. If a drive is already encrypted a different way, changing the policy later does not redo it. Deliver your Intune BitLocker policy early, ideally during Autopilot setup.
Silent encryption
Silent encryption means BitLocker turns on with no prompts and no user involvement. Users never see a wizard and never get asked whether they want it. To make that happen, these settings have to line up:
Require Device Encryption: Enabled.
Allow Warning For Other Disk Encryption: Disabled. This hides the prompt about other encryption software.
Allow Standard User Encryption: Enabled. It only shows up after you disable the previous setting, and it lets encryption run when the signed-in user is not an admin.
The two settings that start silent encryption, with Allow Standard User Encryption right under them. Source: Microsoft Learn.
The operating system drive settings also have to stay out of the way. Set Require additional authentication at startup to Enabled. Then set Configure TPM startup to Allow TPM or Require TPM, and set the startup PIN, the startup key, and the startup key and PIN options to Do not allow. If any of those require a PIN, the user has to type something, and silent encryption fails.
What the device needs
Windows 10 1809 or newer, or Windows 11, on Pro, Enterprise, or Education.
Entra joined or hybrid joined.
A TPM chip, UEFI firmware rather than legacy BIOS, and Secure Boot turned on.
The Windows Recovery Environment turned on.
For the encryption method, Microsoft recommends XTS-AES. If you leave the setting alone, BitLocker uses XTS-AES 128, and 256 works well on newer hardware. If you set the method at all, set it for operating system, fixed, and removable drives together, or the policy fails. Intune's own default for fixed and removable drives is AES-CBC, so pick XTS-AES there on purpose. USB drives that also plug into non-Windows machines should stay on AES-CBC.
Recovery keys
Under Choose how BitLocker-protected operating system drives can be recovered, turn on saving recovery information and turn on Do not enable BitLocker until recovery information is stored. The setting names mention AD DS, but on Entra joined devices they control the backup to Entra ID. Hybrid joined devices back up to both.
Also set Configure Recovery Password Rotation so a key changes after someone uses it. Rotation only works when the store-before-enabling setting is on.
Who can see the key
Admins find it under Devices > All devices, then the device, then Monitor > Recovery keys > Show Recovery Key. Every view gets logged. Helpdesk Administrator, Cloud Device Administrator, and Intune Administrator can read keys. If Intune says No BitLocker key found for this device, the key never made it to Entra ID.
Users can get their own key without calling you. On the Company Portal website, they go to Devices, pick the PC, and click Get recovery key. They can also use myaccount.microsoft.com under Devices. The key hides again after 5 minutes.
Users can pull their own recovery key from the Company Portal website. Source: Microsoft Learn.
If you would rather users call the helpdesk, turn on Restrict non-admin users from recovering the BitLocker key(s) for their owned devices in the Entra Device settings. Deleting a device in Entra ID deletes its BitLocker keys too.
Removable drives
Deny write access to removable drives not protected by BitLocker makes every unencrypted USB drive read-only. People can still open files from a thumb drive but cannot copy company files onto one unless it is encrypted. Test this one with a pilot group first, because it surprises people.
Checking encryption
Intune has an encryption report that lists every Windows device with its TPM version, encryption readiness, and encryption status. Find it under Devices > Monitor. Microsoft's own pages give it slightly different names. It can take up to 24 hours to update, it only covers the operating system drive, and you can export it to CSV.
On the device itself, open Command Prompt as admin and run:
manage-bde -status c:
manage-bde -status shows the encryption state, the method, and the key protectors. Source: Microsoft Learn.
Fully Encrypted with Protection On is what you want. The Numerical Password listed under Key Protectors is the recovery password. PowerShell gives the same answer with Get-BitLockerVolume -MountPoint C | Format-List. The detailed log is in Event Viewer under Applications and Services Logs > Microsoft > Windows > BitLocker-API > Management.
When encryption will not start
Failed to enable Silent Encryption with a note about conflicting settings: Something allows or requires a startup PIN or key. Check every policy, including the Defender for Endpoint security baseline, which allows a startup PIN by default.
TPM is not available: The TPM is off in the BIOS or missing. Check with Get-Tpm or tpm.msc.
The recovery environment is disabled: Run reagentc /info, then reagentc /enable.
The device boots in legacy BIOS mode: Silent encryption needs UEFI.
The encryption method of the OS volume doesn't match the BitLocker policy: Someone encrypted it differently before the policy arrived. The drive has to be decrypted and encrypted again.
Recovery key backup failed: The device could not reach Entra ID, or it already has 200 keys stored, which is the limit.
A BitLocker baseline that works
Build one Intune BitLocker policy with silent encryption, TPM-only startup, XTS-AES on operating system and fixed drives, and recovery keys required in Entra ID before encryption starts. Assign it to devices, deliver it during Autopilot, and check the encryption report for anything stuck on Not ready.
What can we learn as a person
BitLocker has a rule I wish I followed. With the right setting, encryption will not turn on until the recovery key is stored somewhere safe. Lock the drive, sure, but only after someone else can get you back in.
I am great at the encryption part. Bad weeks and the stuff I do not say out loud stay locked down tight. I am terrible at escrow. When I lock myself out, there is no recovery key in anyone's account, and I sit at the blue screen alone.
Who holds your recovery key? And if the answer is nobody, who could you give it to?
The ticket said "email is fine, we just need Autodiscover to stop popping a certificate warning." Two hours later I was in ADSI Edit staring at a full Exchange organization for a server that had not existed since 2019. The previous admin had done the thing that feels productive at 4:45 on a Friday. They shut the VM down, deleted it from the host, removed the computer object, and went home. Active Directory never got the memo.
This is a common mess. The mailboxes went to Exchange Online years ago, nobody has touched the on-prem box since, and then somebody tries to run a schema update, or install a new Exchange server, or clean up Entra Connect, and the ghost server shows up and blocks it. You can still remove Exchange on prem after the fact, with nothing left to work from but what Active Directory remembers about the server. The environment in this walkthrough is the one I keep running into: the dead server was Windows Server 2012 R2 running Exchange Server 2013 CU23, and it was the only Exchange server in the org.
What deleting a server actually leaves behind
Exchange keeps almost none of its configuration on the server itself. That is the whole design. The server is a set of binaries and a couple of databases, and everything that describes the organization lives in the configuration partition of Active Directory. Delete the VM and you have deleted the least important half.
Here is what is still sitting in your directory right now:
The CN=Microsoft Exchange container under CN=Services,CN=Configuration, with your organization name under it.
The server object itself, at CN=<ServerName>,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=<OrgName>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com.
Exchange security groups in the Microsoft Exchange Security Groups OU: Organization Management, Exchange Trusted Subsystem, Discovery Management, and friends.
Arbitration and system mailboxes. The SystemMailbox{GUID} accounts, FederatedEmail, Migration, and DiscoverySearchMailbox.
Address lists, the offline address book, accepted domains, send connectors, and the Autodiscover service connection point that is still telling domain-joined Outlook clients to go talk to a machine that is not there.
The msExch* schema extensions. Those are permanent no matter what you do, so make peace with them now.
Every mail-enabled user in your domain also still carries Exchange attributes. Those live on the user object, not in the org container, and they are not the problem. Leave them alone.
Why you cannot remove Exchange on prem with ADSI Edit alone
I know. It is right there. You can right-click the org container and be done in fifteen seconds.
Microsoft does not support removing Exchange objects with ADSI Edit, and it is not a legal technicality. Setup writes objects in a specific order with specific cross-references. When you rip the container out by hand you tend to leave behind orphaned links in places you did not look, and the next Exchange install in that forest fails at the readiness check with an error that will not tell you why. If the environment is hybrid, you can also break recipient management in a way that is genuinely painful to unwind, because on-prem is still the source of authority for those attributes.
ADSI Edit is the last resort, not the first move. The supported way to remove Exchange on prem is to bring the server back from the dead, and then kill it properly.
Step 1: Inventory before you touch anything
You need three facts to rebuild: the exact server name, the exact Windows version, and the exact install path. Two of those are in AD.
Open ADSI Edit from a domain controller or a workstation with RSAT installed. Connect to the Configuration naming context, then walk down to:
CN=Configuration > CN=Services > CN=Microsoft Exchange > CN=<YourOrgName>
> CN=Administrative Groups > CN=Exchange Administrative Group (FYDIBOHF23SPDLT)
> CN=Servers
Right-click the server object, choose Properties, and write down these attributes:
cn gives you the name the new server has to use. It has to match exactly.
msExchInstallPath gives you the install location. If it is not C:\Program Files\Microsoft\Exchange Server\V15 you will need the /TargetDir switch later.
serialNumber and msExchCurrentServerRoles tell you the build and which roles were installed.
You can get most of this from PowerShell on any domain-joined machine with the AD module, which is faster and gives you something to paste into your notes:
Run that before you assume there is only one. I have walked into environments where the "one old Exchange server" was actually three, and two of them were still powered on in a corner of the datacenter answering SMTP.
Then take a backup of the config container. Not a snapshot of a domain controller, because rolling a DC back causes its own category of misery. Take an LDIFDE export:
That file will not restore itself automatically if things go wrong, but it is a complete record of what was there, and when you are on the phone with support at 9pm that record is worth a lot. Run a system state backup on a DC while you are at it. If your directory is built on a tiered admin model, do this work from the tier that owns the forest, not from your daily driver.
Step 2: Confirm you should actually remove it
Skip this step and a clean weekend turns into an outage. Before you remove Exchange on prem, find out what was leaning on it. Removing the Exchange organization removes the tooling that manages mail attributes on-prem. If Entra Connect is still syncing users up to Microsoft 365, and those users are managed on-prem, you need to know what happens after Exchange is gone.
Work through this list honestly:
Are all mailboxes in Exchange Online? If any mailbox, archive, or public folder is still on-prem, uninstall will refuse.
Is anything relaying SMTP through the old server? Printers, scanners, alarm panels, that one ancient line-of-business app. If the server is already gone this is moot, but check whether someone quietly pointed those at a different internal relay and whether it is still needed.
Is directory sync still running? If yes, decide how Exchange attributes get managed afterward. Microsoft's current answer is cloud-based management of Exchange attributes, which flips the source of authority to Exchange Online. Read up on that before you commit, because it changes how you provision new mailboxes.
Are there hybrid objects left? Organization relationships, intra-org connectors, a federation trust, HCW-created inbound and outbound connectors in Exchange Online. Those live in the tenant and survive the on-prem server just fine.
Do you plan to install Exchange again later? If the answer is "maybe for recipient management," the Exchange Management Tools route is a different conversation, and uninstalling removes the AD containers those tools depend on.
Microsoft's flow for what has to be true before the last Exchange server can come out. Source: Microsoft Learn.
Step 3: Build the stand-in server
Exchange has a recovery mode that rebuilds a server entirely from what is in Active Directory. It was designed for hardware failure. It works just as well when the "failure" was a coworker with a delete key, and it is the only supported way to remove Exchange on prem once the original box is gone.
The rules are strict, and this is where most attempts fall over:
The new server has to run the same version of Windows as the old one. Our dead server was Windows Server 2012 R2, so the rebuild is Windows Server 2012 R2. Not 2016. Not 2012. Recovery checks this and refuses.
The new server has to have the same computer name. Not similar. Identical.
The same drive letters that held mounted databases have to exist. If the old box had databases on E:, give the new VM an E: volume.
The computer account in AD gets reset, not deleted. If the previous admin already deleted it, you will create a fresh one when you join the domain, and that works fine.
So: spin up a VM, install Windows Server 2012 R2 full desktop experience, name it to match, patch it, and join it to the same domain. If the computer object still exists, reset it first from Active Directory Users and Computers by right-clicking the object and choosing Reset Account.
This VM is disposable. It exists for one afternoon. Give it enough RAM to run Exchange setup without crying, around 8 GB, and about 80 GB of disk. It never has to handle a single message.
Step 4: Install the prerequisites
Exchange 2013 CU23 on Windows Server 2012 R2 wants a specific pile of components. Run this in an elevated PowerShell session on the new server:
Reboot when it asks. Then install these, in this order:
.NET Framework 4.7.2. CU23 requires it and will throw an error if you are on an older build. This is the single most common prerequisite failure I see.
Windows Management Framework 4.0, which ships with Server 2012 R2 already, so you are usually just confirming it is there.
Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit.
Visual C++ Redistributable for Visual Studio 2012.
Visual C++ Redistributable for Visual Studio 2013.
Now the media, where Exchange 2013 parts ways with the newer versions. Exchange 2016, 2019, and Subscription Edition ship their cumulative updates as ISO files that you mount. Exchange 2013 ships Exchange2013-x64-cu23.exe, a 1.6 GB self-extracting archive. It is not an ISO, it does not contain an ISO, and it will not mount anything.
You do not need a base Exchange 2013 ISO at all. Every Exchange cumulative update is a complete build of the product, not a patch on top of an earlier install. CU23 by itself is full setup media, so you can skip hunting for the original 2013 or SP1 media in VLSC. That hunt is where people usually lose an afternoon.
Step 5: Run the recovery
Log on to the new server with an account that is in both Domain Admins and Organization Management. If you are not sure who is actually sitting in that group, go count them first, because temporary membership for a job like this has a habit of becoming permanent. Since the Exchange org still exists in AD, that Organization Management group still exists too, and you can add yourself to it.
First extract the setup files. Double-click Exchange2013-x64-cu23.exe and it prompts you for a folder, or do it from the command line so you know exactly where things landed:
Exchange2013-x64-cu23.exe /extract:C:\CU23
That is the standard Microsoft Self-Extractor switch. If it does not behave, run the file with /? to see what that particular package supports, or just double-click it and browse to a folder. Extraction takes a few minutes and produces a full setup tree with Setup.exe at the root of it. Give it somewhere with a few gigabytes free.
Then open an administrative command prompt and run setup from the folder you extracted to:
Microsoft's own recovery article tells you to mount an ISO and run E:\Setup.exe. That article is written for Exchange 2016 and 2019. The 2013 version of the page skips the mounting step entirely and just says to navigate to the installation files. Same idea, different starting point. Check it before you go looking for a drive letter that will never appear.
A note on that license switch. Newer Exchange 2016 and 2019 builds replaced it with /IAcceptExchangeServerLicenseTerms_DiagnosticDataON or _DiagnosticDataOFF. Exchange 2013 CU23 predates that change, so the plain switch is correct here. If you copy a command off a 2019 article it will not run.
Setup reads the server object out of AD and reinstalls the roles it finds. This takes a while. Go get coffee.
If the Scripting Agent was ever enabled in this organization, recovery dies with a complaint about a missing ScriptingAgentConfig.xml. Since this is the only Exchange server, the fix is to rename %ExchangeInstallPath%Bin\CmdletExtensionAgents\ScriptingAgentConfig.xml.sample to ScriptingAgentConfig.xml and run setup again.
When it finishes, reboot, then open services.msc and confirm the Microsoft Exchange services are installed and running. Open the Exchange Management Shell and run Get-ExchangeServer. Seeing that dead server name come back with a live status is satisfying, and a little unsettling.
Step 6: Clean the organization before uninstalling
You now have a working Exchange server that knows about everything the old one knew about. Uninstall will refuse to run while certain objects still exist, so clear them first.
In the Exchange Management Shell, widen the scope to the whole forest and then check what is still homed here. All five of these should come back empty:
In the after-the-fact scenario, the first three are almost always empty because everyone moved to the cloud years ago. The arbitration and audit log mailboxes are the ones that will still be there, because they were created by setup and never went anywhere. They also block uninstall, and they need the disable-and-remove treatment described in Microsoft's article on removing a mailbox database, which covers the -DisableLastArbitrationMailboxAllowed case for the final one.
Also clear the Autodiscover service connection point so domain-joined Outlook clients stop looking at Active Directory for an endpoint that is about to vanish:
On Exchange 2013 it is Set-ClientAccessServer. The Set-ClientAccessService version arrived in 2016. Small difference, and it will trip you up if you are pattern-matching from a newer guide.
If the organization was ever hybrid, remove the hybrid configuration object so the Hybrid Configuration Wizard cannot rebuild it later:
Remove-HybridConfiguration
Then check for the offline address book generating mailbox, any send connectors that still reference this server, and any public folder deployment. An OAB pinned to a mailbox you are about to remove will stop the uninstall dead.
What the environment looks like on the way in, before anything comes out. Source: Microsoft Learn.
Step 7: Remove Exchange on prem for good
Once those queries all come back empty, you are clear to remove Exchange on prem properly. Run the uninstall from an administrative command prompt on the rebuilt server:
You can also do it from Control Panel > Programs and Features, select Microsoft Exchange Server 2013, and click Uninstall. Same outcome. The command line gives you better logging in C:\ExchangeSetupLogs\ExchangeSetup.log, which is where you will be reading if it fails.
When setup finishes, this is what leaves and what stays.
Removed:
The CN=Microsoft Exchange organization container and your org subcontainer under it.
The Exchange security groups.
The server object.
The system and arbitration mailboxes.
All receive connectors. That is permanent, so if anything was still relaying, you already dealt with it in step 2.
Left behind:
The msExch* schema extensions. These are schema, not configuration, and they are there for the life of the forest. This is normal and harmless.
Exchange attributes on individual user objects, such as proxyAddresses, mail, and the extension attributes. Leave them.
The CN=Microsoft Exchange Autodiscover container and its Exchange Online service connection point child. This is a different container from the org container, and uninstall does not touch it. If you actually want it gone, that one is a manual ADSI Edit delete, and it is the only place in this whole process where ADSI Edit is the right tool.
The end state once Exchange is out of the on-premises environment. Source: Microsoft Learn.
Step 8: Verify, then delete the stand-in
Go back to ADSI Edit and confirm that CN=Microsoft Exchange under CN=Services,CN=Configuration is gone. When that container disappears, you have actually removed Exchange on prem rather than hidden it. Then run the earlier LDAP query again:
Empty result means you are done. Check that the Microsoft Exchange Security Groups OU is empty or gone, and confirm the Exchange objects no longer appear in your Entra Connect sync scope if you are still syncing.
Then shut down the stand-in VM, unjoin or delete the computer object, and delete the VM. Its whole job was to give setup a place to stand while it removed itself. Do not leave it running "just in case," because in six months it becomes exactly the same problem you just spent a Saturday fixing.
Where this goes sideways
A few things I would watch for when you remove Exchange on prem this way.
Wrong Windows version. Recovery mode compares the OS and stops. If you built 2019 because that is what your template makes, you get to build it again.
Certificates. Recovery assigns a self-signed certificate to every service that needs TLS. On a server you are about to delete, who cares. On a server you actually intend to keep, reimport the real certificate before anyone connects.
Missing databases. The database objects come back from AD, but the EDB files do not, because they were on the disk you deleted. That is fine for this workflow. You are removing them, not mounting them.
More than one Exchange server in AD. If the query in step 1 returned several, do this one server at a time, and remove the last one last. The order matters more than you would like.
Someone still needs on-prem recipient management. Stop and plan that before you uninstall. Once the containers are gone, the on-prem cmdlets are gone with them.
Remove Exchange on prem: the short version
Read the server object out of AD and back up the config container with LDIFDE. Build a throwaway VM with the same name and the same Windows version. Install the prereqs, extract the CU23 self-extractor, and run Setup /m:RecoverServer from it. Clear the arbitration mailboxes and the SCP. Run Setup /m:Uninstall, verify the org container is gone, and delete the VM. Budget a full day the first time. Budget half a day once you have done it before.
And if you are the one shutting down a server this month, take the forty minutes to remove Exchange on prem properly while the box still boots. The person who inherits your network in three years will never know they should thank you.
Where to get the media
Half the pain in trying to remove Exchange on prem is hunting for an installer that Microsoft quietly moved. Here is where things actually live right now. Everything below was checked before this went up, but download pages get reshuffled, so if a link has rotted by the time you read this, search the Download Center by KB number and you will usually land on it.
Windows Server ISOs
The Microsoft Evaluation Center still hands out full ISOs with a 180-day evaluation period. For a throwaway rebuild server that lives for one afternoon, that is more than enough runway. If you have volume licensing media, use that instead, and talk to whoever owns licensing before you put an evaluation build anywhere near production Active Directory. It is a short conversation and it saves a longer one later.
Remember the matching rule. Whatever the dead server was running, that is what you build. Windows Server 2012 R2 extended support ended in October 2023, so you are installing an out-of-support OS on purpose, for a few hours, on a box that never touches the internet. Keep it off the public network and delete it when you are done.
Exchange Server media
Exchange Server 2013 CU23 (KB4489622). The last cumulative update for 2013 and the one this whole article is built around. You get Exchange2013-x64-cu23.exe, a 1.6 GB self-extracting archive rather than an ISO. Extract it, then run Setup from the folder.
Exchange Server 2016 CU23 (KB5011155). The release page. The media itself comes from the Volume Licensing Service Center or the Microsoft 365 admin center rather than a public download link.
Watch the file type, because it changes by version and it catches people out. Exchange 2013 cumulative updates are self-extracting .exe files. Exchange 2016, 2019, and Subscription Edition cumulative updates are .iso files that you mount. Exchange 2010 SP3 is an exe as well. In every case the cumulative update is a complete build of the product, so you never need to install an older version first and then patch your way up to it.
Exchange 2013 went out of support in April 2023. You are not installing it to run it. You are installing it so that setup has something to stand on while it deletes itself, and then the VM goes in the bin. If somebody in the room suggests keeping it around, that is how the next admin ends up reading this article.
You will also need the prerequisites, which are separate downloads:
I have a habit of closing tabs instead of finishing what is in them. Browser tabs, but also the other kind. I stop replying to a group chat instead of saying I am stepping back. I let a subscription lapse instead of cancelling it. I stop showing up somewhere instead of telling anyone I am not coming. It feels clean in the moment. Nothing is on my screen anymore, so nothing is my problem anymore.
That is exactly what the last admin did with that server. They removed the visible part and left the record of it running in the background, quietly breaking things for someone else. I have written before about doom boxes and what we hand off so we stop carrying it. This is the other half of that. The uninstall is never the hard part. The hard part is going back to a thing you already emotionally closed and doing the boring, unrewarding work of ending it on purpose.
I am not sure I am good at this yet. I do know that the things I walked away from without saying anything are the ones that still come back at odd hours. What did you delete instead of decommission?
Certificate-based Wi-Fi is the right way to keep strangers off the network. Getting there used to mean an on-premises certificate server, an NDES server, the Intune certificate connector, and a long weekend. Intune Cloud PKI gives you the certificate authority from the cloud, so devices get their certificates without any of those servers.
What Cloud PKI replaces
PKI stands for public key infrastructure. It is the system that issues certificates, renews them, and revokes them. Microsoft Cloud PKI does all of that for devices enrolled in Intune, and Microsoft hosts the pieces you used to run yourself: the certificate authority, the revocation list, and the address devices use to look up the chain. It works on Windows, macOS, iOS/iPadOS, and Android.
It is a paid add-on on top of Intune Plan 1 or Plan 2 and part of the Intune Suite. Microsoft's June 2026 update notes say Cloud PKI is also rolling out to Microsoft 365 E5. You can start a 90-day trial for up to 250 users from Intune admin center > Tenant administration > Intune add-ons > All add-ons.
Limits worth knowing up front
A tenant gets 3 certificate authorities total, counting root, issuing, and bring-your-own CAs. A root plus an issuing CA uses two of them.
The keys live in Azure Managed HSM, and you do not need an Azure subscription for that. CAs you build during a trial use software keys and cannot be upgraded later.
You cannot edit a CA after you create it. Get the settings right the first time.
Cloud PKI also does not issue server certificates for your RADIUS or VPN servers, so those still come from somewhere else. It hands out certificates. Something else, usually a RADIUS server, still has to check them at the door.
Pick a model
Cloud PKI root CA: Intune creates both the root CA and the issuing CA. This is the simplest option for a company starting fresh.
Bring your own CA: Intune creates only the issuing CA, and your existing private root, like Active Directory Certificate Services, signs it. This fits a company whose network already trusts its own root.
You can run both in the same tenant. Either way, your Wi-Fi access points, VPN servers, and RADIUS servers need the root and issuing certificates installed by Group Policy or by hand. They also need network access to the revocation list.
Devices get the certificate chain through Intune. Wi-Fi, VPN, and other servers need it delivered another way. Source: Microsoft Learn.
Create the certificate authorities
Start with the root:
Intune admin center > Tenant administration > Cloud PKI
Click Create and give the CA a name.
On Configuration settings, set CA type to Root CA and pick a Validity period of 5 to 25 years.
Pick the Extended Key Usages. For Wi-Fi and VPN sign-in, you want Client authentication.
Fill in the Subject attributes, at minimum a Common name, and choose the Key size and algorithm.
Review + create.
Then create the issuing CA the same way. Set CA type to Issuing CA, set Root CA source to Intune, and pick the root you just made. The issuing CA lasts 2 to 10 years and cannot outlive its root.
Creating an issuing CA. Root CA source is where you pick Intune or your own root. Source: Microsoft Learn.
Be careful with the Extended Key Usages. An issuing CA can only use the ones its root has, and Any Purpose is not supported. Since nothing can be edited later, adding a usage you forgot means building a new CA, and you only get three.
Get certificates onto devices
Open each CA and click Properties. Download the public certificate for both the root and the issuing CA. On the issuing CA, also copy the SCEP URI. Then build three profiles under Devices > Manage devices > Configuration > Create:
A trusted certificate profile with the root certificate.
A trusted certificate profile with the issuing certificate. Android does not look up missing chain pieces on its own, so it needs both.
A SCEP certificate profile that requests the device's certificate.
SCEP profile settings that matter
Certificate type: User or Device, depending on whether the certificate follows the person or the machine.
Subject name format and Subject alternative name: what goes in the certificate. If you use a variable like the email address and the user has no email in Entra ID, no certificate gets issued.
Root Certificate: Pick the root's trusted certificate profile, not the issuing one.
Extended key usage: must match what the CA has. Client Authentication for Wi-Fi and VPN.
Renewal threshold: the percentage of life left when the device asks for a new certificate.
SCEP Server URLs: Paste the SCEP URI exactly. Leave the {{CloudPKIFQDN}} part alone, because Intune fills it in.
Assign the trusted certificate profiles and the SCEP profile to the same kind of group. If one goes to users and the other goes to devices, the SCEP profile fails. Once certificates land, point your Wi-Fi or VPN profile at the SCEP profile for authentication.
Monitor and revoke
Open a CA and look at the Monitor tab. It counts active, expired, and revoked certificates. Click View all certificates, pick one, and click Revoke to kill it. For a view across everything, go to Devices > Monitor > Certificates. These reports update every 24 hours, so do not panic over a missing certificate from this morning.
The Monitor tab on an issuing CA, where revocation starts. Source: Microsoft Learn.
A revoked certificate comes right back if the SCEP profile is still assigned. The device asks for a new one at its next check-in. If you want a device off the network, remove it from the assignment first, then revoke.
The revocation list is good for 7 days. Intune republishes it every 3.5 days and again every time you revoke something. Device certificates renew on their own at the renewal threshold, and an issuing CA can be renewed once it is halfway through its life.
When no certificate shows up
The SCEP profile asks for an extended key usage that the CA does not have.
A subject name variable, like email, is empty for that user or device.
The trusted certificate profile and SCEP profile went to different kinds of groups.
The SCEP profile mixes an old NDES URL with the Cloud PKI SCEP URI. Do not combine them.
On Windows, open Event Viewer and go to Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin. Event 39 says the SCEP certificate installed. Then check the certificate itself with certmgr.msc for user certificates or certlm.msc for device certificates. On iPhones and Macs, an expired certificate can stay stuck if renewal fails. Excluding the device from the profile for a sync, then adding it back, gets it a fresh one.
Rolling out Intune Cloud PKI
Decide between a Cloud PKI root and bring your own CA, then plan your extended key usages before you click Create. Build the root, the issuing CA, two trusted certificate profiles, and one SCEP profile, and assign them all the same way. Test on one device, confirm event 39 and a working Wi-Fi connection, then roll Intune Cloud PKI out wider.
What can we learn as a person
A device trusts a Cloud PKI certificate because it chains up to a root the device already trusts. It also checks a revocation list to make sure nobody took it back.
I run my sense of worth the same way. Whether I did a good job is not something I decide on my own. I chain it up to one or two people, and if I cannot reach them to check, I assume the certificate got revoked. One day without a reply and suddenly nothing validates.
Who is the root CA for your sense of worth? And what would it take to put your own name in the trusted root store?
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.
