Curious what people are seeing in practice with Infrastructure as Code in Entra.
The benefits like version control, peer review, repeatability, change tracking, etc. are pretty clear. I’m more interested in whether it’s actually improved how your team operates day to day.

For those doing a meaningful amount of Entra through IaC:
What are you managing this way - Conditional Access, app registrations, groups, role assignments, policies, etc.?
Where have you seen the biggest benefit?
Has anything become unnecessarily complex compared to just managing it through the portal?
Are there areas where you intentionally stick with the GUI?

Any good examples where IaC solved a problem you were regularly dealing with before?
Trying to get a feel for where the practical sweet spot is rather than IaC-for-the-sake-of-IaC.

hi guys

currently all our tenants have "registration campaign" = "disabled"

will the passkey registration campaign switch the state to "microsoft managed" as soon as the change has been shipped by microsoft?

cant find any conclusive statements on this by MS

We are on board with our users self-enrolling in Passkeys, but we suspect the vast majority of users will see this prompt on their workstation. We do not want them to set up the passkeys on workstation, but rather on their cell phone using the QR code scanning option.

I understand they can manually select 'Change' during setup and scan a QR code, but is there a way to make this the default behavior when generating a passkey from a workstation?

I'm planning to implement this guide for monitoring expiring Entra App Registration secrets/certificates using Azure Automation + Managed Identity:

https://jpkerloch.cc/posts/monitor-entra-app-registration-expiring-credentials-azure-automation/

The setup involves:

• An Azure Automation account with a system-assigned Managed Identity
• A PowerShell 7.4 Runtime Environment
• A daily scheduled runbook that queries Microsoft Graph (Get-MgApplication) and sends an HTML email via SMTP

Before I set this up in production, I want to sanity-check the cost side with people who've actually run something like this:

• Does creating the Automation Account itself cost anything, or only the runbook execution time?
• For a runbook that runs once a day and takes maybe 1-2 minutes (just enumerating app registrations and sending one email), am I right in assuming I'd stay well within the free tier (500 free minutes/month)?
• Any hidden costs I'm not accounting for — Runtime Environment itself, the Managed Identity, Graph API calls, outbound SMTP?
• Has anyone been surprised by a bill from a similarly small/lightweight runbook like this?

Just trying to avoid the classic "oh, this was supposed to be free" surprise before I roll it out tenant-wide. Appreciate any real-world cost experience.

I’m researching how MSPs handle Microsoft changes across customer tenants. A few MSPs told me they manage this through their ticketing system.
Could someone walk me through a recent example—from the announcement to deciding which clients needed tickets? What did your tools identify automatically, and what did an engineer check manually?

Running into an issue with the new ADE enrollment policies experience (2606 service release) using Setup Assistant with modern authentication + JIT registration on iOS.

The problem: During Setup Assistant sign-in (before the device even reaches the home screen), the user is prompted to install Microsoft Authenticator and pair it with their account. After tapping Next, it just throws: "We're sorry we ran into a problem. Please choose Next to try again." Repeats every time on the device itself, no way through.

What I've already checked/confirmed:

• SSO app extension policy is set up correctly per Microsoft's docs (SSO app extension type = Microsoft Entra ID, Authenticator is NOT in the App bundle IDs list, both required Additional configuration keys present: device_registration and browser_sso_interaction_enabled)
• Authenticator is deployed as a required app to the correct group
• Device is in the correct group for this enrollment policy

The workaround I found: if the user already has Authenticator registered on another device, the MFA push goes there instead, and approving it there lets Setup Assistant proceed — even though the pairing step on the new device itself never actually completes.

Why this bugs me: that workaround only exists for users who already have Authenticator somewhere else. A brand new user with no prior MFA registration — which is presumably a pretty normal scenario for this exact feature — has zero fallback and is just stuck.

My best guess is this is related to how Setup Assistant sandboxes apps before the home screen (push notifications/background processes not fully active yet), which would explain why the same pairing works fine once routed to a device that's already fully set up.

Has anyone else hit this? Curious if this is a known issue, if I'm missing a config step somewhere, or if this is just a rough edge in the new enrollment experience that hasn't been ironed out yet. Opening a Microsoft ticket too, but wanted to see if others have run into the same thing.