Monthly Archives: November 2012

Group Maintenance Mode PowerShell Script Updated

Written by Tao Yang

Update – 07, Dec, 2012: the script in this post has been updated to address 2 bugs explained here: Bug Fixes for the Group Maintenance Mode Script

Steve Rachui has posted a wonderful PowerShell script to place a group into maintenance mode in SCOM: Place a Group in Maintenance Mode with PowerShell back in 2010.

I’ve updated the script today to use SDK rather than SCOM 2007 PS Snap-in so the script works on both SCOM 2007 and OM12.

I’ve also made few other changes including change the duration from number of hours to number of minutes to suit my needs.

Here’s the script:

#===========================================================================================
# AUTHOR: Tao Yang
# Script Name: GroupMaintenanceMode.ps1
# DATE: 20/11/2012
# Version: 1.1
# COMMENT: - Script to place a group into maintenance mode (at once) using SDK
# - Update History:
# 1.1 - Bug fix when the group is already in maint. mode condition
# - Added Recursive switch when creating maint. mode to ensure
# group members are also placed into maint. mode.
#===========================================================================================
Param (
[Parameter(Mandatory=$true)]
[string]$RMS,
[Parameter(Mandatory=$true)]
[string]$GroupName,
[Parameter(Mandatory=$true)]
[int]$DurationInMinutes,
[Parameter(Mandatory=$true)]
[string]$Comments)

#Region FunctionLibs
function Load-SDK()
{
 [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.OperationsManager.Common") | Out-Null
 [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.OperationsManager") | Out-Null
}
#EndRegion

#Firstly validate input
#duration has to be between 5 minutes and 2 years
IF ($DurationInMinutes -lt 5 -or $DurationInMinutes -gt 1051200)
{
 Write-Host "Invalid Duration entered. the duration has to be between 5 minutes and 2 years!"
 $host.setShouldExit(1)
}

#Connection to management group
Load-SDK
$MGConnSetting = New-Object Microsoft.EnterpriseManagement.ManagementGroupConnectionSettings($RMS)
$MG = New-Object Microsoft.EnterpriseManagement.ManagementGroup($MGConnSetting)
$query = "DisplayName= '$GroupName'"
$MonitoringClassCriteria = New-Object Microsoft.EnterpriseManagement.Configuration.MonitoringClassCriteria($query)
$GroupMonitoringClasses = $MG.GetMonitoringClasses($MonitoringClassCriteria)

If ($GroupMOnitoringClasses)
{
 Foreach ($Group in $GroupMonitoringClasses)
 {
 $StartTime = ([DateTime]::Now).ToUniversalTime()
 $EndTime = $StartTime.AddMinutes($DurationInMinutes)
 $MonitoringGUID = $Group.Id
 $MonitoringObject = $MG.GetMonitoringObject($MonitoringGUID)
 Write-Host "Monitoring Object GUID: $MonitoringGUID"
 Write-Host "Monitoring Object DisplayName: $($MonitoringObject.DisplayName)"
 If (!$MonitoringObject.InMaintenanceMode)
 {
 $Reason = "PlannedOther"
 Write-Host "Placing $($MonitoringObject.Displayname) into Maintenance Mode..." -ForegroundColor Green
 $MonitoringObject.ScheduleMaintenanceMode($StartTime, $EndTime, $Reason, $Comments, "Recursive")

 } else {
 $CurrentMaintWindow = $MonitoringObject.GetMaintenanceWindow()
 $CurrentEndTime = $CurrentMaintWindow.ScheduledEndTime
 $CurrentReason = $CurrentMaintWindow.Reason
 $CurrentComments = $CurrentMaintWindow.Comments
 If ($CurrentEndTime -lt $EndTime)
 {
 Write-Host &quot;Updating existing maintenance mode for $($MonitoringObject.DisplayName)<code>...&quot; -ForegroundColor Yellow
 $MonitoringObject.UpdateMaintenanceMode($EndTime, $CurrentReason, $CurrentComments)
 } else {
 Write-Host &quot;The end time of the existing Maintenance mode on $($MonitoringObject.DisplayName) is later than specified end time. The existing maintenance mode will not be updated</code>!&quot; -ForegroundColor Yellow
 }

 }
 }
} else {
 Write-Host &quot;Unable to find the monitoring object with the name <code>&quot;$GroupName</code>&quot;!&quot; -ForegroundColor Red
}

Or download the script HERE.

My First Impression on PowerShell Web Access

Written by Tao Yang

I ran up an instance of Windows Server 2012 in my test lab last night so I can play with various new features such as IPAM and PowerShell Web Access, etc.

Today I configured this box as the PowerShell Web Access (PSWA) gateway. I have to say, I am very very impressed! The implementation is easy, took me less than an hour (including time spent reading TechNet articles) and having ability to access PowerShell console on virtually any web browser for all Windows machines in my lab is just fantastic!

Now I can probably get away from using RDP most of the times since I’m pretty comfortable with PowerShell Smile

So, here are the steps I took to setup PSWA:

1. Add the PSWA feature in Server Manager

2. Install PSWA web application using PowerShell:

Install-PswaWebApplication

3. Requested and installed a SSL certificate for the PSWA gateway machine from my Enterprise CA

4. In IIS, configured HTTPS for the default web site and used the SSL certificate I just installed from previous step.

5. Created an AD group called PSWA_Users and added few user IDs into this group.

6. Create PSWA Authorization Rule:

Add-PSWAAuthorizationRule -UserGroupName Corp\PSWA_Users -Computername * -ConfigurationName *

image

7. Since I can’t guarantee that WinRM has been enabled and configured on every machine, I’ve created a GPO to enable WinRM and linked it to the domain root.

Now, PSWA is pretty much ready to go. I launch the web access console on Google Chrome and entered my credential and the computer that I wish to connect to:

image

And I’m in!

image

It’s great to see that Microsoft releases a web-based product that runs on browsers other than IE. I don’t think I’ve seen anything like this before!

Additional Configurations:

I started testing by connecting to a SCOM management server and tried to retrieve all SCOM agents in my management group (Only 11 in total so I’d assume not huge amount of data is returned). I used:

Import-Module OperationsManager

$a = Get-SCOMAgent

Interestingly, it failed and the connection to the management server was closed:

image

Error:

Processing data for a remote command failed with the following error message: The WSMan provider host process did not return a proper response. A provider in the host process may have behaved improperly.

This reminded me the default setting for “Maximum amount of memory in MB per Shell” for WinRM, which I blogged previously in this post. The default setting on Windows Server 2008 R2 and Windows 7 is 150MB. This default setting has increased to 1024MB on Windows Server 2012 and Windows 8.

So to test, since I have 3 management servers in the OM12 management group, I’ve increased this setting to 1024 on another management server. It fixed the error:

image

To further prove this error is actually caused by not having enough memory for the remote shell, I’ve connected PSWA to a Windows 8 machine, which has OM12 console and command shell installed. I used the following commands to connect to the OM12 management group:

Import-Module OperationsManager

New-SCManagementGroupConnection OpsMgrMS03

It prompted an error saying I don’t have sufficient permission:

image

This is by design, when using second hop in CredSSP, the credential has to be explicitly specified. so I changed the command to:

New-SCManagementGroupConnection OpsMgrMS03 –Credential (Get-Credential domain\MyID)

after entering the password, I was successfully connected and I managed to retrieve all SCOM agents by using Get-SCOMAgent Cmdlet without issues.

image

So to fix this issue once for all, I’ve modified the GPO I’ve just created and changed the “Maximum amount of memory in MB per Shell” setting to 1024.

Click here to see settings defined in my WinRM GPO.

I also configured another port forwarding rule on my ADSL router to forward port 443 to the PSWA gateway computer so I can connect when I’m not home.

PSWA on Mobile Devices:

I am able to launch and use PSWA on both my Android tablet (Samsung Galaxy Tab 10.1v running ICS) and my wife’s iPad 3 (running iOS 6) using both built-in browsers and Google Chrome on both devices.

Below are few screenshots from my Galaxy Tab:

image

image

Maybe it’s just me being an Apple noob, when I’m on the iPad, I could not find the Tab key on the keyboard, so I couldn’t use the PowerShell auto completion feature. – One more reason that I’m staying away from that product!

Console Size:

by default, the console size is 120×35, which seems like a waste of space when I’m on a big screen.

So I wrote a simple PowerShell script called Resize-Console.ps1 to resize the window:

$bufferSize = $Host.UI.RawUI.BufferSize
$buffersize.Width = 180
$host.UI.RawUI.BufferSize = $buffersize

$WindowSize = $host.UI.RawUI.WindowSize
$WindowSize.Width = 180
$WindowSize.Height = 40
$host.UI.RawUI.WindowSize = $WindowSize

After I ran this script, the console fits perfectly on my Galaxy tab (resolution 1280×800):

image

This console size also works great on my laptop, which has the resolution of 1366×768. For different resolutions, the width and height need to be adjusted in the script. the only catch is the buffersize cannot be less than the window size (I set the width for both sizes to be the same).

I haven’t managed to work out a automated way to resize the console as when in a PS remote session, there is no $profile so I can’t add scripts into $profile like we normally do on a local console. If I find a way in the future, I’ll post it here.

This is what I found so far. I’ll continue to blog on this topic if I find any other interesting stuff!

By the way, I followed this TechNet article to configure the PSWA: Deploy Windows PowerShell Web Access