Onboarding My Personal PC Into My Own Tenant: Intune, Defender, and RoboShadow

Why I Did This

Two reasons, both honest.

First, I wanted a real dogfooding box. Most of the work I do at the MSP touches Intune, Conditional Access, Defender for Business, and BYOD enrollment — and the cleanest way to get faster at that work is to break things on a machine I own before I touch anything client-side. A managed personal PC inside my own ValorWorks tenant means I can write a CA policy, push a compliance baseline, test ASR rules in audit mode, and validate enrollment flows without ever having to schedule a client maintenance window.

Second, my personal desktop genuinely needed the security upgrade. It had Microsoft Defender Antivirus, sure, but no EDR telemetry, no compliance enforcement, and no tenant-level visibility. Anything that ran on it ran outside the radar of the tenant where most of my actual work lives. Pulling it into ValorWorks fixes that.

This post is the full walkthrough of how that went, including the steps where things didn't go cleanly. There were a few of those.

Step 1: Win 11 Home Doesn't Cut It

The first wall I hit was licensing. My desktop was running Windows 11 Home, and Microsoft Defender for Endpoint (and by extension Defender for Business) is supported only on Windows 10/11 Pro, Enterprise, Education, and Pro Education. Home is excluded from the supported SKU list.

I could have gone hunting for a cheap key on the gray market, but as someone who runs a vulnerability assessment program for a customer, using a sketchy reseller key on a machine that's about to hold tenant credentials and EDR telemetry is exactly the kind of small integrity issue I'd never let one of my clients get away with. So I bit the bullet and bought a Pro upgrade through the Microsoft Store for $99. In-place upgrade, one reboot, done in about ten minutes.

Pro also unlocks a stack of things I actually want for a lab box: Hyper-V, BitLocker, Group Policy Editor, Windows Sandbox, Entra Join, and the broader Intune CSP surface. Worth more than $99 just for those, honestly.

Step 2: Cleaning Up Old Tenant Registrations

Before joining the machine to ValorWorks, I needed to make sure no other tenant had a foothold on it. Running dsregcmd /status as admin from PowerShell showed two surprises.

The User State section listed WorkAccountCount: 2 and WorkplaceJoined: YES. Two stale Workplace Joins from previous jobs were still on the machine — including a device certificate sitting in the TPM with a 10-year validity that another company's tenant would have been able to use to identify the machine until 2032 if I'd left it alone.

Cleanup process for stale Workplace Joins:

1. Settings → Accounts → Access work or school → click each stale entry → Disconnect
2. Reboot
3. Re-run dsregcmd /status and confirm WorkAccountCount: 0 and WorkplaceJoined: NO

If a registration doesn't disconnect cleanly through Settings, the manual cleanup is to delete the device cert from certmgr.msc (current user store, look for issuer MS-Organization-Access), clear the related entries under HKCU\Software\Microsoft\Windows NT\CurrentVersion\WorkplaceJoin, and check the Workplace Join scheduled tasks under Task Scheduler. I didn't need to go that far this time, but it's good to know.

Step 3: Tenant-Side Prep (Don't Skip This)

Two tenant-side settings have to be in place before the Entra Join, otherwise auto-enrollment into Intune silently no-ops and you get an Entra-joined device with no MDM management:

1. Intune license assigned to the user account. Microsoft 365 admin center → Users → your account → Licenses and apps. ValorWorks runs on Business Premium, which includes Intune Plan 1, so the license existed at the tenant level — but it still has to be assigned to the user.
2. MDM auto-enrollment scope. Entra admin center → search for "Mobility (MDM and MAM)" → click Microsoft Intune → set MDM user scope to All (or a group containing your user). Leave the three default URLs as-is. Save.

Default state on a fresh tenant is None for the MDM user scope, which is the most common reason an Entra Join doesn't trigger Intune enrollment.

Step 4: The Actual Entra Join

This is the step Microsoft hides behind a small link that's easy to miss. From the desktop:

1. Settings → Accounts → Access work or school → Connect
2. In the dialog that appears, do not type your email at the top. That field starts a Workplace Join, not an Entra Join.
3. Look at the bottom of the dialog for the small link: "Join this device to Microsoft Entra ID" (sometimes shown under "Alternate actions").
4. Enter your tenant credentials, confirm the org name, accept the reboot prompt.
5. After reboot, sign in with the tenant account.

To verify it took correctly, run dsregcmd /status again. You're looking for:

AzureAdJoined : YES
DomainJoined  : NO
TenantName    : ValorWorks
MdmUrl        : https://...manage.microsoft.com/...

The populated MdmUrl is the critical piece — that's what tells you Intune auto-enrollment fired during the join. If it's blank, the tenant-side MDM scope wasn't set when the join happened, and you'd need to either disconnect/rejoin or manually enroll through Settings.

Within about 15 minutes the machine showed up in the Intune admin center under Devices → All devices, marked Compliant, with the correct primary user and Intune as the management authority. Auto-enrollment worked exactly as designed.

Step 5: Migrating My Existing Profile (The Headache Section)

This is where things got interesting. My desktop had been running for a while as a personal Microsoft Account profile — all my files, app configs, browser data, and PowerShell profile were under C:\Users\Dilla\. Signing in fresh as the ValorWorks account would create a brand-new empty profile sitting next to the personal one. That's not what I wanted.

The right tool for this is ForensiT User Profile Wizard (Profwiz). It rewrites the ACLs on an existing profile to a new account's SID — same files, same configs, just owned by the new identity. The freeware edition is fine for a single migration.

Two specific gotchas hit me along the way that are worth flagging.

Gotcha #1: The "Azure ID file" Requirement

Profwiz Freeware doesn't query Entra directly to resolve account names to SIDs. It expects a ForensiTAzureID.xml file sitting next to Profwiz.exe, and it errors out with "Azure ID file not found" if the file isn't there.

ForensiT publishes a PowerShell script (Save-AzureADUser.ps1) on their GitHub to generate the file. The script uses the Microsoft.Graph PowerShell module and prompts for interactive auth.

I ran the script and it produced an XML file. But Profwiz still threw the error. The file was technically there, but empty:

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type='text/xsl' href='style.xsl'?>
<ForensiTAzureID ObjectId="" Name="" DisplayName="" />

The Microsoft.Graph module's Connect-MgGraph step had failed silently (likely because the admin consent prompt for the requested scopes either didn't trigger or got dismissed), and the script wrote an empty stub. The empty stub is misleading — it implies the file format is one root element with all values as attributes, when the actual schema Profwiz expects is a tenant-level root with a child <User> element containing the user's UPN, Object ID, and display name.

Gotcha #2: The XML Schema Profwiz Actually Expects

For a single-user tenant like mine, hand-crafting the XML is faster than debugging the Graph auth flow. The correct format:

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type='text/xsl' href='style.xsl'?>
<ForensiTAzureID ObjectId="<TENANT-ID>" Name="yourdomain.dev" DisplayName="YourTenant">
  <User>
    <UserPrincipalName>[email protected]</UserPrincipalName>
    <ObjectId><USER-OBJECT-ID></ObjectId>
    <DisplayName>Your Name</DisplayName>
  </User>
</ForensiTAzureID>

The root element's attributes describe the tenant (Tenant ID, primary verified domain, tenant display name). The <User> child element contains the user's data with values as nested elements, not attributes. Both pieces of info you need are in the Entra admin center → Overview page (tenant info) and Users → your account (user info).

Once the XML was correct, Profwiz parsed it cleanly. The migration itself took about three minutes — the Setting Profile ACL step is the longest phase because it recurses through the entire profile tree rewriting NTFS permissions on every file.

Gotcha #3: The TPM/NGC Container Error on First Sign-In

After the migration completed and I rebooted, the first sign-in as the ValorWorks account threw a Microsoft "Device TPM problem" dialog with error code -2146893813 (hex 0x8009000B, which decodes to NTE_BAD_KEY_STATE): "Key not valid for use in specified state."

This is a documented and predictable side effect of profile SID migration on Entra-joined devices that already had Windows Hello provisioned. The NGC (Next Generation Credential) container, which stores Hello PINs and biometrics and is bound to TPM keys plus the original user SID, gets orphaned by the migration. The new identity tries to use the container, sees keys provisioned for a different security context, and Windows surfaces the TPM error.

The dialog is alarming but it's not blocking sign-in itself — it's blocking Hello provisioning. Hitting Retry typically lets Windows self-heal by re-prompting for PIN setup against the new SID. That worked in my case. If Retry hadn't worked, the documented Microsoft remediation is to clear the Hello container manually:

certutil.exe -deleteHelloContainer

Then sign out and sign back in to provision Hello fresh.

This is worth knowing for client work. Any time you migrate a user profile to a new identity on a TPM-backed Hello-enabled machine, plan to clear the Hello container post-migration. ForensiT's docs mention it briefly, but it really should be a step in their wizard.

Step 6: Onboarding to Microsoft Defender for Business

One thing that's easy to miss with Business Premium licensing: it includes Defender for Business (MDB), not the full Defender for Endpoint (MDE) Plan 1 or 2. MDB is the SMB-tier variant — same agent, same telemetry pipeline, same Defender XDR portal — but with a simplified policy experience and a 300-user cap. For an MSP whose clients are mostly on BP, this is exactly the product to be hands-on with.

The onboarding flow at security.microsoft.com is straightforward once the tenant is provisioned (which can take 30–60 minutes the first time you visit the Defender portal):

1. Defender portal → Settings → Endpoints → Onboarding
2. OS dropdown → Windows 10 and 11
3. Connectivity type → Streamlined (newer endpoint set, fewer URLs to allowlist on a firewall — this is the option you'd want for client deployments too)
4. Deployment method → Local Script (for up to 10 devices)
5. Download the onboarding package zip (it contains a .cmd file with your tenant ID and an enrollment token baked in — don't share or commit this)
6. Extract somewhere writable, open Command Prompt as Administrator (not PowerShell — the script uses cmd syntax), and run the WindowsDefenderATPLocalOnboardingScript.cmd file
7. Confirm Y when it prompts

The script writes registry keys under HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection and starts the Sense service, which is the actual Defender for Endpoint agent process (MsSense.exe). Verify with:

Get-Service Sense | Select-Object Name, Status, StartType
# Expect: Running, Automatic

Get-MpComputerStatus | Select-Object AMRunningMode, AntivirusEnabled, RealTimeProtectionEnabled
# Expect: Normal, True, True

If AMRunningMode shows "Passive" or "EDR Block Mode," that means a third-party AV is installed and Defender stepped down. On a clean Pro install with no other AV, expect Normal mode.

Then you run the official MDB detection test from an admin command prompt — it makes a benign HTTP call that the agent recognizes as a test pattern, generating a low-severity event in the portal so you can confirm telemetry is flowing. Within ~10 minutes the device shows up in the Defender portal under Assets → Devices, and the test detection appears on the device timeline.

For client work the local-script approach doesn't scale. The pattern there is to use Intune's Endpoint security → Endpoint detection and response policy with the "Auto from connector" setting, which uses the Intune ↔ Defender connector to onboard devices silently across an entire group. For a single-engineer-managed personal tenant, both approaches are fine — and doing the script once is good experience to have before you set up the Intune-managed version.

Step 7: Adding RoboShadow Into the Mix

With Defender for Business handling AV/EDR, I layered RoboShadow on top for vulnerability management and attack surface visibility. I'd be doing this section a disservice if I didn't talk about RoboShadow properly, because it's one of those rare tools that genuinely punches above its weight class — and most of what it does is free.

What RoboShadow Actually Is

RoboShadow is a unified cyber platform that combines external attack surface management, internal vulnerability scanning, device posture monitoring, and (on the premium tier) automated remediation. Under the hood it's running NMAP, Shodan, and OWASP-style web vulnerability checks on the external side, plus an agent-based scanner on the internal side that inventories software, tracks CVEs, and reports on Zero Trust posture. The whole thing rolls up into a single dashboard with daily automated scans and reporting suitable for compliance evidence.

The thing that genuinely sets RoboShadow apart, and the reason I support what they're doing, is their free tier. They market it as the "World's Best Cyber Free Tier" and they're not exaggerating — about 90% of platform features are available at no cost, including vulnerability reporting, the agent, the LAN scanner, and external scanning. For an individual, a homelab, a small business, or even a small MSP just getting started with cyber service offerings, that's a remarkable amount of capability to put behind a free signup.

The Capability Set

Across the platform, here's what you actually get. Most of these are in the free tier; I've called out the premium-only ones explicitly.

Why This Matters For My Use Case

I run a quarterly vulnerability assessment program for one of our largest customers, and the bulk of that work is in two places: identifying what's vulnerable and tracking remediation through to closure. RoboShadow does the first half automatically, daily, and presents it in a format that's understandable to non-technical stakeholders. The reports are clean enough to drop into a customer-facing deliverable, which is a meaningful time savings on its own.

Beyond customer work, having it on my personal box gives me visibility into my own attack surface — every piece of software installed, every CVE associated with what's running, the patch posture of the OS, the state of Defender. That's hard to replicate with native Windows tooling alone, and it's a useful feedback loop for someone learning detection engineering and security operations on the side.

For anyone reading this who runs a homelab, freelances in IT, or works at a small MSP that's trying to start a cyber service line: their free tier is worth the 60 seconds it takes to sign up. It's the kind of platform where you discover things about your own environment that you didn't know to ask about, which is exactly what a good vulnerability tool should do.

Defender + RoboShadow Coexistence

Two agents on the same machine. The good news is that they shouldn't directly conflict — RoboShadow isn't an antivirus, so Defender doesn't drop into passive mode. They live in different layers entirely. But they do touch some of the same telemetry surfaces in ways worth being aware of, especially for client deployments.

Quick verification commands after both agents are installed:

# Confirm both agent services are running
Get-Service | Where-Object { $_.DisplayName -like "*RoboShadow*" }

# Check Defender's quarantine for anything related to the vuln scanner
Get-MpThreatDetection | Where-Object { $_.Resources -like "*RoboShadow*" }
# Should return nothing

# Review Defender's exclusion list to know your baseline
Get-MpPreference | Select-Object ExclusionPath, ExclusionProcess, ExclusionExtension

Then check both portals for last check-in timestamps. The Defender portal should show the device active and healthy; the RoboShadow portal should show it checking in within the last few hours and surfacing whatever vulnerabilities it's already found in the software inventory.

On my box, the first scan turned up things I'd genuinely forgotten were installed and a couple of CVEs on apps I hadn't realized were behind on patches. That's the value proposition in a single sentence: it tells you what you didn't know about your own environment.

What This Stack Actually Provides

By the end of the night, the machine had:

• Endpoint membership in my ValorWorks tenant via Entra Join, surfaced in the Entra device inventory and eligible for Conditional Access enforcement
• Mobile device management through Intune, ready to receive compliance policies, configuration profiles, and security baselines
• Behavioral EDR through Microsoft Defender for Business, with telemetry feeding into Defender XDR and integration with Advanced Hunting queries
• Next-generation antivirus through Microsoft Defender Antivirus in active mode, managed by tenant policy
• Tamper protection on the Defender agent, preventing local processes from disabling protection
• Vulnerability management through RoboShadow, with agent-based scanning, CVE tracking, and remediation guidance
• Tenant-side observability — every relevant telemetry source flows back to portals I administer, instead of running blind on a personal machine

The bigger value, though, is that this is now a real lab. The next time I need to validate a Conditional Access policy that requires a compliant device, I can scope it to my own user, watch what happens to my own machine, and iterate without ever putting a customer at risk. The same goes for ASR rule tuning, app protection policies, baseline hardening profiles, and any other tenant-side change I'd otherwise be testing in production.

Lessons Learned

Workplace Join and Entra Join are not the same thing, and Microsoft makes this confusing on purpose. Always run dsregcmd /status after any "join" action and verify AzureAdJoined : YES. If it says NO but WorkplaceJoined : YES, you did the wrong action.

Auto-enrollment into Intune requires three things, all in alignment. An Intune-bearing license assigned to the user, MDM user scope set to All (or a group the user is in), and the device joining after both of those are configured. If any one of them isn't true at join time, the device joins Entra cleanly but doesn't enroll into Intune.

Profile migration on Hello-enabled machines breaks the NGC container, and that's expected. Plan for the TPM error on first sign-in. Hit Retry first; if that doesn't work, certutil -deleteHelloContainer from an elevated session is the documented remediation.

Stale Workplace Joins from previous employers are a real OPSEC issue. A device cert in your TPM with a 10-year validity, registered against a tenant you no longer work for, is dormant but exists. Clean these up before you do anything else with a personal machine.

Vuln scanner + EDR coexistence needs validation, not assumption. Watch alert flow for at least a week before enabling ASR rules in block mode. Use vendor-published exclusion guidance, not generic broad excludes. Document what you observe — that documentation is reusable when you propose the same stack to a client.

For a personal lab box, the local-script onboarding for MDB/MDE is the fastest path. For client deployments, use the Intune-based onboarding through the Defender connector. Doing both at least once is good experience.

Conclusion

This was one of those projects where the headline goal — "get my personal PC into Intune" — was about 20% of the actual work, and the rest was small details that compound into a real walkthrough. Win 11 Home not being supported, stale workplace registrations from old employers, the Workplace Join vs Entra Join trap, ForensiT's empty-XML stub, the TPM/NGC mismatch on first sign-in, the connectivity nuances between Defender and a vuln scanner. Each one is a small thing on its own. Taken together, they're the difference between a five-minute task and an entire evening.

What I have at the end of it is something I'll use almost every week going forward — a managed personal endpoint that mirrors what most of my clients run, where I can validate every tenant-side change against a real machine before it touches anything I'm responsible for in production. That's worth the late night.

Next on the list: writing the first compliance policy in Intune, getting BitLocker enforced through tenant policy rather than locally, and pushing ASR rules in audit mode to see what surfaces against my actual workload.