none
перенос RMS или утсановка второго RMS сервера RRS feed

  • Вопрос

  •  

    Добрый вечер!

    интересует вопрос - возможно ли перенести существующий Windows RMS сервер с базами в другой домен?

    или же:

    В корневом домене уже стоит работающий Windows RMS сервер.

    Как можно установить в дочернем домене дополнительный серевер RMS, чтобы клиенты из этого домена обращались именно к нему, но не потерялись права на документы назначенные через RMS сервер этим пользователям корневого домена?

    1 августа 2008 г. 15:48

Все ответы

  • Имею опыт переноса сервера RMS ver.1.0 SP2 с одного физического сервера на другой.

    Причем перенос пошел не по инструкции (инструкции, которые были описаны в справке по продукту), с ошибками - так что пришлось в итоге руками в базе конфигурации подправлять все ручками. Сейчас прекрасно работает.

    На основе полученного опыта с большой степенью уверенности могу сказать что получиться - перенести RMS в другой домен, с уточнением Smile :

    - придется подшаманить в DNS.

    DNS имя сервера должно остаться прежним (оно уже прописано в файлах, защищенных RMS на данный момент, куда собственно клиент RMS и будет стучаться для проверки разрешений).

    Для пользователей исходного домена (откуда ушел RMS) вариант доступа к RMS превратится во "внешний доступ".

    - если используется программная защита ключа - убедитесь, что Вы знаете пароль закрытого ключа. Иначе на новом месте вы не подключите перенесенные\восстановленные базы конфигурации RMS.

    - про точку подключения службы даже не напоминаю Smile, других привязок в\к AD нет.

     

    Вот.

    1 августа 2008 г. 18:51
  • 1) Для переноса RMS-сервера в другой домен в пределах одного леса Active Directory идеальным является следующий вариант:

    - Развертывание нового RMS Server в новом домене и добавление этого сервера к существующему Roor RMS Cluster. Во время этой операции новый RMS-сервер подключиться к конфигурации, хранящейся в Configuration Database Root RMS Cluster. За инструкциями можно обратиться сюда - Deploying an RMS system;

    - В случае использование локальной SQL-базы на старом RMS-сервере необходимо перенести её на новый сервер. В случае использования выделенного SQL-сервера для хранения БД конфигурации RMS этот шаг можно пропустить. За инструкциями можно обратиться сюда - Backing Up and Restoring the RMS System;

     - После успешного переноса, описанного в пунктах 1 и 2, провести операции decommissioning старого RMS-сервера - Decommissioning RMS.

    Использование этого метода позволяет избежать танцев с бубном вокруг правки баз данных SQL, изменения Service Connection Point в Active Directory, а также гарантирует сохранение прав доступа к содержимому защищенных ранее документов.

     

    2) При желании использовать отдельный RMS Cluster в дочернем домене Вам стоит обратить внимание на распределенную топологию организации RMS - Planning a Distributed RMS Topology.

     

    Насчет совета по организации доступа пользователей исходного домена к защищенным документам RMS в контексте использования внешних конвейеров лицензирования и сертификации (проще говоря, внешнего досутпа к RMS). Честно говоря, не понимаю к чему такие сложности. Границы действия организации RMS определяются границами леса Active Directory. То есть один лес - одна организация RMS. Все домены внутри одног леса AD автоматически доверяют друг другу. Соответственно, в пределах одного леса используется одна организация RMS (пусть даже она будет представлена несколькими кластерами), и ни о каком внешнем доступе речи быть не может (опять же таки, имхо).

    4 августа 2008 г. 6:46
  • "избежать танцев с бубном вокруг правки баз данных SQL" - я знаю - это камень в мой огород. Smile

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

     

    Удаленный доступ - да конечно никакого удаленного доступа - эт я сгоряча подумал, т.к. в предложенном мной варианте подразумевался танец с бубном у DNS.

     

    "..провести операции decommissioning старого RMS-сервера .." - т.е. списание RMS сервера, но это означает, что все ранее защищенные документы необходимо открыть, чтобы открыть документ\расшифровать и пересохранить, а  это время и долгое, а значит старый\прежний сервер должен оставаться занятым под нужды RMS.

    Как правило в реальных условиях (малых и средних организаций) такой возможности держать этот (старый) сервер наверно нет. И когда возникает необходимость что то перенести руководство говорит что это должно было быть сделано еще "вчера". Smile

    По хорошему - это правильная процедура (списание), НО на практике - подавляющее большинство пользоваться не будет. Я так думаю..

    6 августа 2008 г. 19:10
  • На самом деле я немного ошибся в терминологии (в спешке к решению поставленного вопроса подошёл). Вместо процедуры decommissioning необходимо со старым сервером провести процедуру uprovisioning. То есть вывести старый RMS-сервер из Root RMS Cluster. А затем удалить компоненты RMS со старого сервера.

    В этом сценарии сам RMS Cluster продолжает функционировать, пара ключей кластера не изменяется, соответственно, оставшийся RMS-сервер (новый) сможет спокойно выдавать лицензии на использование защищённого контента.

     

    Если же есть необходимость полностью удалить старый RMS-кластер и поднять новый, при этом сохранив доступность к защищённым RMS документам, нужно воспользоваться политиками доверия (Trusted Policies), а именно trusted publishing domain. Сразу отмечу, установления политик доверия RMS не имеет никакого отношения к доверительным отношениям между доменами.

    Суть этого метода заключается в том, что все ранее защищённые документы зашифрованы с помощью открытого ключа RMS-сервера. Соответственно, что бы их расшифровать необходимо воспользоваться закрытым ключом RMS-сервера. Для установления trusted publishing domain политики необходимо экспортировать закрытый ключ старого RMS-сервера и импортировать его на новый RMS-сервер. Таким новый RMS-сервер сможет выдавать лицензии на использования документов, защищённых старым RMS-сервером, при том что старый RMS-сервер к этому моменту может быть уже удален.

    Более подробно о политиках доверия Managing Trust and Trust Policy.

    7 августа 2008 г. 13:40