Sp-dev-docs: Breaking change on creating content types using CSOM - Value cannot be null

[siata13]

Category

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

When applying PnPTemplate that contains a content type definition, provisioning fails with the error:
"Apply-PnPProvisioningTemplate : Value cannot be null.
Parameter name: s"

I have observed the problem on 14.05.2019 without changes to PnP engine version (used the latest one). I believe that the problem is not related to PnP but to O365 backend. Sample template definition that fails:

<?xml version="1.0"?> <pnp:Provisioning xmlns:pnp="http://schemas.dev.office.com/PnP/2018/05/ProvisioningSchema"> <pnp:Preferences Generator="OfficeDevPnP.Core, Version=2.20.1711.0, Culture=neutral, PublicKeyToken=3751622786b357c2" /> <pnp:Templates ID="TEST-TEMPLATES"> <pnp:ProvisioningTemplate ID="TEST" Version="1" Scope="RootSite"> <pnp:SiteFields> <Field Type="Text" DisplayName="TestField" Name="TestField" StaticName="TestField" Description="TestField" Required="FALSE" EnforceUniqueValues="FALSE" Indexed="FALSE" MaxLength="255" Group="TEST" ID="{b280c2fa-7aba-40a2-8d9a-e2e23984c305}" SourceID="{{siteid}}" ></Field> </pnp:SiteFields> <pnp:ContentTypes> <pnp:ContentType ID="0x0100240A55DF4AAE484BAFA63308338F5501" Name="TestCT" Description="" Group="TEST" NewFormUrl="" EditFormUrl="" DisplayFormUrl=""> <pnp:FieldRefs> <pnp:FieldRef ID="fa564e0f-0c70-4ab9-b863-0177e6ddd247" Name="Title" Required="true" /> <pnp:FieldRef ID="b280c2fa-7aba-40a2-8d9a-e2e23984c305" Name="TestField" /> </pnp:FieldRefs> </pnp:ContentType> </pnp:ContentTypes> </pnp:ProvisioningTemplate> </pnp:Templates> </pnp:Provisioning>

Observed Behavior

Exception is thrown:
Apply-PnPProvisioningTemplate : Value cannot be null.
Parameter name: s
At line:1 char:1

• Apply-PnPProvisioningTemplate -Path $path
• ~~~~~~~~~
  
  
  
  • CategoryInfo : WriteError: (:) [Apply-PnPProvisioningTemplate], ServerException
  
  
  • FullyQualifiedErrorId : EXCEPTION,SharePointPnP.PowerShell.Commands.Provisioning.Site.ApplyProvisioningTemplate
  
  

Steps to Reproduce

Deployment of PnP Template with CT definition. Attached sample can be used.

Thanks for your contribution! Sharing is caring.

[msft-github-bot]

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

[VesaJuvonen]

Thx @siata13 for reporting this. This seems to be a breaking change in the server side, which we are now actively investigating. Here's a duplicate entry in the PnP Sites Core and in the PnP PowerShell repositories for this one for tracking purposes. I also changed the title to be more descriptive with the oob capabilities as this is not about the PnP wrapper.

In short - there seems to be a breaking change in the oob CSOM for handling content types in server side.

• https://github.com/SharePoint/PnP-Sites-Core/issues/2240
• https://github.com/SharePoint/PnP-PowerShell/issues/2087

[VesaJuvonen]

All repro steps also without PnP template are more than welcome in the tenants which have the issue... if you have possibility to test things with native CSOM and without the template. This will rule out root cause options. Thanks for any further details advance.

[cverhelst]

We've logged a ticket with our tenant for the exact same error description. Debugging in Pnp Sites core I managed to track this down to the fields being reordered on the content type.

When I disabled this on creation & update, the provisioning code works fine.

You get an "Unexpected error" when doing this in the browser as well, so it does not seem to be PnP specific.

[cverhelst]

Note that not every pnp provisioned content type update would trigger this error because the fields may already be in the right order.

[advdberg]

I've tried to just add the content type with PnP PowerShell, but was NOT able to reproduce it that way. So no error occurs. While with the template it still fails.

$documentCT = Get-PnPContentType -Identity "Document"
Add-PnPContentType -ContentTypeId "0x0100FA46988B78C6438D9F618CCDCA592331" -Group "MyFirstContentTypeGroup" -Name "MyFirstContentType" -Description "My description"

When looking at the sample in SharePoint/PnP-Sites-Core#2240 there's no reordering in my opinion.

[vladivanovrf]

I can confirm that CSOM works as expected, this is the issue in PnP.

[vladivanovrf]

Sorry guys, I've made some more tests on content type deployment and faced the same error message from native CSOM API (outside PnP Sites Core). So, it looks like the issue is somewhere in SharePoint's backend in the content type fields reordering section.

[advdberg]

@vladivanovrf do you have an example of your tests?

I've also tested the following (PowerShell) code and it works as expected. What am I missing?

$ctx = Get-PnPContext
$ctCreation = New-Object Microsoft.SharePoint.Client.ContentTypeCreationInformation
$ctCreation.Id = "0x0100FA46988B78C6438D9F618CCDCA592333"
$ctCreation.Name = "MyFirstContentType"
$ctCreation.Description = "My description"
$ctCreation.Group = "MyFirstContentTypeGroup"
$ctx.Site.RootWeb.ContentTypes.Add($ctCreation)
$ctx.ExecuteQuery()

[VesaJuvonen]

We just confirmed this to be a change on the server side APIs related on the field reorder, like also mentioned above by @cverhelst and @vladivanovrf. It's caused by a situation where you execute the fields reorder without any fields for a content type. Recent change in server side API did not take this into account and unfortunately PnP provisioning engine will call the reorder for fields in a content type regardless if there are any.

We are working now on two sides:

• New PnP Sites Core CSOM assembly will be released today (ETA few hours) which will do the workaround for skipping the ReOrder call for content type when there's no fields. This will address the issue from PnP provisioning engine perspective in upcoming hours.
• We have internal threads moving on addressing the server side API change to include a checkup for the fields, which will be addressed in server side code. Getting that changed deployed worldwide will take much longer after the requested change has been approved, but will update this thread on the progress as have any.

Thanks everyone for sharing your test results and insights on the repro. These helped us to move forward on providing initial fix as fast as in few hours after identifying the root cause.

Root cause of the issue - if you execute following code, you will get the same exception:
ContentType.FieldLinks.Reorder(new string[] { });

[advdberg]

@VesaJuvonen to be 100% clear, will there also be an update available of the PnP PowerShell module then, including the updated PnP Sites Core?

[VesaJuvonen]

@advdberg - Yes - We are working on providing update for PnP Sites Core NuGet and for PnP PowerShell as a quick workaround. Basically we change those modules to be aware of this underlying issue, so if you use the PnP wrappers, you will not be impacted.

[69mustang302]

I have three tenants, one gives the exception, two other don't. I assume Microsoft is rolling out update gradually, so i will expert this issue to be present on all tenants shortly.

[in8jaira]

Our production environment is impacted due to this issue and we are not able to provision the new sites via PnP provisioning. Please suggest:

1. Do we need to update PnP Powershell module in our code to get this working
2. By when this fix will be available

Thanks,
Rakhi Jain

[SBajonczak]

Our production environment is impacted due to this issue and we are not able to provision the new sites via PnP provisioning. Please suggest:

1. Do we need to update PnP Powershell module in our code to get this working
2. By when this fix will be available

Thanks,
Rakhi Jain

Like the Post from @VesaJuvonen it seem to be, that we must update the pnp.core assembly and the fix will be available in a few hour.

[cverhelst]

@VesaJuvonen

It's caused by a situation where you execute the fields reorder without any fields for a content type.

Not certain you mean to say this scenario was the only one causing this issue, but I (and others) experienced this issue in the browser when trying to move any field on any content type, as well as using CSOM with any input to the .Reorder() function on the FieldLinks property of a content type.

Just to make sure you're aware this was not exclusive to calling .Reorder() with an empty array.

[mag210]

Hi all, to note I am having the exact same issue. Provisioning scripts that use to work are now failing. For me this happens when the provisioning engine attempts to add a site column to a custom content type. This is on the latest version of PNP Powershell (version 3.9.1905.0) but the tenant is not first release.

Interestingly when running the apply pnp-provision it does actually put the content types in, (even though it errors). So if you re-run the command sufficient times, eventually the template is successfully applied.

[VesaJuvonen]

Thx @cverhelst for the additional test details. It is indeed reproducible from the _layouts/15/ManageContentType.aspx user interface, which clearly shows that it's a server side API issue.

We are actively working on this internally, but if anyone has Premier support, please do open up a case to ensure that we get the scale of the issue identified and situation fixed as soon as possible.

We are looking into ways to reduce the impact of this issue by potentially providing a workaround fixes through PnP CSOM NuGet package and PnP PowerShell, but we can't fix the root cause directly, as fast ans the PnP components, as it's in the server side APIs. Root cause fixes are being also investigated and worked on, but timeline is still unclear.

@mag210 - PnP provisioning engine uses oob CSOM and when you add a site column to content type, it uses the Reorder method, which is then causing your operation to fail. Issue is NOT in the PnP engine, it's in the server side APIs as issue can be reproduced also using native CSOM or using UI in this case.

There's no ETA for resolving this fix for now. Please do open a Premier Support issue if you need to have updated status asap. We will keep on updating this thread also as soon as we have any updates.

[patrick-blanc]

Hi @VesaJuvonen
I had the same findings are yours. Means breaking change on ootb api. The problem is that now you plan to release a fix in the pnp nugget or powershell packages. That's find if we can upgrade to this package version.

On our side, we do not think a breaking changes should occured in a ootb api. If a breaking changes is pushed, then you should think about creating versioning endpoint for this api to keep them both working.

[VesaJuvonen]

We are currently in progress for releasing updated PnP Sites Core NuGet (provisioning engine) and PnP PowerShell to provide a short term workaround for addressing the server side issue. New versions will skip the Reorder call to ensure that normal provisioning scenarios will work as expected.

That can cause minimal changes on the usage of the engine, but it will also ensure that the basic scenarios are working as expected even before the server side API fixes are completed and rolled out.

@patrick-blanc - 100% agree that breaking changes should not be done in server side APIs and we are working on rolling this change back. This was caused by a human mistake and absolutely agree that we should ensure that both are working without these kind of issues in future. This is not intended situation and we are ONLY providing updated NuGet and PnP PowerShell cmdlets to help to reduce the impact of the server side API issue, until that has been fully fixed.

[PzKfWg]

Thanks for taking care of this quickly @Vesa, I felt quite helpless and alone yesterday! I am one week to releasing a big project to a client based on PNP provisioning and felt like a fool yesterday when doing some final tests...

Indeed a serious post mortem should be done at MS as to how this breaking change got to production on the first place!

[VesaJuvonen]

Updated PnP SItes Core CSOM NuGet is now available in NuGet gallery. This is a short term fix for skipping all Reorder calls in the provisioning engine. It is just a "bubble gum" fix to skip the broken API call, but it should most or all of the provisioning engine scenarios fixed.

• https://www.nuget.org/packages/SharePointPnPCoreOnline/3.9.1905.1

We are obviously also working on providing matching PnP PowerShell package and on the root cause fix for the server side APIs, but having this quick fix, should help at least some of you.

[SBajonczak]

I have tested the new version, it works like a charm! Many many thanks :) Sending you many Kudos!

[VesaJuvonen]

thx @SBajonczak for confirming the provisioning engine fix in the PnP CSOM Core NuGet package.

ETA for PnP PowerShell workaround fix is 2-3 hours.
No ETA at this point for the server side API root issue.

We will keep on updating this thread as we have any updates.

[mag210]

Thanks @VesaJuvonen , please do let us know when the PnP PowerShell fix is ready to go. I assume we will need to update to this new version in any location where we are doing site provisioning (including via Azure functions etc)

[Pieter-Veenstra-Triad]

I've got the same issue. My steps were.

Create 2 team site collections. ( Team1 and Team2)

In team site 1 create 2 content types.

Then run the following script:

Connect-PnPOnline -Url https://tenant.sharepoint.com/sites/team1 -UseWebLogin

Get-PnPProvisioningTemplate -Out c:\temp\export.xml

Connect-PnPOnline -Url https://tenant.sharepoint.com/sites/team2 -UseWebLogin

Apply-PnPProvisioningTemplate -Path c:\temp\export.xml

The result no is:

Apply-PnPProvisioningTemplate : Value cannot be null.
Parameter name: s
At C:\Users\pveenstra\Documents\ExportImport.ps1:7 char:1

• Apply-PnPProvisioningTemplate -Path c:\tempexport.xml
• ~~~~~~~~~~~~~~
  
  
  
  • CategoryInfo : WriteError: (:) [Apply-PnPProvisioningTemplate], ServerException
  
  
  • FullyQualifiedErrorId : EXCEPTION,SharePointPnP.PowerShell.Commands.Provisioning.Site.ApplyProvisioningTemplate
  
  

[VesaJuvonen]

thx @Pieter-Veenstra - all operations working around the SPContentType and using the Reorder method are impacted. PnP Provisioning uses that by default when content types are created, which is the case in your steps. We have already provided update for the CSOM NuGet, PnP PowerShell cmdlet update is coming also soon, which will be addressing this as a workaround fix.

No ETA for fixing the root issue at the server side API at this point.

[69mustang302]

@VesaJuvonen We just opened a case through premier support as requested.

[mag210]

Hi all, just to note, I have tested with the latest release of PnP Powershell (3.9.1905.1) which looks like has just been uploaded and can confirm that this resolves the content type creation issue. Our template sites now seem to create as normal. Will continue to test. Release is available at: https://github.com/SharePoint/PnP-PowerShell/releases

[PzKfWg]

Also tested this new version with local and Azure Automation runbook module with success. What a relief!

[VesaJuvonen]

Just to follow up on the progress.

• Updated PnP PowerShell is available which is skipping the problematic server side API in template handling - see https://www.powershellgallery.com/packages/SharePointPnPPowerShellOnline/3.9.1905.1
• No updates for the server side API status or an ETA for that

Thanks for opening the Premier Support cases for following up on the server side API issue. These are good for tracking the root cause and ensuring that it gets fixed as soon as possible.

[VesaJuvonen]

Update on the status - noon PDT.

• No additional details on the server side API status or ETA for the fix
• If you are using PnP PowerShell or PnP provisioning, please update to latest versions as they have been changed to skip the server side issue related on the ContentType.FieldLinks.Reorder method.

Please do open a Premier Support case or standard support case from Tenant Admin UIs if you do run into this API issue or UI issue in the Site Settings content type gallery pages, so we get the scale of the issue reported properly. Thanks for your reports advance and we do apologize the inconvenience this might be causing.

[nikhil-zaware]

Awesome facing this issue from yesterday but the new version of nugget package (https://www.powershellgallery.com/packages/SharePointPnPPowerShellOnline/3.9.1905.1) worked for me.

Thanks

[Kannabirank]

Thanks for the update. I've been struggling with this since yesterday and the latest package resolved this issue... https://www.powershellgallery.com/packages/SharePointPnPPowerShellOnline/3.9.1905.1
Thanks,
Kannan

[VesaJuvonen]

Thanks everyone for confirming that the workaround fix in the PnP PowerShell and NuGet package side is working as expected.

Status on the root issue on the server side APIs:

• Issue has been identified and fixed in the server side source code
• Fix is planned to get fully applied to production worldwide within next 36 hours
• Any customer who have opened a Premier Support case will be prioritized for patching

This means that the root issue at the server side APIs should be fully fixed by end of the day Friday 17th of May. We will be doing an internal postmortem analyses on this issue to minimize possibility for similar mistakes in the future.

We will be rolling back the workaround fix in the PnP components latest by June 2019 release as it does have a small impact on the supported capabilities, but we need to ensure that the ContentType.FieldLinks.Reorder method is first fully fixed in the server side, before this can be performed.

We will be providing any updates on this issue still during this week, but will close it when we have confirmed that the patch is fully deployed worldwide. We do apologize the inconvenience caused by this accident.

[SimSpfx]

Is it possible that there is another update that breaks parameters in templates? All the {param} are not resolved and appear as {param} after the deployment.

[VesaJuvonen]

@SimSpfx - this issue is around the server side APIs in SharePoint Online and not related on the actual PnP templates. If you have any issues with the parameters in the templates, please submit an new issue at https://github.com/SharePoint/PnP-Sites-Core/issues with the exception and environment (used versions etc) details. Thx.

[poikjo]

Looks like there is an issue on new versions that break {parameter} handling. But let's continue on that new issue: Provisioning succeeds but parameters are not resolved in pnp templates

[OTV64]

Hi, now I have the followed error : The specified user {associatedowneridgroup} could not be found.

I use the SharePointPnPCoreOnline 3.9.1905.2, and the error occured when call the method "ApplyProvisioningTemplate" on "Site Security" step.

Does anyone else reproduce this problem?

[VesaJuvonen]

@OTV64 - This issue is around the server side API issue. If you have any issues on the PnP templates, please submit an issue to https://github.com/SharePoint/PnP-Sites-Core/issues with the right details for reproduction. Which version to where you updated. What's in your template etc. Thx.

[in8jaira]

@OTV64 : We are also getting the same issue. When I am generating a new template and try to apply the template using pnp, I am getting the same error:
The specified user {associatedowneridgroup} could not be found.

@VesaJuvonen : Please suggest how to move forward with this as the issue is impacting our activities in production environment.

[tomislavtasic]

I had the same issue with my script. I have solved it by removing "Repost Page" content type from XML files. See the images added to this comment -> Image 1, Image 2, Image 3 & Image 4.

[VesaJuvonen]

@in8jaira - This issue is around the server side issue on the content type handling. It's not beneficial for submitting new issues as a random comments on existing issues, which is why requested any other issue opened as a new issue. That associatedowneridgroup issue has nothing to do with the Reorder method challenge which is getting currently rolled out worldwide in the SPO.

I think this is the issue which you are looking for related on the permissions - https://github.com/SharePoint/PnP-Sites-Core/issues/2245

Let's not mix-and-match multiple issues to one as that not beneficial for anyone as it only means that some comments will get lost. Thx.

[cverhelst]

@VesaJuvonen On our tenant the fix was implemented and our issue was resolved. Thank you for your quick follow up and clear communication!

[christopher-walker]

Thought I would spend this evening updating to the latest CSOM version, but when I retried the deployment scripts in our environment all back back to normal. It seems in our tenant the problem has been resolved server side.
Thank you for keeping us up to date on this issue @VesaJuvonen i guess this isnt the best possible moment for everyone with SPNA around the corner. Hope you have a good conference.

[VesaJuvonen]

Should have closed this while back already. Sorry for the inconvenience and closing this as solved.

[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