Ready to read this content aloud.
Executive summary
This case study documents an infrastructure transformation delivered over approximately four months.
The starting point was not a hybrid environment. The organization relied on on-premises Active Directory as its primary directory, a separate email platform, and an identity structure that had grown without a single consistent model for account naming, functional addresses, and directory organization.
The modernization therefore began before Intune. The first steps were to define the identity model, clean up Active Directory, map existing identities, and consolidate the correct on-premises and cloud accounts. In parallel, Exchange Online was prepared to become the primary corporate email platform without turning the mail-flow cutover into a disruptive user event.
Only after that foundation was established did the architecture expand into Windows provisioning, Microsoft Entra Hybrid Join, Microsoft Intune, Microsoft Defender, compliance, Conditional Access, and user-data modernization.
Sensitive implementation details remain private. Internal names, identifiers, credentials, detailed topology, groups, policy values, and other operational information are intentionally omitted or generalized.
My role
I led the technical design and execution of this modernization end to end over approximately four months. The work included defining the identity model, cleaning up and restructuring Active Directory, mapping and consolidating existing accounts, preparing and migrating mail flow to Exchange Online, and then moving into Windows provisioning automation and modern endpoint management with Intune and Defender.
The challenge was not simply configuring products. It was changing core identity, messaging, and endpoint components in a sequence that preserved operational continuity and allowed each stage to be validated before the scope expanded.
Before → After
| Before | After approximately four months |
|---|---|
| On-premises Active Directory without a single corporate structure | Cleaned-up Active Directory under a predictable corporate scope |
| Personal, functional, and cloud identities following different conventions | One identity model for UPNs, aliases, and functional mailboxes |
| Email on a platform separate from Microsoft 365 | Exchange Online as the primary corporate email platform |
| On-premises and cloud accounts managed independently | Hybrid identity consolidated through Microsoft Entra ID |
| Windows preparation dependent on technical intervention | Automated and repeatable Windows provisioning |
| Endpoint controls handled mostly as local concerns | Centralized Intune, Defender, LAPS, BitLocker, and update policies |
| Access based mainly on user identity | Compliance and Conditional Access able to include device state |
Starting point
The environment had grown around on-premises Active Directory. It was operational, but the directory structure and identity conventions were not consistent enough to be treated as a clean authoritative source for broad cloud integration.
Account names, UPNs, organizational structure, functional addresses, and administrative identities required normalization.
Email followed a separate path. The corporate domain was handled by a legacy platform while Microsoft 365 and Teams had already introduced cloud identities and services.
Before synchronizing more data, the project needed to establish a basic answer: which identity represents each person across every system?
Identity before synchronization
The first design decision was to treat identity as a governance model rather than a synchronization setting.
Standards were defined for usernames and UPNs, primary email addresses, aliases, functional addresses, shared mailboxes, separation of privileged and daily-use accounts, and documented exceptions.
A personal identity should represent a person. Addresses that represent a function or department should remain aliases or shared mailboxes when that model is more appropriate.
This separation makes onboarding, offboarding, ownership, and auditability more predictable.
Active Directory cleanup and restructuring
Cloud consolidation did not begin with the synchronization tool. It began by correcting the source directory.
Active Directory was reviewed in controlled waves. Account names, UPNs, attributes, groups, and OU organization were corrected before the cloud scope was expanded.
The resulting structure places relevant corporate identities and objects under a predictable directory hierarchy. The public case study intentionally omits the exact operational path; the architectural point is that the directory moved from fragmented placement to a clear corporate root for policy, synchronization, and automation.
This also simplified later decisions about synchronization scope, object placement, and policy targeting.
Mapping existing identities
Data and history already existed across several systems, so identity consolidation required mapping before matching.
For each employee, the project related the Active Directory account, current and target UPN, existing Microsoft 365 identity, licensing, Teams usage, legacy mailbox, aliases and functional addresses, privileged accounts, and migration status and risk.
This inventory reduced the risk of duplicate cloud objects or incorrect associations between a local account and an existing cloud identity.
Changes were executed in small batches, with before-and-after evidence and rollback considerations before the next wave.
From on-premises identity to hybrid identity
After the directory was cleaned up, on-premises identities could be associated in a controlled way with the cloud accounts that needed to be preserved.
This turned Active Directory from an isolated directory into a governed source integrated with Microsoft identity services, without treating synchronization as an indiscriminate upload of objects.
The intended relationship became predictable:
Person
↓
Active Directory
↓
Microsoft Entra ID
↓
Microsoft 365
That same foundation later supported device identity, enrollment, and access policy.
Email migration to Exchange Online
Identity modernization ran alongside preparation of the new email platform.
Before changing inbound mail flow, Exchange Online was prepared with the required recipients, licensing, mailboxes, aliases, shared mailboxes, and historical data that needed to be preserved.
The migration also separated personal identities from functional addresses instead of carrying the old ambiguity into the new platform.
The mail-flow cutover happened only after that preparation. The legacy platform stopped acting as the primary entry point for the domain, and Exchange Online assumed that role.
In practice, the transition caused minimal operational disruption for users. The objective was not merely to move mailboxes; it was to replace the messaging platform without making the infrastructure migration a visible interruption to daily work.
The onboarding model also became simpler after the cutover. A new employee no longer required multiple independent identities across unrelated systems; the flow could follow a more consistent chain of directory, synchronization, licensing, and mailbox provisioning.
Endpoint modernization starts after identity
Once identity was consolidated and Microsoft 365 became a central platform, the next problem was the lifecycle of corporate computers.
A domain-joined computer is not automatically a managed endpoint, and a device that appears in Intune is not automatically secure or eligible for every corporate resource.
The architecture therefore treats Windows provisioning, Domain Join, Microsoft Entra Hybrid Join, Intune enrollment, policy and application delivery, endpoint protection and telemetry, compliance evaluation, and access decisions as related but independent states.
Boundary with Windows Unattended Provisioning
Windows installation, Domain Join, and Hybrid Join are documented separately in Windows Unattended Provisioning.
That project covers the bootstrap phase. This case study continues the journey after the device has a known operational and identity state and needs to enter continuous management.
Windows Setup
↓
Domain Join
↓
Microsoft Entra Hybrid Join
↓
Microsoft Intune Enrollment
↓
Policies and Applications
↓
Endpoint Security
↓
Compliance
↓
Conditional Access
Modern endpoint management
Enrollment is treated as the transition from device identity into continuous management. After the first corporate sign-in, the endpoint begins receiving Intune-assigned configuration and applications. Because several operations are asynchronous, portal visibility alone is not considered proof that the complete operational state has been reached.
Software delivery was also centralized using the deployment model appropriate to each application: Microsoft applications, managed catalogs, web applications, and Win32 packages when custom configuration and detection were required. One example is documented in RustDeskIntuneDeployment, which treats installation, configuration, and detection as distinct deployment states.
The Windows baseline then incorporated controls that previously depended on local handling or separate processes. Windows LAPS reduces reliance on shared local administrative credentials; BitLocker adds data-at-rest protection and a measurable compliance signal; Update Rings make the Windows update lifecycle more predictable and separate changes with different operational risk profiles, such as operating-system updates and drivers.
Enrollment, policy delivery, software deployment, local administration, encryption, and updates therefore become part of one centralized and observable operating model.
Security protection and posture
Microsoft Defender for Business added centralized endpoint protection, telemetry, and response capabilities. The pilot evaluated antivirus, real-time protection, EDR, local firewall, tamper protection, web protection, and remote-response capabilities.
Controls with higher compatibility risk were introduced gradually. Network Protection, Controlled Folder Access, and Attack Surface Reduction were evaluated in audit mode before broad enforcement decisions. This provides evidence of legitimate application behavior, incompatibilities, and false positives before hardening becomes blocking policy.
Vulnerability management followed the same principle: recommendations are inputs for prioritization and remediation, not instructions to execute every portal suggestion automatically. Each action still requires technical context, patch validation, and a deployment method appropriate to the operational risk.
Trust and access control
Compliance introduces a deliberate distinction between Managed, when the platform can administer the device, and Compliant, when the device also satisfies the organization’s defined minimum requirements.
This turns endpoint characteristics into reusable security signals.
Conditional Access was initially validated without direct enforcement so that the behavior of managed and unmanaged devices could be observed before users were blocked. The architecture combines user identity and device state so that a valid credential is no longer the only relevant access signal.
Architectural extensions
Endpoint modernization also included reducing reliance on user-profile storage tied exclusively to the internal network. OneDrive Known Folder Move was evaluated as part of that transition while keeping synchronization, retention, and backup as separate concerns.
The same conceptual model was extended to corporate Android devices through Android Enterprise. Enrollment, applications, restrictions, endpoint protection, and compliance form a similar state chain while respecting mobile-specific vendor and application constraints.
The Android track contains enough implementation detail for a dedicated future case study, so it remains an architectural extension here.
Pilot and rollout strategy
The initiative was designed to avoid broad changes without evidence. The pattern was to begin with controlled scope, validate technical behavior and operational impact, use Audit or Report-only where appropriate, document exceptions and limitations, expand in controlled waves, and preserve rollback criteria before increasing scope.
The same principle had already been applied to identity cleanup and email migration: small, observable changes before expanding the blast radius.
Results
In approximately four months, the initiative changed more than the toolset used by IT.
The environment moved from separate on-premises identity and messaging systems to a Microsoft 365-integrated foundation with a reorganized Active Directory and predictable corporate scope, clear separation between personal and functional identities, controlled consolidation of on-premises and cloud accounts, Exchange Online as the primary corporate email platform, hybrid identity for users and devices, automated Windows provisioning, centralized endpoint management through Intune, security telemetry and protection through Defender, measurable compliance, and access controls that can consider device state.
The endpoint is no longer treated as merely a computer joined to a domain. It becomes an entity with observable identity, management, configuration, protection, telemetry, compliance, and access eligibility.
Limitations and next steps
Some controls require longer observation before enforcement. Others depend on application compatibility, mobile-vendor behavior, or policy decisions that need further validation.
The next steps are to move selected Audit or Report-only controls into controlled enforcement, formalize rollout exit criteria, and document the Android management track separately.
Identity governance also remains continuous: the value of the directory cleanup depends on preserving the same standards for onboarding, offboarding, aliases, shared mailboxes, and privileged accounts as the environment continues to evolve.
Related public projects
- Windows Unattended Provisioning — Windows installation and hybrid device-identity bootstrap.
- RustDeskIntuneDeployment — a concrete example of a Win32 application packaged and validated for Intune.
What this case study demonstrates
The central achievement was not adopting a collection of Microsoft products.
Sequence mattered more than tooling: organize identity first, consolidate directories and email, automate provisioning next, and only then use endpoint state as part of the security model.
That approach made it possible to move a traditionally on-premises environment toward a hybrid, managed architecture in a short period without a single disruptive cutover and without carrying every legacy inconsistency directly into the cloud.