Exception calling SPListCollection.Add: : Invalid field name. {1faa4902-9115-44b9-bba7-791441ca1d6f}

Brass Contributor

I get an exception when trying to create a new list using PowerShell (error also happens in C#).


This is my PowerShell:


$lists = $rootWeb.Lists
$index = $lists.Add("avrTest", "", [Microsoft.SharePoint.SPListTemplateType]::GenericList)


The error received is:


Exception calling "Add" with "3" argument(s): "Invalid field name. {1faa4902-9115-44b9-bba7-791441ca1d6f}


At line:1 char:1

+ $index = $lists.Add("avrTest", "", [Microsoft.SharePoint.SPListTempla ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException

    + FullyQualifiedErrorId : ArgumentException


The field referred to has nothing to do with a generic list, but it is a core field in ONET.XML (and in fieldswss4.xml:(

     <Field ID="{1FAA4902-9115-44B9-BBA7-791441CA1D6F}"

This is a SharePoint 2016 system, patched to the March 2017 CU, with the full Enterprise/BI stack installed.  The error was occurring on the previous pach level (Dec 2016 CU) as well.


I don't understand how this field is getting in the way, nor how to get around it.


Can anyone help me?




8 Replies

Hi @Andrew van Renen,


There are two fields that could be invalid here. Either the Lookup field that you are creating with the new list (this is unlikely to be the problem)


or the list that is used buy the lookup field. You might want to check your Docs library/list if the fields used by the lookup field exist or not. It looks like you are connecting to a field called SMTotalFileStreamSize while your new lookup field that is part of the new list also is called SMTotalFileStreamSize.



Thanks for the reply Pieter.


The thing is, I am not creating any lookup fields.  I am creating a straight-forward, unadorned, custom list, using hte Microsoft template, which should just have a Title field and the standard author and date fields.


I have no idea where the reference to SMTotalFileStreamSize is coming from.

That explains things a bit. I think this is an out of the bix lookup to a document library. Could it be that the document library where the field was exported from was renamed? What is the base template of the template file?
In the create list statement, I am using [Microsoft.SharePoint.SPListTemplateType]::GenericList as the template. It is the standard MS template for a custom list (not even a library). I am not adding any fields so it should just be creating a bog-standard custom list with just a Title field.
It isn't the list template that I am after. The problem is the list called Docs. docs isn't standard. The site template should be something like STS#0 and can be found near the top of the xml template file created by get-pnpprovisioningtemplate
Oh, okay. Now I get the drift of your questions.

So that XML fragment that I dropped in (and the associated reference to Docs) is nothing to do with me. That is one of the standard fields in SP 2016, in Microsoft's ONET.xml file.

The only reason I included that fragment is because of the error message I received, which referenced the ID of that field ("Invalid field name. {1faa4902-9115-44b9-bba7-791441ca1d6f}") (I think that is a field ID reference anyway).

I don't know anything about that field, nor do I want that field to be part of anything I am doing. All I am doing is running those 2 pieces of PowerShell to create a basic custom list. There is no other PowerShell being run and no fields being added. The error message comes from doing the Create List operation (calling the .Lists.Add() method)

Just de-activating and re-activating these features fixed the initial problems, but doing them out of order also disabled some publishing features on existing pages. I ended up creating a backup and restoring to a sandbox site multiple times in order to test different orders of de-activation and activation.


stsadm -o deactivatefeature -name publishingresource -url "sitecollectionurl" -force
stsadm -o deactivatefeature -name publishingweb -url "subsiteurl" -force
stsadm -o deactivatefeature -name publishingsite -url "sitecollectionurl" -force
stsadm -o deactivatefeature -name fields -url "sitecollectionurl" -force

 And then re-activate the features in the reverse order. The fields feature could be de/re-activated either at the beginning or the end.

Thanks Dmitry! This fixed the issue we were having as well.