Category Archives: SCSM 2012

System Center Service Manager 2012 SP1

Monitoring an SCSM Connector – Better than guessing!

First post in quite a while, but really I’ve been amassing tons of content to post. Hopefully this gets busier in the near future 🙂

I’ve been doing a *lot* of work with PowerShell automation and Service Manager. So much I daresay it’s become a second language. It’s even crept into my dreams! Seriously. I woke up the other morning with an idea for a new script and I spent the morning hours from 2AM until 9AM writing it.

As part of a user-onboarding script I’ve been working on lately, there was the need to ensure that the user object was synched back into SCSM before proceeding anymore with the onboarding. You would *think* it would be easy to monitor for such things, but alas! The SMLets deities were not so kind.

So, without status information, I was stuck. I was able to sleep the script for 10 minutes and wait for the connector to finish, but as the customer environment grows, that setting might no longer work. Not to mention at the moment, it only takes about 5 minutes for the connector to run, so we’re wasting time!

Then I had the genius idea of monitoring event logs for the final status message in a connector workflow and just waiting for that! As it turns out, this method isn’t *totally* reliable and Get-WinEvent was being a pain, so I never actually got this to work how I had hoped. Not to mention, this a bit of a roundabout way to monitor for things – I don’t love watching event logs, and usually I consider that a last ditch effort.

Enter the SCSM SDK! Now, I’ve spent *all* of my automation life using SMLets and the Service Manager Commandlets, so the SDK was foreign territory for me. Even worse, any examples I could find were SDK + C#, not SDK + Powershell. I tried variations of code on and off for about 3 days, and kept getting lost. By day 2, my hair was thinning and wrinkles were forming on my forehead. I thought that I had been bested.

Enter my coworkers! Cireson happens to have some amazing people on board, several of whom know the SCSM SDK intimately. Allen Anderson, a friend of mine and coworker on the Consulting team, has been doing some work with the SDK and PowerShell, and offered to help me out. Without him, this script would have not been possible – thanks Allen! This is the same guy responsible for a few of our apps, as well as some amazing custom solutions for customers. He’s a consultant and a developer? It’s like the best of both worlds.

Anyway, Allen gave me a bunch of help, and with some of his code, and some of my code, I came up with this script. It watches a connector, waits for it to sync, and then tests for an object at the end of the loop to make sure it exists in SCSM. In my case, I’m waiting for a user to sync to SCSM via AD, so you’ll see me test for a user object.

The code is ugly, and there’s lots of room for improvement, but it works! Hopefully it helps someone else who is onboarding users with SCSM 🙂

Note: you’ll see some slightly weird spacing where I commented out a separate powershell invoke. See the update below.

Enjoy!

PS. Here’s a link to the second write-up of this for my company blog. Just a little different flair 😉

Update: Here’s the code, wrapped in a powershell, shell. If you’re dropping this into Orchestrator, you can use this as a literal ‘drop in’ inside of a .Net activity 🙂

 

Max script block size when passing to powershell.exe or invoke-command

This. This may be the most important piece of information I ever contribute to anyone automating Service Manager (SCSM).

If you’ve ever worked with Orchestrator, and specifically Orchestrator and SMLets, you know what a pain in the butt it is. No, seriously. Orchestrator (Also known as SCORCH or ORCH) is great in a lot of ways but miserable in others. For me, right now, it has a big flaw – working with PowerShell.

If you use the built-in “.Net Activity” to run a PowerShell script, it only runs in PowerShell version 2. No problem you say! Several people have written tutorials on how to drop from PowerShell 2 into PowerShell 3. Those examples are numerous, and are an excellent resource (See here, here, here, here, and many others).

There’s even a separate Orchestrator Integration Pack that allows you to run PS scripts easier in SCORCH. Cool beans.

Here’s where it gets ugly. Let’s say, I’m developing a script in the ISE because it’s awesome. That development is happening on a box that has PowerShell 3. PowerShell 3 has several cool functions in it that I happen to rely on (I know in many cases there are workarounds using PS2, but that’s not always the case!) and so when I paste the entire script into SCORCH and try to run it (like all those examples above tell us to do), I get errors galore.

It’s not that I’m doing anything different from the links above. Nope, not a thing. I’m just passing the entire script to a powershell.exe scriptblock (Or script block, I’ve seen it spelled both ways) or to invoke-command. That will, in theory, drop the entire script into PowerShell 3 land and the script can then proceed on its merry way.

Specifically, I get lovely errors like:

“System.Management.Automation.ApplicationFailedException: Program ‘powershell.exe’ failed to execute: The filename or extension is too long”

PSError

Such errors have been rectified by splitting up script blocks into smaller parts that can be passed on, and ensuring that only the absolute necessary items are passed to PowerShell or invoke-command. This then gets more complex, as you’re making multiple calls and passing multiple variables in and out. This takes more time, and good luck passing any objects in or out; they get deserialzed in that process and lose all access to any methods that the original object had. So now, we’re talking about passing strings between sessions, calling for objects inside the new PS3 session only to recreate the object we had in our existing PS2 session, just so we can run a method on it. This adds complexity, time, and lots of other not-fun things to our automation.

It turns out that both powershell.exe, and invoke-command have a limit on the size of the scriptblock. It’s been something that my co-workers and some of our implementation partners have run up against again, and again.

The size limit we kept hitting was one that we had only guessed at, one that was unknown, one that we tackled blindly… UNTIL TODAY.

There is a 12190 byte MAX limit of any script block passed to powershell.exe or invoke-command. 

The easiest way to see how big your block is, is to just copy it into Notepad++ and look at the ‘length’ value at the bottom of the editor window. That tells you the byte size of the resulting file (and therefore text), and as long as your script is less than 12190 bytes, it will be passed along with no errors to whatever you like

Go over that limit and you’ll be cast into a world of uncertainty and doubt where your ability to code succinctly is called into question!

And now you know 🙂

Authorizing Computers for Software Applications – An Example

So life has been busy lately! The consulting life is quite different than being a Systems Admin, quite different…

Anyway, it just so happens that this past Friday, an e-mail went out with a request for something whipped up in Orchestrator. Since I was totally exhausted with things that I *had* to do, I decided to take a stab at it 🙂

A customer was asking for a workflow that would take input from SCSM (System Center Service Manager) via a Request Offering and allow the end user to select an application, as well as a computer object, and then add that computer object to ‘Authorized Computers.’ It’s worth noting that ‘Authorized Computers’ is a relationship that is part of Cireson Asset Management and is used for ‘authorizing’ CI’s to use a software license.

I had the initial idea roughed out, and a bit of prodding from my co-workers got me to the final solution, which I present to you below!

The Orchestrator Part:

Runbook1

Here’s the runbook I came up with – it’s not too difficult, but let’s walk through it.

We’re taking the ‘ID’ property in from the RBA from SCSM. This property, while called ‘ID’ in SCSM, actually ends up being the GUID of the RB object in SCSM. From there, we’re getting the relationship between that RB and the Service Request, and then getting the Service Request object itself.

From there, we have to get two related items – one that’s a ‘Windows Computer,’ and one that’s a ‘Software Asset.’

For the ‘Windows Computer’ we’re going to do a ‘Get Relationship’, look for a ‘Windows Computer’ related object and make sure any objects that we pass on are related by the ‘Is related to configuration item.’

Runbook2 Runbook3

Now we’ll do the same thing, but for a ‘Software Asset.’

Runbook4
Runbook5

 

Then, lastly, once we’ve gotten all we need, then we’ll create the relationship to the Cireson Software Asset object.

Runbook6

Awesome! We’re halfway there 🙂 Now to build out the templates and requests on the Service Manager side.

To start, you’ll need to make sure you’ve got an Orchestrator connector set up, and your runbooks are syncing properly. I’m going to assume you know how to do that 😉

Now, we’ll need to create two templates, a runbook template, and a service request template.

The runbook template is easy enough – just create it, fill in the basic fields, make sure you check the ‘Is Ready for Automation’ box, and link it to the Runbook in Orchestrator that you’re targeting. When we’re doing property mapping, you’re going to want to map the ID property to the one input field, as shown below.

RBA-1

Onto the Service Request template! This too is pretty basic – create it and fill in the basic properties as you see fit, then head over to the activities tab and link your RB template, as shown below.

SR-1

Last but not least, we’ll create the Request Offering so we can hit it from the portal. Again, make a new RO, and then when we’re asking for user input, let’s put something like the following:

RO-1

And those queries…

Query1 Query1-1 query2

Query2-1

You’ll notice that we only allow the selection of one software asset, and multiple computer objects. This just keeps things a little bit cleaner, and prevents people from going nuts with the selection fields 🙂 I’m also not doing any filtering of the objects. In my lab environment, it’s not too busy, but feel free to scope those queries beyond the objects themselves if you’re returning more values than you need.

Once all that’s in place, publish your Request Offering under a Service Offering of your choosing, navigate to it via the portal (Preferably Cireson’s new beautiful Self Service Portal, but the Out Of Box SCSM Portal will work too!) and let your IT organization authorize software via a nice, easy to use interface!

portal1

 

Enjoy!

Installing Orchestrator integration packs without Deployment Manager

Another day in the life of a systems engineer with limited access! While I own the SCCM and SCSM servers that I’ve been blogging about, the Orchestrator server is owned by a different division of our Technology Services group. Now, it’s not usually a problem, and honestly he does a great job with it, but today I ran into an issue.

The Orchestrator admin was taking a day off, he has no backup, and I needed to add the Runbook Designer to a new workstation (my VDI session that I mentioned in an earlier post). Cool, no problem, just install the Designer with the script I set up before. Easy. Right.

I opened the console today to actually use it, and, oh no! All my runbooks had funny looking question marks where there should have been pretty green cubes!

questionmark

I looked around and noticed that I didn’t have the SCSM integration pack installed. No problem, I’ve just got to find them and install the ones I need! Oh look, they’re right here!

http://www.microsoft.com/en-us/download/details.aspx?id=28725

Except – the install process involves making sure it’s deployed via the Orchestrator Runbook Server… that only the admin has access to.

Now is when I had to get creative. I had the integration packs extracted so I had a bunch of .oip files, but attempting to use the console to ‘import’ them didn’t work. I tried dragging them onto the console (just in case) – nope. Tried using the ‘import’ function (which is usually used for runbooks) – nope. Left with no other choice, I busted out my trusty 7Zip utility and tried to extract the .oic file and see what was inside.

Lo and behold! Extracting a .oic file gives you a few configuration-type files (a .ini, .cap, and .eula) as well as a .msi! Woah.

extracted

Sure enough, running that .msi as an admin, on my local machine with the Runbook Designer installed on it, installed the integration packs I needed!

fixed

Awesome! I can now do what I needed to do.

Now – a few things to keep in mind:

-This is not approved by Microsoft in any way. Do this at your own risk! (That said, I don’t think it’s too risky.)

-This won’t do anything unless the same integration packs have been deployed to your Runbook Server as well! Since I’m just adding a second Runbook Designer on a new machine, pointing to the same server, we’re fine.

-You will feel way cooler that you were able to do this and not pester your Orchestrator admin!

 

Enjoy!