Browsed by
Month: October 2015

System Center 2012 R2 – High Availability: Data Protection Manager

System Center 2012 R2 – High Availability: Data Protection Manager

To continue series about how to implement each product of System Center 2012 R2 suite as highly available and how to backup & recover them, in this article we will focus on System Center Data Protection Manager.

In order to make your Service Manager infrastructure highly available you will have to:

  • Deploy DPM on highly available virtual machine
  • Configure a second DPM server as replica
  • Deploy the DPM database on a SQL Server failover cluster or highly available virtual machine

Just because DPM functions as a data protection solution for other elements of your infrastructure, doesn’t mean that you don’t need to back up the DPM server itself. Your protection strategy for the DPM server should include backing up:

  • The DPM database
  • All local volumes and application data on the computer that hosts DPM
  • All replicas on the DPM server protected by that DPM server

In fact, there are two ways to handle protection of your DPM server. First, you can back up the DPM server using a second DPM server. When you configure DPM in this way, the second DPM server functions as a replica of the first DPM server. In the event that the first DPM server fails, the secondary server will start protecting all of the workloads that were previously protected by the primary DPM server. Additionally, you can configure a tertiary DPM server that will function as a replica of the secondary DPM server, this is called DPM chaining backup.
Secondary you can back up the DPM database to tape. You can configure a DPM server to back up its own databases to its tape library, or you can use non-Microsoft software to back up the databases to tape or removable media. The DPM database is named DPMDB. This database contains the DPM configuration together with data about DPM’s backups. You can back up the database by using several different methods.

In a case of disaster, you can rebuild most of the functionality of a DPM server by using a recent backup of the database. Assuming you can restore the database, tape- based backups are accessible, and they maintain all protection group settings and backup schedules. If the DPM storage pool disks were not affected by the outage, disk-based backups are also usable after a rebuild.
If a primary server fails you can switch protection to the secondary server. After you’ve switched protection, you can perform recovery functions from the secondary server. These are the main tasks to recover your primary server.

  • Recover DPM database
  • Recover replicas after recovering the database
  • Reestablish protection

If you need more detailed information about backing up and restoring your DPM infrastructure you can have a look here.

Open Microsoft Edge as Built-in Administrator

Open Microsoft Edge as Built-in Administrator

Microsoft has gone the direction of making the Edge browser a true app now and additional security is in place much like the Internet Explorer Enhanced Security that we have grown to love and hate.

In order to get rid of this message and be able to use your Built-in administrator account to use Edge, you need to modify your local security policies.

Note
You can also configure a GPO to apply this change in your lab domain (NOT in production please).

You will need to log out or restart the computer in order to apply changes.

System Center 2012 R2 – High Availability: Service Manager

System Center 2012 R2 – High Availability: Service Manager

To continue series about how to implement each product of System Center 2012 R2 suite as highly available and how to backup & recover them, in this article we will focus on System Center Service Manager.

For remember System Center Service Manager 2012 R2 is composed of six major parts, as described below:

  • Service Manager Management Server: Contains the main software part of a Service Manager installation. You can use the Service Manager management server to manage incidents, changes, users, and tasks.
  • Service Manager Database: The database that contains Service Manager configuration items (CI) from the IT Enterprise; work items, such as incidents, change requests, and the configuration for the product itself. This is the Service Manager implementation of a Configuration Management Database (CMDB).
  • Data Warehouse Management Server: The computer that hosts the server piece of the data warehouse.
  • Data Warehouse Databases: Databases that provides long-term storage of the business data that Service Manager generates. These databases are also used for reporting.
  • Service Manager Console: The user interface pieces that is used by both the help desk analyst and the help desk administrator to perform Service Manager functions, such as incidents, changes, and tasks. This part is installed automatically when you deploy a Service Manager management server. In addition, you can manually install the Service Manager console as a stand-alone part on a computer (such as client computer).
  • Self-Service Portal: A web-based interface into Service Manager, that will be mainly used by end-users to create, check and close work items, such as incidents or requests.

In order to make your Service Manager infrastructure highly available you will have to:

  • Deploy multiple load-balanced management servers.
  • Deploy the Service Manager databases on a SQL Server failover cluster or highly available virtual machine.
  • Deploy multiple web content and portal servers.

Backing up Service Manager involves backing up the following elements:

  • Service Manager encryption keys
  • Service Manager database
  • Service Manager data warehouse database

You can backup the Service Manager encryption keys using the SecureStorageBackup.exe command line utility from an elevated command prompt. And you can backup the Service Manager database and the data warehouse database using SQL Server Management Studio or by using DPM.

Additionally, to recover a Service Manager deployment, perform the following general steps (you can learn more about Service Manager disaster recovery here):

  • Restore the encryption key.
  • Install the new Service Manager management server on a computer that has the same name as the original management server.
  • In the event that SQL Server was also installed on the Service Management management server, install SQL Server and restore the Service Manager database.
  • Run the Service Manager installation Wizard, and select the Use and Existing Database option, providing the details of the SQL instance that host the Service Manager database.
System Center 2012 R2 – High Availability: Operations Manager

System Center 2012 R2 – High Availability: Operations Manager

To continue series about how to implement each product of System Center 2012 R2 suite as highly available and how to backup & recover them. In this article, we will focus on System Center Operations Manager (also known as OpsMgr and SCOM).

Unlike OpsMgr 2007, you can natively maintain availability and redundancy for your management servers in any management group. System Center Operations Manager 2012 R2 is composed of these majors roles and services:

  • Management Group: The management group is the basic unit of functionality. At a minimum, a management group consists of a management server, the operational database, and the data warehouse database.
  • Management Server: The management server is the focal point for administering the management group and communicating with the database. Depending on the size of your computing environment, a management group can contain a single management server or multiple management servers gathered in a resource pool.
  • Resource Pool: A resource pool is a collection of management servers used to distribute work amongst themselves and take over work from a failed member.
  • Operational Database: The operational database is a SQL Server database that contains all configuration data for the management group and stores all monitoring data that is collected and processed for the management group. The operational database retains short-term data, by default 7 days.
  • Data Warehouse Database: The data warehouse database is a SQL Server database that stores monitoring and alerting data for historical purposes. Data that is written to the Operations Manager database is also written to the data warehouse database, so reports always contain current data. The data warehouse database retains long-term data.
  • Operations Console: The operations console lets you monitor, author, report and administrates your SCOM infrastructure.

In order to make your Operations Manager infrastructure highly available you will have to:

  • Install multiple management servers and gather them into dedicated resource pools.
  • Make Data Access Service highly available using network load balancing.
  • Install the operations web console on multiple web servers in a load-balanced configuration.
  • Deploy both operational database and data warehouse database on a dedicated SQL Server Failover Cluster.

Backing up Operations Manager involves backing up the following elements (DPM supports backup needs):

  • Operational database
  • Data warehouse database
  • Audit Collection Services (ACS) database (if deployed)
  • Custom Management Packs (manual actions or script required)
  • Custom report definition files
  • Computer certificates

Microsoft recommends the backup schedule listed in the table below for an Operations Manager deployment (You can learn more about backup and disaster recovery in Operations Manager here).

In order to recover a Management Server on your Operations Manager infrastructure:

  • Build a new server, ensuring that it meets the minimum supported configurations, and use the same name that was given to the failed management server.
  • Restore the operational database and data warehouse database, if required.
  • On the new server, open a Command Prompt window by using the Run as Administrator option, and run the following command (this process only recovers the management server):

If you have to recover a management server when all management servers in the management group have failed, then you must also reconfigure the Run as Accounts.

How to Disable Windows 10 P2P Updates

How to Disable Windows 10 P2P Updates

By default in Windows 10, you download Windows updates and apps from other PCs in addition to Microsoft. Definitely, this can help speed up app and update downloads but when this is turned on, your PC may also send parts of previously downloaded Windows updates and apps to PCs on your local network or PCs on the internet!

Hopefully, you can disable this mechanism by going to Windows Update options.

What’s New in SCOM 2016

What’s New in SCOM 2016

If you are looking for what’s new in OpsMgr 2016, you can have a look to Kevin Greene’s System Center Universe Europe 2015 presentation video here.

In brief, SCOM 2016 (TP3 as of today) include these features:

  • Installs on Windows Server 2016 (2012 R2) and SQL 2014 (2012 SP2)
  • Web Console requires Silverlight 5 and run on IE11 but not on MS Edge
  • Operations Console now supported for deployment on Windows 10 & Windows Server 2016
  • No support for monitoring legacy Windows Sever 2003 agents
  • SQL_Latin1_General_CP1_CI_AS collation is no longer mandatory
  • Number of UNIX/Linux monitoring enhancements (multi-threaded shell command/script executions, OMI agent sharing between OpsMgr & ConfigMgr, file system discovery, new shell command templates, native monitoring of Apache and MySQL)
  • System Center Advisor or Operational Insights to Operations updated to Operations Management Suite (Links on-premise monitoring (Management Group or MMA) to Microsoft’s public cloud)
  • Scheduled Maintenance Mode (administration workspace, multiple schedule support, new PowerShell cmdlets)
  • Core Management Packs updated and new Management Pack (Windows Azure, SQL 2014)
System Center 2012 R2 – High Availability: Orchestrator

System Center 2012 R2 – High Availability: Orchestrator

To continue series about how to implement each product of System Center 2012 R2 suite as highly available and how to backup & recover them, in this article we will focus on System Center Orchestrator.

Unlike Virtual Machine Manager, you can’t install Orchestrator service as a Failover Cluster role. For remember, Orchestrator is composed of several role and services.

  • Management Server: The management server is the communication layer between the Runbook Designer and the orchestration database.
  • Runbook Server: A runbook server is where an instance of a runbook runs. Runbook servers communicate directly with the orchestration database. You can deploy multiple runbook servers per Orchestrator installation to increase capacity and redundancy.
  • Orchestration Database: The database is a Microsoft SQL Server database that contains all of the deployed runbooks, the status of running runbooks, log files, and configuration data for Orchestrator.
  • Runbook Designer: The runbook designer is the tool used build, edit and manage Orchestrator runbooks.
  • Runbook Tester: Runbook tester is a run-time tool used to test runbooks developed in the Runbook Designer.
  • Orchestration Console: The Orchestration console lets you start or stop runbooks and view real-time status on a web browser.
  • Orchestrator Web Service: The Orchestrator web service is a Representational State Transfer (REST)-based service that enables custom applications to connect to Orchestrator to start and stop runbooks, and retrieve information about operations by using custom applications or scripts. The Orchestration console uses this web service to interact with Orchestrator.

In order to make your Orchestrator infrastructure highly available you will have to:

  • Install multiple runbook servers.
  • Install the Orchestrator Web Service on multiple web servers in a Load-balanced configuration.
  • Deploy the Orchestrator database on a SQL Server Failover Cluster (or highly virtual machine).
  • You cannot deploy multiple Management Servers. When the management server is unavailable, you will be unable to publish new runbooks. You will be able to start, stop, and monitor existing runbooks using the Orchestration console.

Backing up Orchestrator involves backing up the following elements (You can learn more about backing up Orchestrator here):

  • Backup of the Orchestrator database (which stores runbooks)
  • SQL instance service master key (database uses encryption)
  • File backup of the Orchestrator management server (ensure that settings.dat file is backup, it allows Orchestrator program files to access the Orchestration database)
  • File backup of each runbook server
  • File backup of each Orchestrator web server (ensure that web.config files are being protected)

In order to recover your Orchestrator infrastructure from backups:

  • If you are restoring the same database server from which the backup was taken, and the service master key has not changed, simply restore the backup.
  • If you are restoring to a different database server with a different service master key, or you are restoring to the same database from which the backup was taken but the service master key has changed, the service master key must be restored to match the one used during the database backup. Use this SQL query
  • Restore the database from the backup.
  • On the Orchestrator Management Server, run the Data Store Configuration utility from the Start menu or use settings.dat file, and restart the Management Service.
  • On each Runbook Server, run the Data Store Configuration utility, and restart them.
  • On each Orchestrator Web Server run the following command (assuming your using default installation path)
  • Then you need to open up Connection Strings in Orchestrator 2012 virtual application (IIS Manager) and modify Orchestrator Context. Locate the segment that starts with “provider=System.Data.SqlClient;provider connection string” and then modify the Data Source and Initial Catalog attributes according to your new SQL Server and Database Catalog name respectively.
  • If you want to re-encrypt the connection strings, you can execute the following at the command prompt
System Center 2012 R2 – High Availability: Virtual Machine Manager

System Center 2012 R2 – High Availability: Virtual Machine Manager

The goal of this series is to see how to implement each product of System Center 2012 R2 suite as highly available and how to backup & recover them.

Obviously, the most straightforward method of making the server that hosts a System Center product highly available is to deploy that product within a highly available virtual machine and configure a replica virtual machine hosted on a second failover cluster. Additionally, you have to make the databases for each System Center product highly available by deploying the databases on

  • SQL Server instance hosted on a highly available virtual machine
  • SQL Server failover cluster
  • SQL Server availability groups (Using availability groups involves substantial configuration of SQL Server prior the deployment of the System Center product. You’ll have to specify the availability group listener name during product setup.)

But the problem with deploying the product on a highly virtual machine is that it doesn’t take into account the problems that could go wrong with the VMM service itself or problems with the operating system that the VMM is running on, if something goes wrong in these places, VMM service would go down. Fortunately, you can use specific strategies for mostly System Center products.

About VMM, you can install it on an existing failover cluster. VMM supports being installed as highly available when deployed on an existing failover cluster but it is a fault tolerant service feature, it doesn’t increase scale/performance. In this configuration, the Virtual Machine Manager service account must be a domain account and you must also configure Distributed Key Management to store VMM encryption keys in AD DS. Additionally, deploy the VMM database to a SQL Server failover cluster (should be separate from the failover cluster that hosts the VMM failover cluster).

During installation, it will automatically detect that setup is running on the cluster node and it will ask if you want to deploy VMM as highly available. Setup steps will remain the same except an additional step to configure dedicated failover cluster role.

After the first node installation, you can easily add another node to this HA VMM cluster that you just created, to do that simply start the VMM setup on the second node where you want to install HA VMM. After going through the EULA page and selecting the VMM server feature checkbox you will see a similar pop up as the first node installation, but this time we will detect the HA VMM and ask “if you want to add this server as a node”. If you say YES, there will be the minimum amount of pages of setup and your second node will be added. You will need to repeat this on all of the nodes that you want to add to this HA VMM installation.

Once you have installed VMM, you need to plan backup and recovery scenarios. Perhaps the simplest method of protecting System Center products is to deploy them in virtual machines. You can then configure DPM to protect those virtual machines. When recovering a VM protected by DPM, you can choose to recover the VM, or you can perform item level recovery. When recovering a VM, you can choose to recover the VM to its original location or to a separate Hyper-V host that has the DPM agent deployed. Item level recovery allows you to choose to recover specific files or folders from a VM, rather than having to recover the VM in its entirety.

In order to recover a VMM deployment, you need to have a backup of the VMM database. You should also have a backup of the files stored in the VMM library. Microsoft recommends that you perform a full backup of the VMM database every 7 days and perform an incremental backup of the VMM database every day. You should backup at least on VMM library server whenever you substantially modify content stored on the server (You can learn more about backing up and recovering VMM deployment here).

You can back up the VMM database using the VMM console, by using SQL Server Management Studio, or by configuring protection for the database using DPM.

You can restore the VMM database using SQL Server Management Studio, DPM, or by using the SCVMMRecover.exe utility from an elevated command prompt on the server that hosts VMM. After restoring the VMM database, you will need to:

  • manually remove any virtualization hosts that you had removed from VMM subsequent to when you performed the backup
  • manually remove any VMs that you had removed from VMM subsequent to when you performed the backup
  • manually add any virtualization host that had been added to VMM subsequent to when you performed the backup
Note
If you restore the VMM database to a separate computer, you may need to reassociate any virtualization hosts and library servers that display an Access Denied message.