Can't create Site Collection in SharePoint 2019 #990
Comments
|
Hi @pstork, the mentioned Id (cbb92da4-fd46-4c7d-af6c-3128c2a5576e) has something to do with the Document Sets feature. A couple of questions:
|
ykuijs
added
needs investigation
It also fails when building out the root site collection on the OneDrive Web App. The exact same scripts work perfectly with SharePoint 2016. |
|
I've checked the ULS logs after trying another install. The section of the log dealing with creation of the Site Collection is attached. About all I can see is the following exception trying to apply the web template |
|
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: (I leave a comment here because it's the only site where I found the same error.) |
|
I also reproduce this issue with my ARM template if sharePointVersion is "2019". I don't know the root cause, but interestingly it does not seem to reproduce in my other template, which is very similar. |
|
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
|
|
@Yvand You log shows the following error just before the other message is thrown: 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? |
|
@ikarstein @MyProjectExpert @Yvand @pstork |
|
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 <#990 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AI8uaIaoBb7XvLVrbW0MEkGkKZbKF5krks5vBw3agaJpZM4Y50Py> . <https://github.com/notifications/beacon/AI8uaMWhRUAC3t7lzIAi60n8yRLZ94f_ks5vBw3agaJpZM4Y50Py.gif>
|
|
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 |
|
@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? |
|
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 <#990 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AI8uaKymMtaWLXCIMFgZNxN_BTReQKB3ks5vB5E3gaJpZM4Y50Py> . <https://github.com/notifications/beacon/AI8uaJ2Et_E0rDMe8diVJimOyv0-1Qaiks5vB5E3gaJpZM4Y50Py.gif>
|
|
@NikCharlebois I provisioned the current Azure SharePoint 2019 Trial VM image and updated SharePoint to January 2019 PU 16.0.10340.12101. |
|
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 <#990 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AI8uaOyXqgGbnwtNkccE_oxM2jgkujBeks5vDFQzgaJpZM4Y50Py> . <https://github.com/notifications/beacon/AI8uaPO2db0KbywajKEVMs6d37uLEUm6ks5vDFQzgaJpZM4Y50Py.gif>
|
|
yes |
|
This issue is giving me a hard time. 1 more thing: I use the exact same DSC config on both SharePoint 2013 and 2016, and it works absolutely fine. |
|
Are you using a single server or multi server farm? |
|
@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 |
|
This looks like a timing issue in SP2019 and not related to SharePointDsc |
|
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. |
|
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. |
|
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 |
|
@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
#endregionThis 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 |
|
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";
} |
|
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. |
|
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.
|
|
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. |
|
@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
|
|
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. |
* 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 dsccommunity/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
|
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 |
|
@harbars Do you know if this is (or will be) fixed in a CU? |
|
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 |
* 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 dsccommunity/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 dsccommunity/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
|
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? |
|
Yes, I aggree. At that time it was not clear to me whether it was SharePointDsc or the server. |
|
Closing this issue |
|
FYI: We found a workaround for this issue, which I am in the process of testing. |
ykuijs
added
in progress
|
@ykuijs let me know if you want additional testers, I'll be happy to do that |
Fixed #990 and added logging to SPSearchServiceApp
|
Issue will be fixed in v4.8, which will be released later today. |
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
The text was updated successfully, but these errors were encountered: