Sp-dev-docs: Get-PnPTenantSite : System.InvalidOperationException: The type of data at position 1684 is different than the one expected.

[siata13]

Hi,

When try to obtain the PnPTenantSite information exception is thrown. Seems, it is related to parsing of the JSON result received from O365. I have checked the traffic with fiddler and it seems that the result coming from O365 is correct.

Category

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

Steps to reproduce behavior

Execute 'Get-PnPTenantSite' cmdlet with or without parameters.

Expected behavior

Receive TenantSite / List of TenantSite objects.

Actual behavior

Exception is thrown:

System.InvalidOperationException: The type of data at position 1687 is different than the one expected.
at Microsoft.SharePoint.Client.JsonReader.ReadGuid()
at Microsoft.Online.SharePoint.TenantAdministration.SiteProperties.InitOnePropertyFromJson(String peekedName, JsonReader reader)
at Microsoft.SharePoint.Client.ClientObject.FromJson(JsonReader reader)
at Microsoft.SharePoint.Client.ClientRequest.ProcessResponseStream(Stream responseStream)
at Microsoft.SharePoint.Client.ClientRequest.ProcessResponse()
at Microsoft.SharePoint.Client.ClientRequest.d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.SharePoint.Client.ClientRequest.d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.SharePoint.Client.ClientRuntimeContext.d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.SharePoint.Client.ClientContext.d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
at Microsoft.SharePoint.Client.ClientContextExtensions.d__7.MoveNext()

[msft-github-bot]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[andrewconnell]

This seems related to the PnP Core PowerShell component... best to submit this question to that specific repo's issue list: https://github.com/SharePoint/PnP-Sites-Core

[siata13]

It is not related to PnP Core Powershell. The exception is coming from Microsoft.SharePoint.Client.JsonReader.ReadGuid().

Please reopen.

[VesaJuvonen]

The issue is in the underlying CSOM APIs or specifically in the server side APIs and is being worked on. Path deployment should get on hold and canceled so we should not have new tenants experiencing this anymore. The fix is being worked on and it will be shipped server side as soon as possible, but can't provide an exact ETA at this point.

Thanks for reporting this.

[theportalshop]

Thank you very much for addressing this. Have a client tenant that is adversely affected by this bug. Thanks again.

[joecmajor]

This is affecting both our Live and Dev tenancy's with this issue.

[mdissel]

@VesaJuvonen any ETA / updates? We have many customers who are all having this problem when provisioning sitecollections.

[marcoschmucker]

We do have several customers, along with different DEV/ TEST and PROD tenants who are affected when provisioning site collections.

[koskila]

Thanks for the clarification, @VesaJuvonen ! I can also confirm we have several environments being affected by this issue, so we are eagerly awaiting new updates :)

[VesaJuvonen]

Thanks, everyone for following up on this with updates. I'll try to get the latest status from owners of the issue and share it here asap.

[fredericklin]

We are being impacted as well with Azure Automation scripts that have a dependency on this functionality.

[DwayneMacisaac]

Have they considered backing out the changes on the affected Tenants, until they have a fix?

[theportalshop]

Have they considered backing out the changes on the affected Tenants, until they have a fix?

+1 What he said.

[spkimc]

Our production and development tenants suffered this problem on March 12 - 13, but now it is no longer an issue as of March 14th.

[VesaJuvonen]

I do not have yet ETA for this, but things are actively being worked on. Thanks, everyone for the updates as they do help others to see how things are progressing cross the tenants. Transparency will reduce confusion.

[theportalshop]

Our production and development tenants suffered this problem on March 12 - 13, but now it is no longer an issue as of March 14th.

Per what spkimc also just mentioned, my client's tenant that was experiencing the issue 12th & 13th is also no longer experiencing it today (the 14th). Obviously no idea if that is a roll back or a fix, but its working for now so thank you very much for the support and communication.

[VesaJuvonen]

The fix is currently being rolled out worldwide, so the issue should be resolved for everyone within upcoming hours. Please do provide updates on your tenant status. If the issue still exists after a few hours, please do report that in here as well. Thanks, everyone for your activity on this.

[fredericklin]

It is working again. Thanks for the fix.

[spkimc]

Yesterday I had this error at the beginning of script when creating a site collection app catalog. This line, $ctx.ExecuteQuery(), caused this error:
Exception calling "ExecuteQuery" with "0" argument(s): "The type of data at position 1144 is different than the one expected."

Today, I have been successful in passing the above point in the scripts and in building a hierarchy of 6 sites but right near the end of my scripts I see it again when I am turning off minor versioning on the site pages library: Invoke-PnPQuery : The type of data at position 1145 is different than the one expected.

While the minor versioning is successfully turned off but this Invoke-PnPQuery is returning the above error every time.

[joecmajor]

All working again in both Production and Dev tenancy's. Many thanks for the fix and updates.

[siata13]

It is working on my tenants as well. @VesaJuvonen thank you for your help!

[tavikukko]

Get-PnPTenantSite seems to work ok now, but, you cannot create sitecollection with "publishing portal" template from admin center UI, the task never ends. To create classic teamsite, it works ok. So something to do still with activating publishing feature?

trying to create publishing portal:

teamsite create ok:

[phawrylak]

@VesaJuvonen, fix doesn't seem to be rolled out to the tenant of one of our customers and it's really big problem for us, because CSOM in our app stopped working. I have sent you tenant id via e-mail.

[poikjo]

I can also see issue still on my tenant.

[VesaJuvonen]

Thanks, everyone on your status updates. I'll check things internally and try to get back asap. The update is rolling out gradually, so having some tenants already working and some don't, is understandable.

[VesaJuvonen]

Quick update - Fix is still in progress to get fully rolled out, so it's understandable that some have this already fixed and it's still an issue in some tenants. The situation should be fully resolved within the next 12 hours unless there are unexpected delays.

[stvwllms]

We are not seeing the error anymore but are getting intermittent time outs on Get-PnPTenantSite, GetSPOSite...

[phawrylak]

@VesaJuvonen, unfortunately the bug is still there.

[poikjo]

My tenant is fixed.

[jimmywim]

My tenant's fixed

[swjensen]

We got the error when creating a Teams from an existing Group. The error is gone, but now we are getting this error instead:
{
"error": {
"code": "BadRequest",
"message": "Entity only allows writes with a JSON Content-Type header.",
"innerError": {
"request-id": "0912aea8-c336-49e4-9a68-e38f0dc5577b",
"date": "2019-03-18T11:36:35"
}
}
}

[DwayneMacisaac]

Still getting the error as well.
We have had this issue for a week. When is it going to be fixed?

[koskila]

I can confirm that this issue has been fixed on all 2 of my tenants where I saw this. While we're still experiencing issues with site provisioning, I suppose they're not connected to this particular change?

[bjdekker]

@koskila @tavikukko we also have problems with the site provisioning of Publishing Portals, we get the same error as @tavikukko and the site never gets created. I created a site collection without a template and tried to apply the publishing portal template after creating, but I got the following error:

Probably related to this:

The deployment of the fix is scheduled for 23 March, which is very late, regarding that it is impossible to create new site collections for nearly two weeks now. Can't it be deployed any sooner?

[phawrylak]

My affected tenant was finally patched.

[tavikukko]

All good here too

[VesaJuvonen]

We do understand that this was far from the optimal situation, but thanks for following up with the status updates. Based on our patch tracking, the issue should be now resolved worldwide, so closing this one. We do apologize for the inconvenience caused by this issue and are working on actions to prevent similar issues in the future.

[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