Archive

Archive for January, 2014

Migrating SharePoint 2007/2010 Databases to New SQL Server/Cluster Without Having to Completely Reconfigure SharePoint Utilizing SQL Alias

January 31, 2014 2 comments

I recently had to migrate from an old SharePoint 2007 SQL Server environment to a more stable/robust SQL Server 2008 R2 environment to stabilize and increase the performance of SharePoint. I needed to do this with little to no down time. I was able to accomplish this by utilizing SQL Aliases. Below are the steps I took to accomplish this. Steps work for both MOSS 2007 and SP2010.

For this example I will be using SQL1 as the name for the “old” SQL Server Instance, and SQL2 for the “new” SQL Server Instance.

1. Stop all SharePoint services that might be communicating with SQL1 back-end. This helps to prevent any writing to the databases while they are being backed up.
2. Backup all SharePoint 2007 databases including: (Config, SSPs, Search, and Content) from SQ1.
3. Move all SharePoint 2007 databases to SQL2.
4. Restore all SharePoint 2007 databases to SQL2.

On the SharePoint 2007 Server we now need to create a SQL Alias (Host File for SQL) to tell SharePoint to point to the new SQL2 instance. What we need to do here is use the same exact name as the “old” SQL Server Instance SQL1 as the SQL Alias name. This is so to trick SharePoint into thinking it’s still utilizing the same SQL1 SQL Server Instance, which will prevent us from having to completely reconfigure the SharePoint farm.

Next log into one of the SharePoint 2007/2010 servers and bring up the SQL Server Client Network Utility tool. This comes native with Windows so nothing needs to be installed.

1. Start, Run, Type – cliconfg
2. Select the Alias tab and click the Add… button
3. Enter in the Server Alias (This will be the name of your “old” SQL Server Instance – SQL1)
4. Select the TCP/IP radio button under Network Libraries
5. Enter in the new SQL Server name (SQL2) for the Server Name under Connection Parameters
6.  Click “Ok” and “Ok” to close out of the cliconfg window.
6. Restart all SharePoint 2007 Services.
7. Do an IISreset on WFE Servers.

Browse to your SharePoint environment to verify portal functionality.

That’s it pretty simple.

Fixing SharePoint 2010: Access To This Website Has Been Blocked

January 7, 2014 1 comment

I ran into an issue recently that prevented me from activating a Web Application Feature to a specific web application in my enviornment. When trying to activate the feature I was getting this error:

“Access to this Website has been blocked. Please contact the administrator to resolve the problem.”

Intially thinking it might be a permissions issue I switched users to the Farm Account, but was presented with the same error message when trying to activate.

Usually when this happens you have to make sure there are no locks set on your Site Collections. You can check if there are any locks set by browing to:

http://CENTRAL ADMINISTRATION/_admin/sitequota.aspx

When I checked the Site Collection Quotas and Locks I did not notice my Site Collection as having any locks, so I was a little confused on why I was recieving this error.

What I failed to remember was, even though the main Site Collection did not have a lock, there could possibly be other site Collection within the same Web Application that might have a lock. In my enviornment I have over 20+ databases with over 50 Site Collections.

The Web Application feature I was trying to to activate was trying to iterate through all my Site Collections associated with the Web Application, and unfortunately there was a Site Collection baried within my Web Application that had locks set. Once I found which Site Collection had the lock, I disabled that lock, and then I was able to activate the feature.

If you ever run into this issue, make sure you check ALL site collections within your Web Application and make sure there are no locks.

I will blog about how to automatically check which Site Collections have locks via PowerShell so you don’t have to manually search each Site Collection through Central Administration, especially if you have many Site Collections.

How To Fix: System.ArgumentException: Invalid Field Name {GUID} When Trying To Access a SharePoint 2010 List/Document Library

January 7, 2014 2 comments

I recently had a customer bring to my attention an issue with one of their SharePoint 2010 document libraries they were trying to access, and could not. Upon the customer trying to access the list they were presented with a Correlation ID error that prevented them access to the library.

Looking at the SharePoint ULS logs for this correlation Id I saw this error:

System.ArgumentException: Invalid field name: {GUID} [URL of list]

With me not knowing what the field name was for the referenced {GUID}, I knew of two ways of getting it.

1. Through SQL or
2. by exporting the SchemaXML of the site

Both ways are discussed in a previous blog I did: http://jshidell.com/2012/06/07/removing-a-corrupted-site-column-in-sharepoint-2010/

After determining the field name for the {GUID} I was then able to identify the problem column or content type. In my case the issue was with a column name “TypeTaxHTField0” or simply “Type”. SharePoint by default appends the TaxHTField0 suffix to the end of all the static names.

Now that I have the Field Name Column, I needed a way to get into the lists settings to either delete or remove this column from the list. Since I was unable to access the list because of the correlation id, I had to determine the {GUID} of the list.

The way to get the {GUID} of the list I turned to PowerShell.

Below is the script I used to get the {GUID} of the list.

$site = Get-SPSite {URL OF YOUR SITE}
$web = $site.OpenWeb(“SUBSITE”)
$web.lists | Format-Table title,id
$web.Dispose()
$site.Dispose()

Once I got the {GUID} of the list I was then able to browse to the library settings by appending the {GUID} to the end of the list settings edit URL

i.e.
http://URL OF SITE/SUBSITE/_layouts/listedit.aspx?List={GUID}

Once inside the list settings I was then able to make the necessary changes. For me all I needed to do was remove the “Type” column from the Metadata Navigation Settings by removing it from both “Configure Navigation Hierarchies” and “Configure Key Filters”

Once I removed the “Type” column from the Metadata Navigation I then deleted the “Type” column from my list and then re-added it. Once I re-added it back into the list, I then re-added it back into the Metadata Navigation. Ater doing so I was able to access the list without error.

If you find you do not need that column at all, simply delete it from your list.

Hopefully this helps others who encounter the same issues.