The following blog post is a series of Q&A items related to System Center Orchestrator 2012. Thanks to Marty List, Paul Johnson and Albert Uy for their expertise, insights and assistance putting this together!

 

Question: How can I tell what Integration Packs are current for Orchestrator.

Answer: At this point it appears that the best approach is a documentation based one using this URL to track down what is current: http://technet.microsoft.com/en-us/library/hh295851.aspx.

After installation the versions should appear as the following: The current versions for System Center 2012 Integration packs should be 7.0.1298.0 as of early August 2012.

image

The System Center Marketplace should be the correct location to find integration packs for Orchestrator. The main site is available at: http://pinpoint.microsoft.com/en-US/applications/search?q=integration+pack 

Or System Center 2012 specifically at: http://pinpoint.microsoft.com/en-us/applications/system-center-2012-orchestrator-integration-packs-12884928230

 

Question: Where can I find additional sample integration packs?

Answer: There are several sources for integration packs, and the list will change over time.  Here are some current recommendations:

Microsoft download catalog: http://www.microsoft.com/download/en/search.aspx?q=integration%20pack&p=4&r=10&t=102

TechNet Gallery search:

http://gallery.technet.microsoft.com/site/search?query=orchestrator&f[0].Value=orchestrator&f[0].Type=SearchText

TechNet Gallery Examples:

Community IP downloads:

CodePlex search: http://www.codeplex.com/site/search?query=orchestrator

Other IP download information:

 

Question: When you deploy an Integration Pack (IP), the wizard provides an option to stop running instances, but is there any way of knowing if the running instances should be stopped?

Answer: Not really.  When a new IP is deployed, there should not be a need to stop running instances, but when an upgrade to an existing IP is deployed you might want to stop any long-running instances so they will not keep running with the old version, but the answer will depend on the situation and requires research.

 

Question: How do you know if you need to uninstall/install a new Integration Pack (IP), or if you can install/update an existing IP?

Answer: This depends on how the IP was written, if it has the same product code (similar in concept to MSI product IDs) you can update, but if the author of the IP changed the product code then you would need to uninstall the old IP first.  Usually an updated IP will contain the same product code and can be updated, but if the documentation for the IP does not include this in the instructions, you never really know without looking inside the OIP XML for the Product Code. If the product code changed, you will most likely need to fix any existing Runbooks that referenced the old IP.  Just updating an IP with the same product code could have an impact on any existing Runbooks that use it, but this depends on the types of changes made by the IP author, so full testing is recommended before updating an IP in a production environment.

 

Question: When you unregister (remove) an Integration Pack with the Deployment Manager, does that also undeploy it from the Runbook servers it has been deployed to?

Answer: No, you need to uninstall (undeploy) the Integration Pack from the Runbook servers, then unregister it.

 

Question: When I try to unregister (remove) an Integration Pack with the Deployment Manager, why don’t I don’t get the right-click (context) menu?

Answer: You need to right-click on the actual name of the Integration Pack, the Deployment Manager UI does not recognize right-clicks on the icon.

 

Question: When a job is started, does Orchestrator record who started it?

Answer: No, in the default configuration web service calls are not logged. This applies to requests made with the Orchestration console as well as the Orchestration Integration Toolkit (OIT).  Audit trail logging can be enabled with atlc.exe. For more information about logging, see the Audit Trail topic in TechNet.

 

Question: Can the configuration of an Integration Pack (IP) be secured so that only certain users or groups can access it?

Answer: No, the global IP configuration cannot be locked down by security group or users.  Once the IP is configured with credentials for the external system, anyone with permissions to create or edit Runbooks can access that IP using those credentials, and access or modify any data the IP has permissions to.  This could be viewed as a major security hole if all users with access to the Runbook Designer should not be allowed to access that data.  If the data accessed by a specific Integration Pack needs to be secured to only certain Orchestrator users, a separate Orchestrator environment would need to be installed, and the IP would only be installed in this environment.

 

Question: What security requirements should be required to allow someone to access the Orchestration Console?

Answer: Members of the OrchestratorUsersGroup have full access to the Orchestration Console, as well as many administrative tasks.  Adding users to the OrchestratorUsersGroup grants more access than is required for users to view and run Runbooks.  By default there is no group that just grants access the Orchestration Console, but a member of the OrchestratorUsersGroup can use the Runbook Designer to add users or groups directly to the permissions of the Folders and Runbooks.   Information on security for Orchestrator is available at: http://technet.microsoft.com/en-us/library/hh912320

Note 1: These groups are specified during the initial installation, and can be either local or domain if the management server and web service & console features are on the same server.  Domain groups may be simpler to use, but in general the recommended approach is to secure resources with local groups, adding domain groups to local groups, and adding users to domain groups.  Domain groups are simpler but not required.  But if the management server and web service are on different servers, then domain groups must be used.

Note 2: Despite the name, members of the OrchestratorUsersGroup are granted access to the entire Orchestrator environment along with every RunBook.  This group grants more permissions than a typical user role would be given, think of this as the "Orchestrator Runbook Authors Group".

Category: infrastructure