This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
We have a new SharePoint Server 2019 (on prem) farm we're working on. It is a large farm (17 VM servers + 2 node physical SQL cluster) we will be using to migrate from SharePoint Server 2016. It only has placeholder/blank content DBs and very few service apps built out. The problem is, the SharePoint Products and Configuration Wizard takes a very long time to run, 2 hours or more on any server running web application. Psconfigui runs fast on distributed cache and search servers. I know there are fewer and fewer companies even using SharePoint on prem, but I'm asking here on the chance anyone else is experiencing this. I already have a MS support case open, and they are reviewing logs, but haven't made any headway.
From the upgrade log. UPGRADE PERCENTAGE: 100.00000000% done, Total Elapsed Time 01:59:13.0343961
No errors in the upgrade log, and I haven't seen any reason for this in the ULS either. 2 hours is how long each frond end takes even if there is no upgrading to be done, in other words, if psconfigui completes successfully on all servers, then I go back and run it again on central admin, just to test, it still takes 2 hours! Since we patch monthly, running psconfigui 1 weekend a month for 25-30 hours is unacceptable.
I've tried the psconfig command here https://learn.microsoft.com/en-us/sharepoint/upgrade-and-update/sharepoint-server-2016-zero-downtime-patching-steps
and also the 1 from Stefan Goßner here https://blog.stefan-gossner.com/2015/08/20/why-i-prefer-psconfigui-exe-over-psconfig-exe/ and they have their own problems, and do not run any faster.
Oh, also, we tried disabling all antivirus (Crowdstrike). Didn't help. Also added farm acct to local admins, which isn't required nor recommended, but also didn't help.
Hello @Vincent Collogan ,
I'm glad to hear that your problem has been solved, and you can mark answer from @Trevor Seward .
Have a nice day!
If you disabled Crowdstrike, did you check to see if Windows Defender became enabled again? It's important that you follow https://support.microsoft.com/en-us/office/certain-folders-may-have-to-be-excluded-from-antivirus-scanning-when-you-use-file-level-antivirus-software-in-sharepoint-01cbc532-a24e-4bba-8d67-0b1ed733a3d9 regardless of A/V.
How many Web Applications have you created in the new farm? Did this only get slower as you added more servers to the farm, or was server #2 supporting the FE role also slow to join the farm?
Windows Defender and FW are disabled. There are about 20 web apps and all were created during initial install and config by AutoSPInstaller. It didn't seem like joining farms was slow, nor was installing SP.
Also, correction to above... running psconfigui after a patch is pushed takes 2 hours, but when I run it for a second time (meaning there are no upgrade tasks to perform), it takes a little over an hour on each front end, which is still way too long/way longer than it takes on our SharePoint 2016 farms.
Another thing... all servers, SharePoint and SQL are on same subnet with less than 1ms response. IO testing has been done with DiskSpd, and the storage and servers check out fine. These are big enterprise class servers and SANs, architected for tens of thousands of SharePoint users. SQL and storage utilization are low - no significant waits or anything that would point to performance being the problem.
Is there a reason you're using 20 Web Apps? Recommendation is no more than four for performance reasons. Are all Service Applications running under a single account and likewise, all Web Applications, thus one IIS App Pool for all Service Apps and one for all Web Apps?
Software boundaries and limits for SharePoint Servers 2016 and 2019
https://learn.microsoft.com/en-us/sharepoint/install/software-boundaries-and-limits-0
The "supported" limit is 20 web apps. Not sure where you got 4 from. We have this many web apps because of management that doesn't listen to admins. These have been migrated from disparate SharePoint servers over the years. I don't see how this is related as there is not even any content (yet). This farm takes way longer to psconfig than the SP2016 farm with 11TB of content, same # of web apps, on older hardware. But, I'll delete a few web apps and see if it has an impact (I know it won't).
Supported doesn't mean you won't run into performance problems. Four is the optimal, maximum configuration (this value comes from the product group).
With that being said, diagnosing this will require local tooling to collect logs. I'd suggest you raise a ticket with Microsoft Support as they'll be able to directly work with you while a server is going through psconfig. There is an old bug called a config storm which happens when running psconfig on farms with a "large" number of servers, which your farm would fall under, but that should have been addressed quite some time ago unless there has been a regression.
Never heard that, and we've been working with 20 web apps for many years. We even had a dedicated PFE for a year and he never even brought this 4 web apps max idea up. Also, if that were the problem, why would it show on SP2019 but not 2016? I think this is the wrong goose to be chasing. I know you're trying to help though. Also, from my initial post: I already have a MS support case open, and they are reviewing logs, but haven't made any headway. I'll bring this old config storm thought up to him. Thanks.
PFEs aren't always the best informed. But with that being said, we have no way of knowing without diagnostic logging as to why it is taking longer. There are too many variables to account for, unfortunately.
Remember that when you provision a Web Application, it needs to push out the changes to IIS/local file system -- the more Web Apps you have, the longer this process will take.
I see. Perplexing why SP2016 runs psconfig so much faster with same # of web apps, but you are indeed correct. I deleted several web apps (there is no content anyway), and ran psconfigUI again, and it's running in about half the time. I've already shared this, and the associate logs from the faster psconfig with the eng working on the case. Can you reply with something in the Answer section, and I'll go ahead and mark it as an answer so this can be closed?
I'll keep pursuing on the MS support side. Thanks for the info and idea Trevor.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(19.2, 78%, 11%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EU%3C/text%3E%3C/svg%3E)
So if i understood correctly, Culprit was number of web apps , being more then 4 or 5 ?
Is that correct ? or you did some thing else to resolve this ?