Now that Microsoft is pushing the cloud as a new way of building and experiencing IT, SCORCH (I love this abbreviation btw!) is positioned as the bread-and-butter tool to simplify your datacenter-management along with the rest of the SC family.
While most SaaS environments aren’t hard to clamp in scorch’s grip, as they are usually contained within a single domain, what about IaaS or PaaS where there is much more isolation in place?
Before I go into further detail, I’ll summarize the topology of scorch:
– The management server is responsible for storing flows in the datastore and pushing tools or IP’s to action servers and clients (although they can be manually installed as well). It can also start flows on action servers when commanded to by either a client or the webconsole.
– The action server can be assigned workflows, which it then executes when commanded to by the management server. The action server only needs a connection to the datastore in order to function.
The caveat is that both the management- and action servers run under the usual service account. And unless you want to juggle around with credentials within your flows, you want to run the action-server under a credential that has localadmin-rights on the servers that exist in your flow-scope. Furthermore, the action-server uses its credentials to access the datastore.
These requirements don’t add up when the action-server resides on an untrusted domain. How can it reach it’s datastore, how can it be reached by the management-server if needed?
I asked myself (and google) the same question, and got these results:
This got me on my way to break through the barrier between my scorch-servers:
– In both the native and untrusted domain, create a service-account for the scorch action-server. These MUST be identical in both account name and password!
– Assign the remote account as localadmin on the action-server.
– On the datastore, assign the local service-account the DB_owner schema. Also, create a SQL login ‘eg Orchestrator with password ‘0rch3str@t3Th!s’ and assign it the DB_owner schema as well. This will be used later to register the remote action-server.
– Copy the following items from the scorch-management server to the future action-server:
OpalisIntegrationServer_ActionServer.msi from <Management Server installation location>\Components\Server\
OpalisIntegrationServer_FoundationObjects.msi from <Management Server installation location>\Components\Objects\
Any Integration Packs that need to be installed from <Management Server installation location>\Components\Objects\
– Install the components by using msiexec and the commandline:
Use the remote service account in the AS_USERNAME and AS_PASSWORD parameters.
Foundation Objects (base scorch flow-objects)
Any Integration Pack needed to execute flows
– Point the action-server to the datastore
Point it to the SQL-server on the native domain, and use the SQL-login created earlier to connect and register to the database.
– Verify the action-service is running
At this point when you open the deployment-manager on the management-server, the new action-server should be visible and usable!
You can now assign flows to the action-server and run them under the remote domain’s security-context, nice!
The magic (although lame) trick behind this method is that when the remote service-account accesses the datastore, which has an identical local account as owner, it forces a fallback from the regular Kerberos authentication to a failover protocol where credentials are matched by a hash based on account-name and password (like workgroup-authentication). As the accounts are identical, the authentication succeeds.
An alternative to this method is to program your flows with remote credentials and connect to the remote domain that way, but this requires a lot of flowdesign-overhead and isn’t as practical as having a ‘man behind enemy lines’.
Another cool part is that once the initial setup is complete (and the database-config tool supports parameters), you can design a workflow that will automate the deployment of remote action-servers. In essence, scorch can expand itself!
Although this method works, it is far from beautiful. I hope (and assume) that SCORCH 2012 will have more out-of-the box possibilities to support a workgroup/untrusted domain scenario.
But for now, let the orchestrating begin!