Let’s face it. SharePoint can be scary. There’s an endless variety of things that can go wrong. Luckily, there are experts out there who can save us from ourselves.
One of our AnchorPoint Support team members shared this harrowing, real-life SharePoint horror story…
The curse of the never ending Patching
Not so long ago, I was updating SharePoint to a newer Cumulative Update on my customer’s Production Farm. It began like normal. SharePoint decided to take its time installing the CU. I rebooted the servers, and then proceeded with the Product Configuration Wizard on the Central Administration server. It progressed along nicely, quickly completing the first few tasks, slowing down to complete a few more, and then reached Task 9 of 10. However, when it got to Task 9, it decided to fail.
The error it provided me was: “An exception of type Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException was thrown. Additional exception information: Failed to upgrade SharePoint Products”. Could it be any more generic? I reran the Product Configuration Wizard, hoping for the best. In fact, I did this several times, only to return the same result. As it began getting later in the evening, I began to panic. I had not had this issue on the test and development farms. I started trying everything in the SharePoint fix-all book: IISReset, restart SharePoint Timer Job, restart the servers, re-run the wizard as an administrator (in order to be certain), verify DB permissions for my install account, and verify local admin and local security policy permissions; yet, only to find that the wizard still failed at the same point. I Google searched the error and tried various suggestions, but was still unable to resolve the issue.
At this point, I was several hours into troubleshooting and the clock was ticking. I needed to get the farm back up and running! So into the logs I dove. I checked ULS logs and the upgrade log file. Again, I turned up empty handed. I could not find even the slightest hint as to what my issue was. Next thing I checked: the Event Viewer. In there, I found a slight glimmer of hope. Around the same time as the error entry that the Product Configuration Wizard had failed, I saw another error. One concerning the database. It stated: “Unknown SQL Exception 15151 occurred. Additional error information from SQL Server is included below. Cannot alter the role ‘db_owner’, because it does not exist or you do not have permission.”
I quickly Google searched this error. I found a blog about it. The blog informed me that I needed to grant the install account the “db_owner” schema as one of its Owned Schemas for the SharePoint Subscription Settings database. Racing to add this setting, in the hopes that the Product Configuration Wizard would finish successfully, I logged into the SQL server, opened SQL Management Studio, and looked down the list of databases. I selected the database corresponding to the Subscription Settings database, expanded it down to the Security layer, right-clicked on the dbo user (which corresponds to the install account), and selected Properties. Upon selecting the Owned Schema tab, I ticked the box next to the db_owner schema, and applied the settings.
Quickly, I swapped back to my Central Admin server, where the Product Configuration Wizard had failed, and reran it. It reached Task 9 of 10. I sat there, staring it down, hoping and praying that it would finish successfully. The wizard was sitting on Task 9 for a while. In fact, it had been there longer than the many initial attempts. This is a good sign; perhaps, it is working. Several more minutes of anxiety passed by. Eventually, it reached Task 10, and I was greeted with the loving embrace of “Configuration Successful”! After many hours of troubleshooting, cursing, re-attempting, and thinking all hope was lost, I had finally won the battle. But, hey! That’s the love-hate relationship we have with SharePoint.