This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](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(265.6, 56.00000000000001%, 35%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EM%3C/text%3E%3C/svg%3E)
Hello,
I have a web front end server and application server in my SharePoint 2016 on premise farm. In the application server, I've installed the security update located here: https://support.microsoft.com/en-us/help/4462211/description-of-the-security-update-for-sharepoint-enterprise-server
After a successful install, I've ran the configuration wizard. The configuration wizard ran successfully, but while viewing the Upgrade Status page in Central Administration, I've noticed two warnings. I've check my logs and see this message: "The web application is configured with claims authentication mode however the content database you are trying to attach is intended to be used against a windows classic authentication mode". What does this warning mean? How can I resolve or can it be ignored?
![](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(67.2, 7.000000000000001%, 16%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMM%3C/text%3E%3C/svg%3E)
Hi @MDuBose ,
If trevor's answer helps you, you could accept it as answer. It will be helpful to others in the future.
See https://thesharepointfarm.com/2014/11/test-spcontentdatabase-classic-to-claims-conversion/. This isn't necessarily an issue.
Is there a reason you've chosen to install such an old PU? Microsoft's recommendation is that you keep up to date on PUs. Don't forget you should be installing both the sts-x-none and wssmui patches for any given month.
My organization's Security Team notified me about vulnerabilities and this CU was suggested to be installed. I'm new to installing patches so please excuse my lack of understanding. What is sts-x-none and wssmui patches? Are they listed in this URL: https://support.microsoft.com/en-us/help/4462211/description-of-the-security-update-for-sharepoint-enterprise-server?
You should be applying the latest PUs, i.e. the September 2020 PUs. If your security team indicates there is a vulnerability based on an older PU, the security scanning software isn't smart enough to look at individual binary versions and that needs to be addressed with the security software vendor.
Most months have two patches, sts-x-none and wssmui. They're listed on the given month's patch listing - https://learn.microsoft.com/en-us/officeupdates/sharepoint-updates#sharepoint-2016-update-history.
Thank you for this information @trevorseward . One more question, I've read that once you install a patch, it cannot be undone. My SharePoint servers are backed up by a third party vendor. Besides a backup already taking place, can a snapshot of the server be taken before applying the patch, just in case something goes wrong?
That's correct, and you must shutdown the farm before patching if you're going to snapshot it. See https://learn.microsoft.com/en-us/sharepoint/install/deploy-sharepoint-virtual-machines.
According to this article, if a backup or snapshot is taking place, you must shutdown the farm. Is there a particular order in which the farm should be shutdown? I have 1 WFE, 1 APP, 1 OOS and 1 SQL servers.
No order. OOS is not part of this process.
With that said, it is extremely rare to have regressions with 2016+ patches, I wouldn't worry about it. Just backup prior.
Thank you.
Hi @trevorseward ,
I've already accepted your answer but I have another question. I've patched two non-production servers successfully. I've installed the PU and ran Configuration wizard as recommended. I have a concern with running the SharePoint Configuration Wizard in production, in that, I cannot predict how long it will take to complete. When SharePoint Configuration Wizard is running SharePoint application is down. The process did not take long in the non-production environments but those environments do not have the amount of data that production has. If it seems the wizard is taking longer than my maintenance window, will cancelling the process corrupt SharePoint?
You can't cancel the process during the period that will take a long amount of time. If downtime is a concern, I'd recommend adding additional SharePoint Servers.
Is there a way to clone SharePoint production server down? So, clone prod APP and WFE down to non-production server. Or, copy production database down to non-production database. That way, I can possibly get an idea of how long patching a production environment will take.
You can copy the content databases to a development environment and run the upgrade there. Do not clone SharePoint Servers.
https://learn.microsoft.com/en-us/sharepoint/install/deploy-sharepoint-virtual-machines
Just to be clear, I can copy all SharePoint databases that were a part of the SharePoint installation to a development environment, correct? Also, is this a good article to follow for copying the databases?
No and no. You can copy content databases and attach them to web application(s) on the development farm. Certain service application databases can be copied and a service application can be created/updated to point to the copied databases.
The Config and Admin databases are farm-specific and cannot be restored.
That article has more steps than you need to take. On your prod SQL server, backup the appropriate database(s). Restore to development SQL Server. Attach the restored databases to your dev SharePoint farm.
I would say you should only bring down the content databases as the service apps typically go fast during an upgrade.
Ok thanks for the clarification. To attach the restored content database to my Dev SharePoint farm, do I need to detach the database first that's already on my Dev farm? Should I follow the article below?
https://learn.microsoft.com/en-us/sharepoint/administration/attach-or-detach-content-databases
What do you mean by, "I would say you should only bring down the content databases as the service apps typically go fast during an upgrade."?
If the sites in dev have the same path or same site ID as prod, yes you should detach the content databases from dev prior to mounting the prod content databases.
The service application portion of the upgrade is generally quick. The content database upgrades are what can take a significant amount of time.
SharePoint is connected to the SQL servers through an alias. So, the alias name is what's attached to the farm. Dev has a different alias from Production. If I do not detach the content database from Dev and attach the prod content database to the Dev SharePoint farm, how's does SharePoint know which database to connect to?