Hybrid Identity with Microsoft Entra Connect (formerly Azure AD Connect)

Connecting On Premises to the Cloud:

This is the section where the ADDS project and this project actually meet. Everything I built on premises including the Domain Controllers, the OUs, the user accounts which existed in isolation up to this point. Microsoft 365 was set up but had no idea my on premises Active Directory existed. Microsoft Entra Connect is what bridges that gap.

Once the sync ran, my on premises users existed in two places at once. They are still in Active Directory on premises, managed the same way they always were. But now they also exist in Entra ID in the cloud. One identity, two locations. That is hybrid identity and that is what most organisations actually run today.

Why Customise Over Express:

The wizard gave me two options straight away: Express or Customise. Express would have synced everything in my directory automatically using Microsoft defaults. That sounds convenient but the problem is it would have pushed Domain Controllers, Builtin accounts and system containers into Entra ID. These are objects that have no business being in the cloud.

I chose Customise because I wanted to control exactly what gets synced. That meant selecting specific OUs, choosing the authentication method deliberately and understanding every decision I was making rather than clicking through a wizard and hoping for the best.

How Users Authenticate to the Cloud:

One of the most important decisions in the whole setup is how users prove who they are when signing into Microsoft 365. There were three main options — Password Hash Sync, Pass-through Authentication and Federation with AD FS.

I chose Password Hash Sync. It syncs a hash of the on premises password up to Entra ID so users sign into Microsoft 365 with the same credentials they already use on their domain joined machines. The reason I picked this over the others is resilience. Pass-through Authentication and AD FS both need the on premises environment to be available every time a user signs into the cloud. If my DC goes down, cloud sign in breaks too. With Password Hash Sync the hash is stored in Entra ID, and cloud authentication works independently of whatever is happening on premises.

I also enabled Single Sign-On. This means a user already logged into DELL-LAPTOP does not get asked for their password again when they open Teams or Outlook. The machine's existing Windows session is used to authenticate them automatically. That is the experience enterprise users expect and it is how it should work.

Connecting to the On Premises Directory:

The next step was pointing Entra Connect at my on premises emeka.cloud forest. When I clicked Add Directory it asked for domain administrator credentials. What happens behind the scenes is Entra Connect uses those credentials once to create a dedicated synchronisation service account in Active Directory, a service account with only the permissions it needs to read the directory and run the sync. My administrator credentials are not stored after that. Future syncs run under that dedicated service account.

That is least privilege applied correctly. A specific account for a specific job with nothing extra.

Choosing What Gets Synced:

The OU filtering screen was the most important part of the whole setup. By default every OU and container in the domain is selected, which means if I had just clicked Next without thinking, Domain Controllers, Builtin accounts, system objects and internal containers would all end up in Entra ID.

I went through the list deliberately and unticked everything that should never go to the cloud.

What I kept:

• Departments: my three on premises users live here across the HR, IT and Operations OUs

• Workstations: DELL-LAPTOP and HP-PAVILION

• Servers: ADCON-MID

• Disabled Accounts: worth keeping for visibility and audit purposes

This is exactly why I chose Customise over Express. Express would have synced everything. Customise let me be deliberate about what ends up in the cloud.

The key thing Entra Connect configures during this process is the Service Connection Point. The SCP is an object written directly into my on premises Active Directory that tells domain joined machines where to find the Entra ID tenant. Without it machines have no way of automatically discovering Entra ID when they try to register. Once the SCP was written to emeka.cloud using Enterprise Admin credentials the domain joined machines could find the tenant and complete their registration.

I selected Windows 10 or later domain-joined devices only. The other option covers Windows 7 and 8.1 which require AD FS for hybrid join. This environment has no downlevel devices and no AD FS so that option was not relevant.

One thing I noticed after the configuration completed was a new computer account called AZUREADSSOACC appearing in the Computers container in Active Directory. This is created automatically by Entra Connect when Single Sign-On is enabled. It is not a real machine — it is a Kerberos decryption account that makes seamless SSO work. When a domain joined machine tries to authenticate to Microsoft 365 silently without prompting the user for credentials, it uses a Kerberos ticket. The AZUREADSSOACC account holds the Kerberos decryption key that Entra ID uses to validate that ticket. Without this account seamless SSO cannot function. It sits in the Computers container rather than any of my custom OUs because Entra Connect creates it there automatically and it should be left exactly where it is. 

After the configuration completed I went to DELL-LAPTOP, ran gpupdate /force, restarted and then ran dsregcmd /join to trigger the registration. I ran the status check logged in as tina.timothy rather than the admin account to confirm hybrid join works for synced domain users not just administrators. 

Checking the Entra ID Devices page confirmed everything had registered correctly.

With users synced and devices registered in Entra ID the hybrid identity picture is now complete for this environment. Users that started in on premises Active Directory now exist in Entra ID. Machines that were only known to on premises AD are now visible in the cloud. The foundation is in place for everything that follows.

Microsoft Entra ID

Managing Cloud Identities 

Once the sync ran and the hybrid join completed, Entra ID became the central identity platform for the entire environment. On premises users exist here. The cloud only admin account exists here. Devices are registered here. Every application that needs to verify who someone is goes through Entra ID. It is the single point of identity for both on premises and cloud resources. 

Cloud Only vs Synced Accounts

This is the most important distinction I had to understand in a hybrid environment.

emeka@emeka.cloud is a cloud only account. I created it directly in Microsoft 365 before any sync was configured. It exists only in Entra ID and can only be used to sign into cloud services. I deliberately keep it this way as a break-glass global admin account. If the sync ever breaks, if Entra Connect goes down, if something goes wrong with the on premises environment, this account still works and I can still get into the tenant. That is why Microsoft recommends keeping at least one cloud only global admin account in every hybrid environment, (Microsoft).

Other users are synced accounts. They started life in my on premises Active Directory and Entra Connect brought them into Entra ID. The critical thing about synced accounts is where changes must be made. If I need to update a synced user's name, department or job title I have to do it in ADUC on DC1. Not in Entra ID. The next sync cycle picks up the change and reflects it in the cloud automatically. Trying to edit those attributes directly in Entra ID does not work because most of them are greyed out. 

Licence Assignment 

Synced users appear in Entra ID and Microsoft 365 automatically after the sync but they arrive unlicensed. They exist as identities but cannot access any Microsoft 365 services until a licence is assigned. With two Microsoft 365 Business Premium licences available, emeka@emeka.cloud holds one as the global admin account. The second licence goes to tina.timothy who is the primary standard user for demonstrating Microsoft 365 services throughout this project.

emeka.iwu, tina.tymokhin and james.bond sync to Entra ID and are visible for identity management but remain unlicensed. They cannot access Microsoft 365 apps but their identities are centrally managed alongside everyone else.

Groups Synced from On Premises AD 

The security groups built during the ADDS project did not stay on premises. Entra Connect synced them to Entra ID alongside the user accounts. HR-Staff, IT-Staff and the other department security groups all appear in Entra ID Groups. This matters because those same groups will be used to control access in SharePoint and Teams later in this project. The group that gives someone access to the HR shared drive on premises is the same group that gives them access to the HR SharePoint site in the cloud. One group, consistent access control across both environments. 

MFA, Conditional Access and Self Service Password Reset 

Securing Cloud Identity

Having user identities in the cloud is only valuable if those identities are properly protected. A username and password alone is not enough. I already knew this before this project as every time I sign into my global admin account Microsoft asks me to confirm a code on my Authenticator app. Setting it up deliberately for other users in this project made me understand exactly how it works and why it matters. 

What MFA Actually Is

I implemented MFA, meaning that signing in will require more than just a password. After entering the correct password a user is asked to prove their identity a second way like; approving a notification on the Microsoft Authenticator app, entering a code from the app or using another registered method. Even if someone steals a password they still cannot get in without that second factor.

The way I configured MFA here is through Conditional Access rather than the older per-user MFA settings. Conditional Access is the modern recommended approach. It gives granular control over when MFA is required, for which users, on which apps and under what conditions. Per-user MFA is a blunt instrument — it is either on or off for each person. Conditional Access is a policy engine that evaluates multiple signals before making an access decision.

Conditional Access — The Policy Engine 

Conditional Access evaluates who is signing in, what they are signing into, where they are signing in from and what device they are using. Based on those signals it either allows access, blocks access or requires additional verification like MFA. It is a set of rules that can be as broad or as targeted as needed 

Policy 1: Require MFA for All Users

The first policy is the most fundamental. Every sign in to any cloud app by any user in the tenant requires MFA. No exceptions for standard users. The policy targets all users, all cloud apps and grants access only when MFA has been satisfied. 

Policy 2: Block Sign In Outside the UK 

The second policy is a location based control. Sign in attempts from outside the United Kingdom are blocked entirely. To make this work I first created a Named Location in Conditional Access called United Kingdom. The policy then includes any location and excludes the United Kingdom, meaning anything that is not the UK gets blocked.

I deliberately excluded the Global Administrator role from this policy. This is important. If you block all users including yourself from signing in outside the UK and you happen to be abroad, you lock yourself out of the tenant with no way back in. Excluding Global Administrator from blocking policies was a safety measure.

Testing MFA as Tina Timothy

To test, I signedin in as tina.timothy@emeka.cloud for the first time after the policy was enabled. Signing into office.com as Tina triggered the MFA registration prompt immediately. She was asked to set up Microsoft Authenticator before being allowed to continue. Once set up the Authenticator app was registered and Tina was signed in with full access to her licensed Microsoft 365 apps.

I also tested with emeka.iwu@emeka.cloud. MFA kicked in for that account too even though emeka.iwu has no Microsoft 365 licence. The account authenticated successfully through MFA but landed on a limited view with no access to Microsoft 365 apps. That is exactly what I expected and it demonstrates two things at once; Conditional Access applies to all users regardless of licence status, and licences control what apps you can access after authentication.

Self Service Password Reset

SSPR lets users reset their own passwords without calling the helpdesk. In ITIL terms this reduces the volume of password reset incidents that would otherwise hit the service desk — one of the most common ticket types in any organisation. I enabled SSPR for all users in the tenant through the Password Reset properties page in Entra ID.

With Password Writeback configured during the Entra Connect setup, any password reset through SSPR automatically writes back to the on premises Active Directory. The user ends up with one consistent password across both on premises and cloud without IT needing to touch anything. 

Exchange Online 

Cloud Email Administration 

One of the first decisions I made when setting up this project was whether to keep Zoho handling my email or move everything to Microsoft Exchange Online. I decided to move fully to Exchange Online. It made more sense to have everything under one platform; identity, email, Teams and SharePoint all connected rather than split across two providers.

Shared Mailbox: helpdesk@emeka.cloud 

A shared mailbox is one that multiple people can access and send from without needing a dedicated licence. The helpdesk@emeka.cloud shared mailbox was created so that helpdesk emails can be received and responded to centrally rather than going to one person's individual inbox. 

I delegated access to emeka@emeka.cloud so the admin account can read and send on behalf of the helpdesk address. In a real organisation this would be delegated to the whole IT support team so any member can handle incoming helpdesk emails without them needing to share login credentials. 

Distribution Group: All Staff 

A distribution group is an email address that delivers to multiple recipients at once. I created allstaff@emeka.cloud as a distribution group with both emeka@emeka.cloud and tina.timothy@emeka.cloud as members. Sending an email to allstaff@emeka.cloud delivers it to both accounts simultaneously.

The distinction between a distribution group and a security group is that a Distribution groups are email only, they cannot be used for permissions, SharePoint access or Conditional Access targeting. Security groups handle access control.

Internal Email Flow 

Testing the internal email flow was straightforward. Signed into Outlook as emeka@emeka.cloud, composed an email to tina.timothy@emeka.cloud and sent it. Opened Outlook as tina.timothy in a separate browser window and the email had already arrived. As it was a communication between users in the same tenant, no MX records was involved, no external routing, Microsoft delivered it internally within the tenant instantly. 

This matters because it confirms Exchange Online is working correctly for the most common scenario in any organisation, like colleagues emailing each other. Everything else like shared mailboxes, distribution groups and email rules builds on top of this basic internal flow working correctly. 

Intune and Endpoint Management

Managing Devices from the Cloud

Having users synced, identities secured and email running through Exchange Online is only part of the picture. The devices those users work on need to be managed too. Intune is what does that. It is the cloud based management layer that enforces security baselines, pushes configuration to devices and gives IT the ability to remotely manage, lock or wipe a device from a browser without ever touching it physically.

Enabling Automatic Enrolment

The first thing I configured was automatic MDM enrolment. This tells Intune to accept enrolment from licensed users in the tenant.

intune.microsoft.com → Devices → Windows → Windows enrolment → Automatic enrolment → MDM user scope set to All.

Enrolling Windows via Group Policy 

For DELL-XPS-LAPTOP I used the Group Policy auto enrolment path. I had already created the Intune-Auto-Enrolment GPO in the Workstations OU but it was not working. The MDM policy was not showing in Group Policy Editor because the Windows ADMX administrative templates on DC1 were outdated and did not include the MDM policy definition.

The fix came from this Microsoft Learn article: Enrol a Windows device automatically using Group Policy. The solution was downloading the latest Windows ADMX templates, installing the package on DC1 and copying the PolicyDefinitions folder to SYSVOL. Once the templates were updated the MDM policy appeared in Group Policy Editor and the existing GPO started applying correctly.

There was one more thing blocking enrolment. DELL-XPS-LAPTOP had the domain Administrator account logged in and enrolment kept failing silently. Intune enrolment requires a licensed Entra ID user to be signed in. The domain Administrator has no Microsoft 365 licence so Intune had nothing to associate the enrolment with. Logging in as tina.timothy@emeka.cloud resolved it..

Enrolling iOS

Enrolling an iPhone into Intune wasn't really straightforward. Apple requires a trust relationship between Microsoft and Apple before any iOS device can be managed through a third party MDM. That trust is established through an Apple MDM Push Certificate. 

The process involves downloading a certificate signing request from Intune, taking that CSR to the Apple Push Certificates Portal, generating the push certificate there and uploading the resulting PEM file back to Intune. Without this certificate Intune cannot communicate with any Apple device at all. 

I also created an iOS Device Enrolment BYOD profile using Device enrolment with Company Portal as the enrolment type, assigned to all users. BYOD means individuals use their personal device to access corporate resources (data, apps) that is being managed by the company without taking full control of the personal device. 

With those two things in place I downloaded Company Portal from the App Store, signed in with emeka@emeka.cloud and completed enrolment through the app. 

Enrolling macOS

The MacBook enrolled through the same Company Portal path. Downloaded Company Portal from the Mac App Store, signed in with emeka@emeka.cloud and followed the enrolment prompts. The MacBook appeared in Intune within minutes showing as managed and compliant. 

Compliance Policies 

A compliance policy defines the security baseline a device must meet to be considered trusted. If a device fails compliance it can be blocked from accessing company resources through Conditional Access. I created three separate policies covering all three enrolled platforms.

Windows Compliance Policy 

Thirteen settings covering the full Windows security baseline. BitLocker required, Secure Boot required, Code Integrity required, Microsoft Defender Antimalware required, real-time protection required, firewall required, antivirus and antispyware required, minimum OS version enforced and password requirements set. DELL-XPS-LAPTOP passed all thirteen on first evaluation. 

The policy also includes a Machine Risk Score setting tied to Microsoft Defender for Endpoint. That setting generated a notification about a missing connector because Defender is not yet fully configured. The setting cannot evaluate until the connector exists. This gets addressed in Section 12 when Defender for Business is set up. All other settings evaluate correctly in the meantime. 

iOS Compliance Policy

Jailbreak detection, minimum OS version, passcode requirements including alphanumeric type and screen lock timeout. The initial evaluation returned a remediation failed error on the passcode requirement. The cause was that Face ID was the primary unlock method and no passcode was set alongside it. Setting a passcode resolved it immediately. A personal reminder that BYOD devices often have configuration conflicts between what the user has set up and what the compliance policy expects. 

macOS Compliance Policy 

System integrity protection required, minimum OS version set to 13.0, password and encryption requirements enforced, firewall enabled with incoming connections blocked and stealth mode enabled, Gatekeeper set to Mac App Store and identified developers only. The MacBook passed all settings on first evaluation. 

Configuration Profiles

Compliance policies check whether a device meets requirements. Configuration profiles actively push settings to devices. These are the cloud equivalent of Group Policy Objects and they work on any managed device regardless of whether it is domain joined. 

Edge Browser Configuration 

The first profile pushed Microsoft Edge settings to DELL-XPS-LAPTOP. Homepage set to my ServiceNow developer instance, new tab page configured and startup behaviour defined. All four settings applied successfully without anyone touching the device.

I initially tried to push a corporate lock screen image and a desktop wallpaper. Both failed because the Personalization CSP that handles these settings only works on Windows Enterprise and Education editions. DELL-XPS-LAPTOP runs Windows 11 on a non-Enterprise edition. 

LAPS Configuration 

Without LAPS every Windows device in an organisation typically shares the same local administrator password. If one device is compromised that password works on every other device. LAPS fixes this by giving every device a unique password that rotates automatically and is stored securely in Entra ID where only IT can retrieve it.

I created a LAPS Configuration profile under Endpoint Security with the backup directory set to Azure Active Directory, password age set to 30 days, password length 14 characters with full complexity. The policy applied successfully to DELL-XPS-LAPTOP. 

Windows Update Ring 

Without update management devices update whenever Microsoft decides which can mean unexpected restarts during working hours and untested updates landing on production machines. The update ring I configured defers quality updates by 7 days and feature updates by 30 days, schedules automatic installation outside active hours between 8am and 6pm and gives users the option to pause updates temporarily. All 20 settings applied successfully.

BitLocker Recovery Key 

DELL-XPS-LAPTOP already had BitLocker enabled. I ran the BackupToAAD-BitLockerKeyProtector PowerShell command to escrow the existing recovery key to Entra ID. Within minutes the key appeared in the Intune console. If the device ever triggers a BitLocker recovery prompt the IT admin can retrieve the 48 digit key from Intune without physical access and without the user needing to do anything. 

Device Actions 

Every enrolled device in Intune has remote actions available directly from the console. No physical access needed.

Actions available on DELL-XPS-LAPTOP: Sync forces an immediate check-in. Collect diagnostics gathers device logs without user involvement. Secure allows remote lock and BitLocker key rotation. Locate device shows the last known location. Remote actions include restart, fresh start and Autopilot reset. Remove data covers retire and wipe.

Teams and SharePoint 

Collaboration and File Management in the Cloud   

Having identities managed, devices enrolled and email running through Exchange Online meant the next thing to configure was how people actually work together. Teams handles communication and meetings. SharePoint handles file storage and document management. Every Team automatically gets a SharePoint site created for it and files shared in a Teams channel are stored in that SharePoint document library. 

Creating the Department Teams 

I created four Teams reflecting the department structure from the ADDS project. IT Department, HR Department and Operations are private teams so only members can see them and request to join. All Staff is public so anyone in the organisation can join and see announcements.

The structure mirrors the OU design from the ADDS project deliberately. The same thinking that shaped the on premises directory now shapes the cloud collaboration environment.

Teams Policies 

Creating teams is straightforward. The more interesting administrative work happens in the Teams admin centre where policies control what users can do across meetings and messaging. 

Meeting Policy  

I created a custom meeting policy called emeka.cloud Standard Meeting Policy. Two decisions stood out when configuring it.

Lobby bypass is set to People in my organisation only. Anyone outside the organisation joining a meeting has to wait in the lobby until an organiser admits them. This prevents uninvited guests from joining meetings directly.

Meeting recording is enabled with automatic expiration after 60 days. Recordings are stored in OneDrive and SharePoint and take up storage. Setting an expiration means old recordings are cleaned up automatically rather than accumulating indefinitely. Transcription is enabled alongside recording, useful for accessibility and for catching up on missed meetings.

Messaging Policy 

I created emeka.cloud Messaging Policy with editing and deleting of sent messages enabled, read receipts set to user controlled, priority notifications allowed for urgent messages and voice messages permitted in both chats and channels.

Read receipts as a user controlled setting rather than forced on or off is a deliberate choice. Forcing read receipts on creates pressure on users who may need time to respond. Letting individuals decide respects how different people work.

SharePoint Sites 

When I created the four Teams, SharePoint automatically created a corresponding site for each one. Going into the SharePoint admin centre showed all the sites that had been generated including IT Department, HR Department, Operations, All Staff, a Communication Site and a few others Microsoft creates by default. 

Files uploaded in a Teams channel go into the SharePoint document library for that team. Users can access those files through Teams or directly through SharePoint. The storage is the same either way. 

SharePoint Permissions Using ADDS Security Groups 

The security groups built in Active Directory during the ADDS project synced to Entra ID through Microsoft Entra Connect. Those same groups are now available to assign as SharePoint site members.

For each department site I added the corresponding on premises security group as a Site member with Edit access. HR-Staff to the HR Department site, IT-Staff to the IT Department site and Operations-Staff to the Operations site.

Each site already had a default member object, the Microsoft 365 Group created automatically when the Team was built. That default group handles Teams membership. The on premises security group sits alongside it and handles access for users whose access is managed through Active Directory. Both grant access to the site.

The group controlling access to the HR shared drive on premises is the same group controlling access to the HR SharePoint site in the cloud. One group, consistent access control across both environments without creating duplicate groups or managing permissions separately in two places.

External Sharing Settings 

SharePoint and OneDrive were set to Anyone by default, meaning users could share files using links that require no sign-in. Anyone with the link could access the file without identifying themselves. That is not appropriate for a corporate environment.

I changed both SharePoint and OneDrive external sharing to New and existing guests. External sharing is still possible but anyone receiving a shared file must sign in or verify their identity with a code before accessing it. Anonymous links are blocked. Guest access expires after 30 days and verification codes require reauthentication after 7 days.

External collaboration remains possible when needed but all access is authenticated, tracked and time limited

OneDrive Management 

OneDrive is the personal file storage for each licensed user. Two settings worth configuring at the admin level are retention and storage limits.

The default retention period for a deleted user's OneDrive was 30 days. That is not long enough for an organisation to identify and recover files from a departed employee. I changed it to 180 days, giving six months to recover anything important before it is permanently deleted.

The storage limit is 1024 GB per user, the full allocation included with Microsoft 365 Business Premium. Each licensed user gets 1 TB of cloud storage. Storage limits can be reduced for specific users if needed but the default is appropriate for most business users.

Conditional Access, Security Groups and Compliance Policies

The Conditional Access policies from Section 5 apply when users sign into Teams and SharePoint. MFA is required before access is granted. The compliance policies from Section 8 can be configured to block access from non-compliant devices. The security groups from the ADDS project control who can edit content on each SharePoint site. 

Windows Admin Centre and Azure Arc 

Managing Servers Without Logging Into Them 

Managing servers the traditional way means opening a remote desktop session, launching multiple MMC consoles and switching between them constantly. DNS Manager on one window, Active Directory Users and Computers on another, Event Viewer on a third. Windows Admin Centre replaces all of that with a single browser based interface that can manage multiple servers simultaneously without a single remote desktop session.

Azure Arc takes the story further. Once a server is onboarded to Azure Arc it appears in the Azure portal as a managed resource even though it is sitting on premises. Azure Policy, Microsoft Defender for Cloud and Azure Monitor can all reach it from the cloud without the server moving anywhere.

Together they represent how modern organisations are approaching server management, which is a browser based tooling for on premises administration and cloud visibility for governance and security posture.

Installing Windows Admin Centre 

I installed Windows Admin Centre on ADCON-MID. ADCON-MID was the right choice for this because it is a dedicated utility server that already hosts Entra Connect and runs continuously. Installing Windows Admin Centre on a Domain Controller directly is not recommended as it is better practice to use a separate management server.

The installation wizard offered Express or Custom setup. Express on a Windows Server configures Windows Admin Centre on port 443 with remote access automatically. I selected Express, chose to generate a self signed TLS certificate and set automatic updates. The self signed certificate generates a browser warning on first access which is expected in a home lab environment without a certificate authority.

After installation Windows Admin Centre was accessible at https://adcon-mid.emeka.cloud from any browser on the network.

Adding Managed Servers 

Once inside Windows Admin Centre I added four connections:

• DC1.emeka.cloud

• DC2.emeka.cloud

• ADCON-MID.emeka.cloud

• ADCON-MID as the local gateway

All four connected successfully using domain administrator credentials. The connections list showed recent timestamps confirming active connectivity to each server.

What You Can Do From the Browser 

Clicking into DC1.emeka.cloud opened its full management dashboard showing CPU usage, memory, network throughput and storage at a glance. From the left panel I could access Events, Services, Processes, Storage, Registry, Scheduled Tasks, Roles and Features, Updates and more, everything that would normally require separate MMC consoles or remote desktop.

The Events view showed Windows event logs without opening Event Viewer. The Services view showed all running services with the ability to start, stop and restart them from the browser. The PowerShell view opened a live PowerShell session running directly against DC1.

Azure Arc: Bringing On Premises Servers Into Azure

Windows Admin Centre handles on premises server management. Azure Arc handles cloud visibility and governance for those same on premises servers. The two complement each other, Windows Admin Centre for administration, Azure Arc for security posture and policy enforcement from the cloud.

Azure Arc works by installing the Azure Connected Machine Agent on the on premises server. Once installed the agent establishes an outbound connection to Azure and the server appears in the Azure portal as a managed resource. No inbound firewall rules, no VPN required, the agent connects outbound over HTTPS.

I onboarded DC1 to Azure Arc using a PowerShell script generated from the Azure portal. The script required a service principal with the correct permissions to create resources in Azure. Getting those permissions right took several attempts and is documented in Section 15. Once the permissions were correct the script completed in under five minutes.

What Azure Arc Makes Possible 

With DC1 onboarded to Azure Arc it can now receive Azure Policy assignments, appear in Microsoft Defender for Cloud security assessments and be monitored through Azure Monitor. These are cloud governance capabilities being extended to an on premises server without moving it anywhere.

In a real organisation this matters because not everything can move to the cloud immediately. Some servers stay on premises for compliance, latency or cost reasons. Azure Arc lets those servers participate in the same governance and security framework as cloud resources. One management plane covering both environments.

DC2 and ADCON-MID can be onboarded through the same process when needed. The same script with updated server names handles additional machines.

Microsoft 365 Security and Compliance 

Measuring and Improving Security Posture 

After building the environment, I also needed to secure it, which requires a different set of tools. Microsoft 365 includes a security measurement framework, audit logging, usage reporting and a unified compliance portal that together give an administrator visibility into what is happening across the entire tenant. Section 11 covers all of that.

Microsoft Secure Score

Secure Score is a continuous measurement of the security posture of a Microsoft 365 tenant. Every recommended security action has a point value and completing it increases the score. The score does not measure breraches, rather it measures how many of the available security controls that are configured.

When I first opened Secure Score the tenant was sitting at 35.9%, 98 out of 273 points. Microsoft showed a comparison against organisations of a similar size averaging 48.14%. That gave me a clear benchmark to work toward.

The recommended actions list had 46 items to address. Many of them require Defender for Office 365 plan configuration which is covered in Section 12. Several others require Entra ID Identity Protection which is a P2 feature. Rather than trying to action everything at once I picked two quick wins that were straightforward to complete immediately.

Two Actions Completed: Mailbox auditing enabled

Mailbox auditing records every significant action taken on a mailbox; emails read, messages moved or deleted, login activity, delegate actions. Without it there is no record of what happened to a mailbox if something goes wrong. I connected to Exchange Online through PowerShell and confirmed auditing was enabled at the organisation level with Set-OrganizationConfig and verified it with Get-OrganizationConfig returning AuditDisabled: False.

Two Actions Completed: Anonymous users restricted from Teams meetings 

The default Teams configuration allowed anonymous users to join meetings without signing in. I turned this off in the Teams admin centre under the Global meeting policy. Anyone joining a meeting from outside the organisation now needs to authenticate rather than joining anonymously. A small change with a meaningful security impact, uncontrolled anonymous access to internal meetings is a straightforward data exposure risk. 

Secure Score After Actions 

After completing the three actions the Secure Score updated to 40.29%. A 4.39 percentage point improvement from three configuration changes that each took a few minutes. 

Usage Reports

Usage reports give administrators visibility into how Microsoft 365 services are actually being used. The reports cover Exchange, Teams, SharePoint, OneDrive and other services with data available for 7, 30, 90 and 180 day periods.

The overview page for the emeka.cloud tenant showed 2 active users across Exchange, OneDrive, SharePoint and Teams. 55 email activities recorded covering sent, received and read actions. 25 files stored in SharePoint and 4 in OneDrive. 1 Office activation confirmed. Teams activity was not yet showing significant data as the service had only recently been configured.

In a real organisation usage reports answer practical questions, which services are actually being used, which users are not engaging, whether the investment in a particular service is justified. They also feed into licence optimisation decisions. A user with a Business Premium licence who never uses Teams or SharePoint may be better served by a cheaper licence tier.

Microsoft Purview 

The classic Microsoft compliance portal was retired in November 2024 and all compliance tooling moved to the new Microsoft Purview portal at purview.microsoft.com. The new portal brings together audit logging, data loss prevention, information protection, insider risk management and compliance manager in one place.

The compliance posture score in Purview showed 0% at this stage. No formal compliance assessments have been configured against industry regulations yet. This is expected for a home lab tenant. configuring compliance assessments against frameworks like ISO 27001 or NIST is planned as part of the Microsoft Purview section covered in Section 14.

Microsoft Defender for Business 

Endpoint Security and Vulnerability Management  

Microsoft Defender for Business is included in the Business Premium subscription and I found it to be very practical as It gives visibility into what is actually happening on managed devices. Visibility into what vulnerabilities exist, what software is installed, what security configurations are missing and what threats have been detected. Setting it up was quick and it revealed a lot about DELL-XPS-LAPTOP in the first hour.

Setting Up Defender for Business 

The setup wizard walked through four steps. User permissions were emeka@emeka.cloud, assigned as Security Administrator with full access to view and manage security settings, and tina.timothy@emeka.cloud assigned as Security Reader with read only visibility. Email notifications were configured for both incidents and vulnerabilities so alerts arrive by email without needing to check the portal constantly.

All three Intune enrolled devices were onboarded through the wizard. Defender for Business connects to Intune directly and pushes the onboarding configuration to enrolled devices automatically.

The simplified configuration option was selected rather than continuing to manage security settings through Intune manually. Selecting simplified configuration tells Defender for Business to create Microsoft recommended security policies automatically and apply them across all onboarded devices.

What Simplified Configuration Created 

Two security policies were created automatically and pushed to DELL-XPS-LAPTOP through Intune:

The NGP Windows default policy covers next generation antivirus protection. 27 settings applied across real time monitoring, cloud protection, behaviour monitoring, network protection, email scanning, script scanning, PUA blocking, automatic sample submission and scheduled scanning. All 27 showing as succeeded.

The Firewall Windows default policy covers Windows Firewall across domain, private and public network profiles. 9 settings applied covering inbound and outbound default actions and firewall enablement across all three network types. All 9 showing as succeeded.

36 security configuration settings applied to DELL-XPS-LAPTOP without touching the device.

The Defender Dashboard 

Once devices onboarded the Defender dashboard updated with real data. Secure Score jumped to 42.45% reflecting the additional security controls activated by Defender. Device compliance showing 0% noncompliant confirmed all enrolled devices were meeting the compliance baseline. No active incidents and no active malware detected on initial assessment.

What Defender Found on DELL-XPS-LAPTOP 

DELL-XPS-LAPTOP appeared in the device inventory within 30 minutes of onboarding. Status Active, primary user Tina Timothy, Windows 11 64-bit build 26200.9168, onboarded through Intune. Within the first hour Defender had completed a full assessment of the device. 

966 Vulnerabilities 

The vulnerabilities tab showed 966 items on DELL-XPS-LAPTOP. Multiple Critical severity CVEs scoring 9.8 and 9.6 across Windows 11, Google Chrome and Microsoft Edge. The root cause of the majority was straightforward — the September 2026 Security Updates had not been installed on the device. 

Software Inventory

The software inventory tab showed every application installed on DELL-XPS-LAPTOP with version numbers and CVE counts. Windows 11 carrying 625 known vulnerabilities. Chrome at 288. VS Code at 39. Edge at 49. Dell SupportAssist, Dell Update, PuTTY, Oracle VirtualBox, VMware Player, GitHub Desktop, Zoom, Loom and more all identified automatically.

Software inventory gives administrators complete visibility into what is installed across managed devices without logging into each machine or running manual discovery. 

Missing Patches 

The missing KBs tab identified two outstanding patches. The September 2026 Security Updates KB5124008 covering 624 vulnerabilities on Windows 11 and the August 2026 Hotpatch KB5129241 covering 1 additional vulnerability. A single missing monthly update patch was responsible for the vast majority of the vulnerability count. 

65 Security Recommendations 

The vulnerability management recommendations page showed 65 active items across the tenant. Software update recommendations for Windows 11, Chrome, Edge, VS Code, Dell SupportAssist and PuTTY. Configuration change recommendations covering Attack Surface Reduction rules, LDAP signing and encryption, LSA protection, Credential Guard, UAC settings, controlled folder access and firewall notification settings.

Each recommendation shows the number of affected devices, the category of change required, the relevant security benchmarks recommending it and the related threats it mitigates.

Actioning a Recommendation

Clicking into the Windows 11 update recommendation showed the full breakdown containing 625 vulnerabilities, 24 Critical, 477 High and 124 Medium severity CVEs, with a verified remote code execution exploit publicly available for at least one of them. A remediation request was created directly from the recommendation with a due date of 7 days, High priority and assigned to the admin account.

The Defender and Intune Connection 

Defender for Business and Intune work as a pair in this environment. Intune manages device configuration and compliance. Defender provides security visibility and vulnerability management. The Windows compliance policy configured in Section 8 included a Machine Risk Score setting that could not evaluate at the time because the Defender connector was not yet configured. With Defender now active and the Intune connector enabled that setting can evaluate correctly, a device with a High or Critical risk score in Defender would be marked non-compliant in Intune and blocked from accessing company resources through Conditional Access. The full security enforcement loop is now complete. 

Microsoft Copilot Administration 

AI Across the Microsoft 365 Environment 

Microsoft 365 Copilot came included with the Business Premium subscription and I wanted to document it properly rather than just mention it exists. Every organisation with Microsoft 365 is either already deploying Copilot, planning to or actively deciding whether to. Knowing how to administer it and what it actually does in practice is becoming an expected part of the Microsoft 365 skill set. 

The first thing I understood when setting it up is that Copilot access is licence driven. Both emeka@emeka.cloud and tina.timothy@emeka.cloud have access because both have Business Premium with Copilot licences assigned. Managing who gets Copilot means managing licence assignment through the Microsoft 365 admin centre, the same process used for every other service in the tenant. There is no separate Copilot permissions panel. 

Administering Copilot 

The Copilot section in the admin centre gives visibility into configuration, consumption and adoption across the tenant. When I opened it the top actions flagged three things. Copilot was not pinned to the Windows taskbar making it harder for users to find. Enterprise websites had not been connected so Copilot could only draw on Microsoft 365 data rather than wider organisational knowledge. No Viva Engage community had been set up to support adoption.

In a real organisation the IT admin would work through these actions as part of a Copilot rollout. Pinning Copilot to the taskbar ensures users see it without needing to search for it. Connecting the company intranet or external knowledge bases extends what Copilot can reference when answering questions. The adoption dashboard shows which users are engaging with Copilot and which are not, giving the admin team the data to target training and awareness where it is needed most.

Copilot in Word 

I opened a blank Word document in the browser and used Copilot to draft an IT incident report for a BitLocker recovery event. I chose this scenario deliberately because it connected directly to what was built in Section 8. In that section BitLocker recovery keys were escrowed to Entra ID and made retrievable from the Intune console. If a user ever triggers BitLocker recovery the IT team retrieves the key from Intune and the incident gets documented. Copilot handles the documentation side of that workflow.

The output covered incident summary, impact, actions taken, preliminary root cause and follow-up actions, a complete structured report from a single prompt. In a real service desk environment this reduces the time spent writing routine incident documentation while ensuring the right structure and detail is captured every time.

Copilot in Teams

I asked Copilot inside Teams to draft an All Staff meeting invitation for 10am on the first Tuesday of October 2026. Copilot identified that date as 6 October 2026 correctly and produced three complete options covering different tones including professional, brief and direct, and friendly, each with a subject line, body and sign off ready to send without editing.

In a real organisation this is how Teams Copilot gets used most frequently. Drafting messages, summarising meeting notes, catching up on a channel after time away. The point is that Copilot is embedded inside Teams rather than being a separate application the user has to switch to. It is available where people already spend their working day

In the Business Premium tier Copilot operates as a generative assistant rather than a fully agentic one. Taking direct actions like booking meetings, sending emails or creating tasks requires either a higher tier Copilot licence with Copilot Actions enabled or a custom agent built in Microsoft Copilot Studio with specific action permissions granted. 

Microsoft Purview and Information Protection

Classifying and Protecting Data Across the Tenant

Most of the work in this project up to this point has been about identity, devices and collaboration. Section 14 shifts focus to the data itself — how it is classified, what protections apply to it and how the organisation knows whether it is handling sensitive information correctly. Microsoft Purview is the platform that handles all of that. It was accessible through the Business Premium subscription and I wanted to demonstrate the core information protection capabilities rather than just acknowledge they exist.

Sensitivity Labels

The first thing I configured was sensitivity labels. Labels are the classification layer, they tell users and systems what kind of information a document or email contains and what protections should apply to it. Without labels there is no consistent way to distinguish between a public press release and a confidential HR document stored in the same SharePoint library.

I created three labels reflecting a realistic classification scheme for a small organisation:

Public: content approved for external distribution. No additional protections. Green colour in the user interface.

Internal: the default label for general business content. Applies to most day to day documents and emails. Yellow colour.

Confidential: sensitive content restricted to authorised personnel. Red colour with a watermark marking every document clearly. Full encryption enforcement requires Microsoft Purview Information Protection Plan 1 which is above the current subscription, the label structure and visual classification are in place and encryption can be added when the licence is upgraded.

The labels were created in priority order. Public at 0, Internal at 1, Confidential at 2. Priority matters because it determines which direction counts as a downgrade. Moving from Confidential to Internal is a downgrade and triggers a justification requirement. Moving from Internal to Confidential is an upgrade and happens without restriction.

Publishing the Labels

Creating labels is not enough as they need to be published before users can see them. I created the emeka.cloud Sensitivity Label Policy and configured it with several important settings.

Internal was set as the default label for documents, emails and meetings. Every new document, every email composed and every meeting created starts with the Internal label applied automatically. Users can change it but they cannot leave content unlabelled.

Labels were made mandatory before saving documents or sending emails. A user cannot save a Word document without selecting a label and cannot send an email without one applied. This builds classification as a habit from the start rather than something people do occasionally when they remember.

Justification was required to remove a label or replace it with a lower priority one. Downgrading a Confidential document to Internal requires the user to explain why. That justification is recorded in the audit log and available for review through Activity Explorer.

Label inheritance was enabled for emails. If a user attaches a Confidential document to an Internal email the email label automatically upgrades to Confidential. Sensitive content cannot slip out under a lower classification because of how it was attached.

Data Loss Prevention

Sensitivity labels classify content. A DLP policy enforces what can be done with it. I created a policy called Protect Confidential Content covering Exchange email, SharePoint, OneDrive, Teams and Microsoft 365 Copilot.

The rule inside the policy, Block External Sharing of Confidential Content, detects when content matching the conditions is shared with people outside the emeka.cloud organisation. When triggered it blocks access, shows the user a policy tip explaining why the action was blocked and sends a high severity alert to the administrator.

One limitation encountered during configuration, the sensitivity label condition in DLP rules requires Microsoft Purview Information Protection Plan 1. On the current Business Premium licence the sensitivity label condition was not available in the DLP rule builder. The policy was created with the available conditions and the sensitivity label integration can be added when the licence is upgraded. The architecture is correct, label and DLP policy working together is the right approach and the framework is in place.

Compliance Manager

The Compliance Manager page showed a posture score of 63%, 1702 out of 2674 points achieved. The majority of those points are Microsoft managed controls that Microsoft configures and maintains automatically as part of the service infrastructure. The 80 improvement actions not yet completed represent what the administrator can configure to improve the score further.

The improvement actions cover information governance, access control, device management, threat protection, audit configuration, insider risk management and AI security. Each action shows its point value and links to implementation guidance. Compliance Manager turns compliance from an abstract concept into a prioritised list of specific things to configure.

The score breakdown showed 0% across most categories including Govern information, Control access, Manage devices and Protect information, all of which reflect configurations that require higher licence tiers or additional setup beyond what Business Premium provides. The 63% overall score is driven almost entirely by the Microsoft managed controls rather than administrator actions. Addressing the improvement actions would require Microsoft Purview compliance add-ons or an E3 or E5 licence.

What Purview Adds to the Project

The identity and device controls configured across Sections 3 through 12 determine who can access Microsoft 365 resources and from which devices. Purview adds the data layer, controlling what happens to the content those users create and share. Sensitivity labels travel with documents wherever they go. A Confidential document emailed to an external recipient is blocked by the DLP policy even if the user has a fully compliant device and valid MFA session. The protection follows the data rather than relying solely on access controls at the perimeter.

Windows Autopilot 

Zero Touch Device Deployment 

Everything built in Section 8, including compliance policies, configuration profiles, update rings, LAPS, they all assumes a device is already enrolled in Intune before any of that applies. Autopilot is how devices get into that managed state in the first place, without IT needing to touch them.

The traditional approach to deploying a new Windows device involves IT receiving it, imaging it, installing software, configuring settings and only then handing it to the user. That process takes hours per device and does not scale. Autopilot replaces it. The device ships directly from the supplier to the user. The user turns it on, connects to WiFi and signs in with their Microsoft 365 credentials. Intune handles the rest automatically.

For this demonstration I used an old HP Pavilion that I wiped and reset to factory state. What happened after the reset is what this section documents.

How Autopilot Works 

Before Autopilot can do anything the device needs to be registered with the tenant. Registration involves capturing the hardware hash, which is a unique fingerprint of the device's hardware identifiers, and uploading it to Intune. Microsoft stores that hash against the tenant so when the device connects to the internet during first boot, Microsoft recognises it and knows which organisation it belongs to.

In a real enterprise deployment this registration happens at the manufacturer level. Dell, HP and Lenovo all offer services where every device ordered is registered with your Autopilot tenant before it ships. The hash never needs to be extracted manually. For this home lab demonstration I extracted it manually using PowerShell.

Extracting the Hardware Hash 

On the HP before the reset I ran the Get-WindowsAutopilotInfo script to capture the hardware hash and export it to a CSV file. Getting the hash uploaded to Intune took several attempts, the CSV file encoding caused import errors in the Intune portal and the Online upload method closed PowerShell before confirming completion. The fix was using the WindowsAutoPilotIntune PowerShell module with Microsoft Graph authentication to import the CSV directly rather than through the portal. Once connected the import completed successfully with serial number 5CD8110SQ3 confirmed and an import ID assigned.

This troubleshooting is documented in Section 16. The manual hash extraction process is not how it works in production — it exists here purely for demonstration purposes.

Creating the Deployment Profile

The deployment profile defines what the out of box experience looks like when the device boots for the first time after registration. I created a profile called emeka.cloud Autopilot Profile with these settings:

Deployment mode set to User Driven. The user signs in with their Microsoft 365 credentials during setup rather than the device being pre-configured before delivery.

Join type set to Microsoft Entra joined. The device joins Entra ID directly as a cloud only device with no on premises domain join. This is the modern approach for devices that do not need access to on premises resources through Group Policy.

Licence terms, privacy settings and account change options all hidden to streamline the experience. The fewer screens a user has to click through the less chance of confusion or mistakes during setup.

User account type set to Standard. Users should not be local administrators on company devices. Local admin rights are managed through LAPS configured in Section 8.

Device name template set to EMEKA-%RAND:4%. Every device enrolled through this profile gets named automatically with EMEKA followed by four random characters. Consistent naming without IT manually naming each machine.

Assigned to All devices so any hardware hash uploaded to the tenant receives this profile automatically.

The Reset and First Boot 

With the hash registered and the profile assigned I reset the HP to factory state through Settings → Recovery → Reset this PC → Remove everything. The reset took a little over 30 minutes and returned the HP to the Windows out of box experience.

When it booted the setup experience did not look like a standard Windows setup. Instead of the usual consumer wizard asking for a Microsoft account or local account setup, it presented a work sign-in screen. Signing in with emeka@emeka.cloud triggered the Autopilot process. Windows contacted Microsoft, the hardware hash was recognised, the deployment profile was applied and the device configured itself automatically.

What This Demonstrates 

EMEKA-4696 went from a wiped machine to a cloud managed corporate endpoint in under an hour. The device named itself, joined Entra ID, enrolled in Intune and received six configuration policies automatically. No IT engineer touched it after the reset. No imaging, no manual software installation, no manual domain join.

In a real organisation the process is even simpler because the hash extraction step is handled by the manufacturer. A new employee receives a laptop in the box, powers it on and signs in with their Microsoft 365 credentials. By the time they reach the desktop their policies are applying, their apps are installing and the device is under corporate management. The IT team configured it once in Intune and it scales to every device without additional effort.

The HP Pavilion running Windows 10 with TPM 1.2 had one limitation, BitLocker encryption could not enable automatically because BitLocker automatic enablement requires TPM 2.0. The compliance policy flagged this correctly as noncompliant. In a production environment all devices would have TPM 2.0 and Windows 11 Enterprise, resolving both the BitLocker and the Windows edition limitations encountered across Sections 8 and 15.

What Went Wrong and What I Learned 

IE Enhanced Security Blocking the Entra Connect Login 

During the Microsoft Entra Connect installation the sign-in popup failed to load because Internet Explorer Enhanced Security Configuration was blocking the Microsoft login page. Windows Server enables this by default and it blocks external websites in the browser. The fix was adding login.microsoftonline.com and the Microsoft authentication CDN to the trusted sites list in IE. A simple fix once you know what is happening but it was not obvious at first because the error just showed a red blocked content warning without clearly explaining what to do.

Learning: Windows Server has IE Enhanced Security enabled by default. Any browser based authentication during server side application setup needs those URLs in the trusted sites list first.

MDT and ADK Compatibility

Section 7 was the most frustrating part of the project. MDT boot image generation failed repeatedly with NullReferenceException errors, WIM file errors and drive mapping failures across multiple troubleshooting attempts. Downgrading from the latest ADK to version 2004, editing the Settings.xml file directly and trying both GUI and PowerShell update methods all failed to generate a working x64 boot image.

The root cause was a known compatibility issue between the current version of MDT and newer ADK releases. Microsoft has not released an MDT update to fix it and their own documentation now recommends moving to Windows Autopilot and Intune for modern device deployment. I made the decision to document what I built, the Deployment Share, Windows image import and task sequence, and move on rather than spending more time on a tool Microsoft is actively deprecating.

Section 15 demonstrates the modern replacement. Autopilot and Intune achieved in under an hour what MDT was supposed to do without any of the compatibility problems.

Learning: Always check compatibility between tools before investing significant time in troubleshooting. If Microsoft is steering away from a tool the compatibility issues are likely to get worse not better. Knowing when to move on is as important as knowing how to fix things.

Intune Auto Enrolment GPO Not Working 

The Intune auto enrolment Group Policy I created was not applying to DELL-XPS-LAPTOP. Running gpresult /r showed the MDM policy was not present at all in the applied policies list. The reason was that the Windows ADMX administrative templates on DC1 were outdated and did not include the MDM policy definition. The policy simply did not exist in Group Policy Editor.

The fix came from the Microsoft Learn article on enrolling Windows devices automatically using Group Policy. Downloading the latest Windows ADMX templates, installing them on DC1 and copying the PolicyDefinitions folder to SYSVOL made the MDM policy appear in Group Policy Editor and the existing GPO started applying correctly.

A second issue blocked enrolment even after the GPO was fixed. DELL-XPS-LAPTOP had the domain Administrator account logged in. Intune enrolment requires a licensed Entra ID user. The domain Administrator has no Microsoft 365 licence so Intune had nothing to associate the enrolment with. Logging in as tina.timothy resolved it immediately.

Learning: MDM Group Policy requires current ADMX templates on the Domain Controller. Intune enrolment requires a licensed user to be signed in, the domain Administrator account alone is not enough even with everything else configured correctly.

Azure Arc Permission Errors

Onboarding DC1 to Azure Arc required three separate role assignments before the script would complete successfully. The initial Azure Connected Machine Onboarding role was not enough. Adding Azure Connected Machine Resource Administrator at the resource group level was not enough. The script kept returning error code 403 with the message that the service principal did not have permission to perform the Microsoft.HybridCompute/register/action over the subscription scope.

The fix was assigning the Contributor role at the subscription level to the ArcOnboarding service principal. Contributor was a broader permission than needed for ongoing Arc management so after DC1 was successfully onboarded the Contributor role was removed and only the two Arc specific roles were kept.

There was also an Object ID confusion, the app registration and the enterprise application for ArcOnboarding show different Object IDs. The error message references the enterprise application Object ID while the Azure portal role assignment UI surfaces the app registration. Understanding that these are two representations of the same identity but with different identifiers helped resolve the confusion.

Learning: Azure Arc onboarding requires the Microsoft.HybridCompute/register/action permission at the subscription scope not just the resource group. Role assignment propagation in Azure can take up to 10 minutes. Always wait after assigning roles before retrying a failed operation.

Split-DNS Conflict

Using emeka.cloud as both the public website domain and the internal Active Directory domain name created a split-DNS conflict that surfaced in multiple places across the project. Domain joined machines resolved emeka.cloud to internal AD records rather than the public website. The Edge browser configuration profile set emeka.cloud as the homepage but domain joined machines could not browse to it because DC1 returned internal IP addresses for the domain.

The partial fix was adding public A records to the emeka.cloud zone in DC1's DNS Manager pointing to the Google CDN IP addresses serving the website. This allowed domain joined machines to reach the public website while internal AD name resolution continued working.

Microsoft recommends using a dedicated subdomain like corp.emeka.cloud or a separate non-routable domain for internal AD to avoid this conflict entirely. If I were building this environment again the AD domain would be corp.emeka.cloud and emeka.cloud would remain exclusively for public facing services.

Learning: Never use your public domain name as your internal Active Directory domain name. The split-DNS conflict it creates affects browser based tools, application authentication and any service that resolves the domain differently on premises versus externally.

Windows Server Evaluation Licence Expiring

At 11 hours remaining on the Windows Server evaluation licence on DC1 the desktop showed an activation watermark and the system threatened to shut down. Running slmgr /rearm reset the evaluation timer and gave another 180 days. The same was done on DC2.

Learning: Windows Server evaluation licences run for 180 days and can be rearmed up to three times using slmgr /rearm. In a home lab environment calendar reminders set at 150 days from installation date avoid hitting this unexpectedly. In production servers run on fully licenced copies through volume licensing or Azure hybrid benefit.

Autopilot Hash Upload Failures 

Getting the hardware hash from the HP into Intune Autopilot took far longer than expected. The Get-WindowsAutopilotInfo script exported the hash correctly but the CSV file had UTF-16 encoding with a BOM character that caused Intune to reject it with an incorrect headers error. Converting to UTF-8, adding the required optional column headers, fixing CRLF line endings and multiple portal upload attempts all failed before switching to the PowerShell module approach using Microsoft Graph.

The WindowsAutoPilotIntune module with Connect-MgGraph authentication uploaded the hash directly and successfully. The whole troubleshooting process took over an hour for what should have been a two minute task.

Learning: When uploading Autopilot hashes through the Intune portal the CSV must be UTF-8 encoded without BOM and must include all five column headers including the optional Group Tag and Assigned User columns even if those values are empty. Using the Get-WindowsAutopilotInfo script with the Online parameter or the WindowsAutoPilotIntune PowerShell module bypasses CSV formatting issues entirely.

What This Project Taught Me Overall

Building a home lab and documenting it honestly is a completely different experience from following a tutorial. Tutorials show the happy path. Real environments hit compatibility issues, permission errors, licence limitations and unexpected interactions between systems that no tutorial covers.

Every error in this section represents something I now know how to diagnose and fix because I actually encountered it. The MDT compatibility issue taught me to check Microsoft's current recommendations before investing time in legacy tooling. The Azure Arc permission errors taught me how Azure RBAC propagation works in practice. The split-DNS conflict taught me a planning decision I will never make the same way again.

The project is not finished because everything worked. It is finished because everything that broke got fixed, documented and understood.

What Comes Next

Where This Goes From Here

Two projects are complete. The ADDS home lab built the on premises foundation. This Microsoft 365 project extended that foundation into the cloud. What comes next is connecting everything into a single integrated environment where on premises infrastructure, cloud identity, Microsoft 365 services and ServiceNow all talk to each other.

Where This Goes From Here

ServiceNow Integration Project

The next project in this portfolio connects the environment built here to ServiceNow. The goal is a unified ITOM and identity integration covering everything from CMDB population to SSO to AI powered service management.

MID Server

The MID Server will be installed on ADCON-MID, connecting the on premises environment to the ServiceNow PDI. The MID Server is the bridge that makes everything else in the integration possible, without it nothing on premises can reach ServiceNow.

Active Directory Service Graph Connector

The AD Service Graph Connector will read computer and user objects from the emeka.cloud Active Directory through the MID Server and populate them as Configuration Items in the ServiceNow CMDB. DELL-XPS-LAPTOP, HP-PAVILION, EMEKA-4696, DC1, DC2 and ADCON-MID will all appear as managed CIs.

Microsoft Intune Service Graph Connector

The Intune connector will enrich those same CI records with compliance status, OS version, enrolled user and management state from Intune. One CI in ServiceNow will show both the on premises AD identity and the Intune management data together — a complete picture of each device from a single CMDB record.

AWS EC2 Integration

AWS EC2 instances will be connected to the same CMDB through the AWS Service Graph Connector, adding cloud infrastructure alongside on premises and Microsoft 365 resources. Three platforms, one CMDB.

CMDB Relationship Mapping

Once all connectors are running the focus shifts to CI relationships, service maps and dependency views. Demonstrating downstream impact analysis — what breaks if DC1 goes down, what services depend on ADCON-MID, what the blast radius of an AWS EC2 failure looks like — turns the CMDB from a list of assets into a live map of service dependencies.

Entra ID SSO with ServiceNow

SAML Single Sign-On will be configured between Microsoft Entra ID and the ServiceNow PDI. Users synced from on premises AD, authenticated through Microsoft 365 with MFA enforced by Conditional Access, will sign into ServiceNow automatically without a separate login. The Workspace Reservation Management app built on the PDI will be accessible through SSO from the default browser homepage — completing the identity chain from on premises Active Directory all the way through to a ServiceNow scoped application.

ServiceNow Email Integration via Microsoft Graph

The helpdesk@emeka.cloud shared mailbox configured in Section 6 will be connected to ServiceNow through the Microsoft Graph API. Emails sent to helpdesk@emeka.cloud will appear in ServiceNow automatically and trigger incident creation workflows. The integration uses an Entra ID app registration with Client Credentials authentication and an Application Access Policy scoping access to the helpdesk mailbox only. A scheduled job in ServiceNow will monitor the client secret expiry and create an automated incident task 30 days before it expires.

Microsoft Copilot and ServiceNow via Action Fabric

ServiceNow Action Fabric or MCP integration will allow Microsoft Copilot to query CMDB data directly. A user will be able to ask Copilot a question about a CI — dependencies, downstream impact, open related incidents — and receive the answer from ServiceNow without opening the ServiceNow interface. The post that inspired this section showed exactly this working in a real enterprise environment. Building it in a home lab and documenting it puts this portfolio in a very small group.

Windows Autopilot: Remaining Work

EMEKA-4696 enrolled successfully through Autopilot but is currently showing as noncompliant because BitLocker could not enable automatically on TPM 1.2. When a device with TPM 2.0 and Windows 11 is available it will replace the HP Pavilion as the primary Autopilot demonstration device, completing the full zero touch deployment story from hardware hash registration through to a fully compliant managed endpoint.

Always On VPN

A dedicated standalone project covering Always On VPN will demonstrate how remote workers maintain secure connectivity to on premises resources without a traditional VPN client that requires manual connection. Always On VPN connects automatically when the device is outside the corporate network, giving remote workers transparent access to on premises file shares, printers and internal applications. The on premises AD and ADCON-MID built in this project provide the infrastructure foundation for that deployment.

NinjaOne RMM

NinjaOne will be added as a standalone project demonstrating a third party Remote Monitoring and Management platform alongside the Microsoft native tooling covered here. Many organisations use RMM tools from vendors like NinjaOne, ConnectWise or Datto alongside or instead of Intune. Demonstrating familiarity with both the Microsoft native stack and a third party RMM platform broadens the range of environments the portfolio is relevant to.