Quick Tip: Powershell to List All Databases Used by SharePoint 2010

The following Powershell cmdlet gets a list of all the databases currently used by SharePoint 2010 farm:

Get-SPDatabase | Sort-Object Name | Format-Table Name

If you just need a list of the content databases you can use the following script:

Get-SPContentDatabase | Sort-Object Name | Format-Table Name
Both are useful to try to understand which databases SharePoint 2010 uses if you have a shared database server.

Powershell rules!!!!

See you,

Amadeu.

Broken Reference to SharePoint 2010 Content Database

We got a nice surprise right before leaving for the Easter holiday. One of our web applications stopped working and it was sending all the users to the custom error page.

Checking the event viewer and the ULS logs we could identify this error message:

Log Name:      Application
Source:        ASP.NET 2.0.50727.0
Date:          4/5/2012 4:29:46 PM
Event ID:      1309
Task Category: Web Event
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      SERVERNAME
Description:
Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 4/5/2012 4:29:46 PM
Event time (UTC): 4/5/2012 9:29:46 PM
Event ID: e14426efea4a44bb9aa16d14ea767445
Event sequence: 57
Event occurrence: 21
Event detail code: 0

Application information:
Application domain: /LM/W3SVC/1726127450/ROOT-1-129781347974963750
Trust level: WSS_Minimal
Application Virtual Path: /
Application Path:
E:\inetpub\wwwroot\wss\VirtualDirectories\WEBAPPNAME\
Machine name: SERVERNAME

Process information:
Process ID: 5064
Process name: w3wp.exe
Account name:DOMAIN\APPLICATIONPOOLACCOUNT

Exception information:
Exception type: NullReferenceException
Exception message: Object reference not set to an instance of an object.

Request information:
Request URL: http://WEBAPPURL/Pages/Error.aspx
Request path: /Pages/Error.aspx
User host address: 10.0.0.2
User:
Is authenticated: False
Authentication Type:
Thread account name: DOMAIN\APPLICATIONPOOLACCOUNT

Thread information:
Thread ID: 8
Thread account name: DOMAIN\APPLICATIONPOOLACCOUNT
Is impersonating: True
Stack trace:    at
Microsoft.SharePoint.SPSite.PreinitializeServer(SPRequest request)
at Microsoft.SharePoint.SPWeb.InitializeSPRequest()
at Microsoft.SharePoint.WebControls.SPControl.EnsureSPWebRequest(SPWeb web)
at Microsoft.SharePoint.WebControls.SPControl.SPWebEnsureSPControl(HttpContext
context)
at Microsoft.SharePoint.ApplicationRuntime.SPRequestModule.GetContextWeb(HttpContext
context)
at Microsoft.SharePoint.ApplicationRuntime.SPRequestModule.PostResolveRequestCacheHandler(Object
oSender, EventArgs ea)
at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step,
Boolean& completedSynchronously)

I’ve seen this same error message before when we restored a content database backup and got an error navigating on the site . I tried to resolve it applying the same steps but it didn’t work.

Checking further the issue we found out this error message on the Microsoft.SharePoint.SPSite.PreinitializeServer method has a relationship with the database connection. On Central Admin, under Application Management > Manage Content Databases I checked the content database for this web application and I couldn’t find it, there was no content database attached to the web application. It was a huge surprise. Then checking for the same content database on Upgrade and Migration > Review database status screen I was able to find. I tried to remove it from the web application but it was throwing an “object reference is null” exception.

We then went to the lower level attempts on solving and started trying Powrshell and stsadm scripts. We tried  to run the following commands:

  • remove-spcontentdatabase -identity “database name”
  • test-spcontentdatabase -name “database name” -webapplication “web application url”
  • stsadm -o deletecontentdb -databasename “database name”
  • stsadm -o addcontetdb -databasename “database name”
  • mount-spcontentdatabase -name “database name” -webapplication “web application url”
  • dismount-spcontentdatabase -identity “database name”

None of them worked.

In order to get more information about the content database we ran the following commands:
$db =  Get-SPDatabase | where {$_.Name -eq “database name”}
Then we printed out the $db object and got an output like this:

Id                                : 1c5db325-b77f-4f18-a7a1-664ca0d05249
Name                         : content database name
WebApplication    :
Server                       : database server name
CurrentSiteCount : 1

The WebApplication property was empty, and checking the other content databases we could see a value like “SPWebApplication name=web application name”.

Since this was a PROD issue we called Microsoft support and got a SharePoint Engineer to handle it. After a little research on the servers, lot of Powershell commands we got the confirmation of what was wrong. The content database was recognized by SharePoint as part of the farm but it wasn’t recognized as a content database. It was returned when we ran the get-spdatabase Powershell cmdlet,  but it wasn’t returned when we ran the get-spcontentdatabase Powershell cmdlet.

The solution for this issue was:

Run a Powershell script to get and deleter the content database:
$db =  Get-SPDatabase | where {$_.Name -eq “database name”}

$db.delete()

Actually, it doesn’t delete the database itself but removes all references SharePoint has to it.

Then we attached the content database back to the web application using Central Admin > Application Management > Manage Content Databases page.

It worked liked a charm and everybody could go have fun and enjoy their Easter holiday…..a few hours late of course. lol.

See you,

Amadeu.

Error Moving CMS Pages on the Pages Library

When moving a CMS page to a subfolder on a Pages library using the Manage Content and Structure tool, the Content Managers were getting the following error:

System.ArgumentException – 0x80070057
at Microsoft.SharePoint.Library.SPRequestInternalClass.GetMetadataForUrl(String bstrUrl, Int32 METADATAFLAGS, Guid& pgListId, Int32& plItemId, Int32& plType, Object& pvarFileOrFolder)
at Microsoft.SharePoint.Library.SPRequest.GetMetadataForUrl(String bstrUrl, Int32 METADATAFLAGS, Guid& pgListId, Int32& plItemId, Int32& plType, Object& pvarFileOrFolder)
at Microsoft.SharePoint.SPWeb.GetFileOrFolderObject(String strUrl)
at Microsoft.SharePoint.Publishing.CommonUtilities.GetFileFromUrl(String url, SPWeb web)
at Microsoft.SharePoint.Publishing.PublishingPage.get_Layout()
at Microsoft.SharePoint.Publishing.Internal.DeploymentWrapper.cachePageInfoForXmlFiltering(PublishingPage publishingPage)
at Microsoft.SharePoint.Publishing.Internal.DeploymentWrapper.configureExportCopyOrMove(String[] sourceSmtObjectIds, SPExportSettings& exportSettings, SPIncludeVersions versionsToInclude)
at Microsoft.SharePoint.Publishing.Internal.DeploymentWrapper.MoveItems(String[] sourceSmtObjectIds, String destSmtObjectId)
at Microsoft.SharePoint.Publishing.Internal.WebControls.MoveItems.Copy()

Operation to Move PageName.aspx to /Pages/SubFolder failed
After a little bit of research/thinking (yes, it doesn’t hurt a lot as some people imagine….lol) I recalled this site had been restored from a SharePoint farm in a different environment. So there was a chance the reference to the page layout was still pointing to the web application’s URL of the previous environment.

Fortunately, there are Powershell cmdlets created by Gary Lapointe we can use to solve this kind of issues. I just downloaded it, installed and made sure I got a fresh new Powershell window.

In the case I used the Repair-SPPageLayout cmdlet to fix all the references to page layouts. The syntax is:

Get-SPWebApplication “http://webapplicationurl” | Repair-SPPageLayoutUrl

This command repaired all the content pages which were not checked out. Then I tried the moving operation again and it succeeded.

 

See you,

Amadeu.

Upgrading SharePoint 2010 Solution Packages

When deploying solution packages created using Visual Studio you might have a bad surprise and have all your IIS application pools stopped and restarted in a long and painful operation.

But why? What causes it?

By default all the Visual Studio created solution packages ask for an IIS reset when the solution package is added and a start/stop operation when the solution package is upgraded.

Normally you would avoid this type of operations because they are long and affect all the application pools on your WFE servers, so users will not be happy having their applications restarted when pushing other site’s code.

In order to change it, go to the properties of your solution package on Visual Studio (you will need to do it for each solution package you have). To access these properties you need to open the solution package file in design mode on Visual Studio.

Change the Reset Web Server property value to False. This property controls whether IIS will be restarted when you add the solution to your Sharepoint farm.

Change the Reset Web Server Mode On Upgrade property value to Recycle. This property controls whether the application pools will be recycled or will be stopped and restart when you upgrade the solution package.

This will make your solutions be upgraded quickly and decrease the impact on other web applications which don’t use the solutions you’re upgrading.

See you,

Amadeu.