Kevin Malinoski

If you’ve tested the new ADE enrollment policies in Intune and Company Portal fought you afterward, you’re not alone.

I was testing the new policies and hit the same issue on every device. Setup Assistant finished, Intune managed the device as expected, and device-level apps installed and removed without a problem. Then Company Portal tried to enroll the device all over again.

I’d followed the Microsoft documentation step for step, so this one had me stumped for a while. This post is for admins moving iOS/iPadOS ADE from the old enrollment profiles to the new Enrollment policies, or setting them up for the first time.

TL;DR

The new ADE Enrollment policies removed the Install Company Portal settings, and with them the Company Portal app config that Intune used to send automatically.

Without that config, Company Portal treats an ADE-enrolled device as unenrolled and asks the user to download a management profile that is already installed.

The fix is an app configuration policy for Company Portal with the IntuneCompanyPortalEnrollmentAfterUDA key, assigned to the same devices.

The Learn page that holds the XML warns against deploying it manually. That warning is written for the old profiles.Don’t assign it to devices that still enroll through the old profiles.

The setup

My test configuration used the new enrollment policy experience end to end:

The symptom

After Setup Assistant, the device looked healthy in Intune. Policies and device-level apps landed, and the Intune management profile was installed on the device.

Company Portal was the problem. After sign-in it asked me to set up company access and download a management profile. I could never complete that flow, and it kept looping back.

What changed in the new enrollment policies

The old Profiles experience had an Install Company Portal setting. When Install Company Portal with VPP was configured, Intune sent Company Portal and its ADE app config during enrollment. The ADE setup article still describes that behavior:

“During initial enrollment, Intune automatically pushes app configuration policy settings for devices enrolled with Setup Assistant with modern authentication. This happens when the enrollment policy setting Install Company Portal is set to Yes.“

The new Enrollment policies don’t have that toggle. Microsoft’s announcement for the new experience says the Install Company Portal, Install Company Portal with VPP and Single App Mode settings “aren’t supported and have been removed,” and that Company Portal “will never be sent down automatically” by the policy.

The community thread that matched

I found a Tech Community thread from July 2026 with my exact setup and symptom. The poster deployed Company Portal as a required VPP app on a new enrollment policy, and Company Portal asked for a management profile after sign-in. They also saw two devices in Company Portal: “iPad” and the real device name.

The first reply suggested the old Install Company Portal with VPP setting, which doesn’t exist in the new policies. The poster then got it working with help from an Intune MVP. The MVP isn’t named in the thread, so I can’t credit them here. The fix was the Company Portal app config XML, and the poster noted the keys are case-sensitive: one wrong letter broke it.

A later reply added a useful clue. Entra audit logs showed Register device failing with “Invalid JWT token,” then a successful retry under the same CorrelationId that created a second, orphaned device object. After the XML was deployed, the retry attached to the correct device record.

Why the documentation points the wrong way

The XML lives in Configure the Company Portal app to support iOS and iPadOS devices enrolled with Automated Device Enrollment. That section says ADE “isn’t compatible with the app store version of the Company Portal app by default,” and the XML is what makes Company Portal ADE-aware post-enrollment.

The same section warns not to deploy the config manually when the enrollment profile has Install Company Portal set to Yes, because the duplicate causes the management profile prompt. With the new policies that toggle is gone, so the condition behind the warning can’t happen. The warning reads like “don’t do this,” when for new policies it’s the step you need.

The fix

1. Go to Apps > Configuration > Create > Managed devices. Choose platform iOS/iPadOS and targeted app Intune Company Portal.
2. On Settings, choose Enter XML data and paste the XML below exactly. Keys and tokens are case-sensitive.
3. Assign the app config to the same device group configured on your enrollment profile, then wipe and re-enroll a test device and sign in to Company Portal.

<dict>
    <key>IntuneCompanyPortalEnrollmentAfterUDA</key>
    <dict>
        <key>IntuneDeviceId</key>
        <string>{{deviceid}}</string>
        <key>UserId</key>
        <string>{{userid}}</string>
    </dict>
</dict>

If your devices enroll without user affinity and you want the first Company Portal sign-in to become the primary user, that is a different key: IntuneUDAUserlessDevice.

<dict>
    <key>IntuneUDAUserlessDevice</key>
    <string>{{SIGNEDDEVICEID}}</string>
</dict>

On a live enrollment, the app config status in Intune sometimes showed an error for me even though Company Portal worked. Microsoft documents similar behavior for the userless key, IntuneUDAUserlessDevice, which Intune removes in the background after it applies once. I haven’t seen Microsoft document it for the user affinity key, but don’t panic if you see an error as it should be transient.

Wrapping up

Existing profiles under the old Profiles keep working, and they still send Company Portal and its config when Install Company Portal is Yes. If a fleet is configured, it doesn’t need this app config. Furthermore, if it were to get this configuration, enrollment would break. So be careful when you do decide to migrate.

Microsoft says the older experience won’t receive new features and will eventually be retired, so it’s worth testing the move to the new Enrollment policies sooner than later.

Knowing about this key configuration ahead of time should save you a lot of frustration. Hopefully Microsoft updates the documentation to make it clear this is required with the new enrollment policies.

Have you migrated your fleet to the new enrollment policies yet? Drop a comment if this helped, or if you’ve found other quirks moving your iOS enrollments over.