Архив рубрики: SCDPM

SCDPM в зонированной инфраструктуре

Построение безопасной инфраструктуры в компании обычно подразумевает разделение ресурсов по нескольким зонам безопасности, которые управляются разными администраторами (или, по крайней мере, одними и теми же администраторами, но под разными учётными записями). Например, можно выделить серверы с важными данными, такие как центры сертификации PKI, хостовые машины Hyper-V или машины содержащие персональные данные, и определить их как «Зона 1». Остальные серверы можно обозначить как «Зона 2». Разрешения настраиваются таким образом, чтобы в каждой зонае были свои собственные локальные администраторы, логоны пользователей между зонами — запрещаются (кроме сетевого входа в систему — он обычно не несёт рисков безопасности).

В идеальном мире, для обслуживания каждой зоны безопасности используется своя собственная выделенная инфраструктура, но в реальной жизни не всегда возможно изыскать дополнительные ресурсы для полноценной поддержки инфраструктуры и приходится идти на компромисы. В таком случае, обслуживающие серверы, в т.ч. серверы резервного копирования, логично разместить в более доверенной зоне (зоне 1) — таким образом более защищённые серверы будут получать доступ к менее защищённым, но не наоборот.

Что это означает для SCDPM? DPM не предназначен для резервного копирования между зонами безопасности, но мы можем его заставить.
После того, как вы установили агент SCDPM на сервер в зоне 2, вы должы прикрепить его к серверу SCDPM в зоне 1. На этом шаге, пользователи, под которым вы прикрепляете агента, должен быть локальным администратором одновременно и на сервере, и на клиенте. В зонированной инфраструктуре это невоможно, т.к. одна учётная запись не может быть локальным администратором на машинах в двух разных зонах.
Что же делать? Придётся предоставить необходимые разрешения гранулированно:

Шаг 1

Мы должны предоставить для администратора зоны 1 следующие разрешения на корень WMI на сервере из зоны 2:

  • Enable
  • MethodExecute
  • RemoteAccess
  • ReadSecurity

Вы можете назначить эти разрешения через графический интерфейс (wmimgmt.msc) или через PowerShell.
Если вы выберете PowerShell, используйте эту версию сценария Set-WmiNamespaceSecurity.ps1. В этой версии исправлено назначение наследований разрешений — оригинальный сценарий Стива Ли падает с ошибкой «Invoke-WmiMethod : Invalid parameter».
Запустите сценарий на клиенте из зоны 2 с такими параметрами:
Set-WmiNamespaceSecurity.ps1 -namespace 'root' -operation 'add' -account 'EXAMPLE\tier1-admin' -permissions 'Enable','MethodExecute','RemoteAccess','ReadSecurity' -allowInherit $true

При назначении разрешений через графический интерфейс, они должны выглядеть так:

Шаг 2

Второй шаг немного контр-интуитивный: Как известно, сервер SCDPM запрашивает с агента его часовой пояс и сохраняет в своей базе. Почему-то, назначение разрешений из шага 1 не даёт не-администратору возможность удалённо запросить эти данные. В качестве обходного пути, выполните вот такой запрос к WMI на клиенте SCDPM: select * from Win32_TimeZone. После этого, не-администратор в течение некоторого времени сможет запрашивать часовой пояс удалённого компьютера.
Команда PowerShell для этого: Get-WmiObject -Query 'select * from Win32_TimeZone'

После выполнения этих двух шагов, у вас должно получиться успешно добавить агента из зоны 2 на сервер SCDPM в зоне 1. После этого, вы можете отозвать только что выданные разрешения: Set-WmiNamespaceSecurity.ps1 -namespace root -operation delete -account 'EXAMPLE\tier1-admin'

Упрощаем обслуживание SCDPM-серверов

Если вы когда-нибудь пробовали регулярно обслуживать SCDPM-серверы (например, ежемесячно устанавливать обновления), то, наверняка, знаете, что просто так выключать SCDPM-сервер нельзя — предварительно надо отключить всех агентов и дождаться завершения всех заданий.

Но есть проблема — не существует быстрого способа получить в PowerShell список всех подключённых к серверу активных агентов. Вы, конечно, можете сказать, что я неправ и командлет Get-DPMProductionServer с фильтром «ServerProtectionState -eq ‘HasDatasourcesProtected'» решают задачу, но, на самом деле — нет: вы забыли про узлы кластеров. Если SCDPM-сервер защищает кластерный ресурс, но никак не защищает сами узлы кластера, вы не увидите их в выводе Get-DPMProductionServer (с применённым фильтром). Плюс ко всему, в выводе будут маячить совершенно ненужные кластерные ресурсы, агента на которых как раз никакого и нет.

Вот почему я предлагаю вам скрипт для быстрого и точного получения списка настоящих активных компьютеров, подключённых к вашему SCDPM-серверу. Просто передайте ему на вход список имён SCDPM-серверов (или ничего не передавайте для локального выполнения) и в ответ вы получите коллекцию объектов ProtectedServers для каждого из них. Дальше, вы можете передать эту коллекцию, напрямую через pipeline, командлетам Enable/Disable-DPMProductionServer.

SCDPM: Невозможно изменить Disk Allocation после переключения Exchange DAG

Симптомы:

Предположим, у вас есть Exchange 2010 с одной или несколькими Database Availability Groups и несколькими серверами в каждой из DAG. Вы настраиваете резервное копирование этих DAG при помощи DPM 2010 и выше (до 2012 R2 UR2 включительно). Через некоторое время, вы изменяете статус защищаемой копии почтовой базы с активного на пассивный или наоборот (например, переключаете активную копию базы на другой сервер в DAG). После этого, на странице Review disk allocation мастера создания/изменения групп защиты и в окне Modify Disk Allocation для баз, статус которых был изменён, вы будете получать ошибку:
"The operation failed because the data source VSS component {76fe1ac4-15f7-4bcd-987e-8e1acb462fb7} is missing.
Check to see that the protected data source is installed properly  and the VSS writer service is running.

ID: 915
Details: The operation completed successfully (0x0)»

If you’ll try to add such DB to secondary DPM server, you’ll receive same error at a disk size calculation step.

Если вы попробуете в этот момент добавить такую базу на вторичный сервер SCDPM, вы не сможете этого сделать из-за такой же ошибки в момент рассчёта дискового пространства.

Это известная Microsoft проблема, которая не будет исправлена в обозримом будущем.

Почему это происходит?

Информация о защищаемых ресурсах хранится в таблицах tbl_IM_DataSource и tbl_IM_ProtectedObject базы DPM. В столбцах ApplicationPath, LogicalPath и PhysicalPath содержится XML-документ, описывающий защищаемый ресурс. В случае с Exchange 2010 DAG он будет выглядеть примерно так:

Здесь мы видим:
DAGNODE2.example.com — имя узла DAG, с которого создаётся резервная копия почтовой базы
MAILDB01 — имя почтовой базы
Microsoft Exchange Server\Microsoft Information Store\Replica\DAGNODE2 — путь до копии базы на защищаемом сервере. Обратите внимание на слово «Replica». Оно означает, что данная копия базы — пассивная. Если вы настроили резервное копирование для активной копии базы, эта часть пути просто будет отсутствовать.

При изменении статуса копии базы с активного на пассивный и наоборот, логический путь до почтовой базы на сервере меняется, но в DPM информация об этом не передаётся и в базе DPM остаются неконсистентные данные.

Решение:

Существуют 2 обходных пути (выбирайте любой, который больше вам подходит):

На стороне DPM:

  1. Остановить защиту проблемной базы, с сохранением данных.
  2. Добавить базу обратно в группу защиты. При этом DPM обновит данные в таблицах tbl_IM_DataSource и tbl_IM_ProtectedObject.
  3. После прохождения consistency check вы сможете свободно управлять выделенным для неё местом и добавить на вторичный DPM-сервер.

На стороне Exchange:

  1. Восстановить активный/пассивный статус базы в то же состояние, в котором она была при добавлении её в SCDPM:
    1. Если защищаемая копия базы была пассивной — сделайте её пассивной.
    2. Если же она была активной, то сделайте её активной опять.

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

После перемещения сервера между первичными DPM-серверами, его невозможно добавить на вторичном DPM

Симтомы:

У вас есть один вторичный DPM-сервер (DPM3), защищающий два первичных (DPM1 и DPM2). У вас есть защищаемый сервер (PS1), добавленный на один из первичных серверов (DPM1) и на вторичный. Вы останавливаете защиту PS1 на первичном и вторичном сервере. Вы переключаете PS1 с DPM1 на DPM2. Вы дожидаетесь создания реплик на DPM2. Вы пытаетесь добавить PS1 обратно на DPM3, на этот раз с DPM2.

В таком случае, PS1 будет отсутствовать на вторичном сервере в списке ресурсов, защищаемых новым первичным сервером.

Причина:

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

Решение:

Это можно исправить вручную, обновив атрибут DPMServerId, для перенесённого сервера, на актуальный.

ВНИМАНИЕ! Это НЕ поддерживаемый официально Microsoft сценарий. Используйте приведённые инструкции на свой страх и риск, если только представитель технической поддержки Microsoft явно не указал вам обратного.

ОБЯЗАТЕЛЬНО сделайте полную резервную копию БД DPM перед выполнением следующих действий.

  1. Подключитесь к базе SQL вторичного DPM-сервера. (Как это сделать, читайте здесь.)
  2. Получите список DPM-серверов и их ID:
    SELECT ServerId, ServerName, DPMServerId FROM [dbo].[tbl_AM_Server] WHERE IsDPM = 1
  3. Запишите ID DPM-сервера с которого вы переносили данные (<OLD-ID>) и ID сервера на который их перенесли (<NEW-ID>).
  4. Определите, какой сервер защищает перенесённый сервер, согласно сведениям в базе вторичного сервера запросом:
    SELECT DPMServerId FROM [dbo].[tbl_AM_Server] WHERE ServerName = '<Protected Server's FQDN>'
  5. Убедитесь, что полученный ID совпадает с <OLD-ID>. В противном случае, эта инструкция вам не подходит — обратитесь в техническую поддержку Microsoft.
  6. Обновите сведения в базе вторичного сервера согласно текущей ситуации:
    UPDATE [dbo].[tbl_AM_Server] SET DPMServerId = '<NEW-ID>' WHERE ServerName = '<Protected Server's FQDN>'
  7. Запустите мастер создания/изменения группы защиты и нажмите кнопку «Clear cache».
  8. Больше никогда-никогда не перемещайте защищаемые серверы между Primary-серверами, подключёнными к одному и тому же Secondary DPM серверу. Это НЕ поддерживается Microsoft.

Как подключиться к SQL БД DPM (DPMDB)

Сведения для подключения к БД System Center Data Protection Manager хранятся в разделе реестра HKLM\SOFTWARE\Microsoft\Microsoft Data Protection Manager\DB на компьютере с установленным DPM-сервером. Вы можете быстро определить основные параметры подключения при помощи следующих PowerShell-команд:

Имя сервера базы данных:
(Get-ItemProperty 'HKLM:SOFTWARE\Microsoft\Microsoft Data Protection Manager\DB').SqlServer
>DPMSRV

Имя самой базы данных:
(Get-ItemProperty 'HKLM:SOFTWARE\Microsoft\Microsoft Data Protection Manager\DB').DatabaseName
>DPMDB_DPMSRV

Имя SQL-инстанса:
(Get-ItemProperty 'HKLM:SOFTWARE\Microsoft\Microsoft Data Protection Manager\DB').InstanceName
>MSSQLSERVER

Далее, используйте SQL Server Management Studio для подключения с параметрами, полученными выше. Если имя SQL-инстанса — MSSQLSERVER, его при подключении указывать не надо вообще.
По-умолчанию, доступ в DPMDB разрешён только группе локальных администраторов, поэтому, если запускаете SSMS локально, не забудьте запустить её с повышенными привилегиями (Run as administrator)