Software development projects usually follow some process to ensure they are not failing or disappointing the customer and his/her wishes. In Infrastructure i experienced something different.
Clash of Cultures
Usually people working in Infrastructure Projects, as far as i saw it, come out of some line-organisation, e.g. a company wants to upgrade some System Center Product from 2007 to 2012 –> the resources used will be the people who know the old product and that are the people responsible for software deployment or OS packaging. Those people know how to quick-fix the system and are very fast in case of emergencies (e.g. process has a bug got to be fixed asap). For being able to do this stuff it’s important to have small release processes, any kind of waterfall or scrum would be shooting birds with cannons.
On the other hand big projects like migrations should look at software development and should use a structured process to release the product in time and keep the project in a defined scope even though this might seem unnatural to the people involved in the project.
What can go wrong?
On thing i found which is mostly causing pain are scripts. Let it be VB-Scripts or PowerShell scripts, the problem is that those are not used for extended testing. I once even noticed in a project that scripts are used for everything simply because there was no release process for scripts. In this department a compiled code product would have to go through at least 3 instances of testing environments before it could hit the production environment. Scripts could just pass as minor fix…
So this resulted in a bunch of scripts of which each had at least 3000 lines of code and all of them did cover mission critical parts of the system.
How to prevent Damage?
Even though i wish i could say “No more Scripts!” that’s completely unrealistic.They are useful and they are great for quick fixes. Especially with Tools like System Center Orchestrator scripts are essential to a platform, but i think using other tools around can be helpful to increase the quality.
The one tool i always encourage people to use is Team Foundation Server. First of all it brings Source Control not just for C#-Files but for whatever you put in there and you can use it right out of the explorer. So common scripting strategies like backup by outlook or the famous “I think i had a script for this once, let me search it” are obsolete as there could be one global storage for all scripts.
The second advantage TFS brings is Bug-Tracking. You’ll be able to see what issues are with the script and you’ll be able to have one version of the script covering all fixes.
I’m not saying that TFS will make scripts perfect but its a good first step. It takes about 15 minutes to install TFS 2010 and another 5 on the client to use it correctly. You could even use PowerShell right out of Visual Studio using extensions like PowerGUI-Integration (I think every PowerShell Scripter uses PowerGUI since it’s free to use, if you’re not yet using it –> you should it got IntelliSense). And once you started using Source Control and Bug tracking from TFS you might try out using Task and Project Management out of it too.
I recently build my Test-Environment to get transform my Opalis Policies to the new Product System Center Orchestrator and as I’m a huge fan of testing new features I tried to get my, now called, Runbooks started from an external Application. Currently there aren’t many examples out on the Web how to approach the new Web Service deployed with Orchestrator but I was able to find some nice examples:
http://www.damianflynn.com/2011/08/15/orchestrator-c-and-runbooks/
http://www.damianflynn.com/2011/08/18/orchestrator-runbook-parameters-in-c/
Damian did a great job explaining the Web Service in the first posts but it looked kind of strange how he created the Parameters to trigger a Policy. (Especially since it doesn’t seem to work in the RC anymore). Still great Job being the first out giving Information on the Web Service!
So the following post shows how I’d trigger Runbooks from a C# Program
Building the Reference
First of all, the Web Service Orchestrator provides is a normal OData Web Service and you shouldn’t need anything but Visual Studio to be able to do what I’m showing now. The good thing about Web Services is that they are defined by a Contract which makes it easy for Tools like Visual Studio to auto-generate the communications layer in your Application. So first of all we’ll tell Visual Studio where to find the Web Service and that’s just a right click on References and choosing Add Service Reference. You should get a Window like this:
You have to enter the Path to the Web Service in the Address Line and Click Go so the contract will be received. Orchestrator, by default, installs the Web Service on Port 81 and you’ll find a Orchestrator.svc there. If you can’t access the File you’re missing some rights.
Update: You'll find the Webservice at http://servername:port/Orchestrator2012/Orchestartor.svc in the RC (Thanks Damian)
In this Example I named the Reference OrchestratorService this will be important later on.
Connecting to the Web Service
To be able to find our Runbooks and start them we need to setup the communication with the service. This step won’t send any information but it will allow us to use the objects provided by the service and it’s basically a one liner:
OrchestratorService.OrchestratorContext o = new OrchestratorContext();
Yep that’s it. (Laziness Awareness: you shouldn’t name a object “o”, but this is just an example etc. etc.). You can extend the code to an astonishing number of two lines if you like to use different Credentials:
o.Credentials = new NetworkCredential("OrchestratorUser","Orch3stratorR0x");
And that’s enough to get some Information flowing.
Finding the Runbook
As we want to find a special Runbook to start we have to use the service to identify it. To do that I rely on LINQ and just Query the Data like that:
var first = (from runbook in o.Runbooks
where runbook.Path == "Stage 3/Test/Testbook"
select runbook).First();
This will give us a single Runbook which has the specified path. (Usually in my Projects I always use path-based triggering and identification of Runbooks as Runbook-Ids can change on export/import and it’s a massive annoying job to fix the connections back. So in my opinion: Path > Name (Could be duplicates) > IDs)
Sadly the Runbook Object doesn’t contain any Information about the Parameters the Runbook uses (even though there would be a Property for Parameters ready…) so we also have to get the Parameter Information:
var parameters = from para in o.RunbookParameters
where para.RunbookId == first.Id
select para;
Filling a Parameter
Now this is the ugly part. I spend some time cursing the people who thought this would be the right way as I was figuring out how to fill the parameters. The thing is: You don’t give the parameters by entering them into the Runbook Object you give to the Job, and you also don’t just give them to the Job-Object. Your parameters have to be in a special xml-format to be recognized right.
<Data>
<Parameter>
<ID>{GUID}</ID>
<Value>Hello World</Value>
</Parameter>
</Data>
You can have as many parameter elements as your Runbook needs though you always have to give the ID. So the first thing I did was to get the id from the parameter we received in the last query:
var id = "{"+ lparameters[0].Id.ToString() +"}";
As you can see there is some additional ugly behavior as the parameter-id is expected with {} but provided without them… Anyhow as we got the id now we can build the xml. Here is some example, I’m sure you guys are able to extend it if you need to:
XDocument xml = new XDocument();
xml.Add(new XElement("Data"));
XElement para1 = new XElement("Parameter");
para1.Add(new XElement("ID") { Value = id });
para1.Add(new XElement("Value") { Value = "Hello World" });
xml.Root.Add(para1);
Starting the Job
Last but not least we’ll finally trigger the Runbook by creating a Job, that contains the parameters and the runbook information.
Job j = new Job();
j.Runbook = first;
j.RunbookId = first.Id;
j.Parameters = xml.ToString();
o.AddToJobs(j);
o.SaveChanges();
I think it’s enough to give the Job the RunbookId but to be sure I also inserted the Runbook itself.
So using this approach you don’t need any HttpRequests or other “deep” stuff. The only strange thing that stays is the parameter definition but I guess we have to life with that 
During the last few years i tried to write actively on several blogs, but sadly i faced some problems:
As i was writing on blogs.msdn.com i felt i had to stick to the pure technical stuff as I'm no Raymond Chen who seems to be as famous enough to be allowed to tell stories between his technical posts. Also i don’t want to feel like an official voice of Microsoft as I'm neither able nor allowed to be that. These feeling, even though they might be wrong resulted in a quickly deserted blog.
So this time the Blog is back on my personal space and it will be my own personal Blog in which I'll write whatever comes to my mind.
For those who don’t know me a quick introduction:
My name is Bernd Mayer and I'm a Consultant for Microsoft Germany. My daily work mainly focuses around System Center and its customization for various customers. So my weapons of choice are mostly PowerShell and .NET. Personally I'm much more interested in Software Development than Infrastructure but i guess someone has to do the crossover. So this Blog will show some real world stuff as well as some stuff I encounter during my own hobby programming.