A brand new web console for Orchestrator 2019
Published Dec 16 2021 10:10 AM 19.7K Views
Microsoft

System Center Orchestrator is the datacenter workflow management solution that's commonly used to automate datacenter operations including creation, monitoring, and deployment of data center resources. We consistently hear feedback from customers on enhancing the user experience and support for modern browsers. Thanks to the Orchestrator community for the continued support and feedback.    

 

We are excited to announce the release of brand new web console for System Center Orchestrator 2019. The new web console works well on modern browsers without Silverlight dependency. As you are all aware, the old Orchestrator console was built on Silverlight and Silverlight has been completely discontinued. Read more about the Silverlight announcement here.

The new web console brings in additional capabilities that includes the following.

  • The older version of SCO web console runs only on IE. The new version works on modern browsers like Microsoft Edge, Firefox, or Google Chrome.
  • The new Web console does not use Silverlight.
  • The new OData v4 JSON based Web API simplifies all the endpoints, most notably the ones for Job management.
  • The console also works well along-side the old Web service and old Web console.

The new console for System Center Orchestrator 2019 can be downloaded from here. We would like to inform that the new console will also be part of our upcoming System Center 2022 release. If you are interested to know more about System Center 2022, read our recent blog here.

 

Update [17 August 2023]: An updated version of System Center 2019 Web console v10.19.350.0 is now available here. The new release features .NET Core 6 and introduces significant enhancements as compared to the previous version. You can upgrade to the latest build by following the steps mentioned here.

53 Comments
Copper Contributor

Unfortunately, I can't get this to run. The Orchestrator.WebApi always runs into an HTTP 500 Internal Server Error. The permissions should all fit, but I'm not sure about the Database Connection String. Is the example from the manual enough or do I need more information?

Copper Contributor

@TomRh Note the version is 0.1.0, definitely NOT production level code...  Spent 2 days reverse engineering the install docs till I got it mostly working, but yeah, looks nice, but definitely BETA.

 

So try this:

  1. (Likely your issue) Download and install the ASP.NET core 5.0 (not the latest 6.0 the doc sends you to) web hosting, found here.
  2. (Needed for rewrite rules in web.config below) Download and install URL-Rewrite
  3. Copy the WebConsole folder to c:\inetpub
    • If you want to use port 80/443, you can simply replace the contents of c:\inetpub\wwwroot
    • You can also put the folder anywhere else for that matter
  4. Copy the WebApi folder to c:\inetpub (or other location)
    • There are 2 folders: the tree should look like C:\inetpub\WebApi & C:\inetpub\webconsole
  5. Create an account that has (at least) read access to the database (although I used the Orch Service Account, so it had all the required permissions already)
  6. Run the PowerShell script 2x (1 for the WebConsole, 1 for the WebAPI)
    • Make sure you're using the account from previous step
    • For the WebAPI, I would recommend you use the default port 5001 just in case something else is screwy.  For the webconsole, you can use port 80.
    • Actually, I would recommend that instead of the script you follow the manual process to create the web applications.  
  7. In the WebConsole\assets\configuration.json file, replace the webUri with "http://<ServerFQDN>:5001" (change the port if you didn't use the 5001 port for the WebAPI)
  8. Open your firewall rules to allow inbound TCP to your WebConsole AND WebAPI from your possible clients PCs
  9. Replace the WebApi\web.config with the following file

 

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <httpProtocol>
        <customHeaders>
          <add name="Access-Control-Allow-Credentials" value="true" />
          <add name="Access-Control-Allow-Methods" value="GET, POST, PATCH, OPTIONS" />
          <add name="Access-Control-Allow-Headers" value="Content-Type" />
        </customHeaders>
      </httpProtocol>
	          <rewrite>            
            <outboundRules>
                <clear />                
                <rule name="AddCrossDomainHeader">
                    <match serverVariable="RESPONSE_Access_Control_Allow_Origin" pattern=".*" />
                    <conditions logicalGrouping="MatchAll" trackAllCaptures="true">
                        <add input="{HTTP_ORIGIN}" pattern="(http(s)?:\/\/.*)" />
                    </conditions>
                    <action type="Rewrite" value="{C:0}" />
                </rule>           
            </outboundRules>
        </rewrite>
      <handlers>
        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
      </handlers>
      <aspNetCore processPath="dotnet" arguments=".\Orchestrator.WebApi.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess">
        <environmentVariables>
          <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Production" />
                    <environmentVariable name="Database__Database" value="Orchestrator" />
                    <environmentVariable name="Database__Trusted_Connection" value="true" />
                    <environmentVariable name="Database__Address" value="***DBSERVERNAME***" />
        </environmentVariables>
      </aspNetCore>
    </system.webServer>
  </location>
</configuration>
<!--ProjectGuid: 2b28e03a-bff3-4fa9-98ee-fd2db7d151d6-->

 

  • For some added level of security, you may want to change the regex at line 18 with something to match all the possible clients (eg: PCs) that may access the webconsole (I have in mine but of course, that's confidential :smile:). 
  • Replace line 30 with your DB name
  • Replace line 32 with your actual DB Server name/alias.

 

 

...OK, I think that's sufficient for the time being.  For troubleshooting:

  • Use the Application Event Log for the WebAPI
  • Open the client's Browser Console (F12) to look at the WebConsole errors

HTH

 

 

@Molish How can you release something when there can only be 1 hardcoded client (IP/Hostname) that can actually use the Web Console, as per the design provided because of the Allow-Origin.  See Stack Overflow above for more info

Copper Contributor

@Molish got it up and running in our dev/test environment, with the tweaks from @PChip1976 (thanks!)

 

Is there a way to track development work on it, or raise queries/questions other than the bug report icon?

 

e.g.

- Folder structure not in alphabetic order like older version

- No runbook servers or events tabs?

- Summary stats not showing up ? (i.e. "Active Jobs shows 15" but nothing in the list underneath it on the page?

 

Keen to see this progress, and to help out.

Copper Contributor

Missed one - Cog icon top right has a blank popup - doesn't seem to do anything?

Copper Contributor

Thanks for the new console.
I have successfully installed the webservice and I can display the Runbooks, Folders and Servers.
But I have an error to display the instances and jobs because there are too many objects, yet I only have 30 days of history (17607 jobs).
Even if I force to recover only the first 5 jobs, it falls into error 500.

 

Invoke-RestMethod -Uri 'http: // localhost: 881 / api / Jobs? Top = 5' -UseDefaultCredentials
Invoke-RestMethod: The remote server returned an error: (500) Internal Server Error.

 

Thomas_Moinelet_BYCN_0-1642072217745.png

 

Category: Microsoft.AspNetCore.Server.IIS.Core.IISHttpServer

EventId: 2

SpanId: 7efe98416550b544

TraceId: 3bc584801971744ab99578033d428017

ParentId: 0000000000000000

RequestId: 80000019-0000-fe00-b63f-84710c7967bb

RequestPath: /api/Jobs

 

Connection ID "18302628887244308503", Request ID "80000019-0000-fe00-b63f-84710c7967bb": An unhandled exception was thrown by the application.

 

Exception:

System.InvalidOperationException: 'AsyncEnumerableReader' reached the configured maximum size of the buffer when enumerating a value of type 'Microsoft.EntityFrameworkCore.Internal.InternalDbSet`1[Orchestrator.Data.Models.Job]'. This limit is in place to prevent infinite streams of 'IAsyncEnumerable<>' from continuing indefinitely. If this is not a programming mistake, consider ways to reduce the collection size, or consider manually converting 'Microsoft.EntityFrameworkCore.Internal.InternalDbSet`1[Orchestrator.Data.Models.Job]' into a list rather than increasing the limit.

   at Microsoft.AspNetCore.Mvc.Infrastructure.AsyncEnumerableReader.ReadInternal[T](Object value)

   at Microsoft.AspNetCore.Mvc.Infrastructure.AsyncEnumerableReader.ReadInternal[T](Object value)

   at Microsoft.AspNetCore.Mvc.Infrastructure.ObjectResultExecutor.ExecuteAsyncEnumerable(ActionContext context, ObjectResult result, Object asyncEnumerable, Func`2 reader)

   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextResultFilterAsync>g__Awaited|29_0[TFilter,TFilterAsync](ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)

   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResultExecutedContextSealed context)

   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.ResultNext[TFilter,TFilterAsync](State& next, Scope& scope, Object& state, Boolean& isCompleted)

   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeResultFilters>g__Awaited|27_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)

   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|19_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)

   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Logged|17_1(ResourceInvoker invoker)

   at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)

   at Microsoft.AspNetCore.Authorization.Policy.AuthorizationMiddlewareResultHandler.HandleAsync(RequestDelegate next, HttpContext context, AuthorizationPolicy policy, PolicyAuthorizationResult authorizeResult)

   at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)

   at Orchestrator.WebApi.Middlewares.TokenMiddleware.Invoke(HttpContext context, OrchestratorContext dbContext) in C:\__w\1\s\src\Orchestrator.WebApi\Middlewares\TokenMiddleware.cs:line 66

   at Orchestrator.WebApi.Middlewares.HttpOptionsMiddleware.Invoke(HttpContext context) in C:\__w\1\s\src\Orchestrator.WebApi\Middlewares\HttpOptionsMiddleware.cs:line 34

   at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)

   at Microsoft.AspNetCore.OData.Query.ODataQueryRequestMiddleware.Invoke(HttpContext context)

   at Microsoft.AspNetCore.OData.Routing.ODataRouteDebugMiddleware.Invoke(HttpContext context)

   at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContextOfT`1.ProcessRequestAsync()

 

Copper Contributor

@Molish Any update/fixes to the console?

 

The download page shows an updated date of 2nd Feb, but there's no change to the contents of the available download...

Microsoft

@TomRh Please check the Event logs in Event Viewer (Windows Logs > Application [filter: IIS AspNetCore Module V2+.NET Runtime]) to investigate the 500 responses. The AppPool Identity might not have the right permissions for Orchestrator database.

Regarding the Connection String: the example shown should be enough. If you have to change the string please refer to the table on Connection String Syntax

Microsoft

Hi @Andy_Stewart , In the Feb 2nd update, we only updated the user guide to v.0.1.1. The update includes changes to link of ASP.NET Hosting bundle (v5.0). All the new changes are captured under the changelog section of the user guide. We will roll out updates and bug fixes to console in upcoming SC2022 release. 

Microsoft

@PChip1976 Thanks for condensing the (very lengthy) setup steps nicely!

The sample WebApi `web.config` makes use of `<customHeaders>`, which as you rightly point out, limits the use of just one domain name for the WebConsole. I'd like to add another method of enabling CORS without relying on `customHeaders` or wildcard rewrite rules to replace the Allow-Origin header:

 

Install the IIS CORS module and use this as a sample `web.config`:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <!-- Setting failUnlistedOrigin=true will serve 403 when the request origin does not match the ones listed here.
      Setting it to false will also fail such requests but silently -->
      <cors enabled="true" failUnlistedOrigins="true">
        <!-- origin is the address used to access the WebConsole (not WebApi!) using a browser -->
        <!-- Here we are allowing user to browse the WebConsole on http://localhost:5001 -->
        <add origin="http://localhost:5001" allowCredentials="true" maxAge="7200">
          <allowMethods>
            <add method="GET" />
            <add method="PUT" />
            <add method="POST" />
            <add method="PATCH" />
            <add method="DELETE" />
          </allowMethods>
          <allowHeaders allowAllRequestedHeaders="true" />
        </add>
        <!-- Here we are allowing user to browse the WebConsole on http://test-machine.test.domain:5001 -->
        <add origin="http://test-machine.test.domain:5001" allowCredentials="true" maxAge="7200">
          <allowMethods>
            <add method="GET" />
            <add method="PUT" />
            <add method="POST" />
            <add method="PATCH" />
            <add method="DELETE" />
          </allowMethods>
          <allowHeaders allowAllRequestedHeaders="true" />
        </add>
        <!-- Add any number of "allowed" origins -->
      </cors>
      <handlers>
        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
      </handlers>
      <aspNetCore processPath="dotnet" arguments=".\Orchestrator.WebApi.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess">
        <environmentVariables>
          <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Debug" />
          <environmentVariable name="Database__Database" value="Orchestrator" />
          <environmentVariable name="Database__Trusted_Connection" value="true" />
          <environmentVariable name="Database__Address" value="localhost" />
        </environmentVariables>
      </aspNetCore>
    </system.webServer>
  </location>
</configuration>
<!--ProjectGuid: 2b28e03a-bff3-4fa9-98ee-fd2db7d151d6-->

Hope this helps. We will update this CORS module option in the usage guide as well.

Copper Contributor

Thx a lot for finally moving away from Silverlight! We also managed to get the new console working on SCO 2019. It took a couple of days, though...

 

In order to get ready for SCO2022 as early as possible we need to know how to use the new Web API. We are Sys Admins rather than seasoned Developers and need some help with this.


We use an in-house built Visual Studio .Net Windows forms app to trigger Runbooks, We've been wondering if we can still use it with SCO2022 and or how much work it will be to rewrite the web service connection routines. It would be great if anyone could post a few examples on how to do this in Visual Studio via the new Web API.  We specifically need to be able to trigger a Runbook (Create Job), query the status of the new Job and/or its Instances. Any help is appreciated!

 

Here is an example how it is currently is done using VB. However, examples in C# would be fine too:

 

Dim scorchSVC = New Microsoft.SystemCenter.Orchestrator.WebService.OrchestratorContext(New Uri("http://<SCO server FQDN>:81/orchestrator2012/orchestrator.svc")) With {
.Credentials = System.Net.CredentialCache.DefaultCredentials
}

Dim strRunbook As String
strRunbook = "Create AD User Account"

'retrieve Runbook
Dim runbooks = (From rbData In scorchSVC.Runbooks
Where rbData.Name = strRunbook).ToList()

'retrieve Runbook parameters
Dim runbookpars = (From rbData In scorchSVC.RunbookParameters
Where rbData.RunbookId = runbooks.Single().Id).ToList()


'initialize input paramaters
Dim input1param = (From rbData In runbookpars
Where rbData.Name = "Creator").Single()

Dim input2param = (From rbData In runbookpars
Where rbData.Name = "FirstName").Single()

Dim input3param = (From rbData In runbookpars
Where rbData.Name = "LastName").Single()

'etc........


'create parameter XML
Dim paramxml = New XDocument(
New XElement("Data",
New XElement("Parameter",
New XElement("Name", input1param.Name),
New XElement("ID", input1param.Id.ToString("B")),
New XElement("Value", strCreator)
),
New XElement("Parameter",
New XElement("Name", input2param.Name),
New XElement("ID", input2param.Id.ToString("B")),
New XElement("Value", strFirstName)
),
New XElement("Parameter",
New XElement("Name", input3param.Name),
New XElement("ID", input3param.Id.ToString("B")),
New XElement("Value", strLastName)
'etc.........
)))

 

'prepare Runbook job
Dim job = Microsoft.SystemCenter.Orchestrator.WebService.Job.CreateJob(System.Guid.NewGuid(), runbooks.Single().Id, GlobalVariables.StrLoginName, DateTime.Now, GlobalVariables.StrLoginName, DateTime.Now)
Dim strParam As String = paramxml.Document.ToString()

job.Parameters = strParam
scorchSVC.AddToJobs(job)
scorchSVC.SaveChanges()

Copper Contributor

@jukedude Thanks for the IIS Core Module stuff, would this allow to whitelist an entire domain? (eg: *.myADdomain.local, not just PC1.myADdomain.local).  I am currently upgrading my PC so it would be a bummer to have CORS work for my old PC and not work for my new PC, just because it is hardcoded to my old PC name?  (I installed not too long ago so things are fresh in my mind but imagine a year down the line...)

Is there somewhere an official "dummed down for sysadmins who are not devs" version of the IIS Cors module we could have?  

 

@Chris4870 I am not a dev (at all!) but, you may want to use Fiddler to capture the HTTP traffic while using the new console.  Would ease the analysis.  In the meanwhile here's what I have found so far (using PowerShell):

$OrchURI = 'http://OrchServerFQDN:5001' #Replace 5001 by the WebService port
$JobID = '00000000-0000-0000-0000-000000000000' # Correct job ID of course, you can list all jobs to search by name later on or maybe there can be filtered...

# To list all Runbook Servers
$RunbookServers = @(Invoke-RestMethod -Uri ('{0}/api/RunbookServers' -f $OrchURI) -UseDefaultCredentials | Select -ExpandProperty value | Select -ExpandProperty Name)

# To list all Jobs currently running
$CurrentJobs = Invoke-RestMethod -Uri ('{0}/api/Jobs?$filter=Status%20in%20(%27Running%27,%27Pending%27)&$expand=Runbook($select=Name),RunbookInstances' -f $OrchURI) -UseDefaultCredentials | Select -ExpandProperty value

# To list all available Runbooks
Invoke-RestMethod -uri ('{0}/api/Runbooks' -f $OrchURI) -UseDefaultCredentials | Select -ExpandProperty value

# To Stop a job
Invoke-RestMethod -Uri ('{0}/api/jobs/{1}' -f $OrchURI,$JobID ) -UseDefaultCredentials -Method Patch

# To Start a job
    $body = @{
        RunbookId = $JobID
        RunbookServers = $RunbookServers
        Parameters = @()  # Assume we could put the parameters here, never went past this section
        CreatedBy = $null
    } | ConvertTo-Json 
    Invoke-RestMethod -Uri ('{0}/api/Jobs' -f $OrchURI) -Body $body -Method Post -ContentType 'application/json' -UseDefaultCredentials

 

Copper Contributor

@PChip1976 , your solution works for me when I am on the IIS server for any of it's local hostnames, IP address etc whereas before it would only work with localhost but when I try to access it from another machine it fails with the "Uh oh! Trouble connecting to WebApi..." error.

 

Any ideas? Thanks!

 

Microsoft

@PChip1976  Indeed, you can use wildcards in 'origin' to make CORS config simple, see the example in the IIS CORS official docs. CORS is not that easy to wrap your head around quickly but, its worth the effort :)

 

I found the following articles useful on IIS and CORS:

1. https://blogs.iis.net/iisteam/getting-started-with-the-iis-cors-module

2. https://techcommunity.microsoft.com/t5/iis-support-blog/putting-it-all-together-cors-tutorial/ba-p/7...

 

General tips on CORS debugging for sysadmins:

CORS issues will only arise when you use the browser (to view the Console) and not if you use other (API) clients like a PS script. Practically, they manifest as failed API requests and the infamous "Uh Oh - can't connect to API" popup.

They can be easily spotted in your browser's developer console in the 'Console' and 'Network' tabs. Once CORS issue is ascertained,

1. look for the `Origin` header in the preflight request (HTTP verb == `OPTIONS`) which failed. This value is automatically generated by the browser and the Web Console app has no control over it.

2. Check if the Web API's web.config accept this value of `Origin`.

3. The IIS CORS module interprets `origin='*'` in a special manner.

4. Update `web.config` or figure out how you can make the browser emit a different `Origin` value.

Microsoft

@Zen77 Please look at the browser's developer console, the Console and Network tabs.

1. Is the issue due to CORS misconfiguration?

2. If not, try to access the API remotely via PS.

3. If the PS route fails, look at the API machine's Event Log (Windows Logs > Application Logs) for insight into the error. Otherwise, (PS route succeeds) a CORS misconfiguration or using the wrong user to open the Web Console could be potential reasons.

Copper Contributor

@PChip1976 Thx for the Powershell examples. They will come in handy.

However, we need to trigger Runbooks from a Windows Forms app. I have been successful by creating a small test app in C# and the extension 'OData Connected Service'. Important: It seems the 'Connected Services' configurator cannot authenticate when entering the address URI/$metadata.xml. Just download the $metadata.xml first and load it from a local disk. Once configured add the statement 'using Orchestrator.Data.Models;' on top of your code and you should be able to connect via the new API.

 

Chris4870_0-1647383456413.png

Chris4870_1-1647383505841.png

 

Copper Contributor

@Molish So I now have the new WebAPI & WebConsole working from any machine but when triggering one of the runbooks on the server by clicking submit and entering the details (just a upn) the runbook doesn't appear to start, the submit button is greyed out and the small progress bar above it moves along without ever stopping.

This behaviour is seen on the server itself using Edge, so it is not just on other web clients. There is no problem with the runbook if run from IE with Silverlight. 

 

What is the most likely cause of this behaviour when all of the authentication seems fine?

All the runbooks present are listed in the WebConsole and I don't see any errors in any of the Windows logs!

 

Other runbooks have various options which cannot be selected individually in the new console so it seems as though it is not communicating properly with the existing system which works fine using IE with Silverlight!

Copper Contributor

@Zen77 You may want to check that your Web Service Auth Settings:

 

Anonymouse Authentication needs to be Enabled

And

Windows Authentication needs to be Enabled

 

That's required for the web service, but NOT required for the web console.

Copper Contributor

@OllrickQuad20 

Thanks ever so much, that's fixed it!

 

I do still have an issue with optional fields in a runbook being flagged as mandatory though, not sure why that would be.

Copper Contributor

Any newer ETA or any further updates on the console for 2019?

Copper Contributor

@PChip1976  Thank you for the PS examples - great help!

 

in case anyone would like to pass parameters below as example of the parameter array 

 

$Parameters = @()
$Parameter = [pscustomObject]@{Name="ParamName";Value="ParamValue"}
$Parameters += $Parameter

 

 

Copper Contributor

Hello everyone. I have some questions about launching job (using WebApi with powershell)  - tried with example from @PChip1976 - but always have error - (400) bad request. 

Can anyone give some ps example how to start a new job in some runbook (i have his name and id) with 1 parameter (IniParam) - for initialization data activity.

Will be very grateful for help.

Microsoft
Extending @PChip1976 and @Juan__F example:
# To Start a job
    $body = @{
        RunbookId = $JobID
        RunbookServers = $RunbookServers
        Parameters = @(
            [pscustomobject]@{Name='IniParam';Value='the_value'}
        )
        CreatedBy = $null
    } | ConvertTo-Json 
    Invoke-RestMethod -Uri ('{0}/api/Jobs' -f $OrchURI) -Body $body -Method Post -ContentType 'application/json' -UseDefaultCredentials
@Dmytro125 you may want to share the structure of your request which generates 400 error response.
Copper Contributor

@jukedude - after some tests find out a problem - incorrect RunbookId in body of request.  Thanks!

Iron Contributor

I was able to get the console up and running finally where I'm able to see job history and I can run runbooks from that perspective but my list of Runbooks and Runbook Folders is blank. Anyone else having this issue?

Edit: Determined that this is because the console will not list runbooks located in the root "Runbooks" folder. Created a new folder within the root and moved my runbook and it appeared in the console.

 

Another thing I noticed is that when I have an output parameter (Returned data), it shows up as a required INPUT parameter when I try running it from the console. That is a huge problem...

Edit: This is documented in their known issues (https://docs.microsoft.com/en-us/system-center/orchestrator/release-notes-orch?view=sc-orch-2022)

agreca_1-1656075290196.pngagreca_0-1656075265981.png

 

Edit: Also, does any documentation exist for the REST API? The comments provided here are great and I'm able to start runbooks but I need to be able to retrieve the Returned Data as well.

Edit2: Found that by querying the root "/api" uri it will list the endpoints available and from that I was able to get the Returned data using the RunbookInstanceParameters endpoint. Here's the complete list for any curious but this is by no means appropriate documentation..

 

Jobs
Runbooks
RunbookParameters
RunbookInstances
RunbookInstanceParameters
Activities
ActivityInstances
ActivityInstanceData
RunbookServers
RunbookDiagrams - returns (404) Not Found
Events
Folders
Statistics
Script - returns (500) Internal Server Error
Login - of kind "FunctionImport"

 

Iron Contributor

@Zen77 


@Zen77 wrote:

I do still have an issue with optional fields in a runbook being flagged as mandatory though, not sure why that would be.


What do you mean by optional fields?

Edit: do you mean that all fields are technically optional in all contexts other than the new console and in the new console every field is required? It even includes the output parameters as required input fields... Which is a huge issue.

Iron Contributor

Has anyone submitted feedback using the Bug report button on the console? If so, has anyone received any response regarding their feedback? I'm guessing "no" since there doesn't appear to be a way to identify who is submitting the report.. 

Copper Contributor

I should say Parameters, they appear as optional in the original console's runbook but are required in the new console's runbook...

 

[Parameter(ValueFromPipelineByPropertyName)]
[String]$Delegate1,

[Parameter(ValueFromPipelineByPropertyName)]
[String]$Delegate2,

[Parameter(ValueFromPipelineByPropertyName)]
[String]$Delegate3,

 

Thanks

Copper Contributor

Good evening, trying to track down a potential bug and would like to see if anyone else has a similar entry in their Orchestrator database. 

Upon running the following TSQL - does any have a record for Name like S-1-0-0 or S-1-1-0 or S-1-5-32-545?

use <orchestratorTableName>;
SELECT * FROM [Microsoft.SystemCenter.Orchestrator.Internal].[Parties]

 

Thanks

Copper Contributor

@Juan__F 3 entries in our parties table - 1 matches the service account we run the SCORCH services under.

 

No entries for S-1-0-0, S-1-1-0, or S-1-5-32-545

Copper Contributor

@Andy_Stewart Thank you for checking Andy. 

Copper Contributor

@Molish Hi, any further updates to the code, or are we still on 0.1.0?

Copper Contributor

Hi all,

after installing SCORCH2022 the new console was working fine. But now the left pane with "Runbook Folders" stays empty. The console users are member of the  "Orchestrator Users Group". Do you have any ideas what to check? The history is working and i can trigger runbooks through it. 

Best regards

Philipp

 

Brass Contributor

@preisss 

 

I found this post about halfway down:

 

cpierce1720_0-1674164862182.png

 

Copper Contributor

@preisss 

what has worked for me in the past is truncating the AuthorizationCache - closing the browser and opening up once more. 

TRUNCATE TABLE [Microsoft.SystemCenter.Orchestrator.Internal].AuthorizationCache

Copper Contributor

Hi,

thanks for your answers. I changed the Users Group to a Domain Group with PermissionsConfig and reset the Auth Cache and now we can see the Folders in the console. But now everyone can see and start all Runbooks. The Users Group only has read access to the root and the other folders are different Domain Groups. In the Designer the permissions are working correctly and i can only start Runbooks where i have access. But somehow the Console seems to ignore the Folder settings? Any ideas again?

 

Copper Contributor

Hey Guys,

 

Thanks a lot for the valuable comments on the API - helped a lot to force PS to cooperate with various endpoints.

Based on the above comments, this request body was accepted by the API - the RB starts correctly:

 

$body = @{
        RunbookId = $runbookId 
        RunbookServers = @($runbookServer)
        Parameters = @(
                    [pscustomobject]@{Name='Test_param1';Value='test 1_2_3'},
                    [pscustomobject]@{Name='Test_param2';Value='The value of the 2nd parameter'}
                    )
        CreatedBy = $null 
    } | ConvertTo-Json 

#Start RB

 Invoke-RestMethod -Uri "$($SCORCHAPIUri)/api/Jobs" -Body $body -Method Post -ContentType 'application/json' -UseDefaultCredentials

Notice that the RBServers parameter is declared as an array - it would not work without the '@'.

 

I've been trying to install the UR1 recently, seeing a weird issue. Regardless of the source for the updates (Windows Update or MS Update Catalog), it seems that the Runbook Server MSP package is mutually exclusive with the Management Server MSP package.

When one is installed (either the Runbook Server UR1 patch or the Management Server UR1 patch), the installation of the other cannot complete. It ends up with a 1603 error (MSI log) or 0x80070643 (Windows Update).

@Molish Any hints on what could be the reason, or maybe this is intended to happen (ie. the Management Server patch contains the contents of the Runbook Server)?

In my environment, all the SCORCH roles except the SQL DB are located on the same machine.

 

Much obliged for any comments!

Brass Contributor

Hello. The SCO 2019 Web Console user guide (page 3) says, "Please install ASP.NET Core Hosting bundle for IIS (.NET Core v5.x.y)

The download link goes to a download page for .NET 5.0, which has a highlighted warning stating, "This release has reached end of life...'. 

 

Question:   Does the new Orchestrator web console specifically require .NET 5.0?  Or will it work with a newer version? 

 

thanks

Chris

Microsoft

Hi @cpierce1720,

 

The new web console in 2022 UR1 removes requirement of .NET 5.0 (and upgrades to .NET 6 LTSC).

Both the new console for SCO 2019 and SCO 2022 RTM depend on .NET 5.0 and will not work with .NET 6.0

Brass Contributor

@jukedude  -  thank you!

Brass Contributor

Hello, 

 

Despite multiple efforts (looking at the tips in this forum), I am still receiving a '500 Error' when I try to navigate to the new WebAPI site. Not sure what's causing this. 

 

webapi_error.jpg

 

thanks in advance,

Chris

Microsoft

Hi @cpierce1720,

 

Looks like IIS is rejecting your web.config because it may be malformed or it does not have the right form/syntax. I had previously shared a sample config here.

I suggest you take out some of the XML elements from web.config till it parses (the app would not work, IIS should no longer reject the config and the error message would change). Then you may bring the elements back.

 

Good luck!

Microsoft

@Juan__F @preisss The incorrect authorizations observed for various users has been acknowledged as a bug in the original release (ie. this blog post) and in Orchestrator 2022 RTM. It has been fixed in 2022 UR1 as mentioned in their KB article.

Brass Contributor

Hello again, 

 

I've been removing XML elements from the web.config file, one at a time, and it seems like the module might be the issue. 

 

bad module.jpg

 

This is the module I have installed:

 

installed module.jpg

 

Is this the wrong module for the new SCO console? 

 

 

Thanks, 

Chris

Microsoft

@cpierce1720 Hmm... that is puzzling, maybe the installation of the ASP.NET Core Hosting module is broken in some way. It is mentioned in your web.config (and that's necessary), but "wrong" according to IIS.

Copper Contributor

Is there any further update on when this will be available and usable for live?

Having to rely on IE and Silverlight is starting to be an issue...

Copper Contributor

Hiya,

 

Thanks for the info in this blog been really helpful. 

 

Managed to get SCORCH 2019 WebApi working but the console side doesn't work.  Only got anonymous authentication set there and fire it up and still asks for username/password.  I input it anyway, use my own account which has sql perms also tried the SCORCH service account and it fails to connect to the WebAPI and get this "Uh oh! Trouble connecting to WebApi..." error.  

 

Any ideas please.

Copper Contributor

Hi @PChip1976 ,

thanks a lot for your Code triggering a Runbook with Orchestraor 2022 webAPI!

I can pass a value for a parameter in the Initialize Data activity like below:

$OrchURI = 'https://sco2022.stefan.local' #Replace 5001 by the WebService port
$RunbookPath = '\Test\TEST.Runbook'
$RunbookID =  ((Invoke-RestMethod -uri ('{0}/api/Runbooks' -f $OrchURI) -UseDefaultCredentials)  | Select -ExpandProperty value | where {$_.Path -eq $RunbookPath}).Id

# To Start a job
    $body = @{
        RunbookId = $RunbookID
        Parameters = @(
                [pscustomobject]@{Name='HyperVName';Value='HyperV01'}
                )
        CreatedBy = $null
    } | ConvertTo-Json 
Invoke-RestMethod -Uri ('{0}/api/Jobs' -f $OrchURI) -Body $body -Method Post -ContentType 'application/json' -UseDefaultCredentials



 

Microsoft

Hi @Andy_Stewart, Microsoft has released an update on the WebAPI/WebConsole components ~17 Aug. Please try it out, it is essentially the latest SCO 2022 Web components bundled for SCO 2019.

The migration steps provide a changelog as well.

Copper Contributor

Hi @jukedude ,

Installed latest version onto our web server to test.

Powershell calls to the API endpoint are returning lists of jobs, runbooks, runbook servers etc, so that proves the API endpoint can retrieve details from the SCORCH DB itself.

The issue i'm having is trying to run the Web Console itself - constantly get the popup error "Uh oh! Trouble connecting to WebApi [status 0]"

 

Nothing really obvious that I can see i've missed? Hoping its something simple - any thoughts on what to check ?

 

Copper Contributor

Dev Console is showing:

Access to XMLHttpRequest at 'http://xxxxxxxx:8082/api/folders' from origin 'http://yyyyyy.testdomain.com:8082' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

 

But i DO have this entry in the API web.config

 

<add allowCredentials="true" maxAge="7200" origin="http://yyyyyy.testdomain.com:8082">
<allowMethods>
<add method="GET"/>
<add method="PUT"/>
<add method="POST"/>
<add method="PATCH"/>
<add method="DELETE"/>
</allowMethods>
<allowHeaders allowAllRequestedHeaders="true"/>
</add>

Version history
Last update:
‎Aug 17 2023 05:42 AM
Updated by: