Sunday, October 16, 2011

Installing System Center Orchestrator 2012

In this blog post I'll walk through the steps involved to get the new Microsoft System Center Orchestrator 2012 BETA installed. System Center Orchestrator 2012 (also known as SCO or SCORCH) is the new name for the market leader 'Automation and Runbook' application Opalis that Microsoft aquired in late 2009.

Taken from the Microsoft System Center Blog:

System Center Orchestrator 2012 delivers 3 core benefits to customers:

  • Integration – Optimize and Extend your existing Investments
  • Orchestration – Deliver Flexible and Reliable Services
  • Automation – Lower Costs and Improve Predictability

The steps in this post are based on the BETA edition, although the installation steps will be the same for the final RTM version.

To start with, ensure you have a virtual or physical machine that meets the following pre-requisites:

Resources:

  • 1 gigabyte (GB) of RAM or above (2 GB recommended)
  • 200 megabyte (MB) of available hard disk space
  • Dual-core CPU or better
 
Software:

  • Microsoft Windows Server 2008 R2
  • Web Server Role (IIS) installed
  • .Net Framework 4
  • Sliverlight 4 (for the Orchestration Console)
  • Microsoft SQL Server 2008 R2

You can download the BETA from the link below:

http://www.microsoft.com/download/en/details.aspx?id=26503

Once you have downloaded the BETA to a location on the C drive of your new Windows Server 2008 R2 machine, right mouse click on the 'SystemCenterOrchestrator2012Beta.exe' installer and select 'Run As Administrator' to begin the process.


Choose a directory to extract the files to and select 'OK'


Now Right Mouse Click on the 'SetupSCO.exe' installer and select 'Run As Administrator' to begin the installation wizard



You should now see the 'System Center Orchestrator 2012 Setup' window and you will be presented with a number of installation options. SCORCH supports either a fully co-located installation of all the roles onto the same server or it also supports standalone installation of each component onto different servers if you so wish.


We're going to go for the co-located installation and install all of the components onto the one virtual machine, so click on the 'Install Orchestrator' option to continue



 The installer will now check to see if your machine has met the pre-requisites and will prompt you if something needs to be installed beforehand  - see the screen below


Once the pre-requisites have been met, the 'System Center Orchestrator 2012 Setup' wizard will continue. Accept the licence agreement from the screen below and click on 'Next'


From the 'Select Features to Install' screen, ensure that the feature(s) you want are selected and then click 'Next' to move on


Based on the features that you have selected to install, the Pre-Requisite checker will again run and check the requirements for these features against the computer you are installing onto. In the screen below,I haven't installed the .Net Framework 4.0 so this has been highlighted. It does provide a nice little link for me though to go and download the .Net Framework 4.0 which is a handy tip!


Once you have downloaded and installed the pre-requisites, click on the 'Verify Prerequisites Again' button and the installer should move on to the next step

In the next step, you need to create a user account within your Active Directory that will be used to run Runbooks and access remote system resources. This account must have at least local administrative privileges on the computer you are installing SCORCH onto along with 'Log on as a service' rights enabled too.


Once you have created the new account with the relevant administrative and logon as a service peissions on the SCORCH computer, click on the 'Test' button and the installer should confirm if all is in place to continue on. When you see the 'Credentials Accepted' message, then click 'Next'


At this point we are now ready to create the new Orchestrator SQL database and there are a couple of ways to do this. I am installing SCORCH into its own SQL instance on a remote SQL server and have already configured this before I have begun the SCORCH installation process.

Important Note: As was the case with SCOM, System Center Orchestrator 2012 needs an SQL collation setting of  - SQL_Latin1_General_CP1_CI_AS. If this collation setting is not configured, you WILL run into problems down the line with an issue relating to 'Send Email Activity not storing data'

The screenshot below shows the SQL collation setting being configured at the time of the SQL Instance installation


As I've installed a separate SQL instance for my SCORCH installation, I've made my SCORCH service account (srv_scorch) a member of the 'Sys Admin' role for this particular instance in SQL. The SCORCH service account needs to have at least 'db_owner' permissions on either the SQL instance or a pre-created empty SQL database named 'Orchestrator' before you continue with the SCORCH installer.

From the screen below, type in the SQL server name and instance (if applicable) and select either a new or existing database depending on your preferences, then click 'Next'


From the next screen, configure the Orchestrator management group and whether or not you want to grant remote access for the Runbook Designer (this option will have to be selected from a computer other than the Management Server however). Click 'Next' to continue


Leave the ports at their default values or change them to whatever you need to and then click 'Next' to continue on


Choose either the default installation path for SCORCH or browse to a different location and then click 'Next'


Confirm you are happy with the installation summary or if you need to change anything simply click on the handy 'Change' link option beside each section to go back directly to make your changes. Click 'Next' once you're happy to continue


Finally, once the installation is finished, you should see the screen below stating that 'Setup completed successfully'.


Click on 'Close' from the screen above and the new 'System Center Orchestrator Runbook Designer' window will now open confirming that you have installed SCORCH correctly!


 You can also now open the 'System Center Orchestrator Deployment Manager' from the 'Start Menu' as below


The screen below shows the new System Center Orchestrator Web Console - accessible from the port number that you specified during installation


So that completes the installation of SCORCH and for anyone who has had the hardship of installing Opalis 6.3 with the console, then you'll find this a much more pleasant and easier process than that one!

Now to see how hard I can push the integration of SCORCH with the other System Center products!


Saturday, October 15, 2011

Resolving DPM 2012 Untrusted Domain Server Communication Issues

I ran into this problem during the week with a multi-tenant DPM 2012 installation. This server was originally a DPM 2010 server of which we had configured untrusted domain server’s to communicate with. The solution that I have outlined in this post will work for both DPM 2010 and DPM 2012.

All was working fine on this server until I noticed an alert from SCOM detailing the following:

Alert: DPM2012: Recovery point creation failed (3114) Resolution state: New

When I analysed the alert I found the following text:

The protection agent operation failed because DPM could not communicate with the Protection Agent service on sql-srv.lab.local.

DPM failed to communicate with sql-srv.lab.local because of a communication error with the protection agent. (ID: 53)

I logged onto the DPM 2012 server - using my newly configured Central Console through SCOM!, checked the agents from within the ‘Management’ tab and found the screen below:


It was interesting that all of the servers in this particular untrusted domain had the same ‘Unavailable’ message and straight away got me thinking that it had to be a password or logon issue with the account that is created when the communication is originally setup between the untrusted domain server and the DPM server.

When I checked the ‘Local Users and Groups’ on the DPM 2012 server and looked at the accounts for the untrusted servers giving the error message, I saw that I had forgot to change the password policy on the local user account when I originally created them and they were set with the password policy in the screen below


Untick the ‘User must change password at next logon and change it to ‘Password Never Expires’ and then click ‘OK’ to continue


A new feature of DPM 2012 is to use Certificate authentication (PKI) between the untrusted domain and DPM servers and if this feature was in use here, then I wouldn’t have the problem I was now facing (as the original DPM 2010 server that this communication was setup from didn’t have PKI functionality).

To resolve the issue was fairly easy though and here’s what I did to get the agents back to a working state.

Firstly, logon to the server in the untrusted domain that is generating the error in DPM and open up an elevated command prompt.

Now browse to the following location on the C drive of your untrusted domain server:

C:\Program Files\Microsoft Data Protection Manager\DPM\bin

Once here, type the following to reset the password:

SetDpmServer.exe -dpmservername dpmservername.domainname.local -isnondomainserver –updatepassword


It should now present you with an option to type in your new password for the local account that the DPM server is using for communication between the untrusted domains.

Once you’ve typed your new password in twice, you should then get a message back stating that the configuration has completed successfully!


Now all that’s left to do is to go back to your DPM 2012 console, go to the Management tab and then select the ‘Agents’ option from the left hand side. Right mouse click on the agent that you have just updated the password for and select the ‘Refresh’ option


Once you have refreshed the agent status, it should now change to ‘OK’

 
Repeat this process for any other agents that you have with an error status similar to this one.

DPM 2012 Role Based Access Management with SCOM

This is a quick post to describe a new feature of System Center DPM 2012  - centralised Role Based Access.

With DPM 2012, you can achieve a centralised management model by using the DPM 2012 Central Console. See my previous posts on 'Managing and Monitoring System Center DPM 2012 with SCOM' for more information and on how to install to Central Console.

Logon to your SCOM server which should already have the DPM 2012 Central Console installed onto it. Open up an elevated command prompt and browse to the following location:
C:\Program Files\Microsoft DPM\bin\
Once here, kick off the ‘DefaultRoleConfigurator.exe’ installer


Once this finishes you should see the screen below to confirm that the DPM Centralised Role Based Access is configured.


Once that's complete, open up your SCOM Console, go to the 'Administration' tab and then select 'Security' and 'User Roles'.


The screenshot above shows the new DPM 2012roles available for configuration within your environment - all from the central SCOM Console window and no need to logon to a DPM 2012 server to configure!

Managing and Monitoring System Center DPM 2012 with SCOM Part 3

This is the final part of my blog series about 'Managing and Monitoring System Center DPM 2012 with SCOM' and if you haven't read my previous two posts on this topic, then you can get to Part 1 here and Part 2 here - both of which go through the steps required to install the DPM 2012 Management Pack into SCOM along with the DPM 2012 Central Console integration that links the two System Center products together.

In this post I will demonstrate the centralisation of DPM tasks using the SCOM console as the central point of administration.

Open the SCOM Console, click on the ‘Monitoring’ tab on the left and expand the ‘Data Protection Manager 2012’ Management Pack folder. You will notice that you now have separation of the alerts within the DPM Management Pack down to ‘Backup Alerts’ and ‘Infrastructure Alerts’.


The ‘Backup Alerts’ folder and its contents show all alerts pertaining to backup issues such as recovery point creation, replica synchronization, disk backup and tape backup alerts.

The ‘Infrastructure Alerts’ folder shows alerts relating to the Disk Infrastructure, the DPM Server itself, Protected computers and also the Tape infrastructure.

The power of the new DPM 2012 Management Pack along with the DPM 2012 Central Console installed into SCOM is evident when you click on an alert and then look at the actions available to you in the ‘Actions’ pane over on the right hand side of the screen.

You will see that you have your specific ‘Alert Tasks’ actions along with your ‘DPM Data Source Tasks’ pane which both allow you to have a much more granular level of control when troubleshooting and resolving your DPM alerts.


To troubleshoot an alert, highlight the alert in the central window and then click on an action from the ‘Actions’ pane on the right hand side.


For the error above, I’ve clicked on the ‘Run Consistency Check’ action and the DPM server has initiated the consistency check without any other input required from me and has come back with the following message to confirm the consistency check has begun.


Now, if I click on the radio box from the notification above to launch the Jobs View to monitor the progress of jobs on exit, I can see the progress of all current jobs on my DPM 2012 server as shown below


Back in the SCOM Console again, if you click on the ‘View Affected Items’ task from the ‘Alert Tasks’ action pane, it will open up the window below


When this window opens up, you now have access to the three options for this specific alert. These options are: TroubleshootTake Recommended Action and Resume Backups.

If you click on the ‘Troubleshoot’ button it will automatically open up the DPM 2012 console with a scoped view of the particular error message directly from the SCOM Console like below


If you click on the 'Take Recommended Action' button, DPM will try to automate the recommended action (if any) for the alert that is raised. In this example, there is no corrective action required.


If you click on the 'Resume Backup' button, DPM will try to resume the backup job that had stopped due to the error.



These are just some of the tasks and actions that you can take with your new DPM 2012 installation once you have it integrated into your SCOM environment. It is worth remembering too that I haven’t needed to log on to any other server than the SCOM server so it is already consolidating the management of two System Center products into one application. Also, with the new DPM 2012 Central Console being able to manage multiple DPM servers including DPM 2010 and DPM 2012 at the same time, you can really see the benefits in upgrading to this latest version sooner rather than later!!

Wednesday, October 12, 2011

Managing and Monitoring System Center DPM 2012 with SCOM Part 2

In Part 1 of this blog series I walked through the steps to get the DPM 2012 Central Console components installed onto a SCOM Management Server.

This post will go through the next phase of the installation, covering the import of the DPM 2012 Management Pack into SCOM and making the necessary changes to your SCOM servers to allow for smooth operation of the DPM 2012 Central Console once it's integrated into your SCOM environment.

Once the Central Console installation is finished, you need to browse to your DPM installation location (generally it’s something like - C:\Program Files\Microsoft DPM). If all is going to plan, then we should now have a ‘Management Packs’ directory in here which contains the new DPM 2012 Management Packs for SCOM.


Now, open up your SCOM 2007 R2 console, go to the ‘Administration’ tab, right mouse click on ‘Management Packs’ and then click on the ‘Import Management Packs’ option from the flash out menu to open the ‘Import Management Packs’ wizard


From here, click on the ‘Add’button and then click on ‘Add from disk’


Click on ‘No’ from the screen below


Now in the ‘Select Management Packs to Import’ window, browse to the location of your DPM 2012 SCOM Management Packs and select them both. Now click on ‘Open’ to import them into SCOM

You should then see a security warning message coming back from one of the management packs – at this point, you can safely ignore this security warning and then click on ‘Install’


 Click ‘Yes’ from the confirmation window below


After a few seconds, the two management packs should be installed correctly


Once the Management Packs have installed correctly, click on 'Close' to exit the 'Import Management Packs' window

Now, staying within the SCOM Console, go back to the ‘Monitoring’ tab and then you should see a new management pack available called ‘Data Protection Manager 2012’ as shownindicating that the DPM 2012 Management Pack for SCOM has installed correctly


Before you start using the SCOM console to manage your DPM 2012 installations, you will need to possibly make some changes to your SCOM environment in the form of some overrides. You will also need to add 1 registry key to the Operations Manager Management Server and 3 additional registry keys to your DPM 2012 server.

Note: You DO NOT need to worry about creating the 4 overrides below in your SCOM environment if you have installed the most recent core ‘Operations Manager 2007 R2 Management Pack’ into your environment (you always keep your SCOM MP’s up to date right?). The new core MP for SCOM automatically updates these values within SCOM for the Management Server role so no need to change anything for your DPM 2012 install!

I highly recommend updating your SCOM MP’s on a regular basis and you can download the latest core ‘Operations Manager 2007 R2 Management Pack’ from here:



The tables below are taken from the DPM 2012 BETA documentation and outline the changes required in your environment:


Post-Installation

If you are using an Operations Manager server to monitor the DPM servers, you must make the following overrides on the server running Operations Manager:


Default
Override Value
Health Service Handle Count Threshold
2000
8000
Health Service Private Bytes Threshold
100MB
1GB
Monitoring Host Handle Count Threshold
2000
8000
Monitoring Host Private Bytes Threshold
100MB
1GB

Whether or not you had to make the above overrides to your SCOM environment, you will definitely need to make the following changes to the registry on your SCOM server and also your DPM 2012 server.

On the SCOM Management Server where you have the DPM 2012 Central Console installed, open up ‘Regedit’ and browse to the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Modules\

Note: It is VERY IMPORTANT that you use the exact letter case size when specifying keys and DWORD entries. Make sure you use Capital letters exactly in the examples, otherwise it won’t work!
Now create a new ‘Key’ below the ‘Modules’ key called ‘Global’


Now create a new ‘Key’ below the ‘Global’ key called ‘PowerShell’


Finally, right mouse click on a blank space within the new ‘PowerShell’ sub-key and create the two new DWORD Values as specified below

Value: IsolationLevel  Type: dword   Data:00000000

Value: QueueMinutes  Type: dword   Data:00000077



On the DPM server, you need to make changes to two keys and four values.

Note: Before making the following changes, ensure that Operations Manager agent (not console) is installed on this computer.

On the DPM server open up ‘Regedit’ and browse to the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Modules\

Note: It is VERY IMPORTANT that you use the exact letter case size when specifying keys and DWORD entries. Make sure you use Capital letters exactly in the examples, otherwise it won’t work!
Now create a new ‘Key’ below the ‘Modules’ key called ‘Global’


Now create a new ‘Key’ below the ‘Global’ key called ‘PowerShell’


Finally, right mouse click on a blank space within the new ‘PowerShell’ sub-key and create the two new DWORD Values as specified below

Value: IsolationLevel Type: dword Data:00000000

Value: QueueMinutes Type: dword Data:00000077



Now, still on the DPM server, within Regedit, you need to browse to the following location:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HealthService\Parameters

Once here, you need to change the value for the ‘Persistence Version Store Maximum’ DWORD value to 0005dc00


Next, from the same screen, you need to right mouse click on a blank area and then select ‘New’ and then ‘DWORD (32 Bit) Value’ and then you need to name the new DWORD ‘State Queue Items’ with a value of 0x00001000 as shown below


For the final registry edit on the DPM server, browse to the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HealthService\Parameters\Management Groups\<Management Group Name>

Now change the ‘MaximumQueueSizeKB’ DWORD value to 0x00019000 as shown below


That completes the registry edits on the DPM server and all that’s left to do now is to restart the ‘System Center Management’ service (Health Service) on the DPM server from the ‘services.msc’ snap-in to enable the new registry values.

If you have followed the steps in this post and also Part 1 of this series, you should now have the DPM 2012 Central Console installed and integrated into your SCOM Console with all of the relevant overrides and registry changes in place too.

In the final post of this series - Part 3 - I will demonstrate running some administrative tasks for DPM 2012 direct from the SCOM Console which will show a central management pane for both System Center products.