dsccommunity / SharePointDsc

The SharePointDsc PowerShell module provides DSC resources that can be used to deploy and manage a SharePoint farm
MIT License
247 stars 107 forks source link

Can't create Site Collection in SharePoint 2019 #990

Closed pstork closed 3 years ago

pstork commented 5 years ago

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 commented 5 years ago

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

A couple of questions:

pstork commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

ykuijs commented 5 years ago

@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 commented 5 years ago

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

ikarstein commented 5 years ago

@ykuijs

I have this patch installed: https://support.microsoft.com/en-us/help/4461548/descriptionofthesecurityupdateforsharepointserver2019december112018

MyProjectExpert commented 5 years ago

Hello All

Issue can be duplicated by using the SharePoint 2019 Trial VM image on azure portal.

I found out if I update my windows server and then run the SharePoint Configuration Wizard, that my issue goes away and not an issue with me any more.

Sincerely

Michael Wharton, Project MVP cell: 336-972-5741

From: Ingo Karstein notifications@github.com Sent: Thursday, January 10, 2019 4:55 AM To: PowerShell/SharePointDsc SharePointDsc@noreply.github.com Cc: Michael Wharton mwharton@whartoncomputer.com; Mention mention@noreply.github.com Subject: Re: [PowerShell/SharePointDsc] Can't create Site Collection in SharePoint 2019 (#990)

@ykuijs https://github.com/ykuijs

I have this patch installed: https://support.microsoft.com/en-us/help/4461548/descriptionofthesecurityupdateforsharepointserver2019december112018

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PowerShell/SharePointDsc/issues/990#issuecomment-453036506 , or mute the thread https://github.com/notifications/unsubscribe-auth/AI8uaIaoBb7XvLVrbW0MEkGkKZbKF5krks5vBw3agaJpZM4Y50Py . https://github.com/notifications/beacon/AI8uaMWhRUAC3t7lzIAi60n8yRLZ94f_ks5vBw3agaJpZM4Y50Py.gif

NikCharlebois commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

Yes, I basically ran the Windows Update and installed all the patches. Didn’t have time to isolate which particular patch.

One other point and I am investigating it. When I build SharePoint from the image, I don’t use the SharePoint Configuration wizard. Its build using PowerShell script. Done it this way for years. There is a possibility that something need is required when using PowerShell and will test.

Here is the basic order

  1. Build SharePoint VM using Azure SharePoint 2019 Trial
  2. Deploy SharePoint using PowerShell command (version SharePoint Configuration Wizard). This is done to manage SharePoint database names.
  3. Powershell scripts to build web applications and sites. This is where things fail and get error message.
  4. Apply windows patches
  5. Run SharePoint configuration wizard. All is good and SharePoint is update if any patches are found. This is where I want to test and see if windows patch is not needed.
  6. PowerShell Scripts to build web applications and sites. Now everything works. Basically same scripts used in SharePoint 2019.

Github has all my scripts and steps

https://github.com/MyProjectExpert/ProjectServer-Tools/tree/master/Azure-SharePoint-IaaS

Sincerely

Michael Wharton, Project MVP cell: 336-972-5741

From: Yorick Kuijs notifications@github.com Sent: Thursday, January 10, 2019 2:15 PM To: PowerShell/SharePointDsc SharePointDsc@noreply.github.com Cc: Michael Wharton mwharton@whartoncomputer.com; Mention mention@noreply.github.com Subject: Re: [PowerShell/SharePointDsc] Can't create Site Collection in SharePoint 2019 (#990)

@MyProjectExpert https://github.com/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?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PowerShell/SharePointDsc/issues/990#issuecomment-453218062 , or mute the thread https://github.com/notifications/unsubscribe-auth/AI8uaKymMtaWLXCIMFgZNxN_BTReQKB3ks5vB5E3gaJpZM4Y50Py . https://github.com/notifications/beacon/AI8uaJ2Et_E0rDMe8diVJimOyv0-1Qaiks5vB5E3gaJpZM4Y50Py.gif

Yvand commented 5 years ago

@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 commented 5 years ago

After applying patch, did you run the SharePoint Configuration Wizard?

Sincerely

Michael Wharton, Project MVP cell: 336-972-5741

From: Yvan Duhamel notifications@github.com Sent: Monday, January 14, 2019 4:56 AM To: PowerShell/SharePointDsc SharePointDsc@noreply.github.com Cc: Michael Wharton mwharton@whartoncomputer.com; Mention mention@noreply.github.com Subject: Re: [PowerShell/SharePointDsc] Can't create Site Collection in SharePoint 2019 (#990)

@NikCharlebois https://github.com/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

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PowerShell/SharePointDsc/issues/990#issuecomment-453950221 , or mute the thread https://github.com/notifications/unsubscribe-auth/AI8uaOyXqgGbnwtNkccE_oxM2jgkujBeks5vDFQzgaJpZM4Y50Py . https://github.com/notifications/beacon/AI8uaPO2db0KbywajKEVMs6d37uLEUm6ks5vDFQzgaJpZM4Y50Py.gif

Yvand commented 5 years ago

yes

Yvand commented 5 years ago

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 commented 5 years ago

Are you using a single server or multi server farm?

Yvand commented 5 years ago

@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 commented 5 years ago

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

pstork commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago
    I can try this script. I’ve got a setup in Azure with PUSH DSC that can be reset fairly quickly.

    Paul Papanek Stork (MCSM, MVP)Owner, Principal Architect Don’t Papanic Consultinge: pstork@dontpapanic.comp: 216.272.0573www.dontpapanic.com/blogSent from my iPhone

On Thu, Jan 31, 2019 at 7:21 PM -0500, "Nik Charlebois" notifications@github.com wrote:

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.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

NikCharlebois commented 5 years ago

@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 commented 5 years ago

Thanks,

I’ve got a full set of PowerShell and DSC that build out the same things. I just need to pull some of the stuff out of the SharePoint DSC so I can run the script you requested instead.

As I mentioned in the notes on the issue, I’ve gotten around the timing problem by having the system do a Reboot after building out the Web Applications and before building the site collections. After that the only remaining issue I’ve had is with the Distributed Cache service not stopping and starting correctly. I’m still working on that one. I tried the current Dev branch and that actually caused more problems rather than fixing the cache issue.

--

Paul Papanek Stork (MCSM, MVP)

Owner, Principal Architect

Don’t..Papanic Consulting

e: pstork@dontpapanic.com mailto:pstork@dontpapanic.com

p: 216.272.0573

http://www.dontpapanic.com/blog www.dontpapanic.com/blog

From: Nik Charlebois notifications@github.com Sent: Thursday, January 31, 2019 7:28 PM To: PowerShell/SharePointDsc SharePointDsc@noreply.github.com Cc: Paul Papanek Stork pstork@att.net; Mention mention@noreply.github.com Subject: Re: [PowerShell/SharePointDsc] Can't create Site Collection in SharePoint 2019 (#990)

@pstork https://github.com/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

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PowerShell/SharePointDsc/issues/990#issuecomment-459559942 , or mute the thread https://github.com/notifications/unsubscribe-auth/AMUXRCEtKvsPmvhhSRNfwInotm3r6Q4zks5vI4n8gaJpZM4Y50Py . https://github.com/notifications/beacon/AMUXRJPOjjnAlv6r5dbB0jrfZAPu_PYRks5vI4n8gaJpZM4Y50Py.gif

Yvand commented 5 years ago

@pstork look at PR https://github.com/PowerShell/SharePointDsc/pull/997 for the Distributed Cache issue: since I updated resource SPDistributedCacheService I don't face it anymore.

pstork commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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

NikCharlebois commented 5 years ago

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.

harbars commented 5 years ago

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

ykuijs commented 5 years ago

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

harbars commented 5 years ago

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

ykuijs commented 5 years ago

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 commented 5 years ago

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

ykuijs commented 5 years ago

Closing this issue

ykuijs commented 3 years ago

FYI: We found a workaround for this issue, which I am in the process of testing.

Yvand commented 3 years ago

@ykuijs let me know if you want additional testers, I'll be happy to do that

ykuijs commented 3 years ago

Issue will be fixed in v4.8, which will be released later today.