Opalis 6.3 is the new kid on the block. This version was
just released last Friday and it really rocks (http://blogs.technet.com/b/systemcenter/archive/2010/11/19/announcing-the-rtm-of-opalis-6-3.aspx)
You may wonder: "Why talking about System Center Opalis in
my SharePoint blog?"
The answer is pretty simple: MSFT announced the acquisition
of Opalis on Dec.10th 2009 (you may want to read this: http://blogs.technet.com/b/systemcenter/archive/2009/12/11/microsoft-acquires-opalis-software.aspx
). As soon as I learned that, I finally saw the vehicle we all miss to automate
Fortunately, thanks to the Grid team internship I did, I got
confirmation of a lot of the concepts and tools I started to build either on
Codeplex, or internally. The issue was to get them on a platform that could
ship out of Microsoft. My exec sponsors got me in touch with the Opalis Product
Group. Meeting this guy was really great, and we work together since.
(System Center) Opalis
was clearly the best fit to place the entire workflow and automation engine
needed to manage complex systems like SharePoint.
I think it really worth to give some insights on Opalis for
guys interested in SharePoint automation.
This product is built for Orchestration. This IT area (including
Run Book Automation) should be a post in itself, but that's not the topic for
So, Opalis orchestrate things in the IT systems. It is built
to fuel Private Clouds and orchestrate altogether complex systems (Microsoft and
others vendors one), in a pretty simple manner.
The main components of Opalis can be described using the
content structure of the Opalis Program Files folder:
Opalis Integration Server
This is the name of the product suite used to run the orchestration
Quick Integration Kit
This part enables you to create your own Integration Packs
In the Opalis Integration Server, you'll find
these 3 folders:
This is the component deployed on the Action Servers, so that they
can run the policies (workflows)
This is the software component used to create policies
This component is used to run the Management Server role on a
machine. This is from this server that most of the other components are
This role includes the necessary components to:
There are some command line tools
available, like these ones:
And GUI tool
to work with the product like:
The overall schema looks like this (my personal sketch - not
officially backed by Opalis PG):
6.3 ships with few great and interesting features for SharePoint 2010 use:
More information on Opalis here: http://www.microsoft.com/systemcenter/en/us/opalis.aspx
Now that Opalis is presented, let's put SharePoint in the
SharePoint deployment, there are various aspects to cover:
I'll cover the first aspect, as the others will be worked,
but no one really internally funded the work to make the story of SharePoint
and Opalis happen for real (so far, I think).
So, on my spare time, I setup an Opalis infrastructure, and
spent some time to create and launch a SharePoint farm deployment system.
The first main task has been to build what is called a
"PatchedOS": this is a VHD that includes everything you want standard in your
To be able to pilot this VHD, Remote PowerShell is enabled.
With this, I can pilot both the Hyper-V servers (thanks to SC VMM Integration
Pack) and the Guests themselves thanks to Remote PowerShell task from Opalis.
The task to use is this one:
And especially with this setting:
And here you go for a great journey.
More information on Remote PowerShell with Opalis is
available in this video: http://youtu.be/kaRxfMS-y9E?hd=1
Now, for SharePoint, I built a full system that generates
all the VHD you need to create a SharePoint Farm.
Here is the
And here is an example of workflow: this one sets up all the
SharePoint 2010 Prerequisites from a DSL (Definitive Software Library - ITIL
standards) to get them in the SharePointOS VHD:
And here is a typical example of one Task/Object in this
I think you got the idea.
This is absolutely great way to automate SharePoint and make
Of course, developing the full set of workflow for most of
SharePoint administrations tasks, will take some time. But frankly, a lot of
this can be mutualized: Opalis provides variables so that any workflow can
easily be packaged and distributed. Opalis Service Bus, publishing data from a
task to the next ones, and the branching/joining capabilities, really gives a
great flexibility to both create and distribute a full tool set for SharePoint.
Let's wish some of you will be interested, and that MSFT
will decide to invest in this area. It was part of the initial idea of my Grid
internship, but some changes happened when FY11 arrived. So now, the strategy
is different: onboard our cloud!
< Emmanuel />