u/Fabulous_Cow_4714

Autopatch is enabled in the tenant and devices are Windows 11 Enterprise. Devices ate hybrid joined and enrolled in Intune comanagement,

However, the autopatch readiness reports say Device diagnostic data not received for every device.

Documentation says set telemetry to “required,” but there is no such option in the settings catalog.

It has basic, security, or full. It’s set as basic .

Telemetry is also enabled at the tenant level. Windows data enablement is on.

Still nothing is working. What else is needed?

Do you have to assign devices to Autopatch groups before you even collect the readiness reports?

At the moment, all we want to do is collect data on status and readiness without using Autopatch to deploy anything.

Are Cisco VPN, WLAN controllers, and general routing and switching hardware used in office environments expected to support ML-DSA certificates within the next year?

When I try to look this up, I get results talking about cross tenant collaboration settings.

I know it doesn’t require all that because I can send encrypted messages to an external test tenant that has no connection to ours and they can read the encrypted messages from their own Outlook Web Access pages with no collaboration settings required.

However, when we send encrypted messages to a specific tenant that has very locked down network access that only allows access to specific IP ranges, when users from that tenant click the Read Message link in OWA and either sign in as their work account or enter the OTP code, they get an error stating something went wrong and your encrypted message couldn’t be opened.

They want us to tell them specifically what minimum IPs and URLS they need to allow be able to read Purview encrypted messages from outside tenants.

Aren’t the Windows desktop apps supposed to display a banner integrated in the apps like Outlook and Word when updates are due to be installed?

Instead, they only see a white popup Window on the screen with a 29 minute countdown to postpone only once for 2 hours before it automatically closes apps and installs the update.

We still need to enforce updates installation, but we need users to have a longer warning period so that they can at least postpone until the end of the day, if not until the next day.

Is there a configuration policy we can deploy to change this user experience?

I started another thread going down the path of using RSA and ECDSA ECC to handle a mixed environment.

https://www.reddit.com/r/PKI/comments/1t2r348/comment/olr2cgu/

However, now I see both RSA and ECDSA are on the path to deprecation in only 4 years.

Wouldn‘t it make more sense to use RSA and ML-KEM ML-DSA together instead?

If you need legacy compatibility, RSA has more compatibility than ECDSA, and if you want future-proofing ML-KEM/DSAC has a better future than ECDSA.

So, would you be better off not even getting involved with ECDSA at this point?

I thought ECDSA was safe from deprecation, but I just read that both RSA and ECDSA deprecation start deprecation in 2030 and become invalid in 2035.

If you are starting a new ADCS PKI now in an environment that also needs legacy backwards compatibility, what can you use today that won’t need to be replaced in 2030?

Just use RSA for now to ensure maximum compatibility and then change over to a new algorithm in 2029?

There is nothing that has legacy compatibility and isn’t also quantum-vulnerable?

If you are moving to a new PKI, what benefit do you get from cross signing during the transition vs just pushing a trust of the new root CA via group policy alongside the existing and simply stop issuing any new certificates from the old PKI and start issuing new certificates from the new PKI?

Wouldn’t the old CAs need to stay running simply to publish CRL updates until the last issued certificate expires even if we stopped issuing new certificates from them regardless or cross signing?

I’m not getting what we would get out of cross signing.

The tenant doesn’t have cloud update available. So, we must use a configuration policy to manage Office updates.

We set up different rings with different deferral policies plus deadlines.

An issue we are seeing is that once the automatic update triggers, it only gives the user a maximum of 2 hours to postpone installing.

First and only warning message says “Last chance to postpone the installation for 2 hours.”

Is there a setting to allow postponing longer than 2 hours or else postpone for 2 hours more than once?

The deadline is set for 1 day. I expected that to give them 24 hours to postpone installing instead of 2 hours.

We are considering deploying smart cards for use cases not supported by Windows Hello or FIDO2. However, we are wondering if that would require deployment of the additional overhead and points of failure of OCSP responder servers.

We can revoke the smart card and publish a new CRL, but devices may not check for the update for at least a day.

Is there any other rapid way to block use of a compromised smart card other than disabling or deleting the account? For instance, can the smart card be manually unmapped from a user account so that it loses the user’s access even if the certificate revocation is not yet recognized due to local CRL caching on devices?

Is

Has anyone found an Intune configuration that can be used to centrally disable this feature?

All I found were steps to turn it off manually in each browser’s settings. This will not scale.

https://support.google.com/chrome/thread/431301652/google-automatically-downloading-some-ai-model-called-optguideondevicemodel-to-my-computer?hl=en

No users allowed or all users allowed works, but if you try to choose specific users to allow, we cannot type into the search box and the scroll box has a limit. I can even get to end of the A users.

Looks like a bug. Already tried other browsers and computers.

Is there a solution?

Is there a report we can run on existing 23H2 systems that would be able to detect why certain systems will not upgrade past 23H2 without failing and reverting changes?

Apparently, 24H2 and 25H2 have certain requirements that 23H2 doesn’t, but it isn’t clear what that is.

It isn‘t the hardware because we can install a clean image of 24H2, but not upgrade from 23 to 24 or 25 on these systems.

Whats recommended for the offline root, issuing intermediate CAs, and end entities that maximizes security without breaking legacy device and app compatibility?

I have seen EDCSA recommended over RSA, but won’t that break functionality in any environment that needs to maintain legacy compatibility?

You generally should exclude break glass accounts from conditional access policies, but you need some to prevent someone discovering the password and then registering a rogue device for MFA.

Shouldn’t you have some restrictions such as strictly requiring phishing resistant MFA for login and having location restrictions for registering new authentication methods?

Looking for a way to remove it from Excel, Word, etc. across all devices.

I know everything modern has been supporting 4096-bit keys for many years.

Can anyone name any widely used legacy processes enterprise environments might still have in place in 2026 that would break if the internal root CA switched from 2048 to 4096?

Everything just says no items found.

We have a now dormant subdomain that at one point had high volume traffic for email and needed a third party bulk mail service to handle.

The subdomain will now be used for a new service that will never approach the daily sending limits of Exchange Online. Max number of emails in a day will average in the hundreds.

DNS records still point to the old email provider.

So, we want to migrate it into our Office 365 tenant now,

I know that the accepted domain wizard is supposed to give you DNS values to post to your DNS provider while you are in the process of setting it up.

I assume we don’t need to get a random TXT record to prove domain ownership since this is just a subdomain of an already accepted domain.

Is it possible to anticipate all the DNS record values we will need for MX, SPF, autodiscover, DKIM, and DMARC and prepopulate all the DNS records days ahead of time so that everything will just work immediately after adding the accepted domain in Exchange Online and not have to wait around for DNS propagation for testing emailing from the subdomain?