Paid $100 for Standard Support, Submitted Ticket 5 Days Ago, Still no Response

Hi Dan Hickman

Apologies for the inconvenience. I have reviewed the case status, and it appears that no support engineer has been assigned to the ticket yet. I will escalate the ticket from my end to ensure it gets the necessary attention as soon as possible.

It's been a full week now and still nothing. Feeling pretty ripped off paying for support and getting no help.

Hi Dan Hickman
I have escalated the support ticket from my end, and I expect that an engineer will be assigned to it shortly.

In the meantime, I will assist you with your issue. After reviewing the case, I understand that the applications are visible in your Azure tenant, but when you attempt to edit the SSO settings, the changes cannot be made as the apps appear to be associated with a different tenant.

The tenant ID 9188040d-6c67-4c5b-b112-36a304b66dad is owned by a Microsoft account (MSA). Any changes must be made within the tenant where the application was originally registered. If the application was created under an MSA, you can only manage or modify it from that same MSA-associated tenant.

To help further, could you please clarify:

• Why are you trying to adjust the SSO settings?
• What exact error are you seeing when trying to configure SSO in your tenant?

There is still no activity on this support ticket. I still need assistance.

Hi Dan Hickman

Please check your private messages for the status of the issue.

@Navya do you have any status you can report? I need my question answered, not just telling me things I already know.

@Navya do you have any status you can report? I need my question answered, not just telling me things I already know.

Hello Dan Hickman,

I’ve reviewed the case and the details regarding your application. I understand you're looking to migrate from Live SDK apps to MSAL 2.x. However, your Live SDK app was originally created using a Microsoft personal account (******@domainX.com) through the apps.dev.microsoft.com portal (Now deprecated). These apps are registered under a different tenant (Tenant ID: 9188040d-6c67-4c5b-b112-36a304b66dad), and in your current Azure tenant, you only have a service principal object for the app—meaning it was added as a multi-tenant application from another tenant. As a result, you’re unable to edit the app in your current Azure portal.

The tenant ID 9188040d-6c67-4c5b-b112-36a304b66dad corresponds to the Microsoft Account (MSA) tenant, also known as the "consumers" domain. This is the default tenant for personal Microsoft accounts.

If you see this tenant ID listed as the App Owner Tenant ID for your app registrations, it confirms that the apps were created under a personal Microsoft account and not within an organizational Entra (Azure AD) tenant. That’s why you’re unable to manage them through the Azure portal of your enterprise tenant.

To migrate and modernize these apps, you'll need to register new applications within your Azure tenant.

Sign in to the Azure portal.

• Navigate to Microsoft Entra ID > App registrations > New registration.
• Use the same app name and redirect URIs (including SPA URIs for MSAL 2.x).
• Choose the appropriate Supported account types (e.g., single-tenant or multi-tenant).

Once you register the new app, you can replace the old client ID with the new one from your Azure tenant and configure MSAL 2.x with the new authority, redirect URI, and required scopes.

Once the new applications are fully functional, you can begin phasing out the old Live SDK-based apps.

Please note that apps created using personal Microsoft accounts cannot be transferred to Azure (Entra ID) tenants. If you still need to access the original app settings, you'll have to sign in using the personal account that created them. However, they cannot be updated to use MSAL 2.x within an organizational tenant context.

Migrating from MSAL 1.x to MSAL 2.x

Hello Dan Hickman,

Just checking in to see if below information was helpful. If you have any further updates on this issue, please feel free to post back.

No, creating a whole new app is not an acceptable solution because we will lose all our visitor consents. We need to keep the current app and regain access or find some way to transfer the current consents to the new app.

Hello Dan Hickman,

Since the application in question is not owned by you or created within your tenant, you won’t be able to edit or configure it from your side.

If your concern is about the consent prompt shown to users, you can work around this by creating a new application in your tenant. After registering the app, follow these steps:

Add the required API permissions (matching those of the original app).

Grant tenant-wide admin consent to the app.

This will ensure that users signing into the new application will not receive a consent prompt during login, as the necessary permissions are approved by admin tenant-wide.

The application was owned by my MSA account but somehow went away without me taking any action and I need Microsoft to restore it.

The consent work around you mentioned will not work because the users that have given consent are not part of our organization.