Good afternoon,

I am running into the problem that my devices are not enrolling in UEM via Autopilot. It does not seem to pick up the Airwatch by VMware but enrolls itself with Intune (which is strange since the scope is set to "none" there). Tried various manuals, had calls with people from Omnissa but it seems that something is wrong with the Airwatch by VMware app. When I add it I run into an error message, see attachment. Anyone familiar with this?

I am also having the same issue where devices are not getting enrolled in UEM. As currently working with MS support for the same and it looks like requests are not hitting to T&C and enrollment URL.

We had this issue and it was due to us removing and recreating the Airwatch application within Entra when creating the environment. There was a stale Airwatch entry lurking behind the scenes that only MS could see.

On 10/31/2024 at 1:14 AM, David Bailey said:

We had this issue and it was due to us removing and recreating the Airwatch application within Entra when creating the environment. There was a stale Airwatch entry lurking behind the scenes that only MS could see.

We have received an update from MSFT regarding a stale Airwatch entry with another app ID. Could you please clarify if you have already removed this entry? Alternatively, if there is any support required from MSFT or Omnissa, please let us know.

It seems this issue would be resolved by Microsoft, as they control where the enrollment is sent. Are you able to open a Microsoft case?

I have added all the details in above topic

The only change that happened in regards to the MDM app recently(but after your issue I think) was the name change to AirWatch by Omnissa which happened automatically for you and the update of the static MDM app gallery entry to also be called AirWatch by Omnissa. This did not affect the functionality of the app so. It's a multitenant app and it was working for other so the thing that must have been stale must have been the Service Principal and Enterprise app created from the multitenant app in your tenant. Why that became stale is something that would need to be investigated with Microsoft.

On 11/7/2024 at 6:37 PM, Jason Misleh said:

It seems this issue would be resolved by Microsoft, as they control where the enrollment is sent. Are you able to open a Microsoft case?

Sorry for my late response, I will report this to Microstoft via my employer PQR to resolve the issue and of course I will let you know the outcome here. Thanks!

Edited November 27, 2024Nov 27 by Stevin van Keulen

On 11/27/2024 at 1:56 PM, Stevin van Keulen said:

Sorry for my late response, I will report this to Microstoft via my employer PQR to resolve the issue and of course I will let you know the outcome here. Thanks!

Hi @Stevin van Keulen do you have any update on this?

Hi Pim,

Unfortunately, not... I finally had my first contact with Microsoft last Friday. They mentioned that they encountered some issues with ticket assignments, but they are now working on to resolving our issue. I hope that I will have an update soon and will keep you informed of any progress.

Cheers!

Hi all,

We resolved the issue.

After the autopilot steps on the device, we used the following CMD command: dsregcmd /status
In this we saw that the MdmUrl and the MdmTouUrl were empty. This should be filled by the AirWatch by Omnissa app but it was not. 

We then continued diving with the MS Graph explorer: https://developer.microsoft.com/en-us/graph/graph-explorer. Here we requested the following GET request: https://graph.microsoft.com/beta/policies/mobileDeviceManagementPolicies

This shows all Mobility (MDM and WIP) apps, even those that we do not see in the UI of MS itself. In this we saw that in addition to the Intune and Omnissa app there was also a "ghost app" that could not be seen in the UI. For this app the "appliesTo" was set to "all" which caused our (autopilot) devices to be provided with this app and gave the empty MdmUrl and the MdmTouUrl. 

{

"id": "97832396-a5a4-428b-a777-41465c3ece3d",

"appliesTo": "all",

"complianceUrl": null,

"description": null,

"discoveryUrl": null,

"displayName": null,

"isValid": false,

"termsOfUseUrl": null

}

Solution:

In the MS Graph explorer we have the following DELETE request done: https://graph.microsoft.com/beta/policies/mobileDeviceManagementPolicies/97832396-a5a4-428b-a777-41465c3ece3d

That's basically the same request we used to retrieve all Mobility (MDM and WIP) apps but we added the app id of the "ghost app" and changed GET to DELETE.

This removed our "Ghost app" from Azure and allowed our device to autopilot into Workspace ONE UEM!

Special thanks to @Pim Van De Vis for helping me to troubleshoot this!

Great writeup, thanks for sharing. And glad that we were able to solve this.

I agree with @Pim Van De Vis. Really good content.

On 5/6/2025 at 4:17 PM, Stevin van Keulen said:

Hi all,

We resolved the issue.

After the autopilot steps on the device, we used the following CMD command: dsregcmd /status
In this we saw that the MdmUrl and the MdmTouUrl were empty. This should be filled by the AirWatch by Omnissa app but it was not. 

We then continued diving with the MS Graph explorer: https://developer.microsoft.com/en-us/graph/graph-explorer. Here we requested the following GET request: https://graph.microsoft.com/beta/policies/mobileDeviceManagementPolicies

This shows all Mobility (MDM and WIP) apps, even those that we do not see in the UI of MS itself. In this we saw that in addition to the Intune and Omnissa app there was also a "ghost app" that could not be seen in the UI. For this app the "appliesTo" was set to "all" which caused our (autopilot) devices to be provided with this app and gave the empty MdmUrl and the MdmTouUrl. 

{

"id": "97832396-a5a4-428b-a777-41465c3ece3d",

"appliesTo": "all",

"complianceUrl": null,

"description": null,

"discoveryUrl": null,

"displayName": null,

"isValid": false,

"termsOfUseUrl": null

}

Solution:

In the MS Graph explorer we have the following DELETE request done: https://graph.microsoft.com/beta/policies/mobileDeviceManagementPolicies/97832396-a5a4-428b-a777-41465c3ece3d

That's basically the same request we used to retrieve all Mobility (MDM and WIP) apps but we added the app id of the "ghost app" and changed GET to DELETE.

This removed our "Ghost app" from Azure and allowed our device to autopilot into Workspace ONE UEM!

Special thanks to @Pim Van De Vis for helping me to troubleshoot this!

@Stevin van Keulen

I have tested the procedure as you suggested, and it worked well. I have also updated some details as noted below. However, I observed that a few steps and screenshots were missing. The information you provided is comprehensive, and I appreciate the thorough update.

Thank you once again for your detailed contribution.

https://community.omnissa.com/forums/topic/69027-oobe-enrollment-issue-at-first-time-configuration/?&_rid=24711