Articles in the "Reboot script for Exchange environment" series
- Patch and reboot script for an entire Exchange environment, Part 1
- Patch and reboot script for an entire Exchange environment, Part 2
- Patch and reboot script for an entire Exchange environment, Part 3 [This article]
- Patch and reboot script for an entire Exchange environment, Part 4
- Patch and reboot script updated to version 2.1
- Patch and reboot script updated to v2.4
The first part of the script body gets the current window title, then checks if transcript is running, starting it if not.
1 2 3 4 5 6 7 |
#Region Script Body $savedTitle = $Host.UI.RawUI.WindowTitle if (!($global:transcriptIsRunning)) { Start-Transcript -Path $transcriptLog -Append $global:transcriptIsRunning = $true } |
Since the script can’t use remote PowerShell to connect to an Exchange server that will be rebooted, the snap-in is loaded locally.
1 2 3 |
#Load Exchange 2010 snap-in if (-not (Get-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010 -ErrorAction SilentlyContinue)) {Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010} |
If the SCOM variable is set to true, then the remote PowerShell connection to the RMS is loaded.
1 2 3 4 5 |
if ($bUpdateSCOM) { WriteTime;Write-Host 'Option: SCOM maintenance mode support enabled.' LoadSCOMShell } |
Throughout the script you will see that whenever something is output to the console it is prefixed with the time. This is accomplished with a function to format it the way I want to see it.
1 2 3 4 5 |
function WriteTime { $a = Get-Date -Format g Write-Host "$a`: " -NoNewline } |
This is the function to connect to the SCOM RMS:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
function LoadSCOMShell { WriteTime;Write-Host 'Creating remote session to SCOM server...' $ErrorActionPreference = 'Stop' try { $global:scomSession = New-PSSession -ComputerName $rmsName Invoke-Command -ScriptBlock {Add-PSSnapin 'Microsoft.EnterpriseManagement.OperationsManager.Client'} -Session $global:scomSession Invoke-Command -ScriptBlock {Set-Location 'OperationsManagerMonitoring::'} -Session $global:scomSession Invoke-Command -ScriptBlock {param($rmsName) New-ManagementGroupConnection -connectionString:$rmsName | Out-Null} -Session $global:scomSession -ArgumentList $rmsName Invoke-Command -ScriptBlock {param($rmsName) Set-Location $rmsName} -Session $global:scomSession -ArgumentList $rmsName Invoke-Command -ScriptBlock {$monClass = Get-MonitoringClass | Where-Object {$_.DisplayName -eq 'Windows Server'}} -Session $global:scomSession WriteTime;Write-Host "Successfully created remote session to SCOM server." -ForegroundColor Green $global:bSCOMSessionOpen = $true } catch { WriteTime;Write-Host 'Error: Unable to create remote session to SCOM server...' -ForegroundColor Red $global:bSCOMSessionOpen = $false } $ErrorActionPreference = 'Continue' } |
The function creates a new session to the RMS, scoping the variable as $global so that if the script aborts and you restart it in the same shell, the session can still be used instead of creating a new one. Once the session is established, several script blocks are executed in it to load the SCOM snap-in and configure it so that a server can be put into maintenance mode. It took some time to figure out how to do all this because the PowerShell documentation for SCOM is very poor and code samples on other sites were for working with clusters or doing other tasks. If no error occurs during any of this, a variable is set to indicate that the session is working. If an error does occur, the script does not abort. I only treat this as a warning since an inability to put a server into maintenance shouldn’t keep the server from being patched. The status variable is set so that the script won’t try and put servers into maintenance mode if doing so will only result in an error anyway.
The next post in the series will get into the actual processing of the servers.
Download the complete script:
Reboot-ExchangeServers.zip (7.5 KiB)