Monthly Archives: January 2014

Troublshooting a 404 error related to moving a content database

I’ve had an odd issue come up a few times now….

For one reason or another, a content database needed to be detached and then re-attached to the SharePoint farm.

The most recent need for this was so a specific content DB could me moved to a different disk on the SQL server.

In theory, the operation is pretty easy:
  • Umount the Content DB –  I did this from Central administration, Manage content databases
  • have the DBA move the DB to a new disk.
  • Mount the content DB – this is where trouble started….
Here’s what happened:

The Site collections in that DB were available on one WFE, but not the other one.

Hmm, now for the troubleshooting….

Using PowerShell, I used the command below on each WFE:

get-spcontentdatabase -webapplication http://myurl.com

Oddly, on the working WFE, my “moved” content database showed  up in the list.

On the non-working WFE it was missing.

The fix:

I tried unmounting and remounting from Central admin – no luck. (though one time the “working” WFE flipped to the other WFE!)

Next I thought I would get clever and use powershell on the broken WFE to mount it there – this didn’t work- I got an error that said the Content DB was already attached.

I also tried things like restarting IIS, Restarting the SharePoint Timer Service and Restarting the SharePoint Admin Service – no luck.

I also tried clearing the SharePoint Timer Cache – no luck either!

So Finally I unmounted it from the farm (again from CA)

Then I ran the command below on ALL nodes (WFE and APP) to confirm that it wasn’t in the farm anywhere:

get-spcontentdatabase -webapplication http://myurl.com

Finally I ran the mount-spcontentdatabase command from the Central admin box:

Mount-SPContentDatabase -name mydbname -WebApplication http://myurl.com

Note that I only had to run this once – I confirmed the Content DB was visible on all 5 boxes by re-running the get-spcontentdatabase command on each of them and all was good!

As a side note, I was lucky – Because we moved the content database, I knew what site collection to validate. Also as a habit, I log into each WFE to validate – had I used the public URL and gone through the load balancer,  would have had a 50/50 chance of seeing the problem.

To make matters worse, we have 18 content Databases in this web application. The Content database we moved was NOT the root site collection! Meaning uncaught issues would have gone unnoticed for a long time. And when the issues were discovered, they’d only apply to a single site collection and only then on a specific WFE would there be a problem. These kinds of situations are nearly impossible to figure out down the road.

So if you find yourself detaching & re-attaching content databases, be sure to test the site collections in those databases on each WFE, it could save you hours down the road.

(SharePoint 2010 SP1)

Troubleshooting Bad AD accounts and people picker issues in Central admin while granting Site collection admin rights

I had a strange problem today – While trying to set a site collection admin via central administration on SharePoint 2010, The existing user ID’s were both underlined with a red squiggly line, and trying to pick new names in people picker resulted in no results.

image001

At first I suspected the CA box had maybe been dropped from the domain or some other AD related issue.

But further investigation showed that other web apps on the same farm were fine.

Additionally, From the web app itself, I was able to select users in the people picker and they worked just fine, So the problem was only with the people picker in central admin, and only for this one specific web application.

I asked around on the SPYam forum on Yammer, and also at SharePoint-Community.net.

I got some great dialog going within a few minutes –

Adam Larkin asked if I had been using IE 10 – He had seen issues caused by IE – I was using IE 10 but this didn’t turn out to be the issue in this case.

Jasit Chopra suggested that I check Authentication mechanism – but this was set to NTLM, and was the same between the working and non-working site,

Paul Choquette – suggested I compare web.configs – another great suggestion – It didn’t turn up anything however.

Vlad (one of the founders of SharePoint-Community.net) also chimed in.

So far so good, No solution yet, but narrowed it down quite a bit. I always appreciate any help troubleshooting – sometimes just talking about things leads to a resolution.

Over on Yammer I had asked the question as well, and Trevor Seward had the suggestion to check the people picker settings. Combining Trevor’s suggestion along with Pauls, I compared PeoplePicker settings between a working web app and the non-working web app and found that the “broken” one had something in the ActiveDirectoryCustomFilter.

Specifically, here’s the powershell I used:

$webapp = get-spwebapplication http://myurl.com
$webapp.peoplepickersettings
#this showed that there was something set in a sub property of peoplepickersettings called ActiveDirectoryCustomFilter.

#next step to fix this was to reset that property, the code below was used:
$webapp = get-spwebapplication http://myurl.com
$webapp.peoplepickersettings.ActiveDirectoryCustomFilter = $null
$webapp.update()

Whats really amazing is that Trevor’s reply on Yammer came from his phone, including the above PowerShell commands!

I think today there were several lessons learned:

1) I know a little more about the people picker settings

2) Reaching out to the community for help can be both engaging and rewarding.

Special thanks to everyone listed above for their help today!

Update: Trevor has a nice article on troubleshooting PeoplePicker related issues at http://thesharepointfarm.com/2014/01/people-picker-troubleshooting-tips/