By Ruben is back with another awesome blog post, and I have no doubt this one is going to help a lot of people!
We all know the hassles of migrating your SCOM from one version to another, and it involves a lot of manual efforts. And especially so when you choose the side-by-side upgrade path. Making sure you have all the Management Packs re-imported, all overrides are intact, making sure all permissions to various users you’ve assigned over the years are still in place, etc just to mention a few examples. We’ve all wished how great it would be if you could run some kind of script and it’ll do it all for us. Well, this is exactly what Ruben has made available for us! Here, take a look:
Preface
Migrating from SCOM 2012 R2 to SCOM 1801 isn’t a stressful job as both environments can live in parallel.
This blog gives examples how to migrate the configuration from A to B by trying to leverage PowerShell whenever possible / reasonable.
Please apply the PowerShell code only if you feel comfortable with it. If there are questions, please don’t hesitate to drop me a line.
Introduction
Although it is possible letting the agent do duplicate work in the sense of executing code in management packs, sending data to different management groups can cause excessive resource consumption on the monitored computer.
I suggest:
- Migrate configuration to 1801 from 2012 R2 (blog topic)
- Test with a very small amount of machine of different types (Application Servers, Web Servers, MSSQL, Exchange, Domain Controllers)
- Move the remaining, majority to 1801
- Change connectors to ticket systems, alert devices other peripheral systems
- Remove the agent connections from 2012 R2 (see below for details)
- Monitor the new environment for a while, if all fine decommission 2012 R2
Requirements
- 1801 is setup fully functional and first agents have been deployed successfully.
- Windows PowerShell 5.1 is required on the 2012 R2 and on the 1801 server
- Service Accounts used in 2012 R2 will be re-used. – If they are different in 1801 it is no big obstacle to change them if they are overwritten by one of the import steps.
- Usually SCOM will alert if there is misconfiguration such a lack of permission somewhere.
Migration
Below now the steps separated in the different parts. – No guarantee for complete- or correctness.
Management Packs
Migrating to a new environment is always a great chance to perform cleanup and apply the lessons you’ve learned in the old one.
Review
Export all Management Packs from the current SCOM environment and review.
Get-SCOMManagementPack | Select-Object -Property Name, DisplayName, TimeCreated, LastModified, Version | Export-Csv -Path C:\temp\CurrentMps.csv -NoTypeInformation
For your convenience use Excel to open the CSV file. Import only those Management Packs which bring measurable benefit.
Overrides
Standard Approach
If you have followed best practices you have created Override Management Packs for each Management Pack to store your customizations. Export those and import them into your new environment.
Note: Verify that the overrides work as expected.
Green field approach
In case you have stored the all overrides only in one Management Pack or want to be more selective follow these steps
- Create a new Override Management Pack for that specific MP and name it properly.
- E.g. <YourCompayName>.Windows.Server.Overrides
- Follow the steps mentioned in ‘Management Pack tuning’.
https://anaops.wordpress.com/2018/06/22/guest-blog-management-pack-tuning-ruben-zimmermann/
- E.g. <YourCompayName>.Windows.Server.Overrides
Notification Settings (Channels, Subscribers and Subscriptions)
Quoted from: http://realscom.blogspot.de/2017/05/migrate-notifications-to-another.html
- Export the Microsoft.SystemCenter.Notifications.Internal mp in the old and new management groups – do not modify these, they are our backup copies
- Make a copy of both files and rename them to something meaningful like Microsoft.SystemCenter.Notifications.Internal.ManagementGroupName_backup.xml
- Make a note of the MP version number of the Microsoft.SystemCenter.Notifications.Internal MP from the new management group. In my case it was 7.2.11719.0
- Open up the Microsoft.SystemCenter.Notifications.Internal.xml file for the old management group and change the version number to that of the new management group MP version + 1. In my case I changed it from 7.0.9538.0 to 7.2.11719.1. This is so the MP imports properly in the new management group
Exporting Configuration with PowerShell
Open a PowerShell console on the 2012 R2 Management Server and use the following cmdlets to store the information to C:\Temp\ResolutionStates.json
Alert Resolution State
Only user defined resolution states are exported.
Get-SCOMAlertResolutionState | Where-Object {$_.IsSystem -eq $false} | Select-Object Name, ResolutionState | ConvertTo-Json | Out-File C:\Temp\ResolutionStates.json
Alert Auto – Resolution Settings
Limited to the properties AlertAutoResolveDays and HealthyAlertAutoResolveDays
Get-SCOMAlertResolutionSetting | Select-Object AlertAutoResolveDays, HealthyAlertAutoResolveDays | ConvertTo-Json | Out-File C:\Temp\SCOMExport\AlertResolutionSetting.json
Database Grooming Settings (hint to dwarp! Plus link)
Exports data retention settings for information in the OperationsManager database. The DataWareHouse database is covered later.
Get-SCOMDatabaseGroomingSetting | Select-Object AlertDaysToKeep, AvailabilityHistoryDaysToKeep,EventDaysToKeep,JobStatusDaysToKeep,MaintenanceModeHistoryDaysToKeep,MonitoringJobDaysToKeep,PerformanceDataDaysToKeep,PerformanceSignatureDaysToKeep,StateChangeEventDaysToKeep | ConvertTo-Json | Out-file C:\Temp\SCOMExport\DatabaseGrooming.json
User Roles
Exporting User roles and System roles into dedicated files.
Get-SCOMUserRole | Where-object {$_.IsSystem -eq $false } | Select-Object -Property Name, ProfileDisplayName, Users | ConvertTo-Json | Out-File C:\Temp\SCOMExport\UserRoles.json
Get-SCOMUserRole | Where-object {$_.IsSystem -eq $true } | Select-Object -Property Name, ProfileDisplayName, Users | ConvertTo-Json | Out-File C:\Temp\SCOMExport\SystemUserRoles.json
Run As Accounts
Exporting user defined RunAsAccounts. System defined ones are created by Management Packs.
Get-SCOMRunAsAccount | Where-Object {$_.isSystem -eq $false} | Select-Object -Property AccountType, UserName, SecureStorageId, Name, Description, SecureDataType | ConvertTo-Json | Out-File C:\Temp\SCOMExport\RunAsAccounts.json
<# The cmdlet 'Get-SCOMRunAsAccount' can't extract credential information. A free cmdlet, written by Stefan Roth is required for that. – Import it to your 2012 R2 environment before proceeding with the following lines. https://www.powershellgallery.com/packages/RunAsAccount/1.0 #>
Get-SCOMRunAsAccount | Select-Object -ExpandProperty Name | ForEach-Object {
try {
$theName = $_
$theTmp = Get-RunAsCredential -Name $theName
$thePass = ($theTmp.Password).ToString()
$thePass
$secPass = ConvertTo-SecureString $thePass -AsPlainText -Force
$theCreds = New-Object -TypeName System.Management.Automation.PSCredential($theName,$secPass)
$theCreds | Export-Clixml -Path "C:\temp\SCOMExport\$theName.cred"
$fileName = "C:\temp\SCOMExport\" + $theName + ".txt"
"$($thePass)" | Out-File -FilePath $fileName
} catch {
$info = 'Swallowing exception'
}
}
Importing Configuration with PowerShell
Copy the JSON files to the 1801 Management Server (C:\Temp\SCOM-Scripts) and import using the following code:
Alert Resolution State
$jsonFileContent = Get-Content -Path C:\Temp\SCOM-Scripts\ResolutionStates.json | ConvertFrom-Json
foreach ($aState in $jsonFileContent) {
Add-SCOMAlertResolutionState -Name $aState.Name -ResolutionStateCode $aState.ResolutionState
}
Alert Resolution Setting
$jsonFileContent = Get-Content -Path C:\Temp\SCOM-Scripts\AlertResolutionSetting.json | ConvertFrom-Json Set-SCOMAlertResolutionSetting -AlertAutoResolveDays $jsonFileContent.AlertAutoResolveDays -HealthyAlertAutoResolveDays $jsonFileContent.HealthyAlertAutoResolveDays
Database Grooming Settings
$jsonFileContent = Get-Content -Path C:\Temp\SCOM-Scripts\DatabaseGrooming.json | ConvertFrom-Json Set-SCOMDatabaseGroomingSetting -AlertDaysToKeep $jsonFileContent.AlertDaysToKeep -AvailabilityHistoryDaysToKeep $jsonFileContent.AvailabilityHistoryDaysToKeep -EventDaysToKeep $jsonFileContent.EventDaysToKeep Set-SCOMDatabaseGroomingSetting -JobStatusDaysToKeep $jsonFileContent.JobStatusDaysToKeep -MaintenanceModeHistoryDaysToKeep $jsonFileContent.MaintenanceModeHistoryDaysToKeep -MonitoringJobDaysToKeep $jsonFileContent.MonitoringJobDaysToKeep Set-SCOMDatabaseGroomingSetting -PerformanceDataDaysToKeep $jsonFileContent.PerformanceDataDaysToKeep -PerformanceSignatureDaysToKeep $jsonFileContent.PerformanceSignatureDaysToKeep -StateChangeEventDaysToKeep $jsonFileContent.StateChangeEventDaysToKeep
User Roles
# Importing User roles and System roles from dedicated files. – Review them first.
$jsonFileContent = Get-Content -Path C:\Temp\SCOM-Scripts\UserRoles.json | ConvertFrom-Json
foreach ($uRole in $jsonFileContent) {
switch ($uRole.ProfileDisplayName) {
'Advanced Operator' {
Add-SCOMUserRole -Name $uRole.Name -DisplayName $uRole.Name -Users $uRole.Users -AdvancedOperator
}
'Author' {
Add-SCOMUserRole -Name $uRole.Name -DisplayName $uRole.Name -Users $uRole.Users -Author
}
'Operator' {
Add-SCOMUserRole -Name $uRole.Name -DisplayName $uRole.Name -Users $uRole.Users -Operator
}
'Read-Only Operator' {
Add-SCOMUserRole -Name $uRole.Name -DisplayName $uRole.Name -Users $uRole.Users -ReadOnlyOperator
}
}
}
$jsonFileContent = Get-Content -Path C:\Temp\SCOM-Scripts\SystemUserRoles.json | ConvertFrom-Json
foreach ($sRole in $jsonFileContent) {
if ($sRole.Users) {
Get-SCOMUserRole | Where-Object {$_.Name -eq $sRole.Name} | Set-SCOMUserRole -User $sRole.Users
} else {
continue
}
}
Run As Accounts
# Importing User roles and System roles from dedicated files. – Review them first.
$jsonFileContent = Get-Content -Path C:\Temp\SCOM-Scripts\RunAsAccounts.json | ConvertFrom-Json
foreach($rAccount in $jsonFileContent) {
$theName = $rAccount.Name
if ($theName -match 'Data Warehouse') {
write-warning "Skipping default account $theName"
continue
}
switch ($rAccount.AccountType) {
'SCOMCommunityStringSecureData' {
$credFile = Get-Content -Path "C:\Temp\SCOM-Scripts\creds\$theName.txt"
$secPass = ConvertTo-SecureString $credFile -AsPlainText -Force
Add-SCOMRunAsAccount -CommunityString -Name $theName -Description $rAccount.Description -String $secPass
}
'SCXMonitorRunAsAccount' {
try{
$thePass = Get-Content -Path "C:\Temp\SCOM-Scripts\creds\$theName.txt"
$secPass = ConvertTo-SecureString $thePass -AsPlainText -Force
$theCreds = New-Object -TypeName System.Management.Automation.PSCredential($theName,$secPass)
Add-SCOMRunAsAccount -SCXMonitoring -Name $theName -Description $rAccount.Description -RunAsCredential $theCreds -Sudo
} catch {
Write-Warning $_
}
}
'SCXMaintenanceRunAsAccount' {
try{
$thePass = Get-Content -Path "C:\Temp\SCOM-Scripts\creds\$theName.txt"
$secPass = ConvertTo-SecureString $thePass -AsPlainText -Force
$theCreds = New-Object -TypeName System.Management.Automation.PSCredential($theName,$secPass)
Add-SCOMRunAsAccount -SCXMaintenance -Name $theName -Description $rAccount.Description -RunAsCredential $theCreds -Sudo
} catch {
Write-Warning $_
}
}
'SCOMBasicCredentialSecureData' {
try{
$thePass = Get-Content -Path "C:\Temp\SCOM-Scripts\creds\$theName.txt"
$secPass = ConvertTo-SecureString $thePass -AsPlainText -Force
$theCreds = New-Object -TypeName System.Management.Automation.PSCredential($theName,$secPass)
Add-SCOMRunAsAccount -Basic -Name $theName -Description $rAccount.Description -RunAsCredential $theCreds
} catch {
Write-Warning $_
}
}
'SCOMWindowsCredentialSecureData' {
try{
$thePass = Get-Content -Path "C:\Temp\SCOM-Scripts\creds\$theName.txt"
$secPass = ConvertTo-SecureString $thePass -AsPlainText -Force
$theName = $env:USERDOMAIN + '\' + $rAccount.Name
$theCreds = New-Object -TypeName System.Management.Automation.PSCredential($theName,$secPass)
Add-SCOMRunAsAccount -Windows -Name $theName -Description $rAccount.Description -RunAsCredential $theCreds
} catch {
Write-Warning $_
}
}
default {
Write-Warning "Not coverd: $rAccount.AccountType please add manually."
}
}
}
Run As Profiles
Run As Profiles usually come with Management Packs and therefore not handled here.
Note:
Run As Profiles are the binding component between Run As Account and the Object (e.g. a Computer / Health State) they are used. Please check the configuration in the 2012 R2 environment to setup the mapping and distribution manually.
Datawarehouse Retention Settings
Datawarehouse retention settings are configured with a cmdline tool named dwdatarp.exe. It was released in 2008 and works since then.
Download link can be found here: https://blogs.technet.microsoft.com/momteam/2008/05/13/data-warehouse-data-retention-policy-dwdatarp-exe/
Checking the current settings
After downloading, copy the unpacked executable to your SCOM – database server (e.g. C:\Temp).
Open an elevated command prompt and use the following call to export the current configuration:
dwdatarp.exe -s OldSCOMDBSrvName -d OperationsManagerDW > c:\dwoutput.txt
Setting new values
The following values are just a suggestion to reduce the amount or required space.
dwdatarp.exe -s newscomdbsrv -d OperationsManagerDW -ds "Alert data set" -a "Raw data" -m 180
dwdatarp.exe -s newscomdbsrv -d OperationsManagerDW -ds "Client Monitoring data set" -a "Raw data" -m 30
dwdatarp.exe -s newscomdbsrv -d OperationsManagerDW -ds "Client Monitoring data set" -a "Daily aggregations" -m 90
dwdatarp.exe -s newscomdbsrv -d OperationsManagerDW -ds "Configuration dataset" -a "Raw data" -m 90
dwdatarp.exe -s newscomdbsrv -d OperationsManagerDW -ds "Event data set" -a "Raw Data" -m 30
dwdatarp.exe -s newscomdbsrv -d OperationsManagerDW -ds "Performance data set" -a "Raw data" -m 15
dwdatarp.exe -s newscomdbsrv -d OperationsManagerDW -ds "Performance data set" -a "Hourly aggregations" -m 30
dwdatarp.exe -s newscomdbsrv -d OperationsManagerDW -ds "Performance data set" -a "Daily aggregations" -m 90
dwdatarp.exe -s newscomdbsrv -d OperationsManagerDW -ds "State data set" -a "Raw data" -m 15
dwdatarp.exe -s newscomdbsrv -d OperationsManagerDW -ds "State data set" -a "Hourly aggregations" -m 30
dwdatarp.exe -s newscomdbsrv -d OperationsManagerDW -ds "State data set" -a "Daily aggregations" -m 90
Agent Migration – Remove the older Management Group
After the computer appears as fully managed computer in the SCOM console, remove the older Management group.
Jimmy Harper has authored a Management Pack which helps to clean-up the agent migration after the new agent has been deployed. Please read through:
This is great! Thanks a lot Ruben, for taking the time and efforts to put this all together!
Get to know more about Ruben here!
Cheers!
AnalyticOps Insights 