Hello readers. My group is already starting to “dogfood” the beta of System Center Orchestrator 2012. We came up against an issue that is definitely worth talking about in case anyone sees this issue in evaluation. This information could change in the near future so keep in mind that this is specific to the beta at this point. Let’s get on to the info!
Setting the Stage
To set the stage for the issue, I need to give you a little background on how the problem surfaced to begin with. This is an interesting one for sure. There are two things I really like about Opalis and Orchestrator.
If you notice in the example below, the links between the objects can have descriptive names such as “Success” or “Failure” or “Go” – essentially anything you want in there. The default is the word “Link” or whatever you have changed it to. You cannot have simply a “blank” by inputting a blank in the GUI and hitting enter. It will default back to the previous text that was there. Me being the type of person that wants to ensure my policies are visually appealing I leveraged a “hack” (CNTRL+SHIFT+6) to make the link text disappear and we could have essentially a single “underscore”. This was something I picked up in an training I was in. This may have proliferated out as it was a great way to clean up your policies so they were more visually appealing. See below for an example.
So what’s the issue?
So the issue comes into play when you want to import your exported Opalis 6.3 workflows into Orchestrator Beta 2012. The XML processing logic that is leveraged by Orchestrator in the new version is not allowing for CHAR(1) through CHAR(31) to be processed. Long story short, CNTRL+SHIFT+6 is in this list of non printable (non-allowable) characters.
How do you know if you have this issue?
So working with Charles Joy, we (mostly Charles) created this SQL query that will find all offending CHARs that Orchestrator has an issue with and display them in the results to take action on.
The above query yields something like what is displayed below. It will show you the offending CHAR value (in this case it is the CNTRL+SHIFT+6) along with the Policy Name that you can find the problem child.
So how do I update this you ask?
Manually. Find all occurrences of the non printable CHARs that are unsupported with the query above, chase them down from there to update your Opalis workflows before you go and export them to re-import them into Orchestrator.
Don’t like recommendation 1 above? Well, there is another couple of queries that Charles Joy and I worked out for updating our MPSD Opalis lab environment. Two options are presented below because we were trying to take into consideration scenarios where you may have the special character at the beginning of a string or in a case where it is the only thing on a line.
Note: Run this against a backup DB before running in production. This is a “use at your own risk” type thing. This isn’t reversable so make sure you are testing, retesting, and validating your tests.
That’s it. The SQL queries are provided in a download for your review and testing. And I mean it…..test!
Happy Automating! Enjoy Orchestrator!