sql and system center - · pdf file1 deploy sql 2012 in various different configurations to...

1

Deploy SQL 2012 in various different configurations to support System Center 2012 R2

running on Server 2012 R2

Paul Keely MVP

SQL AND SYSTEM CENTER

SQL SERVER 2012 WITH SYSTEM CENTER 2012

R2 ON SERVER 2012 R2

2

SQL AND SYSTEM

CENTER

Introduction ........................................................................................... 6

1.0 SQL Versions and Supportable Features ................................... 7

1.1 SCOM 2012 R2 ...................................................................... 7

1.2 SCCM 2012 R2 ...................................................................... 8

1.3 SCSM 2012 R2 ....................................................................... 8

1.4 SCVMM 2012 R2 .................................................................... 8

1.5 SCO 2012 R2 ......................................................................... 9

1.6 SQL Server on Windows Server 2012 .................................. 10

2.0 Building a SQL Cluster ............................................................. 11

2.1 Sequence for a Cluster Build ................................................ 11

2.2 Prepare and Present Storage ............................................... 12

2.3 Initialize the Disks ................................................................. 15

2.4 Create a Windows Cluster .................................................... 19

2.5 SQL Cluster Installation ........................................................ 28

3.0 SQL AlwaysOn ......................................................................... 40

3.1 Install SQL Server on the Replica ......................................... 40

3.2 Enabling AlwaysOn Availability Groups on the Cluster ......... 43

3.3 Adding the Replica to the Failover Cluster ............................ 46

3.4 Adding AlwaysOn Endpoints to the Replica .......................... 52

3.5 Creating a Blank Database to Protect with AlwaysOn ........... 53

3.6 Create the AlwaysOn Seed Share ........................................ 55

3.7 Creating an AlwaysOn Availability Group .............................. 57

3.8 Deploying SCOM into the AlwaysOn Availability Group ........ 65

3.9 Adding the SCOM Databases to the Availability Group ......... 66

3.10 Deploying Additional System Center Products ...................... 73

4.0 Hyper-V Replica ....................................................................... 75

4.1 Testing HVR ......................................................................... 86

SQL AND

SYSTEM

CENTER

Learn how to deploy

SQL in Highly Available

(HA) scenarios to

support any System

Center product. Then

use System Center to

monitor, backup,

automate and deploy

SQL in a highly

managed environment.

3

5.0 Deploying SCOM with Different HA Options .............................................................................. 89

5.1 Basic SCOM Design .............................................................................................................. 90

5.2 Distributed Design ................................................................................................................. 91

5.3 Local Site HA ......................................................................................................................... 93

5.4 Multi-Site HA with SQL AlwaysOn ......................................................................................... 94

5.5 SQL Stretched Cluster ........................................................................................................... 96

5.6 HA Using Separate Management Groups .............................................................................. 97

5.7 Using Hyper-V Replica .......................................................................................................... 99

6.0 SQL in Azure to Support System Center ................................................................................. 101

6.1 Network Connectivity ........................................................................................................... 101

6.2 System Center Support in Windows Azure .......................................................................... 102

6.3 VM Configuration ................................................................................................................. 102

6.4 VM Sizing ............................................................................................................................ 103

6.5 Network Bandwidth .............................................................................................................. 103

6.6 Disk Types and Configurations ............................................................................................ 104

6.6.1 High Availability Disks ................................................................................................... 104

6.6.2 Disk Cache Settings in Windows Azure Virtual Machines ............................................. 105

6.6.3 Enabling Read Write Cache for the OS Disk ................................................................. 106

6.7 Optimizing SQL Configuration in Windows Azure VMs ........................................................ 106

6.8 Use Data Disks for SQL DB Files ........................................................................................ 106

6.9 Disk IOPS in Azure Virtual Machines ................................................................................... 107

6.10 Autogrow Settings................................................................................................................ 107

6.11 High Availability & Disaster Recovery (HADR) ..................................................................... 107

7.0 Backing up SQL with DPM ...................................................................................................... 109

7.1 Introduction to System Center Data Protection Manager 2012 R2 ....................................... 109

7.2 What Can DPM 2012 R2 Protect? ....................................................................................... 109

7.3 Change Tracking ................................................................................................................. 109

7.4 Getting Started with DPM .................................................................................................... 110

7.5 Adding Disk to the DPM Storage Pool ................................................................................. 110

7.6 Deploying DPM Agents ........................................................................................................ 110

7.7 DPMDB ............................................................................................................................... 110

7.8 Special Considerations for Using DPM to Protect SQL Workloads ...................................... 111

7.8.1 RPO, RTO and RLO ..................................................................................................... 111

7.8.2 Recovery Point Objectives ............................................................................................ 111

4

7.8.3 Recovery Time Objectives ............................................................................................ 111

7.8.4 Recovery Level Objectives ........................................................................................... 111

7.8.5 Local SQL Backups ...................................................................................................... 111

7.8.6 SQL Maintenance Tasks .............................................................................................. 112

7.8.7 SQL Management Tasks .............................................................................................. 112

7.8.8 Moving SQL Server Between Domains ......................................................................... 112

7.8.9 Renaming a Computer Running SQL Server ................................................................ 112

7.8.10 Changing the Recovery Model of a Database ............................................................... 112

7.8.11 Replacing a Disk on a SQL Server ............................................................................... 112

7.8.12 Adding Databases to a SQL Server .............................................................................. 113

7.8.13 Changing the Path of a SQL Server Database .............................................................. 113

7.8.14 Renaming a SQL Server Database ............................................................................... 113

7.8.15 Parallel Backups ........................................................................................................... 113

7.8.16 Auto-Protection of SQL Instances ................................................................................. 113

7.8.17 Co-Location for Large Scale SQL Server Implementations ........................................... 114

7.9 Windows Azure .................................................................................................................... 115

7.10 Pre-Configuration................................................................................................................. 115

7.11 SQL Recovery Models ......................................................................................................... 115

7.12 Supported SQL Server Versions .......................................................................................... 115

7.13 SQL Clusters ....................................................................................................................... 116

7.13.1 Adding SQL Cluster Members ...................................................................................... 116

7.13.2 Removing SQL Cluster Members ................................................................................. 116

7.14 Mirrored SQL Servers .......................................................................................................... 116

7.15 Unsupported Scenarios ....................................................................................................... 117

7.16 Specific SQL Server Configurations ..................................................................................... 117

7.16.1 Configuration Walkthough............................................................................................. 117

7.17 Configuring Protection Groups for SQL Server .................................................................... 121

7.18 Restoring SQL Server Data from DPM ................................................................................ 141

7.19 Short-Term Recovery Goals Restore ................................................................................... 143

7.19.1 Recovery to the Original Instance of SQL Server .......................................................... 144

7.19.2 Recovery to Any Instance of SQL Server ...................................................................... 145

7.19.3 Copy to Network Folder ................................................................................................ 146

7.19.4 Copy to Tape ................................................................................................................ 147

7.20 Long-Term Recovery Goals Restore ................................................................................... 148

5

7.21 Cloud Recovery Restore ...................................................................................................... 149

7.22 Additional DPM Information ................................................................................................. 150

8.0 Monitoring SQL with SCOM - Matthew Long ........................................................................... 151

8.1 Management Pack Audience ............................................................................................... 151

8.2 Configuration and Customization ......................................................................................... 152

8.2.1 Initial Setup ................................................................................................................... 152

8.2.2 Optional Monitoring Features ........................................................................................ 153

8.3 Extending the SQL Management Pack with MP Authoring ................................................... 157

8.3.1 SQL Management Pack Structure ................................................................................ 157

8.3.2 Useful modules when authoring SQl Monitoring ........................................................... 159

8.4 Sample VBScript ................................................................................................................. 160

8.5 System.OleDbProbe Module ............................................................................................... 165

8.5.1 When Should You Use It .............................................................................................. 165

8.5.2 Required Configuration ................................................................................................. 166

8.5.3 Optional Configuration .................................................................................................. 166

8.6 Example Configurations ....................................................................................................... 168

8.7 Simple/Specified Authentication ........................................................................................... 169

8.7.1 Scenario 1 – Monitoring ................................................................................................ 169

8.7.2 Scenario 2 – Collection ................................................................................................. 169

8.7.3 Links and Further Reading ............................................................................................ 170

9.0 Building Out a SQL Server Template with VMM –Craig Taylor ................................................ 171

9.1 Using SQL Server Profiles in SCVMM 2012 R2 ................................................................... 171

9.2 Introduction .......................................................................................................................... 171

9.3 Preparing VMM .................................................................................................................... 172

9.4 Creation of a Sysprep SQL Server Virtual Machine Template .............................................. 173

9.5 Creation of the SQL Server Profile ....................................................................................... 182

9.6 Further Customisation Options ............................................................................................ 186

9.7 Deployment of the Service Template ................................................................................... 189

9.8 Conclusion ........................................................................................................................... 192

10.0 Special thanks ......................................................................................................................... 194

6

INTRODUCTION

Some time ago I wrote a guide for SQL and System Center, at the time of writing System Center 2012

had just released and it took until SP1 for SQL 2012 to be supported with System Center. The previous

guide focused very much on SQL and looked at areas like troubleshooting, best practices etc. In this

guide I have decided to be very much more focused on SQL and its interaction with System Center and

indeed Server 2012. In the last guide I felt that a lot of people were already installing SQL for quite some

time and there was a lot of knowledge out there on SQL installs but not best practices. SQL 2012 and

Server 2012 have brought some real game changers to the story, and because of that this guide is going

to go into way more detail on areas like setup and some of the options we have here. We are not going

to walk you through a basic SQL setup, there are a ton of guides for that on the internet, instead we are

going to look at some of the more complex areas like clustering, AlwaysOn, Storage Spaces and SQL

Azure. If you are new to this subject then I suggest that you download the guide above and use in in

conjunction to this one.

This guide is going to be a group effort, I wrote the last guide by myself, but felt it was better to include

some of the seasoned expert MVP's out there to help with this guide as there is a lot to take in. The idea

behind this guide was to discuss any time SQL comes in contact with System Center, of course the

design and setup are the start to it, but then we want to look at how System Center interacts with SQL

and give examples of it. So how do we build a SQL template in VMM, how do we monitor it in SCOM,

how can we automate things in SQL with SCO, how should we be backing up SQL with DPM. This guide

is going to go through a lot more walk thoughts on these and discuss different options. The people

involved with this guide were Pete Zerger did Azure, Robert Hedblom did DPM, Matthew Long did the

SQL MP chapter, Craig Taylor did the SQL VMM template section, Richard Green and Craig worked with

me on the general editing and work on the cluster builds etc.

Why are these community guide becoming more popular? As we all know things are changing really fast

in IT at the moment, long release cycles are just not cutting it when it comes to keeping up to day with

industry trends, a simple example of this was where the VMM team would release with a support for

versions of VMware that were already two versions old, and so Microsoft is releasing software faster and

faster. As Microsoft continues down the path of "rapid release" whereby R2 will follow SP1 with a year or

so it's going to be harder and harder to write conventional print books. They require too many edits and

can't keep up with the pace of production.

Lastly this guide is a community effort and so it may not be perfect and is not an official Microsoft guide.

It is written by people who work with System Center and SQL every day, and it is our way to share with

you and give a little back for all the hard work others give to us. If you find any errors, have thoughts of

your own or questions please forward them to [email protected].

Updates to this guide should be fairly frequent and we will tweet this in the usual groups.

Paul Keely -Cloud and Datacenter Management MVP

http://gallery.technet.microsoft.com/SQL-Server-guide-for-8584c403

mailto:[email protected]

7

1.0 SQL VERSIONS AND SUPPORTABLE FEATURES

The first thing to think about when it comes to deploying SQL to support System Center (SC) is what are

the supported configurations for System Center. In this document we are assuming that you are deploying

SQL 2012 on Server 2012. We are going to start off with each System Center product’s one by one,

what features of SQL are supported. The version of SQL listed here is the highest version, you can look

at the TechNet page to get more information. At a very high level here is a TechNet page that overviews

the SQL requirements.

Can I install this on Server 2008 with SQL 2008? The answer to this questions is more should you rather

than can you. Deploying SC on a VM on day 1 on older OS’s and SQL versions is certainty feasible. A

better discussion is would it not be better to deploy your new SC apps in such a way so that you can

leave it in place for 3-5 years from now. If you choose to deploy on Server 2008 you are deploying on

really old code. If you decide to use Windows Clustering in 2008 you are just starting off on a poor footing

compared to Server and SQL 2012. If you are running on an older version of VMware that does not

support deploying Server 2012 then you may be in a bit of a bind. It is a best practice to install your

systems and then just leave them alone, performing either OS upgrades on the Database servers, SQL

upgrades or DB moves in years to come is not the best approach for an enterprise management tool. We

are just going to cover a short overview of the SQL requirements for each product in the suite. There is

also a short commentary on each DB here.

1.1 SCOM 2012 R2

The requirements for SCOM 2012 R2 are listed here on TechNet. The SCOM environment contains up

to 3 DB’s, the operational DB, the DW and ACS. You need to configure the DW settings at primary install

time whether or not you are going to install the DW. You can connect multiple Management Groups (MG)

to the same DW but there must not be much latency between MG’s. If for example you have a preexisting

SCOM MG in Europe and you wanted to add a new MG in the US but share the European DW this would

be a poor SCOM SQL configuration and not the way the product was designed. The SCOM SQL DB

usage is considered one of the highest in the SC suite as agents are sending data to the Management

Servers (MS’s) all the time. If you are building SCOM on the cluster whereby you mount the drives on a

small mount point the SCOM installer cannot read the size of the underlying drives and as such it will fail

if the mount point is not less than the size of the DB’s you are trying to create in the installer.

SQL Version SQL 2012 SP1

SQL components SQL Server Full Text Search is required.

SQL components (DW) SSRS

SQL Clustering Single Active/Passive

SQL AlwaysOn Supported

Dynamic Port Supported

http://technet.microsoft.com/library/jj628198.aspx

http://technet.microsoft.com/en-us/library/dn249696.aspx#BKMK_RBF_OperationsDatabase

8

1.2 SCCM 2012 R2

The SQL requirements for SCCM are quite different than any of the other SC suite. The SCCM primary

Site (PS) server needs to have local admin rights on the SQL instance and this may impact your decision

to co-locate this SC product with any other DB due to some security concerns. Unlike other products in

the suite SCCM does not have a separate DW so do pay close attention to the SQL backend or report

rendering (that is not the fastest) will be quite slow.


SQL components SSRS

SQL Clustering Active/Passive Active/Active Multi Instance

SQL AlwaysOn Not Supported

Dynamic Port Not supported

1.3 SCSM 2012 R2

The SCSM SQL requirements are listed in TechNet here. SCSM where the reporting instance is installed will install up to 7 DB’s. In production SCSM requires a powerful SQL backend, and you should pay close attention to how you deploy the SQL backend.


SQL components SSRS, SSAS, AMO, Native Client

SQL Clustering Not specified on TechNet however as AlwaysOn in supported

clustering has to be supported


Dynamic Port Not specified on TechNet

1.4 SCVMM 2012 R2

The database requirements for SCVMM on TechNet is available here. The requirements on TechNet are not very specific for VMM. As you are using VMM to manage your hypervisor environment pay close attention to how you manage the HA component of your DB. One point of note is that if you are using Software Defined Networking (SDN) in VMM then all of your networking is located within your SQL DB, prudence would indicate some form of clustering and AlwaysOn for this DB.

SQL Version SQL 2012 SP2 or earlier

SQL components Not specified on TechNet





http://technet.microsoft.com/en-us/library/gg682077.aspx#BKMK_SupConfigSQLDBconfig

http://technet.microsoft.com/en-us/library/hh495585.aspx

http://technet.microsoft.com/en-US/library/gg610574.aspx

9

1.5 SCO 2012 R2

The Orchestrator DB has almost no SQL requirements outside the standard DB engine.

SQL Version SQL 2012

SQL components Not specified on TechNet





10

1.6 SQL Server on Windows Server 2012

Server 2012 has been a real game changer in many ways. The areas that will spring to mind are:

Better availability As Server 2012 can use a whole lot more CPU and RAM as a VM it’s possible to have very large and powerful SQL servers. Server 2012 now supports 640 processors over 64 sockets with up to 4TB of RAM.

Migration of RAM Hardware Errors Where the hardware permits SQL server

Storage Spaces

Storage Spaces often now referred to as “Spaces” is a new paradigm in storage and has a massive impact on how we can build SQL. When we look at the SQL cluster build below we are going to be using a Scale Out File Server (SOFS) Cluster. This cluster uses Storage Spaces as a storage target. This is the very latest way to use the Server 2012 storage features to build a cluster and present that to an application cluster as shared storage. *some points of note are CSV’s and Resilient File System are not supported with SQL 2012*

11

2.0 BUILDING A SQL CLUSTER

The preferred design for any SQL infrastructure that is important is to

cluster the SQL servers. This helps to secure against the failure of a

SQL compute node, it does not however help with a failure with the

backend storage. In the configuration I am using here we are using a

Scale Out File Server Cluster using storage paces as the backend

infrastructure. What this means is that I have a two node cluster

presenting storage, and a two node cluster presenting the SQL

application layer. With this configuration I can lose one node

presenting storage and one node presenting SQL. The last thing I am

then going to do is add a last layer of HA to the mix by using SQL

AlwaysOn (AO) You can just use a SQL cluster and not use AO, the

cost of AO is not for the fait hearted as you will need at least 3 copies

of SQL Enterprise .

2.1 Sequence for a Cluster Build

Design your SQL cluster

Build out the SOFS (beyond the scope of a SQL for System Center guide)

Build out your Hyper-V Cluster (beyond the scope of a SQL for System Center guide)

Build your SQL cluster (you are in the right place)

There are a ton of resources out there for a SOFS and Hyper-V

clusters.

Let’s first start off with a high level overview of what we are hoping to

achieve. We are going to use a 2 node SOFS cluster presenting

storage to a 2 node Hyper-V cluster. On the Hyper-V cluster we have a

VM on each node, SQL1 and SQL2.

The diagram below gives an overview of what the environment looks

like.

IF YOUR

DB’S ARE

IMPOR-

TANT

THEN YOU

NEED TO

CLUSTER

YOUR SQL

INSTANCE!

In this example we are

going to deploy a multi

instance SQL cluster

and then we are going

to add another layer of

HA with SQL

AlwaysOn.

12

We are only going to look at the SQL build here and there is a lot to get through. In the following steps

we are going to

Prepare and present storage

Create a windows cluster

Create a SQL cluster

2.2 Prepare and Present Storage

In this SQL cluster I want to build out several instances to host the whole of the System Center suite. I

am going to use 4 or even 5 instances. As this is a virtual guest cluster I am going to be housing the

different SQL files on separate VHDX's. I want to separate data and log not only for the applications

but also for each tempdb on each instance. So I am going to need a minimum of 4 drives per instance.

So the first thing I do is create a load of VHDX's on my storage and present that storage to the SQL

nodes, as you can see I have 31 drives and assigning a drive letter to each volume isn't gonna fly.

13

What I am going to do is create a top level volume, assign it a drive letter and then mount the 4 SQL drives for each instance inside that drive letter. This is all easier to do from a script but I am going to show you a run through from a GUI, so you get to understand the process. Work out how many instances you want and then go and create 5 VHDX's for each instance with the relative size you want. I ran this script to create the following drives for a SCOM instance, it’s pretty simple and from it you can see the disk sizes we are going to use. I ran a script to create 29 drives, I am separating for example the SCOM DB and the DW, and I am going to do the same for SCSM.

14

And in server manager I send up with this

15

Disk 2-5 are what I need to use for SCOM. Online the 4 disks (better to just do the 4 you want right

now because if you bring in 30 it’s difficult to manage that in the GUI.

2.3 Initialize the Disks

When they come online you need to format them and give them some form of workable name, I’m not

going to go through all the screen’s but as an example I’ll take the first drive (it’s going to be my empty

root) format it as a 64K drive and name it SCOM_ROOT

Just a quick note, you need a volume for the OS and if you want to separate

the SQL bits from the OS (and you really should) then you need to add a disk

to each node and ideally make it the same drive letter to host your SQL

instance bits

16

Then go to the file explorer and create a top level folder called SCOM_ROOT and in it 4 folders to hold the drives you are about to mount. (This is of course just a personal preference, you can mount the drives anywhere you like, just be aware of the complexity of VHDX sprawl)

Why are you making an empty root top level folder that is going to hold the

SQL disks 25GB, surely we only need a 1 GB drive? Well this is a good

point however if you take the SCOM installer it looks at the size of this top

level folder and if its 1 GB then it won’t let you install the SCOM DB’s

17

Then go and mount the drives into each folder

My disk structure now looks like this

18

And all the drives are now sitting on the empty root drive on the SQL node

19

2.4 Create a Windows Cluster

You need to do all these steps on each node in the cluster.

Install the Failover Clustering Feature on each of the nodes.

Then once the feature has been added, launch the Failover Cluster Manager.

As was mentioned earlier, this guide is not going to go into all the details and

nuances of building a Windows cluster as there are so many great references

for that elsewhere

20

Strictly speaking you don’t need to validate a cluster but you would be mad not to. Clustering in 2012

has become such a joy to work with and that is especially so when your clusters pass their validation.

21

Add each of the nodes in the cluster (I am going to add another node SQL3 to act as a target for the

AlwaysOn node in the next chapter)

Run the cluster verification tests and test everything.

22

The report has thrown up some warning and we need to review them but we can go ahead with the

cluster build.

23

I give the cluster a name and IP address and these are the Windows cluster details and are separate

from the SQL cluster details.

24

The cluster has been deployed and you should be able to ping the cluster name and IP address.

(This is not the place to go into complex cluster setup troubleshooting, but the main reason for me that

cluster wont deploy in production is that the cluster instance needs to create a computer object in AD, you need to either have the rights to do that or have it done in advance for you. Get this sorted, provide shared storage of some description, you can now ping that cluster name (SQLSC in my case) and it should be ready to go for a SQL deploy.

25

The last step in this process is the add the storage you created in the first step

Now as you can see the cluster brings in the disks but doesn’t name them the way I did in server

manager so I need to sort that out, I start off with finding the root

26

Gen2 VM’s and disk importing. During the build of this guide I created a disk

for the SQL bits and assigned it the D drive, as its hanging off the SCSI

controller. However as it’s a SCSI drive Failover Cluster Manager will allow

you to import this disk into a cluster as it sees this as shared. If you do this

by mistake (and I did) each time you import new disks into the system the

cluster will take ownership of this disk, or at least try to, and you will lose it as

a shared drive and as it’s got the SQL bits your SQL cluster will fail too . So

top tip is only import the number of drives you need.

27

Rename the drive to SCOM_ROOT and do the same with all the other drives

As all of these disks are mounted in the root of SCOM_DATA I need to make them all dependent on

SCOM_DATA so that the cluster knows to bring up the parent drive first, otherwise in a failover the

drives would fail.

28

2.5 SQL Cluster Installation

Now I am ready to go an install SQL on node 1 in the cluster, I am going to name it SCOM and place

the SQL files in the correct drives that we have already prepared.

To begin with I am going to create an empty role on the cluster and assign the disks to that role.

Add your disks to the empty role

29

Now you can see the storage with the empty role

From the SQL media select Installation and then New SQL Server failover cluster installation (I always

run this with admin rights)

36

Now when I go to SQL management studio I open on SCOM

37

The secondary node install is a few clicks and go, as you are just joining an existing cluster there is

almost no configuration, from the SQL media choose “Add node to a SQL failover cluster”

40

3.0 SQL ALWAYSON

SQL Server AlwaysOn is a new feature of SQL Server 2012. It allows us to replicate a database or a

group of databases to another server. The additional server could be located in a remote location from

the primary as there is no need for shared storage. AlwaysOn is only available with SQL Enterprise so

it’s not cheap. In our example above we have built out a multi instance SQL cluster that we are going

to install the full suite of SC applications. As we have built out the cluster using a clustered storage

configuration (SOFS) we have removed a single point of failure in the storage and SQL host level, what

we are now going to do is install SQL on a 3rd server (SQL3) and we are going to enable and configure

AlwaysOn. Ideally you would configure this in advance of installing the SC applications as you are

effectively generating a new instance, name and port for the applications to connect to.

3.1 Install SQL Server on the Replica

On a new VM, imaginatively called SQL3 we are going to install a standalone SQL instance and then

we will install Failover Clustering and finally join this node to the existing Windows cluster.

It’s a full install, however I am only going to cover the bare number of screens below as you have seen them in the previous chapters. The important thing to remember for the install is that the product key you use to install SQL3 must be Enterprise Edition to access the AlwaysOn feature.

41

The whole point of AlwaysOn is that it abstracts the back-end and so you do not need use the same

instance name. Obviously it will make it easier for the purposes of administration and troubleshooting if

you can use the same instance names on both the primary and secondary copies in the AlwaysOn

Availability Group but it’s not a hard and fast requirement.

42

Now for the really important part. All of the Data Directories listed here are using

the exact same drive letter and path as were configured previously on the SQL

cluster with the shared storage. AlwaysOn assumes that we have the same drive

mappings and folder naming in place on all servers in the solution.

43

3.2 Enabling AlwaysOn Availability Groups on the Cluster

Once the installation is complete, head over to the cluster nodes previously deployed, SQL1 and SQL2.

On each of the servers, open SQL Server Configuration Manager to enable AlwaysOn for each of

the SQL Server Database Engine instances which has been installed. In this case, this applies to

SCOM and the SCOM Data Warehouse SQL Server instances.

As you can see from the screens above and below, the Windows Failover Cluster name for the cluster

which this node is a member is populated for us. Tick the Enable AlwaysOn Availability Groups

check box to enable the feature and then hit the OK button.

Rinse and repeat the above for all of the instances you will be enabling AlwaysOn for. The next step is

to remove the dynamic port mode and list a static port instead. This is done in the SQL Server

44

Network Configuration portion of SQL Server Configuration Management on the TCP/IP Protocol

Name for each instance.

Scroll all the way to the end of the IP Addresses tab to reach the IPAll section and clear any value

from the TCP Dynamic Ports field and add a port number value to the TCP Port field. In this example,

I’m using 15100 and 15101 for SCOM and SCOMDWR respectively.

Once again, rinse and repeat these steps for the remaining instances and remember that these steps

need to be completed for all of the cluster node members (SQL1 and SQL2 in this example).

45

Now that AlwaysOn Availability Groups has been enabled you will need to restart the SQL Server

Database Engine service for each of the instances. You will only need to do this on the node which

currently owns the SQL Server database instance as the other node will have its service already in a

stopped state.

46

3.3 Adding the Replica to the Failover Cluster

We now need to add the Failover Clustering feature to SQL3 and add it to our cluster.

To do this, head back over to SQL3 and either from the Server Manager GUI as shown below or using

PowerShell add the Failover Clustering feature. For PowerShell, use the Cmdlet Import-Module

ServerManager | Install-WindowsFeature –Name Failover-Clustering –IncludeManagementTools.

47

Once the feature is enabled, the easiest way to add SQL3 to the cluster is to connect to an existing

node in the cluster, SQL1 in my case. Once connected, use the Add Node option from the GUI to add

SQL3 to the Windows Failover Cluster.

48

On the Select Servers pane of the wizard, enter SQL3 as the server name and then click Add.

On the Confirmation pane of the wizard, be sure to un-check the Add all eligible storage to the

cluster option. Leaving this ticked will attempt to add the local disks from SQL3 to the cluster which

wouldn’t work too well.

49

Once the wizard is completed, you should see SQL3 as a third node in the cluster from the Node view

in the Failover Cluster Manager.

Enabling AlwaysOn Availability Groups on the Replica

Once you have verified the above, make the changes to the SQL Server services that we previously

made to the clustered services to enable the AlwaysOn High Availability feature on SQL3.

Open SQL Server Configuration Management and use the SQL Server Services view and select

Enable AlwaysOn Availability Groups on the SQL Server Database Engine services for each

instance.

50

With AlwaysOn now enabled for the instances, use the SQL Server Network Configuration view to

set the port for each of the instances to a static port for the TCP/IP Protocol.

Use the same port number for each instance as you used on the clustered instances and be sure to

clear any values from the TCP Dynamic Ports field so that Dynamic Port is disabled.

52

Once you’ve finished enabling the feature and changing the port number to the new static port for the

instances, restart the SQL Server Database Engine service for each of the instances for the changes to

take effect.

3.4 Adding AlwaysOn Endpoints to the Replica

With the above now done, we need to setup the SQL endpoints on SQL3 which will pair with those

created previously on the clustered SQL instances.

Using PowerShell, enter the following Cmdlets:

$endpoint = New-SqlHadrEndpoint SCOMEndpoint –Port 5022 –Path

SQLSERVER:\SQL\SQL3\SCOM

Set-SqlHadrEndpoint –InputObject $endpoint –State “Started”

$endpoint = New-SqlHadrEndpoint SCOMDWEndpoint –Port 5023 –Path

SQLSERVER:\SQL\SQL3\SCOMDWReporting

Set-SqlHadrEndpoint –InputObject $endpoint –State “Started”

53

3.5 Creating a Blank Database to Protect with AlwaysOn

Now using SQL Server Management Studio establish a connection to the clustered SQL instance

SCOM\SCOM. Open a New SQL Query and create a new blank database with the syntax create

database sql_guide. This is required because the AlwaysOn Availability Group cannot be created

without a database to make Highly Available.

Once the database is created, we must take an initial Full backup of it. This is required because the

database is set to Full Recovery Model (required for AlwaysOn protection).

54

Make a full backup of this DB

55

As the database is the blank sql_guide database we created earlier, this completes in a second or two.

3.6 Create the AlwaysOn Seed Share

The next step in the process for configuring AlwaysOn is to setup the AlwaysOn seed share. This share

is used by the AlwaysOn High Availability wizard to perform the initial data synchronization. This share

must be accessible by all servers and nodes which will participate in the AlwaysOn configuration.

56

Once you have created a new folder for the share, use the Advanced Sharing tab on the folder

properties to enable sharing of the folder, and edit the permissions. We need to grant the service

accounts used to operate the SQL Server Database Engine instance and the service account used for

the SQL Server Agent to the share using the Full Control Allow permission.

Once you have enabled the share and set the share permissions, the same permissions need to be

applied to the NTFS folder. Use the Security tab on the folder to add the NTFS ACEs for the same

service accounts, the SQL Server Database Engine and the SQL Server Agent service accounts.

57

3.7 Creating an AlwaysOn Availability Group

Once all of the above is done, we’re ready to start the AlwaysOn Availability Group wizard. From the

server which you want to be used as the initial primary replica (probably the clustered instance), login to

SQL Server Management Studio.

Right-click on the AlwaysOn High Availability folder and select the New Availability Group Wizard

option.

58

After the introductory step, we are asked what to use as the Availability Group Name. This name will be

added to the Windows Failover Cluster as a new Resource Group with a Virtual IP Address and a

Network Name which will be used going forwards as the network name for our client and application

connections to the database instance.

59

Next, select the databases to protect with AlwaysOn. As this is a new instance with only our sql_guide

database, select this. If you omitted the steps earlier to take a backup of the database, you will not be

able to proceed past this point until it has been done.

With our database now selected, we need to get the clustered SQL Server instance and the standalone

instance talking. Click the Add Replica button and you will be presented with a SQL Server login

dialog. Enter the server and instance name (SQL3\SCOM in this example) and login with Windows

Authentication using your current credentials.

60

On the Endpoints tab, you should see the name Hadr_endpoint and the Port Number 5022 shown. If

these look familiar, good. These are the ports and names we specified earlier using the PowerShell

Cmdlets.

On the Backup Preferences tab you can configure how SQL Server databases on this instance will be

backed up. The default option is Prefer Secondary which is ideal as it allows our primary to continue

servicing client and applications requests for database records while a backup runs from our replica on

the secondary.

61

On the Listener tab we configure the DNS Name (Network Name) which will be configured and the IP

Address and TCP Port. In this example, SCOMAO is the network name, 15100 is the TCP Port and a

Static IP Address of 10.1.10.211 has been defined.

62

Once you have moved on to the Data Synchronization panel, ensure that the Full option is selected to

get things going immediately. Here we specify the path to the file share created earlier through which

the initial synchronization is performed.

64

After the summary, SQL Server will setup the Availability Group and make the sql_guide database

highly available for the SCOM instance.

Repeat the steps given in the Creating a Blank Database to Protect with

AlwaysOn and the Creating an AlwaysOn Availability Group sections for your

SCOM Data Warehouse instance.

65

3.8 Deploying SCOM into the AlwaysOn Availability Group

Now when it comes to installing a System Center product database into the AlwaysOn Availability

Group, we need to point the setup to the AlwaysOn listener (SCOMAO in my case) and not the

clustered SQL Server instance name. The same process applies to all SC product installations.

66

Assuming your SCOM installation completes without a hiccup or an issue, you’ve now got SCOM

installed and configured to use the AlwaysOn Listener name which means it’s setup to use AlwaysOn

however SQL itself isn’t quite ready so we need to dive back into SQL to make the SCOM and SCOM

Data Warehouse databases highly available.

3.9 Adding the SCOM Databases to the Availability Group

With SCOM now installed, we’re using our AlwaysOn Listener to connect to the SQL Server however

the SCOM database isn’t being replicated throughout the AlwaysOn configuration currently.

Connect to your SQL Server which is currently the Primary for the Availability Group. You can verify

the primary or secondary status from the AlwaysOn High Availability folder in the SQL Server

Management Studio.

67

Once connected and verified that you are connected to the Primary, we need to make changes to the

SCOM database.

Expand the Databases folder and access the Properties for the OperationsManager database.

From the Recovery Model drop-down menu, change the option from Simple to Full as required by

AlwaysOn.

With the Recovery Model now set, we need to take a full backup of the database before processing

with the AlwaysOn wizards.

68

With the database now ready, return to the AlwaysOn High Availability folder and right-click the

SCOMAO Availability Group name and select the Add Database option from the menu.

69

This will open the Add Database to Availability Group wizard.

On the Select Databases pane, you will see the sql_guide databases already a part of the availability

group and the OperationsManager database should report the status of Meets prerequisites.

Select the check box for the OperationsManager database and hit Next.

On the Select Data Synchronization pane, leave the default option of Full as is and use the same

shared file share which we created earlier in the guide for the initial data transfer.

70

On the Connect to Replicas pane, you don’t need to specify any replicas this time as the connections

are already configured in the Availability Group but you do need to connect to the instance.

Click the Connect button and use Windows Authentication to connect to the remote SQL Server

instance.

On the Validation pane, you should hopefully get green for all of the pre-flight checks.

On the final pane before synchronization begins, the Summary will confirm all of your selections from

the wizard. Select Finish and let the replication begin.

71

All going well, you should get a confirmation that the wizard completed successfully.

Viewing the list of Availability Databases back in the SQL Server Management Studio folder view

should now show the OperationsManager database as per the screen below.

72

Repeat the steps in this section for your SCOM Data Warehouse instance.

Once you have completed this section and repeated the steps against your SCOM Data Warehouse

instance, you’re all set. You’re now using SCOM 2012 R2 with SQL Server 2012 AlwaysOn technology,

protecting your databases across a multi-node, multi-instance SQL cluster and a standalone SQL

server.

73

3.10 Deploying Additional System Center Products

When it comes to deploying the rest of the suite you can present your AlwaysOn instance and

sometimes the port is requested and sometimes it doesn’t. Before we go any further please

understand that SCCM 2012 does not support AlwaysOn, no question. For some time the reason this

was not supported was just that it hadn’t been tested, however as far as I know it has been tested (or

considered) and it has been ruled out by the product group.

SCO looks for the instance and port

And SCSM does not ask for the port it queries the AlwaysOn listener.

75

4.0 HYPER-V REPLICA

Hyper-V Replica (HVR) is a host based Hypervisor centric replication process, it is an in-box feature

from Microsoft and is a fairly simple replication setup. Unfortunately HVR is not supported with other

types of SQL replication. There is no native automated failover like there is with a SQL clustering. So

why might I use HVR and not SQL clustering…

HVR is easy to setup

Its host based so the fabric team can setup and configure it

It's fairly easy to setup

It does not require shared storage

It allows you to protect a SQL server across a WAN link

There is a 1:1 I/O hit on the storage write

If you chose SQL clustering

You get automated failover

It is more complex to setup

You can use clustering with AlwaysOn

It is an application level replication process

We have 2 servers HV1 and HV4

Let's start with HV1 that is going to be the replica target for the VM's, I have added a 500Gb drive

called HVR and I am going to use this as my target location.

78

Now we go to HV4 and select the SQL server, as you can see from the screen below the SQL server is hosting a ton of System Center DB's, it’s not clustered and we want to have some warmish copy of the data

86

4.1 Testing HVR

When you want to test the replication an easy way is to place a file on the desktop and check it go

migrated

87

I am also going to create a new DB called SQL guide

88

Now back on SQL 1 (the replica host I should be able to test the replication, to do that I simply go to re

plication and select "test failover". This will create a new virtual machine with a snapshot of the VHD's.

89

5.0 DEPLOYING SCOM WITH DIFFERENT HA OPTIONS

So we have explored a number of configurations possible when it comes to how you can configure SQL

in terms of HA for the SQL server and for the site where your database or databases might run. So in

this section we are going to walk through the different options for installing SCOM in a multi-site

environment and what considerations you may need to take into account in designing and

implementing your SQL server or servers. SCOM is a great product in the System Center suite to

discuss because a lot of companies require multi-site monitoring and want to have the ability to have a

HA SCOM whereby if they lose a primary date center they want monitoring to failover to a secondary

datacenter or DR site.

We are going to start off with the most basic SCOM deployment and work our way up from there. If you

are a seasoned SCOM pro please excuse the basic nature of

this, but it will be helpful for others to understand where it’s all

building on.

Just in case some of the common abbreviations are not

familiar to you

MG Management Group, the security realm between the MS and the SQL DB MS Management Server, the server that has a writable connection to the SQL DB DB Data Base, the SCOM, monitoring and reporting databases that are hosted by SQL GW Gateway, the SCOM, role that is used in remote locations to forward to a MS MP Management Pack, XML document that holds discoveries, rules, monitors and reports

Firstly we need a management server and a SQL server to host

the SCOM DB. A server we want to monitor has a SCOM agent

loaded on it, and it sends its monitoring data to the

management server and the management server in turns writes

that data to data bases on a SQL server. If we deploy SQL

standard and it is only running to support System Center then

there is no cost for the SQL license.

We will then move on to basic SQL clustering whereby we

cluster the SQL DB on two servers. With Server 2012 the cluster build and on-going management is a

much easier prospect than any other version of Windows.

The other scenarios covered in this chapter are quite advanced and many of them are only possible with

either Server 2012 and or SQL 2012. What is important to keep in mind is that any solution that involves

HA and no single point of failure comes at a price, and usually a high one.

SQL Licensing

Licensing is always a complex

issue with System Center, and it

doesn’t get easier with SQL, that

being said I have been told from

several sources that the no cost

for SQL standard also applies for

clustered instances of SQL

standard only being used to

house System Center DB’s. It

was also confirmed to the MVP

group that you can deploy

SharePoint who’s only purpose if

to house System Center

dashboards and there is no

licensing requirement

90

5.1 Basic SCOM Design

SCOM is installed on a single VM with a SQL

instance on a separate VM.

An agent is installed on a server.

The agent comunicates direct with the

management Server (MS)

The SQL is a stand alone SQL standard edition that comes with the

SCOM licence

©Paul Keely MVP

[email protected]

Important points of note here are:

The agent can connect to the MS across a WAN link

The MS must be located close to the SQL DB where the latency does not exceed 20ms

All the monitoring and reporting data is stored on the SQL DB’s the management server has no

real information (except MP data) on it.

There is no HA or DR in this configuration, lose the SQL server or the MS and all monitoring stops

91

5.2 Distributed Design

Now let’s increase the complexity a little and assume we have 2 locations spread across a WAN link, but

please note we are talking about a WAN link with extended distance, so if you have two physical sites

located a few KM’s from each other with fiber between them then that really doesn’t count. In this example

we have an office in Dublin, Europe and one in NYC US, we are just going to expand on the first example

whereby we have the main data center in Europe, some small satellite sites and then an additional large

data center in the US.

92

Important points of note here are:

We are using a SCOM MS and SQL server in the main EU data center

In the small satellite office where they are only a small number of servers they can connect directly

across the WAN to report to a MS in the main data center

In one of the additional EU data center where we placed an additional MS we consider this a

poor design as the network latency across the WAN is greater than 20ms

In the US data center a GW server is deployed. As the minimum latency between the US and EU

is about 60ms the GW server will collect agent data in the US, compress the data and then forward

it to a MS in the EU

There is no HA or DR in this configuration

GW servers bring a layer of complexity and add an additional server so in small satellite offices a

calculation needs to be made to decide at what point you place a GW server versus just allowing

agents to report across the WAN. Where a small office has a domain controller and a multi role

file and print server adding a GW server may add little to the configuration.

This design is full of single points of failure

The GW server cannot write direct to the SQL DB, and has to proxy to a MS who in turn writes to

the SQL DB.

There is no licensing cost for SQL if we are using SQL standard and it’s just for System Center

93

5.3 Local Site HA

In this configuration we are going to overview basic HA with SCOM in a single site. The reason we are

using a single site is to get the basic tenets of design across, to facilitate a discussion on HA, before we

get into more complex multi-site options.

Important points to note here:

Using two MS’s in a pool allows agents to fail over from one MS to another

Using a SQL cluster the failure of a single SQL node means the MS can fail over to another node

in the cluster

This configuration would be considered a basic HA option as we are still using a single copy of

the data bases.

94

The SQL cluster can be built on SQL standard with no licensing cost

This is a fairly easy setup and configuration and does not have a high admin effort or TCO

Can even be built with no shared storage and can use a iSCSI target on Windows Server

5.4 Multi-Site HA with SQL AlwaysOn

This is a more complex and costly option but allows for multi-site, multi-server failover.

Important points of note here:

We are using a SQL cluster in the main data center, as we are using AlwaysOn in the remote site

we need then need to use SQL Enterprise for all nodes.

95

The 3rd SQL node in the remote site can be used for actions like backup etc.

This is an automated fully supported configuration

We are using double MS’s and GW servers in each site

In this environment we can still monitor under the following situations

o Loss of the production cluster in the primary site

o Loss of both MS’s in the production site

o In the event of the complete loss of the primary site we can still monitor the secondary

data center

This is a reasonably complex configuration with an amount of planning and design necessary

This is a reasonably expensive configuration due to the SQL Enterprise licensing

It would be possible to collocate other databases on the cluster especially other System Center

products and use the cluster as a management cluster

If you locate other products on the 2 node cluster in the primary data center the database does

not necessarily need to take part in the AlwaysOn replication node.

This type of configuration would typically be deployed in a large multi-site environment

This configuration does not require storage replication

You can add more than one location for the backup SQL node

96

5.5 SQL Stretched Cluster

In this example we are using a 2 node cluster using a replicated SAN

Points of note for this configuration:

This design is based on using storage replication from your storage vendor

The SQL cluster is based on 2 nodes one in each location

The SQL cluster needs only SQL Standard

The cluster requires a stretched subnet spanning the two sites

In the event of a failover in terms of the SQL environment the MS in the primary data center needs

to be powered off to force the agents in the primary data center to now a GW server in that data

center

97

It is essential to perform component failure analysis, to understand what happens in the event of

failure of individual infrastructure components. This ensures the supporting team knows what is

required to bring the solution back to operation in all failure scenarios

This is not an easy setup

While there is a reduction in cost for the SQL in terms of not needing/using SQL enterprise, there

is the cost of storage mirroring.

5.6 HA Using Separate Management Groups

In this configuration we are going to deploy two completely separate MG’s in two separate data centers.

All agents will be deployed to both MG’s but we will only focus on the prod instance.

98

Important points of note here:

This configuration uses two completely separate MG’s

All agents are multi-homed sending data to each MG

All MP’s sealed and unsealed need to be in sync in each location

The “secondary” MG can have all agents in maintenance mode

All the SQL can be Standard edition

There is a reasonable level of administrative effort required to keep both systems in synch

It is most likely the lowest cost HA solution covering two sites, requiring the least amount of

licensing effort.

If the production SCOM environment goes down and the DR MG is used there is no way to sync

back reporting and alerting data back to the production MG.

99

5.7 Using Hyper-V Replica

Deploying the SQL servers as VM’s

Points to note about this configuration

The SQL server is running as a VM on a hypervisor that is Server 2012

There is no storage replication needed

There is no stretched VLAN needs

The SQL can run as Standard edition

This is not an overly complex solution

The Hyper-V replica is not overly complex to set up, but does require special configuration to

maintain SQL Server product support & recoverability

10

0

Hyper-V replicas are asynchronous, snapshot based replicas, the shortest interval it is possible

to configure being five minutes

There is a substantial IO hit on the replication

You can replicate the VM to several locations

10

1

6.0 SQL IN AZURE TO SUPPORT SYSTEM CENTER

This section is intended to discuss how to implement your System Center SQL Server instances in

Windows Azure virtual machines (VMs). While many of the guidelines for configuring Microsoft SQL

Server are the same, the architecture of VMs in Windows Azure is quite different. Rather than

duplicating information found elsewhere in this guide, this chapter will serve primarily to clarify those

differences and how to optimize performance for your SQL Server instances hosting databases in

Windows Azure.

With this in mind, this chapter does not aim to teach you Windows Azure Virtual Machines (Windows

Azure IaaS) from the ground up. For training on Windows Azure IaaS, see the “Windows Azure for IT

Pros Jump Start” course on the Microsoft Virtual Academy at

http://www.microsoftvirtualacademy.com/training-courses/windows-azure-for-it-pros-jump-

start#?fbid=8YnntofK5KO

Topics covered in this module include:

Network Connectivity

System Center Support in Windows Azure

VM Configuration

Optimizing SQL Configuration in Windows Azure VMs

High Availability and Disaster Recovery

6.1 Network Connectivity

It is assumed you have network connectivity equivalent to what System Center would have in an on-

premise scenario. Therefore, it is assumed you have Windows Azure and your corporate datacenter

connected in a site-to-site VPN (S2S), enabling Activity Directory authentication. In this configuration,

the Azure virtual network will use your DNS servers for name resolution.

A full discussion of Windows Azure virtual networking and site-to-site VPN is beyond the scope of this

section, but you can learn more with these resources:

For networking configuration (site-to-site VPN):

Windows Azure Virtual Networking (TechNet documentation)

Create a Virtual Network for Site-to-Site Cross-Premises Connectivity

For Active Directory Domain Services (ADDS) in Windows Azure:

Guidelines for Deploying Windows Server Active Directory on Windows Azure Virtual Machines

Install a Replica Active Directory Domain Controller in Windows Azure Virtual Networks

Windows Azure VMs are dynamically addressed and you cannot override this by setting a static address.

Any attempt to do so will result in loss of connectivity to the VM.

http://www.microsoftvirtualacademy.com/training-courses/windows-azure-for-it-pros-jump-start#?fbid=8YnntofK5KO

http://www.microsoftvirtualacademy.com/training-courses/windows-azure-for-it-pros-jump-start#?fbid=8YnntofK5KO

http://msdn.microsoft.com/en-us/library/windowsazure/jj156007.aspx

http://www.windowsazure.com/en-us/documentation/articles/virtual-networks-create-site-to-site-cross-premises-connectivity/

http://msdn.microsoft.com/en-us/library/windowsazure/jj156090.aspx

http://www.windowsazure.com/en-us/documentation/articles/virtual-networks-install-replica-active-directory-domain-controller/

10

2

Virtual machines within a VNet will have a stable private IP address. Azure assigns an IP address from

the address range you specify and offer an infinite DHCP lease on it. So the IP address will stay with

the virtual machine for its lifetime. The exception to this is when a virtual machine is in a Stopped

(Deallocated) state, in which case the IP address is returned to the pool allocated to the virtual network

you defined. You should avoid placing production VMs in this state to prevent an unwanted IP address

change.

6.2 System Center Support in Windows Azure

Most System Center 2012 components can be virtualized in Windows Azure. The System Center 2012

SP1 and later components are supported in Windows Azure are:

App Controller

Operations Manager

Orchestrator

Server Application Virtualization

Service Manager

You will notice that Virtual Machine Manager is not mentioned is not listed, which is not surprising,

given VMM manages the hypervisor….a layer not under our control in Windows Azure.

For a current list of System Center and Windows component support in Windows Azure, see

http://support.microsoft.com/kb/2721672

6.3 VM Configuration

The considerations for SQL Server running in Windows Azure VMs are largely due to differences in

Windows Azure VM and platform architecture versus that of Hyper-V and vSphere. Considerations

include:

VM Sizing

Network Throughput

Disk Subsystem

Database File Placement

However, some aspects of VM architecture in Azure differ from the Hyper-V or VMware equivalents and

therefore will be addressed in this chapter.

http://support.microsoft.com/kb/2721672

10

3

6.4 VM Sizing

The first rule of virtualizing SQL Server is to ensure you have enough compute, storage and compute

resources to match what you used in the physical server. If you review Microsoft documentation around

Windows Azure VMs, the documentation says “Review options and choose a size that matches the

workload”. In Windows Azure, you cannot simply set the CPU cores and memory to exactly the values

you wish. Instead, you must choose one of the available VM template sizes. Even if you upload one of

your own Hyper-V VM templates to Azure, you will have to choose one of these template sizes. There

are currently eight (8) VM templates in Windows Azure, which are shown here.

Based on your desired VM size, you should pick the VM that most closely matches that of your sizing.

The right template may have a slightly more or slightly less resources (in terms of CPU and memory)

than what you would have chosen in an on-premise situation. Since Windows Azure costs are

calculated on a pay-for-what-you-use basis, be sure not to choose a larger VM than necessary!

6.5 Network Bandwidth

Your measure of control over network bandwidth in Windows Azure is based largely on the VM size you

choose. Every virtual machine size has its own limits in terms of network traffic that goes through the

Windows Azure Virtual Network layer. This network traffic also includes all traffic between client

applications and SQL Server in a Windows Azure VM and, any other communication that involves a

SQL Server process, or other processes in a virtual machine, such as ETL packages or backup and

restore operations. Microsoft recommends that you choose a larger virtual machine size with more

network bandwidth. In the word of System Center, SQL Server roles that fall into this category would

include SCCM, SCOM and SCSM database and data warehouse servers.

The bottom line is the CPU and memory resources available in VM templates will almost certainly be

the driver of your decision, and the larger VM sizes provide greater bandwidth.

http://www.windowsazure.com/en-us/manage/services/networking/

10

4

Important: Network communications generated by accessing data disks and the operating system disk

attached to the virtual machine are not considered part of the bandwidth limits.

6.6 Disk Types and Configurations

Proper configuration of your Windows Azure disks (operating system and data) is one of the most

important areas to focus on when optimizing the performance of your SQL Server workloads supporting

your System Center 2012 R2 deployment. This section will cover some basic concepts of disk behavior,

performance and configuration relevant to SQL Server instances hosted in Windows Azure VMs.

Windows Azure Virtual Machines provide three types of disks:

Operating system disk (persistent): Every virtual machine has one attached operating system

disk (C: drive) that has a limit of 127 GB. You can upload a virtual hard disk (VHD) that can be used

as an operating system disk, or you can create a virtual machine from a platform image, in which

case an operating system disk is created for you. An operating system disk contains a bootable

operating system. It is mostly dedicated to operating system usage and its performance is optimized

for operating system access patterns such as boot up.

Data disk (persistent): A data disk is a VHD that you can attach to a virtual machine to store

application data. Currently, the largest single data disk is 1 terabyte (TB) in size. You can specify

the disk size and add more data disks (up to 16, depending upon virtual machine size). This is

useful when the expected database size exceeds the 1 TB limit or the throughput is higher than

what one data disk can provide. Data disks are where your SQL database, log files and SQL

application files will reside.

Temporary local disk (non-persistent): Each virtual machine that you create has a temporary

local disk, the D: drive and which is labeled as TEMPORARY STORAGE. This disk is used by

applications and processes that run in the virtual machine for transient storage of data. It is also

used to store page files for the operating system. Temporary disk volumes are hosted in the local

disks on the physical machine that runs your virtual machine (VM). Temporary disk volumes are not

persistent. In other words, any data on them may be lost if your virtual machine is restarted.

Temporary disk volumes are shared across all other VMs running on the same host.

Each data disk can be a maximum of 1 TB in size. Depending upon your virtual machine size, you can

attach up to 16 data disks to your virtual machine. I/Os per second (IOPS) and bandwidth are the most

important factors to consider when determining how many data disks you need. Storage capacity

planning is similar to the traditional ‘spindle’ count in an on-premises storage design. A single Azure

data disk delivers approximately 500 IOPS, and you can have up to 16 data disks in a single Azure

storage account. Disk configuration and sizing for I/O is covered in "Optimizing SQL Configuration in

Windows Azure VMs" later in this chapter.

6.6.1 HIGH AVAILABILITY DISKS As of this writing, Windows Azure Storage guarantees in its Service Level Agreements that at least 99.9%

of the time, storage blobs will be available. Using a single data disk simplifies recovery scenarios in case

of temporary unavailability. For example, if you want to leverage geo-replication at the Storage Account

https://www.windowsazure.com/en-us/support/legal/sla/

10

5

level to automatically replicate your data disk to a secondary region, using a single data disk can be

helpful.

IMPORTANT: You cannot use geo-replication with multiple data disks configurations, because consistent

write order across multiple disks is not guaranteed.

6.6.2 DISK CACHE SETTINGS IN WINDOWS AZURE VIRTUAL MACHINES In Windows Azure virtual machines, data of persisted drives is cached locally to the host machine,

which brings the data closer to the virtual machine. Windows Azure disks (operating system and data)

use a two-tier cache:

Frequently accessed data is stored in the memory (RAM) of the host machine.

Less recently accessed data is stored on the local hard disks of the host machine. There

is cache space reserved for each virtual machine operating system and data disks based

on the virtual machine size.

Cache settings help reduce the number of transactions against Windows Azure Storage and can

reduce disk I/O latency in some scenarios. Windows Azure disks support three different cache settings:

Read Only, Read Write, and None (disabled). There is no configuration available to control the size of

the cache.

Read Only: Reads and writes are cached for future reads. All writes are persisted

directly to Windows Azure Storage to prevent data loss or data corruption while still

enabling read cache.

Read Write: Reads and writes are cached for future reads. Non-write-through writes are

persisted to the local cache first, then lazily flushed to the Windows Azure Blob service.

For SQL Server, writes are always persisted to Windows Azure Storage because it uses

write-through. This cache setting offers the lowest disk latency for light workloads. It is

recommended for the operating system and data disks with sporadic disk access. Note

that total workload should not frequently exceed the performance of the physical host

local disks when this cache setting is used.

None (disabled): Requests bypass the cache completely. All disk transfers are

completed against Windows Azure Storage. This cache setting prevents the physical

host local disks from becoming a bottleneck. It offers the highest I/O rate for I/O intensive

workloads. Note that I/O operations to Windows Azure Storage do incur transaction

costs but I/O operations to the local cache do not.

The following table demonstrates the supported disk cache modes:

Disk type Read Only Read Write None (disabled)

Operating system disk Supported Default mode Not supported

Data disk Supported Supported Default mode

Important notes:

Cache can be enabled for up to 4 data disks per virtual machine (VM).

10

6

Changes to caching require a VM restart to take effect.

6.6.3 ENABLING READ WRITE CACHE FOR THE OS DISK Enabling “Read Write” cache (default setting) for the operating system disk helps improve overall

operating system performance and boot times. Also, it can help reduce the read latency for workloads

with smaller databases (10 GB or smaller) that require a low number of concurrent read I/Os. This is

because the working set can fit into the disk cache or the memory, reducing trips to the backend Blob

storage.

Since “Read Write” cache is enabled by default, no action is typically needed here. Just don’t disable this

setting without good reason!

6.7 Optimizing SQL Configuration in Windows Azure VMs

Since storage architecture in Windows Azure is much different than what you may be familiar with in the

data center, guidance on scaling storage IOPS for SQL databases and logs is provided in this section.

6.8 Use Data Disks for SQL DB Files

For databases larger than 10 GB, Microsoft recommends that you use data disks. For data disks, the

recommended cache setting depends on the I/O pattern and intensity of the workload.

If the workload demands a high rate of random I/Os (such as a SQL Server OLTP workload) and

throughput is important to you, the general guideline is to keep the cache set to the default value of

“None” (disabled). Because Windows Azure storage is capable of more IOPS than a direct attached

storage disk, this setting causes the physical host local disks to be bypassed, therefore providing the

highest I/O rate. This is the setting that will apply to your larger System Center databases, including;

Configuration Manager Site DB

Operations Manager operational DB and data warehouse

Service Manager database and data warehouse

For smaller databases with typically lower IO, including Orchestrator and App Controller, you may

consider placing them on an existing SQL instance, but still placing the database files on a data disk is

recommended.

While the VMM database typically falls into the “small with low I/O category, VMM is not supported in

Windows Azure VMs and therefore is not applicable to this discussion.

The same rules apply for TempDB when running SQL in Azure VMs. TempDB should be placed on the

operating system disk or a separate data disk (preferably a data disk if possible). Do not be tempted to

place this database on a temporary disk!

IMPORTANT: Using files and filegroups across multiple data disks does not help scaling transaction log

throughput and bandwidth (sequential writes) in the same way it does for random IO activity. If you need

to scale your transaction log performance, MS recommends use a striped volume instead, such as

10

7

Storage Spaces in Windows Server 2012 R2. For step-by-step guidance in using this technology in

Windows Azure, see “Use Windows Azure to learn Windows Server 2012 Storage Spaces”.

NOTE: With regards to Windows Azure disk performance, you may read that Microsoft have observed

a “warm-up effect” that can result in a reduced rate of throughput and bandwidth for a short period of

time. In situations where a data disk is not accessed for a period of time (approximately 20 minutes),

adaptive partitioning and load balancing mechanisms kick in. This warm-up effect is unlikely to be

noticed on systems with workloads in continuous use, such as System Center SQL instances.

6.9 Disk IOPS in Azure Virtual Machines

A single Azure data disk delivers approximately 500 IOPS. In order to achieve higher levels of I/O, you

will need to spread the database across multiple files. For example, for a database requiring 2,000

IOPS, you would need to spread the database across four (4) data disks, for 4,000 IOPS you would

need eight (8) data disks, etc. You can have up to 16 disks in a single Azure storage account, for a total

of 8,000 IOPS for a single Azure storage account. This is enough to meet the needs of virtually any

single System Center SQL instance you are likely to encounter.

For write intensive workloads (which is descriptive of the System Center SQL instances), adding more

data disks increases performance in a nearly linear fashion according to Microsoft testing.

For a sample T-SQL script for splitting (striping) a SQL database into multiple files on multiple drives, see

“Create Database (Transact SQL)” at http://msdn.microsoft.com/en-US/library/ms176061.aspx.

To update an existing database to stripe the database across multiple files, you will need to use the

ALTER DATABASE statement with the FILE option. T-SQL samples are available at

http://msdn.microsoft.com/en-us/library/bb522469.aspx.

IMPORTANT: While you could potentially scale beyond the 4,000 IOPS limit of disks in a single storage

account by attaching disks from multiple storage accounts, Microsoft recommends avoiding this if

possible. Attaching data disk from multiple Azure storage accounts increases complexity and the

likelihood of data consistency issues in some failure scenarios.

6.10 Autogrow Settings

With regards to the Autogrow setting, the same rules you observe on physical or virtual machines in your

data center also apply in Windows Azure.

6.11 High Availability & Disaster Recovery (HADR)

The following HADR technologies in SQL Server are supported in Windows Azure:

AlwaysOn Availability Groups

Database Mirroring

Log Shipping

http://blogs.technet.com/b/kevinremde/archive/2013/01/27/use-windows-azure-to-learn-windows-server-2012-storage-spaces-31-days-of-servers-in-the-cloud-part-27-of-31.aspx

http://msdn.microsoft.com/en-US/library/ms176061.aspx

http://msdn.microsoft.com/en-us/library/bb522469.aspx

10

8

Backup and Restore with Windows Azure Blob Storage Service

It is possible to not only to use these technologies in Windows Azure, but to combine them to

implement a SQL Server solution that has both high availability and disaster recovery capabilities,

whether in a private cloud, public cloud or hybrid cloud environment. Depending on the technology you

use, a hybrid cloud deployment option may require a site-to-site VPN tunnel with the Windows Azure

virtual network.

For step-by-step guidance in implementing these SQL Server HADR technologies, see the following

tutorials:

AlwaysOn Availability Groups - see Tutorial: AlwaysOn Availability Groups in Windows Azure

(GUI)

Database Mirroring - see Tutorial: Database Mirroring for High Availability in Windows Azure

Log Shipping - see Tutorial: Log Shipping for Disaster Recovery in Hybrid IT

Backup and Restore with Windows Azure Blob Storage Service - see Backup and Restore

for SQL Server in Windows Azure Virtual Machines

For additional reading on the currently available options and example HADR architectures for SQL

Server 2012 in Windows Azure virtual machines, see

High Availability and Disaster Recovery for SQL Server in Windows Azure Virtual Machines

http://msdn.microsoft.com/en-US/library/windowsazure/dn249504.aspx


http://msdn.microsoft.com/en-US/library/windowsazure/jj870961.aspx

http://msdn.microsoft.com/en-US/library/windowsazure/jj889442.aspx



http://msdn.microsoft.com/library/windowsazure/jj870962.aspx

10

9

7.0 BACKING UP SQL WITH DPM

7.1 Introduction to System Center Data Protection Manager 2012 R2

System Center Data Protection Manager 2012 R2 (SCDPM or DPM) is Microsoft’s answer for how you

should take backups, perform restores and manage disaster recovery in a modern datacenter. The key

selling point of the product is the ease with which advanced backup & restore operations can be

performed. Microsoft have developed System Center Data Protection Manager to be the best of breed

recovery software for the most common Microsoft enterprise workloads.

7.2 What Can DPM 2012 R2 Protect?

As mentioned in the introduction, SCDPM or DPM is a backup & recovery application with the main

focus being on delivering advanced restore operations with high performance. SCDPM will protect and

restore the following Microsoft workloads:

1. File Services

2. Hyper-V

3. Exchange Server

4. SQL Server

5. SharePoint Server

6. Windows Servers in trusted domains, untrusted domains & Microsoft workgroups

7. Windows Clients

8. System State

System Center Data Protection Manager 2012 R2 will also protect any Windows Failover Server

Cluster based solution, being a cluster-aware backup product.

7.3 Change Tracking

System Center Data Protection Manager 2012 R2 is a true Continuous Data Protection (CDP) product,

meaning that it has a sophisticated change level tracking process. The change tracking process could

most easily be described as identifying block level changes on the actual disk or volume via close co-

operation between the DPM agent, DPM server and Volume Shadow Copy Services (VSS) with VSS

coordinating the interaction between the DPM agent, the VSS Writer and Minifilter drivers on the

protected host.

11

0

7.4 Getting Started with DPM

After you have installed System Center Data Protection Manager 2012 R2 you will need to perform

some additional steps:

1. Add disk to the DPM disk pool

2. Deploy or in a pre-deployed scenario attach the DPM agents

3. Create a Protection Group

For a full installation guide and further useful information regarding DPM please visit the blog “Robert

and DPM” at http://robertanddpm.blogspot.com/.

7.5 Adding Disk to the DPM Storage Pool

The DPM server requires locally attached disk to store all its recovery points for the protected data it

stores. The following types are supported:

1. SAN

2. NAS

3. DAS

4. VHDX

For further information and guidelines regarding how to design and deploy DPM please visit ‘Robert

and DPM’ at http://robertanddpm.blogspot.com/ or read the ‘DPM 2012 R2 Cookbook’ which will be

released during 2014 by Packt Publishing.

7.6 Deploying DPM Agents

For SCDPM to be able to commence protection of your workloads within your datacenter you must

install and attach a SCDPM agent. This process is also known as deploying a DPM agent.

This can be done from the DPM console but also other System Center components such as System

Center Configuration Manager or System Center Orchestrator. You can also use simple batch files and

GPOs within Active Directory to deploy the agent.

7.7 DPMDB

The most critical part of the SCDPM server platform is the local database, called DPMDB. All

configurations made for Protection Groups, SCDPM agent deployment & backup schedules are stored

within the DPMD. In a high-end implementation of SCDPM it is strongly recommended to place the

DPMDB on a dedicated volume that has the correct sector sizes to ensure high performance and

scalability. The recommended NTFS unit allocation size is 64 Kb since this is matches SQL write

patterns.

The location of the DPMDB database on disk can be specified two ways:

http://robertanddpm.blogspot.com/

http://robertanddpm.blogspot.com/

11

1

1. As a configuration option during the installation of the DPM software

2. As a re-configuration, performed at any later time, using SQL Management Studio

The recommended option is to place the DPMDB on the correct volume during the installation of the

software, to minimize rework.

7.8 Special Considerations for Using DPM to Protect SQL Workloads

In this section we will discuss arguably the most important element of data protection software: The

considerations surrounding restoring of data. All backups are made with one purpose, to be able to be

restored within an organization’s accepted timeframe. We will also discuss why you shouldn’t run local

backups and how you manage SQL management tasks that execute at the same time of the backup.

7.8.1 RPO, RTO AND RLO To be able to identify an organization’s accepted timeframe for data loss you must have an

understanding of the Service Level Agreement (SLA). The SLA will explain how the companies

perceives & classifies it’s most important services. In those cases where there is not a SLA in place,

you must initially start by classifying your data that represents the services within your datacenter.

7.8.2 RECOVERY POINT OBJECTIVES The Recovery Point Objectives are an organization’s way of defining how much data they can afford to

lose during an incident. It is the maximum tolerable period in which data might be lost from an IT

service due to a major incident.

7.8.3 RECOVERY TIME OBJECTIVES The Recovery Time Objectives are an organization’s way of defining how fast they must be able to

bring the services online when an incident has occurred. In those cases a service has a value of zero

(0) the company must deliver the application via some sort of clustering service. Clustering itself

however does not guarantee safety of an organization’s data. One must still consider corrupted data

scenarios, for example users deleting the wrong data or the occurrence of an unwanted malware

intrusion. A combination of cluster and backup is the right way of managing an organization’s most

significant workloads. Clustering services will be used to provide High Availability and a backup

solution, such as SCDPM, will be used to provide the last line of data protection.

7.8.4 RECOVERY LEVEL OBJECTIVES The Recovery Level Objectives are a means of defining the level of data an organization must be able

to restore in the event of data loss. An example of this is the SharePoint workload, the RLO will define

the granularity of the wished restore for the workload. For example company A must be able to restore

the total SharePoint farm but the company B must be able to restore item-level-restore in form of sites,

lists or documents.

7.8.5 LOCAL SQL BACKUPS Many database administrators (DBA) uses local backup jobs that they configure in the SQL

Management Studio. There are advantages and disadvantages inherent to this method.

If you use SCDPM you will gain:

11

2

A centralized console that will keep track of all your backups of your SQL workloads present in

your datacenter.

The ability to monitor backup alerts produced by SCDPM in SCOM.

A means of automating backup alerts and auto-heal broken backups via SCO.

7.8.6 SQL MAINTENANCE TASKS An important part of being a SQL database admin or DBA is to keep the SQL databases in an optimal

functioning state. As maintenance plans are running in your SQL server environment, SCDPM will

understand the execution state of the maintenance plans and still be able to make a valid snapshot of

your SQL server data.

7.8.7 SQL MANAGEMENT TASKS At some points in time, the database administrators or DBA’s will need to perform SQL Management

tasks. In this section we will present the most common activities and outline how they will impact the

protection of SQL via DPM

7.8.8 MOVING SQL SERVER BETWEEN DOMAINS If the DBA moves a SQL server to another domain, System Center Data Protection Manager 2012 R2

will not be able to continue to protect SQL databases hosted on that server without intervention from

the DPM administrator. There are three ways of protecting a SQL Server database in an untrusted

domain:

Establish a two-way transitive trust between the domains: The author would not casually

recommend this approach due to security considerations.

Using Workgroup protection: This will not protect any clustered or mirrored databases

Using Certificate Based Authentication (CBA): This will also protect clustered SQL databases

7.8.9 RENAMING A COMPUTER RUNNING SQL SERVER If a DBA renames a DPM protected SQL Server, System Center Data Protection Manager 2012 R2 will

no longer continue to protect the SQL Server or its databases. If the DBA needs to perform this activity,

significant amount of planning needs to be performed. The DPM administrator must stop protecting all

data sources including SQL, System State & File System and then they must uninstall the DPM agent.

After the DBA has renamed the SQL Server the DPM administrator can reinstall the DPM agent and

recreate the Protection Group on the DPM server containing the SQL databases.

7.8.10 CHANGING THE RECOVERY MODEL OF A DATABASE If the DBA wishes to change the recovery model of a SQL Server database, the DPM administrator

needs to stop the protection, but may elect to retain previous backups on the DPM server. The DBA

can then change the recovery model. Following the configuration change, the DPM administrator can

reconfigure SCDPM protection for the SQL database.

7.8.11 REPLACING A DISK ON A SQL SERVER In the scenario that a disk fails that contains protected SQL Server databases the DBA must use the

same drive letter for the new disk that was assigned to the old disk. System Center Data Protection

Manager 2012 R2 can then restore protected data to the new disk.

11

3

7.8.12 ADDING DATABASES TO A SQL SERVER If the DBA adds a database to an instance of SQL that is protected, the database is not by default

included in the DPM protection group. This could be accomplished by using the auto-protection

configuration. For the DPM administrator to use the auto-protection method you must protect all the

databases within that instance.

7.8.13 CHANGING THE PATH OF A SQL SERVER DATABASE If the DBA changes the path of a protected SQL Server database, an alert is raised in the DPM

console. To continue protecting the database files in their new location, the DPM administrator must

stop protection of and re-establish protection of the SQL Server databases.

7.8.14 RENAMING A SQL SERVER DATABASE If the DBA renames a SQL database the DPM protection will fail. For System Center Data Protection

Manager 2012 R2 to be able to protect the renamed database the DPM administrator must include the

“new” database in a present Protection Group or create a new.

7.8.15 PARALLEL BACKUPS System Center Data Protection Manager 2012 R2 can run parallel backups for protected data sources

to optimize the network load. Due to limitations in the SQL Server software System Center Data

Protection Manager 2012 R2 cannot leverage this feature.

7.8.16 AUTO-PROTECTION OF SQL INSTANCES System Center Data Protection Manager 2012 R2 has the ability to auto-protect all SQL databases

present in an instance. This feature will include any newly added databases but not remove exiting

backups for SQL databases that are removed from the SQL Server instance by the DBA.

As a DPM administrator you can’t be selective with this behavior if you would like to exclude some SQL

databases from the auto-protection. If you enable this feature, System Center Data Protection Manager

2012 R2 dos it for all databases within the SQL Server instance.

11

4

To enable the Auto-Protection for a SQL Server instance you check the checkbox next to the SQL

Server instance name. A text (Auto) will appear in front of the SQL Server instance name and then you

know that the Auto-Protection feature is enabled.

7.8.17 CO-LOCATION FOR LARGE SCALE SQL SERVER IMPLEMENTATIONS In a large scale environment the number of SQL Server databases that need to be protected could be

very high. Since System Center Data Protection Manager 2012 R2 includes a feature that will allow you

to protect a larger number of SQL Server databases the actual number of DPM server that needs to be

deployed will decrease during the planning phase of the DPM design for SQL Server database

protection.

By collocating the replica volumes in the DPM disk pool the number of possible protectable SQL Server

databases will increase from approximately 1,000 to 2,000 SQL Server databases. Now keep in mind

that this is a theoretical number meaning that the size of the databases will also play an important role.

The best way to find out how many databases a DPM server can protect is to begin to calculate the

sizes of the databases. More information regarding this can be found on the blog

http://robertanddpm.blogspot.se

http://robertanddpm.blogspot.se/

11

5

7.9 Windows Azure

System Center Data Protection Manager 2012 R2 can connect to the Windows Azure Backup Service

to provide off-site archiving for up to 120 days. The supported workloads to be archived into Azure are:

SQL Server databases

Hyper-V servers

File Services file data

For more information regarding how to enable Windows Azure online protection read the Configuring

Protection Groups for SQL Server section.

7.10 Pre-Configuration

In this part of the chapter you will get both a walkthrough of how to setup a protection group and also

special pre-configuration tasks that may need to be performed dependent on your version of SQL

Server.

7.11 SQL Recovery Models

As you probably are familiar with there are different recovery models for a SQL database. For SQL

Server 2012 the available recovery model options are:

SIMPLE

FULL

BULK-LOGGED

The major difference between the SQL database recovery models are that FULL and BULK-LOGGED

recovery models works with transaction logs whereas a database configured with SIMPLE recovery

mode does not use transaction logs. Since System Center Data Protection Manager can interrogate

SQL Server and see what recovery model a database is configured to use, System Center Data

Protection Manager 2012 R2 will provide the appropriate restore options permissible for the given

recovery model.

7.12 Supported SQL Server Versions

System Center Data Protection Manager 2012 R2 can protect the following version of SQL Server:

SQL Server 2012

SQL Server 2008 R2

SQL Server 2008

11

6

7.13 SQL Clusters

System Center Data Protection Manger 2012 R2 protects a SQL Server failover cluster in a fully

supported manner. On a planned failover System Center Data Protection Manager 2012 R2 will

continue protection of a SQL Server workload and understand the new node ownership, continuing to

provide an optimal and fully supported backup of the SQL Server workload.

In the scenario where a SQL Server failover cluster is performing an unplanned failover in response to

a failure, the DPM server will generate an alert to indicate that a consistency check needs to be

performed. This results in an inconsistent replica. Replica inconsistency can remember, be easily

resolved using the built-in auto-heal function. If you don’t want to wait three hours for the auto-heal

function to trigger you can alternatively create a Runbook in System Center Orchestrator 2012 R2 and

clear any replica of a data source that is inconsistent.

For System Center Data Protection Manager 2012 R2 to be able to protect a SQL Server failover

cluster built on the supported protectable versions of SQL Server a DPM agent must be deployed to all

servers participating in the failover cluster.

7.13.1 ADDING SQL CLUSTER MEMBERS In the scenario where the SQL Server failover cluster is expanded with additional nodes the DPM

administrator will be presented with an alert stating that the new cluster nodes must have a DPM agent

installed to them for System Center Data Protection Manager 2012 R2 to be able to protect the cluster.

The deployment of DPM agents can be automated for a modern dynamic datacenter by combining the

power of System Center Data Protection Manger 2012 R2, System Center Operations Manager 2012

R2 and System Center Orchestrator 2012 R2.

7.13.2 REMOVING SQL CLUSTER MEMBERS In the scenario where a SQL Server cluster member has reached end-of-life and needs to be retired

System Center Data Protection Manager 2012 R2 will understand this and will alert the DPM

administrator that the cluster node is no longer a member of the SQL Server cluster.

7.14 Mirrored SQL Servers

System Center Data Protection Manager 2012 R2 can protect mirrored SQL Server database clusters

but there are some considerations that you must apply before configuring the protection:

Be sure to install the DPM agent on both partners of the mirror

Do not mirror the database on the same computer

As mentioned System Center Data Protection Manager 2012 R2 will also be able to protect a mirrored

SQL Server cluster. System Center Data Protection Manager 2012 R2 will be able to protect the

following configurations:

Principal is clustered, mirror in not clustered

Principal is not clustered, mirror is clustered

Both principal and mirror are clustered

11

7

7.15 Unsupported Scenarios

The following scenarios are not supported for SQL Server mirrored database:

If the database is mirrored on the same SQL Server

If the SQL Server mirroring session uses an explicitly configured IP address

If the Always-On feature in SQL Server 2012 is turned on

7.16 Specific SQL Server Configurations

For System Center Data Protection Manager 2012 R2 to be able to protect SQL Server 2012 there are

some special configurations that needs to be made on the SQL Server side. When you initially start to

protect SQL Server 2012, the DPM server will raise an alert saying that the DPM server was “Unable to

configure protection” as shown in the below picture.

As you also can see System Center Data Protection Manager 2012 R2 will also provide you with the

information of what you should do to get this up and running. You must provide the DPMRA service

sysadmin rights on the SQL Server instance that the database resides in.

7.16.1 CONFIGURATION WALKTHOUGH For System Center Data Protection Manager 2012 R2 to be able to protect a SQL Server 2012

database you need grant the DPMRA service sysadmin privileges on the SQL Server instance. This is

a walkthrough of the configuration.

Open the SQL Server 2012 Management Studio and log on to the instance that contains the databases

that you would like to protect using System Center Data Protection Manager 2012 R2.

11

8

Create a New Login… by right click the Logins folder.

Add the NT SERVICE\DPMRA account under the Login name. You can also search for it by clicking

the Search… button on the right side of the Login name field.

11

9

Click on Server Roles page on the left side of the window and add the sysadmin rights for DPMRA.

12

0

When you now execute the Configure New Protection Group job again in System Center Data

Protection Manager 2012 R2 you will now be able to protect the SQL Server 2012 databases.

12

1

7.17 Configuring Protection Groups for SQL Server

For System Center Data Protection Manager 2012 R2 to be able to start protect a SQL Server, you

need to create a Protection Group. A Protection Group is a set of instructions that will provide the DPM

agent with the backup schedule and workload information for a successful backup.

To configure a Protection Group you click on the New button in the top left part of the DPM console.

You will be presented with a Welcome screen, click Next >.

You now need to choose if you want to protect Servers or Clients. Select Servers and click Next >.

12

2

Now it’s time to choose Group Members of the Protection Group.

12

3

In this example I will expand the server SCSQL and all the present workloads will be presented.

12

4

Expand All SQL Servers and all SQL Server Instances will be displayed.

12

5

Now you have two choices, you can:

Protect specific databases

Enable auto-protection for an instance

Mark the instance to enable auto-protection or choose a specific database for protection. Choose your

database and click on Next >.

12

6

You will now choose the way you want to protect your workload, for SQL servers you can choose:

Shot-term protection using disk, it’s not a recommendation to use tape though it’s a possible

approach.

Online protection using Azure

Long-term protection using tape

In this example we will mark Short-term protection for on-premise restore operations and Azure for long

term protection (archiving). Click Next > to continue.

12

7

Now you must choose your Short-Term recovery goals. Initially, you should consider for how many

days you wish to store the protected data source recovery points in your DPM disk pool. This is called

Retention Range, the default value is five (5) days.

12

8

Next you must consider the Synchronization frequency by choosing a synchronization interval in the

dropdown list. The last part is to select when Recovery points should be created. By default recovery

points are created at 8 PM every day, to change this click the Modify button.

12

9

Now you can choose the recovery point times that meet your organizations recovery point objectives

(RPOs). Mark the times and click on the Add > button, also choose the appropriate weekdays for

creating recovery points. When you are done you click on OK.

13

0

Now you will get an updated summary for the sort-term recovery goals, verify it and click Next > to

continue.

13

1

On the Review Disk Allocation step, DPM will present a summary of the actual disk allocation that

need to be made for the workload to be protected according to your recovery point schedule. Please

note the checkbox that says “Automatically grow the volumes”. This is one of System Center Data

Protection Manager 2012 R2 auto-heal functions.

You can alter the disk allocation configuration by clicking the Modify button.

13

2

When you click the Modify button, you will be presented of the actual allocation for the collocated

volumes. You can alter the value that is proposed however if DPM detects that this will not result in a

successful modification you will be prompted with a warning.

13

3

When you are done altering the disk allocation click the OK button and you will return to the Review

Disk Allocation step. Click Next > to continue to the Choose Replica Creation Method step.

13

4

In the Choose Replica Creation Method step you have three different options that will provide you

with suggestions how to create your replica, these are:

Now, replica will be created during the creation of the Protection Group

Later, replica will be scheduled for creation

Manually, replica will be created manually by the DPM administrator

In this guide we will create the replica Now. Click the Next > button to continue.

13

5

The next step is the Consistency check option where you specify another of DPM’s auto-heal

functions called “Run a consistency check if a replica becomes inconsistent”. You can also choose if

the Protection Group you are designing will schedule a daily Consistency Check. This means that

DPM will synchronize any changes from the production workload to the DPM server and making the

replica consistent once again.

When you are finished you click Next > to get to the next step of the configuration.

13

6

In the next step called Specify online protection data you choose which workloads should be

archived to Windows Azure Backup. The supported workloads are:

SQL

Hyper-V

File Services

Check the checkbox for the workload you would like to put in Azure and click on Next >.

13

7

In the Specify Online Protection Goals window, you have two options. You can archive recovery

points every day or on a weekly basis. For the weekly archiving basis see the next screenshot.

13

8

Specify when the DPM server should synchronize the recovery point and click on Next > to continue.

13

9

Verify the configuration in the Summary step and click on the Create Group button.

14

0

In the Status step you will see when the configuration is successfully finished and the Close button will

be clickable. Click Close to end the setup wizard for the Protection Group.

14

1

7.18 Restoring SQL Server Data from DPM

There are three media types that DPM can restore SQL data to:

From disk (Short-term recovery goals)

From Tape or Virtual Tape Library (VTL) (Long-term recovery goals)

From Azure (Cloud)

In this chapter you will be presented with the different restore operations these three different media

types will provide. All operations have the same granularity of restore meaning that you will be able to

restore a single database per restore job.

To restore data from System Center Data Protection Manager 2012 R2 you must click the Restore in

the navigation bar (down left in the console).

With transactional log systems like SQL (recovery model FULL or BULKED-LOGGED only) and

Exchange server you have the possibility to restore the SQL database or Exchange mailbox database

to its last good transaction using the Latest recovery time option. You will only be able to restore the

data to its original location using the Latest restore recovery option.

14

2

If you would like to restore from a valid recovery point click start by choosing the correct date all dates

that contains valid recovery points have bold numbers. Now you must choose a valid Recovery time in

the dropdown list, choose the time that you would like to perform a restore from.

After you have specified the date and time you right-click the database that you would like to restore

and choose Recover.

If you would like to see all of the available recovery points for restore for the data source choose Show

all recovery points.

14

3

7.19 Short-Term Recovery Goals Restore

When restoring from short-term recovery goals (disk) you have the following restore options:

Recover to original instance of SQL Server (Overwrite database)

Recover to any instance of SQL Server

Copy to a network folder

Copy to tape

14

4

7.19.1 RECOVERY TO THE ORIGINAL INSTANCE OF SQL SERVER This recovery type will restore the SQL database to its original location and overwrite the database

files. This option is useful in the case of for example corruption or accidental deletion.

In this recovery type you have two different database states that you can choose:

Leave database operational

Leave database non-operational but be able to restore additional transaction logs

14

5

The second database state mentioned (Leave database non-operational but able to restore additional

transactional logs) will make it possible to restore additional log file data. These additional transaction

log must be in a folder on the original SQL Server.

7.19.2 RECOVERY TO ANY INSTANCE OF SQL SERVER This recovery type will make it possible to restore the database to any instance of a SQL Server that

has a DPM Agent installed and attached to the DPM server when another protected database exists in

that instance This option will give you the possibility to restore SQL databases to any SQL Server

instance and also makes it possible to restore 2008 SQL server databases to SQL Server 2012

instances.

14

6

Browse the network and select the SQL Server that you would like to restore the database to. You

have the ability to change the database alias so that you are able to restore the database to its original

SQL Server but with a different database name. One important consideration regarding the latter option

is that a new location for the database files must be specified since this recovery type does not

overwrite any existing database files.

7.19.3 COPY TO NETWORK FOLDER When a DPM administrator need to restore a database to a network folder for the DBA so he or she

can perform additional testing before manually restore the database in production there is one

important thing to keep in mind. You can only restore an Express-Full Recovery Point not any

subsequent Synchronizations.

If you have chosen to restore a Synchronization, DPM will prompt you with the following screen:

14

7

Now DPM presents the valid recovery points that you can choose to restore to a network folder. When

you have a valid recovery point you will be prompted to select where to restore the database. You can

restore the files to any server that DPM protects and choose a specific folder for the restore.

7.19.4 COPY TO TAPE This option is generally for archiving purposes. To be able to restore your database to a tape you need

to have a standalone tape drive or library attached, configured and operational.

14

8

You need to specify the primary library and a copy library if you have one configured. You can choose

to compress or encrypt the data written to the tape. One important thing to keep in mind is if you

choose to encrypt the data written to the tape you will always need that specific certificate that

encrypted the data. If the certificate is lost or expires, you will be unable to restore this data from the

tape.

7.20 Long-Term Recovery Goals Restore

When restoring from long-term recovery goals or tape you must choose a recovery point that is listed

as tape in the dropdown menu.

Right click the database and choose Recover and the Recovery Wizard starts. Keep in mind that only

Express-Full recovery points will be written to tape.

You have the same options as you had when you restored from the short-term recovery goals. There is

one thing which differentiates the two options and that is the Specify database state option. If you

choose to restore the database and set the “Leave database non-operational but able to restore

additional transaction logs” option you won’t be able to restore additional transactional log files, just the

database.

14

9

7.21 Cloud Recovery Restore

When you choose to restore databases from Azure you need to start by pointing out a recovery point

that was stored in Azure by choosing the right date and time in the Recovery workspace.

Right-click the database and choose Recover and the Recovery Wizard starts. You will have three

options:

Recover to original instance of SQL Server (Overwrite database)

Recover to any instance of SQL Server

Copy to a network folder

15

0

The recovery types will not differentiate from the steps previously explained in this chapter.

7.22 Additional DPM Information

If you find System Center Data Protection Manger 2012 R2 interesting and would like to know more

how it could be used to enable a sophisticated protection for a modern datacenter you should start be

visiting the Microsoft TechNet DPM webpage: http://technet.microsoft.com/en-us/library/hh758173.aspx

Also available are System Center Data Protection Manager blogs. The ideal starting place is the official

product group blog from Microsoft at http://blogs.technet.com/b/dpm.

There are also several MVP blogs dedicated to DPM such as http://robertanddpm.blogspot.se.

http://technet.microsoft.com/en-us/library/hh758173.aspx

http://blogs.technet.com/b/dpm

http://robertanddpm.blogspot.se/

15

1

8.0 MONITORING SQL WITH SCOM - MATTHEW LONG

System Center Operations Manager is Microsoft’s enterprise monitoring tool, and through its

Management pack system has a deep level of knowledge and monitoring insight on the health of a wide

variety of applications (both Microsoft and otherwise).

One such freely available management pack is the System Center Management Pack for SQL Server.

This management pack provides SCOM with the capabilities to automatically find SQL Servers in your

environment, proactively monitor SQL components for health state changes, and provide dashboards,

architecture diagrams and common task shortcuts for SQL administrators and operations staff.

As of the current release (6.4.1.0) the management pack provides support for:

SQL Server 2005, 2008, 2008 R2, 2012, 2012 R2

Database engines Monitoring

o Individual Database Monitoring

o SQL agent Monitoring

o SQL Job Monitoring

Reporting Services Monitoring

Analysis Services Monitoring

Integration Services Monitoring

AlwaysOn Monitoring

o Database Replicas

o Availability Groups

o Availability Replicas

You can download the SQL Server management pack from Microsoft download. Whilst the SQL

management pack is also available from the SCOM MP Catalog (available within the SCOM console),

this does not include the SQL Presentation management pack which provides SCOM 2012 with

advanced SQL dashboards.

As such we recommend you download the SQL MP from Microsoft download if you are using SCOM

2012 and wish to get the full experience. In addition the SQL mp guide is extremely details and covers

the prerequisites and monitoring capabilities in full. This guide is only available from Microsoft

download and must be read and understood by your SCOM administrators prior to importing the SQL

management pack.

You can download the current SQL management pack release from http://www.microsoft.com/en-

gb/download/details.aspx?id=10631.

8.1 Management Pack Audience

Whilst the SQL management pack provides detailed monitoring, Alert knowledge and resolutions

directly from the SQL product group, it is operating as part of the Operations Manager system. As such

it does not provide second by second performance or transaction monitoring. SQL administrators who

already use dedicated monitoring tools may find that SCOM is not a suitable substitute for the features

and tools they have come to use within their roles.

http://www.microsoft.com/en-gb/download/details.aspx?id=10631

http://www.microsoft.com/en-gb/download/details.aspx?id=10631

15

2

The SQL mp is not designed to replace these monitoring tools, but instead to provide a “single-pane” of

health state information at a high to medium depth. Rather than locking this health state and reporting

capability within a particular silo, SCOM allows operators and application owners of other systems to

gain insight and understanding into the health of the SQL components that their systems rely upon.

This in turn releases resources that the SQL administration team may otherwise have to spend

investigating issues or fielding enquiries into SQL health and defending the platform when issues arise

for which the root cause is not apparent.

The SQL management pack also collects a huge amount of performance information, which is then

stored and aggregated in the SCOM Data Warehouse for long term reporting. Whilst the performance

counter collection interval may be too low to troubleshoot certain issues (with most performance

counters sampled on a 5 or 15 minute interval) this is more than acceptable for trending and reporting

across the last year of operation.

8.2 Configuration and Customization

The SQL management pack is by far one of the most complex management packs to implement within

Operations Manager. Unlike most management packs which can simply be imported into SCOM and

left to their own devices, the SQL MP has a series of important configuration steps that must be

understood and implemented depending on a series of factors in your environment.

8.2.1 INITIAL SETUP It is absolutely crucial that you read the SQL mp guide, specifically the Security Configurations

section. By default SCOM agents will most likely not have access to correctly discover and monitor

SQL components. This is because starting from SQL Server 2008 the Local System account (which in

most environments is the SCOM agent action account) does not receive the necessary security rights

to log into SQL.

If your organization restores these rights to SQL roles as part of their build process then you will not

need to provision SCOM Run as Accounts. However as this is generally not considered a secure

configuration it is more likely that you will need to provide SCOM with an account that has access to

SQL resources in order to correctly discover and monitor SQL components.

The Low-privilege Environments section details what the necessary accounts and rights should be.

Note that by default Local System (the default agent action account) will likely already have access to

WMI, performance counters and the Windows registry. If you do not use one global account for

monitoring all SQL servers, you may have to provision and configure multiple accounts within

Operations Manager. Take note of the Run As Account distribution model you are using for these

accounts; if you are using the “Most Secure” method you will need to configure each agent monitoring

SQL components to be able to make use of that account. This may impact your system onboarding

process into operations manager.

If you are making use of SQL Clusters or AlwaysOn capabilities, you must ensure that you enable the

Agent Proxy capability on all SCOM agents monitoring those SQL components. Failure to do so will

prevent correct discovery of Clustered or AlwaysOn components. Whilst SCOM will raise alerts for

15

3

agents missing Run As Accounts or Agent proxy settings, the alerts will not appear in SQL specific

views and can only be rectified by SCOM administrators.

8.2.2 OPTIONAL MONITORING FEATURES By default the SQL management pack has all generic monitoring capabilities enabled. What this

means is that monitors and rules that you would wish enabled for 99% of production SQL components

are enabled and configured out of the box with sensible thresholds from the SQL product group.

However, there are many situational or scenario specific monitors and rules that are disabled out of the

box as they are only of use in certain configurations, or require thresholds specified by your SQL

administrators before they can provide accurate heath calculations.

The following table lists all content in the SQL 2012 mp (as of 6.4.1.0) that is disabled by default.

Consider enabling these elements in your environment if they would prove useful (these can be

enabled either environment wide or only for specific SQL instances via SCOM Overrides).

Name Type Description Target

General Custom

User Policy

Discovery

Discovery Discovery of Custom User policies

for AlwaysOn objects

Availability Group

Discover SQL

Server 2012

Agent Jobs

Discovery Discovers SQL Server 2012 Agent

jobs.

SQL Server 2012 Agent

SQL Server 2012

Database

Custom User

Policy Discovery

Discovery Discovery of Custom User Policies

for SQL Server 2012 Database

SQL Server 2012 DB

Engine

Discover

Replication

Components

Discovery This discovers all SQL Server

Replication components on a SQL

Server 2012 DB Engine

SQL Server 2012 DB

Engine

SQL Server 2012

Replication

Publications and

Subscriptions

Discovery

Provider

Discovery This discovers replication

publications and subscriptions for

each SQL Server 2012 database.

SQL Server 2012 DB

Engine

SQL Server Full

Text Search

Service

Monitor This monitor checks the status of

the SQL Full Text Search service.

SQL Server 2012 DB

Engine

SQL User

Connections

Performance

Monitor This monitor analysis the user

connections to the SQL database

engine over time and calculates a

baseline over the initial learning

period.

SQL Server 2012 DB

Engine

15

4

Blocking

Sessions

Monitor Monitors blocked sessions for a

SQL instance.

SQL Server 2012 DB

Engine

Database Backup

Status

Monitor This monitor checks the status of

the database backup as reported by

Microsoft® SQL Server™.

SQL Server 2012 DB

Auto Close

Configuration

Monitor Monitors the auto close setting for

the database

SQL Server 2012 DB

Auto Create

Statistics

Configuration

Monitor Monitors the auto create statistic

setting for the database

SQL Server 2012 DB

Auto Shrink

Configuration

Monitor Monitors the auto shrink setting for

the database

SQL Server 2012 DB

Auto Update

Statistics

Configuration

Monitor Monitors the auto update statistics

setting for the database

SQL Server 2012 DB

Auto Update

Statistics Async

Configuration

Monitor Monitors the auto update statistics

async setting for the database

SQL Server 2012 DB

DB Chaining

Configuration

Monitor Monitors the DB chaining setting for

the database

SQL Server 2012 DB

Recovery Model

Configuration

Monitor Monitors the recovery model setting

for the database.

SQL Server 2012 DB

Page Verify

Configuration

Monitor Monitors the page verify setting for

the database.

SQL Server 2012 DB

Trustworthy

Configuration

Monitor Monitors the trustworthy setting for

the database

SQL Server 2012 DB

DB Total Space Monitor Monitors the space available in the

database and on the media hosting

the database in percentage terms.

SQL Server 2012 DB

DB Space

Percentage

Change

Monitor Monitors for a large change in value

of database available space over a

set number of sample periods.

SQL Server 2012 DB

Long Running

Jobs

Monitor This monitor checks for long running

SQL Agent jobs.

SQL Server 2012 Agent

Disk Read

Latency

Monitor Disk Read Latency monitor for 2012

DBs

SQL Server 2012 DB

Disk Write

Latency

Monitor Disk Write Latency monitor for 2012

DBs

SQL Server 2012 DB

SQL Re-

Compilation

Monitor SQL Re-Compilation for 2012 DB

Engine

SQL Server 2012 DB

Engine

Transaction Log

Free Space (%)

Monitor Transaction Log Free Space (%)

monitor for 2012 DBs

SQL Server 2012 DB

15

5

SQL Server 2012

DB Engine is

restarted

Rule Detects SQL Server 2012 DB

Engine restart.

SQL Server 2012 DB

Engine

SQL Server

Service Broker or

Database

Mirroring

Transport

stopped

Rule Detects that at least one endpoint in

a SQL Server broker conversation

has stopped listening for

connections.

SQL Server 2012 DB

Engine

SQL Server

Service Broker

transmitter shut

down due to an

exception or a

lack of memory

Rule SQL Server Service Broker

transmitter stopped due to an error

or a lack of memory

SQL Server 2012 DB

Engine

SQL Server

Service Broker or

Database

Mirroring is

running in FIPS

compliance

mode

Rule SQL Server Service Broker or

Database Mirroring is running in

Federal Information Processing

Standard (FIPS) compliance mode

SQL Server 2012 DB

Engine

The SQL Server

Service Broker or

Database

Mirroring

transport is

disabled or not

configured

Rule The SQL Server Service Broker or

Database Mirroring endpoint is

disabled or not configured.

SQL Server 2012 DB

Engine

SQL Server

Service Broker

Manager has

shutdown

Rule SQL Server Service Broker

Manager has shut down

SQL Server 2012 DB

Engine

An SNI call failed

during a Service

Broker/Database

Mirroring

transport

operation


Database Mirroring attempted to

access the transport layer through

the SQL Network Interface (SNI).

SNI returned an error. Transport

cannot continue.

SQL Server 2012 DB

Engine

An SQL Server

Service Broker

procedure output

results

Rule A procedure that SQL Server

Service Broker internally activated

output results. Internal procedures

should not output results.

SQL Server 2012 DB

Engine

15

6

The Service

Broker or

Database

Mirroring

Transport has

started


Database Mirroring transport has

started

SQL Server 2012 DB

Engine

Process Worker

appears to be

non-yielding on

Scheduler

Rule This error indicates that there is a

possible problem with a thread not

yielding on a scheduler.

SQL Server 2012 DB

Engine

IO Completion

Listener Worker

appears to be

non-yielding on

Node

Rule I/O completion ports are the

mechanism by which SQL Server

uses a pool of threads that was

created when the service was

started to process asynchronous I/O

requests.

SQL Server 2012 DB

Engine

An SQL job failed

to complete

successfully

Rule A SQL Server Agent Job failed. SQL Server 2012 Agent

IS Service has

attempted to

stop a running

package

Rule The Integration Services service

was used to send a request to the

Integration Services runtime to stop

a running package.

SQL Server 2012

Integration Services

SQL Server

terminating

because of

system

shutdown

Rule SQL Server is stopping because the

server is shutting down.

SQL Server 2012 DB

Engine

Table: Creating

statistics for the

following

columns

Rule sp_createstats has generated

statistics for each eligible column in

the current database

SQL Server 2012 DB

Engine

In addition to the disabled features above, it may be necessary to turn off functionality which is enabled

out of the box because it is noisy, not applicable, duplicating an existing alert, or not violating a best

practice of your organization. The SQL management packs provide a series of version specific and

generic groups that you can use for this purpose.

In addition, it may be worthwhile creating a series of custom dynamic groups that automatically

populate with SQL components matching certain criteria. These groups can then be used as the target

for monitoring overrides, in order to reduce SCOM administrative overhead and shorten the alert tuning

process. Common groups may include:

15

7

SQL Express/Developer edition Instances and databases (products may install SQL Express

DBs and self-manage these systems, so SCOM alerting is not required).

SQL DR systems (these systems are often inactive and will generate false alerts until they are

enabled for production use).

Clustered SQL Servers (monitoring configuration may differ significantly for a cluster. For

example, the cluster will manage which SQL services should be started at any given time).

8.3 Extending the SQL Management Pack with MP Authoring

Whilst the SQL MP does an excellent job of monitoring SQL out of the box, as it is written without

specialized knowledge of your environment (and consuming applications) there will sometimes be

scenarios that you wish to monitor for that are not provided by the management pack. In these cases

as the management pack platform used by SCOM is open, many people author their own monitoring

workflows in their own custom management pack and make use of the existing discoveries and class

objects from the SQL mp.

8.3.1 SQL MANAGEMENT PACK STRUCTURE The SQL management pack uses a granular class structure that enables you to target monitoring

workloads easily by SQL role and specific version. The Microsoft.SQLServer.Library management

pack defines version agnostic classes that you can use if you wish to monitor any version of the SQL

component you are targeting.

Each Microsoft.SQLServer.xxxx.Discovery management pack then defines a version specific object

that you can target if your monitoring workflow is only relevant for that version. If you need to target

multiple specifc versions of SQL (such as 2008 or 2008 R2 only) then you will need to either target your

monitoring at the generic classes in the library MP and use overrides to enable them, or implement your

monitor multiple times (once for each version).

The following table illustrates what classes exist in the SQL management packs, which may prove

useful when deciding how to target your custom monitors and rules.

Icon Name Hosted by Comments

SQL Role Windows Computer Target this class if you wish this

monitor to run on every SQL server

(may run multiple times if multiple

roles are installed).

SQL DB Engine Windows Computer SQL Database Instance (will exist

multiple times if multiple instances

installed).

SQL Reporting

Services

Windows Computer SQL Reporting Services instance.

SQL Analysis Services Windows Computer SQL Analysis Services instance.

SQL Integration

Services

Windows Computer SQL Integration Services instance.

15

8

SQL Agent SQL DB Engine The SQL Agent is discovered once

per instance of a DB Engine.

SQL Agent Job SQL Agent Discovery is disabled by default.

One instance will be discovered per

job once enabled.

SQL Database SQL DB Engine One instance will exist for each

database. Note that system

databases will also be discovered as

this class. If monitors/rules are

specific for a certain database, leave

them disabled by default and enable

via overrides.

SQL Server DB File SQL Server DB File

Group

One instance discovered for each

DB file in the file group.

SQL Server DB Log

File

SQL Database One instance discovered per

database.

15

9

8.3.2 USEFUL MODULES WHEN AUTHORING SQL MONITORING Once you have identified the appropriate class that you wish to target with your custom SQL

monitor/rule, you will need to build a module in your custom management pack that can be used to

query SQL and process whatever health check you wish to perform.

There are three main ways that you can easily query SQL using the built in SCOM modules:

Method Used as

part of

Create In SCOM

Console

Required

Knowledge

Notes

ADODB.Connection VBScript Yes (as long as

the default agent

account has

access to SQL).

VBScript skills Medium

performance

impact, flexible

System.Data.SqlClient.

SqlConnection

PowerShell

Script

No Powershell

Scripting, working

with .Net objects

Heavy

performance

impact, flexible

System.OleDbProbe Custom

Composite

workflow

No SCOM MP

custom module

authoring

Lightweight

performance

impact,

requires

knowledge of

other modules

Each of these modules has its own set of set of knowledge prerequisites (VBScript skills, Powershell

script skills, SCOM Composite module creation) so choosing the appropriate method will largely be pre-

deteremined by your available skillset. If you are comfortable with many of these methods, it should be

noted that whilst the OleDbProbe has the lighest performance impact on the SCOM agent, it will require

knowledge of other SCOM modules in order to process the returned data and generate a

health/performance state.

All three modules will allow you to specify a SQL query that will be executed against the targeted

system. If you are creating a Powershell or VBScript, you will need to ensure that you can build a

suitable connection string to connect to the SQL DB in question.

The database name can be retrieved using the name parameter on the SQL Database class.

The SQL Server/instance can be retrieved using the “Connection String” property of the SQL

DB Engine hosting the SQL database.

The connection string should specify one of:

o Integrated security (to run as the user account the script is executing under). You should

specify that your script module needs to use the SQL Server Monitoring Run as profile

(Microsoft.SQLServer.SQLProbeAccount) if the default SCOM agent account does

not have access to query SQL.

o If you are using SQL authentication you will need to create a Run As account and Profile

and use the SecureInput optional parameter of the Script module.

16

0

8.4 Sample VBScript

The following sample comes from the SQL Server 2012 MP. This script provides the state of each

Database which can then be filtered upon in a monitor to provide health state information.

Option Explicit SetLocale("en-us") Function Quit() WScript.Quit() End Function Function IsValidObject(ByVal oObject) IsValidObject = False If IsObject(oObject) Then If Not oObject Is Nothing Then IsValidObject = True End If End If End Function Function MomCreateObject(ByVal sProgramId) Dim oError Set oError = New Error On Error Resume Next Set MomCreateObject = CreateObject(sProgramId) oError.Save On Error GoTo 0 If oError.Number <> 0 Then ThrowScriptError "Unable to create automation object '" & sProgramId & "'", oError End Function '#Include File:Error.vbs Class Error Private m_lNumber Private m_sSource Private m_sDescription Private m_sHelpContext Private m_sHelpFile Public Sub Save() m_lNumber = Err.Number m_sSource = Err.Source m_sDescription = Err.Description m_sHelpContext = Err.HelpContext m_sHelpFile = Err.HelpFile End Sub Public Sub Raise() Err.Raise m_lNumber, m_sSource, m_sDescription, m_sHelpFile, m_sHelpContext End Sub Public Sub Clear() m_lNumber = 0 m_sSource = ""

16

1

m_sDescription = "" m_sHelpContext = "" m_sHelpFile = "" End Sub Public Default Property Get Number() Number = m_lNumber End Property Public Property Get Source() Source = m_sSource End Property Public Property Get Description() Description = m_sDescription End Property Public Property Get HelpContext() HelpContext = m_sHelpContext End Property Public Property Get HelpFile() HelpFile = m_sHelpFile End Property End Class Function ThrowScriptErrorNoAbort(ByVal sMessage, ByVal oErr) On Error Resume Next Dim oAPITemp Set oAPITemp = MOMCreateObject("MOM.ScriptAPI") oAPITemp.LogScriptEvent WScript.ScriptName, 4001, 1, sMessage & ". " & oErr.Description End Function Function ThrowScriptError(Byval sMessage, ByVal oErr) On Error Resume Next ThrowScriptErrorNoAbort sMessage, oErr Quit() End Function Sub HandleError(customMessage) Dim localLogger If Not (Err.number = 0) Then Set localLogger = new ScriptLogger localLogger.LogFormattedError(customMessage) Wscript.Quit 0 End If End Sub Function HandleErrorContinue(customMessage) Dim localLogger HandleErrorContinue = False If Not (Err.number = 0) Then Set localLogger = new ScriptLogger localLogger.LogFormattedError(customMessage) Err.Clear HandleErrorContinue = True End If End Function '#Include File:ConnectionString.vbs Function BuildConnectionString(strServer, strDatabase) ON ERROR RESUME NEXT

16

2

Err.Clear BuildConnectionString = "Data Source=" & EscapeConnStringValue(strServer) & ";Initial Catalog=" & EscapeConnStringValue(strDatabase) & ";Integrated Security=SSPI" End Function ' This function should be used to escape Connection String keywords. Function EscapeConnStringValue (ByVal strValue) ON ERROR RESUME NEXT Err.Clear EscapeConnStringValue = """" + Replace(strValue, """", """""") + """" End Function '#Include File:GetSQL2012DB.vbs 'Copyright (c) Microsoft Corporation. All rights reserved. ' This script takes a single parameter ' Param 0: The SQL connection string to connect to ' All database state is output in a property bag. A number of properties are output ' Name: DBName\State Value: Returns the status of the db. Status can be: ' RESTORING ' RECOVERING ' RECOVERY_PENDING ' SUSPECT ' EMERGENCY ' OFFLINE ' Const SQL_DISCOVERY_CONNECT_FAILURE = -1 Const SQL_DISCOVERY_QUERY_FAILURE = -2 Const DB_PROPERTY = "Status" Call GetDBHealth() Sub GetDBHealth() If WScript.Arguments.Count = 1 Then Dim oAPI, oBag Set oAPI = MOMCreateObject("MOM.ScriptAPI") Set oBag= oAPI.CreatePropertyBag() Dim nResult nResult = DBHealth(WScript.Arguments(0), oBag) Call oAPI.Return(oBag) Else Wscript.quit() End If End Sub Function DBHealth(sSQLConnectionString, byRef oBag) Dim e Set e = New Error Dim cnADOConnection Set cnADOConnection = MomCreateObject("ADODB.Connection") cnADOConnection.Provider = "sqloledb" cnADOConnection.ConnectionTimeout = 30 Dim sProv sProv = BuildConnectionString(sSQLConnectionString, "master") e.Clear

16

3

On Error Resume Next cnADOConnection.Open sProv e.Save On Error Goto 0 If 0 <> Err.number then DBHealth = SQL_DISCOVERY_CONNECT_FAILURE ThrowScriptErrorNoAbort "Query execution failed for '" & sSQLConnectionString & "' SQL Server", e Exit Function End If Dim oResults e.Clear On Error Resume Next ' query for the list of databases which are not database snapshots Set oResults = cnADOConnection.Execute("SELECT name , ISNULL (DATABASEPROPERTYEX(name," & "'" & DB_PROPERTY & "'),'N/A') from sys.databases") e.Save On Error Goto 0 If e.Number <> 0 Then DBHealth = SQL_DISCOVERY_QUERY_FAILURE ThrowScriptErrorNoAbort "Query execution failed for '" & sSQLConnectionString & "' SQL Server", e If (oResults <> null) Then oResults.Close Exit Function End If Do While Not oResults.EOF Call oBag.AddValue(oResults(0) & "-State", CStr(oResults(1))) oResults.MoveNext Loop

cnADOConnection.Close End Function

Sample Powershell Script

The following sample comes from the SQL Server 2012 MP. This script provides information on the

number of active connections for each SQL Database.

# ActiveConnectionsDataSource.ps1 # Active Connections Property Bag Script # param($computerName, $sqlInstanceName) # $InstancePath is the 'Connection String' property of SQL DB Engine Class (Microsoft.SQLServer.DBEngine) # $InstancePath supposed to be of three types: # computername # computername\MSSQLSERVER # computername\MSSQLSERVER.db1 #TODO: Discuss event id $SCRIPT_EVENT_ID = 7701

16

4

#Event Severity values $INFORMATION_EVENT_TYPE = 0 $ERROR_EVENT_TYPE = 1 function BuildConnectionString($serverName, $databaseName) { 'Data Source="' + ($serverName -replace '"', '""') + '";Initial Catalog="' + ($databaseName -replace '"', '""') + '";Integrated Security=SSPI' } function SqlQueryTables($ComputerName, $InstanceName, $query) { $res = ""; if ($InstanceName -eq "MSSQLSERVER") { $InstanceName = "DEFAULT" } $principalName = $ComputerName if ($InstanceName -ne "DEFAULT") { $principalName = "{0}\{1}" -f $principalName, $InstanceName } $UserPolicies = @{} $msg = "User Policies: {0}" -f [Environment]::NewLine $SqlConnection = New-Object System.Data.SqlClient.SqlConnection try { $SqlCmd = New-Object System.Data.SqlClient.SqlCommand $SqlAdapter = New-Object System.Data.SqlClient.SqlDataAdapter $DataSet = New-Object System.Data.DataSet $SqlConnection.ConnectionString = BuildConnectionString $principalName 'master' $SqlCmd.CommandText = $query $SqlCmd.Connection = $SqlConnection $SqlAdapter.SelectCommand = $SqlCmd $SqlAdapter.Fill($DataSet)|out-null $res = $DataSet.Tables } catch { $SqlConnection.Close() throw $_ } $SqlConnection.Close() return $res } function Main { param( $computerName, $sqlInstanceName ) # # Prepare MOM API and property bag object # $api = New-Object -comObject "MOM.ScriptAPI" try { $msg = [string]::Empty $query = "SELECT DB_NAME(dbid) as DBName FROM sys.sysdatabases; SELECT DB_NAME(dbid) as DBName, COUNT(dbid) as NConnections from sys.sysprocesses as sp inner join sys.dm_exec_connections as ex on sp.spid = ex.session_id WHERE dbid > 0 GROUP BY dbid;"

16

5

$res = SqlQueryTables $computerName $sqlInstanceName $query $dbConections = New-Object 'System.Collections.Generic.Dictionary[String,Double]' $res[0] | foreach { $dbConections[$_.DBName] = [double]0 } $dbCount = 0; $res[1] | foreach {$dbConections[$_.DBName] = [double]$_.NConnections } $dbConections.GetEnumerator() | foreach { $bag = $api.CreatePropertyBag() $bag.AddValue("Name", $_.Key) $bag.AddValue("Value", $_.Value) $dbCount++; $bag } $msg = "Active connections were got for {0} DBs on {1}" -f $dbCount, $InstancePath } catch { $header = "Managegement Group: $Target/ManagementGroup/Name$. Script: {0}" -f ($MyInvocation.MyCommand).Name.ToString() $msg += "Error occured during Active connection data source executing.{0}Computer:{1} {0}Reason: {2}" -f [Environment]::NewLine, $env:COMPUTERNAME, $_.Exception.Message $api.LogScriptEvent($header, $SCRIPT_EVENT_ID, $ERROR_EVENT_TYPE, $msg) } } Main $computerName $sqlInstanceName

8.5 System.OleDbProbe Module

The System.OleDbProbe Module is a built in probe module that will use an OLEDB provider/driver on

the system to make a database query from the hosting agent. The database, query and other settings

are defined via probe configuration and do not need to be hard coded into the MP (though obviously the

query usually is). The query can be modified using context parameter replacement prior to execution so

you can dynamically insert information into it if need be. It supports integrated and also manually

specified credentials, usually via Run As Profiles.

It also has the nifty ability to retrieve the database settings from specified registry keys, which can avoid

the need to go out and discover those pieces of information. This makes it quite suitable for attaching

onto existing classes from other management packs.

8.5.1 WHEN SHOULD YOU USE IT

You know in advance which columns you need to access.

You know how to implement your own module.

You don’t need to perform complex processing on each returned row.

16

6

8.5.2 REQUIRED CONFIGURATION

ConnectionString - The connection string you wish to use to connect to the database. On

windows 2003 or later, this is encrypted by the module. If you are using Integrated security, you

do not need to specify credentials as long as you are using a run as profile with this module (but

make sure you flag the connection as using integrated security!).

Query - The query you wish to run against the database. Supports context parameter

replacement, so you can use $Config/$ variables etc in your query.

8.5.3 OPTIONAL CONFIGURATION

GetValue – (true/false) Whether the results of the query should be returned or not (set to false if

you just want to connect to the DB, and you don’t care about the results of the query).

IncludeOriginalItem - (true/false) Determines if the resulting data item(s) will contain the item

that originally triggered this module. Note that the data is returned as CData, so you won’t be

able to perform XPath queries directly against it.

OneRowPerItem – (true/false) Should all resulting data be returned in a single data item, or 1

data item returned for each row in the query results? Normally setting this to true is more

useful, as you’ll often want a condition detection to process each row individually, and you won’t

know the order (or number) of resulting rows.

DatabaseNameRegLocation - Registry key where we can find the database name. Must be

under the HKLM hive.

DatabaseServerNameRegLocation - Registry key where we can find the database server

name (and instance, if required). Must also be under the HKLM hive.

QueryTimeout – (Integer) Optional parameter that allows you to perform a query timeout.

GetFetchTime – (true/false) Optional parameter that allows you to specify that the resulting

data item(s) should contain the fetch time for the query.

An important parameter is the OneRowPerItem. If set to false when you get back data the data item

will look like the below snippit (I’ve omitted the other elements to save space).

<RowLength></RowLength> <Columns> 

<Column>Data in first column</Column> <Column>Data in Second column. </Column> </Columns> <Columns>  <Column>Data in first column</Column> <Column>Data in Second column. </Column> </Columns>

This can make processing the results in further modules a pain, since your XPath Query is going to

have to specify which row and column specifically you want to access. If you instead set

OneRowPerItem to true then you’ll get multiple return items and can filter them using an Expression

filter with a simple syntax such as $Data/Columns/Column[1]$ You may also wish to filter on the

RowLength property to establish if any rows were returned. Remember that the module will return a

data item if it succeeded to connect but doesn’t have rights to query, so check that data was returned

before you try to do something with it!

16

8

8.6 Example Configurations

Normally if I’m going to use an OleDBProbe to access a database repeatedly I’ll create my own probe

module that sets up the settings I’m going to need and is already set to use my MP’s run as profile for

DB access. That way I don’t have to keep specifying it over and over again. Below is a sample where

I’ve done this, and configured everything other than my query to pass in for a SQL database

probe. Now all my monitors and rules that make use of this know where to locate the DB and what

other query options to use automatically (along with credentials).

<ProbeActionModuleType ID="DBProbe.Library.Probe.DatabaseOledbQuery" Accessibility="Public" RunAs="MSL!Microsoft.SQLServer.SQLProbeAccount " Batching="false" PassThrough="false"> <Configuration> <xsd:element minOccurs="1" name="Query" type="xsd:string" /> <xsd:element minOccurs="1" name="OneRowPerItem" type="xsd:boolean" /> </Configuration> <ModuleImplementation Isolation="Any"> <Composite> <MemberModules> <ProbeAction ID="PassThru" TypeID="System!System.PassThroughProbe" /> <ProbeAction ID="OledbProbe" TypeID="System!System.OleDbProbe"> <ConnectionString>Provider=SQLOLEDB;Integrated Security=SSPI</ConnectionString> <Query>$Config/Query$</Query> <GetValue>true</GetValue> <IncludeOriginalItem>false</IncludeOriginalItem> <OneRowPerItem>$Config/OneRowPerItem$</OneRowPerItem> <DatabaseNameRegLocation>SOFTWARE\MyRegKey\Database\DatabaseName</DatabaseNameRegLocation> <DatabaseServerNameRegLocation>SOFTWARE\MyRegKey\Database\DatabaseServerName</DatabaseServerNameRegLocation> </ProbeAction> </MemberModules> <Composition> <Node ID="OledbProbe"> <Node ID="PassThru" /> </Node> </Composition> </Composite> </ModuleImplementation> <OutputType>System!System.OleDbData</OutputType> <TriggerOnly>true</TriggerOnly> </ProbeActionModuleType>

Here I’ve done the same thing, only without using registry keys to specify the location of my

DB. Normally I’d pass the DB details from my targeted class as I’ll have some property that has been

discovered defining where the database is. Also note that the module has been configured to use the

SQL Monitoring account Run as Profile automatically.

<ProbeActionModuleType ID="DBProbe.Library.Probe.DatabaseOledbQuery" Accessibility="Public" RunAs="MSL!Microsoft.SQLServer.SQLProbeAccount " Batching="false" PassThrough="false"> <Configuration> <xsd:element minOccurs="1" name="DatabaseServer" type="xsd:string" /> <xsd:element minOccurs="1" name="DatabaseName" type="xsd:string" /> <xsd:element minOccurs="1" name="Query" type="xsd:string" /> <xsd:element minOccurs="1" name="OneRowPerItem" type="xsd:boolean" /> </Configuration> <ModuleImplementation Isolation="Any">

16

9

<Composite> <MemberModules> <ProbeAction ID="PassThru" TypeID="System!System.PassThroughProbe" /> <ProbeAction ID="OledbProbe" TypeID="System!System.OleDbProbe"> <ConnectionString>Provider=SQLOLEDB;Server=$Config/DatabaseServer$;Database=$Config/DatabaseName$;Integrated Security=SSPI</ConnectionString> <Query>$Config/Query$</Query> <GetValue>true</GetValue> <IncludeOriginalItem>false</IncludeOriginalItem> <OneRowPerItem>$Config/OneRowPerItem$</OneRowPerItem> </ProbeAction> </MemberModules> <Composition> <Node ID="OledbProbe"> <Node ID="PassThru" /> </Node> </Composition> </Composite> </ModuleImplementation> <OutputType>System!System.OleDbData</OutputType> <TriggerOnly>true</TriggerOnly> </ProbeActionModuleType>

8.7 Simple/Specified Authentication

If you don’t (or can’t) want to use Integrated security, you can pass credentials using simple

authentication and a run as profile. DO NOT hard code the credentials, these are now stored in plain

text and readable. The run as profile creds are encrypted and the connection string is encrypted across

the wire, the MP isn’t!

The syntax for this is shown below. Obviously replace the text in italics with your values.

Provider=SQLOLEDB; Server=ServerName; Database=databaseName; User Id=$RunAs[Name="RunAsIdentifierGoesHere"]/UserName$; Password=$RunAs[Name="RunAsIdentiferGoesHere"]/Password$

8.7.1 SCENARIO 1 – MONITORING In this scenario, you want to monitor a database for a certain condition. Perhaps you are getting the

result of a stored procedure, checking the number of rows in a table or checking rows for a

certain value (perhaps error logs?). Once queried, you pass the data items onto

a System.ExpressionFilter module to filter for your desired criteria and alert as appropriate.

8.7.2 SCENARIO 2 – COLLECTION Another fairly common scenario, here we are doing the same thing as above as part of an event

collection or performance collection rule. This could even be ignoring the data and just checking how

long it took the query to run, via the InitializationTime, OpenTime, ExecutionTime and

FetchTime properties of the output data. Following your System.OleDBProbe module you’ll usually use

one of the mapper condition detection modules to generate event or performance data (these are quite

nicely documented around the web and on MSDN. This is normally done with property bags, but the

principle is the same).

17

0

8.7.3 LINKS AND FURTHER READING You can find documentation for the System.OleDbProbe online at http://msdn.microsoft.com/en-

us/library/ff472339.aspx. A sample output of the System.OleDbProbe module is shown at

http://msdn.microsoft.com/en-us/library/ee533760.aspx.

http://msdn.microsoft.com/en-us/library/ff472339.aspx

http://msdn.microsoft.com/en-us/library/ff472339.aspx

http://msdn.microsoft.com/en-us/library/ee533760.aspx

17

1

9.0 BUILDING OUT A SQL SERVER TEMPLATE WITH VMM –

CRAIG TAYLOR

9.1 Using SQL Server Profiles in SCVMM 2012 R2

9.2 Introduction

In System Center Virtual Machine Manager (SCVMM or VMM), Microsoft have provided the capability

to deploy SQL Server as part of a Service Template, allowing for the more rapid deployment of multi-

tier applications dependent on the SQL Server database engine.

SQL Server 2008 R2 and later provide a Sysprep functionality as an advanced installation option. This

two-step installation process is similar to the Windows Sysprep tool in use. The two steps are:

1. Image Preparation - Installation of SQL Server setup files

SQL Server Sysprep can be used prior to image generalisation (via Windows Sysprep) to create

an operating system image that includes an un-configured SQL Server installation.

2. Image Completion - Finish SQL installation

Once the image has been deployed, either to a physical server, say via System Center

Configuration Manager, or to a virtual server via a virtual machine template, an end user can

finalise the SQL installation in a far quicker time than they may have deployed SQL from the

setup binaries.

Through embedding a Sysprep installation into an OS image, it is possible for an IT practice to both

accelerate and standardise their SQL Server deployments, whilst retaining the flexibility of

customisation to allow the deployed SQL Server instance to support any given applications specific

database requirements, (e.g. collation setting or FILESTREAM).

17

2

9.3 Preparing VMM

Preparing Virtual Machine Manager to make use of SQL Server Sysprep is also a two-stage process:

1. Creation and capture as a template of a SQL Server prepared image

During this stage, the administrator deploys an existing virtual machine template, installs a

Sysprep installation of SQL Server & creates a fork of the VM template

2. Creation of a SQL Server Profile & Service Template

During this stage, a SQL Server profile is created and used as part of a VMM Service Template

This chapter will outline the steps required to make use of SQL Server Profiles in Virtual Machine

Manager.

17

3

9.4 Creation of a Sysprep SQL Server Virtual Machine Template

Deploy a virtual machine from the base template you wish to fork. In this instance we are deploying our

standard Windows Server 2012 R2 template to the 'Production' VMM cloud

17

4

So that the VHDX files are meaningfully labelled, once captured to template during the VMM template

generalisation phase, we provide a Virtual Machine name that mentions SQL - in our instance -

WS2012R2_DC_SQL

17

6

It is important to ensure that the virtual machine is deployed as a workgroup server. This will prevent

configuration changes being applied to the Windows OS (say, via Group Policy) upon which we will

base our template disk

Once the virtual machine we plan to base our new template on has been deployed, we may run the

required SQL Server Sysprep image preparation.

NB: It is the author's recommendation that installation of the SQL Server pre-requisite, .NET 3.5, be

performed in advance of running the SQL installer, due to the unreliability inherent to this feature's

activation.

Following the activation of .NET 3.5, open the ‘Advanced’ section of the SQL Server Installation Center

and then click 'Image Preparation of a stand-alone instance of SQL Server'

17

7

It is possible to perform Sysprep-ed installs of Server Database Engine Services and SQL Server

Reporting Services. In this guide we cover preparation of the DB engine.

Select the features required for our template and then configure the installation directories

17

8

Provide the SQL installation with an Instance ID and Instance root directory, where the instances

system databases and logs will be deployed.

Please note that this Instance ID is immutable and cannot be altered during the Image Completion

process undertaken via the application of the VMM SQL Server profile.

18

0

Once the preparation has succeeded, copy the contents of the SQL media to a drive on the virtual

machine. In our example we copy the binaries to a subfolder of D:\Sources. Then using the VMM

administrators console, create a generalised VM Template based on the virtual machine

18

2

9.5 Creation of the SQL Server Profile

SQL Server Profiles are created in the Library section of the VMM administration console. Much like OS

& HW profiles, they are ultimately stored in the VMM database. No files on the VMM library server are

created as a consequence of their commission.

To create a SQL Server Profile, click the 'Create' drop down button on the Library section of the VMM

console. Then click 'SQL Server Profile'.

Provide a name and description for the SQL Server Profile

18

3

Under the SQL Server Configuration parent node, we must provide the profile with:

A name

An Instance name - This does not have to match the instance ID specified during the SQL Server

sysprep image preparation

An Instance ID - Note that this instance ID MUST match the one specified during the Sysprep-ed SQL

Server image preparation

A product key - the Image Completion process will fail without this being entered. It is normally found in

the DefaultSetup.ini file found on the installation media under the subfolder 'x64'

A RunAs account with administrative rights on our VM guest. In this instance, we have specified an

account that will be seeded as a local administrator on our server when it is joined to the domain. This

was achieved via the application of Group Policy

18

4

Under the SQL Server configuration ‘Configuration’ node, we must:

Provide a path for the SQL Server installation media accessible from the deployed virtual machine.

Note we have configured this to be a local path to minimize external dependencies during Service

Template deployment. Specifically, we have configured the path to which we copied the SQL Server

binaries during the template preparation.

Provide the users and groups you wish to provision SA rights on the SQL Server instance.

Specify the security mode you wish the SQL Server instance to operate under, either Windows

Authentication or Mixed Authentication

Define if TCP/IP & named pipes are going to be allowed for remote connections

18

5

Finally, configure an SA password by selecting a VMM RunAs profile containing the required credential

18

6

Under the SQL Server configuration ‘Service Accounts’ node, specify the Service Accounts under

which the SQL Server service & SQL Server Agent service will operate under, again using VMM RunAs

accounts:

9.6 Further Customisation Options

On first examination, it may appear that the degree of customisation that can be applied via SQL Server

profiles is somewhat limited. However using a SQL installation INI file, it is possible to configure

settings that are not directly configurable via the GUI, for example instance collation. To do this, a SQL

installation INI file must be present in the VMM library and configured using the Configuration node of

the SQL Server Configuration wizard

18

8

Further information on how to configure a SQL Server deployment using an INI file can be found on

Microsoft TechNet.

If a SQL Server installation INI file is used as part of a profile, the administrator will be asked if they

wish to populate the SQL Server deployment profile with the settings contained in the INI file.

Should the administrator accept this warning, it is recommended to revisit all sections of the profile

wizard to ensure they have retained the expected settings:

http://technet.microsoft.com/en-us/library/dd239405.aspx

18

9

9.7 Deployment of the Service Template

SQL Server Profiles can only be used as part of a Service Template. In this tutorial, we configure a

single tier service template, containing our SQL Server VM Template.

To apply a our created SQL Server profile to the VM tier right click on the tier and then select

'properties'. Following this, select the ‘SQL Server Configuration’ section of the properties window and

then select the profile we have configured from the SQL Server profile dropdown menu

19

0

Deploying this service will create a single virtual machine with SQL Server installed to our specification.

19

2

Upon deployment, one should attempt to connect to the deployed SQL instance using SQL

Management Studio, to confirm it meets the defined functional specification.

9.8 Conclusion

Virtual Machine Manager SQL Server profiles provide an easily managed means of rapidly provisioning

consistently configured SQL Server Virtual Machines as part of multi-tier Service Templates. The ability

19

3

to customise the functional specification, using an administration GUI for common settings and script

files for advanced settings, provide the cloud administrator with a flexible, low-overhead means of

providing standardised SQL infrastructure to their customers, be it for test, development or production

purposes. As many administrators can attest, SQL Server installations are typically a reasonably time-

consuming endeavour. As such, it is the author’s observation that time invested in educating oneself in

automating the process is typically pays dividends in a reasonably short period.

19

4

10.0 SPECIAL THANKS

This guide is nearly 130 pages of extra content over the last version, this would not have been possible

without Pete’s Azure experience when it comes to System Center in the cloud. Robert showed us why

he still loves DPM. Matthew who is a great MP dev gave a solid explanation of the SQL MP . Craig and

Richard gave a ton of help with the clustering, AlwaysOn and full guide edits.

All of the contributors hope to do a V2 of this guide over the next few months so check back soon, we

will announce the next edition on Twitter @paul_keely

Any mistakes and errors in this guide were inserted by a hacker!

http://matthewlong.wordpress.com/

http://2big4twitter.com/

http://richardjgreen.net/

sql and system center - · pdf file1 deploy sql 2012 in various different configurations to...

Documents