Opalis 6.3 to orchestrate SharePoint 2010

Hi,

Opalis 6.3 is the new kid on the block. This version was
just released last Friday and it really rocks (https://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: https://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: https://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: https://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 />