Блог IT-KB

SCCM 2007 R2 – Использование Remote Tools для клиентов в рабочей группе

13.12.2010 Автор:Алексей Максимов
6 201 Просмотров 1 Комментарий

Эта заметка о том, как организовать возможность механизма удалённого управления SCCM Remote Tools для клиентов не входящих в домен (являющихся членами рабочей группы). Всё нижеописанное относиться только к Смешанному режиму работы сайта SCCM (Mixed mode).

Как обычно бывает на практике с SCCM, несмотря на довольно обширный объём доступной онлайн документации, мне нигде не удалось найти исчерпывающей информации обо всех подводных камнях этой задачи, поэтому решил написать для себя на будущее небольшую шпаргалку.

Нормальное взаимодействие не доменного клиента SCCM и доменного сервера SCCM во многом зависит от корректной работы механизмов разрешения имён. В интернете можно встретить несколько способов организации разрешения имён для этой задачи. Мы пойдём по самому короткому и надёжному пути, без всяких танцев с бубном вокруг серверов WINS, ковыряния конфигурационных файлов LMHOSTS и т.п. – то есть будем использовать DNS.. как звучит в гайде – “We recommend DNS for workgroup clients”

Для начала мы включим публикацию точки распространения нашего сайта SCCM в DNS. Сделать это можно в консоли SCCM, открыв свойства сайта на закладке “Advanced”

После включения этой опции мы должны удостовериться в том, что SCCM сервер действительно создал в DNS в нашей основной зоне прямого просмотра в контейнере _tcp необходимую запись Service location resource record (SRV RR). В нашем примере это будет зона mydom.com

Если же по какой то причине сервисная учетная запись так и не появилась, мы можем создать её в ручную. Процесс создания такой записи описан в статье System Center TechCenter – How to Manually Publish the Default Management Point to DNS.

Следующим шагом будет установка специальной серверной роли SCCM – Server Locator Point (SLP), которая в нашем случае будет нужна для того чтобы не доменные клиенты могли общаться c нашим сервером SCCM внутри домена посредствам протокола HTTP.

Процедура добавления роли пошагово описана в статье System Center TechCenter – How to Create a Server Locator Point in Configuration Manager. В консоли SCCM развернём дерево настроек нашего сайта (Site Database > Site Management > SITENAME > Site Settings), перейдём в раздел Site Systems и в меню действий выберем пункт New Roles

Далее в открывшемся мастере добавления ролей отметим интересующую нас роль – SLP, остальные настройки мастера в большинстве случаев можно оставить неизменными.

После того как мастер установки роли успешно завершит свою работу, мы можем проверить доступность Application-части добавленной роли, - для этого откроем в браузере специально сформированный URL формата:

http://<SLPServerName>/sms_slp/slp.dll?site&sc=<SiteName>

В нашем примере эта ссылка будет выглядеть так:
http://kom-sccm01.mydom.com/sms_slp/slp.dll?site&sc=KOM

Как минимум, мы не должны получать никаких ошибок веб-сервера, запросов авторизации и т.п. вещей. В качестве ответа SLP мы должны получить XML примерно такого содержания:

   <?xml version=”1.0” ?>

   <SiteAssignment>

   <Site Sitecode=”KOM” BuildNumber=”6487” Version=”4.00.6487.2000” DefaultMP=”KOM-SCCM01.MYDOM.COM”>

        <Capabilities SchemaVersion=”1.0” />

</Site>

</SiteAssignment>

Далее переходим непосредственно к настройке не доменного клиента. В первую очередь мы должны обеспечить адекватную работу DNS клиента. Для этого мы убеждаемся в том, что в качестве DNS серверов для клиента используется сервера обслуживающие нашу доменную зону, а в свойствах системы на клиенте задан Основной DNS-суффикс указывающий имя домена:

После этого с клиента проверяем доступность SCCM сервера по короткому имени (без указания DNS суффикса) и по полному FQDN имени:

Ping KOM-SCCM01
Ping KOM-SCCM01.mydom.com

Затем регистрируем в DNS имя нашего не доменного клиента и затем проверяем его доступность по имени с SCCM сервера.

Следующим шагом копируем дистрибутив SCCM клиента из подкаталога Client каталога установки серверных компонент SCCM на наш не доменный компьютер, например в папку «C:SCCMClientDistr»:

Необходимо чтобы файлы установки клиента располагались именно на локальном ресурсе и оставались доступными в той же папке после установки клиента, так как они могут потребоваться в дальнейшем для процедур обновления/реконфигурации клиентского ПО.

Открываем командную строку, переходим в каталог с указанными файлами и выполняем запуск программы установки с передачей ей всех необходимых параметров командой:

CCMSetup.exe /Source:“C:SCCMClientDistr” CCMHTTPPORT=80 SMSSITECODE=“KOM” SMSMP=“KOM-SCCM01.mydom.com” SMSSLP=“KOM-SCCM01.mydom.com” DNSSUFFIX=“mydom.com”

Примечание: Полный список используемых ключей и их описания можно найти по ссылке на первоисточник в конце заметки.

Дожидаемся когда в системном журнале «Приложение» будет зафиксировано событие успешного окончания установки клиента:

Проверяем доступность дополнительных апплетов SCCM в Панели управления, которые должны появиться после окончания установки клиента:

После этого переходим на консоль SCCM, убеждаемся в том, что наш клиент там появился, и выполняем для него процедуру одобрения (Approve)

Всё теперь наш клиент «в строю». Для того чтобы успешно работал механизм Remote Tools в составе клиента SCCM, на клиентской системе в свойствах проводника необходимо отключить Использование простого общего доступа к файлам (simple file sharing)

После этого мы сможем подключаться к нашему не доменному клиенту через Remote Tools, указывая при запросе авторизации локальные учетные данные этого клиента (без указания имени домена):

И ещё один момент, если мы планируем использовать распространение ПО на таких клиентов , то на сервере SCCM обязательно должна быть сконфигурирована учетная запись Network Access Account, в противном случае не доменные компьютеры не смогут получить доступ к контенту точки распространения (distribution point).

Дополнительные источники информации:

System Center TechCenter Configuration Manager 2007 General Supported Configurations (Computers in Workgroups)

System Center TechCenter - How to Install Configuration Manager Clients on Workgroup Computers

System Center TechCenter - How to Specify the Server Locator Point for Configuration Manager Client Computers

System Center TechCenter - About Configuration Manager Client Installation Properties
Windows Server 2008 R2 – Добавление скриптов входа на сервере RDS через ключ реестра AppSetup

11.12.2010 Автор:Алексей Максимов
8 417 Просмотров 4 комментария

При настройке сервера служб Remote Desktop Services (RDS) на Windows Server 2008 R2 c включённым UAC, столкнулся с интересной ситуацией. Стояла такая задача, чтобы при входе в систему для каждого пользователя отрабатывал *.cmd файл, в котором исполнялись бы все необходимые директивы дополнительной настройки пользовательского окружения.

По старой памяти, запустив редактор реестра от имени Администратора, я открыл ветку реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon и с удивлением обнаружил отсутствие строкового параметра AppSetup (параметр служит для запуска скриптов обеспечения совместимости приложений в многопользовательской среде). Без задней мысли я создал этот параметр, вписал в него имя моего командного файла (USRLOGON_2.CMD), расположенного в папке C:\Windows\System32 и перезагрузил систему. Но к моему удивлению после перезагрузки, при входе пользователей в систему, файл не отрабатывал.

Читать далее...
PowerShell – Сравнение включённых правил брандмауэра на двух компьютерах

09.12.2010 Автор:Алексей Максимов
3 796 Просмотров 1 Комментарий

Столкнулся с ситуацией, когда в разборе полётов у одного из Hyper-V серверов с включенным брандмауэром Windows Firewall потребовалось сравнить действующие правила с другим сервером. Первое, что пришло в голову - с помощью PowerShell удалённо через вызов Invoke-Command слить правила Windows Firewall с обоих серверов в текстовые файлы и затем сравнить их содержимое.

Читать далее...
PowerShell – Получение информации о локальных пользователях и группах

08.12.2010 Автор:Алексей Максимов
36 800 Просмотров Комментариев нет

Чтобы быстро получить информацию о списке локальных пользователей на удалённом компьютере можно воспользоваться подключением через PowerShell к интерфейсу WMI с запросом в одну строку:

Get-WmiObject Win32_UserAccount -ComputerName MyPC -Filter "Domain= MyPC'"

Тоже самое, но уже при обращении к интерфейсу ADSI:

$computerName = "MyPC"

$computer = [ADSI]"WinNT://$computerName,computer"

$computer.psbase.Children | Where-Object { $_.psbase.schemaclassname -eq 'user' } | Format-Table Name, Description -autoSize

Если нужно получить информацию с локального компьютера в переменной $computerName укажем значение "."

По аналогии для получения списка локальных групп безопасности удалённого компьютера используем команду:

Get-WmiObject Win32_Group -ComputerName MyPC -Filter "Domain='MyPC'"

..или…

$computerName = "MyPC"

$computer = [ADSI]"WinNT://$computerName,computer"

$computer.psbase.Children | Where-Object { $_.psbase.schemaclassname -eq 'group' } | Format-Table Name, Description -autoSize

Если же мы хотим получить картину в целом по всем существующим группам безопасности и членам, входящим в эти группы используем более сложную конструкцию:

$computerName = "MyPC"

$computer = [ADSI]"WinNT:// $computerName,computer"

$computer.psbase.children | where { $_.psbase.schemaClassName -eq 'group' } | foreach {

    write-host "Group:" $_.Name

    write-host "Descr:" $_.Description

    write-host "-----"

    $group =[ADSI]$_.psbase.Path

    $group.psbase.Invoke("Members") | foreach {

    $ADSIName = $_.GetType().InvokeMember("AdsPath", 'GetProperty', $null, $_, $null)

        if ($ADSIName -match "[^/]/[^/]") {

        [String]::Join("", $ADSIName.Split("/")[-2..-1])

        }

        else {

        $ADSIName.Split("/")[-1]

        }

    }

    write-host

}

Источники информации:

Janel Blog - Script pour l'énumération des membres d'un groupe

Powershellcommunity Forum - Listing local user accounts on remote machines
HP System Management Homepage - Установка FQDN Local Server Certificate

07.12.2010 Автор:Алексей Максимов
4 238 Просмотров Комментариев нет
При установке HP System Management Homepage (SMH) по умолчанию использует самоподписанный сертификат, что приводит к паническим предупреждениям веб-браузеров. Встроенный механизм управления локальным сертификатом HP System Management Homepage непосредственно через веб-интерфейс, несмотря на свой почтенный срок существования, до сих пор не умеет формировать запрос на создание цифрового сертификата с атрибутом commonName в формате FQDN. Если для сравнения взять, например веб-интерфейс управления iLO2, то там такая возможность появилась в одном из предпоследних релизов firmware, что само по себе подаёт надежду на то, что технари HP таки одумаются и добавят такую возможность и в функционал HP System Management Homepage… А пока такой возможности нет, мы попробуем использовать альтернативный метод установки сертификата SMH, имеющего в качестве commonName FQDN имя сервера, подписанного нашим локальным доверенным центром сертификации.

Проделаем несколько несложных действий:
- Сгенерируем запрос на сертификат средствами OpenSSL к ЦС Windows;
- Получим от ЦС файла сертификата (.cer) в формате X.509 Base-64;
- Заменим сертификат в встроенном веб-сервере HP System Management Homepage
Для того чтобы создать запрос к ЦС Windows нам понадобиться OpenSSL, а именно 3 файла из его состава – openssl.exe, ssleay32.dll, libeay32.dll. Сложим их в один каталог (например в каталог C:ToolsOpenSSL).

Для подготовки запроса к ЦС создадим конфигурационный файл для OpenSSL - текстовый файл myopenssl.cfg со следующим содержимым:

[ req ]
distinguished_name = req_distinguished_name

[ req_distinguished_name ]
commonName = FQDN of server
commonName_default = SERVER.mydom.com
countryName = Country Name (2 letter code)
countryName_default = RU
0.organizationName = Organization Name (eg, company)
0.organizationName_default = MyCompany
localityName = Locality Name (eg, city)
localityName_default = Syktyvkar
organizationalUnitName = Organizational Unit Name (eg, section)
organizationalUnitName_default = KOMI

Как вы понимаете, в этом файле мы указываем параметры, которые нужны для идентификации запроса сертификата в ЦС, т.е. указываем имя сервера, которому требуется сертификат, имя организации и т.п.
Для формирования запроса с закрытым ключом нам нужно получить собственно сам закрытый ключ используемый сервером в данный момент – файл file.pem (по умолчанию расположен в каталоге C:hpsslshare).
Далее создаем запрос на сертификат с учётом подготовленных ранее параметров и ключевого файла командой:

C:ToolsOpenSSL >openssl req -config myopenssl.cfg -new -key file.pem -out myreq.req

Полученный файл запроса myreq.req загружаем в центр сертификации Windows Server, где выдаем сертификат на загруженный запрос. Выгружаем из ЦС новый сертификат в файл с именем cert.pem в формате X.509 в кодировке Base-64.

Файл cert.pem копируем в каталог, где HP SMH хранит файл самоподписанного сертификата (по умолчанию каталог C:hpsslshare). При этом имеющийся там файл на всякий случай сохраняем и переименовываем в cert.back.

После этого на сервере с HP SMH перезапускаем службу HP System Management Homepage командами:

Net stop SysMgmtHp
Net start SysMgmtHp

В итоге открываем HP System Management Homepage в вэб-браузере (по умолчанию URL типа https://server.mydom.com:2381/) и убеждаемся в том, что HP SMH использует определенный нами сертификат и предупреждения безопасности браузера отсутствуют.
Ошибка обработки GPP: Group Policy object did not apply because its targeting item failed with error code 0x86012004

01.12.2010 Автор:Алексей Максимов
4 372 Просмотров Комментариев нет

Ранее уже описывалась проблема с обработкой Group Policy Preferences (GPP) в части применения нацеливания (Item-level targeting) на OU - Долгая обработка GPP на этапе “Applying Group Policy Drive Maps policy” на клиентах RODC Windows Server 2008 R2

В ходе дальнейшей эксплуатации GPP для изменения членства группы Администраторов на доменных компьютерах описанная проблема проявила себя по аналогичному сценарию (при нацеливании на доменные OU). Чтобы уйти от этого, приняли решение использовать нацеливание на группы безопасности, то есть изменять членство группы Администраторов в зависимости от членства учетной записи компьютера в той или иной доменной группе безопасности. Однако после настройки GPP и применения на клиентских компьютерах с Windows 7 и Windows Server 2008 R2 обнаружилось, что данная настройка GPP не отрабатывает. Сбор трейсов GPP выявил ошибку обработки типа:

Failed filter [FilterGroup]. [ hr = 0x86012004 "Клиентское расширение перехватило необрабатываемое исключение "filter expand" в: "Access violation (0xc0000005) occurred at 0xca12dad1; the memory at 0xca12dad1 could not be ????."%100790275" ]

Как выяснилось, эта проблема известна уже почти год и описана в статье KB976399 - FIX: You cannot apply Group Policy settings on a computer that is running Windows 7 or Windows Server 2008 R2 when security group filters are used in Group Policy preference settings.

К удивлению для себя выяснил, что данное обновление через WSUS не раскатывалось и для его применения MS предлагает воспользоваться отдельно загружаемым файлом исправления

Имеющийся на данный момент перечень исправлений включенных в готовящийся к выпуску SP1 для Windows 7 и Windows Server 2008 R2 - Documentation for Windows 7 and Windows Server 2008 R2 Service Pack 1 Release Candidate (KB976932) говорит нам о том, что этот фикс туда включен. Так что ждём релиза SP1, а пока можем выбрать для себя либо вариант с отдельной установкой фикса на проблемных клиентов, либо опять же нужно выбирать альтернативные методы нацеливания.
Exchange Server 2007 – Просмотр статистики БД почтовых ящиков

29.11.2010 Автор:Алексей Максимов
2 982 Просмотров Комментариев нет

Для получения статистики об использовании почтовых ящиков пользователями организации в Exchange Server 2007 можно воспользоваться Exchange Management Shell и командлетами Get-MailboxDatabase и Get-MailboxStatistics.

Для того чтобы получить сводную информацию о количестве почтовых ящиков в каждой базе данных и общему размеру каждой базы данных на определенном сервере в Exchange Management Shell выполним скрипт:

$MailBoxServer = "MyMailBoxServer"

Get-MailboxDatabase | Where-Object {$_.ServerName -eq $MailBoxServer} | Select @{Label="SG Name";Expression={$_.StorageGroupName}}, @{Label="DB Name";Expression={$_.Name}}, @{Label="Mailboxes";Expression={(Get-Mailbox -Database $_.Identity | Measure-Object).Count}} , @{Label="DB Size";Expression={"{0:N2}" -f ((get-mailboxstatistics -database $_.Identity | Measure-Object -Property TotalItemSize,TotalDeletedItemSize -Sum | Select-Object Sum | Measure-Object -Property Sum -Sum).Sum.ToString() /1024KB)}} | Sort -Property "DB Name" | Format-Table –AutoSize

Для того чтобы получить информацию об использовании пространства почтовых ящиков в определенной базе данных (в мегабайтах) выполним скрипт:

$FullDBIdentity = "MyMailBoxServerMyStorageGroupMyDataBase"

Get-MailboxDatabase -Identity $FullDBIdentity | Get-MailboxStatistics | Sort -Property TotalItemSize | Select DisplayName,@{label="TotalItemSize(MB)";expression={$_.TotalItemSize.Value.ToMB()}},ItemCount,StorageLimitStatus | Format-Table -AutoSize

Если же нас интересует информация только о почтовых ящиках, у которых превышен лимит хранения почты, выполним скрипт:

$FullDBIdentity = "MyMailBoxServerMyStorageGroupMyDataBase"

Get-MailboxDatabase -Identity $FullDBIdentity | Get-MailboxStatistics | Where-Object {$_.StorageLimitStatus -ne "BelowLimit"} | Sort -Property TotalItemSize | Select DisplayName,@{label="TotalItemSize(MB)";expression={$_.TotalItemSize.Value.ToMB()}},ItemCount,StorageLimitStatus | Format-Table –AutoSize

Дополнительные источники информации:

Exchange Server TechCenter - Get-MailboxDatabase: Exchange 2007
Neil Hobson - Getting Mailbox Statistics in Exchange 2007
Exchange Server Share Blog - Exchange 2007: Database Statistics in Powershell
PowerShellCommunity Forums - Exchange Mailbox Database size
System Center DPM 2010 QFE Rollup KB2250444 (3.0.7706.00)

28.11.2010 Автор:Алексей Максимов
2 682 Просмотров Комментариев нет

В первой половине Ноября появился пакет исправлений для DPM 2010 RTM – System Center DPM 2010 QFE Rollup (KB2250444) который изменяет версию DPM до 3.0.7706.00

Описание: Description of the hotfix rollup package for System Center Data Protection Manager 2010: November 10, 2010
URL для скачивания: System Center Data Protection Manager 2010 QFE Rollup

После установки требуется перезагрузка DPM сервера и обновление всех клиентов DPM. Сделать обновление клиентов DPM можно как с консоли DPM так и вручную (обе процедуры описаны в вышеперечисленных ссылках). После обновления клиентов DPM перезагрузка не потребуется.

Наконец то исправлена ошибка, с которой неоднократно приходилось сталкиваться - когда при создании Protection Group мы пытались изменить предлагаемые по умолчанию размеры партиций Replica volume и Recovery point volume – в некоторых случаях из этого ничего не выходило :)
SQL Server 2008 - Перенос файлов БД tempdb на отдельный диск

27.11.2010 Автор:Алексей Максимов
12 584 Просмотров 5 комментариев

При планировании развертывания приложений активно использующих системную временную базу данных SQL Server – tempdb, необходимо учитывать тот факт, что по умолчанию файлы этой БД расположены на системном диске. Соответственно для того чтобы избежать в будущем возможных проблем, связанных с переполнением системного диска из-за увеличения размера файлов tempdb, нам по возможности нужно выделить для файлов этой БД отдельное логическое дисковое пространство.

При создании отдельного логического дискового пространства нужно понимать то, что оно не должно быть использовано для работы каких либо других приложений и его размер должен быть рассчитан исходя из технических требований приложения, использующего наш SQL Server.

Следует учитывать, что для достижения максимальной производительности в работе tempdb может потребоваться разнесение файла данных и лога транзакций БД tempdb. Также следует отметить то, что для поднятия производительности хорошо нагруженных систем в документе MSDN Library - Optimizing tempdb Performance присутствует рекомендация создавать отдельные группы файлов tempdb на разных дисках для каждого ядра серверного процессора.

По умолчанию БД tempdb настроена на авто-расширение (Autogrow) и при каждой перезагрузке SQL Server пересоздаёт файлы этой БД с минимальным размером инициализации (Initial Size). Опираясь на рекомендации вышеуказанного документа, мы увеличим размер инициализации файлов tempdb таким образом, чтобы свести к минимуму затраты системных ресурсов на операции авто-расширения.

Для того чтобы определить где в текущий момент физически располагаются файлы БД tempdb, откроем SQL Server Management Studio и выполним SQL запрос:

SELECT name, physical_name AS CurrentLocation

FROM sys.master_files

WHERE database_id = DB_ID(N'tempdb');

GO

Получим примерно такой результат:

Затем, определившись с тем, на каких логических дисках будут расположены файлы БД, и какой они будут иметь размер, выполним SQL запрос:

USE master;

GO

ALTER DATABASE tempdb

MODIFY FILE (NAME = tempdev, FILENAME = 'H:TempDB_Datatempdb.mdf' , SIZE = 10240);

GO

ALTER DATABASE tempdb

MODIFY FILE (NAME = templog, FILENAME = 'I:TempDB_Logtemplog.ldf' , SIZE = 3072);

GO

Перед выполнением этого запроса необходимо понимать, что если мы указываем размер файлов, то SQL Server сразу попытается увеличить существующие в данный момент файлы, и их размер окажется больше места, доступного на текущем диске места диске,- мы получим сообщение об ошибке.

После успешного выполнения запроса - перезапустим службу SQL Server и убедимся что наши файлы расположены там где мы хотим, выполнив SQL запрос:

SELECT name, physical_name AS CurrentLocation, size, state_desc

FROM sys.master_files

WHERE database_id = DB_ID(N'tempdb');

Если всё нормально, результат должен быть примерно таким:

После этого необходимо удалить файлы tempdb.mdf и templog.ldf с их старого месторасположения.

Дополнительные источники информации:

MSDN Library- Moving System Databases

MSDN Library - How to: Move a Database Using Detach and Attach (Transact-SQL)

KB224071 - How to move SQL Server databases to a new location by using Detach and Attach functions in SQL Server
SCOM 2007 R2 – Пакетный перевод агентов в Maintenance Mode

24.11.2010 Автор:Алексей Максимов
2 227 Просмотров Комментариев нет

В окружении с большим количеством агентов мониторинга SCOM 2007 R2 массовый перевод этих агентов в режим обслуживания (Maintenance Mode) через UI консоль может стать весьма хлопотным занятием. На помощь в таком случае как всегда приходит Operations Manager Shell.

Например, для того чтобы перевести в Maintenance Mode все сервера в имени которых встречается “SQL”, с текущего момента сроком на 2 часа в Operations Manager Shell можно выполнить следующий нехитрый скрипт:

$Time1 = [DateTime]::Now

$Time2 = $Time1.AddMinutes(120)

$Agents = Get-Agent | Where {$_.Name –match "SQL"}

$Agents | foreach {New-MaintenanceWindow -StartTime $Time1 -EndTime $Time2 -Reason "PlannedOther" -Comment "Maintenance Mode Window" -MonitoringObject $_.HostComputer}

Здесь вместо функции AddMinutes() можно также использовать AddHours() и AddDays()

Или другой пример, когда необходимо указать конкретный диапазон дат:

[DateTime] $Time1 = "11/23/2010"

$Time1 = $Time1.ToUniversalTime()

[DateTime] $Time2 = "11/28/2010"

$Time2 = $Time2.ToUniversalTime()

$Agents = Get-Agent | Where {$_.Name –match "SQL"}

$Agents | foreach {New-MaintenanceWindow -StartTime $Time1 -EndTime $Time2 -Reason "PlannedHardwareMaintenance" -Comment "Hardware Maintenance" -MonitoringObject $_.HostComputer}

Если же в организации существуют регламентированные окна обслуживания, в период действия которых нужно обязательно по расписанию снимать с мониторинга агентов для проведения процедур обслуживания, можно поместить вызов скрипта из первого примера в планировщик задач. При этом команда запуска будет следующей:

%SYSTEMROOT%system32WindowsPowerShellv1.0powershell.exe C:MaintenanceModeStartMaintenanceModeWindow.ps1

Так же для того чтобы скрипт успешно отработал при таком вызове из планировщика задач, в начало скрипта следует добавить строки инициализации командлетов Operations Manager Shell и вызов подключения к корневому серверу управления SCOM (RMS):

$RMSServer = 'RMSServerName'

Add-PSSnapin "Microsoft.EnterpriseManagement.OperationsManager.Client";

Set-Location "OperationsManagerMonitoring::";

New-ManagementGroupConnection -ConnectionString:$RMSServer;

Set-Location $RMSServer;

Дополнительные источники информации:

System Center TechCenter - How to Put a Monitored Object into Maintenance Mode in Operations Manager 2007

System Center TechCenter- Operations Manager 2007 R2 Cmdlets - New-MaintenanceWindow

Collection of Maintenance Mode Scripts, Utilities and MPs for Opsmgr and Essentials 2007 (Updated for SCOM 2007 R2)

System Center Operations Manager Forums > Extensibility > Setting all entities to maintenance based on a particular class