Как мы помним, резервное копирование - это хорошо, а избыточное резервное копирование это вдвойне хорошо. Так например, в нашем случае, резервное копирование System Center 2012 R2 Configuration Manager (SCCM) делается двумя способами – штатным заданием обслуживания сайта SCCM (резервное копирование сайта с файлами и дампом БД, необходимыми для восстановления сайта SCCM) и заданием резервного копирования виртуальной машины Hyper-V с сервером сайта SCCM средствами System Center 2012 R2 Data Protection Manager (SCDPM). Не так давно обновился пакет мониторинга SCOM для SCCM, и после его установки мы столкнулись с одной проблемой, – при каждом случае выполнения задачи резервного копирования Configuration Manager нас стало обильно посыпать оповещениями SCOM о временной недоступности компонент SCCM.
После изучения ситуации стало понятно, что в процессе выполнения процедуры резервного копирования как средствами самого SCCM, так и средствами SCDPM происходит кратковременная остановка некоторых служб SCCM, о чём, в частности свидетельствуют события евент-лога на сервере сайта SCCM на начальном этапе процедуры:
Log Name: Application Source: SMS Server Date: 15.04.2016 2:53:15 Event ID: 6829 Task Category: SMS_SITE_VSS_WRITER Level: Information Keywords: Classic Computer: KOM-AD01-SCCM02.holding.com Description: On 4/15/2016 2:53:15 AM, component SMS_SITE_VSS_WRITER on computer KOM-AD01-SCCM02 reported: SMS Writer is about to stop the ConfigMgr Services as part of the preparation for the Site backup.
И на этапе завершения процедуры резервного копирования:
Log Name: Application Source: SMS Server Date: 15.04.2016 2:55:56 Event ID: 6831 Task Category: SMS_SITE_VSS_WRITER Level: Information Keywords: Classic Computer: KOM-AD01-SCCM02.holding.com Description: On 4/15/2016 2:55:56 AM, component SMS_SITE_VSS_WRITER on computer KOM-AD01-SCCM02 reported: SMS Writer has started the ConfigMgr Services successfully.
Как следствие, на этих стадиях SCOM и генерирует "букет" оповещений о недоступности служб SCCM:
Таким образом, мы получали такой "букет" два раза в сутки, что со временем порядком поднадоело и заставило задуматься о решении этой проблемы.
Логичным решением в данной ситуации будет перевод сервера SCCM, как объекта мониторинга, в режим обслуживания (Maintenance Mode) в SCOM на время выполнения задачи резервного копирования. И здесь можно было бы пойти по пути наименьшего сопротивления, создав скрипт перевода сервера SCCM в режим обслуживания (с жёстким значением окончания времени режима обслуживания) и настроить его запуск из планировщика заданий Windows перед началом запланированной процедуры резервного копирования. Однако такой упрощённый подход не решил бы пары нюансов, наличие которых не позволило бы считать этот подход изящным. Во первых, у нас не было бы возможности правильно управлять временем окончания режима обслуживания, и за отведённое в скрипте время, задача создания резервной копии при некоторых раскладах могла бы и не закончиться. Во вторых, если говорить об онлайн-бэкапе самой виртуальной машины SCCM, то в случае, если на SCDPM эта виртуальная машина входит в группу защиты (DPM Protection Group) с неким количеством других виртуальных машин, время фактического начала резервной копии такой ВМ может ощутимо варьироваться по времени. Поэтому у меня и возникло желание привязать скрипты перевода в режим обслуживания SCOM к конкретным событиям начала и окончания процесса резервного копирования SCCM.
Отбрасывая излишнюю лирику и рассказы о безрезультатных попытках подобраться к поставленной задаче с разных сторон, обозначу какие решения в итоге были использованы в нашей ситуации:
- Для перевода сервера SCCM в режим обслуживания SCOM во время бэкапа виртуальной машины Hyper-V средствами SCDPM будет использоваться механизм Pre-Backup и Post-Backup скриптов SCDPM, инициируемый служебным файлом ScriptingConfig.xml.
- Для перевода сервера SCCM в режим обслуживания SCOM во время бэкапа сайта SCCM средствами штатной задачи обслуживания сайта SCCM "Резервное копирования сайта" будет использоваться форсированный запуск службы SMS_SITE_BACKUP с последующей обработкой служебного файла AfterBackup.bat
Далее подробно рассмотрим пример настройки таких решений.
Скрипт управления режимом обслуживания SCOM
Для начала я приведу пример скрипта, который будет в дальнейшем использоваться для управления режимом обслуживания объектов мониторинга на SCOM, так как в дальнейшей настройке мы будем отталкиваться от его наличия. Изначально за основу был взят скрипт из заметки Put agent into maintenance mode remotely via PowerShell in SCOM 2012 R2, однако предложенная автором заметки конструкция имела некоторые недостатки, и в результате ряда проведённых тестов скрипт был переработан и расширен:
C:\Tools\Scripts\SCOM-Object-MMode.ps1
# Parse Params [CmdletBinding()] Param( [Parameter( Position=0, Mandatory=$True, HelpMessage="Enable maintenance mode?" )] [Bool]$MMEnable = $True, [Parameter( Position=1, Mandatory=$True, HelpMessage="FQDN of machine to put into maintenance mode:" )] [String]$MMMachine = "KOM-AD01-SCCM02.holding.com", [Parameter( Position=2, Mandatory=$True, HelpMessage="How long should maintenance mode last (in minutes)?" )] [ValidateRange(6,999)] [int]$Minutes = 60, [Parameter( Position=3, Mandatory=$True, HelpMessage="FQDN of SCOM server for this script connecting?" )] [string]$SCOMServer = "KOM-AD01-SCOM01.holding.com", [Parameter( Position=4, Mandatory=$False, HelpMessage="Add a comment about why you're doing this here:" )] [String]$Comment = "Maintenance Mode for object: "+$MMMachine+" from script on server: "+$env:computername ) # Get Credentials for connecting to SCOM server $omusrname = "KOM\s-OM-Oper" $omusrpswd = Get-Content "C:\Tools\Scripts\s-OM-Oper-pwd" | ConvertTo-SecureString $omusrcred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $omusrname, $omusrpswd # Connect to SCOM server $Session = New-PSSession -ComputerName $SCOMServer -credential $omusrcred $Session = Get-PSSession # Run script remotely against SCOM server Invoke-Command -Session $Session -ScriptBlock { Param($MMEnable, $MMMachine, $Minutes, $SCOMServer, $Comment) Import-Module OperationsManager If ($MMEnable -eq $True) { $Instances = Get-SCOMClassInstance -Name $MMMachine ForEach($Instance in $Instances) { $AlreadyMM = Get-SCOMMaintenanceMode -Instance $Instance If ($AlreadyMM -eq $null) { $EndTime = ([System.DateTime]::Now).AddMinutes($Minutes) Start-SCOMMaintenanceMode -Instance $Instance -EndTime $EndTime -Reason "PlannedOther" -Comment $Comment } } Start-Sleep -s 60 } ElseIf ($MMEnable -eq $False) { $MMEntries = Get-SCOMMaintenanceMode | Where {$_.Comments -eq $Comment} ForEach($MMEntry in $MMEntries) { $EndTime = ([System.DateTime]::Now).AddMinutes($Minutes) Set-SCOMMaintenanceMode -MaintenanceModeEntry $MMEntry -EndTime $EndTime } } } -ArgumentList $MMEnable, $MMMachine, $Minutes, $SCOMServer, $Comment # Cleanup Remove-PSSession -Session $Session
По сути скрипт имеет два основных варианта работы (управляется параметром MMEnable) - включение режима обслуживания и отключение режима обслуживания объектов мониторинга SCOM.
Скрипт не требует наличия компонент SCOM, например установленной консоли SCOM или зарегистрированных в системе PS-командлетов SCOM, на том сервере, где он запускается, так как для манипуляций с режимом обслуживания SCOM используется удалённое подключение к самому серверу управления SCOM.
При запуске скрипта обязательными являются параметры:
- MMEnable - Режим работы скрипта. Значение $True задаёт директиву на включение режима обслуживания SCOM. Значение $False задаёт директиву на отключение режима обслуживания объекта монтиринга в SCOM.
- MMMachine - Объект мониторинга SCOM, режимом обслуживания которого мы хотим управлять. Например FQDN имя компьютера. в нашем случае в значение этого параметра попадёт имя сервера SCCM.
- Minutes - Время действия режима обслуживания SCOM в минутах.
- SCOMServer - FQDN имя сервера управления SCOM, которому будет выполнено удалённое подключение с помощью PSSession для выполнения командлетов управления режимом обслуживания SCOM.
Параметр Comment не является обязательным и настроен по умолчанию определённым образом. Этот параметр является важным, так как именно по содержимому этого параметра будет выполнен поиск всех экземпляров действующих режимов обслуживания в SCOM, которые потребуется завершать.
***
Так как эти скрипты нужно запускать с параметрами, нам желательно написать отдельные командные файлы для их запуска со всеми нужными параметрами. Это нужно сделать для того, чтобы избежать возможных неприятностей связанных с интерпретацией параметров в разных механизмах из которых мы будем вызывать эти скрипты, например из служебного файла SCDPM.
Пример командного файла для включения режима обслуживания SCOM (в нашем случае этот командный файл должен запускаться перед началом процедуры резервного копирования SCCM):
C:\Tools\Scripts\SCOM-Object-MMode-Start_KOM-AD01-SCCM02.cmd
Powershell "C:\Tools\Scripts\SCOM-Object-MMode.ps1 -MMEnable $True -MMMachine 'KOM-AD01-SCCM02.holding.com' -Minutes 180 -SCOMServer 'KOM-AD01-SCOM01.holding.com'"
Пример командного файла для выключения режима обслуживания SCOM (в нашем случае этот командный файл должен запускаться после окончания процедуры резервного копирования SCCM):
C:\Tools\Scripts\SCOM-Object-MMode-Stop_KOM-AD01-SCCM02.cmd
Powershell "C:\Tools\Scripts\SCOM-Object-MMode.ps1 -MMEnable $False -MMMachine 'KOM-AD01-SCCM02.holding.com' -Minutes 10 -SCOMServer 'KOM-AD01-SCOM01.holding.com'"
<
p align="center">***
Для того, чтобы указанный скрипт заработал методом удалённого вызова команд на стороне сервера управления SCOM, нам потребуется сделать ряд действий:
- Создать отдельную учётную запись доменного пользователя, от имени которого будут выполняться командлеты управления режимом обслуживания SCOM. В нашем случае это учётная запись KOM\s-OM-Oper. Имя этой учётной записи должно быть указано в PS-скрипте в переменной $omusrname).
- Включить созданную учётную запись (KOM\s-OM-Oper) в группу безопасности, которая ассоциирована с ролью уровня Operator в SCOM (соответствие прав доступа ролям SCOM можно подсмотреть в этом документе). В нашем случае это группа безопасности KOM-SCOM-Operators. Разумеется у соответствующей роли SCOM должны присутствовать права доступа к объекту мониторинга, режимом обслуживания которого мы планируем управлять из нашего скрипта.
- Разрешить соответствующей группе безопасности (KOM-SCOM-Operators) удалённый доступ к механизму PSSession на сервере управления SCOM для возможности удалённого вызова PS-команд.
Полагаю, что с первыми двумя пунктами всё понятно и очевидно, а вот последний пункт может быть выполнен следующим образом. Переходим на сервер управления SCOM и, открыв консоль PowerShell с правами администратора, вызываем команду:
Set-PSSessionConfiguration -ShowSecurityDescriptorUI -Name Microsoft.PowerShell -Force
Откроется форма управления правами доступа к механизму PSSession , в которой к имеющимся разрешениям мы добавим нашу группу безопасности ассоциированную с ролью операторов SCOM и как минимум, выдадим ей права уровня Read и Execute:
Такой вариант выдачи прав доступа позволит членам соответствующей группы безопасности удалённо выполнять команды PowerShell, не имея при этом полного административного доступа к самой системе сервера управления SCOM в целом.
***
Проделанных действий уже будет достаточно для того, чтобы проверить работу скрипта на любой машине в сети, например, на рабочей станции администратора. Однако мы не обговорили ещё один момент. Вы наверняка обратили внимание на то, что в скрипте пароль служебной учётной записи оператора SCOM (KOM\s-OM-Oper) не присутствует в открытом виде. Всё дело в том, что для усиления мер безопасности в данном случае мы используем специально подготовленный файл с зашифрованным паролем пользователя (C:\Tools\Scripts\s-OM-Oper-pwd). Чтобы сгенерировать такой файл, можно воспользоваться PS-командой:
Read-Host -AsSecureString | ConvertFrom-SecureString | Out-File 'C:\Tools\Sсripts\s-OM-Oper-pwd'
После выполнения команды введём пароль, который нужно зашифровать:
В результате по указанному пути будет создан файл с зашифрованным содержимым, к которому, в свою очередь, уже сможет обращаться наш скрипт.
***
Ну вот, теперь всё готово, и мы можем проверить корректность работы скрипта, запуская его, например с рабочей станции администратора. Когда тестовые запуски скрипта отработаны, и мы видим то, что интересующая нас система успешно переходит в SCOM в режим обслуживания и успешно выходит из него, можно приступить к разливке скрипта по тем серверным системам, с которых он и будет у нас в дальнейшем запускаться разными способами.
***
Однако пароль, ранее зашифрованный нами под учётной записью администратора, не будет работать из под другой учётной записи, да ещё и на другом компьютере. Это связано с тем, что при описанном методе шифрования ключевая информация, необходимая для дешифровки пароля, сохраняется на локальном компьютере, да ещё и с привязкой к пользователю. Так как в нашей ситуации скрипт, использующий файл с шифрованным паролем, будет исполняться на нескольких разных системах, например, на серверах виртуализации, и на каждой из них - от имени пользователя SYSTEM, то и генерацию зашифрованного файла с паролем по вышеописанной причине нам придётся выполнить на каждой такой системе, запустив соответствующую PS-команду от имени пользователя SYSTEM.
Поэтому переходим на каждый сервер, где планируется запуск скрипта управления режимом обслуживания SCOM, и запускаем консоль PowerShell от имени системы с помощью утилиты PsExec из состава PsTools:
C:\Tools\PsExec.exe -s -i "PowerShell.exe"
После того, как консоль PowerShell запустится, убедимся в том, что она выполняется от имени SYSTEM, выполнив команду whoami
Выполним в этой консоли команду создания шифрованного файла с паролем пользователя, от имени которого в дальнейшем будет выполняться скрипт (напомню, в нашем примере это учётная запись KOM\s-OM-Oper), добавим к имени файла какое-нибудь произвольное расширение, чтобы помнить, что файл сгенерирован в контексте пользователя SYSTEM:
Read-Host -AsSecureString | ConvertFrom-SecureString | Out-File "C:\Tools\Scripts\s-OM-Oper-pwd.SYSTEM"
После ввода команды курсор будет перемещён на новую строку и PowerShell будет ожидать ввода пароля, который мы хотим зашифровать. Введём пароль (будет отображаться в виде звёздочек) и нажмём Enter:
Убедимся в том, что на файловой системе появился соответствующий файл (C:\Tools\Scripts\s-OM-Oper-pwd.SYSTEM). Если всё в порядке, то теперь можно приступить к проверочному запуску PS-скрипта от имени пользователя SYSTEM. Перед проверочными запусками не забудьте в теле скрипта поправить путь к файлу с зашифрованным паролем, если он был изменён.
Проверочный запуск скрипта на перевод нужного нам сервера в режим обслуживания SCOM выполняем интерактивно запустив соответствующий командный файл с помощью PsExec от имени SYSTEM:
Если запуск скрипта перевода агента SCOM отработал без ошибок, проверим результат в консоли SCOM:
Как видим, объект мониторинга SCOM успешно перешёл в режим обслуживания с теми параметрами, которые мы передали в скрипт через командный файл.
Аналогичный образом проверяем запуск командного файла, который отключит режим обслуживания для выбранного объекта мониторинга SCOM:
Если запуск скрипта с параметрами завершения режима обслуживания отработал без ошибок, проверим результат в консоли SCOM. Убедимся в том, что время окончания режима обслуживания сократилось до указанных нами 10 минут с отсчётом от момента выполнения скрипта, а также в том, что спустя эти 10 минут объект мониторинга успешно выйдет из режима обслуживания…
На этом этапе можно считать проверку работы скрипта законченной, и теперь можно переходить к интеграции этого скрипта и сопутствующих ему командных файлов с разными механизмами по условиям наших задач, такими, как резервное копирование виртуальной машины c SCCM средствами SCDPM и/или резервное копирование сайта SCCM средствами штатной задачи обслуживания этого сайта.
Резервное копирование виртуальной машины сервера сайта SCCM
Информацию о механизме Pre-Backup и Post-Backup скриптов SCDPM можно найти в документе TechNet Library - Using Pre-Backup and Post-Backup Scripts. Если кратко, то перед началом выполнения задания резервного копирования и после его завершения SCDPM умеет выполнять запуск сторонних скриптов согласно настройкам служебного файла ScriptingConfig.xml, который по умолчанию можно найти на стороне защищаемой системы (агента SCDPM) в каталоге:
C:\Program Files\Microsoft Data Protection Manager\DPM\Scripting\
Кстати, ранее в нашем Блоге уже приводился пример использования этого файла.
В конфигурации по умолчанию файл не содержит вызова никаких скриптов и имеет следующий вид:
<?xml version="1.0" encoding="utf-8"?> <ScriptConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/2003/dls/ScriptingConfig.xsd"> </ScriptConfiguration>
Для того, чтобы по условиям нашей задачи инициировать процесс перехода сервера SCCM в режим обслуживания SCOM перед началом резервного копирования, а также процесс завершения режима обслуживания SCOM после окончания резервного копирования, добавим вызов соответствующих командных файлов для интересующего нас источника данных (DataSourceName):
<?xml version="1.0" encoding="utf-8"?> <ScriptConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/2003/dls/ScriptingConfig.xsd"> <DatasourceScriptConfig DataSourceName="7F61727F-ACBE-4BCA-A37F-B228CD5C794C"> <PreBackupScript>"C:\Tools\Scripts\SCOM-Object-MMode-Start_KOM-AD01-SCCM02.cmd"</PreBackupScript> <PostBackupScript>"C:\Tools\Scripts\SCOM-Object-MMode-Stop_KOM-AD01-SCCM02.cmd"</PostBackupScript> <TimeOut>10</TimeOut> </DatasourceScriptConfig> </ScriptConfiguration>
Чтобы выяснить имя DataSourceName, запустим на сервере SCDPM консоль DPM Management Shell и выполним команду поиска источников, указав в качестве условия отбора имя интересующей нас виртуальной машины:
Get-Datasource | Select-Object -Property DatasourceName,ObjectType,ComponentName | Where {$_.DatasourceName -like "KOM-AD01-SCCM02"} | fl
В полученном выводе нас интересует значение параметра ComponentName. Именно его мы и будем указывать в качестве значения для параметра DataSourceName в файле ScriptingConfig.xml.
В нашем случае виртуальная машина KOM-AD01-SCCM02 расположена в кластере Hyper-V состоящем из нескольких хостов виртуализации, и поэтому в разные моменты времени в зависимости от разных обстоятельств эта виртуальная машина может оказаться на любом из хостов кластера. Поэтому нам потребуется внести вышеописанные изменения файла ScriptingConfig.xml на всех хостах виртуализации (разумеется и агент SCDPM должен работать на каждом хосте кластера).
Также на каждом из хостов виртуализации разместим скрипт и его вспомогательные файлы в одном и том же каталоге C:\Tools\Scripts\:
- SCOM-Object-MMode.ps1
- SCOM-Object-MMode-Start_KOM-AD01-SCCM02.cmd
- SCOM-Object-MMode-Stop_KOM-AD01-SCCM02.cmd
- s-OM-Oper-pwd.SYSTEM
Теперь всё готово для того, чтобы запустить процедуру резервного копирования виртуального сервера SCCM (KOM-AD01-SCCM02) на SCDPM и убедиться в том, что перед началом резервного копирования на SCOM происходит автоматическое включение режима обслуживания для этого сервера, а после завершения резервного копирования происходит автоматическое завершение режима обслуживания.
Если при использовании механизма Pre-Backup и Post-Backup скриптов SCDPM возникнут какие-то сложности, то можно включить режим расширенного логирования работы агента DPM, как ранее описано в статье Вики: Как включить расширенное логирование на стороне агента System Center DPM.
Резервное копирование сайта через задачу обслуживания сайта SCCM
В процессе запуска штатного задания обслуживания сайта SCCM на сервере сайта выполняется запуск системной службы SMS_SITE_BACKUP, которая в свою очередь полностью управляет всеми этапами создания резервной копии сайта. Однако подобраться к этой службе таким образом, чтобы перед шагом остановки основных служб SCCM выполнить наш скрипт создания режима обслуживания в SCOM мне так и не удалось. Поэтому было решено прибегнуть к простому но действенному методу – отключению штатного задания облуживания сайта в SCCM и переходу на самостоятельное управление запусками службы SMS_SITE_BACKUP по нужному нам расписанию через планировщик заданий Windows.
В консоли SCCM переходим в раздел \Администрирование\Обзор\Конфигурация сайта\Сайты , выбираем сайт и, открыв контекстное меню действий с сайтом, выбираем пункт Обслуживание сайта
В открывшемся списке задач обслуживания находим и открываем задачу Резервное копирование, где отключаем опцию Включить эту задачу. При этом путь указанный для расположения резервной копии должен остаться заполненным и ссылаться на тот каталог, в который и будет выполняться резервное копирование сайта при стороннем запуске службы SMS_SITE_BACKUP
Далее на сервере SCCM создадим специальный командный файл запуска резервного копирования сайта, который заменит собой отключенную задачу обслуживания:
C:\Tools\Scripts\SCOM-Object-MMode-Start_KOM-AD01-SCCM02.cmd
Powershell "C:\Tools\Scripts\SCOM-Object-MMode.ps1 -MMEnable $True -MMMachine 'KOM-AD01-SCCM02.holding.com' -Minutes 60 -SCOMServer 'KOM-AD01-SCOM01.holding.com'" TIMEOUT /T 120 NET START "SMS_SITE_BACKUP"
Первой командой мы запустим на SCOM режим обслуживания для сервера SCCM, затем выждем дополнительную паузу в пару минут, чтобы перевод в режим обслуживания успел завершиться, и наконец запустим службу вызова процедур резервного копирования сайта SCCM.
Здесь же, на сервере SCCM, в планировщике заданий Windows, создадим задание на запуск созданного командного файла в нужное нам время с нужным нам интервалом от имени пользователя SYSTEM:
На завершающем этапе процедур резервного копирования SCCM штатными средствами службы SMS_SITE_BACKUP происходит поиск и обработка файла служебного AfterBackup.bat. Информацию об этом файле можно найти, в частности, в документе How to Archive the Backup Snapshot (AfterBackup.bat). В этот файл мы и поместим вызов нашего командного файла, который будет вызывать наш PS-скрипт для завершения режима обслуживания сервера SCCM, как объекта мониторинга в SCOM:
C:\Tools\Scripts\SCOM-Object-MMode-Stop_KOM-AD01-SCCM02.cmd
Powershell "C:\Tools\Scripts\SCOM-Object-MMode.ps1 -MMEnable $False -MMMachine 'KOM-AD01-SCCM02.holding.com' -Minutes 10 -SCOMServer 'KOM-AD01-SCOM01.holding.com'"
Служебный файл SCCM AfterBackup.bat в конфигурации по умолчанию отсутствует, и поэтому мы самостоятельно создадим его в каталоге <ConfigMgrInstallPath>\inboxes\smsbkup.box\ (он также доступен как сетевая папка \SCCMServer\SMS_<SiteCode>\inboxes\smsbkup.box\) и добавим в него вызов командного файла отвечающего за завершение режима обслуживания SCOM:
C:\Tools\Scripts\SCOM-Object-MMode-Stop_KOM-AD01-SCCM02.cmd
Отследить успешность обработки файла AfterBackup.bat мы сможем в логе smsbkup.log, копия которого создаётся в той папке, в которую сохраняется резервная копия сайта SCCM:
На этом всё.
Теперь у нас два вида резервного копирования SCCM выполняются с автоматическим запуском режима обслуживания сервера SCCM на SCOM и исключительно на время выполнения процедуры резервного копирования. К тому же рассмотренные сценарии не являются единственными случаями применения PS-скрипта управления режимом облуживания SCOM. Скрипт можно успешно применять и в других сценариях, например, при перезагрузке системы, в случае если перезагрузка выполняется долго и это порождает избыточные оповещения SCOM. В общем инструмент предложен, а дальше всё уже зависит от вашей фантазии.
Дополнительные источники информации:
- Stephan Wibier - SCCM 2012 SP1 Site Backup and Afterbackup.bat
- Gary Simmons - MCS - Using PowerShell with System Center 2012 R2 Configuration Manager Maintenance Tasks
- Script Center - How to Create a Robust ConfigMgr Backup with Powershell
- StackOverFlow.com - ConvertTo-SecureString gives different experience on different servers
RSS - Записи
Обратная ссылка: PowerShell New-PSSession — WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot find the computer | Блог IT-KB /