Scom Maintenance mode scheduler

#SCOM Maintenance mode scheduler. The assemblies can be found in this folder on your management servers  C:\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\SDK Binaries

$scriptdir = Get-location
$ScriptDir = split-path -parent $MyInvocation.MyCommand.Path
$void = [System.Reflection.Assembly]::LoadFile("$scriptdir\Microsoft.EnterpriseManagement.OperationsManager.dll")
$void3 = [System.Reflection.Assembly]::LoadFile("$scriptdir\Microsoft.EnterpriseManagement.Runtime.dll")
$void1 = [System.Reflection.Assembly]::LoadFile("$scriptdir\Microsoft.EnterpriseManagement.Core.dll")

$server = "testsql"

$RootMS = "testdc01"
$Minutes =  60
$Comment = "Scheduled Maintenance Request"
$MGConnSetting = New-Object Microsoft.EnterpriseManagement.ManagementGroupConnectionSettings($RootMS)
$MG = New-Object Microsoft.EnterpriseManagement.ManagementGroup($MGConnSetting)
$Admin = $MG.GetAdministration()
$Agents = $admin.GetAllAgentManagedComputers()
$agent = $Agents | ?{$_.Computername -match $server}
$monitoring =$MG.Monitoring
$AllClasses = $MG.GetMonitoringClasses()
$MyClass = $AllClasses | ?{$_.name -eq "Microsoft.Windows.Computer"}
$Objects = $Mg.GetMonitoringObjects($Myclass)
$Object = $Objects | ?{$_.name -match $server}
$Object.schedulemaintenancemode
$startTime = [Datetime]'12/21/2016 04:26:00'
$StartTimeUTC = $startTime.ToUniversalTime()
$EndTime = $startTimeUTC.AddMinutes('10')
$Object.ScheduleMaintenanceMode($startTimeUTC,$EndTime,"PlannedOther",$Comment)

 

Problem installing Service Manager Authoring Console

https://blogs.technet.microsoft.com/thomase/2014/02/11/problem-installing-the-scsm-authoring-console/

 

SCOM agent less monitoring access denied

Today I was facing and error with monitoring agentless servers. The agent proxy was getting access denied to event logs. In my environment the health services run under the local system account.

I added the server account to administrators on the agentless server but it did not help.

Then I made changes in the default action account profile for the server and and specified another action account instead of the local system action account to run the healthservices under.

Then everything was peachy...