IT-блог компании "ЛанКей" » System Center

Восстановление прав администратора к консоли SCCM 2007 R3

Сергей Ерин — Fri, 27 Jan 2012 21:49:47 +0000

Многие продукты Microsoft разворачиваются так, что по умолчанию оказывается, что административными правами на данный продукт обладает только тот системный администратор, который их устанавливал. При этом даже члены группы Domain Admins или Enterprise Admins не имеют никаких прав на администрирование данного ПО. Одним из таких продуктов является Microsoft System Center Configuration Manager 2007 R3.
Теперь представьте ситуацию, что системный администратор, который разворачивал и в дальнейшем управлял SCCM, уволился, и его учётную запись удалили. Соответственно в домене не остаётся ниодной учётной записи с административными правами на управление SCCM. Обладая правами доменного администратора, вы можете добавить учётную запись в локальную группу безопасности SMS Admins, но это лишь позволит вам запустить консоль управления Configuration Manager Console, но не изменять что либо. Существующие права и пользователей SCCM можно посмотреть в консоли ConfigMgr Console\Site Database…\Security Rights\Users. Соответственно, если бы вы обладали административными правами на управление SCCM, то нажав правой кнопкой по узлу Users, выбрав Manage ConfigMgr Users, можно было бы добавить нового пользователя и дать ему права на управление SCCM. Но поскольку вы не обладаете административными правами, данный пункт будет отсутствовать в контекстном меню:

Что делать? Если обратить внимание на приведённый выше скриншот, то можно увидеть, что среди пользователей SCCM есть встроенная учётная запись SYSTEM. В следующем узле Rights, можно убедиться, что учётная запись SYSTEM имеет полные административные права на управление SCCM. Соответственно осталось войти под учётной записью SYSTEM, запустить консоль управления System Center Configuration Manager Console и добавить себя в администраторы SCCM.

Но как войти под учётной записью SYSTEM? В данном случае может помочь известная утилита от Марка Русиновича – psexec, которая входит в набор PSTools. Распаковываем архив и запускаем:

psexec -s -i mmc.exe

Ключ -i делает интерактивный вывод приложения в данный сеанс, а ключ -s запускает приложение под учётной записью SYSTEM. Далее в открышемся окне Microsoft Management Console, нажимаем меню File, Open… и открываем оснастку управления SCCM, которая находится по следующему пути: C:\Program Files (x86)\Microsoft Configuration Manager\AdminUI\bin\adminconsole.msc.

Обращаем внимание, что теперь в контекстном меню узла Site Database…\Security Rights\Users доступно меню «Manage ConfigMgr Users». Соответственно, теперь уже по стандартной процедуре, добавляем новую учётную запись и предаставляем ей необходимые административные права на управление System Center Configuration Manager.

Data Protection Manager 2010 Release Candidate и его интересности

Ярослав Никифоров — Fri, 12 Feb 2010 09:43:17 +0000

На днях, а именно 9-го февраля 2010 года, компания Microsoft выпустила на тестирование Release Candidate продукта Data Protection Manager 2010. Хотя продукт еще не вышел в релиз – он нам очень интересен, потому что бэкапит Exchange 2010, внедренный некоторым нашим клиентам. Кстати, скачать DPM можно с официального сайта здесь.

DPM 2010 RC интересен (кроме того, что его выход означает – релиз уже близко!) тем, что он поддерживает бэкап виртуальных машин кластера Hyper-V 2 с Cluster Shared Volumes. Чисто случайно как раз такой кластер оказался под рукой, поэтому было принято решение – устанавливать

Развертывание DPM 2010 RC открыло несколько любопытных вещей, которыми я и хочу поделиться:

DPM 2010 Release Candidate поддерживает простой апгрейд с DPM 2010 Beta. Я тестировал его на двух системах – одна инсталляция была выполнена на Windows Server 2008 R2, вторая – на Windows Server 2008 x64.

Beta-версия DPM 2010, кстати, нормально апгрейдится с DPM 2007 SP1 - устанавливает новый SQL-сервер, и апгрейдит старую базу DPMDB. Все параметры и бэкапы при этом сохранились. Как работает апгрейд с DPM 2007 на DPM 2010 RC – сказать пока не могу, не пробовал.

Апгрейд DPM 2010 Beta, стоящего на R2, прошел без проблем и вопросов. А вот для апгрейда той Betы, которая стоит на Windows Server 2008, инсталлятор попросил меня скачать и установить два патча – с номерами 975759 и 962975. Причем, эти патчи недоступны через Windows Update и выдаются по запросу на сайте – нужно только ввести свой e-mail.

После инсталляции вышеуказанных патчей апгрейд DPM прошел на ура. Кстати интересно - RC использует другой instance своего SQL-сервера, и если для Beta он назывался MSDPMV3BETA1EVAL, то для версии RC дополнительно ставится SQL instance с названием MSDPM2010RCEVAL. Базу данных инсталлятор переносит и обновляет сам – но не забудьте перед апгрейдом все-таки сделать ее резервную копию , а также удостовериться, что на диске хватит места под еще один экземпляр SQL Server 2008 и базу данных MSDPM.

Итак, после установки Release Candidate версия DPM станет 3.0.7558.0, вместо версии 3.0.7336.0 у Beta.

После апгрейда самого сервера нужно сапгрейдить и агенты DPM – для этого открываем консоль DPM, заходим в Management -> Agents, и нажимаем на ссылку Update Available рядом с каждым сервером.

Кстати говоря, на некоторые серверы через DPM агент по неясным причинам обновляться отказался – так и оставался в состоянии Needs Updating. Пришлось запускать на сервере установку агента вручную – из папки Agents дистрибутива DPM. После установки агента вручную достаточно нажать Refresh на странице консоли DPM.

Больше ничего с существующими Protection Group делать не надо – все предыдущие настройки и бэкапы сохраняются и подключаются нормально.

А вот при попытке добавить в Protection Group виртуальную машину с кластера Hyper-V, DPM выдал любопытное сообщение:

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

Для Windows Server 2008 – 948465 (это просто Service Pack 2), и 971394.
Для Windows Server 2008 R2 – 975921 и 975354.

Эти обновления опять-таки необходимо загружать с Microsoft по запросу, указывая свой e-mail, на который и придет ссылка для скачивания файлов, вместе с паролем.

Вот такие любопытные нововведения продолжаем исследовать RC, и ждем релиз.

Особенности развертывания управляющего сервера MS SC DPM 2007 на управляемом сервере в рамках роли Hyper-V

Игорь Подольский — Mon, 07 Sep 2009 09:06:33 +0000

Иногда возникают ситуации, когда вынести управляющий сервер на отдельный физический невозможно в силу определенных причин. Примеров на самом деле множество. Из-за неправильного планирования инфраструктуры, когда игнорируется невозможность работы управляющего сервера на управляемом, неправильный подбор конфигурации. Наличие конфликтующих ролей на физическом сервере или испорченный Application Pool IIS (например, из-за наличия побочных служб диагностики компонентов сервера, вроде SuperDoctor Supermicro). И многое другое.

У данной схемы есть ряд преимуществ (догадаться о которых не составляет особого труда), главное из которых состоит в легкой переносимости управляющего сервера в случае острой необходимости на любой физический сервер с ролью HYPERV. Само собой подразумевается наличие отдельного массива на управляемом сервере под группы хранения или хранилищ типа DAS/SAN.

Итак, если возникла вышеописанная ситуация, то первое с чем мы столкнемся после установки DPM – это потенциальная невозможность работы (установки) агента DPM на управляемом сервере. Потенциальная именно из-за того, что ее может и не быть. А будет она в том случае, если у физического сервера имеется по меньшей мере два активных (но не обязательно подключенных) сетевых интерфейса (что является нормой в наше время). Все дело в том, что данный продукт плотно использует архитектуру DCOM, что подразумевает наличие источника данных (как на управляющем сервере, так и на управляемом) и множества клиентов, обращающихся к источнику. DCOM за все время своего существования не претерпел сколь-либо значимых изменений. Эта технология на основе разновидности RPC позволяет COM-компонентам взаимодействовать друг с другом по сети. Сеть является ключевым моментом в описываемой ситуации. Поскольку мы имеем дело с HYPERV, то реализация виртуальных сетевых интерфейсов подразумевает ряд неких программных ухищрений (довольно размыто описанных самой Microsoft), которые, возможно, кроют в себе причину в невозможности нормального взаимодействия между службами DCOM на обоих серверах. Есть подозрения, что использование собственной DCOM-технологии является одной из причин, по которой невозможно резервировать сервер, на котором стоит продукт MS SC DPM2007.

Установку агента DPM можно осуществить, перенеся виртуальную машину с управляющим сервером на любой другой сервер с ролью HYPERV, но при переносе обратно основные службы управляющего сервера DPM начнут сваливаться по таймауту. Преодолеть эту ситуацию возможно, либо оставив активным только один сетевой интерфейс, либо реализовать агрегирование сетевых подключений в командный режим (соответственно, либо с удваиванием пропускной способности, либо с балансированием нагрузки). Стоит заметить, что классический NLB здесь не поможет. Агрегирование хорошо реализуется на интеловских адаптерах собственными средствами.

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

Удаление старых резервных копий в Data Protection Manager 2007

Ярослав Никифоров — Thu, 03 Sep 2009 07:59:26 +0000

Все мы знаем продукт для резервного копирования данных от Microsoft – System Center Data Protection Manager 2007. Его основная задача – выполнять резервные копии и складировать их на подключенные к серверу жесткие диски. В дальнейшем для долговременного хранения данные могут быть перенесены на ленты, но основным местом хранения является жесткий диск. При создании группы хранения DPM сам разбивает выделенный ему диск на разделы, в зависимости от предполагаемого им размера резервных копий и частоты копирования.

Естественно, при создании группы защиты DPM спрашивает, каков срок хранения резервных копий для восстановления – recovery points. И, само собой, по истечении этого срока он должен удалять старые копии, чтобы на их место сохранять новые.

Но мы столкнулись с ситуацией, что старые резервные копии DPM не удаляет. Они так и копятся на диске – и, рано или поздно, наступает время, когда места под новую резервную копию уже не хватает, и DPM вываливается с ошибкой «Recovery Point Volume threshold exceeded».

Для удаления устаревших резервных копий в DPM есть скрипт PruneShadowCopies.ps1, который можно запустить и вручную. Но – данный скрипт не работает. Выдает ошибку:

Index operation failed; the array index evaluated to null. At C:\Program Files\Microsoft DPM\DPM\bin\pruneshadowcopies.ps1:205 char:18 + $replicaList[$ <<<< inactiveDs.ReplicaPath] = $inactiveDs.RecoveryRangeinDays Index operation failed; the array index evaluated to null. At C:\Program Files\Microsoft DPM\DPM\bin\pruneshadowcopies.ps1:206 char:23 + $latestScDateList[$ <<<< inactiveDs.ReplicaPath] = new-object DateTime

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

В июне 2009 года Microsoft выпустила обновление 970267 для Data Protection Manager, среди прочих решающее и эту проблему. Скачать его можно здесь. Процесс установки таков:

Скачиваем три файла, нужной нам платформы – в зависимости от того, 32- или 64-битная версия DPM установлена у нас. Кстати, ставится это обновление на Data Protection Manager 2007 Service Pack 1.
Запускаем файл DataProtectionManager2007-KB970867.exe и производим обновление сервера. Чтобы не перезагружать сервер после обновления – убедимся, что DPM Administrator Console и DPM Management Shell не запущены.
Если база данных SQL, в которой хранится конфигурационная информация DPM, находится не на том же сервере, где сам DPM – запускаем на этом сервере файл SqlPrep-KB970867.msp. Если мы ставили SQL Express вместе с DPM на ту же машину - обновление запускать не нужно.
Если мы используем DPM Management Shell не на том же сервере, где сам DPM – запускаем на этом сервере файл DPMManagementShell2007-KB970867.msp. Если все находится на одном сервере – обновление запускать не нужно.
Заходим в DPM Administrator Console, выбираем Management – Agents, и обновляем все клиентские агенты DPM до новой версии – версия DPM и агентов после этого обновления становится 2.0.8844.0. При обновлении нужно указать Manual restart – потому что на самом деле перезагружать серверы не нужно.

Все. После завершения обновления скрипт PruneShadowCopies.ps1 должен выполняться без ошибок.

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

$VerbosePreference = "continue"

После этого запускать скрипт.