DEV Community: Cloudek Hosting

Exchange Server on Windows Server 2016: Migrate, Do Not Upgrade the OS

Cloudek Hosting — Mon, 09 Nov 2026 04:55:11 +0000

If Exchange Server is installed on a Windows Server 2016 machine, you have two end-of-support dates stacked on one server, and the one that matters more has already passed. Exchange Server 2016 and 2019 reached end of support on 14 October 2025, and the Windows Server 2016 operating system underneath follows in January 2027. This guide explains why the answer here is to migrate rather than upgrade, what Microsoft documents as your options, and a step list with the cmdlets and the points where you can still turn back. Sources checked 6 November 2026 against Microsoft Learn, Microsoft Lifecycle and the Exchange team blog; they are listed at the end.

Verdict

Verdict: Migrate.
Microsoft says an in-place upgrade of the Windows Server operating system between major versions with Exchange installed is not supported, and Exchange 2016 cannot be upgraded in place to a newer Exchange, so the only supported road is a new server or Exchange Online.

There is no clever shortcut. Upgrading the operating system under Exchange is the tempting move because it keeps the server name, the databases and the certificates. It is also the one Microsoft's supportability matrix rules out, and Exchange 2016 does not run on Windows Server 2019 or later in any case.

Who this is for and what changes on the end-of-support date

This is for anyone with Exchange Server 2016 (or 2019) servers on Windows Server 2016, including the "leftover" server kept only for mail relay, public folders or recipient management after a move to Microsoft 365.

Start with Exchange, because it is the bigger problem. Microsoft's end-of-support roadmap says support for Exchange 2019 and 2016 ended on 14 October 2025, so Microsoft no longer provides technical support, bug fixes, security fixes or time zone updates for them. The installation keeps running, but nothing fixes it. Microsoft ran an Extended Security Update programme for Exchange 2016 and 2019. Its second period ran from May to October 2026 for customers with an Enterprise Agreement, covering Exchange 2016 CU23 and Exchange 2019 CU14 and CU15. In an update dated 13 October 2026 the Exchange team said it had released the final set of updates, that no more updates will be released for Exchange 2016 or 2019, and that future updates will be for Exchange Server Subscription Edition (SE) only. So there is no ESU path left to buy time for Exchange itself.

For the operating system, Microsoft Lifecycle lists Windows Server 2016 under the Fixed Lifecycle Policy. The Lifecycle table shows the extended support end as 1/13/2027 6:59:59 AM, while Microsoft's extended security updates page names 12 January 2027 and says 2016 ESU starts on that date. Microsoft's Azure Arc documentation says Windows Server 2016 ESU provides Critical and Important updates for up to three years, through 2030, can be configured in the Azure portal from August 3, 2026, is billed from January 13, 2027 and requires Software Assurance or an equivalent server subscription; the pages show no price. That covers the operating system only. Whatever you decide about the operating system, it does not repair an Exchange build that no longer gets fixes.

Exchange servers are commonly reachable from the internet, which is why this role belongs near the top of the list. Finish before 12 January 2027, and treat any Exchange 2016 or 2019 server as overdue now.

Decision table

Option	What Microsoft documents	Fit for Exchange on Windows Server 2016
Stay and buy ESU	Windows Server 2016 ESU (Azure Arc: up to three years, through 2030, needs Software Assurance or equivalent) covers the operating system only. Exchange 2016 and 2019 ESU periods have ended and no more updates will be released	Does not protect Exchange. Not a plan
In-place upgrade	The supportability matrix says in-place upgrade of the server OS between major versions with Exchange installed is not supported. Exchange 2019 CU14 or CU15 can upgrade in place to Exchange SE	Not available for Exchange 2016. The 2019 to SE route needs a 2019 server on Windows Server 2019 or later
Side-by-side migration	A legacy upgrade: add Exchange SE servers, move mailboxes and resources, uninstall the old servers. Required when moving from Exchange 2016 to 2019 or SE and when moving to a newer Windows Server	The on-premises answer. Exchange SE runs on Windows Server 2019, 2022 and 2025
Move to Microsoft 365	Cutover, staged or hybrid migration to Exchange Online, then decommission on-premises Exchange where the rules allow	Microsoft's recommended and simplest option; read the decommission caveats below

Exchange Server SE supports Windows Server 2025, 2022 and 2019 in Datacenter and Standard editions, with Server Core recommended, per the supportability matrix. Exchange 2016 supports Windows Server 2016, 2012 R2 and 2012.

Steps, with the rollback point

Inventory the organization. In the Exchange Management Shell run Get-ExchangeServer | Format-Table Name, Edition, AdminDisplayVersion, Get-Mailbox -ResultSize Unlimited | Measure-Object, Get-MailboxDatabase -Status, Get-ReceiveConnector and Get-SendConnector. Run Get-OrganizationConfig | Format-List PublicFoldersEnabled and Get-HybridConfiguration. Write down every client, application and device that sends mail through this server by name or address; those are the things that break.
Decide the destination. Microsoft 365 if no regulatory or technical reason forces mail on-premises. Exchange SE otherwise. Microsoft's decommission guide says organizations under 2,000 mailboxes should strongly consider a cutover or staged migration over hybrid, and hybrid for larger or longer migrations, because hybrid allows moves in both directions.
Know the identity catch. If you keep Microsoft Entra Connect managing accounts from on-premises Active Directory, you must keep at least one Exchange server to change Exchange recipient attributes, because the source of authority is on-premises. Microsoft's roadmap lists upgrading to Exchange SE, or using a management-tools approach, as the supported answers. Plan this before you promise "we will switch Exchange off".
Prepare Active Directory. Domain controllers must run versions supported for the target Exchange. If a Windows Server 2025 domain controller holds the Schema Master, Microsoft requires the November 2025 or later cumulative update on it before any PrepareAD operation. If your domain controllers are also on Windows Server 2016, schedule that work first, because Exchange setup depends on a healthy forest.
Back up and freeze. Take a verified backup of the Exchange databases, the system and the configuration, record Get-ExchangeCertificate, the virtual directory URLs (Get-OwaVirtualDirectory, Get-EcpVirtualDirectory, Get-WebServicesVirtualDirectory) and the Autodiscover settings, and stop any "just one more change" on the old server. This is your rollback.
On-premises route: build and join. Install Windows Server 2019, 2022 or 2025, run Exchange SE setup (the Exchange Server Deployment Assistant generates a tailored checklist), and add the new server to the existing organization. Microsoft warns that SE CU2 setup prohibits coexistence with any Exchange version no longer supported at that release, so plan to remove Exchange 2016 on a schedule rather than leave it indefinitely, and install the newest cumulative update at build time.
On-premises route: move. Create target databases, then move mailboxes with New-MoveRequest -Identity user@contoso.com -TargetDatabase DB-NEW, watch Get-MoveRequest | Get-MoveRequestStatistics, and complete in batches. Move arbitration, audit and discovery mailboxes and public folder mailboxes too. Move the namespace last: import or request certificates, repoint the Autodiscover and virtual directory URLs, and update receive connectors and any relay IP lists.
Microsoft 365 route: connect. For a cutover or staged migration, follow the migration batch process in the Exchange admin center. For hybrid, run the Hybrid Configuration Wizard from an on-premises Exchange server, then move mailboxes as remote moves. Public folders need their own migration if you use them, and the decommission guide lists the exact check.
Cut mail flow. For Microsoft 365, point MX and Autodiscover at Exchange Online, update both internal and external DNS (Microsoft warns about inconsistent client behaviour otherwise), and move relay users to a supported alternative. Rollback point: keep the old server, its databases and its connectors untouched until mail has flowed cleanly through the new path for a full business cycle.
Decommission only when allowed. If all mailboxes are in the cloud and you can disable directory synchronization, Microsoft's steps include removing the Hybrid Configuration Wizard connectors and organization relationship, disabling the OAuth intra-organization connectors, setting Get-ClientAccessService | Set-ClientAccessService -AutoDiscoverServiceInternalUri $Null, and then uninstalling Exchange. If you keep synchronization, keep one (preferably two) Exchange servers for recipient management; they need no database availability group.
Uninstall the old server. Run Exchange setup in uninstall mode (Setup.exe /mode:Uninstall /IAcceptExchangeServerLicenseTerms_DiagnosticDataON) after mailboxes, public folders, arbitration mailboxes and connectors have moved, then rebuild or retire the Windows Server 2016 machine.

Mistakes that cause outages

Upgrading Windows underneath Exchange. Microsoft states it is not supported. A failed upgrade usually means a rebuild during business hours.
Removing the last Exchange server in a synchronized environment. You lose the ability to edit Exchange attributes for cloud mailboxes.
Forgetting relay. Printers, scanners, line-of-business apps and scripts relay through the server by IP address. Public folders and SMTP relay are the two things Microsoft calls out as reasons not to decommission.
Changing MX or Autodiscover in only one DNS. Internal and external records both need to move.
Leaving the certificate for last. The new server needs a certificate with the right names before clients find it.
Skipping the schema and domain controller checks. A Windows Server 2025 Schema Master without the required cumulative update can cause replication issues during PrepareAD.
Running Exchange 2016 alongside a newer SE build indefinitely. Microsoft's coexistence rule for SE CU2 and later blocks it.
Treating hybrid as free. Hybrid adds complexity; Microsoft recommends cutover or staged for smaller organizations.

Checklist

Exchange servers, versions, mailboxes, connectors, public folders and relay users inventoried
Destination chosen: Exchange SE or Microsoft 365
Identity source of authority understood; plan for the last Exchange server written down
Domain controllers and functional levels checked; Schema Master update confirmed if on 2025
Backups verified; certificates and URLs recorded
New server or tenant ready; test mailboxes moved first
Mail flow and DNS cut over; relay users moved
Old Exchange uninstalled, Windows Server 2016 host retired
Finish before 12 January 2027, and sooner for Exchange itself

Sources

Checked 6 November 2026.

General planning information, not a design for your environment. Pilot with test mailboxes first.

Originally published at cloudekhosting.com. Free IT admin tools are at cloudekhosting.com/tools.

How to Find and Reclaim Unused Microsoft 365 Licences

Cloudek Hosting — Mon, 09 Nov 2026 04:49:48 +0000

Short answer: build a report that flags possible waste, then have an administrator verify each account, workload, mailbox, group assignment and contract before changing anything. A disabled account or a long gap in sign-in activity is a reason to investigate, not automatic proof that a licence can be removed.

This report-first method helps teams find unused Microsoft 365 licences without disrupting work. It separates observable signals from decisions and keeps removal under human approval.

Start with evidence, not an automatic removal

A good licence assignment review starts with a dated inventory of users, account state, assigned products and service plans, assignment source, sign-in indicators, mailbox type and business owner. Microsoft Graph's licenseDetails endpoint returns details for licences assigned directly and through licensed-group membership. Its documentation identifies delegated LicenseAssignment.Read.All as the least privileged permission for that operation and says application permissions are not supported. This is a Microsoft API reference; administrators should confirm the current permission model and their approved reporting route before use.

Keep the extract limited to fields needed for the review, store it in an approved location and record when it was generated. A spreadsheet or read-only CSV report is enough to begin. Do not start by removing assignments or by treating a cost estimate as a realized saving.

Four signals worth reviewing

1. Disabled accounts that still have assignments

A disabled account with a paid product assigned is a strong prompt to ask whether the person has left, changed role, or still owns a service, workflow, mailbox or data. Check the account's owner and dependencies, group-based assignment rules, retention needs and any handover period. If the account is an emergency, service or shared workload identity, use the organization's specific policy instead of an employee rule.

2. Long gaps since sign-in

Microsoft 365 sign-in activity is one signal to review. Microsoft Entra's inactive-account guidance explains how sign-in activity can help investigate inactive accounts. It also stresses that an inactivity window depends on context. The documented lastSignInDateTime records an interactive sign-in attempt, which is not the same as proof of successful use. The page notes that displayed activity can take time to update; access to lastSuccessfulSignInDateTime has separate licensing and permission prerequisites.

Use a gap as a review threshold that your organization chooses. Check leave, seasonal patterns, non-interactive workloads and recent successful activity with the service owner. If the evidence is stale or missing, mark the candidate as uncertain rather than inactive.

3. Shared mailboxes

A shared mailbox licence needs its own review category. Microsoft's shared-mailbox guidance says a separate licence is not required in some situations, but lists exceptions tied to mailbox size, archiving, holds and advanced features. Verify the live mailbox configuration and current licensing terms before changing its assignment. A missing interactive sign-in is not a safe removal signal for a shared mailbox.

4. Duplicate or overlapping SKU assignments

Duplicate licence SKUs can look similar while providing different service plans, or the same entitlement can arrive by direct and group assignment. Compare the enabled services with the user's work, confirm the assignment source, and check whether a group rule will restore a removed licence. Label these rows "possible overlap" until an administrator and service owner verify the requirement.

Make the report useful to a reviewer

For each candidate, show the evidence and its date, why it was flagged, what remains unknown, the business or service owner, the next verification step and a status such as review, confirmed needed, approved to change or unresolved. Do not label a row "waste" just because an account is disabled or quiet. Keep the report separate from the action process: no automatic removal, no silent group changes and no unreviewed mailbox changes.

Before anyone acts, check dependent services, retention and legal holds, mailbox features, group membership and subscription commitments. The authorized administrator should make an approved change through the tenant's established process, document the decision and check that the user or service still works afterward. If a reviewer cannot establish the assignment's purpose, leave it in place until the right owner can decide.

Estimate savings carefully

Use the tenant's actual contract price, currency, renewal date and cancellation terms. A public list price may not match a negotiated rate, and a remaining commitment can mean that removing an assignment does not immediately reduce the bill. Keep confirmed changes separate from potential candidates, and state the assumptions behind any estimate.

A practical review checklist

Export a minimal, dated view of assignments and account signals.
Separate disabled users, long sign-in gaps, shared mailboxes and possible SKU overlap.
Confirm the signal with the account or service owner.
Check group assignments, enabled service plans, mailbox features and retention.
Verify actual contract and renewal terms before estimating savings.
Record approval before an authorized administrator changes anything.
Recheck the dependent service and assignment rule afterward.

Tools that help

The licence waste analyzer reviews a selected CSV locally in the browser. The Microsoft 365 licence cost calculator helps organize cost assumptions. Both are review aids: they do not connect to a tenant or remove licences.

Frequently asked questions

Does a disabled account always mean its licence is unused? No. Confirm its owner, services, group rules, retention requirements and any handover period first.

Does no recent sign-in prove a licence is not needed? No. Sign-in activity is a signal with timing and interpretation limits. Check with the owner and consider workload patterns.

Should a shared mailbox have its licence removed? Not without checking the mailbox's current size, archive, hold and feature requirements against Microsoft's current guidance.

Can duplicate products be removed automatically? This guide recommends human review. Similar names or overlapping assignments do not prove that an entitlement is redundant.

Originally published at cloudekhosting.com. Free Microsoft 365 and IT admin tools are at cloudekhosting.com/tools.

DMARC Rollout Plan: From p=none to p=reject Without Losing Mail

Cloudek Hosting — Mon, 09 Nov 2026 04:43:14 +0000

What a DMARC rollout is really doing

DMARC lets a domain owner tell receiving mail systems what to do with messages that claim to be from the domain but fail authentication. The DMARC policy has three levels: p=none asks for no action, p=quarantine asks the receiver to treat failing mail with suspicion, and p=reject asks it to refuse the mail. The risk in moving from the first to the last is simple: if a legitimate sender is not authenticating correctly, it will start losing mail when you tighten the policy. A good DMARC rollout plan is mostly about finding every legitimate sender before that happens.

This plan assumes SPF and DKIM already exist for your main mail system. If you are unsure, begin with the email domain health score to see which records are published, and read how to check email domain records for what each one does.

How DMARC decides pass or fail

A message passes DMARC if SPF or DKIM passes and, crucially, the domain it authenticated is aligned with the domain in the visible From address. It fails only if both fail. Alignment is where most rollouts hit trouble. A marketing platform may pass SPF for its own bounce domain and sign DKIM with its own domain, so both authentication checks pass but neither aligns with your From domain, and DMARC fails. By default alignment is relaxed, meaning a subdomain of the same organizational domain aligns; strict mode requires an exact match.

Stage 0: take stock

Before publishing anything, list who sends mail as your domain. Typical senders are your main mailbox service, a marketing platform, a ticketing or support system, an invoicing or billing system, a website contact form, monitoring and printers or scanners, and a few forgotten servers. Ask each department, and also check the DNS: your SPF record often names the services someone once approved. Remove nothing yet; collect.

Stage 1: publish p=none with reporting

Publish a DMARC record at _dmarc.yourdomain with p=none and an rua=mailto: address for aggregate reports. A minimal example is:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Use a dedicated shared mailbox or group for reports, not a person's inbox, and expect the volume to grow. If the report address is in a different domain from the one being protected, the receiving domain has to publish a small TXT record to authorise report delivery, or receivers may not send reports. Many teams use a DMARC reporting service to turn the XML into something readable; if you do, check what the service stores and who can see it.

Stay at p=none long enough to see a full business cycle. That should include month-end invoicing, any quarterly mailings and seasonal campaigns, since infrequent senders are the ones you miss. Microsoft's guidance is to monitor for enough time before moving up, without giving a fixed number; the right length depends on how many senders you have and how regular they are.

How to read aggregate reports

Receivers usually send aggregate reports as a daily XML attachment, often compressed. Reading raw XML is tedious, so use a viewer or a script, but understand the fields:

source_ip: the server that sent the mail, and count, how many messages.
policy_evaluated: whether SPF and DKIM were aligned, and what disposition the receiver applied.
auth_results: the raw SPF and DKIM results and the domains they used.
header_from and the envelope sender, so you see which domain was used.

The pattern to look for is a known, legitimate source where the authentication result is pass but the aligned result is fail. That is a sender who needs fixing, either by signing DKIM with your domain or by using a bounce address in your domain. A high-volume unknown source that fails everything is probably spoofing, and DMARC will protect recipients once you enforce. Forwarded mail and mailing lists often fail and are normal background noise; do not chase every line.

Not every receiver sends reports, so the data is a sample of your mail rather than all of it. Also note that Microsoft 365 does not send the per-message forensic reports, so do not rely on ruf; start with rua only.

Stage 2: find and fix the senders

Work through the senders from the aggregate reports, one at a time. For each, decide whether it should send as your domain. If yes, make it align. The two usual fixes are to configure DKIM signing in the service using your domain, which tends to be the more robust route since it also survives most forwarding, and to configure a custom return-path domain so SPF aligns. If a service cannot do either, send its mail from a subdomain and give that subdomain its own record. If a sender should not exist, remove it from SPF and ask why it was sending.

Use a subdomain for third-party bulk senders so that their reputation does not reflect on your main domain. For domains that never send mail, you can publish a restrictive record straight away, as parked domains should not be sending at all.

Check progress by re-reading the reports: the legitimate sources should move from failing to aligned passes. Before you publish a change, check your record's syntax and tags with the DMARC record check in the email health tool; it explains a pasted record and does not look it up in DNS.

Stage 3: move to p=quarantine

When the reports show your legitimate senders aligned, change to p=quarantine. The pct tag in the record lets you apply the policy to a share of failing messages first, and Microsoft's own example steps through increments such as 10, 25, 50, 75 and 100. Be aware that pct comes from the original specification, RFC 7489. A newer revision of the standard is reported to retire it in favour of a simple test-mode tag, so check the current specification and how your receivers treat partial enforcement before relying on it. Whichever way you stage it, keep watching reports and the help desk for complaints about missing mail.

Wait for a full cycle again before the last step. Tell the business a change is coming and who to contact.

Stage 4: move to p=reject

When quarantine has been quiet, change to p=reject. Rejected mail is bounced or discarded by the receiver, so there is no junk folder to rescue it from. That is why the previous stages exist. Keep reading reports, because new senders appear when a team signs up for a new service without asking you.

If you have subdomains, decide whether they inherit the parent policy, as they do when no record exists for them, or need their own. The sp tag sets a policy for subdomains in the parent's record. Roll out low-volume, low-complexity domains first and leave the main domain until last, which is Microsoft's suggested order.

After the rollout

DMARC is not a one-time project. Add "does this send mail as our domain?" to the checklist for any new application, review aggregate reports monthly, and keep an eye on the SPF lookup limit as senders are added. A policy of p=reject does not stop all phishing. It makes direct spoofing of your exact domain much harder; look-alike domains remain.

Keep a record of each change and the date, so that if mail disappears you can see what changed. Verify your own record syntax, alignment settings and report addresses against Microsoft Learn and the DMARC specification before you publish.

Originally published at cloudekhosting.com. Free email checks, including the email health score, are at cloudekhosting.com/tools.