← Back to articles Intune

Windows Hello for Business - Cloud Kerberos Trust Complete Hybrid Deployment

Windows Hello for Business - Cloud Kerberos Trust Complete Hybrid Deployment

🚨 What Is Happening & Why It Matters

Windows Hello for Business (WHfB) with Cloud Kerberos Trust is the modern passwordless deployment model for hybrid enterprises. It lets users sign in with PIN, fingerprint, or face recognition and still access on-premises file shares, printers, and legacy services — without passwords, certificates, or on-prem PKI. Yet in 30–50% of hybrid deployments, the rollout fails silently.

The failure is never one thing. Cloud Kerberos Trust is a four-layer orchestration where on-premises AD, Entra ID, Intune, and the device itself must all be precisely configured in sequence. Miss one step, apply one policy to the wrong scope, or leave one legacy GPO in place — and users cannot enroll. No error. No alert. Just non-compliance.

🔴 Critical: TPM 2.0 Is Non-Negotiable Without Require Security Device = Enabled in your Account Protection policy, WHfB keys are stored in software, not hardware. Software-stored keys are phishable. This directly violates NIST 800-63B AAL3, NIS2 Article 21, and ISO 27001 A.9.4. Every deployment must enforce TPM 2.0 from day one.
4Infrastructure Layers
3Critical Failure Modes
TPM 2.0Required for NIST AAL3
≠ GPOMDMWinsOverGP Required

🏛️ Architecture Overview

ON-PREMISES ENTRA ID / CLOUD INTUNE MDM DEVICE Domain Controller AzureADHybrid AuthManagement ✓ Cloud Kerberos Active Directory On-Prem Domain Hybrid Join Sync ⚠ FAILURE #1 TLS / PSGallery Module Install Fails Microsoft Entra ID Cloud Identity Trust Kerberos Ticket Issuance Hybrid Join AzureAdJoined=YES AzureAdPrt=YES Microsoft Intune Settings Catalog OMA-URI Custom Account Protection ⚠ FAILURE #2 Device vs User Scope Silent Policy Miss Windows Device TPM 2.0 Chip Hello Container PIN / Face / Finger ⚠ FAILURE #3 TPM Missing / BIOS SCCM Workload Block Registers Kerberos Trust Token MDM Policy ✓ USER ENROLLED WHfB Active On-Prem Access OK Healthy data flow Failure point Successful enrollment
Four-layer WHfB Cloud Kerberos Trust architecture — animated blue arrows show healthy data flow; red dashed boxes mark the three most common silent failure points

📋 Prerequisites Before You Start

💻 Device Requirements

Windows 10 21H2+ or Windows 11. TPM 2.0 chip enabled in BIOS. Azure AD Hybrid joined or Entra ID joined. Must have an active Primary Refresh Token (PRT).

🏢 Infrastructure Requirements

Active Directory with at least one Windows Server 2016+ DC. Azure AD Connect syncing to Entra ID. Microsoft Entra ID P1 or P2 licence. Intune licence per user.

🔐 Admin Accounts Needed

On-premises Domain Admin account (for DC setup). Entra ID Global Admin or Hybrid Identity Admin (for cloud credential). Intune Administrator.

🚫 What You Do NOT Need

No on-premises PKI or Certificate Authority. No certificate templates. No NPS servers. Cloud Kerberos Trust eliminates the certificate dependency entirely.

🔧 Step-by-Step Deployment

  1. Prepare the Domain Controller - Fix TLS & PSGallery

    Open PowerShell as Administrator on a Domain Controller. Older Windows Server versions default to outdated TLS protocols, which causes PSGallery connections to fail. Run these commands first:

    # Force TLS 1.2 - required on Windows Server 2016 / 2019 [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 # Install NuGet provider Install-PackageProvider -Name NuGet -Force # Register PSGallery if not already present if (@(Get-PSRepository | Where-Object { $_.Name -eq "PSGallery" }).Count -eq 0) { Register-PSRepository -Default Set-PSRepository -Name "PSGallery" -InstallationPolicy Trusted } # Update PowerShellGet then install the Cloud Kerberos module Install-Module -Name PowerShellGet -Force Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
    ⚠ Common Error on Server 2016 / 2019 If you see "Unable to find repository 'PSGallery'" or "TLS/SSL connection failed", the [Net.ServicePointManager] line above is the fix. This command must run in the same PowerShell session before any Install-Module call.
  2. Register the Cloud Kerberos Server on the DC

    After the module installs, register the domain controller with Entra ID. This creates the AZUREAD Kerberos server object in your AD that issues cloud-aware tickets:

    # You will be prompted for two sets of credentials: # 1. DomainCredential - your on-prem Domain Admin account # 2. CloudCredential - your Entra ID Global Admin / Hybrid Identity Admin Set-AzureADKerberosServer ` -DomainCredential (Get-Credential) ` -CloudCredential (Get-Credential) # Verify it registered correctly: Get-AzureADKerberosServer # Expected: IsDefault=True, CloudDisplayName=[your tenant domain]
    🛠️ Multi-Domain Forests If your AD forest contains multiple child domains, run Set-AzureADKerberosServer once per domain on a DC in that domain. The registration is not forest-wide — each domain needs its own cloud Kerberos object.
  3. Create the Entra ID Pilot User Group

    Before touching any Intune policy, create the group that will scope your entire pilot rollout. In Entra ID (portal.azure.com) → Groups → New Group:

    # Group configuration: "Group Type": Security "Name": Windows Hello for Business Users "Membership Type": Assigned # Add 10-20 pilot users as members # DO NOT add all users yet - validate pilot first # Optional: verify via PowerShell Get-MgGroup -Filter "displayName eq 'Windows Hello for Business Users'"
  4. Intune Policy 1 - Settings Catalog: Cloud Kerberos Trust

    In Intune: Devices → Configuration → Create → New Policy → Windows 10 and later → Settings Catalog

    Search for and enable these two settings:

    # Settings Catalog - search and enable: # Category: Kerberos "Cloud Kerberos Ticket Retrieval Enabled": Enabled # Category: Windows Hello for Business "Use Cloud Trust For On Prem Auth": Enabled # Assignment: "Assign to": Windows Hello for Business Users (the group from Step 3)
  5. Intune Policy 2 - Custom OMA-URI Profile (4 Settings)

    Create a second policy: Devices → Configuration → Create → Custom. Add these four OMA-URI entries. The MDMWinsOverGP setting is critical in environments with legacy Group Policy or SCCM — it forces Intune policy to win every conflict:

    ## Setting 1 - MDMWinsOverGP (forces Intune priority over GPO) Name: MDMWinsOverGP OMA-URI: ./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP Type: Integer Value: 1 ## Setting 2 - Activate Windows Hello for Business Name: UsePassportForWork OMA-URI: ./Device/Vendor/MSFT/PassportForWork/8858cc88-8c0d-48e6-b87c-dcc34f48dc0f/Policies/UsePassportForWork Type: Integer Value: 1 ## Setting 3 - Enable Cloud Trust for On-Prem access Name: UseCloudTrustForOnPremAuth OMA-URI: ./Device/Vendor/MSFT/PassportForWork/8858cc88-8c0d-48e6-b87c-dcc34f48dc0f/Policies/UseCloudTrustForOnPremAuth Type: Integer Value: 1 ## Setting 4 - CRITICAL: Enforce TPM 2.0 hardware key storage Name: RequireSecurityDevice OMA-URI: ./Device/Vendor/MSFT/PassportForWork/8858cc88-8c0d-48e6-b87c-dcc34f48dc0f/Policies/RequireSecurityDevice Type: Integer Value: 1
    🔗 Reference: Microsoft Learn These OMA-URI values are documented in Microsoft's official Hybrid Cloud Kerberos Trust deployment guide. The GUID 8858cc88-8c0d-48e6-b87c-dcc34f48dc0f is the PassportForWork policy area identifier used in all CSP-based WHfB configurations.
  6. Intune Policy 3 - Account Protection (USER Scope - Most Critical)

    Navigate to Endpoint Security → Account Protection → Create Policy → Windows 10 and later → Account Protection template. This policy activates WHfB and defines PIN security rules. It must be assigned to Users, not Devices — assigning to Devices is the single most common deployment failure.

    🔴 User Scope is Mandatory — Not Optional If you assign this policy at Device scope, registry keys write to HKLM but the user context never receives the enrollment trigger. Users see no prompt. No error. Just permanent non-enrollment. The policy must target the user group, not a device group.

🔎 PIN Policy Configuration Reference

Every setting in the Account Protection policy has a specific rationale tied to a compliance standard. Do not adjust these values without understanding the regulatory impact:

Setting NameRecommended ValueStandardRationale
Enable Windows Hello For BusinessTrueAllActivates the feature. User-scoped assignment mandatory.
Use Windows Hello For BusinessTrueEnforces WHfB as the primary sign-in method.
Require Security Device (TPM 2.0)⚡ True - CRITICALNIST AAL3 / NIS2Keys stored in hardware TPM, not software. Phishing-resistant. Without this = compliance failure.
Enable PIN RecoveryTrueISO 27001 A.17MFA-secured recovery. Reduces helpdesk tickets. Protects availability.
Minimum PIN Length8 charactersNIST 800-63B §5.1.1.26 is baseline minimum; 8 recommended for AAL2+ environments.
Maximum PIN Length127 charactersNIST 800-63BAllows users to use passphrases instead of short PINs if preferred.
Special CharactersRequiredISO 27001 / SOC2ISO and SOC2 auditors expect at least one special character. Prevents trivial numeric-only PINs.
Uppercase LettersAllowedNIST 800-63B"Allowed" not "Required" reduces friction while maintaining security posture.
Lowercase LettersAllowedNIST 800-63BSame as above. Full character set permitted.
PIN ExpirationNot ConfiguredNIST 800-63B §5.1.1.2NIST explicitly recommends against forced rotation. Expiration leads to predictable increments: 1111 → 1112 → 1113.
PIN HistoryNot ConfiguredNIST 800-63BNot needed since expiration is disabled. History enforcement only matters when rotation is mandatory.

🔴 The Three Silent Failure Modes

These are the failure patterns that affect 30–50% of WHfB Cloud Trust deployments. They share one trait: no error message, no alert, just no enrollment.

🔴 Failure #1 — Module Installation Blocked on Domain Controller

What happens: The Install-Module AzureADHybridAuthenticationManagement command fails or hangs on Windows Server 2016/2019.

Root cause: PowerShell defaults to TLS 1.0/1.1 on older Server versions. PSGallery (PowerShell Gallery) requires TLS 1.2+. Additionally, PSGallery may not be registered as a repository out of the box.

Fix: The four-line TLS + PSGallery block in Step 1 above. Run it in the same PowerShell session immediately before any Install-Module call.

🔴 Failure #2 — Policy Scope Mismatch (Most Common)

What happens: All policies are deployed, devices are compliant in Intune, but users are never prompted to set up Windows Hello. WHfB remains disabled.

Root cause: The Account Protection policy was assigned to a Device group instead of a User group. Registry keys write to HKLM\SOFTWARE\Microsoft\Policies\PassportForWork correctly — but the per-user enrollment trigger never fires. The device sees the policy; the user never does.

Fix: Delete the device-scoped Account Protection policy. Recreate it and assign the group in the Users tab, not the Devices tab, of the assignment blade.

🔴 Failure #3 — TPM Missing in BIOS or SCCM Workload Blocking

What happens: Policy arrives. PRT is valid. Azure AD join is confirmed. But enrollment still fails or falls back to software key storage.

Root cause A: TPM 2.0 is present but disabled in the device BIOS firmware settings. Get-Tpm shows TpmPresent=True but TpmReady=False.

Root cause B: In SCCM co-managed environments, if SCCM owns the Device Configuration or Resource Access co-management workloads, Intune's WHfB policies are silently ignored by design.

Fix A: Enter BIOS/UEFI firmware settings and enable TPM 2.0. Clear the TPM if previously owned by another system.
Fix B: In SCCM console: Administration → Cloud Attachment → Co-management Properties → move Device Configuration and Resource Access sliders to "Pilot Intune" or "Intune".

📋 Diagnostic Script — Smart WHfB Health Check

Run this script on any affected device (as SYSTEM or elevated Admin) to instantly identify which layer is blocking enrollment. Written by Souhaiel MORHAG.

#Requires -RunAsAdministrator <# .SYNOPSIS Smart WHfB Diagnostic - Author: Souhaiel MORHAG .DESCRIPTION Checks all prerequisites. Auto-triggers MDM sync if policy is missing. #> $ErrorActionPreference = "SilentlyContinue" Clear-Host function Write-Check { param($Label, $Pass, $FixHint) if ($Pass) { Write-Host " [OK] $Label" -ForegroundColor Green } else { Write-Host " [!!] $Label - $FixHint" -ForegroundColor Red } } Write-Host "`n=== Windows Hello for Business Diagnostic ===" -ForegroundColor Cyan # 1. Azure AD Join + PRT $dsreg = dsregcmd /status Write-Check "Azure AD Joined" ($dsreg -match "AzureAdJoined : YES") "Run: dsregcmd /join" Write-Check "Primary Refresh Token (PRT)" ($dsreg -match "AzureAdPrt : YES") "Trigger Workplace Join sync below" if ($dsreg -notmatch "AzureAdPrt : YES") { Get-ScheduledTask -TaskPath "\Microsoft\Windows\Workplace Join\" | Start-ScheduledTask Write-Host " -> PRT sync triggered. Wait 2 min and rerun." -ForegroundColor DarkGray } # 2. TPM 2.0 $tpm = Get-Tpm Write-Check "TPM 2.0 Present" $tpm.TpmPresent "No TPM chip detected - check BIOS" Write-Check "TPM 2.0 Ready" $tpm.TpmReady "TPM disabled in BIOS - enable and clear TPM" Write-Check "TPM 2.0 Enabled" $tpm.TpmEnabled "TPM not enabled - check UEFI firmware" # 3. Intune Policy Registry $intuneKey = "HKLM:\SOFTWARE\Microsoft\Policies\PassportForWork" $policyArrived = Test-Path "$intuneKey\*" Write-Check "Intune Policy Arrived" $policyArrived "Policy missing - triggering MDM sync" if (-not $policyArrived) { Get-ScheduledTask | Where-Object { $_.TaskName -like "Schedule #3 created by enrollment client*" } | Start-ScheduledTask Write-Host " -> MDM sync triggered. Wait 5 min and rerun." -ForegroundColor DarkGray } # 4. GPO Conflict Check $gpo = Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\PassportForWork" -EA SilentlyContinue if ($gpo.Enabled -eq 0) { Write-Host " [!!] GPO CONFLICT - PassportForWork disabled by Group Policy" -ForegroundColor Red Write-Host " -> Deploy MDMWinsOverGP=1 OMA-URI policy in Intune" -ForegroundColor Yellow } else { Write-Host " [OK] No GPO conflict detected" -ForegroundColor Green } # 5. SCCM Co-management Check $coMgmt = Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\CCM\CoManagement" -EA SilentlyContinue if ($coMgmt) { $flags = $coMgmt.CoManagementFlags $intuneDevCfg = ($flags -band 4) -eq 4 $intuneResAcc = ($flags -band 32) -eq 32 Write-Check "SCCM: Intune owns Device Config" $intuneDevCfg "Move slider to Intune in SCCM console" Write-Check "SCCM: Intune owns Resource Access" $intuneResAcc "Move slider to Intune in SCCM console" } else { Write-Host " [OK] No SCCM co-management detected" -ForegroundColor Green } # 6. Hello Enrollment Status $pinPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{D6886603-9D2F-4EB2-B667-1971041FA96B}" $containers = Get-ChildItem $pinPath -Recurse -EA SilentlyContinue if ($containers) { Write-Host " [OK] Windows Hello Enrolled - $($containers.Count) container(s) found" -ForegroundColor Green $containers | ForEach-Object { Write-Host " Container: $($_.PSChildName)" -ForegroundColor DarkGray } } else { Write-Host " [--] No PIN container - user not enrolled yet (expected if policy just applied)" -ForegroundColor Yellow } # 7. Event Log (WHfB success/fail events) $evts = Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-User Device Registration/Admin'; ID=358,360 } -MaxEvents 5 -EA SilentlyContinue if ($evts) { Write-Host "`n Recent WHfB Events:" -ForegroundColor Cyan foreach ($e in $evts) { $label = if ($e.Id -eq 358) { "SUCCESS" } else { "BLOCKED" } $col = if ($e.Id -eq 358) { "Green" } else { "Red" } Write-Host " [$label] $($e.TimeCreated)" -ForegroundColor $col } } Write-Host "`n=== End of Diagnostic ===" -ForegroundColor Cyan

📊 Intune Detection Script - Proactive Remediation

Deploy this as a Proactive Remediation in Intune (Devices → Remediations) on a daily schedule. The detection script exits 0 if healthy, 1 to trigger the remediation script. Written by Souhaiel MORHAG.

Detection Script

# # Intune Detection Script - WHfB Enrollment Status # Author: Souhaiel MORHAG | Exit 0 = Healthy, Exit 1 = Remediate # # Primary check: does the user have a Hello PIN container? $pinPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{D6886603-9D2F-4EB2-B667-1971041FA96B}" $hasPin = Get-ChildItem $pinPath -Recurse -EA SilentlyContinue | Where-Object { $_.PSChildName -match "S-1-5-21" -or $_.PSChildName -match "S-1-12-1" } if ($hasPin) { Write-Host "WHfB enrolled - healthy"; Exit 0 } # Deep diagnostics to identify WHY it is missing $dsreg = dsregcmd /status if ($dsreg -match "AzureAdJoined : NO") { Write-Host "Error: Not Azure AD Joined"; Exit 1 } $tpm = Get-Tpm if (-not $tpm.TpmReady) { Write-Host "Error: TPM not ready"; Exit 1 } # SCCM co-management workload check $coMgmt = Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\CCM\CoManagement" -EA SilentlyContinue if ($coMgmt) { $flags = $coMgmt.CoManagementFlags if (($flags -band 4) -ne 4 -and ($flags -band 32) -ne 32) { Write-Host "Error: SCCM owns Device Config + Resource Access workloads"; Exit 1 } } # GPO blocking check $gpoEnabled = (Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\PassportForWork" -EA SilentlyContinue).Enabled if ($gpoEnabled -eq 0) { Write-Host "Error: Blocked by on-prem GPO"; Exit 1 } # Policy sync check if (-not (Test-Path "HKLM:\SOFTWARE\Microsoft\Policies\PassportForWork\*")) { Write-Host "Warning: Intune policy not synced yet"; Exit 1 } Write-Host "Policy present but user not enrolled - trigger remediation" Exit 1

Remediation Script

# # Intune Remediation Script - Force MDM Sync + PRT Renewal # Author: Souhaiel MORHAG # $ErrorActionPreference = "SilentlyContinue" # Trigger Intune MDM sync Get-ScheduledTask | Where-Object { $_.TaskName -like "Schedule #3 created by enrollment client*" } | Start-ScheduledTask # If PRT is missing, trigger Workplace Join sync $dsreg = dsregcmd /status if ($dsreg -notmatch "AzureAdPrt : YES") { Get-ScheduledTask -TaskPath "\Microsoft\Windows\Workplace Join\" | Start-ScheduledTask Write-Host "PRT sync triggered" } Write-Host "Remediation complete - MDM sync running. Allow 5 minutes." Exit 0

🔒 Compliance & Regulatory Mapping

NIST 800-63B ISO 27001 NIS2 DIRECTIVE WHfB SETTING Section 5.1.1.2 Min 6 chars / No rotation Min PIN = 8, Expiry = Off History = Not Configured AAL3 - Hardware Keys Phishing-Resistant MFA ⚡ Require Security Device = True (TPM 2.0 enforced) A.9.4 Access Control Character Complexity Special Chars = Required Upper/Lower = Allowed Article 21 - Risk Mgmt Strong Authentication TPM 2.0 + PIN Recovery = Meets Article 21 control
How WHfB Account Protection policy settings map to NIST 800-63B, ISO 27001 A.9.4, and NIS2 Article 21 requirements

👤 FAQ - Common Questions

💻 Does fingerprint authentication work when the laptop lid is closed?
Yes — if the fingerprint reader is powered when the lid is closed (most modern laptops keep USB/biometric sensors active even with the lid shut). However, face recognition requires the IR camera, which is lid-mounted and unavailable when the lid is closed. PIN always works regardless of lid state. For external monitor + closed-lid setups, fingerprint or PIN are the recommended methods.
📱 Can iPad and Android users access Microsoft 365 with Windows Hello-style passwordless auth?
Native Windows Hello for Business does not run on iOS or Android. However, Microsoft Authenticator on iOS/Android supports Passkey (FIDO2) sign-in and phone sign-in — both are phishing-resistant and use the same Entra ID account. For sales teams on iPad, configure Microsoft Authenticator as a passkey authenticator in Entra ID. This gives equivalent passwordless, biometric-backed MFA without requiring WHfB on the mobile device. Entra ID Conditional Access can enforce this requirement per platform.
🔒 What happens if a user forgets their PIN?
With Enable PIN Recovery = True in the Account Protection policy, users click "I forgot my PIN" on the Windows lock screen, complete an MFA challenge via the Authenticator app or email code, then set a new PIN immediately. No helpdesk ticket required. The recovery flow is secured by Entra ID MFA — the same protection level as the original enrollment.
🔓 How long does it take for policies to apply after I create them in Intune?
Policy sync typically takes 15–30 minutes for devices that are online and PRT-valid. You can force immediate sync: Settings → Accounts → Access Work or School → Info → Sync, or run the diagnostic script which triggers MDM sync automatically. After policy arrives, the user must sign out and sign back in to trigger the enrollment flow.

✅ Pre-Go-Live Validation Checklist

Run this validation at least 48 hours before expanding from pilot to enterprise rollout. All items must pass:

LayerValidation CheckCommand / VerificationStatus
On-Prem DCCloud Kerberos module installedGet-Module AzureADHybridAuthenticationManagement✓ Listed / ✕ Missing
On-Prem DCKerberos server registeredGet-AzureADKerberosServer | Select IsDefault, CloudDisplayName✓ IsDefault=True / ✕ Not registered
Entra IDHybrid join & PRT activedsregcmd /status | findstr "AzureAdJoined AzureAdPrt"✓ Both YES / ✕ NO on either
IntuneSettings Catalog policy assignedIntune → Devices → Configuration — verify Cloud Trust profile assigned to pilot group✓ Assigned / ✕ Missing
IntuneOMA-URI custom policy assignedCheck MDMWinsOverGP = 1 and all 4 Passport URIs exist✓ All 4 present / ✕ Missing
IntuneAccount Protection USER-scopedEndpoint Security → Account Protection — confirm Users assignment (not Devices)✓ User scope / ⚠ Device scope!
DeviceTPM 2.0 readyGet-Tpm | Select TpmPresent, TpmReady, TpmEnabled✓ All True / ✕ Any False
DeviceNo GPO conflict(Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\PassportForWork").Enabled ≠ 0✓ Not 0 or missing / ⚠ Value=0 blocks
DeviceHello container existsGet-ChildItem "HKLM:\...\{D6886603...}" -Recurse✓ Containers found / — Not enrolled yet
FunctionalOn-prem share accessSign in with PIN → try \\server\share → should open without password prompt✓ Opens cleanly / ✕ Auth dialog appears
✓ Go/No-Go Gate Only proceed to enterprise-wide rollout after: 95%+ of pilot devices pass all validation checks, 100% of file share and printer tests succeed with PIN-only authentication, and you have run the pilot for a minimum of 7 days with no helpdesk escalations.

🔗 Official Documentation References

Was this article helpful?

🎓 Ready to go deeper?

Practice real MD-102 exam questions, get AI feedback on your weak areas, and fast-track your Intune certification.

Start Free Practice → Book a Session
Souhaiel Morhag
Souhaiel Morhag
Microsoft Endpoint & Modern Workplace Engineer

Souhaiel Morhag is a Microsoft Intune and endpoint management specialist with hands-on experience deploying and securing enterprise environments across Microsoft 365. He founded MSEndpoint.com to share practical, real-world guides for IT admins navigating Microsoft technologies — and built the MSEndpoint Academy at app.msendpoint.com/academy, a dedicated learning platform for professionals preparing for the MD-102 (Microsoft 365 Endpoint Administrator) certification. Through in-depth articles and AI-powered practice exams, Souhaiel helps IT teams move faster and certify with confidence.

Related Articles

Popular on MSEndpoint