Blog Post

Automating GigaCloud Installation with Azure Resource Manager and PowerShell Desired State Configuration

GigaTrust has invested years of effort into creating GigaCloud, our fully managed offering to help our customers protect their email and documents, in-use and at-rest.

Up until now, installing GigaCloud has been a manual process involving multiple machines running Windows Server with various roles and cluster configurations. Starting from scratch, this installation can take a full day or more, with pages and pages of instructions to follow, and lots of configuration tasks that are detailed and error-prone. When a problem is discovered with the installation, figuring out what went wrong can take hours.

Although we’ve gotten good at it, as we gain more and more customer adoption of GigaCloud, we know there’s a better way to do this, and we’re going full-speed ahead with automating the installation process.


Our customers span the range of enterprises around the world. Some are well on their path to a hybrid cloud infrastructure. Some are still keeping all of their most important services on-premises and behind the firewall. Some want to use GigaCloud as Software-as-a-Service, managed by GigaTrust. Some want GigaCloud deployed as a one-click virtual appliance deployed in their Azure subscription, while some want it deployed as a set of Hyper-V virtual machines.

In other words, our automation solution has to be flexible and powerful.

Fortunately, Microsoft has us covered with Azure Resource Manager (ARM) and PowerShell Desired State Configuration (DSC).

Make It So

ARM and PowerShell DSC both allow us to do declarative configuration. Instead of writing scripts that procedurally run through the steps of installing and configuring all of the pieces we need to run GigaCloud, ARM and PowerShell DSC allow us to write templates and code that declare what we need to build. For the most part, we don’t have to worry about how it happens… we just say what we want, and Windows and Azure make that happen for us.

Jeffrey Snover, the inventor of PowerShell, Chief Architect of Windows Server, and a Microsoft Technical Fellow, calls this the “make it so” model of infrastructure. It’s not “do this, then do that” like most scripting is. It’s “here’s what I want… build it for me.”

It’s this “make it so” model that allows us to build the best automated installation solution we can, while keeping our ability to remain flexible in the face of different customer needs.


We’re looking at the installation of GigaCloud as consisting of two parts: creating VM’s, and configuring VM’s.

In the first part, we create the virtual machines. In Azure, we’re using custom, parameterized ARM templates to tell Azure to create the VM’s, with all of the required networking and storage infrastructure. In Hyper-V, we’re using PowerShell DSC, applied to the Hyper-V hosts, to tell Hyper-V what VM’s and networking to create for us.

Once the VM’s exist, we use PowerShell DSC to configure them. DSC allows us to tell each VM what it needs to do, from installing Windows features and roles, to joining a domain, to participating in a cluster. We’re even creating custom DSC resources to automate the installation of our software on top of the Windows features we need. We’re trying to get as much of it to be declarative as possible.

First of a series

Over the coming weeks, we’re going to publish a series of blog posts detailing our journey of adopting ARM and DSC to massively improve speed and quality of our GigaCloud installations, while giving us the flexibility to change and grow with our customer base. It’s been exciting to see the solution grow, and to see how quickly we can stand up a fully-redundant set of servers, with proper network protection and security patching, while nailing quality every time.

We’re still working on it, and we still have a lot to do, but the promise of ARM and DSC for GigaCloud already has proven itself. I hope you’ll follow along as we tell you all about what we’re doing, and how we’ve tackled the inevitable challenges we’re facing in making it work. We’re happy with what we’re seeing. It means better quality and fewer support issues for us and for our customers, and we can’t wait to share it with you.

By Scott Arbeit, Chief Cloud Architect