How Does SharePoint Outbound Email Work?

SharePoint outgoing mail is one of the simpler aspects of configuring your farm. You pretty much just point it to an outgoing email server. It can get slightly more complicated when you think about securing that outgoing email server.

SharePoint has no mechanism for authenticating with and SMTP server. That means that for SharePoint to be able to send out email notifications you'll have to leave it open for anonymous relaying and connections. Your SMTP server can be secured by only allowing connections to and relaying from known, safe servers.

So, which servers do you need to allow connections from in your SharePoint farm? The answer is ll of the front ends and the Central Administration(CA) server. At first I thought it was only the CA, but when we had some email issues I took a look at the SMTP logs and the SMTP server was recieving connections from all of the front end servers. It appears that the on-demand emails that are generated (access request emails, workflow start emails) are sent directly from the server the person is connected to at the time and the scheduled alert emails are sent from the Central Admin server.

One way of configuring you SharePoint mail environment would be to configure one of your front ends or your Central Administration server to be an SMTP server (this will also be beneficial for if/when you want to configure incoming email). Set it up to only allow relaying from the other front end servers in the farm and set up your network's SMTP server as a Smart host.
In this configuration you will have the ability to gather metrics on emails coming from SharePoint and you can worry about reconfiguring the SMTP server for relaying if you add new servers rather than bother your networking folks, they only have to worry about your single SMTP server now.

SharePoint and Mirroring

Rather than deal with issues we've run into with the Microsoft Clustering service, it was decided that we try SQL database mirroring...and in the process opened up another can of worms.

Careful planning and thorough design are the keys to success in any IT project, this article will show some of the things to consider before going with mirroring or clustering for you high availability solution.

The differences between SQL mirroring and clustering:

1. A SQL cluster uses a virtual server instance that the active server uses to host the Server...the entire server.
   A SQL mirror mirrors individual databases between two servers. By mirroring I mean it passes the transaction logs between servers.
2. SQL cluster shares a single storage location for databases
   With mirroring each server manages it's own databases, so there isn't a single point of failure.
3. A mirror can have a 3rd server that acts as a witness...it receives and passes on the transactions to ensure no transactions are lost.

The big advantage to clustering is that it is completely transparent to outside servers since no matter which server is active the servers will always connect to the virtual server which never changes. SharePoint doesn't have any method natively of detecting or handling a database failover. So this leads me to ask, how do we handle a failover?

There are two ways of managing this, the first is through stsadm. Run the commands to change the database server and reconnect the databases...I'll look those up and get back to you...This method seemed cumbersome to me, so of course there's more than one way to skin a SharePoint instance.
Another alternative is to use SQL client aliases. A SQL alias is basically a local nickname for a SQL server. You can configure Aliases by running "cliconfg.exe" and going to the alias tab. Add one, give it a logical name, select tcp/ip as the protocol and put in the SQL server FQDN.


Repeat for each of the front end and application servers. If the DB server goes down, or the databases fail over, just change this value on each of these. Sharepoint will refresh the connection within about 60 seconds and your users will just assume it was a blip in the system.

Now the next question: Do we really have to do this manually? on every one of the servers? What a pain! Yes, you will have to do it manually and there's no "Microsoft" way of doing it...I also couldn't find any third party tools for making it happen either. On the advice of another blogger I wrote my own asp.net windows service to take care of this. The logic is pretty simple, connect to the witness server, query the sys.mirroring_databases view and check the principal server of one of the SharePoint databases (I usually have it check the config DB) and change the SQL client alias information accordingly. You do this in this registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo
There is a seperate value for each alias in this registry key.

So...what happens if a single database fails over and not the entire server? That's right, more SharePoint Instances to be skinned. One thing you can do is add a SQL server alert to catch WMI event changes to the DATABASE_MIRRORING_STATE_CHANGE object which then tells all the databases to fail over. A good way of doing this is documented on this page: http://www.mssqltips.com/tip.asp?tip=1564.
We ran into a problem when our server lost connectivity briefly and started failing databases over. When it came back online the remaining databases stayed Primary but the others stayed mirrored. I haven't investigated entirely to see if in that situation if the server would register a WMI event for a fail over. In the event that it doesn't, you're stuck with databases scattered on two different servers and your SharePoint server doesn't know where to find it's data. My recent idea was to make a separate alias for each database and tell the mirror watch service which database belongs to which alias. Now it doesn't matter where your databases are because SharePoint will be able to find them. This method will increase initial administrative overhead when creating new databases and installing initially, and will make SharePoint's server list in CA look huge. I'll have to do more research into any other side effects this may have on SharePoint as a whole.

A couple closing notes...and precautions about SQL mirroring with SharePoint.

1. Be very careful how many databases you put into a mirrored set. Unless you have a real beefy SQL server, you will get very strange behavior from your mirrored databases, 10 per server is one recommendation that I heard, but it's possible to have thousands, provided you have the processing power and RAM.
2. When designing your maintenance plans, keep in mind that the databases won't always be live on the same server. If you are planning to have databases live on different servers, you might want to write a T-SQL script that only backs up databases that are currently principals on both databases. If possible, make sure they write to the same backup location also to prevent confusion.

There are a few different whitepapers from Microsoft out there detailing the steps to take to get database mirroring functioning, the purpose of this article was to detail to you some further concerns you might want to consider when designing your SharePoint archicture. With SharePoint sometimes it's not so easy to make a second go of it.

To sum up, when considering an SQL high availability solution, some things to consider: how will the application fail over? How will you maintain the databases? How many databases are you planning to host? What are you looking for your solution to achieve? After considering these points you'll be more prepared to proceed successfully with your deployment.