• Create and save a OMS Log Analytics search result
• Create an Azure Storage Blob Container
• Create an Azure SQL Data Warehouse
• Utilize Azure Automation to schedule the OMS Log Analytics search and upload data blob to storage container
• Create and connect resources to Azure Data Factory
• Create a ADF (Azure Data Factory) pipeline to move the OMS Log Analytics search data from Storage Blob to Azure SQL Data Warehouse

Before you begin

Step 1: Build and save the search results of OMS Log Analytics query with data you want to move into the Azure SQL Data Warehouse

Step 2: Create an Azure Storage Account and a Blob Storage Container within the Storage Account

Step 3: Create the Azure SQL Data Warehouse

Step 4: Choose a Table Name and Populate the Table Schema

Step 6: Create an Azure Data Factory Service and Create Linked Services to Azure Storage Blob and Azure SQL Data Warehouse

Step 7: Use the Data Factory Copy Wizard to create a Pipeline from Azure Storage to Azure SQL Data Warehouse

• Enter a the task name like 'CopyOMSLogsToAzureSqlDw'.
• Enter a description (optional)
• Choose the task cadence to run regularly on schedule and choose Daily once a day.
• Select a start time in the past and then set a stop time in the future. For testing I did put a value of yesterday and then ended it a year in the future. The key thing with the time is that you want to sync this to after your Azure Automation schedule will make the CSV file available. We'll discuss that in more detail later.
• Click 'Next'.

As I try to recall the specifics of the environment that I used this script in, SCVMM had an update server specified, a baseline was configured, and the baseline was targeted to a specific host group. What this script does is gets the baseline and the host group and looks for the fifty (50) newest updates from the update server with classification of “Security Updates” and “Critical Updates” for Windows Server 2008 R2. These were the only classifications the customer was interested in and I chose to look up the newest 50 updates with the rational that there could never be more than 50 updates between each Patch Tuesday each month :-). Once I get the newest 50 updates, I then compare them to what is currently listed in the current baseline and then build an array with the difference. Which ever updates are not listed in the current baseline will get updated with the newest updates.

Try it out and let me know if there’s any questions. Again I developed this script a while ago and haven’t tested it recently.

Import-Module VirtualMachineManager

$ContosoBaseline = Get-SCBaseline | where { $_.Name -eq "Contoso Baseline" }
$ContosoHostGroup = Get-SCVMHostGroup | where { $_.Name -eq "Contoso Host Group" }

$baseline = Get-SCBaseline -ID $ContosoBaseline.ID

$addedUpdateList = @()
$scope = Get-SCVMHostGroup -Name $ContosoHostGroup.Name -ID $ContosoHostGroup.ID

$SCVMMJobGUID = [System.Guid]::NewGuid()

$ContosoLatestUpdates = Get-SCUpdate -Newest 50 | where { ($_.UpdateClassification -eq "Security Updates" -or $_.UpdateClassification -eq "Critical Updates") -and $_.Products -eq "Windows Server 2008 R2" }

# Nested For Loop needed to filter against existing updates to new updates and only add new updates to the $addedUpdateList
ForEach ($Update in $ContosoLatestUpdates)
      {
            ForEach ($ContosoUpdate in $ContosoBaseline)
        {
            If ($Update -eq $ContosoUpdate)
             {
                $UpdateExistsInBaseline = $True   
             }
            Else
             {
                $UpdateExistsInBaseline = $False
             }
        }

        If (!$UpdateExistsInBaseline)
         {
                $addedUpdateList += Get-SCUpdate -ID $Update.ID
                }

      }

Set-SCBaseline -Baseline $baseline -AddAssignmentScope $scope -JobGroup $SCVMMJobGUID.ToString() -RunAsynchronously

Set-SCBaseline -Baseline $baseline -Name $ContosoBaseline.Name.ToString() -RunAsynchronously -AddUpdates $addedUpdateList -JobGroup $SCVMMJobGUID.ToString() -StartNow

$myPublishedVMs = @()

$myVMs = Get-SCVirtualMachine

ForEach ($vm in $myVMs)
{
    $myPublishedVMs += $vm.Name.ToString()
}

If you build a simple Orchestrator runbook using the Run VMM PowerShell Script activity using the PowerShell code and publishing the $myPublishedVMs as Output Variable 01 and send it to a Send Platform Event for testing, you would expect the Send Platform Event to run as many times as the number of elements in the collection.

But instead what you get is an output of System.Object[] in the details of the Send Platform Event as shown below.

I immediately thought there was an issue until I started doing some digging, like reading the documentation :-), and there it was on the TechNet page saying that this is expected behavior for the Run VMM PowerShell Script activity if your “variable contains a complex type or a collection of objects”.

https://technet.microsoft.com/en-us/library/hh830716.aspx

Now knowing that I cannot use the Run VMM PowerShell Script activity to publish a collection out to the Orchestrator databus, I had to come up with a solution to make my runbooks work with all that rich data I was getting from the Run VMM PowerShell Script. At first thought I figured I would just substitute in my workflows the Run VMM PowerShell Script activity to the Run .Net Script activity. There’s pros and cons with this and I personally like the Run VMM PowerShell Script activity because it takes care of remoting to the VMM server and the importing of the VMM PowerShell module. When using the Run .Net Script activity I’ve found you have to instrument more error handling to account for the Invoke-Command and other things.

So understanding that I could pass a string as a variable, I figured I would do something I have done countless times in C#, which is to use the String Builder class and just append my string data to a string that I would just publish on the Orchestrator databus and on the next activity I would take the string and then do a split on it to get the items in a collection and then publish that collection onto the databus outside of using the Run VMM PowerShell script. It does add an extra step to your workflow, but the benefits of being able to utilize the built-in looping functionality of Orchestrator is well worth it. In using the same PowerShell code example you would make the following edits below.

$myPublishedVMs = new-object System.Text.StringBuilder

$myVMs = Get-SCVirtualMachine

ForEach ($vm in $myVMs)
{
    $myPublishedVMs.append($vm.Name.ToString())
    $myPublishedVMs.append(',')
}

$outputVariable01 = $myPublishedVMs.ToString()

Notice that I’m appending a comma as well and simply building a string that will look like “Server01,Server02,Server03,”. You can now output this string on the Orchestrator databus and use a split on the comma to create an array. One other thing that you want to be cautious of is the length of your string that you will put on the Orchestrator databus. Reading Robert Hearn’s blog post ( https://blogs.technet.com/b/orchestrator/archive/2012/05/08/orchestrator-quick-tip-what-s-the-maximum-size-of-parameters.aspx) I would keep the character length of this string to under 2000 characters. So the final code will look like this below.

$myPublishedVMs = new-object System.Text.StringBuilder

$myVMs = Get-SCVirtualMachine

ForEach ($vm in $myVMs)
{
    $myPublishedVMs.append($vm.Name.ToString())
    $myPublishedVMs.append(',')  
}

$outputVariable01 = $myPublishedVMs.ToString()

$charCount = ($outputVariable01 | Measure-Object –Character).Characters

If ($charCount –gt 2000)
{
    Throw [System.Exception]”The output string is more than 2000 characters.”
}

In the following activity use the Run .Net Script activity to convert the $myPublishedVMs string into a collection object that you can then publish back to the Orchestrator databus. One thing to note is that the way I’m building my string in the Run VMM PowerShell Script will always leave an empty element do to the final append of a comma. I’m filtering out the empty element by simply checking if it is null or empty. That PowerShell script code will look similar to this below.

$myVMsArray = @()

$stringOutput = “<Output Variable 01 from Run VMM PowerShell Script>”

$splitVMsOnComma = $stringOutput.Split(“,”)

ForEach ($vm in $splitVMsOnComma)
{
    If (![string]::IsNullOrEmpty($vm))
    {
            $myVMsArray += ,$vm
    }
}

$myVMsArray

The final test Orchestrator runbook will look like the following.

Notice there are double quotes around the Output Variable 01

Once you check the Orchestrator runbook in and run it, you should see the following results.

On my Events tab I show two entries from the Send Platform Event and this correlates to what I have in my current lab, which is two virtual machines showing in Virtual Machine Manager.

And if I look at both of those events listed in Orchestrator I should see each individual virtual machine listed as an event, which I do shown below.

So that’s all for this post. I hope you guys out there managing and developing solutions around Clouds can utilize this. I know for me being able to have this functionality was HUGE when working with Virtual Machine Manager and developing service requests. This can be very powerful when using the Run VMM PowerShell Script because that activity allows for up to 20 outputs on the Orchestrator databus. Have fun out there :-).

Thanks,

Phil Gibson [MSFT]

In the case that you need to move your System Center Operations Manager 2012 OperationsManager and/or OperationsManagerDW database(s) to a different back-end SQL server, we have documented those step-by-step procedures for you. You can actually find those step-by-step procedures located here for the OperationsManager database ( https://technet.microsoft.com/en-us/library/hh278848.aspx ) and here for the OperationsManagerDW database ( https://technet.microsoft.com/en-us/library/hh268492.aspx ).

What I have done is taken those procedures and coded it into a PowerShell script that you can run in a completely automated fashion. The reason for the development of this script was to provide a solution to a customer that actually needed to have a System Center Operations Manager 2012 infrastructure that could manage servers in multiple geo-located datacenters, and have that infrastructure able to survive a single datacenter outage. I’m going to blog extensively on that solution later, but for now just understand that in this scenario both the OperationsManager and OperationsManagerDW are located on a mirrored SQL database back-end that is replicated throughout the geo-located datacenters. This PowerShell script will automate all of the procedures listed in the above step-by-step URLs. What I’ve tried to do was to identify in the PowerShell script the step number it was listed as in documented steps. Because I was merging both the OperationsManager and OperationsManagerDW in one PowerShell script, the steps may not totally correlate back to the documentation, but if you are familiar with what the documentation is asking to do, the PowerShell script is following those procedures as serial as possible.

A couple of preparation tips before you begin to utilize this script in your environment

1. Ensure that you are an administrator on all of the Management Servers as well as the SQL Servers
2. Ensure that the WS-Man protocol is enabled on all of the Management Servers as well as the SQL Servers. I’m using PowerShell Invoke-Commands, so this PowerShell script will be initiating remote sessions on those computers. You may want to run “winrm quickconfig” to enable this.
3. Ensure that your PowerShell execution policy is set to RemoteSigned or lower for all of the Management Servers as well as the SQL Servers.
4. Ensure that the machine you plan on executing this PowerShell script has the SQL 2008 R2 client tools installed. When I first began developing this PowerShell script I was using the ADO COM objects to query and update SQL. I have found it much easier to add the SQLServerCmdLetSnapin100 snapin and utilize the Invoke-SQLCmd cmdlet. You’ll want to test that you can add that snapin before running the script in automation.
5. Ensure that the SQL server that you are moving your database(s) to has the same SQL logins for the System Center Operations Manager 2012 accounts that you have defined during installation. Because we will be using a different SQL server, you must ensure that your SDK, DB Reader, and DB Writer accounts continue to have the same level of access from the previous SQL server used.

 Automated OpsMgr 2012 DB Move PowerShell Script Breakdown

I’m going to highlight the PowerShell script key functions. You can download the complete script at the end of the post.

Lines 11 – 34 – Here you will have to change the server names to the servers in your environment. You’ll enter your Management server names, your current SQL Server(s) that host the OperationsManager and OperationsManagerDW, your new SQL Server(s) that will host the OperationsManager and OperationsManagerDW, your Operations Manager Reporting Server, and the path to ConfigService.config on each Management server. In my case the Management servers had the same standard build configuration, so the path was the same on all Management servers.

Line 36 – Adding the SQL PowerShell snapin

Lines 38 – 60 – Stopping all services on all Management Servers

Lines 62 – 86 – Updating all Management Servers registry information to point to the new SQL Server

Lines 88 – 107 – Updating the Operations Manager Report Server to point to the new SQL Server

Lines 109 – 139 – Updating the ConfigService.config XML file on all Management Servers to point to the new SQL Server

Lines 141 – 188 – Updating the OperationsManager and OperationsManagerDW with the new SQL Server name

Lines 190 – 207 – Enabling the SQL Broker for the OperationsManager DB if needed

Lines 210 – 231 – Starting all services on all Management Servers

 1: <#

 2:   Purpose  : Automate the move of System Center Operations Manager 2012 Databases

 3:             

 4:   Author   : pgibson.online@hotmail.com [MSFT]

 5:  

 6:   Disclaimer: THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, 

 7:               EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED 

 8:               WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.

 9: #>

 10:  

 11: # ************ Set PS Script Environemnt Variables *************************

 12:  

 13: # Management Servers Array

 14: [Array]$MgmtServers ="MGMTSRV01.contoso.com","MGMTSRV02.contoso.com","MGMTSRV03.contoso.com"

 15:  

 16: # Current SQL OperationsManager DB Server

 17: $global:CurrentSQLOpsMgrDBSrv = "SQLSRVOPSDB01.contoso.com"

 18:  

 19: # New SQL OperationsManager DB Server

 20: $global:NewSQLOpsMgrDBSrv = "SQLSRVOPSDB02.contoso.com"

 21:  

 22: # Current SQL OperationsManagerDW DB Server

 23: $global:CurrentSQLOpsMgrDWSrv = "SQLSRVDWDB01.contoso.com"

 24:  

 25: # New SQL OperationsManagerDW DB Server

 26: $global:NewSQLOpsMgrDWSrv = "SQLSRVDWDB02.contoso.com"

 27:  

 28: # Current OpsMgr Report Server

 29: $global:CurrentOpsMgrRptSrv = "OPSMGRRPTSRV01.contoso.com"

 30:  

 31: # Enter the path of the ConfigService.config file of all Management Servers

 32: $global:CngSvcCfgFilePath = "E:\Program Files\System Center 2012\Operations Manager\Server\ConfigService.config"

 33:  

 34: # ************ End PS Script Environemnt Variables *************************

 35:  

 36: add-pssnapin SqlServerCmdLetSnapin100 -EA 0

 37:  

 38: # Step 1 - Stop the Operations Manager services

 39: write-host "Stopping Management Server(s) services."

 40: Invoke-Command -ComputerName $MgmtServers -ScriptBlock {

 41:     $OpsMgr12MgmtSrvSvcArray = @("System Center Data Access Service", "System Center Management", "System Center Management Configuration")

 42:  

 43:     ForEach ($svc in $OpsMgr12MgmtSrvSvcArray)

 44:         {

 45:             write-host "Stopping service $svc on $Env:ComputerName..."

 46:             $SCOpsMgrSvc = Get-Service | ? { $_.DisplayName -eq $svc}

 47:             If ($SCOpsMgrSvc.Status -ne "Stopped")

 48:                 {

 49:                     Stop-Service -DisplayName $svc

 50:                     Do

 51:                         { 

 52:                             Start-Sleep -s 15

 53:                             $SCOpsMgrSvc = Get-Service | ? { $_.DisplayName -eq $svc}

 54:                         } Until ($SCOpsMgrSvc.Status -eq "Stopped")

 55:                 }

 56:             write-host "The service $svc is stopped on $Env:ComputerName."            

 57:         

 58:         }

 59:  } # End Invoke-Command for stopping Management Server services

 60: write-host "Finished stopping Management Server(s) services."

 61:         

 62: # Step 6 - Update registry to refer to the new SQL Server-based computer

 63: write-host "Updating Management Server(s) registry to refer to new SQL Server."

 64: Invoke-Command -ComputerName $MgmtServers -ScriptBlock {

 65:     param(

 66:         [Parameter(Position=0)]

 67:         $LocalVarNewSQLOpsMgrDBSrv

 68:     )

 69:  

 70:     $RegKeyDatabaseServerName = Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\System Center\2010\Common\Database" -Name "DatabaseServerName"

 71:     

 72:     If ($RegKeyDatabaseServerName.DatabaseServerName -ne $LocalVarNewSQLOpsMgrDBSrv)

 73:         {

 74:             write-host "Changing registry key HKLM:\SOFTWARE\Microsoft\System Center\2010\Common\Database\DatabaseServerName on $Env:ComputerName"

 75:             Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\System Center\2010\Common\Database" -Name "DatabaseServerName" -Value $LocalVarNewSQLOpsMgrDBSrv

 76:             write-host "Completed registry key change HKLM:\SOFTWARE\Microsoft\System Center\2010\Common\Database\DatabaseServerName on $Env:ComputerName"

 77:         }

 78:     Else

 79:         {

 80:             write-host "No modification to registry key HKLM:\SOFTWARE\Microsoft\System Center\2010\Common\Database\DatabaseServerName needed on $Env:ComputerName"

 81:         }

 82:         

 83:     

 84: } -Argumentlist $NewSQLOpsMgrDBSrv

 85: # End Invoke-Command for changing management server registry keys  

 86: write-host "Completed updating Management Server(s) registry to refer to new SQL Server."

 87:  

 88: # Step 6.1 - Update registry on OpsMgr Report Server to refer to the new SQL Server-based computer

 89: write-host "Updating Management OpsMgr Report Server registry to refer to new SQL Server."

 90: Invoke-Command -ComputerName $CurrentOpsMgrRptSrv -ScriptBlock {

 91:     param(

 92:         [Parameter(Position=0)]

 93:         $LocalVarOpsMgrRptSrv

 94:     )

 95:     

 96:     #$RegKeyDefaultSDKServiceMachine = Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Reporting" -Name "DefaultSDKServiceMachine"

 97:     $RegKeyDWDBInstance = Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Reporting" -Name "DWDBInstance"

 98:     If ($RegKeyDWDBInstance.DWDBInstance -ne $LocalVarOpsMgrRptSrv)

 99:         {

 100:             write-host "Changing registry key HKLM:\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Reporting\DWDBInstance on $Env:ComputerName"

 101:             Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Reporting" -Name "DWDBInstance" -Value $LocalVarOpsMgrRptSrv

 102:             write-host "Completed registry key change HKLM:\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Reporting\DWDBInstance on $Env:ComputerName"

 103:         }

 104:  

 105: } -ArgumentList $CurrentOpsMgrRptSrv

 106: # End Invoke-Command for changing OpsMgr Report Server registry keys  

 107: write-host "Completed updating OpsMgr Report Server registry to refer to new SQL Server."

 108:  

 109: # Step 7 - Edit the ConfigService.config file

 110: write-host "Editing Management Server(s) ConfigService.config file."

 111: Invoke-Command -ComputerName $MgmtServers -ScriptBlock {

 112:     param(

 113:         [Parameter(Position=0)]

 114:         $LocalVarCngSvcCfgFilePath

 115:     ,

 116:         [Parameter(Position=1)]

 117:         $LocalVarNewSQLOpsMgrDBSrv

 118:     )

 119:  

 120:     If (test-path $LocalVarCngSvcCfgFilePath)

 121:         {

 122:             $xmlConfigSvcCfg = [XML] (get-content $LocalVarCngSvcCfgFilePath)

 123:  

 124:             $CmdbServerName = $xmlConfigSvcCfg.SelectSingleNode("/Config/Component/Instance/Category[@Name='Cmdb']/Setting[@Name='ServerName']")

 125:             $CmdbServerName.Value = $LocalVarNewSQLOpsMgrDBSrv

 126:  

 127:             $ConfigStoreServerName = $xmlConfigSvcCfg.SelectSingleNode("/Config/Component/Instance/Category[@Name='ConfigStore']/Setting[@Name='ServerName']")

 128:             $ConfigStoreServerName.Value = $LocalVarNewSQLOpsMgrDBSrv

 129:  

 130:             $xmlConfigSvcCfg.Save($LocalVarCngSvcCfgFilePath)

 131:         }

 132:     Else

 133:         {

 134:             write-host "File not found at $LocalVarCngSvcCfgFilePath"

 135:         }

 136:  

 137: } -ArgumentList $CngSvcCfgFilePath, $NewSQLOpsMgrDBSrv

 138: # End Invoke-Command for editing management server ConfigService.config file

 139: write-host "Finished editing Management Server(s) ConfigService.config file."

 140:  

 141: write-host "Updating SQL tables with new SQL Server name."

 142: # Step 8 - Udpate Operational Database with new SQL Server name

 143:  

 144: # Translate tables name which has "$" in name

 145: $MT_MSFTSysCntrMgmtGrpTbl = "dbo.MT_Microsoft`$SystemCenter`$ManagementGroup"

 146: $MT_MSFTSysCntrDWTbl = "dbo.MT_Microsoft`$SystemCenter`$DataWarehouse"

 147: $MT_MSFTSysCntrDWAppMonTbl = "dbo.MT_Microsoft`$SystemCenter`$DataWarehouse`$AppMonitoring"

 148:  

 149: # Because the SQLServerName_GUID column is dynamic, we need to find out the column name for this installation instance

 150: $GetMgmtGroupSrvNameColumn = invoke-sqlcmd -Database OperationsManager -Query "Select top 1 * from sys.syscolumns where name like 'SQLServerName_%'" -ServerInstance $NewSQLOpsMgrDBSrv

 151:  

 152: # Translate $GetMgmtGroupSrvNameColumn result to string data type

 153: $MgmtGrpSrvNameColumn = $GetMgmtGroupSrvNameColumn.Name.ToString()

 154:  

 155: # Update Opertional Database server name

 156: write-host "Updating SQL table $MT_MSFTSysCntrMgmtGrpTbl column $MgmtGrpSrvNameColumn on SQL Server $NewSQLOpsMgrDBSrv..."

 157: invoke-sqlcmd -Database OperationsManager -Query "UPDATE $MT_MSFTSysCntrMgmtGrpTbl SET $MgmtGrpSrvNameColumn = '$NewSQLOpsMgrDBSrv'" -ServerInstance $NewSQLOpsMgrDBSrv

 158: write-host "Completed updating SQL table $MT_MSFTSysCntrMgmtGrpTbl column $MgmtGrpSrvNameColumn on SQL Server $NewSQLOpsMgrDBSrv."

 159:  

 160: # Step 9 - Udpate Operational Database with new SQL Server name for APM tables

 161:  

 162: # Translate table name which has "$" in name

 163: $MT_MSFTSysCntrOpsMgrDBAppMonTbl = "dbo.MT_Microsoft`$SystemCenter`$OpsMgrDB`$AppMonitoring"

 164:  

 165: # Update Opertional Database server name

 166: write-host "Updating database OperationsManager, SQL table $MT_MSFTSysCntrOpsMgrDBAppMonTbl, column MainDatabaseServerName_5C00C79B_6B71_6EEE_4ADE_80C11F84527A on SQL Server $NewSQLOpsMgrDBSrv..."

 167: invoke-sqlcmd -Database OperationsManager -Query "UPDATE $MT_MSFTSysCntrOpsMgrDBAppMonTbl SET MainDatabaseServerName_5C00C79B_6B71_6EEE_4ADE_80C11F84527A = '$NewSQLOpsMgrDBSrv'" -ServerInstance $NewSQLOpsMgrDBSrv

 168: write-host "Completed updating database OperationsManager, SQL table $MT_MSFTSysCntrOpsMgrDBAppMonTbl, column MainDatabaseServerName_5C00C79B_6B71_6EEE_4ADE_80C11F84527A on SQL Server $NewSQLOpsMgrDBSrv."

 169:  

 170: write-host "Updating database OperationsManager, SQL table $MT_MSFTSysCntrDWTbl, column MainDatabaseServerName_2C77AA48_DB0A_5D69_F8FF_20E48F3AED0F on SQL Server $NewSQLOpsMgrDBSrv..."

 171: invoke-sqlcmd -Database OperationsManager -Query "UPDATE $MT_MSFTSysCntrDWTbl SET MainDatabaseServerName_2C77AA48_DB0A_5D69_F8FF_20E48F3AED0F = '$NewSQLOpsMgrDBSrv'" -ServerInstance $NewSQLOpsMgrDBSrv

 172: write-host "Completed updating database OperationsManager, SQL table $MT_MSFTSysCntrDWTbl, column MainDatabaseServerName_2C77AA48_DB0A_5D69_F8FF_20E48F3AED0F on SQL Server $NewSQLOpsMgrDBSrv."

 173:  

 174: write-host "Updating database OperationsManager, SQL table $MT_MSFTSysCntrDWAppMonTbl, column MainDatabaseServerName_5C00C79B_6B71_6EEE_4ADE_80C11F84527A on SQL Server $NewSQLOpsMgrDBSrv..."

 175: invoke-sqlcmd -Database OperationsManager -Query "UPDATE $MT_MSFTSysCntrDWAppMonTbl SET MainDatabaseServerName_5C00C79B_6B71_6EEE_4ADE_80C11F84527A = '$NewSQLOpsMgrDBSrv'" -ServerInstance $NewSQLOpsMgrDBSrv

 176: write-host "Completed updating database OperationsManager, SQL table $MT_MSFTSysCntrDWAppMonTbl, column MainDatabaseServerName_5C00C79B_6B71_6EEE_4ADE_80C11F84527A on SQL Server $NewSQLOpsMgrDBSrv."

 177:  

 178: write-host "Updating database OperationsManagerDW, SQL table dbo.MemberDatabase, column ServerName on SQL Server $NewSQLOpsMgrDWSrv..."

 179: invoke-sqlcmd -Database OperationsManagerDW -Query "UPDATE dbo.MemberDatabase SET ServerName = '$NewSQLOpsMgrDBSrv'" -ServerInstance $NewSQLOpsMgrDWSrv

 180: write-host "Completed updating database OperationsManagerDW, SQL table dbo.MemberDatabase, column ServerName on SQL Server $NewSQLOpsMgrDWSrv."

 181:  

 182: # Step 14 - Execute SQL commands on new Operations database

 183: write-host "Executing sp_configure and reconfigure on database OperationsManager on SQL Server $NewSQLOpsMgrDWSrv..."

 184: invoke-sqlcmd -Database OperationsManager -Query "sp_configure 'show advanced options', 0" -ServerInstance $NewSQLOpsMgrDBSrv

 185: invoke-sqlcmd -Database OperationsManager -Query "reconfigure" -ServerInstance $NewSQLOpsMgrDBSrv

 186: invoke-sqlcmd -Database OperationsManager -Query "sp_configure 'clr enabled',1" -ServerInstance $NewSQLOpsMgrDBSrv

 187: invoke-sqlcmd -Database OperationsManager -Query "reconfigure" -ServerInstance $NewSQLOpsMgrDBSrv

 188: write-host "Completed executing sp_configure and reconfigure on database OperationsManager on SQL Server $NewSQLOpsMgrDWSrv."

 189:  

 190: # Step 15 & 16 - Check if OperationsManager DB broker is enabled

 191: write-host "Checking to see if the DB broker is enabled on database OperationsManager on SQL Server $NewSQLOpsMgrDWSrv..."

 192: $BrokerEnabled = invoke-sqlcmd -Database OperationsManager -Query "SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'" -ServerInstance $NewSQLOpsMgrDBSrvA

 193:  

 194: If (!$BrokerEnabled.is_broker_enabled)

 195:     {

 196:         # Step 16 - Alter Operations Manager DB

 197:         write-host "The DB broker is not enabled on database OperationsManager on SQL Server $NewSQLOpsMgrDWSrv."

 198:         write-host "Altering database OperationsManager on SQL Server $NewSQLOpsMgrDWSrv to enable the DB broker..."

 199:         invoke-sqlcmd -Database OperationsManager -Query "ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE" -ServerInstance $NewSQLOpsMgrDBSrv

 200:         invoke-sqlcmd -Database OperationsManager -Query "ALTER DATABASE OperationsManager SET ENABLE_BROKER" -ServerInstance $NewSQLOpsMgrDBSrv

 201:         invoke-sqlcmd -Database OperationsManager -Query "ALTER DATABASE OperationsManager SET MULTI_USER" -ServerInstance $NewSQLOpsMgrDBSrv

 202:         write-host "Completed altering database OperationsManager on SQL Server $NewSQLOpsMgrDWSrv to enable the DB broker."

 203:     }

 204: Else

 205:     {

 206:         write-host "DB broker for database OperationsManager is enabled. No DB altering needed."

 207:     }

 208:  

 209:  

 210: # Step 17 - Start the Operations Manager services

 211:  

 212: Invoke-Command -ComputerName $MgmtServers -ScriptBlock {

 213:     $OpsMgr12MgmtSrvSvcArray = @("System Center Data Access Service", "System Center Management", "System Center Management Configuration")

 214:  

 215:     ForEach ($svc in $OpsMgr12MgmtSrvSvcArray)

 216:         {

 217:             write-host "Starting service $svc on $Env:ComputerName..."

 218:             $SCOpsMgrSvc = Get-Service | ? { $_.DisplayName -eq $svc}

 219:             If ($SCOpsMgrSvc.Status -ne "Running")

 220:                 {

 221:                     Start-Service -DisplayName $svc

 222:                     Do

 223:                         { 

 224:                             Start-Sleep -s 15

 225:                             $SCOpsMgrSvc = Get-Service | ? { $_.DisplayName -eq $svc}

 226:                         } Until ($SCOpsMgrSvc.Status -eq "Running")

 227:                 }

 228:             write-host "The service $svc is started on $Env:ComputerName."             

 229:         

 230:         }

 231:  } # End Invoke-Command for starting Management Server services

 232:  

 233:  write-host "Script Complete."

One thing that is not automated in this script is the reconfiguration of the Operations Manager Report Server SQL Reporting Services configuration. If the SSRS ReportServer and ReportServerTemp is being moved as well to a different SQL Server, you will have to manually go into the SQL Reporting Services Configuration Manager and attach that instance of SSRS to the correct SQL Server.

This is a version 1.0 development effort provided to the community. If you have any additions to include and/or questions feel free to email me.

Thanks,

Phil Gibson

OpsMgr2012-AutoMoveDBs.ps1

Recently I’ve been doing a lot of work in highly secure environments containing extremely hardened GPOs and isolated networks. As I was working with a customer to deploy System Center Operations Manager 2012 to monitor some highly critical machines, I noticed that the installation was giving us an error and would not complete.

After further investigation I looked into the OpsMgrSetupWizard.log and noticed the following lines:

Debug:    :StartService: attempting to start service OMSDK
Error:       :StartService: Could not get service status.: Threw Exception.Type: System.InvalidOperationException, Exception Error Code: 0x80131509, Exception.Message: Cannot start service OMSDK on computer '.'.

and

Info:trying to connect with server <Your Server>
Info:Error while connecting to management server: The Data Access service is either not running or not yet initialized.   

After some additional further investigation of the errors I came across KB2730040 ( https://support.microsoft.com/kb/2730040 ) that spoke about the System Center Data Access service (OMSDK) failing to start with a TimeOut error due to applying the KB2677070 patch to the server. I double checked the server to see if the patch had indeed been installed, but it was not listed and I wasn’t sure if it had been superseded in another patch. In the more information section of KB2730040 it spoke about URLs being changed to contact Windows Update to download trusted and untrusted CTLs. Knowing that I was in a isolated network, I went ahead and disabled the CRL checking as described in the KB and it resolved the issue. There’s some timing that has to take place to get through this smoothly so I documented my steps to get a successful installation of System Center Operations Manager 2012 in a completely offline and/or isolated network environment that doesn’t have access to the internet.

NOTE: Since I already had a failed installation I was able to copy the Microsoft.Mom.Sdk.ServiceHost.exe.config file and make the required edits, discussed in KB2730040, to it for use for my next installation. If this will be a fresh install for you, I’ve attached the modified version of the file to use. This file is not installation or machine specific, so you should not have any issues utilizing my file for your installations.

Step 1: Start your installation as normal

Step 2: At the point when the installation gets to the Management server task, either copy the edited version of  Microsoft.Mom.Sdk.ServiceHost.exe.config to your clipboard or be prepared to open the file and make the edits during the installation.

Step 3: Open the path to the Microsoft.Mom.Sdk.ServiceHost.exe.config. In my test lab installation this was C:\Programs Files\System Center 2012\Operations Manager\Server. If you have taken the default path during installation the only difference should be your drive letter. Make sure that you allow the installation to create this file first so that you can overwrite it with the modified version.

Step 4:  Overwrite the Microsoft.Mom.Sdk.ServiceHost.exe.config or edit it like the following examples:

Overwrite

Edit Microsoft.Mom.Sdk.ServiceHost.exe.config

 

Step 5: You should now be able to observe the OpsMgrSetupWizard.log file showing the OMSDK service started

You should now have a successful installation of System Center Operations Manager 2012 in a offline environment that does not connect to the internet.

Microsoft.Mom.Sdk.ServiceHost.exe.config

This is Part 2 in my series “Using System Center 2012 for Host Cluster Remediation (Patching) and Host Cluster VM Rebalancing”, and this post will focus on rebalancing your VMs to their original host after you have done a Host Remediation to your Microsoft Private Cloud infrastructure using System Center Virtual Machine Manager 2012. Again this solution involves using System Center products Virtual Machine Manager 2012, System Center Operations Manager 2012, and System Center Orchestrator 2012. The script in this post, just as in Part 1, are intended to run in a System Center Orchestrator 2012 runbook, but you can alter the script to run it in your environment without Orchestrator, but you will need System Center Virtual Machine Manager 2012.

Prerequisites

The following script assumes that you have utilized the SCVMMClusterRemediation.ps1 Windows PowerShell script from the Part 1 post of this series to automate your Microsoft Private Cloud Host Remediation. If you have not utilized that script, or a variation of that script, to populate the Custom Fields of your VM with the VM Host name then this script will not be able to rebalance the VMs back to running on their original VM Host they were prior to the System Center Virtual Machine Manager 2012 Host Remediation job. To prepare your Microsoft Private Cloud VMs to utilize the following script please see the Part 1 post in this series at https://blogs.technet.com/b/phillipgibson/archive/2012/05/09/using-system-center-2012-for-host-cluster-remediation-patching-and-host-cluster-vm-rebalancing-part-1-of-many.aspx.

The VM Rebalancing Script Breakdown

Below is the VM rebalancing script that you can run against your Microsoft Private Cloud Hyper-V host clusters in your System Center Virtual Machine Manager 2012 environment after the VMs have been tagged with their VM Host server in their Custom Field 1 property. Prior to running this script you should check the properties of your VMs to ensure they have their original VM Host name populated in the Custom1 field they were running on prior to the host cluster remediation. The properties of the VM should look similar to the picture below. 

Unlike the Windows PowerShell script in Part 1 of the series (SCVMMClusterRemediation.ps1) the SCVMMClusterVMRebalance.ps1 is much less involved and doing less so I will not document it so thoroughly as I’ve done for the previous script. Overall this script is just running against the VM Host Clusters you filter on, enumerating all VMs on each node of the Host Cluster, and running the SCVMM PowerShell cmdlet Move-SCVirtualMachine to the Host Cluster node listed in the Custom1 field of the VM. That activity is specifically happening from Lines 68-90 and when this script runs you should see SCVMM job activity similar to the picture below. I’ve removed private data out of the picture such as the VM name and the Host Cluster Nodes.

Another key thing the script is doing is writing the Move-SCVirtualMachine SCVMM Job GUID to the event log (Line 85). Again, that SCVMM Job GUID will be used in the total solution to monitor the result of the SCVMM Job, with a runbook that get initiated when that event is written.

The next post in this series (Part 3) will focus on automating these scripts utilizing System Center Orchestrator 2012 runbooks. The runbooks will detail how the solution is scheduled, how the SCVMM Job GUIDs are captured for monitoring, and how I use the VM Host time zone properties to ensure that Host Clusters are patched during a specific time local to the Host Cluster.

As always feel free to post your comments or questions. You can also email me too.

Phil Gibson | Senior Consultant | Microsoft | System Center & Private Cloud Infrastructure & Development

Prerequisites

The following script assumes that you have already configured your System Center Virtual Machine Manager 2012 server with an Update Server. If you have not done this, please follow the guidance on managing fabric updates for System Center Virtual Machine Manager 2012 https://technet.microsoft.com/en-us/library/gg675084.aspx.

The Remediation Script Breakdown

Below is the remediation script that you can run against your Hyper-V host clusters in your System Center Virtual Machine Manager 2012 environment. One thing to note is that this script is intended to run as a runbook in System Center Orchestrator 2012 using the SCVMM 2012 Integration Pack. When using the run SCVMM script object you do not need to import the VirtualMachineManager module for Virtual Machine Manager 2012 because the object configuration does this for you. If you do want to utilized this script outside of Orchestrator 2012 you will have to add the Import-Module VirtualMachineManager to the script. The script itself is somewhat busy, but it will automate all the key activities needed to make the process 100% completely automated using System Center Orchestrator 2012. I will detail out the major parts in the script so that you can feel comfortable and confident using it in your Microsoft Private Cloud environments. Because the script is well documented, I will only explain the major parts. The script will also be available to download as a zip file.

Lines 12 – 97  - The script contains four globally declared functions WriteEvent, VMHostTimeZone, VMHostComplianceStatus, and UpdateRemediationBaseline. The functions are well documented and I will discuss them in more detail when the script uses them. For a quick description of the functions the WriteEvent function is used for tracing the script activity and logging to the event log. The VMHostTimeZone function will translate the VMHost time zone metric to the configured three letter time zone. The VMHostComplianceStatus function will initiate a compliancy status against VM Host Cluster. The UpdateRemediationBaseline function will add the VM Host Cluster to the approved baseline.

Lines 100 – 107  - Setting the error action setting for the PowerShell script. There are also two global variable being declared for the time zone and the baseline. These are static entries now, but when we move the script into System Center Orchestrator they will be variables using published data in the data bus.

Line 112 - Starts the Try,Catch in the scripts and does the search Where clause for the Host Clusters you are looking to target. You will have to edit this for your environment.

Line 125 – Ensures the Host Cluster is assigned to a baseline

Line 137 – Verifying the Nodes in the Host Cluster are in the required time zone.

Line 142 – Checking to see if the VM Host is not compliant. If compliant it is skipped and not added to the Job Group

Line 147 – 152 – This is a ForEach loop that will got through all the VMs on the VM Host and add the VM Host information to the Custom Field 1 property of the VM. This will be used in a later script to return the VM to the host it was running on prior to remediation. After the script runs through remediation, you will notice the Custom1 Property of the VM listed with the VM Host name that the VM is currently running on.

Line 158 – 170 – This is a sequence to determine if the VM has the DVD drive mounted and then unmounts the the DVD drive if mounted on the VMs

Line 177 – Add the VM Host node of the VM Host Cluster to the Job Group if found not compliant.

Line 196 – Initiate the VM Host Cluster Remediation Job in SCVMM

Line 197 – Writing out the SCVMM Job GUID to the event log for System Center Operations Manager to monitor and execute a System Center Orchestrator runbook that will monitor the SCVMM Job until complete and report status. You will see this detailed out in later posts on this series.

Line 213 – Script Complete

Feel free to post your comments or questions. You can also email me too.

Phil Gibson | Senior Consultant | Microsoft | System Center & Private Cloud Infrastructure & Development

I recently attended and participated in the Microsoft Management Summit 2011 (MMS 2011) in Las Vegas, NV. While I was working at the Datacenter Services booth I was approached by a guy that asked me a question "Hey is there any way to use .NET code in a management pack?" I responded and told him that there's nothing native that supports using .NET code, but since the arrival of R2 there is a native PowerShell provider that will allow you to do pretty much everything in .NET in PowerShell. After a lengthy conversation I was then left with the curiosity of can it be done? Is there an easy supportable and efficient way to implement .NET code in a management pack? The answer is YES! This post will provide an overview of how I accomplished the task.

The PowerShell Add-Type Cmdlet (The secret sauce)

When I started to research this possibility, I discussed this with a co-worker Don and he led me to the PowerShell Add-Type cmdlet ( https://technet.microsoft.com/en-us/library/dd315241.aspx) . This cmdlet allows you to define a .NET class in your PowerShell script. As you can see from the TechNet example below, you simply create a variable and encapsulate your .NET code within the @" <.NET code here> ". You can then instantiate your class for use.

C:\PS>$source = @"

public class BasicTest

{

    public static int Add(int a, int b)

    {

        return (a + b);

    }

    public int Multiply(int a, int b)

    {

        return (a * b);

    }

}

"@

C:\PS> Add-Type -TypeDefinition $source

C:\PS> [BasicTest]::Add(4, 3)

C:\PS> $basicTestObject = New-Object BasicTest

C:\PS> $basicTestObject.Multiply(5, 2)

Creating the PowerShell Script

Now that I have an understanding of how to encapsulate .NET code in a PowerShell script, I now need to come up with an example to use. I've found this to be the most challenging part because everything I could code in .NET I could do in PowerShell and in most cases with much less lines of code. So I decided to go with a common example in the management pack documentation, I will return the number of files in a folder.  This is the C# class I will use below.

public static int FileCount(string FolderName)

        {

            string s = FolderName;

            int files;

            System.IO.DirectoryInfo f = new System.IO.DirectoryInfo(FolderName);

            files = f.GetFiles().Length;

            return files;

        }

So from looking at the C# class, it is roughly 8 lines of code. Compared to doing the functionality in PowerShell in one line of code like this (Get-ChildItem C:\Temp).Count . Again if it was me I would just write a PowerShell script and use the native script module provider in R2, but since this post is about using .NET code in a management pack we will continue on. Also one thing to note is I had to fully qualify my method calls such as System.IO.DirectoryInfo whereas if you are using a directive such as "using System.IO;" I could just call DirectoryInfo instead of System.IO.DirectoryInfo. I'm sure there's a way to utilize directives, but I just did not investigate all the Add-Type cmdlet options and in my testing the script didn't work when using it.

Now that I know what I want to monitor and have my .NET C# class, I now need to put it in a script for Operations Manager to consume.  Below is the PowerShell script containing the .NET C# class that I will use when creating the management pack.

param([string]$MonitoredFolder)

$api = New-Object -comObject 'MOM.ScriptAPI'

$api.LogScriptEvent("CheckFolderFileCount.ps1",101,4,"Script started.")

$api.LogScriptEvent("CheckFolderFileCount.ps1",101,4,"The monitored folder is $MonitoredFolder")

$bag = $api.CreatePropertyBag()

$CSharpCode = @"

public class Folder

{

    public static int FileCount(string FolderName)

        {

            string s = FolderName;

            int files;

            System.IO.DirectoryInfo f = new System.IO.DirectoryInfo(FolderName);

            files = f.GetFiles().Length;

            return files;

        }

}

"@

Add-Type -TypeDefinition $CSharpCode

$api.LogScriptEvent("CheckFolderFileCount.ps1",101,4,"The amount of files in $MonitoredFolder is {0}" -f [Folder]::FileCount($MonitoredFolder))

$bag.AddValue('FolderFileCount', '[Folder]::FileCount($MonitoredFolder)')

$bag

$api.LogScriptEvent("CheckFolderFileCount.ps1",101,4,"Script complete.")

Part 2 of this post will discuss implementing the script into a custom management pack.