O R G A N I C / F E R T I L I Z E R: 01.11

Jan 7, 2011

powershell: naming functions and cmdlets

creating stuff in powershell and are curious about how to name it?  you already know the verb-noun format, but what are the right verbs to use?

use the get-verb cmdlet!

Verb                            Group
---- -----
Add Common
Clear Common
Close Common
Copy Common
Enter Common
Exit Common
Find Common
Format Common
Get Common
Hide Common
Join Common
Lock Common
Move Common
New Common
Open Common
Pop Common
Push Common
Redo Common
Remove Common
Rename Common
Reset Common
Search Common
Select Common
Set Common
Show Common
Skip Common
Split Common
Step Common
Switch Common
Undo Common
Unlock Common
Watch Common
Backup Data
Checkpoint Data
Compare Data
Compress Data
Convert Data
ConvertFrom Data
ConvertTo Data
Dismount Data
Edit Data
Expand Data
Export Data
Group Data
Import Data
Initialize Data
Limit Data
Merge Data
Mount Data
Out Data
Publish Data
Restore Data
Save Data
Sync Data
Unpublish Data
Update Data
Approve Lifecycle
Assert Lifecycle
Complete Lifecycle
Confirm Lifecycle
Deny Lifecycle
Disable Lifecycle
Enable Lifecycle
Install Lifecycle
Invoke Lifecycle
Register Lifecycle
Request Lifecycle
Restart Lifecycle
Resume Lifecycle
Start Lifecycle
Stop Lifecycle
Submit Lifecycle
Suspend Lifecycle
Uninstall Lifecycle
Unregister Lifecycle
Wait Lifecycle
Debug Diagnostic
Measure Diagnostic
Ping Diagnostic
Repair Diagnostic
Resolve Diagnostic
Test Diagnostic
Trace Diagnostic
Connect Communications
Disconnect Communications
Read Communications
Receive Communications
Send Communications
Write Communications
Block Security
Grant Security
Protect Security
Revoke Security
Unblock Security
Unprotect Security
Use Other

Jan 5, 2011

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).