{"id":3573,"date":"2013-04-20T19:48:03","date_gmt":"2013-04-20T17:48:03","guid":{"rendered":"http:\/\/contoso.se\/blog\/?p=3573"},"modified":"2013-04-25T09:59:55","modified_gmt":"2013-04-25T07:59:55","slug":"system-center-orchestrator-2012-community-check-part-vi","status":"publish","type":"post","link":"http:\/\/contoso.se\/blog\/?p=3573","title":{"rendered":"System Center Orchestrator 2012 Community Check – part VI"},"content":{"rendered":"

I have updated the “runbook validator” again. Added a couple of new checks and also added a table of contents in the beginning of the report. You can download the new version here, 20130419_SCO_CHECK<\/a>.<\/p>\n

Since I started to work with Opalis I have been surprised to see how fast people build their first runbook (policy back in Opalis). When showing Orchestrator for a group of engineers it doesn\u00e2\u20ac\u2122t take many minutes before they have a running workflow. A disadvantage when it is too easy, drag-drop-done,\u00c2\u00a0is that\u00c2\u00a0Orchestrator is some times\u00c2\u00a0not used as it should be used. In Orchestrator the challenge is that many engineers quickly drag and drop a couple of activities to\u00c2\u00a0the\u00c2\u00a0runbook, click Start and then lean backward. Most likely they have a working runbook, but are they really working? Is it built as it should be? Is it tested?\u00c2\u00a0I have written a couple of blog posts around best practices and\u00c2\u00a0the areas that the “runbook validator” checks<\/p>\n