Archive for the 'Orchestrator' Category

Error after upgrading Orchestrator to 2012 R2

After upgrading from System Center Orchestrator 2012 sp1 to 2012 R2, my Runbooks weren’t running via my scheduled tasks.  After some digging, I figured out that I couldn’t open the Orchestration Console, because I kept getting this error:

Error executing the current operation.
[HttpWebRequest_WebException_RemoteServer]
Arguments: NotFound
Debugging resource strings are unavailable. Often the key and arguments provide sufficient information to diagnose the problem. See http://go.microsoft.com/fwlink/?linkid=106663&Version=5.1.20913.0&File=System.Windows.dll&Key=HttpWebRequest_WebException_RemoteServer

I did some research, but couldn’t figure it out, and there was a particular Runbook that I needed to have run every night.  So I opened a ticket with Microsoft.  In order to save you the trouble, if you come across this issue, here is the solution:

1. Enable detailed logging for the connection attempt.

Create a folder to store the log file: C:\Logs in this sample:

    initializeData="C:\logs\SRV_Traces.svclog" />

Edit the Web.Config file located in the following default location:

C:\Program Files (x86)\Microsoft System Center 2012 R2\Orchestrator\Web Service\Orchestrator2012

======================

Part1 add the following just below section <configuration>

<system.diagnostics>

    <sources>

      <source name="System.ServiceModel"

              switchValue="Information, ActivityTracing"

              propagateActivity="true" >

        <listeners>

          <add name="xml"/>

        </listeners>

      </source>

      <source name="System.ServiceModel.MessageLogging">

        <listeners>

          <add name="xml"/>

        </listeners>

      </source>

    </sources>

    <sharedListeners>

      <add name="xml"

           type="System.Diagnostics.XmlWriterTraceListener"

                 initializeData="C:\logs\SRV_Traces.svclog" />

    </sharedListeners>

</system.diagnostics>

==============

Part2 added into the  section: <system.serviceModel>

<diagnostics wmiProviderEnabled="true">

      <messageLogging

           logEntireMessage="true"

           logMalformedMessages="true"

           logMessagesAtServiceLevel="true"

           logMessagesAtTransportLevel="true"

           maxMessagesToLog="3000"

       />

</diagnostics>

2. Perform an IISRestart and test connecting to the Orchestration console to generate the error.

3. Stop the IIS Site and view the resulting log file.

4. Opening the log file using: SvcTraceViewer.exe make it much easier to parse.

You can get it either by installing (a non-express version of) Visual Studio, or by installing the (free) Windows SDKs

(http://www.microsoft.com/downloads/details.aspx?FamilyID=E6E1C3DF-A74F-4207-8586-711EBE331CDC&displaylang=en)

5. Drilling into the XML data for the "Handling an Exception" entry and locating the inner exception we found the following:

System.Data.SqlClient.SqlException: The EXECUTE permission was denied on the object ‘GetSecurityToken’, database ‘<SCO DB Name>’, schema ‘Microsoft.SystemCenter.Orchestrator’.

It appears that in uninstalling/reinstalling the Web Console the needed permissions were not updated in SQL.

6. To address this issue we ran a SQL script that was contained in the following MSI

%localappdata%\Microsoft System Center 2012\Orchestrator\Microsoft.SystemCenter.Orchestrator.ManagementServer.msi"

From the *.SQL located the file:  Microsoft.SystemCenter.Orchestrator.Roles.SQL

Using the text from this file, we created a new query to run  against the Orchestrator database to reapply the permission grant operations.

The key was step 6.  The security evidently didn’t get setup correctly on the update, and needed to be fixed manually.

Using SCOJobRunner

We have started using System Center Orchestrator (2012 SP1) to do some automation.  Most of what we have done so far could be done outside of Orchestrator pretty easily.  Having it in Orchestrator makes it easier to keep track of all the automated tasks that we have.  ( A central repository in theory.)

I have had a few different issues so far with the way that Orchestrator works.  It seems there is a common issue of Runbooks not showing up in the web console.  This isn’t hard to correct is seems, but it is annoying that they don’t automatically show up.

The way to get them to show up seems to be to clear the AuthorizationCache:

Hi, by default the orchestrator console refresh every 10 minutes. You could try update your AuthorizationCache, that is done by default every 10 minutes. If you run

TRUNCATE TABLE [Microsoft.SystemCenter.Orchestrator.Internal].AuthorizationCache in the Orchestrator database, do they show up direct then? Make sure you have a DB backup Before you do anything in the database.

http://social.technet.microsoft.com/Forums/sv/scogeneral/thread/3a4f49f1-b282-465c-84aa-e84335c4a7f9

Once they show up in the web console, you can use SCOJobRunner to call the Runbook.  That utility can be found here: http://blogs.technet.com/b/orchestrator/archive/2012/05/15/cool-tool-new-command-line-utility-to-start-a-runbook.aspx

Once you have that, you can use Task Scheduler to call the Runbook with SCOJobRunner.  The one thing that is kind of un-obvious is finding the ID.  There are a couple of ways, but here is a simple one:

An easy trick to getting the runbook ID is to go to the Orchestrator web console and click on the runbook itself in the left hand pane.  Within the URL you will find the runbook ID.

Example: http://server:82/#/RunbooksPage$FolderId=cdafbfdc-363f-49c4-81a0-62a18236a5ce&RunbookId=e46304a1-f900-4665-b0bc-ea0ad6c9f86e&RunbookInstanceId=&TabId=1&Filter

Vaughn

http://social.technet.microsoft.com/Forums/ko/scogeneral/thread/24c13d8c-b6d6-45c5-87c3-a68801a9005b