Add-PnPPage broken: One of the identified items was in an invalid format.

[ohaak2]

Provisioning new client side pages using a PnP template fails with error 'One of the identified items was in an invalid format'.

Error is reproduceable by the following steps:

1. Create a new plain-vanila page in a SharePoint site.
2. Export the page as PnP template using Export-PnPPage.
3. Delete the page in the site.
4. Try recreating the page by applying the previously exported PnP tempalte using Invoke-PnPTemplate. This will produce the error 'One of the identified items was in an invalid format'. The page nevertheless has been created, but somehow is incomplete / non functional.
5. Re-applying the template by calling Invoke-PnPTemplate again won't change a thing.

Interestingly the template will be applied without issues, if the page already exists in the site. So currently it's a kind of work around for me to first create the page using SharePoint GUI and then applying the template.

Please note: We don't have that issue in all tenants, but we can now reproduce it at least in two of them.

Issues can be nailed down to the actual page creation process:

Creating a new page like this:

Add-PnPPage -Name "TEST"

Result: Add-PnPPage: One of the identified items was in an invalid format.

The underlying exception is this:

Exception             :
    Type       : System.FormatException
    TargetSite :
        Name          : GetGuid
        DeclaringType : System.Text.Json.JsonElement
        MemberType    : Method
        Module        : System.Text.Json.dll
    Message    : One of the identified items was in an invalid format.
    Data       : System.Collections.ListDictionaryInternal
    Source     : System.Text.Json.Rethrowable
    HResult    : -2146233033
    StackTrace :
   at System.Text.Json.JsonElement.GetGuid()
   at PnP.Core.Model.SharePoint.FieldTaxonomyValue.FromJson(JsonElement json)
   at PnP.Core.Services.JsonMappingHelper.ProcessSpecialRestFieldTypeAsync(TransientObject pnpObject, String propertyName,
JsonElement json)
   at PnP.Core.Services.JsonMappingHelper.FromJsonRest(TransientObject pnpObject, EntityInfo entity, ApiResponse apiResponse,
Func`2 fromJsonCasting)
   at PnP.Core.Services.JsonMappingHelper.FromJson(TransientObject pnpObject, EntityInfo entity, ApiResponse apiResponse, Func`2
fromJsonCasting)
   at PnP.Core.Model.BaseDataModel`1.ProcessResponseAsync(ApiResponse apiResponse, Expression`1[] expressions)
   at PnP.Core.Services.JsonMappingHelper.FromJsonRest(TransientObject pnpObject, EntityInfo entity, ApiResponse apiResponse,
Func`2 fromJsonCasting)
   at PnP.Core.Services.JsonMappingHelper.FromJson(TransientObject pnpObject, EntityInfo entity, ApiResponse apiResponse, Func`2
fromJsonCasting)
   at PnP.Core.Services.JsonMappingHelper.MapJsonToModel(BatchRequest batchRequest)
   at PnP.Core.Services.BatchClient.ProcessSharePointRestInteractiveResponse(BatchRequest restRequest, HttpStatusCode
statusCode, Dictionary`2 responseHeaders, Stream responseContent)
   at PnP.Core.Services.BatchClient.ExecuteSharePointRestInteractiveAsync(Batch batch)
   at PnP.Core.Services.BatchClient.ExecuteSharePointRestBatchAsync(Batch batch)
   at PnP.Core.Services.BatchClient.ExecuteBatch(Batch batch)
   at PnP.Core.Model.BaseDataModel`1.BaseRetrieveAsync(ApiCall apiOverride, Func`2 fromJsonCasting, Action`1 postMappingJson,
Expression`1[] expressions)
   at PnP.Core.Model.SharePoint.Web.GetFileByServerRelativeUrlAsync(String serverRelativeUrl, Expression`1[] expressions)
   at PnP.Core.Model.SharePoint.Web.GetFileByServerRelativeUrlOrDefaultAsync(String serverRelativeUrl, Expression`1[]
expressions)
   at PnP.Core.Model.SharePoint.Page.GetPageFileAsync(String pageName, IList pagesLibrary)
   at PnP.Core.Model.SharePoint.Page.EnsurePageListItemAsync(String pageName)
   at PnP.Core.Model.SharePoint.Page.SaveAsync(String pageName)
   at PnP.Core.Model.SharePoint.Page.Save(String pageName)
   at PnP.PowerShell.Commands.Pages.AddPage.ExecuteCmdlet() in c:\build\src\Commands\Pages\AddPage.cs:line 77
   at PnP.PowerShell.Commands.PnPSharePointCmdlet.ProcessRecord() in c:\build\src\Commands\Base\PnPSharePointCmdlet.cs:line 60
CategoryInfo          : WriteError: (:) [Add-PnPPage], FormatException
FullyQualifiedErrorId : EXCEPTION,PnP.PowerShell.Commands.Pages.AddPage
ErrorDetails          : One of the identified items was in an invalid format.
InvocationInfo        :
    MyCommand        : Add-PnPPage
    ScriptLineNumber : 1
    OffsetInLine     : 1
    HistoryId        : 16
    Line             : Add-PnPPage -Name "TEST"
    PositionMessage  : At line:1 char:1
                       + Add-PnPPage -Name "TEST"
                       + ~~~~~~~~~~~~~~~~~~~~~~~~
    InvocationName   : Add-PnPPage
    CommandOrigin    : Internal
ScriptStackTrace      : at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo :

By the way - the same is (not surprisingly) true, if one tries to remove such a broken page:

Remove-PnPPage -Identity 'TEST.aspx'

Result: Remove-PnPPage: One of the identified items was in an invalid format.

[ohaak2]

Some additonal information:

As mentioned above the page will nevertheless being created (kind of). Accessing the page from SitePages libray will get an error page like this (sorry it's in German, but I think you'll get the gist of it):

[ohaak2]

We've now identified the reason behind our issue. It's infact nothing tenant specifc but in our case occurs just on all intranet sites using a specific content type.

Content type was referencing a site taxonomy based site field that was configured to have a specific default value. The field definition contained a default value like this:

<Default>21;#Local|2ebe66bc-885a-49df-b930-20926596de15</Default>

The fact that the id number '21' here might not correlate to the correct value in the taxonomy hidden list was so far never an issue for any type of provisioning, but it seems to be now - and not just for items using the content type in question, but in fact for all items (site pages) created in the library (no matter which content type). Funny thing here is, that creating a new page using the same content type using SharePoint GUI has no issues.

Our fix is now changing the field definition like this:

<Default>-1;#Local|2ebe66bc-885a-49df-b930-20926596de15</Default>

Thanks to PnP PowerShell it's quite easy to fix all sites involved using something like this:

Set-PnPField -Identity 'Scope' -Values @{DefaultValue = '-1;#Local|2ebe66bc-885a-49df-b930-20926596de15' -UpdateExistingLists

[jansenbe]

@ohaak2 : scanning over this, seems your issue is resolved and it can be closed?

[ohaak2]

@jansenbe Yes, at least kind of "resolved": If it's intended that this kind of misconfiguration is actually breaking the page created with PnP, then that's ok, I guess. After all it is a misconfiguration "under the hood".

However, something must have changed to cause this. We haven't had this issue before and SharePoint itself has also no issue with that configuration while creating a new page.

[conncampbell]

This is not resolved as the issue effects the template system too.

[SaltySweats]

This is still an issue. Thank you @ohaak2 for the workaround. Replacing all default values in our pnp templates using -1 fixed the issue:

Calling Add-PnPPage or Invoke-PnPSiteTemplate for new pages work without issue.