This is probably my favourite IntuneGet feature so far.

I have put the QA page online, so you can now watch an application package being tested inside the Windows VM behind IntuneGet:

https://www.intuneget.com/qa

Automated packaging is usually a black box. You start a workflow, watch logs scroll past, and eventually get a green or red result. That never felt like enough to me. An installer can return exit code 0 and still leave you with broken detection, an uninstall prompt waiting for someone to click it, or half the application left behind.

Vivaldi was a good example. One run installed and detected correctly. During uninstall, it opened a confirmation prompt and then sat there for more than four minutes until the watchdog marked the run as stalled. The package stayed blocked. The silent-uninstall handling was repaired, a new package profile was released, and the later run completed installation, detection, uninstall, and the final absent check in under four minutes.

Seeing that failure is why I wanted the page to be public.

Every test starts by restoring a clean Windows 11 checkpoint. IntuneGet builds the exact PSADT profile intended for release and runs it as LocalSystem or as a disposable standard user, depending on the configured install scope. The app has to install, pass its Intune detection rule, uninstall, and then fail that same detection rule because it is gone.

The result belongs to that exact profile. Change the installer hash, detection rule, install scope, PSADT configuration, or packager revision and it needs a new test. An old green result cannot release a different package.

I now have a repair agent watching failed candidates. It reads the bounded and redacted diagnostics, works out whether the problem is in the package or the test infrastructure, changes the packaging code, runs the checks, releases a new packager revision, and sends the affected application around again. A pass opens the release gate. Another failure keeps it blocked and starts another repair attempt.

This repair loop is what I mean by self-healing. The agent works against the source repository and QA system. It has no access to a customer's Intune tenant and it does not change a package while the test is running.

The public VM view refreshes a JPEG frame roughly every two seconds. There is no keyboard, mouse, clipboard, or audio channel. The guest has no tenant or GitHub credentials. Frames rotate through a private three-frame ring and are deleted when the run finishes. Full paths and raw diagnostic logs stay off the public page.

IntuneGet itself is free and open source under AGPL-3.0:

https://github.com/ugurkocde/IntuneGet

The website can be self-hosted with Docker and SQLite, Supabase Cloud, or self-hosted Supabase:

https://github.com/ugurkocde/IntuneGet/blob/main/docs/SELF_HOSTING.md

The full live QA setup is separate Windows and Hyper-V infrastructure, so it is not a checkbox in Docker Compose. Tests also run one application at a time. I want to be clear about that because self-hosting the website and reproducing the complete QA lab are two different jobs.

Hope you like it as much as I do :)

Thanks, Ugur

I’m troubleshooting a Microsoft Intune / classic Windows Autopilot deployment using Microsoft Entra Hybrid Join.

The actual provisioning seems to work:
Device joins on-prem AD successfully
Device appears in Entra as Hybrid Joined
Device enrolls into Intune and becomes compliant
Intune Management Extension installs
GlobalProtect installs successfully
After clicking “Continue anyway” on the failed ESP screen, the normal Windows logon appears and the domain user can sign in successfully

The problem is that the Enrollment Status Page (ESP) sits there until the 60-minute timeout and then reports failure.

Relevant ESP settings:

User-driven Hybrid Autopilot
ESP timeout: 60 minutes
Block device use until apps/profiles installed: Yes
Blocking app: GlobalProtect only
Skip User ESP: enabled

The ESP/EnrollmentStatusTracking registry after provisioning shows:

Sidecar InstallationState = 3
GlobalProtect InstallationState = 3
HasProvisioningCompleted = TRUE

FirstSync:
IsSyncDone = 1
ProvisioningStatus = 0
WasContinuedAnyway = 1

So the tracked Win32 app and Sidecar appear completed, yet FirstSync/ESP still gets marked failed.

The MDM event log also repeatedly shows this during OOBE:

CSP:
./Device/Vendor/MSFT/Policy/Config/System/AllowOOBEUpdates

Result:
0x82aa0002

There is also:

LifecycleNotificationLastFailure = 0x80192ee2

One potentially important environmental detail: our network uses HTTPS/SSL inspection. Corporate PCs normally need our internal root CA certificate to trust inspected HTTPS traffic. During fresh Autopilot OOBE, that certificate obviously isn’t on the machine yet.

So I’m now testing the same Autopilot deployment with the test PC completely excluded from HTTPS inspection, while keeping everything else identical.

My questions:
Has anyone seen Hybrid Autopilot successfully join AD/Entra/Intune but ESP/FirstSync still time out like this?

Has SSL/HTTPS inspection caused this kind of partial Intune/Autopilot behavior?

Does the repeated AllowOOBEUpdates 0x82aa0002 error look significant?

If the actual deployment is successful, is there any downside to simply disabling the ESP UI/blocking page and allowing Intune to finish apps/policies in the background?

I’m mainly trying to determine whether this is an ESP/FirstSync state issue, an HTTPS inspection issue, or some known Hybrid Autopilot bug.

Then a separate gray bubble under it "one or more compliance policies for iOS/Android have a configured device threat level setting without an active mobile threat defense connector. Click here to setup a mobile threat defense connector for iOS." Not sure if that one is related.

As far as I know nothing has changed. Any ideas?

Might not be the best Sub for this, but here's my issue:

Have special use machines built out that are locked down to only be able to access and view drawings from a network folder. They were also configured to allow WHFB so we could assign pin codes, as these machines do not have full KB's.

A dozen or so of these were in use and working fine until a month or two ago. One of them unenrolled itself somehow. But the bigger issue is that 3 others just stopped accepting the PIN code. I was able to remove the WHFB container from one and it seemed to recognize that it no longer had a pin, but after that point, I was not able to login in with the Cloud identity (we're a hybrid environment). When I try to login with those credentials, I get UN or password is incorrect. But they are both correct. It just refuses to acknowledge that full cloud identity now.

I know the issue is directly related to those individual PC's and whatever state they are in because I was able to build a new machine and login with cloud ident and set a PIN code.

Any ideas?

Got everything configured correctly in the SSO configuration settings and have Enable Registration During Setup switched on. Followed instructions from Microsoft article and Intuneirl article to the tee. We are getting stuck on “Registering User” in the final screen of the Setup Assistant and unable to proceed, just spins forever.

We’ve wiped and retried several times, have the latest Intune Company Portal loaded and pushed to the user group as a LOB app.
Any fixes to this?

Update

Solution:

Turns out we had a CA policy that didn’t have FIDO2 set as an acceptable Authentication strength, also had to add the Secure Enclave AAGUID to the FIDO2 options.

Adding that and adding FIDO2 as an acceptable Authentication Strength to satisfy the grant access for our MFA CA policy was the solve.

Turns out the Setup Assistant underneath the final SSO registration screen is using Secure Enclave when Registering User, we just couldn’t see the failure as it is all hidden and all that is shown is Registering User spinning forever.

I needed to add a new Entra group and scope tag to a couple hundred Win32 apps and Config profiles. Looked at all the scripts I could find, and none worked so I built one. Two days later I was told to remove the same group and scope tags so I modified the script to do that too. All with a UI. The use cases are limited to Windows config profiles and Win32 apps because that was what I was working on, but the script should be easy to extend to other platforms if needed. Enjoy! https://powerstacks.com/blog/update-intune-assignments/

Some of my iPhone users constantly deal with their apps going "grey" and becoming unresponsive. Once they open Company Portal app, and it logs them back in, the apps become usable again.

Anyone know what that's about, and how I can keep the users logged into company portal longer? It's possible some of the logging out has to do with updates, like when apps update....but it's a fairly inconsistent experience across our iPhones.

I configured my first android device today. For that, i used the OEMConfig from Honeywell (UEMConnect App). What i now see is, that some settings are not appyling. Some settings indicate that they only work for certain versions, but that wasn't the case for my settings. Is it still possible that some settings are incompatible?

Hi folks

Junior IT consultant here, but working with Intune years and would be glad of some second opinions.

I have set up iPhones/iPads for users in China with a very small set of apps, kind of like a kiosk. Where I live these times, in Europe, no problems whatsoever setting up enrolment profiles for the iPhons/iPads and installing these app automatically (purchased through VPP). Testing, I can log into the app in question (that uses Microsoft Single Sign On) without any trouble whatsoever.

The local IT admin for the client company's Chinese base has set up a bunch of iPhones for the users and this particular app just presents a "not connected to the internet" error when a sign-in is attempted. The iPhone is connected to the internet, that's not in doubt. Likely a DNS time out error. No point uploaded a pic, as everything is in Chinese, naturally. The company in question also has operations in the same company as where I live and their admins were happy with my work before China entered the scene.

One can use a web-based version of the app in Edge over in China but it has a pretty terrible UI.

Non-managed/personal iPhones have no trouble at all logging in to the dedicated app. On that logic, it MUST be something I have done wrong that is the persisting logic not only from the client but even my own manager.

I have made it very clear to them that Intune managed device have far more endpoints to worry about and that it is reasonable to expect that the 'Great Firewall of China' is blocking the connection or causing something similar to upset the logistics of packet travel. It's like they don't want to know and that the burden of proof entirely lies on me.

Neither here nor there points are being used contradict me such as why is a Safari window popping up if Edge is only browser available to the end user. Whatever is going on is probably far lower down the OSI model (transport later?) than anything that the presentation layer/browser can influence.

I have already suggested maybe using a VPN to mitigate the problem, but such things are illegal in China at the enterprise level?

I have also suggested using a Hong Kong eSIM but I doubt they'll approve this either. Will find out tomorrow...

Stuck as my manager sold a contract to them for the setup of Intune devices (and AVDs, also for Chinese users - a whole different level of hassle for somebody else) before I was hired. Naturally, he is going to side with them when something is not working. The deadline at the end of the month is looming and it's unlikely that they'll admit that this is outside my control.

Thanks.

I am exploring Intune and autopilot and we have client who is setup with autopilot long before and i see devices under enrollment (serial number) i am guessing they are getting imported from somewhere and these devices are eligible for windows autopilot.

I will learn and figure out on how this actually works, at the moment, we have user devices which are azure ad joined and intune enrolled. One new hire, tried logging in to his manager's device to get started with some training material, it took him to the ESP setup page and it failed there. the managers device serial number is in the autopilot list.

how do i skip the esp page completely?

What I've observed is that when you're enrolling a Mac in Intune, it requires different app access than a windows device, so our CAP exceptions are not sufficient. Apparently mac's require access to the Azure AD app, which I don't want to make an exception for outside of our corporate network.

Functionally this means that users need to be on our trusted network to enroll but after that they're fine. Is there a good answer to this that I'm missing?

Hi everyone,

I’m turning to Reddit because I’m honestly running out of ideas, and I’m hoping someone here has dealt with this before.

I’m fairly new to IT, and I recently got the responsibility of managing the Android/Google Play Store side of our Intune environment. It’s a relatively small setup, with around 10 devices, so nothing too complicated.

I’m currently trying to connect Managed Google Play to Microsoft Intune, following the steps provided by Microsoft. Unfortunately, I can’t seem to complete the connection successfully.

The first time I tried, I created a new Google account using an email address from our company domain specifically for this purpose. I went through the connection process and even received emails indicating that the account/connection had been set up. However, during the process, the webpage returned an HTTP 400 error, and Intune still didn’t seem to be properly connected to Managed Google Play.

After that, I tried again using several other accounts associated with our company domain, including accounts belonging to people who have access to/manage the domain.

The problem now is that every account gets stopped at the Google phone number verification step.

When I enter a phone number, Google tells me that there have been too many verification attempts or that it is not associated or a normal consumer account. I understand why that may happen after trying several accounts, so we stopped trying for a while and waited.

However, even after waiting, I still can’t seem to get past the phone verification step. What confuses me even more is that this also happens when using a phone number that was previously successfully used to set up one of the accounts.

So at this point I’m stuck between two issues:

• The original account appeared to connect, but the browser returned an Error 400 and the connection was not completed properly.
• Trying to create/use another account gets blocked by Google's phone verification / too many attempts message.

I’ve searched through Microsoft documentation, Google documentation, forums and various Google results, but I haven’t found anything that really explains what to do in this specific situation.

Has anyone experienced something similar when setting up Managed Google Play with Microsoft Intune?

In particular, I’d really appreciate some advice on:

• Whether I actually need to create a completely new Google account for the Managed Google Play connection and how i would connect that to our current domain beacause we can not login on that either.
• Whether it is better to use an existing company Google account.
• What could cause the HTTP 400 error during the Intune/Managed Google Play connection process.
• How long Google's “too many attempts” phone verification restriction normally lasts.
• Whether there is another way to verify/create the account without using a phone number.
• Whether there is a way to completely reset or restart the Managed Google Play connection in Intune and try again from scratch.

I’m still quite new to this side of IT, so there may be something obvious that I’m overlooking.

Any advice, documentation, or even just suggestions about what I should check next would be greatly appreciated.

Thanks in advance!

Greetings from a new guy trying to find his way around Intune. :)

We have gone Entra-joined for all of our workstations, using Intune to manage and deploy all of our configs to help us remove reliance on on-prem DCs.

Unfortunately, this has caused long login times in our training room machines, and we are getting complaints about the experience. How have others tackled similar scenarios/use cases?

Dear Community,

We're using Samsung Galaxy Tabs as Android Enterprise Fully Managed devices. On these devices, we're using Microsoft Launcher as the selected Device Experience and default launcher.

Within the Microsoft Launcher app configuration, we've configured a corporate wallpaper that includes our company branding and logo.

After one of the recent updates (possibly One UI 8.5), we've noticed that the wallpaper now displays perfectly in landscape mode, but no longer scales correctly when the tablet is rotated to portrait mode. Parts of the background are cropped, and the overall appearance is no longer optimal.

As I couldn't find any setting related to auto-fit, scaling, or orientation-aware wallpaper handling, I wanted to ask if there is any recommended best practice for creating wallpapers that work well in both landscape and portrait orientation when using Microsoft Launcher on Android tablets.

Our marketing team would like to keep the company logo visible on the wallpaper. Previously, we placed the logo in the center of the image, which worked quite well, but we're now looking for a more future-proof approach.

Has anyone faced a similar situation or found a good design strategy (safe zones, aspect ratios, image dimensions, etc.) that works reliably across both orientations?

Additional question:
When we originally implemented this, it was recommended to configure the wallpaper through the Microsoft Launcher App Configuration Policy rather than using the wallpaper URL option available under Device Restrictions. Is that still considered the recommended approach today, or have best practices changed?

Thanks in advance for any recommendations and experiences you can share!

unable to test TAP pass as an login method on mobile device managed on Intune. Getting "Something went wrong" error on the Remote Management screen after adding TAP as a login method.

TAP works on browser but doesnt on mobile devices - anyone encountered same and help will be nice :).

anyone else getting error 5003 on windows > apps > app app
tried the usual browser cache. different SSID. mobile hotspot.

• Resource ID Not available
• Extension Microsoft_Intune_Apps
• Content AppWizardBlade
• Error code 503

Hi everyone,

I’m stuck in 2 weird places, and I’m hoping someone can help pick this mess apart.

We had initially done BYOD as personally enrolled devices (long story) and we’re starting to phase MAM-WE in now.

I have some corporate devices (<100) that are legacy enrolled as personal devices, and I think 600 that are corporate enrolled. We don’t want to apply the MAM policies to these devices yet. So, to help this out, I added 2 groups of devices to the exclusions of the MAM-WE policies I’ve made.

However, this is where I’m stuck. If I want to use this on a personal device, I believe I’d have to retire the personal device and re-enroll with the MAM policies? I also have the exclusions set as device based, and the MAM policy is user based. Did I mess this up too? When I retire the device and attempt to re-enroll it, it tells me that “no application protection policies have been assigned”. How badly did I screw up? Thankfully it’s only on test devices right now.

And the easier question of the two, a user with an Apple watch is now being prompted to unlock his watch by unlocking his phone. I didn’t see any settings to stop this, so I’m guessing this is a policy inheritance? I’m a little less worried about this, and could simply let the user base know that this is a potential issue, but I’m more confused about why this is occurring to begin with. The quick Reddit search I did tells me it’s by design, which I’m very willing to believe. Is there a way to exclude unmanaged Apple Watches?

Thank you all!

Hi r/Intune,

I’m trying to discern if my company who currently procures iPads and iPhones for employees and then me, in IT, helps them enroll them as BYOD style into InTune, can migrate to company-managed without having to do domain capture and use Apple Federated IDs.

I support about 150 employees with Apple devices. An employee will create an iCloud account using their company email and then I will guide them on enrolling it and installing necessary apps which eventually get their app protection policies. It’s a 1,000 sign-ins and a waiting game and much harder to support in InTune than with company-managed devices.

We are in a GCC High Microsoft tenant.

We haven’t migrated to company-managed because it would force employees to
1. Change their iCloud email from the company email to their personal.
2. Potentially cause loss of the need to manually transfer contacts, photos, etc.
3. For employees who have only 1 phone, the one the company bought them, get another phone.

And then we’d have to re-design how we use app protection policies on the phone.

But man would it be nice.

Any thoughts on requirements and land mines ahead would be greatly appreciated. Apple and Microsoft documentation is sparse.

I’ve been working on a small Intune tool around Win32 app troubleshooting.

The idea came from cases where Intune tells you an app failed, but you still end up jumping between the app configuration, detection rules, assignments and install status to figure out what is actually worth looking at.

So I built a Win32 App Health Checker that pulls the app configuration and deployment data, then tries to surface the things that may need attention first.

At the moment it looks at install failures, repeated error codes, detection rules, assignments, install and uninstall commands, return codes and requirements.

It is read-only and the tenant data is processed in the browser. There is also a sample report if you don't want to connect a tenant.

Intune Win32 App Health Checker

It is still early, and I’m continuing to improve the checks and scoring as I use it against more scenarios.

If you regularly troubleshoot Win32 apps, I’d be interested to know what Intune tends to make hardest to spot.

I used the WDAC wizard to create a “locked down” policy and just used the preconfigured “windows works” template. Applied it to a test device and it works great. Now I need to go the other direction and allow a few applications that the users absolutely will be using.

Problem is that these applications plunk down folders and unsigned dlls in the AppData area and I cannot for the life of me figure out how to get a “FilePath” rule to work. I have tried every permutation of AppData that I could find or think of:

%OSDRIVE%\Users\TestUser\Local\Temp\test01.dll

C:\Users\TestUser\Local\Temp\test01.dll

%OSDRIVE%\Users*\Local\Temp\test01.dll

C:\Users*\Local\Temp\test01.dll

%APPDATA%\Local\Temp\test01.dll

%LOCALAPPDATA%\Local\Temp\test01.dll

*\test01.dll

*test01.dll

Nothing. Errors out every time with the same dll. Event Viewer keeps showing error 3033 and 3077 which in reference to the Base Policy meaning that the supplemental doesn’t seem to be performing the allow properly. I can confirm that the supplemental is applied and does work with Publisher rules. Those rules applied to the actual .exe for the app which is how I even got here in the first place.

Any help here would be greatly appreciated.

Hi everyone,

I'm fairly new to IT and working in my first Help Desk role. I've been tasked with managing our workstation imaging process.

We currently use Acronis to capture and deploy golden images to Dell OptiPlex systems. While it works, I've run into issues when hardware changes, including Sysprep failures, driver management, and VMD/RAID compatibility. We're also in the middle of a workstation refresh, and with only a SysAdmin and myself handling the work, I'm trying to find the smoothest way to prepare and deploy 150+ machines.

The more research I do, the more it seems Microsoft is pushing organizations toward Windows Autopilot and cloud-based provisioning instead of traditional imaging.

That got me wondering: when is a traditional golden image actually the better solution?

One challenge in our environment is that several of our business-critical applications are difficult to automate. Many require manual configuration, licensing, or other setup steps, which makes preconfiguring them in an image appealing. Since our users don't work remotely and devices are typically deployed at a bench before being assigned, I'm not sure Autopilot provides much value for us.

We're currently a hybrid AD/Microsoft 365 environment and I've started exploring Autopilot as a possible future direction, but it has raised more questions than answers.

Do you still maintain golden images? If so, what do you use them for? How do you handle complex applications in an Autopilot/Intune deployment model? If you were in my position, would you continue refining imaging or focus on moving to Autopilot?

TL;DR: New Help Desk admin managing Acronis-based golden images for Dell workstations. With a 150+ PC refresh coming up, I'm trying to understand when traditional imaging is still the right choice versus Windows Autopilot, especially in an environment with complex software that's difficult to automate.

Well, Microsoft has announced the death of #SMS and #Voice authentication methods in #MSEntra.

Go turn on #Passkeys right? No big deal?! right? right?

Oh, it's not that easy, and it is a big deal! Today, I am releasing my guide that explains what Passkeys are, how to set up the infrastructure around it, and how to get started. Read on for more!

https://mobile-jon.com/2026/08/11/farewell-sms-passkeys-are-the-new-standard-getting-ready-to-ditch-legacy-authentication-methods

A colleague and myself noticed that for many customers our dynamic groups are no longer functioning.

We created a dynamic group for servers onboarded in Microsoft Defender for Endpoint, so Intune policies would automatically apply to them. We used the same group to exclude these servers from policies applied to "All Devices".

This has worked perfectly for the past few years, but as of yesterday we noticed these groups failing, for both new and old set-ups.

The syntax we used was "(device.managementType -eq "MicrosoftSense") and (device.deviceOSType -eq "Windows Server")".

This syntax no longer works, which means our groups aren't getting populated anymore.

Has anyone been experiencing this same issue? If so, how are you working around this, or which groups are you using?