Sp-dev-docs: SPFX 1.6 msGraphClient error on SharePoint app Android

[RicoNL]

Category

• [ ] Question
• [ ] Typo
• [X] Bug
• [ ] Additional article idea

Expected or Desired Behavior

I created a SharePoint Framework 1.6 webpart which uses the MSGraphClient. On all browsers (tested with IE11, Edge, Chrome on laptop. Tested with Chrome, Edge, Samsung browser on cell phone ) this is working as expected: information from Graph is received.

Observed Behavior

However, when I open the site with the webpart in the SharePoint mobile app (Version 3.0.0 on Android 7.0) the webpart receives an error:

"AADSTS50058: A silent sign-in request was sent but no user is signed in. The cookies used to represent the user's session were not sent in the request to Azure AD. This can happen if the user is using Internet Explorer or Edge, and the web app sending the silent sign-in request is in different IE security zone than the Azure AD endpoint (login.microsoft.com). "

Steps to Reproduce

this.props.context.msGraphClientFactory.getClient().then((graphClient:MSGraphClient) => {
  //Office 365 and security groups
  graphClient
    .api("me/memberOf")
    .version("v1.0")
    .get()
    .then((graphgroups: any) => {
      alert("groups response received");
    }, (error: any) => {
      alert(error.message);
    });
});

[KingKangMSFT]

I think you can refer to this document AADSTS50058: A silent sign-in request was sent but no user is signed in

[OliverZeiser]

I am seeing the same issue, when adding a SharePoint page in the Microsoft Teams Client as a tab. But it is working when running MS Teams in the browser ;)

[BigEaseGueldi]

Does this happen just with 1.6 or is this a general problem?

Many of our user stories include accessing something Graph-based during an early morning subway ride - of course with the SharePoint App...

[RicoNL]

Does this happen just with 1.6 or is this a general problem?

Many of our user stories include accessing something Graph-based during an early morning subway ride - of course with the SharePoint App...

msGraphClient has become General Available in spfx 1.6 . You are probably using a different method for connecting to Graph

[OliverZeiser]

The way I see it this happens when using native applications and not the browser. We do not have any settings there to allow for cross-domain cookies, trusted sites or things like that. Is this working for anyone or is this a general issue using SPFx 1.6 and graph/adal? Because the old GraphHttpClient did work just fine in this scenario.

[OliverZeiser]

Okay i just realized....if I enable and disable the MS Teams developer preview, at least for MS Teams client it is working now. It must have been some caching issue. Still I cannot get the SP Mobile App to work though....

[JHolah]

I am also seeing this in the SP app...

[BigEaseGueldi]

+1

[PzYon]

We have the same issue.

[OliverZeiser]

Okay it looks like everyone has this issue in the SharePoint mobile app. So adding @VesaJuvonen and @patmill who should be able to forward this to the right people/channel...

[patmill]

Yes - known issue. We are working on it. Things work quite nicely in the browser, but client apps are problematic.

[shaipetel]

Hmmm... just got this issue on Chrome. This browser and specific page were working fine for weeks - now all of the sudden I get this error.

Any idea what could be the issue?

Regular team site, modern web part page, SPFx 1.6, Chrome latest build, Windows 10

[shaipetel]

Found a workaround for the browser, but it won't work for everyone:
Visited https://developer.microsoft.com/en-us/graph/graph-explorer and logged in.
Once I did that - my pages started to work again.
Would be great to still have an answer for customers who will experience this issue...

[GrahamMcMynn]

This is a known issue that we currently have across all rich clients. Our graph calls require that the cookie from the browser which contains the access token already exists. We are working on a generic solution that will work across all non browser clients (teams/android/ios etc).

[PzYon]

@patmill , @VesaJuvonen is there any news on when this will be fixed? We have several customers that are using the SharePoint Mobile App and that get errors all over the place.

[harshdamaniahd]

Yes, this is really annoying

[Rasstryga]

The same problem is critical! @patmill , @VesaJuvonen is there any news on when this will be fixed? Is this problem fixed in SPFx 1.7?

[MaheshakaMudli]

Any updates on the above issue. We are facing this issue for a while and client needs solution for it. It works well on all the browsers but fails in Sharepoint mobile app(android/iOS).

[lucmoco]

I would also appreciate a solution to this problem. We developed a business application as a SharePoint Framework web part, but it doesn't work in the SharePoint android mobile app. In our case we are accessing a back-end API using the aadHttpClient, but I guess the same authentication mechanism is failing in both cases.

[luis-ribeiro]

We are also facing this issue in several spfx:1.7 webparts that use msGraph client.
It works on all browsers but not in the SharePoint App!
Any news on this?

[patmill]

We are working on this full-time. It's a gross problem, but we hope to have some solutions soon. Sorry about the delay.

[gagan2singh]

Hi Team,
Now even the Browser version have stopped working. Was there any update done to the Graph API recently. Please see the error below:

Error: AADSTS50058: A silent sign-in request was sent but none of the currently signed in user(s) match the requested login hint.
Trace ID: f70e612d-e154-4747-b547-add37d760c00
Correlation ID: 819ee0d8-7b0b-48c7-abbf-3e91331777e6
Timestamp: 2018-12-19 01:46:40Z
at Array. (sp-webpart-workbench-assembly_en-nz_759e6103ee382f9a2e85f131c6949cf9.js:1067)
at _callBackMappedToRenewStates.(anonymous function)._callBackMappedToRenewStates.(anonymous function) (https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-12-07.005/1.sp-http-adal_7a2d498ba73bbc02778f.js:3:7561)
at AuthenticationContext.handleWindowCallback (VM26401 adal.min.js:2)
at parseTokenFromUrl (spfxsinglesignon.aspx:20)
at onload (https://intergen1.sharepoint.com/_forms/spfxsinglesignon.aspx#error=login_required&error_description=AADSTS50058%3a+A+silent+sign-in+request+was+sent+but+none+of+the+currently+signed+in+user(s)+match+the+requested+login+hint.%0d%0aTrace+ID%3a+f70e612d-e154-4747-b547-add37d760c00%0d%0aCorrelation+ID%3a+819ee0d8-7b0b-48c7-abbf-3e91331777e6%0d%0aTimestamp%3a+2018-12-19+01%3a46%3a40Z&state=504a1ef8-9be7-466a-b185-1f3f1b942f46%7c85e59333-0277-4eed-a282-4728bc60d06c:31:38)

[Rasstryga]

Hi Team,
Now even the Browser version have stopped working. Was there any update done to the Graph API recently. Please see the error below:

Error: AADSTS50058: A silent sign-in request was sent but none of the currently signed in user(s) match the requested login hint.
Trace ID: f70e612d-e154-4747-b547-add37d760c00
Correlation ID: 819ee0d8-7b0b-48c7-abbf-3e91331777e6
Timestamp: 2018-12-19 01:46:40Z
at Array. (sp-webpart-workbench-assembly_en-nz_759e6103ee382f9a2e85f131c6949cf9.js:1067)
at _callBackMappedToRenewStates.(anonymous function)._callBackMappedToRenewStates.(anonymous function) (https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-12-07.005/1.sp-http-adal_7a2d498ba73bbc02778f.js:3:7561)
at AuthenticationContext.handleWindowCallback (VM26401 adal.min.js:2)
at parseTokenFromUrl (spfxsinglesignon.aspx:20)
at onload (https://intergen1.sharepoint.com/_forms/spfxsinglesignon.aspx#error=login_required&error_description=AADSTS50058%3a+A+silent+sign-in+request+was+sent+but+none+of+the+currently+signed+in+user(s)+match+the+requested+login+hint.%0d%0aTrace+ID%3a+f70e612d-e154-4747-b547-add37d760c00%0d%0aCorrelation+ID%3a+819ee0d8-7b0b-48c7-abbf-3e91331777e6%0d%0aTimestamp%3a+2018-12-19+01%3a46%3a40Z&state=504a1ef8-9be7-466a-b185-1f3f1b942f46%7c85e59333-0277-4eed-a282-4728bc60d06c:31:38)

Hi. Our team faced with same error during using MS Graph Api from SPFx 1.6 solutions

[b00johst]

One of my customers are experiencing this issue as well. First in their test tenant and one day later in the production environment. We have built key funktionality based on the aadClient in spfx 1.6.

[mohag519]

We have been experiencing the same thing. First on test tenant and now some users on production. We have tested everything: different browsers, different computers, a new minimalistic mockup app to test the same mechanics. This error happens for users overnight, with no code changes or AD changes.

[OliverZeiser]

The issue you have been seeing should be resolved and there is another issue for this topic: #3147
This issue here is about the SharePoint mobile App. Please don't mix those two, thx!

[mohag519]

The issue you have been seeing should be resolved and there is another issue for this topic: #3147
This issue here is about the SharePoint mobile App. Please don't mix those two, thx!

You're right. Thanks for pointing me in the right direction.

[sortegamartin]

@patmill can we expect this to be fixed "behind the scenes", or will it be part of a new SPFx release?

[thenail]

Any updates on this one?, we are experiencing it in our first release enviroment in Chrome.

[dalejo09]

I think I resolved the problem on "Internet Explorer", this issue is because "https://login.microsoftonline.com" is not added to "IE security zone", so the error says: "the web app sending the silent sign-in request is in different IE security zone than the Azure AD endpoint"

Steps:
On IE, open "Internet Options" and you have to ensure both sites are on the same security zones "https://{tenant}.sharepoint.com" and "https://login.microsoftonline.com", after that close all sessions and restart it

It worked for me!
Diego A. Campo
[email protected]

[lucmoco]

@dalejo09, your're talking about a different problem. This one is specifically about the SharePoint app on Android, and not Internet Explorer.

By the way we also had we also had to solve the zones problem in IE, but this didn't solve the SharePoint Android app one.

[lucmoco]

@thenail, I think the problem here is that the authentication in SharePoint is still valid the next day, thus the SharePoint page is displayed successfully, but the authentication cookie has expired at login.microsoftonline.com. When SharePoint uses the msGraphClient or aadHttpClient for the first time in the morning, the following happens:

• The access token to the service (Microsoft Graph or other API) has expired
• Thus SharePoint requests a new token by loading login.microsoftonline.com in a hidden iframe
• Since the authentication cookie expired in login.microsoftonline.com, the silent generation of an access token fails.

In order to circumvent the problem, we detect the error and display in our web part a message and link asking the user to authenticate again in login.microsoftonline.com in another tab, and then reload the SharePoint page with the web part.

But of course it's just a work-around and it would be a lot better if SharePoint could handle the problem for us !

[SPDev8]

I don't know the ins and outs of login.microsoftonline.com but it would be interesting if we could "detect the error", redirect the browser to login.microsoftonline.com to have the user login, and then be redirected back to the original SharePoint page.

I've tried to set the redirect_uri to something other than https%3A%2F%2Fyourtenant.sharepoint.com%2F_forms%2Fdefault.aspx but get the error: "AADSTS50011: The reply url specified in the request does not match the reply urls configured for the application: '00000003-0000-0ff1-ce00-000000000000'".

If you open a new browser and try visiting a site collection (e.g. https://yourtenant.sharepoint.com/sites/site1), you get sent to login, and then redirected back to your site1. I tried to copy and paste the login url along with the query string parameters that were generated but it's one time use. Use the login url a second time and you'll end up on the main SPO root instead of your site collection.

[SPDev8]

Sorry, I just realized that this thread started with SharePoint app on Android issues while I'm talking about desktop issues.

Our solution was to "detect the error", then window.location.href the user to:
https://yourtenant.sharepoint.com/_forms/default.aspx?returnUrl=https%3A%2F%2Fyourtenant.sharepoint.com%2Fsites%2Fsite1

This will check the AAD session, ask user to login, redirect back to site at returnUrl, and Graph/Azure resources will be working again.

[AsunSanLo]

Hi, any updates on this? I'm experiencing the same issue both on MS Teams Client and app, but it is working on web.

I configured a web tab instead of a SharePoint page tab and, although it is not the best experience, it worked because it showed the log in page to the user and then it correctly redirected to our page. However, a few days ago it started to fail also after the user logs in. In mobile app it is still failing and the user has to use the "Open in browser" option for the tab.

One last thing, a few weeks ago it was working fine when we activated the developer preview mode on Teams client, but it is also failing in that mode now.

[Christian-Stahl]

Any updates on this one? I have a SPFx custom web part that works just fine in all browsers etc but not in the native SP mobile app, same as above.. the graph calls in this web part require a cookie from the browser which contains the access token already exists.

[lucabandMSFT]

hey guys, customers should now be able to run SPFx solutions in Mobile clients.
Can you please follow the steps below and confirm that this unblock their scenario?
Once we get that confirmation we will proceed on make those steps available to everybody through Public doucumentation.

Note: you have to be Global Tenant Administrator to perform all the steps below
Step 1. Visit the "Manage Permissions" Page in SharePoint Tenant Admin
Step 2. Go to -> https://aad.portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredAppsPreview
Step 3. Click on "SharePoint Online Client Extensibility" Web Application Principal
Step 4. Click Manifest on the left menu
Step 5. Copy the id from the oAuth2Permission array
"oauth2Permissions": [
{
"adminConsentDescription": "Allow the application to access SharePoint Online Client Extensibility Web Application Principal on behalf of the signed-in user.",
"adminConsentDisplayName": "Access SharePoint Online Client Extensibility Web Application Principal",
"id": "2143704b-186b-4210-b555-d03aa61823cf",
"isEnabled": true,
"lang": null,
"origin": "Application",
"type": "User",
"userConsentDescription": "Allow the application to access SharePoint Online Client Extensibility Web Application Principal on your behalf.",
"userConsentDisplayName": "Access SharePoint Online Client Extensibility Web Application Principal",
"value": "user_impersonation"
}
],
Step 6. Replace “preAuthorizedApplications” entry with the following json
"preAuthorizedApplications": [
{
"appId": "00000003-0000-0ff1-ce00-000000000000",
"permissionIds": [
"2143704b-186b-4210-b555-d03aa61823cf"
]
}
],
Step 7. Hit Save.

Thanks,
Luca

[TheTedAdams]

@lucabandMSFT just want to confirm your suggested fix has allowed me SPFx web parts to start working in tabs in the desktop app.

We get a graph token with the following:

const tokenProvider = await this.context.aadTokenProviderFactory.getTokenProvider();
this.token = await tokenProvider.getToken('https://graph.microsoft.com');

We were getting null until I made the changes in manifest you suggested, and now we are successfully getting a graph access token.

[lucabandMSFT]

Ted (@TheTedAdams), glad to hear that!
hey @michelsmit , your problem seems to be completely unrelated. can you confirm to me that your web part works in the Teams tab on the Teams browser but not on the Teams desktop app?

Thanks!

[michelsmit]

@lucabandMSFT It took a few hours before the change in the manifest worked his way through but I can confirm the webparts are working now in the SharePoint app. Is this a permanent solution or a workaround?

[lucabandMSFT]

Guys, thank you very much for your feedback, truly appreciated.
@michelsmit, the solution is permanent but the workaround is a temporary one. Let me explain :)
The fix we released is composed of two parts, one part that allow us to get and use the right token on the rich client to call the Web API (MS Graph etc..) that the (SPFX) component requires, and one part that allows us to control the App Principal in AAD to perform such token acquisition.

the second part is still in the roll out phase (final testing.. rolling out in production environment etc. etc. ), which is the reason why you have to manually change the App Principal manifest.
We are going to document that today officially and, once the second part of our fix rolls out 100% we will remove that part from our documentation.

Thanks again folks. I'm closing this issue now.

[OliverZeiser]

@lucabandMSFT
I can not confirm that this is working. I did the modifications in the manifest and doublechecked that they are correct. But when I look at it with fiddler this is what I am seeing:
I see a request to:
https://TENANT.sharepoint.com/teams/spfxtest/_api/Microsoft.SharePoint.Internal.ClientSideComponent.Token.AcquireOBOToken?resource=%27https://graph.microsoft.com%27&clientId=...
But the response is:
{"odata.error":{"code":"-2147024891, System.UnauthorizedAccessException","message":{"lang":"en-US","value":"Access denied. You do not have permission to perform this action or access this resource."}}}

When running the same webpart it in the browser everything works fine. In the Teams client or mobile client it is not working. I am a Tenant Admin btw, so it should not be a permission issue.

[lucabandMSFT]

@OliverZeiser, thanks. Did you also visited back the "Manage API" page once you did the modification of the manifest in AAD Portal?

[OliverZeiser]

@lucabandMSFT Yes, i just did that. Still not working though. I will try again in a few hours and see if that works..

[OliverZeiser]

@lucabandMSFT Okay, NOW it is working :)
Thank you!

[lucabandMSFT]

@OliverZeiser , glad to hear that 👍

[NickSevens]

@lucabandMSFT I'm experiencing the same issue (I think) on a MS Teams app, loading a SP page with SPFx webpart on it. It works fine in the web client, not on desktop client.
I tried the manifest-editing workaround, and now see this error message in fiddler:

/sites/.../_api/Microsoft.SharePoint.Internal.ClientSideComponent.Token.AcquireOBOToken?resource='9bebc8ed-8a93-4efc-84a3-ae979d301124'&clientId='add82f27-80e9-45e3-9cf5-345e72d24ff7'
{"odata.error":{"code":"-1, System.AggregateException","message":{"lang":"en-US","value":"One or more errors occurred."}}}

[TheTedAdams]

Just because I worry the instructions as written are slightly unclear I just wanna make sure it's understood...

In the manifest there is an entry like this:

"oauth2Permissions": [
    {
        "adminConsentDescription": "Allow the application to access SharePoint Online Client Extensibility Web Application Principal on behalf of the signed-in user.",
        "adminConsentDisplayName": "Access SharePoint Online Client Extensibility Web Application Principal",
        "id": "[THIS IS THE ID THAT YOU WANT TO COPY]",
        "isEnabled": true,
        "lang": null,
        "origin": "Application",
        "type": "User",
        "userConsentDescription": "Allow the application to access SharePoint Online Client Extensibility Web Application Principal on your behalf.",
        "userConsentDisplayName": "Access SharePoint Online Client Extensibility Web Application Principal",
        "value": "user_impersonation"
    }
],

You need that ID, and then you need to replace your preAuthorizedApplications entry with:

"preAuthorizedApplications": [
    {
        "appId": "00000003-0000-0ff1-ce00-000000000000",
        "permissionIds": [
            "[THIS IS WHERE YOU PUT THE COPIED ID]"
        ]
    }
],

I only bring it up because when I read the instructions I wasn't sure if I should be putting the copied ID in the appId or in the permissionIds array, and wanted to make sure nobody else made that mistake.

[lucabandMSFT]

@TheTedAdams, that's exactly correct. Thank you very much for providing such important clarification.
@NickSevens, where you able to get unblocked by following the updated instructions provided by Ted above?

[NickSevens]

@lucabandMSFT I was not. The error is still the same. The updated instructions are what I did in the first place - so no help for me there :)

[lucabandMSFT]

@NickSevens , do you mind sharing your manifest? also, to be 100% sure we get all the information right, you did visit the "manage API" page in SharePoint after you edited the Manifest in AAD, yes?

[NickSevens]

@lucabandMSFT sure

{
    "id": "180b0848-80e7-4882-84bc-d573e892c6ef",
    "acceptMappedClaims": null,
    "accessTokenAcceptedVersion": null,
    "addIns": [],
    "allowPublicClient": null,
    "appId": "add82f27-80e9-45e3-9cf5-345e72d24ff7",
    "appRoles": [],
    "oauth2AllowUrlPathMatching": false,
    "createdDateTime": "2019-05-09T07:19:41Z",
    "groupMembershipClaims": null,
    "identifierUris": [
        "https://microsoft.spfx3rdparty.com"
    ],
    "informationalUrls": {
        "termsOfService": null,
        "support": null,
        "privacy": null,
        "marketing": null
    },
    "keyCredentials": [],
    "knownClientApplications": [],
    "logoUrl": null,
    "logoutUrl": null,
    "name": "SharePoint Online Client Extensibility Web Application Principal",
    "oauth2AllowIdTokenImplicitFlow": true,
    "oauth2AllowImplicitFlow": true,
    "oauth2Permissions": [
        {
            "adminConsentDescription": "Allow the application to access SharePoint Online Client Extensibility Web Application Principal on behalf of the signed-in user.",
            "adminConsentDisplayName": "Access SharePoint Online Client Extensibility Web Application Principal",
            "id": "496fc11e-8713-4b37-8a27-1a511275d1e4",
            "isEnabled": true,
            "lang": null,
            "origin": "Application",
            "type": "User",
            "userConsentDescription": "Allow the application to access SharePoint Online Client Extensibility Web Application Principal on your behalf.",
            "userConsentDisplayName": "Access SharePoint Online Client Extensibility Web Application Principal",
            "value": "user_impersonation"
        }
    ],
    "oauth2RequirePostResponse": false,
    "optionalClaims": null,
    "orgRestrictions": [],
    "parentalControlSettings": {
        "countriesBlockedForMinors": [],
        "legalAgeGroupRule": "Allow"
    },
    "passwordCredentials": [],
    "preAuthorizedApplications": [
        {
            "appId": "00000003-0000-0ff1-ce00-000000000000",
            "permissionIds": [
                "496fc11e-8713-4b37-8a27-1a511275d1e4"
            ]
        }
    ],
    "publisherDomain": "dvine.work",
    "replyUrlsWithType": [
        {
            "url": "https://dlw365.sharepoint.com/",
            "type": "Web"
        },
        {
            "url": "https://dlw365.sharepoint.com/_forms/spfxsinglesignon.aspx",
            "type": "Web"
        },
        {
            "url": "https://dlw365.sharepoint.com/_forms/spfxsinglesignon.aspx?redirect",
            "type": "Web"
        }
    ],
    "requiredResourceAccess": [
        {
            "resourceAppId": "00000002-0000-0000-c000-000000000000",
            "resourceAccess": [
                {
                    "id": "311a71cc-e848-46a1-bdf8-97ff7156d8e6",
                    "type": "Scope"
                }
            ]
        },
        {
            "resourceAppId": "00000003-0000-0000-c000-000000000000",
            "resourceAccess": [
                {
                    "id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d",
                    "type": "Scope"
                }
            ]
        }
    ],
    "samlMetadataUrl": null,
    "signInUrl": null,
    "signInAudience": "AzureADMyOrg",
    "tags": [],
    "tokenEncryptionKeyId": null
}

And yes, I did indeed visit the "manage API" page several times before and after the manifest change.

[lucabandMSFT]

Hey @NickSevens , we really don't see anything wrong on the manifest. Would be possible for us to either access the environment or have a screen sharing session with you?

Feel free to follow up privately at luca.[email protected]

[NickSevens]

@lucabandMSFT I'll send you an email. Thanks for the follow-up.

[lworkman]

@lucabandMSFT Is there somewhere I check on the progress for the proper fix? Our SPFX application customizer is used by a couple dozen companies, and getting them to all make the manual change isn't really viable.

Can you also confirm whether or not once the fix goes out there users will have to do any updates?

[MaheshakaMudli]

@lucabandMSFT : We had tried this on one of our dev tenant and the changes got reflected in sometime. But now we are trying to replicate the same in other tenants(test,prod) but it does not seem to work. You can check the manifest file which we have edited. Is there something else which we are missing.

[TheTedAdams]

@lucabandMSFT I reported that the fix worked for us... and it did for some time. But I just received a report that our SPFx web part quit working in the Teams application, and I verified in my demo environment where it was previously working that it is no longer getting a graph token.

Did something change in the background that renders your earlier fix ineffective? As before, works in browser version of Teams, does not work in applications. We made our customers go through the difficult install process of editing JSON etc. so having this quit working is a major bummer...

[lucabandMSFT]

Folks, thanks for continuing to provide feedbacks.
We had to disable the capability temporarily as we found some issues on the underneath technology we use to do tokens exchange.

We have fixed the issue and now we are testing it internally before release it broadly.

From now on, let's use this other issue to track progresses here: #3923 .
We hope to be able to re-enable this capability soon.. expect an update from me soon.

Thanks again

[lucabandMSFT]

Ok, good news:
We have finalized the fix and it is currently rolling right now in production. As soon as it hits 100% of our production environments we will turn the capability back on.
As things state right now, we are planning to re-enabling the capability by Friday this week.

I will provide an update by Friday no matter what.

Thanks for your patience and please keep providing super valuable feedback!
Luca

[michel-weber]

As stated here:

https://github.com/SharePoint/sp-dev-docs/issues/3923 it is re-enabled.

[PieterHeemeryck]

@lucabandMSFT @TheTedAdams I can confirm this fix works for me !

[lucmoco]

The problem was also fixed in our application. Congrats :-)

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues