Installing SharePoint on a "non-standard" SQL Port

Attempting to install SharePoint on a "non-stardard" port can be a challenge.  Typically a Database Administrator will not run SQL on the standard port for security concerns.  Additionally, you might be attempting to install SharePoint on a Cluster and attempting to connect to the Cluster Port where your instance of SQL is being hosted.  

The "non-standard port" creates a challenge for SharePoint Administrators and the SharePoint Installation.  The SharePoint installation is looking for SQL Server on the Standard Port (1433).

An option that I've used and found to be very effective is the creation of a SQL Server Alias on each server in the farm.  It's never bad, in my opinion to alias your SQL Server connection.  You never know when this will be helpful in the future, specifically in the case of a database migration or hardware refresh.



Steps to create a SQL Server Alias:

1. Open SQL Server Client Network Utility.  (I believe this tool is native to Server 2003, 2008 and 2008 R2).
2. Click on the Alias tab
3. Click Add
• Server Alias:  "Enter the Alias information (eg. "SPDatabase")
• Network Libraries:  TCP/IP
• Server Name:  "Enter the name of the SQL Server you where the Databes will be hosted"
• Dynamically Determine Port:  "Uncheck to enter a specific port, or leaved checked to dynamically determine port

Notes:  If you leave "Dynamically determine port" checked, your Database Administrators can do some magic on their side to forward requests from a specific account to a specific port. 

You'll need to recreate these steps on all the servers in the farm.

SharePoint 2010 - Uniquely Secured Content

A very nice feature from SharePoint 2010 is the visibility into site content. I can't even count the number of times I've received the question from users "I gave them access to my site but they still can't see the list!".

There's a simple explanation for this. Inheritance is broken and "The List" has unique permissions. Unfortunately the Technology Team, more often than not, needed to get involved to communicate to with the user.  For the more seasoned business users, the next question would be "So what do they have access to?".

Great question and a great answer for SharePoint 2010 to solve this problem?

Under Site Permissions, you have the option to see content with Unique Permissions.  Click on the link "Show me uniquely secured content".



Show me uniquely secured content



Microsoft has really been listening to our Admistrative Challenges and gave a great and simple way to continue to empower the users.  Once clicking on the link we can see what's uniquely secured.  In the screen shot below, "Site Collection Images" and "Style Library" have unique permissions and are not inheriting from the site. 

Docs and Test contain item level permission in side the libraries which is defined with "Lists that may contain items with unique permissions".  It's a little bit misleading because Docs is a document library, but let's focus on what's important:  We have better visability into our busines content and can better share those insites with our clients. 

The Search Service is not able to connect to the machine that hosts the administration component.

I've seen many posts about people who are trying to deploy the search service and are receiving this message. Unfortunately most of the solutions I've see say "Rebuild the farm", "Delete the service and start over" or some other doom and gloom scenario. I've found something that seems to be consistently missed - PERMISSIONS

When the Search Administration Web Service for Search Service Application component is created, it is only granted access as Local Farm - Full Control. Basically if you're not creating the Search Service as the Farm Account, you will see this message.

Never fear! There is a very easy fix. Give your installation account permissions to the Search Administration Web Service for Search Service Application.

This will prevent you from having to delete the service, rebuild your farm and lose your sanity.