Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't create Site Collection in SharePoint 2019 #990

Open
pstork opened this issue Nov 29, 2018 · 39 comments

Comments

@pstork
Copy link

commented Nov 29, 2018

Details of the scenario you tried and the problem that is occurring

When using SharePointDSC to create a Custom minrole server using the Azure SharePoint 2019 image it throws an error for every Site Collection I try to create. New-SPSite works normally outside of DSC. Site Collections with the same settings can be built using New-SPSite in PowerShell or Central Admin

Verbose logs showing the problem

VERBOSE: [2018-11-29 14:11:35Z] [VERBOSE] [SPT019]:
[[SPSite]TeamSite] Performing the operation "New-SPSite" on target
"http://Portal2019.Actualdomainname.com".
VERBOSE: [2018-11-29 14:11:58Z] [ERROR] Invalid field name.
{cbb92da4-fd46-4c7d-af6c-3128c2a5576e} http://portal2019.Actualdomainname.com

Suggested solution to the issue

This works fine in SharePoint 2013 and 2016. It only happens in 2019

The DSC configuration that is used to reproduce the issue (as detailed as possible)

           SPWebApplication SharePointSites
            {
                Name = "SharePoint Sites"
                ApplicationPool = $WebAppPoolName
                ApplicationPoolAccount = $WebPoolManagedAccountCreds.UserName
                AllowAnonymous = $false
                DatabaseName = "SP$($ReleaseYear)_Sites_Content"
                WebAppUrl = $PortalUrl
                Port = 80
                PsDscRunAsCredential = $SharePointSetupUserAccountcreds
                DependsOn = "[SPFarm]CreateSPFarm"
            }
        
            SPWebApplication OneDriveSites
            {
                Name = "OneDrive"
                ApplicationPool = $webAppPoolName
                ApplicationPoolAccount = $WebPoolManagedAccountCreds.UserName
                AllowAnonymous = $false
                DatabaseName = "SP$($ReleaseYear)_Sites_OneDrive" 
                HostHeader = "OneDrive$($ReleaseYear).$($AdDomainName)"
                WebAppUrl = $OneDriveUrl
                Port = 80
                PsDscRunAsCredential = $SharePointSetupUserAccountcreds
                DependsOn = "[SPFarm]CreateSPFarm"
            }

            SPCacheAccounts WebAppCacheAccounts
            {
                WebAppUrl = "http://Portal$($ReleaseYear).$($AdDomainName)"
                SuperUserAlias = "$DomainNetbiosName\$SuperUserAlias"
                SuperReaderAlias = "$DomainNetbiosName\$SuperReaderAlias"
                PsDscRunAsCredential = $SharePointSetupUserAccountcreds
                DependsOn = "[SPWebApplication]SharePointSites"
            }

            SPCacheAccounts OneDriveCacheAccounts
            {
                WebAppUrl = "http://oneDrive$($ReleaseYear).$($AdDomainName)"
                SuperUserAlias = "$DomainNetbiosName\$SuperUserAlias"
                SuperReaderAlias = "$DomainNetbiosName\$SuperReaderAlias"
                PsDscRunAsCredential = $SharePointSetupUserAccountcreds
                DependsOn = "[SPWebApplication]OneDriveSites"
            }

            SPSite TeamSite
            {
                Url = $PortalUrl
                OwnerAlias = "$($DomainNetbiosName)\$($SharePointSetupUserName)"
                Name = "Root Demo Site"
                Template = "STS#0"
                PsDscRunAsCredential = $SharePointSetupUserAccountcreds
                DependsOn = "[SPCacheAccounts]WebAppCacheAccounts"
            }

            SPSite MySiteHost
            {                             
                Url = $OneDriveUrl
                OwnerAlias = "$($DomainNetbiosName)\$($SharePointSetupUserName)"
                Name = "OneDrive"
                Template = "SPSMSITEHOST#0"
                PsDscRunAsCredential = $SharePointSetupUserAccountcreds
                DependsOn = "[SPCacheAccounts]OneDriveCacheAccounts"
            }
        }

The operating system the target node is running

Version of SharePoint that is used (e.g. SharePoint 2016)

SharePoint 2019

Version and build of PowerShell the target node is running

Version of the DSC module that was used ('dev' if using current dev branch)

SharePoint DSC 3.0.0.0

@ykuijs

This comment has been minimized.

Copy link
Collaborator

commented Dec 4, 2018

Hi @pstork, the mentioned Id (cbb92da4-fd46-4c7d-af6c-3128c2a5576e) has something to do with the Document Sets feature.

A couple of questions:

  • Does the ULS log give a little more information? Maybe you have to increase the logging level.
  • Did you try to run the New-SPSite cmdlet using the same credentials as specified in the config ($SharePointSetupUserAccountcreds)?
  • What are the exact parameters you used with New-SPSite?
@pstork

This comment has been minimized.

Copy link
Author

commented Dec 8, 2018

  1. I didn't look at the ULS logs. I will try that and let you know if I find any more info,.
  2. Yes, running new-SPSite manually using the same credentials and the same parameters does work.
  3. The parameters when used with a regular new-spsite cmdlet are: -Url "http://portal2016.acmeman.com" -OwnerAlias "Acme\SP_install" -name "Root Demo Site"
    -Template "STS#0"

It also fails when building out the root site collection on the OneDrive Web App. The exact same scripts work perfectly with SharePoint 2016.

@pstork

This comment has been minimized.

Copy link
Author

commented Dec 11, 2018

I've checked the ULS logs after trying another install. The section of the log dealing with creation of the Site Collection is attached.
errors.log

About all I can see is the following exception trying to apply the web template
12/11/2018 12:32:47.02 wsmprovhost.exe (0x0E3C) 0x1294 SharePoint Foundation Topology c977 Unexpected Exception attempting to ApplyWebTemplate to SPSite http://portal2019.acmeman.com/: Microsoft.SharePoint.SPException: The field with Id {0a9ec8f0-0340-4e24-9b35-ca86a6ded5ab} defined in feature {8b2c6bcb-c47f-4f17-8127-f8eae47a44dd} was found in the current site collection or in a subsite. ---> System.Runtime.InteropServices.COMException: 0x8107058aThe field with Id {0a9ec8f0-0340-4e24-9b35-ca86a6ded5ab} defined in feature {8b2c6bcb-c47f-4f17-8127-f8eae47a44dd} was found in the current site collection or in a subsite. at Microsoft.SharePoint.Library.SPRequestInternalClass.ApplyWebTemplate(String bstrUrl, String bstrWebTemplateContent, Int32 fWebTemplateContentFromSubweb, Int32 fDeleteGlobalListsWithWebTemplateContent, Int32 fIgnoreMissingFeatures, String& bstrWebTemplate, Int32& plWebTemplateId) at Microsoft.SharePoint.Library.SPRequest.ApplyWebTemplate(String bstrUrl, String bstrWebTemplateContent, Int32 fWebTemplateContentFromSubweb, Int32 fDeleteGlobalListsWithWebTemplateContent, Int32 fIgnoreMissingFeatures, String& bstrWebTemplate, Int32& plWebTemplateId) --- End of inner exception stack trace --- at Microsoft.SharePoint.SPGlobal.HandleComException(COMException comEx) at Microsoft.SharePoint.Library.SPRequest.ApplyWebTemplate(String bstrUrl, String bstrWebTemplateContent, Int32 fWebTemplateContentFromSubweb, Int32 fDeleteGlobalListsWithWebTemplateContent, Int32 fIgnoreMissingFeatures, String& bstrWebTemplate, Int32& plWebTemplateId) at Microsoft.SharePoint.SPWeb.ProvisionWebTemplate(SPWebTemplate webTemplate, String webTemplateToUse, SPFeatureWebTemplate featureWebTemplate, Page page, SPFeatureDependencyErrorBehavior featureDependencyErrorBehavior, ICollection1& featureDependencyErrors) at Microsoft.SharePoint.SPWeb.ApplyWebTemplate(SPWebTemplate webTemplate, Page page, SPFeatureDependencyErrorBehavior featureDependencyErrorBehavior, ICollection1& featureDependencyErrors) at Microsoft.SharePoint.SPWeb.ApplyWebTemplate(String strWebTemplate) at Microsoft.SharePoint.Administration.SPSiteCollection.AddInternal(SPSiteCollectionAddParameters param) Attempting to delete the site collection. d6f6aa9e-fd7a-0054-97ea-2ebbbc22d45e

@ikarstein

This comment has been minimized.

Copy link

commented Dec 13, 2018

Same for me, but without SharePointDSC :

new-spsite -Url "https://intranet19.farm/msh" -Template "SPSMSITEHOST#0" -Language 1031 -Name "MySites" -OwnerAlias "ingo" -Verbose

new-spsite -Url "https://intranet19.farm/cthub" -Template "STS#0" -Language 1031 -Name "Content Type Hub" -OwnerAlias "ingo" -Verbose

Both fail with the same error:
new-spsite : Invalid field name. {cbb92da4-fd46-4c7d-af6c-3128c2a5576e} https://intranet19.farm/cthub

(I leave a comment here because it's the only site where I found the same error.)

@Yvand

This comment has been minimized.

Copy link
Contributor

commented Dec 14, 2018

I also reproduce this issue with my ARM template if sharePointVersion is "2019".
Interestingly, if I delete the SPSite and run DSC configuration again, it does not fail again, it's only the 1st time DSC runs.
I attached the log for the correlation ID. The relevant errors are the following:

12/14/2018 13:51:38.34	wsmprovhost.exe (0x0E8C)	0x0898	SharePoint Foundation	Fields	8tpt	Medium	Unable to locate the xml-definition for FieldName with FieldId 'acd16fdf-052f-40f7-bb7e-564c269c9fbc', exception: Microsoft.SharePoint.SPException ---> System.Runtime.InteropServices.COMException: <nativehr>0x8000ffff</nativehr><nativestack></nativestack>    
at Microsoft.SharePoint.Library.SPRequestInternalClass.GetGlobalContentTypeXml(String bstrUrl, Int32 type, UInt32 lcid, Object varIdBytes)    
at Microsoft.SharePoint.Library.SPRequest.GetGlobalContentTypeXml(String bstrUrl, Int32 type, UInt32 lcid, Object varIdBytes)     -
-- End of inner exception stack trace ---    
at Microsoft.SharePoint.SPGlobal.HandleComException(COMException comEx)    
at Microsoft.SharePoint.Library.SPRequest.GetGlobalContentTypeXml(String bstrUrl, Int32 type, UInt32 lcid, Object varIdBytes)    
at Microsoft.SharePoint.SPFieldCollection.FetchFieldsFromWeb()

12/14/2018 13:51:38.52	wsmprovhost.exe (0x0E8C)	0x0898	SharePoint Foundation	Feature receiver assembly 'Microsoft.Office.Policy, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c', class 'Microsoft.Office.RecordsManagement.Internal.ProjectPolicyFeatureReceiver', method 'FeatureActivated' for feature '2fcd5f8a-26b7-4a6a-9755-918566dba90a' threw an exception: System.ArgumentException: Invalid field name. {acd16fdf-052f-40f7-bb7e-564c269c9fbc} http://spsites     
at Microsoft.SharePoint.SPFieldCollection.GetFieldById(Guid fieldId, Boolean bThrowException)    
at Microsoft.Office.RecordsManagement.InformationPolicy.ProjectPolicyItemListUtility.CreateProjectPolicyItemList(SPSite site)    
at Microsoft.Office.RecordsManagement.Internal.ProjectPolicyFeatureReceiver.FeatureActivated(SPFeatureReceiverProperties properties)    
at Microsoft.SharePoint.SPFeature.DoActivationCallout(Boolean fActivate, Boolean fForce)

12/14/2018 13:51:40.23	wsmprovhost.exe (0x0E8C)	0x0898	SharePoint Foundation	Feature Infrastructure	8e1b	High	Failed to activate feature 'ProjectBasedPolicy' (Id 2fcd5f8a-26b7-4a6a-9755-918566dba90a) associated with site template 'STS#0'
at scope \"http://spsites\".  Exception: System.ArgumentException: Invalid field name. {acd16fdf-052f-40f7-bb7e-564c269c9fbc} http://spsites     
at Microsoft.SharePoint.SPFieldCollection.GetFieldById(Guid fieldId, Boolean bThrowException)    
at Microsoft.Office.RecordsManagement.InformationPolicy.ProjectPolicyItemListUtility.CreateProjectPolicyItemList(SPSite site)    
at Microsoft.Office.RecordsManagement.Internal.ProjectPolicyFeatureReceiver.FeatureActivated(SPFeatureReceiverProperties properties)    
at Microsoft.SharePoint.SPFeature.DoActivationCallout(Boolean fActivate, Boolean fForce)    
at Microsoft.SharePoint.SPFeature.Activate(SPSite siteParent, SPWeb webParent, SPFeaturePropertyCollection props, SPFeatureActivateFlags activateFlags, Boolean fForce)    
at Microsoft.SharePoint.SPFeatureCollection.AddInternal(SPFeatureDefinition featdef, Version version, SPFeaturePropertyCollection properties, SPFeatureActivateFlags activateFlags, Boolean force, Boolean fMarkOnly)    
at Microsoft.SharePoint.SPTemplateAssociationElement.EnsureTemplateAssociatedSiteFeaturesActivated(SPSite site, String sTemplateName)

12/14/2018 13:51:40.47	wsmprovhost.exe (0x0E8C)	0x0898	SharePoint Foundation	Topology	6141	Critical	The site / could not be created.  The following exception occurred: Invalid field name. {acd16fdf-052f-40f7-bb7e-564c269c9fbc} http://spsites .	22efab9e-40d2-700e-9988-57614d4f8df8

I don't know the root cause, but interestingly it does not seem to reproduce in my other template, which is very similar.

@MyProjectExpert

This comment has been minimized.

Copy link

commented Jan 6, 2019

Yes, I have been getting this as error well using PowerShell. What is weird is somedays, it works.

New-SPSite : Invalid field name. {acd16fdf-052f-40f7-bb7e-564c269c9fbc} http://demosp.wcc2dev.local
At line:1 char:5

  • New-SPSite $WebAppURL -Name $SiteRootName -Template STS#0 `
    
  • ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    • CategoryInfo : InvalidData: (Microsoft.Share...SPCmdletNewSite:SPCmdletNewSite) [New-SPSite], SPException
    • FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletNewSite
@ykuijs

This comment has been minimized.

Copy link
Collaborator

commented Jan 9, 2019

@Yvand You log shows the following error just before the other message is thrown:

12-14-2018 13:51:36.54	wsmprovhost.exe (0x0E8C)	0x0898	SharePoint Foundation	General	8e2s	Medium	Unknown SPRequest error occurred. More information: 0x80070002	22efab9e-40d2-700e-9988-57614d4f8df8

0x80070002 means "The system cannot find the file specified". Can you use make a trace of your environment using Process Monitor and share it with me?

@ykuijs

This comment has been minimized.

Copy link
Collaborator

commented Jan 9, 2019

@ikarstein @MyProjectExpert @Yvand @pstork
Can you guys share the patch level of SharePoint which you are using?

@ykuijs ykuijs added the bug label Jan 9, 2019
@MyProjectExpert

This comment has been minimized.

Copy link

commented Jan 10, 2019

@NikCharlebois

This comment has been minimized.

Copy link
Contributor

commented Jan 10, 2019

Folks, I am responsible for the Azure Trial Images. Can you folks confirm that the problem goes away when applying the December 2018 CU? I normally update the images every 6 months, but could update it sooner if we can confirm 100% that this fixes the issue. Thanks

@ykuijs

This comment has been minimized.

Copy link
Collaborator

commented Jan 10, 2019

@MyProjectExpert Do you mean install all available Windows Updates? If so, does that also include any SharePoint security updates (and which)? Or did you install a specific CU?

@MyProjectExpert

This comment has been minimized.

Copy link

commented Jan 10, 2019

@Yvand

This comment has been minimized.

Copy link
Contributor

commented Jan 14, 2019

@NikCharlebois I provisioned the current Azure SharePoint 2019 Trial VM image and updated SharePoint to January 2019 PU 16.0.10340.12101.
Unfortunately I continue to reproduce the issue

@MyProjectExpert

This comment has been minimized.

Copy link

commented Jan 14, 2019

@Yvand

This comment has been minimized.

Copy link
Contributor

commented Jan 14, 2019

yes

@Yvand

This comment has been minimized.

Copy link
Contributor

commented Jan 22, 2019

This issue is giving me a hard time.
One thing I noticed, I always reproduce it the 1st time I run the DSC config (which creates the SharePoint farm).
If I run the same script again, it creates site collections successfully.
So to reproduce the issue, I have to destroy the farm and run the DSC config again.
Has anybody any idea why it repro only during farm creation?

1 more thing: I use the exact same DSC config on both SharePoint 2013 and 2016, and it works absolutely fine.

@andikrueger

This comment has been minimized.

Copy link
Contributor

commented Jan 23, 2019

Are you using a single server or multi server farm?

@Yvand

This comment has been minimized.

Copy link
Contributor

commented Jan 23, 2019

@andikrueger it's a single server farm. To reproduce I disconnect server from the farm and delete every database before I run the DSC config again

@ykuijs

This comment has been minimized.

Copy link
Collaborator

commented Jan 25, 2019

This looks like a timing issue in SP2019 and not related to SharePointDsc

@pstork

This comment has been minimized.

Copy link
Author

commented Jan 30, 2019

I agree it looks like a timing issue, but that still makes it an issue for SharePointDSC. Unless we can find some kind of workaround it makes using DSC to build and provision SharePoint much less useful. I'm going to try using xpendingReboot and force a reboot after creation of the Web App and then see if after the reboot the site collections create normally.

@pstork

This comment has been minimized.

Copy link
Author

commented Jan 31, 2019

So I've found a workaround that seems to fix the problem for DSC. I'm using xPendingReboot to insert a Reboot between creating the Web Applications and creating new site collections. That either helps get the files registered that creating sites needs or simply the delay involved is enough to fix the timing problem. Either way it works. Here's the code I used.

        Script ForceReboot
        {
            TestScript = {
                return (Test-Path HKLM:\SOFTWARE\MyMainKey\RebootKey)
            }
            SetScript = {
                New-Item -Path HKLM:\SOFTWARE\MyMainKey\RebootKey -Force
                 $global:DSCMachineStatus = 1 

            }
            GetScript = { return @{result = 'result'}}
            DependsOn = @('[SPWebApplication]SharePointSites', '[SPWebApplication]OneDriveSites')
        }    

        xPendingReboot Reboot2
        {
            Name = 'AfterWebApps'
            SkipCcmClientSDK = $true
            DependsOn = "[Script]ForceReboot"
        }
@NikCharlebois

This comment has been minimized.

Copy link
Contributor

commented Jan 31, 2019

This may or may not be related, but calling the SPServiceInstance blocks before SPWebApplication throws an error complaining that there's a concurrent job in running in OWSTimer. If I move the SPServiceInstance blocks after SPWebApplication, but before SPSite, then I get the invalid field name error. Definitively looks like a timing issue

@NikCharlebois

This comment has been minimized.

Copy link
Contributor

commented Feb 1, 2019

@pstork I managed to get repro steps for the initial issue. As mentioned, it seems to be a timing issue. Can one of you folks reproduce the following:

The farm has to be a single server farm, on which we simply installed the SP19 Binaries, and ran PSConfig with MinRole = Custom, nothing else.

The run the following script (replace the server names by yours):

add-pssnapin Microsoft.SharePoint.PowerShell -EA SilentlyContinue

#region Service Instances
$services = @("Central Administration", "Managed Metadata Web Service", "Microsoft SharePoint Foundation Incoming E-Mail", "Microsoft SharePoint Foundation Web Application", 
"Microsoft SharePoint Foundation Workflow Timer Service", "Search Host Controller Service", "Search Query and Site Settings Service", "SharePoint Server Search")

foreach ($service in $services)
{
    $si = Get-SPServiceInstance -Server $env:COMPUTERNAME | Where-Object -FilterScript {
        $_.TypeName -eq $service
    }
            
    if ($null -eq $si) 
    {
        $domain = (Get-CimInstance -ClassName Win32_ComputerSystem).Domain
        $fqdn = "$($env:COMPUTERNAME).$domain"
        $si = Get-SPServiceInstance -Server $fqdn | Where-Object -FilterScript {
            $_.TypeName -eq $service
        }
    }
    if ($null -eq $si)
    {
        throw [Exception] "Unable to locate service application '$($service)'"
    }
    Start-SPServiceInstance -Identity $si 
}
#endregion

#region WebApplication
$ap = New-SPAuthenticationProvider
$newWebAppParams = @{
    Name = "SharePoint - 90"
    ApplicationPool = "SharePoint - 90"
    ApplicationPoolAccount = "contoso\sp_farm"
    Url = "http://sptechcon2013/"
    AuthenticationProvider = $ap
    DatabaseName = "WSS_Content"
    DatabaseServer = "SPSQLTBD2"
    HostHeader = "sptechcon2013"
    Path = "C:\inetpub\wwwroot\wss\VirtualDirectories\90"
    Port = "90"
}
New-SPWebApplication @newWebAppParams | Out-Null
#endregion

This throws the following error on every instance:

New-SPWebApplication : An update conflict has occurred, and you must re-try this action. The object SPWebApplication Name=SharePoint - 90 
was updated by CONTOSO\sp_farm, in the OWSTIMER (2264) process, on machine SPTC19TBD2.  View the tracing log for more information about the 
conflict.
At line:43 char:1
+ New-SPWebApplication @newWebAppParams | Out-Null
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidData: (Microsoft.Share...PWebApplication:SPCmdletNewSPWebApplication) [New-SPWebApplication], SPUpdated 
   ConcurrencyException
    + FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletNewSPWebApplication
@NikCharlebois

This comment has been minimized.

Copy link
Contributor

commented Feb 1, 2019

The logic in the PowerShell script above is the logic flow that gets executed in the background on a new environment by running the following DSC script:

SPFarm 3faf0512-ce3f-496d-829d-1cb824e34446
        {
            Passphrase = New-Object System.Management.Automation.PSCredential ('Passphrase', (ConvertTo-SecureString -String $ConfigurationData.NonNodeData.PassPhrase -AsPlainText -Force));
		AdminContentDatabaseName = "SharePoint_AdminContent_9c516a86-4058-4368-b312-31a973d47573";
		FarmAccount = $Credssp_farm;
		FarmConfigDatabaseName = "SharePoint_Config";
		CentralAdministrationPort = 7777;
		PsDscRunAsCredential = $Credssp_farm;
		CentralAdministrationAuth = "NTLM";
		RunCentralAdmin = $True;
		Ensure = "Present";
		IsSingleInstance = "Yes";
		DatabaseServer = $ConfigurationData.NonNodeData.DatabaseServer;
        }
        foreach($ServiceInstance in $Node.ServiceInstances)
        {
            SPServiceInstance ($ServiceInstance.Name.Replace(" ", "") + "Instance")
            {
                Name = $ServiceInstance.Name;
                Ensure = $ServiceInstance.Ensure;
                PsDscRunAsCredential = $Credssp_farm
            }
        }
        SPManagedAccount 812bfce0-ed47-4ce6-a79b-4fee1dc4b901
        {
		Account = $Credssp_farm;
		AccountName = $Credssp_farm.UserName;
		PsDscRunAsCredential = $Credssp_farm;
		Ensure = "Present";
		EmailNotification = 5;
		Schedule = "";
		PreExpireDays = 2;
        }
        SPWebApplication SharePoint-80
        {
		DatabaseName = "WSS_Content";
		ApplicationPool = "SharePoint - 80";
		Path = "C:\inetpub\wwwroot\wss\VirtualDirectories\80";
		PsDscRunAsCredential = $Credssp_farm;
		AllowAnonymous = $False;
		Name = "SharePoint - 80";
		Ensure = "Present";
		UseClassic = $False;
		ApplicationPoolAccount = $Credssp_farm.UserName;
		Port = "80";
		DatabaseServer = $ConfigurationData.NonNodeData.DatabaseServer;
		WebAppUrl = "http://sptechcon2013/";
		HostHeader = "sptechcon2013";
        }
@NikCharlebois

This comment has been minimized.

Copy link
Contributor

commented Feb 1, 2019

I understand you folks are getting the Invalid Field Name issue on the SPSite creation, but I believe the error above is the true error being thrown, and that the SPSite one is just its collateral.

@pstork

This comment has been minimized.

Copy link
Author

commented Feb 1, 2019

@NikCharlebois

This comment has been minimized.

Copy link
Contributor

commented Feb 1, 2019

@pstork Sure. I actually use the following ARM templates if that makes it easier for you:
https://github.com/NikCharlebois/Conferences/tree/master/2019%20-%20SPTechCon%20-%20Austin

@pstork

This comment has been minimized.

Copy link
Author

commented Feb 1, 2019

@Yvand

This comment has been minimized.

Copy link
Contributor

commented Feb 1, 2019

@pstork look at PR #997 for the Distributed Cache issue: since I updated resource SPDistributedCacheService I don't face it anymore.

@pstork

This comment has been minimized.

Copy link
Author

commented Feb 1, 2019

I ran a test yesterday with the current DEV branch that includes that fix. I still get the errors when trying to configure the distributed cache. PR #997 didn't fix the issue for me.

@NikCharlebois

This comment has been minimized.

Copy link
Contributor

commented Feb 1, 2019

I am still trying to narrow down the issue as much as possible. I don't get the issue whenever I assign the SingleServer MinRole to the server. It kind of makes sense since doing so will automatically enable most services, and that by the time I run my PowerShell script to create the Web App and SPSite, all the jobs have been executed.

@pstork

This comment has been minimized.

Copy link
Author

commented Feb 1, 2019

@NikCharlebois - I just finished running the test you provided and I also get the same error message that you get.

New-SPWebApplication : An update conflict has occurred, and you must re-try this action. The object SPWebApplication Name=SharePoint - 90 was updated by
acmeman\SP_Farm, in the OWSTIMER (4988) process, on machine SPT01. View the tracing log for more information about the conflict.
At C:\DSC\NickTest.ps1:43 char:1

  • New-SPWebApplication @newWebAppParams | Out-Null
  •   + CategoryInfo          : InvalidData: (Microsoft.Share...PWebApplication:SPCmdletNewSPWebApplication) [New-SPWebApplication], SPUpdatedConcurrencyException
      + FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletNewSPWebApplication
    
@NikCharlebois

This comment has been minimized.

Copy link
Contributor

commented Feb 1, 2019

In my case, the script I was using came from a SP2013 environment I extracted using ReverseDSC and which I was trying to use to replicate the farm as a SP2019 environment. When you extract from 2013, it doesn't pickup any MinRole and leaves the SPFarm block without the ServerRole parameter. The SPFarm resource threats SPFarm block missing that parameter as defaulting to Custom MinRole. My issue with the Web Application was solved by manually adding MinRole = SingleServerFarm. This allowed me to move past the OWSTimer concurrent process error, but then it still threw the Invalid field name on the SPSite block.

leovms added a commit to Azure/azure-devtestlab that referenced this issue May 6, 2019
* Add SharePoint template
* Remove unnecessary content
* Update documentation
* Delete Deploy-AzureResourceGroup.ps1
* Update all DSC modules to latest version
* Update documentation
* Manage DSC scriptFileUri as documented in https://github.com/Azure/azure-quickstart-templates/blob/master/1-CONTRIBUTION-GUIDE/best-practices.md#deployment-artifacts-nested-templates-scripts
* Update metadata.json
* Set relying party identifier to "urn:federation:sharepoint"
* Rename template folder to SharePoint-AllVersions
* Update DSC module SharePointDSC to 3.3
* Add logic to create optional public IP addresses for VMs
* Force a reboot before creating site in SharePoint 2019 to workaround bug PowerShell/SharePointDsc#990
* Use function resourceGroup().location to set location of resources
* Add missing DSC module xPendingReboot
* Add configurable auto-shutdown of VMs
* Update apiVersion of all resources to latest version
* Remove resources "Microsoft.DevTestLab/schedules" as Azure DTL does not support them
* DTL generates following error if ARM template contains resources "Microsoft.DevTestLab/schedules": "Resource type "Microsoft.DevTestLabs/labs" and its nested resource types are not supported in this flow. Please deploy this template by following http://aka.ms/armtemplatedeploy."
* Update CHANGELOG.md
* Applying review comments
@harbars

This comment has been minimized.

Copy link

commented May 13, 2019

Hi folks,

It's worth noting this isn't a specific issue with DSC or any other approach. It impacts every use of New-SPSite within a PoSh automation approach, and was a bug during pre-release and RTM builds. on any farm type. in some cases, reloading the snapin will allow the site creation. other times the entire process needs to be reloaded

@SteveL-MSFT SteveL-MSFT added this to Needs investigation in powershell/dscresources May 14, 2019
@ykuijs

This comment has been minimized.

Copy link
Collaborator

commented May 15, 2019

@harbars Do you know if this is (or will be) fixed in a CU?

@harbars

This comment has been minimized.

Copy link

commented May 15, 2019

i'm not aware of any work to fix it - it may have already been done - it's not something I've looked at in a while, but was pointed to this page when it came up related to something else. the bottom line - the problem is/was SharePoint, not anyone else's tool/automation choice or implementation

Yvand added a commit to Yvand/AzureRM-Templates that referenced this issue Jun 6, 2019
* Add logging on failure

* Properly enable TLS 1.2 for SharePoint 2013

* Configure TLS 1.2 for all SharePoint VMs

* Set relying party identifier to "urn:federation:sharepoint"

* Update SharePointDSC to 3.2 and test to create SPSite in SharePoint 2019

* Manually copy bug fixes in PowerShell/SharePointDsc@2a2271d

* Reverting changes - SharePointDSC 3.2 has bugs and resource SPSite still doesn't work in SP 2019

* Update DSC module SharePointDSC to 3.3

* Update links for dev branch

* Add logic to create optional public IP addresses for VMs

* Rename createPublicIPAddresses to createPublicIPAndDNS

* Force a reboot before creating site in SharePoint 2019 to workaround bug PowerShell/SharePointDsc#990

* Use function resourceGroup().location to set location of resources

* Add missing DSC module xPendingReboot

* Add configurable auto-shutdown of VMs

* Update apiVersion of resources "Microsoft.Compute/virtualMachines/extensions" to "2019-03-01"

* Update apiVersion of resources "Microsoft.Compute/virtualMachines/exensions" and "Microsoft.DevTestLab/schedules"

* Update apiVersion of all resources to latest version

* Remove resources "Microsoft.DevTestLab/schedules" as Azure DTL does not support them

DTL generates following error if ARM template contains resources "Microsoft.DevTestLab/schedules": "Resource type "Microsoft.DevTestLabs/labs" and its nested resource types are not supported in this flow. Please deploy this template by following http://aka.ms/armtemplatedeploy."

* Update template

* Update azuredeploy.json

* Update template

* Update templates
@ykuijs

This comment has been minimized.

Copy link
Collaborator

commented Sep 19, 2019

Since this is a SharePoint related issue, I suggest to close this issue here. We can't do anything to fix the issue in SharePointDsc anyways.

Agree?

@ikarstein

This comment has been minimized.

Copy link

commented Sep 19, 2019

Yes, I aggree. At that time it was not clear to me whether it was SharePointDsc or the server.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
powershell/dscresources
Needs investigation
8 participants
You can’t perform that action at this time.