Hi,

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.10^th 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 efficiently SharePoint.

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.

System Center Opalis

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 now.

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 Program Files folder

Opalis Integration Server	This is the name of the product suite used to run the orchestration system
Quick Integration Kit	This part enables you to create your own Integration Packs

In the Opalis Integration Server, you'll find these 3 folders:

Opalis Integration Server folder content

Action Server

This is the component deployed on the Action Servers, so that they can run the policies (workflows)

Client

This is the software component used to create policies

Management Service

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 piloted.

This role includes the necessary components to:

Manage the orchestration instance

Create the Opalis Datastore in a DBMS

Deploy Integration Packs and policies on Action Servers

There are some command line tools available, like these ones:

Aspt.exe
Atlc.exe
ActionServerWatchdog.exe
Oedc.exe
OIS5StartPolicy.exe
Pic.exe

And GUI tool to work with the product like:

Opalis Integration Server Client
Deployment Manager
Operator Console (also allowing to trigger policies calling web services J)

The overall schema looks like this (my personal sketch - not officially backed by Opalis PG):

Opalis architecture

The version 6.3 ships with few great and interesting features for SharePoint 2010 use:

Runs on Windows Server 2008 R2 (enabling Remote PowerShell :-) :-) :-) )
System Center Integration Packs for
- SC Virtual Machine Manager
- SC Service Manager
+ other things that are not that relevant for SharePoint

More information on Opalis here: http://www.microsoft.com/systemcenter/en/us/opalis.aspx

SharePoint 2010 with Opalis 6.3

Now that Opalis is presented, let's put SharePoint in the loop!

To manage SharePoint deployment, there are various aspects to cover:

Physical deployment
Farm creation
Logical deployment
SharePoint Operations

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 infrastructure.

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:

Run .Net script

And especially with this setting:

Run PowerShell

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 list:

Workflow list

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:

One workflow

And here is a typical example of one Task/Object in this workflow:

Setup server role task

I think you got the idea.

This is absolutely great way to automate SharePoint and make it fly.

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!

Cheers,

< Emmanuel />