locked
System Center Orchestrator RRS feed

  • Question

  • What are the limitations of System Center Orchestrator????
    • Edited by rohtvikrant Thursday, February 25, 2016 12:06 PM
    Thursday, February 25, 2016 12:00 PM

Answers

  • Hi,

    it really depends on what you mean by "limitations". I'll try to give you a list of some of the important stuff.

    1. Limitations from the hardware and software perspective - Minimum Requirements for SCorch

    This really depends on the scale of the Orchestrator Depoyment, but there are some minimum requirements, which must be fulfilled in order for your deployment to work properly. I'll suggest you start with this article and review the requirements of the Orchestrator for the different deployment scenarios:

    System Requirements

    Here are also the requirements in regards to the network ports:

    TCP Port Requirements

    Going through this you will note that there are separate requirements for every of the Orchestrator features:

    Individual Feature Requirements

    2. Limitations in regards to PowerShell

    You probably know that Orchestrator uses the so called "Activities" to do what you want it to do. There are multiple Integration Packs (IP) both from Microsoft as well as such from other vendors (HP, DELL, etc.) The interesting part comes when you want to do some custom stuff and you don't have an activity for this. What do you do? You use the "Run .NET Script" activity, which allows you to run your custom code (scripts written in VB.NET, JScript, C#, and Windows PowerShell) within Orchestrator. In my experience so far PowerShell is the one used the most. So what are the PowerShell limitations?

    You can only run PowerShell version 2 with SCorch. Sounds like a limitation, right? Fortunately there are ways to optimize and workaround this. So please take a look at this great Wiki article, it will give you a good start on running PS with SCorch:

    PowerShell & System Center Orchestrator - Best Practice Template

    Here are also a couple of good advices on the same topic:

    Hitting Limits and Breaking Through – Making Orchestrator Work for You!

    3. Other limitations

    Well here some other limitations, which you might face:

    Orchestrator Quick Tip: What’s the Maximum Size of Parameters?

    and

    Orchestrator and Activity data size limits - a case of re-executing Runbooks

    You have also an alternative, depending on what you have to automate - it is called SMA (Service Management Automation):

    Service Management Automation

    Of course you could combine them both in order to achieve more complex goals:

    Service Management Automation: Integration with OrchestratorI think this information should be enough to give you a good overview. Hope it helps.

    Regards,


    Stoyan (Please take a moment to "Vote as Helpful" and/or "Mark as Answer" where applicable. This helps the community, keeps the forums tidy, and recognizes useful contributions. Thanks!)


    Thursday, February 25, 2016 2:36 PM

All replies

  • What are the limitations of Runbook Server.
    Thursday, February 25, 2016 12:02 PM
  • Hi,

    from:

    Orchestrator Architecture

    "You can deploy multiple runbook servers per Orchestrator installation to increase capacity and redundancy." There is no hard coded limit regarding the number of Runbook Servers. 

    From:

    How to Configure Runbook Throttling

    "By default, each runbook server is configured to simultaneously run a maximum of 50 runbooks. You can change this number by using the Runbook Server Runbook Throttling tool. In most cases, you can keep this default setting, but you should consider the resource requirements of the runbooks on a particular server when considering whether to change it. If the server has a number of runbooks with high resource requirements, you might run fewer runbooks simultaneously on the runbook server. If they are simple runbooks with minimal requirements, you might consider increasing the number of simultaneously run runbooks."

    An interesting article on the topic:

    Optimising Runbook Performance

    You could use also the Orchestrator BPA, which:

    "Gathers information about an Orchestrator deployment.
     Determines if the configurations are set according to the Microsoft recommended best practices.
     Reports on collected configurations, indicating settings that differ from recommendations.
     Indicates potential problems in the deployment."

    Here you can find more information about the SCorch BPA:

    Best Practices Analyzer

    And at the end some helpful information in regards to the SCOrch DB:

    Database Sizing and Performance

    Another two good articles, written by Stefan Horz on the topic SCorch DB Performance and Size:

    Keep your Orchestrator DB small – find the toplogging Runbooks

    Turn off Logging for all Orchestrator Runbooks

    Hope this helps. Regards,


    Stoyan (Please take a moment to "Vote as Helpful" and/or "Mark as Answer" where applicable. This helps the community, keeps the forums tidy, and recognizes useful contributions. Thanks!)


    Thursday, February 25, 2016 12:47 PM
  • Hi,

    it really depends on what you mean by "limitations". I'll try to give you a list of some of the important stuff.

    1. Limitations from the hardware and software perspective - Minimum Requirements for SCorch

    This really depends on the scale of the Orchestrator Depoyment, but there are some minimum requirements, which must be fulfilled in order for your deployment to work properly. I'll suggest you start with this article and review the requirements of the Orchestrator for the different deployment scenarios:

    System Requirements

    Here are also the requirements in regards to the network ports:

    TCP Port Requirements

    Going through this you will note that there are separate requirements for every of the Orchestrator features:

    Individual Feature Requirements

    2. Limitations in regards to PowerShell

    You probably know that Orchestrator uses the so called "Activities" to do what you want it to do. There are multiple Integration Packs (IP) both from Microsoft as well as such from other vendors (HP, DELL, etc.) The interesting part comes when you want to do some custom stuff and you don't have an activity for this. What do you do? You use the "Run .NET Script" activity, which allows you to run your custom code (scripts written in VB.NET, JScript, C#, and Windows PowerShell) within Orchestrator. In my experience so far PowerShell is the one used the most. So what are the PowerShell limitations?

    You can only run PowerShell version 2 with SCorch. Sounds like a limitation, right? Fortunately there are ways to optimize and workaround this. So please take a look at this great Wiki article, it will give you a good start on running PS with SCorch:

    PowerShell & System Center Orchestrator - Best Practice Template

    Here are also a couple of good advices on the same topic:

    Hitting Limits and Breaking Through – Making Orchestrator Work for You!

    3. Other limitations

    Well here some other limitations, which you might face:

    Orchestrator Quick Tip: What’s the Maximum Size of Parameters?

    and

    Orchestrator and Activity data size limits - a case of re-executing Runbooks

    You have also an alternative, depending on what you have to automate - it is called SMA (Service Management Automation):

    Service Management Automation

    Of course you could combine them both in order to achieve more complex goals:

    Service Management Automation: Integration with OrchestratorI think this information should be enough to give you a good overview. Hope it helps.

    Regards,


    Stoyan (Please take a moment to "Vote as Helpful" and/or "Mark as Answer" where applicable. This helps the community, keeps the forums tidy, and recognizes useful contributions. Thanks!)


    Thursday, February 25, 2016 2:36 PM