Gimme All Your Cache!


Those of us who have the wonderful job of managing a SharePoint farm know, installing patches can be a bit like playing roulette. This is especially true when installing Cumulative Updates, but not limited to.

Those of us who manage a SharePoint farm with multiple servers have definitely seen our fair share of messages like the one below.

Obviously, the first thing you need to verify, is that the noted patch is actually on all the servers. If it is, often we are then directed by sites, even mine, to manually run some combination of the PSCONFIG.exe command manually via powershell. This typically works because we’re forcing SharePoint to skip important version checks etc.

I highly recommend before you jump to any powershell that you follow the instructions on the site below.

SharePoint 2010 – Clearing the Configuration Cache

What this site is doing is clearing your configuration cache on each server before you attempt to run the SharePoint Configuration Wizard on any of your servers. The instructions specifically indicate they are for SharePoint 2010, but they work for SharePoint 2013 as well.

I’ve found I’ve even had issues running the PSCONFIG.exe manually and I still cannot get the config to finish. Clearing the cache is what works. You may need to reboot your servers, and you may even need to clear the cache twice, but soon, it will likely resolve the issue. So if you’re sitting stuck at 10% for forever, kill that PSCONFIG.exe task in the Task Manager and clear your cache. But don’t thank me, thank , the author of the above article.

Advertisement

ISSUE: KB2844286 RESOLVED with Update KB2872441


Microsoft has finally released an update to the KB2844286 issue with SharePoint. That update is linked below.

http://support.microsoft.com/kb/2872441

We have installed it in our DEV environment and have verified the issue is fixed within our farm. I have also confirmed that you must still have KB2844286 installed and then install KB2872441 as you will still need the other security related patches from KB2844286 (or KB2844285, or KB2844287 depending on OS)

My original post can be found below as I am still updating that post as I get updates.

ISSUE: KB2844286 Security Update on SharePoint 2010

ISSUE: KB2844286 Security Update on SharePoint 2010


Came in today to find the following error message showing up on seemingly random web parts and lists throughout our SharePoint 2010 Foundation farm. ULS Logs on the servers weren’t very helpful.

[This issue has been RESOLVED see updates below]

KB2844286 Error

For the sake of search indexing, here is the text version of the error we are getting.

Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Microsoft SharePoint Foundation-compatible HTML editor such as Microsoft SharePoint Designer. If the problem persists, contact your Web server administrator.

We quickly tracked it down to a Security Update that was applied to our web front end servers last night. Check the OS below to find the KB update associated with your server.

Windows XP and Windows Server 2003

Windows 7 Service Pack 1 and Windows Server 2008 R2 Service Pack 1

Windows Vista Service Pack 2 and Windows Server 2008 Service Pack 2

This is in regard to the following Microsoft Security Bulletin for July 2013

Microsoft Security Bulletin MS13-052

As a temporary workaround, we found uninstalling the update (KB2844286) from your servers (all WFE’s and App servers) then performing an IISReset on the servers will resolve the issue. Several others have experienced this issue as noted in just one of many forums such as the one below

http://social.technet.microsoft.com/Forums/sharepoint/en-US/cc9a557b-93cd-40d5-965c-e0a2f107624d/unable-to-display-this-web-part-error-message-after-patch-kb2844286

If I find there is a solution better than uninstalling I will update this post to reflect that. As of right now, uninstalling this update is the best option.

[Update 7/16/2013 3:40pm]

It appears the error typically appears when a list or web part view has had the XSLT customized. At least in our Farm, that has been the common behavior.

[Update 7/17/2013 10:03am]

Not much of an update, but I’m awaiting contact from our Microsoft TAM to see about this issue. If we don’t hear from them soon, then we’ll be opening a ticket with Microsoft. Luckily we were able to work around the issue by uninstalling.

[Update 7/17/2013 12:50pm]

I just received confirmation from our TAM that Microsoft is aware of 2 issues regarding the patch noted in this article above. One of which appears to be the SharePoint issue we’re having.

[Update 7/17/2013 2:43pm]

Just spoke with our Microsoft Sr. Support Escalation Engineer assigned to our premier support ticket and here is their response (summarized).

“Our product group is currently working on the updated patch. We have no ETA for the new release at the moment.”

Looks like we wait then for a resolution.

[Update 7/17/2013 2:59pm]

One more confirmation from Microsoft Support and a link to the forum MS is using to track the issue publicly. No public information just yet beyond that, however.

“Both the SharePoint and .NET product groups are aware of the issue and they are in the process of fixing the patch.”

Follow the issue at this TechNet Forum

[Update 7/18/2013 9:24am]

So far I have heard of no updated patch being released yet by Microsoft. There were two MS Security Bulletin updates but it doesn’t appear they were related to this issue as they were for Bulletin MS12-006 and MS12-052.

[Update 7/21/2013 12:36pm]

Still no updated patch. Received an e-mail from our MS Support representative and they indicated they too have no ETA on any updates to the security patch. I guess I’d rather they take their time then rush an update out all to break something else. It would be a good idea if Microsoft were to either add a note to the update download page indicating the issue, or just pull the update altogether.

[Update 7/24/2013 8:28am]

I just got a message from our Microsoft Support representative and she informed me there is no update as of yet on a new download for the patch. No surprise there.

[Update 7/25/2013 7:50am]

As you can see from the comments that have arrived thus far, it appears Microsoft has provided a fix to the KB2844286 issue. We are in the process of testing it out in our DEV environment now. Let’s hope it fixes it and doesn’t cause more issues.

[Update 7/25/2013 8:22am]

I am at this point, comfortable with counting this issue RESOLVED. We’ve tested it in DEV and the solution resolves the problem and doesn’t seem to break anything else. We won’t be able to complete the resolution in our Production environment until after hours as we will have to re-install KB2844286 which will require a reboot and the patch requires at the very least an IISRESET.

Go to http://support.microsoft.com/kb/2872441 to download the update. Note: You will need to run an IISRESET for the update to take effect after installing.

SharePoint 2013 Error Writing to RBS Enabled Database


I recently configured a SharePoint 2013 Standard environment for a customer who required RBS for a video streaming service they wanted to build in SharePoint and I came across the following errors.

This is an array of errors I got depending on the site template (2010 vs. 2013) or what service I tried to write with, such as using Windows Explorer or using the Upload Document web interface.

This slideshow requires JavaScript.

Architecture

The architecture of this SharePoint environment was quite simple as you can see below.

  • SharePoint 2013 Standard
  • SQL Server 2012 Standard
  • RBS (FileStream)

All of this lives on the same physical server.

Symptoms

After having configured the SharePoint 2013 content database to use RBS as prescribed in the very useful instructions HERE, the end user gets the above error messages. Most often, the message states something similar to the below message.

Sorry, something went wrong

The URL ‘Shared Documents/filename.docx’ is invalid. It may refer to a nonexistent file or folder, or refer to a valid file or folder that is not within the current Web.

You will find later, that this error is not very helpful.

No new documents can be uploaded or created, and existing documents cannot be edited or removed.

Troubleshooting Attempts

I spent and inordinate amount of time troubleshooting this issue. Google searches of the error turned up little useful information. The most common articles I found typically were related to folks that could write small files under 1MB but anything larger wouldn’t write. That wasn’t helpful as I couldn’t write anything.

Checking the BLOB file location and it appeared that I had RBS setup right as the folder was created.

Resolution

It turns out the issue was a permissions issue (as I had expected). It was a SQL permissions issue with the Web Applications service account.

I found that when I added the service account to the db_owner role on the content database, all of a sudden I could write to the site with new files, modify existing files and even delete files. Even the RBS portion was working just fine writing to the BLOB store.

Long story short, here are the instructions to manually add your service account for the web application to the db_owner role on the content database.

  1. Open SQL Server Management Studio
  2. Expand the Database folder
  3. Expand the specific content database you’ve configured for RBS
  4. Expand the Security folder
  5. Expand the Roles folder
  6. Double click db_owner (see below)
  7. SQL Database DBO
  8. In the Role Members section click the Add button (see below)
  9. SQL DBO Add
  10. Select the Web Application Service Account and click OK
  11. Click OK until you have returned to the screen from step 6 above
  12. You should now be able to write to your RBS enabled Content Database

I searched the web for quite some time and found no articles that was experiencing this issue so perhaps it was just a fluke. At first, I thought it was because I pre-created my content databases, but I did try letting SharePoint create the content database through the Add Content Database menu in Central Administration but I had the same issue.

I hope if you are experiencing this issue you find this article and it helps quicker than it took me to find the solution.

Clean Deploy of Central Admin


SharePoint 2010 is a really fun platform to administer, but configuring it can be a challenge, both technically and socially. If your organization is like mine and has a team of DBA’s administering your SQL instance/s for SharePoint, you’ll want to know how to deploy SharePoint 2010 as clean as possible.

What is a Clean install of SharePoint?

SharePoint 2010 can be installed and configured in a very short amount of time using the configuration wizards which basically will do almost all of the work for you. If you value your relationship with your DBA’s… DON”T DO THIS!!

Using the configuration wizard will inevitably create a slew of SQL databases with horrible names that include a long GUID at the end. This can be a real nightmare for maintenance and just plain ugly. (see below)

This is default SharePoint 2010 Foundation Database configuration. Standard/Enterprise are much worse by default.

This article will just address that of deploying and configuring the SharePoint Farm and Central Administration web application so as to keep that aspect of the installation clean.

This is what SharePoint 2010 Foundation could look like with some extra effort. Standard/Enterprise can be cleaned up as well.

If I can’t use the wizard, what do I use?

In order to do this, you will need to use the SharePoint 2010 Management Shell to do this as there is no clean way of doing it via a GUI interface that I know of.

But don’t get too nervous just yet, because even though it’s powershell, it’s pretty easy, and if you follow my steps, you can do it with little to no powershell experience. Leave a comment if you’re interested in downloading a script that makes these steps even easier.

NOTE: I highly recommend you familiarize yourself with PowerShell if you plan on administering SharePoint.

SQL Steps

  • Install SharePoint on your server
  • Skip to SharePoint Steps Section if not using Pre-Created Databases (i.e. are you or DBA’s creating empty databases, if so continue to next step)
  • Run SQL Server Management Studio 
  • Connect to SQL Instance SharePoint will reside
  • Click New Query
  • Enter the following commands

CREATE DATABASE “SharePoint_Config” COLLATE LATIN1_General_CI_AS_KS_WS
CREATE DATABASE “SharePoint_AdminContent” COLLATE LATIN1_General_CI_AS_KS_WS

  • Press F5 key when ready to execute
  • Verify the new Databases “SharePoint_Config” and “SharePoint_AdminContent” were created successfully

SharePoint Steps

  • Navigate to Start > All Programs > Microsoft SharePoint 2010 Products > SharePoint 2010 Management Shell
  • Enter the following command (Replace < > entries with specified info)

psconfig.exe -cmd configdb -create -server <“SQLServerName/Instance”> -database “SharePoint_Config” -user <“domain\username”> -password <“password”> -admincontentdatabase “SharePoint_AdminContent” -passphrase <“PassPhrase”>

  • Ensure the command completed successfully (see image above)
  • Now enter the following command to configure the Central Administration Port (You could proceed using the Configuration Wizard if preferred)

psconfig.exe -cmd adminvs -provision -port <“Port”> -windowsauthprovider onlyusentlm

  • Click Start > All Programs > Microsoft SharePoint 2010 Products > SharePoint 2010 Central Administration
  • Ensure the site comes up

You’re now on your way to a happy and clean SharePoint 2010 installation and a happy team of DBA’s

Again, if you’re interested in getting a script from me that performs this for you so all you need to do is enter your specific information please leave a comment and I’ll ensure I get it to you.

SharePoint 2010 Disaster Recovery Planning – Part III


A backup is useless if it cannot be restored. The only way to determine data can be restored is to perform periodic restores. A good DRP will include a recommended test restore schedule such as quarterly or annually.

There is no way to test every situation, but the most likely scenarios should be tested. This includes testing your procedures as well as the actual data restoration. Ensure your DRP includes a section on Test Cases or Smoke Tests.

In SharePoint there are two primary methods for restoration.

  • Central Administration
  • Windows PowerShell

In most cases using the Central Admin tool is the preferred method for restoration as it is less complicated, though you have less options to choose from.

If Project Server 2010 is integrated into your SharePoint 2010 there is more to consider. Let me know if you’re interested in this information.

There are also two restoration configuration options as well to consider.

  • Same Configuration – Used to restore a farm with the same server, service, and database names.
  • New Configuration – Used to restore a farm to a completely different environment. This could be different Web or App servers or a different SQL server.

Click Here to download a copy of some simple restore instructions using both a New Configuration and Same Configuration.

Often, an entire Farm restore is not required. There may be instances in which a single Site Collection or Site needs to be backed up and restored. For this there are two more options to choose from.

  • Site Collection Backup (Granular) – Used to take a snapshot of a Site Collection so the entire collection can be restored. Click Here for more backup information.
  • Export/Import – Often used to move sites, lists, or libraries from one collection to another but can be used as a backup and restore of Site Collections, Sites, Lists, and libraries. Click Here for more information.

SharePoint 2010 Disaster Recovery Planning – Part II


To have a successful Disaster Recovery Plan (DRP) you need to be able backup and restore your product. This article will lay out a scripted Farm backup method.

NOTE: Scripts are included as-is and are intended as an example to use. Administrators should edit their scripts to meet their own business needs.

Microsoft recommends using the built-in Sharepoint Farm backup tools. Click Here for more information.

Below are 2 scripts that can be scheduled via Windows Task Scheduler to run a Farm backup. The first script is the backup script in PowerShell.

**There is no GUI method provided by Microsoft for scheduling the Farm backups**

Auto_Farm_Backup_Full.ps1
# Adds the Sharepoint Powershell snapin so scheduling via Windows Scheduler will complete using cmd shell

Add-PSSnapIn Microsoft.SharePoint.PowerShell

# Backs up the Farm via a Full backup

Backup-SPFarm -Directory "\\servername\share" -BackupMethod Full -Force -Verbose

If you are performing Differential backups change the <FULL> in the script above to <Differential> and save as a new script.

This second script is a batch file to be used to call the first script in the Windows Task Scheduler. The reason for the batch file is simply to ensure your PowerShell script is run in PowerShell not the Command.exe.

Execute_Auto_Farm_Backup_Full.bat
Powershell -command "\\servername\share\Auto_Farm_Backup_Full.ps1"
 
Ensure the account running these scripts has Read/Write permissions to the backup directory as well as the SQL Service account that is performing the backup.
 

In all you will have 4 scripts. Two for your weekly full backup and two for your daily differentials assuming you choose to do differentials. A typical backup schedule might look similar to the one below.

Day of Week

Backup Start Time

Backup Type

Saturday

2:00am

Full

Sunday

2:00am

Differential

Monday

2:00am

Differential

Tuesday

2:00am

Differential

Wednesday

2:00am

Differential

Thursday

2:00am

Differential

Friday

2:00am

Differential

This should get you going in the right direction in your DRP process. Don’t assume because you’ve got backups, however, that you’re protected and your DRP is done. We’re far from done so stay tuned for more ideas.