opalis: guidance on troubleshooting failed workflows

as you move into deeper integration stories with opalis, it’s probable that you’re going to run into situations where the expected outcome isn’t quite as you dreamed.

now why is this?  it’s usually because as you write the process, it isn’t completely determined what you’ll need.  this manifests itself often for me (anyway) as security related problems.  the most common reason this occurs is that you are designing as your own account and running your workflows as the opalis action service account.

so, if you would, allow me to offer a little guidance on this.

• repeat to yourself: i am not the opalis action account.  this has a profound effect in separating you from your delusion that the universe does not want you to succeed today.  the point really is to remember that that testing console runs as the user launching the opalis client.  here's a demonstration by pete.
• review your audit history.  it's object specific but sometimes you can glean problems occurring by viewing the audit history such as access denied errors when using the AD object.

• check the system logs.  while the logs can be quite noisy, it can provide a lot of value if the object problems are being logged.  how do you know if they are?  check!  this post has the log locations.  the policymodule*.log files are the ones to read.
• minimize confusion by documentation.  document the permissions required for the action server with passionate fervor!  (duh)  i can't even begin to explain how many times i was changing things in the wrong place.
• measure once, cut twice or measure twice, cut once – just measure.  go back and assess the various places where a credential conflict might cause problems.  generally, when connections are defined, you define the credentials as well to connect to those environments.  while these may execute as the defined account (connections to opsmgr for example), other objects that were not defined will execute as you (in the testing console) and as the opalis action service account (in running policies).
• put on your running shoes.  if you’re working with nested workflows, chase your log histories!  review the log histories of all your workflows.  while not as valuable as being able to run them in the testing console, it still pulls back some data that can be useful.
• execute each workflow individually if required.  sometimes log history isn't enough.  it can be useful to separate the workflows and run them through the testing console.  remember your identity crisis.  you're running these tests as YOU, not the action server.
• append line object is your friend.  back when we scripted in that archaic language known as vbscript, there was this concept of echoing.  you chiseled commands like wscript.echo "i am so cool" into a rock wall and inside of your cmd shell, out it would come (and coincidentally, inside the cmd shell is also where you're cool).  this is akin to using echo statements to capture places that you are in your script.  write to log.  log often.  log is your copilot.
• be something you’re not.  try running the opalis client as the action account. this presents its own challenges though as you will be required to grant the action account access to your policies.
• violate all security principles.  where at all possible, just put the action account into the domain administrators and rid yourself of all the pesky permissions issues.  I AM JOKING!  do not ever do this.

for real world context, i wish to say that i ran into every one of these things.  and probably twice.  (except the last one.  thought about it.  a lot.  not dumb enough to do it though).