Windows Hello for Business: Pick Cloud Kerberos Trust and Move On

image

Every few weeks I get a question from an MSP engineer that starts with some version of “we’re about to roll out Windows Hello for Business — key trust or cloud trust?” My answer has been the same for a couple of years now, but the question keeps coming because the documentation is sprawling and the old hybrid PKI diagrams still haunt everyone who deployed WHfB before 2022. If you have a hybrid Active Directory and a Business Premium tenant, you should be on cloud Kerberos trust. Full stop. Everything else is legacy baggage.

The prerequisites people still miss

Microsoft’s own planning guide is the source of truth, but two prereqs catch MSPs out every time.

First, domain controllers. Cloud Kerberos trust needs Windows Server 2016 or later DCs, fully patched, and you need enough read-write DCs in every AD site where users will authenticate. If your branch office has one creaky 2012 R2 box left, the sign-in will fail in ways that look like network issues and waste a day of your life.

Second, Microsoft Entra Kerberos has to be explicitly enabled against the on-prem domain. It’s not on by default. Skip it and users will provision a PIN happily, then fail to reach on-prem file shares the first time they try. The cloud Kerberos trust deployment guide walks through enabling it.

Where to configure it

For greenfield Autopilot tenants, the fastest path is the Intune tenant-wide enrolment policy at Intune admin center → Devices → Enrolment → Windows → Windows Hello for Business. Set it to Enabled and configure the defaults there. That covers OOBE.

For everything else, build an explicit Account Protection policy at Intune admin center → Endpoint security → Account protection → Create Policy → Windows → Account protection → Windows Hello for Business. This is the one you target at device groups for staged rollout. Microsoft’s tenant-wide policy guide explains the precedence rules; read it before you layer policies.

A rollout pattern that survives contact with users

I run three rings and I don’t apologise for how boring it looks.

Ring 1: five to ten IT-adjacent devices for two weeks. You’re looking for PIN provisioning completion and on-prem resource access — not for smiles.

Ring 2: one full business unit, minimum fifty devices, two to three weeks. This is where you catch VPN quirks, smartcard reader conflicts, and the one shared PC nobody told you about.

Ring 3: the rest of the fleet, staged over a fortnight by device group, not by user.

Stage by device, not by user, because Windows Hello is a per-device-per-user credential. Chasing user groups creates a weird matrix where someone’s laptop prompts for a PIN but their desktop doesn’t, and the helpdesk gets blamed for inconsistency.

The pitfalls that burn you

Rolling back is worse than rolling forward. Disabling the policy doesn’t remove provisioned PINs; it just stops new ones. Plan the forward path before you enable it.

Don’t mix trust types. If you have leftover key trust policy from an old deployment, retire it before enabling cloud Kerberos trust on the same fleet. The hybrid key trust guide is still published, and Microsoft explicitly recommends against key trust for new deployments — pay attention to that.

Shared and kiosk devices need explicit exclusions. WHfB binds a credential to a user-device pair, which is exactly wrong for a front-desk PC logged in as five different people a day. Use Intune filters to carve those devices out of the policy.

Get the prerequisites right, pick cloud Kerberos trust, ring it, and Windows Hello becomes the quietest part of your security stack. Which is what you want.

Friction is the problem

image

Here’s the uncomfortable truth most MSPs and consultants won’t admit: the problem with sales isn’t lead volume, pricing, or even competition. It’s friction. Too many steps. Too much chasing. Too many maybes clogging up your calendar and your head.

If you’ve ever found yourself following up with someone who “just needs a bit more time”, you already know how this ends. Ghosted inbox. Awkward check‑in. Energy wasted on people who were never going to buy in the first place.

There is a simpler way to sell. Not a hack. Not a funnel with seventeen moving parts. Just a cleaner path for the right buyer to move from recognising a problem to committing to a solution.

It starts with clarity.

Make the decision easy, not emotional

Most sales calls exist because the offer isn’t clear enough on its own. When pricing, scope, outcomes, and expectations are fuzzy, people feel unsafe deciding. So they ask for a call. Or another call. Or “one last question”.

A well‑constructed offer document removes that uncertainty. It spells out exactly who it’s for, what changes, what it costs, and what happens next. The wrong people self‑select out. The right people don’t need convincing.

If someone can’t say yes after reading a clear, specific offer, they were never your client anyway.

This is how you sell without talking.

Attention beats persuasion every time

Even great offers fail when there’s no urgency. Not fake scarcity. Real focus.

When there’s no timeframe to decide, people default to delay. Not because they don’t want the outcome — but because there’s no cost to waiting. That’s not a motivation problem. It’s a prioritisation one.

A short, defined buying window forces a decision. It compresses attention. It moves the offer from the “someday” pile into the “do I act now or not at all?” category.

And here’s the key: a deadline doesn’t pressure the buyer. It respects their time. They either act, or they opt out cleanly. No limbo. No follow‑ups. No chasing.

You can run this every week if you want. Same offer. Same structure. New group of buyers. Simple, repeatable, predictable.

Demand is built before you sell

If your offer relies on clever copy to create desire, you’ve already lost. Demand doesn’t start on launch day. It’s built in advance, through relevance and trust.

This is where most MSPs get it backwards. They build services first, then hope the market catches up.

Instead, you grow an audience around a problem you understand deeply. You share insight. Opinions. Practical guidance. Over time, people stop seeing you as “a provider” and start seeing you as the obvious next step.

So when you make an offer, it doesn’t feel like selling. It feels like progression.

That’s how you scale. Not with bigger funnels or louder campaigns, but with a warmer market that’s already aligned with how you think and how you work.

Less noise. Better clients.

The goal isn’t more leads. It’s fewer, better decisions.

No hand‑holding prospects. No endless objections. No paying a percentage just to get work you could close yourself. No energy drain from people who aren’t serious.

Just a clean system that respects your time and your buyer’s autonomy.

The right people don’t need chasing. They need clarity, focus, and a reason to act.

Build that, and sales stops being something you dread — and starts being something that just works.

Intune Filters vs Assignment Groups: Stop Treating Them as Interchangeable

image

If your Intune estate has grown past a couple of hundred devices, you’ve probably built a forest of dynamic groups that only you understand. You don’t need another group. You need a filter. Here’s where each one earns its keep, and where MSPs keep getting the split wrong.

The mental model

Groups answer who the policy targets. Filters answer which subset of that assignment it actually applies to at evaluation time. A group is resolved at assignment and refreshed on Entra’s schedule. A filter is evaluated per device, per policy, at the point of applicability. That timing difference is the entire reason filters exist — and the reason swapping one for the other silently changes behaviour.

Use groups for ownership of the assignment (department, site, client tenant, pilot ring). Use filters for device traits that change underneath you: OS version, model, enrollment profile, personal vs corporate, join type.

Prerequisites people miss

  • Filters only work on managed devices and managed apps — the supported workload matrix matters. Not every policy type honours filters, and app assignment filters for MAM are a different object from device assignment filters. Check the reference before assuming your policy can be filtered.

  • Dynamic device groups require at least one Entra ID P1 licence in the tenant. Business Premium covers you, but confirm before promising dynamic membership to an M365 Standard client.

  • The “All users” and “All devices” virtual groups bypass normal targeting logic. If a client’s environment feels “haunted”, check whether a legacy assignment is hitting All devices with no filter.

Where to configure

In the Intune admin center, filters live under Tenant administration → Filters. Build the rule, pick the platform, and save — the filter itself has no targets. You apply it at assignment time on any supported policy (Devices → Configuration → your profile → Assignments → Edit filter).

Groups are managed in the same console under Groups, but remember these are Entra ID security groups — any change you make is tenant-wide, not Intune-only.

The rollout pattern that actually works

  1. Ring by group, scope by filter. Three device groups (Pilot, Early, Broad) assigned by user or device attribute. Apply the same policy to all three with different filters (e.g. deviceOwnership -eq "Corporate" plus osVersion -startsWith "10.0.22").

  2. Exclude filters beat exclusion groups. If you’re excluding kiosks from a CA-backed compliance policy, a filter keyed on enrollmentProfileName is faster to audit than a stale exclusion group nobody refreshes.

  3. Name everything for future-you. FLT-Win11-Corp-NotKiosk beats Filter1. Same for groups: prefix by purpose (INT- for Intune-only, SEC- for CA), include platform, include intent.

  4. Test in report-only. Every new filter goes onto one profile assigned to a lab group first. Confirm the Assignment status report matches expectation before widening.

The pitfalls that will bite you

  • Filter evaluation is not group membership. A filter excluding “personal” devices won’t retroactively remove a policy from a device that was previously “corporate” until the device checks in and the assignment re-evaluates. Plan for the delay during ownership changes.

  • Negation logic is deceptively literal. -notEquals treats a null property as “not equal”, so filters on sparsely populated properties (custom enrollment profile names, model on older hardware) can match devices you didn’t intend. Test with -eq plus include/exclude to lock it down.

  • Overlapping filters on the same assignment don’t AND. If you add a filter and also use include/exclude groups, precedence rules apply — exclude always wins, then filters, then includes. Map this out before complaining about “Intune not applying my policy.”

References

Experience builds ideas. Insecurity borrows them.

image

There’s a clear line between people who are doing the work and people who are just talking about it.

You don’t need a title or a following to spot the difference. You see it in how they speak, not how loudly.

People with real experience tend to build their own thinking. It’s imperfect, occasionally blunt, and often inconvenient. It comes from trying things, getting them wrong, adjusting, and doing it again. Their ideas are shaped by reality.

Everyone else tends to borrow.

They echo whatever message is trending. They swap a few words, add a diagram, and pass it off as insight. Same advice, different branding. No scars. No evidence. No ownership.

Doing the work changes your language

When you’ve actually implemented something—whether that’s a security framework, a new service offering, or AI inside a business—you stop speaking in absolutes.

You don’t say “this will change everything”.
You say “this worked here, under these conditions”.

You don’t promise miracles. You talk about trade-offs.

That shift only happens when you’ve been responsible for the outcome. When you’ve had to answer the awkward questions. When you’ve watched users ignore the thing that looked perfect in a slide deck.

That’s why experience produces original thinking. It can’t help it.

The AI gold rush has exposed the gap

AI has made this divide painfully obvious.

Right now, it’s easy to generate confident-sounding content without having touched a real deployment. Tools can produce posts, prompts, courses, and “frameworks” at scale. The barrier to publishing has collapsed.

The barrier to credibility hasn’t.

Most AI commentary falls into the same bucket:

  • Vague promises

  • Recycled examples

  • Zero mention of friction

Very little of it answers the questions businesses actually ask:

  • Why didn’t staff use it?

  • What broke when permissions were wrong?

  • Where did the time savings not appear?

  • What did we stop doing to make this work?

Those answers only come from hands-on work. You can’t fake them convincingly for long.

MSPs live or die on credibility

This matters even more for MSPs and IT pros.

Our job isn’t to repeat vendor messaging. It’s to interpret reality for customers. That means filtering hype, testing claims, and sometimes saying “not yet” or “not like that”.

The strongest MSPs I know don’t rush to publish hot takes. They pilot first. Internally. With a handful of customers. They watch what actually happens, then they form a point of view.

When they speak, it sounds different. Less polished. More grounded. More useful.

That’s not an accident. That’s earned.

Borrowing ideas is safe. Creating them isn’t.

Borrowing someone else’s thinking feels low-risk. If it doesn’t land, you can shrug and move on. You were just sharing something interesting.

Creating your own position is riskier. It invites disagreement. It exposes what you don’t know yet. It ties your name to an outcome.

But that’s also where authority comes from.

Not from being first. Not from being loudest. From being responsible.

Ask yourself the harder question

Before publishing, presenting, or advising, it’s worth pausing and asking:

Am I speaking from repetition, or from experience?

Have I tested this, or just read about it?

Would I still hold this view if the tool, platform, or trend disappeared tomorrow?

If the answer is uncomfortable, that’s probably a signal—not to stop sharing, but to go deeper. To build something. To test something. To get closer to the work.

Because in the long run, people don’t follow confidence. They follow clarity. And clarity comes from contact with reality, not from copying what’s already out there.

That’s how real ideas are formed. And that’s what makes them worth listening to.

Revisiting Copilot image generation analysis

A while back I shared the results of an identical image prompt in a number of AI tools. That article is here:

https://blog.ciaops.com/2026/03/07/image-generation-analysis/

Now that Copilot has access to OpenAI Image 2 model I thought I’d re-run and share the results.

This is the result from the previous test with Copilot chat:

image

This is the updated response using the identical prompt as before with Copilot Chat again:

image

This is the same prompt with Copilot Chat again BUT with ‘Create a detailed infographic using the new openAI image 2 model’ added at the beginning of the prompt:

image

This is the original prompt but used in the dedicated ‘Create Image’ part of Copilot:

 image

Still not perfect if you examine each closely but a significant improvement from the last round.

BitLocker Silent Enablement via Intune: The Deployment Pattern That Actually Sticks

image

Every MSP ends up doing BitLocker. Very few do it silently on the first attempt. Between TPM quirks, third-party encryption leftovers, and the three different Intune policy surfaces that all claim to configure BitLocker, the difference between “encrypted fleet with recoverable keys” and “2am call from a locked-out CEO” is a handful of settings. Here’s the pattern to deploy in production under Microsoft 365 Business Premium.

Prerequisites people skip

Silent means standard user, no prompts, no elevation — which is a higher bar than “BitLocker on.”

  • TPM 2.0, ready state, UEFI, Secure Boot on. If the TPM reports “not ready” or is owned by a prior OEM image, silent encryption aborts. Check with Get-Tpm before blaming policy.

  • Entra joined or Hybrid joined. Workgroup and AD-only devices have no key escrow target and will not silently encrypt.

  • No third-party encryption agent. McAfee DE, Sophos SafeGuard, legacy Dell Data Protection — all block BitLocker takeover until fully decrypted and uninstalled.

  • No startup PIN or startup key requirement. Silent mode and pre-boot authentication are mutually exclusive. Pick one.

  • WinRE present and healthy. BitLocker uses it for recovery.

If any of those are wrong, don’t touch policy yet. Fix the device first.

Where to configure it

Ignore the Settings Catalog for this one. Microsoft is explicit that the Settings Catalog does not expose the TPM startup authentication controls silent enablement depends on (docs).

Use the Endpoint security path:

Intune admin center → Endpoint security → Disk encryption → Create Policy → Platform: Windows → Profile: BitLocker.

The settings that actually matter for silent:

  • Enable full disk encryption for OS and fixed data drives: Yes
  • Hide prompt about third-party encryption: Yes
  • Allow standard users to enable encryption during Autopilot: Yes
  • Require device to back up recovery information to Azure AD: Yes (gates encryption on successful escrow — this is the setting that saves you)

  • Recovery password rotation: Enable on Entra and Hybrid-joined devices
  • OS and fixed drive: XTS-AES 256, TPM-only protector, no PIN

Full setting reference: Disk encryption profile settings.

The rollout pattern

Do not target All Devices. Ever.

  1. Pilot ring (5–10 devices): your own, one per client hardware family. Watch the Endpoint security → Disk encryption report for “Encrypted” status and a recovery key present in Entra. If the key isn’t there, the device isn’t safe, regardless of what Windows says.

  2. Early ring (10–20% by dynamic group): let this soak for a week. Check the encryption report daily. Anything stuck in “Waiting for response” usually means TPM readiness or a WinRE issue — remediate per device, don’t loosen policy.

  3. Broad rollout: remaining corporate devices via a dynamic group filtered on deviceOwnership eq "Company". Never include BYO.

  4. New builds: bake the policy into Autopilot so encryption completes during ESP. Standard-user silent enablement only works if “Allow standard users to enable encryption during Autopilot” is Yes — double-check before you cut a new image.

The help desk also needs the recovery-key retrieval flow documented before you go broad, not after the first lockout.

The pitfalls that bite

  • Silent and startup PIN are incompatible. If compliance demands pre-boot auth, you’re running standard BitLocker, not silent. Decide once.

  • Recovery key escrow failures hide in plain sight. Without “Require device to back up recovery information to Azure AD = Yes”, devices encrypt, keys never land in Entra, and you discover it the day a laptop gets stolen. Audit the encryption report monthly — the ground truth is “Recovery key: Yes/No” per device, not policy compliance.

  • Don’t mix endpoint protection + disk encryption profiles targeting the same devices. Conflicts resolve unpredictably. Pick the Disk encryption profile and delete the legacy Endpoint protection one (policy comparison).

Get those three right and BitLocker becomes a checkbox — exactly what your clients are paying for.

Progress Is Quiet. That Doesn’t Mean It Isn’t Working.

image

One of the hardest things to accept in business—and in life—is that real progress is mostly invisible.

We’re conditioned to look for obvious signals. Big wins. Public milestones. Announcements, launches, applause. If none of that is happening, it’s easy to assume we’re stuck. Or worse, going backwards.

But that’s not how meaningful progress actually works.

Every problem you solved before it became a crisis.
Every decision you didn’t rush just to feel productive.
Every shiny “opportunity” you said no to because it wasn’t aligned.

That’s progress. Quiet progress. The kind that happens in the background while no one is watching.

In MSPs and IT businesses, this shows up all the time. You harden security instead of chasing a new tool. You standardise processes instead of custom‑building for every client. You invest time learning Copilot properly instead of posting another “AI will replace us” hot take on LinkedIn.

None of that feels exciting in the moment. It feels slow. Boring, even. And because there’s no immediate payoff, the temptation is to assume those are “lost days”.

They’re not.

Those slow days are doing the heavy lifting. They’re building the foundation that lets everything else scale later—reliably, profitably, and without burning you out.

The problem is that we often misdiagnose what’s missing. We assume we need a better routine. A new framework. A clever hack. Another app, another system, another morning ritual.

Most of the time, that’s not the issue.

The issue is trust.

Trust that the work you’re doing—when it’s deliberate and aligned—actually compounds. Trust that saying no is as powerful as saying yes. Trust that progress doesn’t need to announce itself to be real.

This is especially true with long‑term capability building. Training staff properly. Improving documentation. Fixing fundamentals. Learning how to use tools like Microsoft Copilot effectively instead of dabbling and moving on.

There’s no dopamine hit for that. No instant validation. Just steady, unglamorous effort.

But it adds up.

And one day, usually without warning, things feel easier. Decisions get clearer. Results come faster. Other people start calling it “overnight success”.

It wasn’t overnight. You just did the work when no one was clapping.

So if today feels slow, that doesn’t mean it’s wasted. If it feels like you’re laying bricks instead of building towers, that’s exactly how it’s supposed to feel.

You don’t need to overhaul everything.
You don’t need a new system.
You don’t need to panic‑pivot.

You just need to keep going.

Trust the work. It’s adding up—even when you can’t see it yet.

CIAOPS Need to Know Microsoft 365 Webinar – May

laptop-eyes-technology-computer_thumb

Now in our tenth year!

Join me for the free monthly CIAOPS Need to Know webinar. Along with all the Microsoft Cloud news we’ll be taking a look at Copilot Cowork.

Shortly after registering you should receive an automated email from Microsoft Teams confirming your registration, including all the event details as well as a calendar invite.

You can register for the regular monthly webinar here:

May Registrations

(If you are having issues with the above link copy and paste – https://bit.ly/n2k2605 )

The details are:

CIAOPS Need to Know Webinar – May 2026
Friday 29th of May 2026
11.00am – 12.00am Sydney Time

All sessions are recorded and posted to the CIAOPS Youtube channel.

Also feel free at any stage to email me directly via director@ciaops.com with your webinar topic suggestions.

I’d also appreciate you sharing information about this webinar with anyone you feel may benefit from the session and I look forward to seeing you there.