This project is based on an older codebase, I will move it over to reference the orchestrator.administration.dll project (same project that is used to sanitizing using the parse orchestrator export tool). I will also update that project to handle SCOM 2007 and 2012 configuration schemas as you have described above.

The inconsistences you are pointing out in how configurations are referenced has to do with a difference between ‘native’ and ‘oit’ developed integration packs. Native IPs are kind of the wild west of integration packs, the author gets their own table(s) inside of the database and can pretty much do / configure their IP however they want. OIT (the publically available development toolkit) makes you implement a standardized interface when creating IPs. This causes all of their exports to have a consistent schema. Internally we don’t use any Microsoft Developed integration packs (we develop our own and release them out to scorch.codeplex.com). This means that we have been buffered from these problems since the Opalis days .

You probably know most of the following already from your “Parse Orchestrator Export” tool, but just in case, here’s what I have found so far.
These issues are probably related to the multiple (if not to say “inconsistent”, but I don’t know enough about the inner workings of Orchestrator to justify that) ways configurations can be referenced in the export file.
For most IPs, it just seems to be a node “Configuration” in the “Object” node.
Not so for …
- SCCM 2007 IP, which refers to the activities’ configuration with a “ConnectionName” node.
- SCOM 2007R2 IP, which refers to the activities’ configuration with a “Connection” node.

And while most IPs do store their configurations’ settings inside a “Configurations” node for each entry, these two do not (“List” for SCOM, “ServerList” for SCCM).

As if that wasn’t enough, the SCOM Configuration doesn’t even have a configurable “Name” property, the “Connection” name is generated dynamically by using some of the configuration’s configurable properties (domain name, user name, SCOM server name), concatenating them to “[DOMAIN]:[SERVER]:[ACCOUNT]“. In other words: for SCOM, there won’t be a proper “[Name]Some SCOM Configuration Name[/Name]” node in GlobalConfigurations, but the configuration object based on its GUID would have to examined whether the properties of one of its entries will form a connection name referenced in an exported Activity object (which leaves the problem on how to determine the SCOM configuration(s) without hardcoding GUIDs in the program and limiting it to certain IP releases…).

Regards,
Manuel

Just noticed that in my earlier post, some information for “Alternate Runbook Users:” I put between “” was swallowed.
For the sake of completeness, that should have been
Alternate Runbook Users:
- When the alternate user account is picked from Global Variables or from Published Data, the “raw” names (“\`d.T.~Ed/{[Activity GUID]}.[PD Name]\`d.T.~Ed/”, “\`d.T.~Vb/{[Variable GUID]}\`d.T.~Vb/”) are displayed as domain/user names; ideally, variable account names would be resolved to “[Activity Name].[PD Name]” or “[Global Variable Name]” in the treeview, and the “Objects” viewlist would display the respective Names, Types (“Published Data”, “Global Variable”) and GUIDs used in the account settings.

Some feedback to the changes:
GUI:
- The vertical scroll bar now remains in place when resizing the window.

Global Configurations:
- Multiple configurations for the same IP are now listed.
- Configurations for SCCM, SCOM, “Standard Logging” are now picked up; the former two as “NativeConfig:{[GUID]}” (can’t be resolved in the export, I know), the latter with its name.

Regards,
Manuel

Thanks for the feedback I’ll look into the suggestions you brought up

-Ryan

Alternate Runbook Users:
- If the runbook user account is picked from Global Variables or from Published Data, the “raw” names (“\`d.T.~Ed/{}.\`d.T.~Ed/”, “\`d.T.~Vb/{}\`d.T.~Vb/”) are displayed as domain/user names; ideally, variable account names would be resolved to “.” or “” in the treeview, and the “Objects” viewlist would display the respective Names, Types (“Published Data”, “Global Variable”) and GUIDs used in the account settings.

Global Configurations:
- If more than one configuration is present for an IP, “Global Configurations” seems to pick up only the first one listed in the export file.
- It doesn’t pick up Configurations for some of the more common integration packs, for example “System Center Configuration Manager 2007″, “System Center Operations Manager 2007 R2″ (and at least one of the more uncommon ones, “Standard Logging” from http://orchestrator.codeplex.com/releases/view/76097)

Regards,
Manuel

Regards
Michael