Windows SharePoint Services on Amazon EC2
Elumenotion got bigger last year and our meager infrastructure was showing signs of strain. If you’ve downloaded the Skinner Setup over the last few months you probably noticed. So, we needed more bandwidth and better servers. We took a look at several options and after shopping around decided that the best solution for this site and the Atlanta .NET User Group site was to run Windows SharePoint Services 3.0 on Amazon’s Elastic Compute Cloud.
The key requirement was that we wanted a dedicated server instance that would allow us complete control with the ability to install web solution packages and other custom bits. There are a lot of choices out there for SharePoint hosting, but the ‘complete control’ requirement limited our choices and dramatically increased the cost. On these particular sites we aren’t doing any collaboration or heavy lifting and so most of the dedicated SharePoint specific solutions brought a lot of value added features that we didn’t want or need. In the end, the cost to run the EC2 instance is just over $100/month as configured, but we can easily increase capacity as needed.
I took notes to share the setup experience if you would like to try this for yourself.
First, download and read the Getting Started Guide, http://docs.amazonwebservices.com/AWSEC2/latest/GettingStartedGuide/, and setup the Elasticfox Firefox Add-in, http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1797. Strictly speaking, you don’t need Elasticfox but it definitely makes things easier.
An EC2 instance is based on an Amazon Machine Image, AMI. When you launch an instance, the instance will match the AMI. Amazon provides several different AMI’s for windows with different capabilities and price points. The one I chose is ec2-public-windows-images/SqlSvrExp2003r2-i386-Win-v1.03.manifest.xml. This AMI has the base components needed for a generic ASP.NET web server. The final build does not use SQL Express, but the image without it also lacks IIS and the .NET 2.0 Framework.
Before Installing WSS
You work with a running instance with a Remote Desktop Connection and Terminal Services. When you create an instance using the provided public AMI, EC2 will generate the computer name and the Administrator password. The first two things you should do in your instance are:
- Change the Administrator password
- Change the computer name
When you finish setting up SharePoint, you’ll create a new AMI from your fully configured instance. However, SharePoint will need to connect to the embedded SQL Server database. If new instances based on the private AMI change the machine name, SharePoint will fail because its connection string will be incorrect. To turn of the machine name generation, open %programfiles%AmazonEc2ConfigSetupconfig.xml and set Ec2SetComputerName to disabled and then open %programfiles%AmazonEc2ConfigSetupbundleconfig.xml and set setsysprep to no.
The first time I created an AMI, I didn’t know this and I wound up with a useless image!
Whoever created the base AMI installed the .NET 2.0 Framework before they installed IIS. As a result, IIS does not have the correct setup for ASP.NET 2.0. To fix this problem, open Control Panel|Add or Remove Programs. Select Microsoft .NET Framework 2.0 Service Pack 1 and click Change.
1. Download and install WSS 3.0 SP1 from http://www.microsoft.com/downloads/details.aspx?FamilyId=4191A531-A2E9-45E4-B71E-5B0B17108BD2.
2. Install the December cumulative update from http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=960010&kbln=en-us.
3. Create your site collection
4. Create and mount a block storage volume (See the Elasicfox and EC2 manuals)
5. Move the databases to the EBS volume (See Matt Johnson’s blog for a walkthough) -OR- setup a backup if 10gb is enough
The biggest decision you have to make is with regards to #5. The each instance comes with a 10gb OS partition. When you install WSS and create site collections, the databases will start out on that 10gb partition of which almost 6gb will be free. If you expect to have more than a few gigabytes of content, you should create and mount an EBS volume and move the databases. The other thing that you must understand is that, should your instance shut down for more than a few minutes, EC2 will delete it. When you create a new instance it will have whatever content the 10gb OS volume contained when you bundled the image. So, if your site is volatile, you should move the database.
On the other hand, if the content databases are small and change slowly, you might choose to use a backup/restore strategy. The Elumenotion and Atlanta .NET sites are both small. A scheduled job uses stsadm –o backup each night to create a backup on the persistent EBS volume. On the off chance that we lose the instance, the recovery requires that we create a new instance from the AMI, mount the EBS volume, and restore the backups.
Both sites send emails for alerts and for the various request forms. This is a challenge on EC2 because the infrastructure doesn’t support reverse lookups. Therefore, any mail sent from the instance will get ignored as spam in most cases. To work around this problem we use an SMTP relay service provided by AuthSMTP. For $40 a year we can relay 2000 messages a month which will support both our alerts and email to the user group members. The server uses the regular old Windows Server 2003 SMTP service that is configured to relay through AuthSMTP. SharePoint uses the local SMTP service to send the emails.
Finishing the Configuration
Once you have everything setup:
1. Bundle the image (See the Elasicfox and EC2 manuals)
2. Register the image (See the Elasicfox and EC2 manuals)
This process took a couple of hours and our sites both use the anonymous membership provider which is beyond the scope of this post. If you are interested in running on EC2, but need help, Elumenotion is happy to help. Drop us an email at firstname.lastname@example.org!
Author: Doug Ware