Introduction by Vishwas Lele:

Amazon Web Services (AWS) CTO Werner Vogels offers this great piece of cloud advice: “Treat everything as a programmable resource, including data centers, networks, compute, storage and load balancers.” In other words, automate every aspect of your (cloud-based) infrastructure. There are significant benefits in following Werner Vogels’ advice:

  1. You can build systems that are cost aware by only keeping the parts of the system that are needed and turning off everything else .
  2. Capacity planning is hard. It is much better to dynamically build capacity based on the need.
  3. Failures are not an exception but a rule. Rather than building complex logic to handle exceptions, make your systems fault resilient by provisioning failover resources as needed.
  4. Make your systems more agile – systems that can scale in the direction of business vs. a design time scaling criterion.

Given AIS’ years of experience with SharePoint, we are always looking for ways to make the underlying infrastructure more cost effective, scalable and robust. Fortunately, the aforementioned benefits of automation apply equally to a SharePoint 2013 farm hosted in the cloud — whether it is the ability to dynamically provision a SharePoint 2013 farm on the fly, or the ability to scale up and down based on load, or the ability to make the SharePoint 2013 farm more fault resilient.

But it all begins with developing robust automation scripts to provision and manage a SharePoint 2013 farm. This brings us back to the purpose of this blog post by Abhijit Kumar. Abhijit discusses an automated approach for provisioning a SharePoint 2013 farm using Amazon Web Services. It is noteworthy that the automation approach we describe below is based solely on PowerShell. This might come as a surprise given that AWS offers services like CloudFormation, which enables creation of AWS resources, combined with open source tools such as Opcode Chef and AWS Puppet, which enable the installation and configuration of applications. We chose to rely solely on PowerShell for the following reasons:

  1. PowerShell is Microsoft’s canonical task automation framework, consisting of a command-line shell and a scripting language that has full access to COM and WMI, giving Windows administrators control over every aspect of Windows OS-based machines.
  2. PowerShell scripting language is based on the .NET framework. This means a PowerShell script can take advantage of .NET framework enhancements such as Workflow Foundation (WF). We use WF extensively to manage long-running automation scripts.
  3. AWS Cloud Formation is not available on AWS Gov Cloud. AWS Gov Cloud is an isolated AWS region designed to allow U.S. government agencies and customers with sensitive workloads to address their specific regulatory and compliance requirements. Given that AIS services a large number of customers with stringent regulatory and compliance requirements, we needed an automation approach that worked on AWS Gov Cloud.
  4. If you read our earlier blog post about SharePoint 2013 automation on Windows Azure, you will notice that we have been able to achieve a high level of reuse between Windows Azure and AWS scripts for SharePoint 2013 scripts. While the WF-based provisioning logic is largely the same, Azure Service Management SDK calls are replaced with AWS Tools for Windows PowerShell. This reuse allows us the flexibility to offer our customers a choice between the industry leading IaaS platforms – AWS and Windows Azure.

Abhijth’s post below walks you through the script to deploy SharePoint 2013 Farm on AWS in an automated manner. I am confident that you will it useful. Please give the scripts a try and let us know.

The recent announcement about the general availability of Windows Azure IaaS comes with the following key enhancements:

  1. Remote PowerShell is enabled by default when deploying Virtual Machine using PowerShell.
  2. Availability of trial images such as SharePoint in the image gallery.

These enhancements make it easy to deploy a SharePoint Farm in an automated manner using PowerShell scripts.

The goal of this blog post is to walk you through such a script. Read More…

I was recently working on an automation task that involved opening an XML document, reading the values its contents, and passing them as arguments to install a variety of processes, etc., etc. All rather routine and mundane. Of course, my XML document was littered with environment variables and other special monikers that would be replaced after the file had been loaded. So I reached for my PowerShell editor and started putting together a solution. Then I got to thinking…why don’t I just embed PowerShell variables directly in the file?

Well, why not indeed. The problem was as PowerShell read the file in, it simply ignored my variables and I was stuck with an XML attribute value of something like $Domain\$User. It didn’t help me one whit. Surely there must be some way to convince PowerShell to evaluate that.

As luck would have it, there is! Or I should say, there are! Because it turns out there are multiple ways to do this, none of which are specific to XML (that was just my target data). So, let’s review the options…

Read More…

This week, many AIS team members are attending the Microsoft SharePoint Conference in Las Vegas, Nevada. We’ll be posting blog posts from each of them as they learn what’s new and what’s exciting during sessions, demonstrations and other conference highlights.

We’re out at the SharePoint Conference 2012 this week and learning a ton about the new features of SharePoint 2013. One of particular interest to the IT pros should be the introduction of PowerShell 3.0. There are a number of new features available in PowerShell 3.0 not to mention the cmdlets!

Read More…