Смысл и предназначение Microsoft Office SharePoint Server

О Microsoft Office SharePoint Server, внедренном на предприятии (часто внедренном стихийно), довольно часто можно услышать смешанные отзывы – часто говорят, что система непонятно для чего предназначенная, трудноадминистрируемая и прочее.
Часто приводят в пример свободное ПО, предназначенное для узких целей – к примеру, средства для организации Интернет-форумов – и говорят о них как о замене SharePoint. Мол, «для коллективных обсуждений удобнее пользоваться таким-то таким-то форумом, и просто и быстро и и администрировать проще».
В общем, отзывов очень много и все разные. Хотелось бы резюмировать несколько аспектов моего видения данного продукта… Дело в том, что компания Microsoft в разработке и позиционировании многих своих продуктах руководствуется принципом платформы, или, если хотите – конструктора. Касается это не только MOSS; яркий пример – продукты System Center, скажем, System Center Operations Manager. Инсталлировав этот продукт «из коробки» - мы мало что получим кроме минимальных данных о доступности базовых сервисов, на которые мы его «натравим». Полезность близка к нулю. А в другой ситуации, когда мы используем проектный подход в пику стихийному использованию, то есть: проводим исследование потребностей и требований, формируем концепцию решения мониторинга и управления ИТ-инфраструктурой, расписываем сценарии инсталляции, администрирования и эксплуатации, сформировав системные требования для данной конкретной ситуации – мы получаем решение, а не инсталляцию продукта. Это решение представляет собой идею, стратегию, воплощенную при помощи какой-то платформы-конструктора. В общем, это почти то же самое, о чем я говорил в предыдущем посте про хорошую AD и плохую AD.
О платформе какого рода следует говорить касательно MOSS? Есть много замечательных картинок, вроде приведенной мной, которая, собственно, все и объясняет:

Итак, SharePoint – это платформа для организации:
1. Совместной работы
2. Корпоративного портала
3. Управления содержимым
4. Управления бизнес-процессами
5. Бизнес-анализа
6. Корпоративного поиска
Итак, стоит пораздумать над тем, что MOSS – это в первую очередь платформа-конструктор для реализации с помощью ее средств самых различных решений по вышеуказанным направлениям. И эту платформу можно оттачивать и настраивать под самые различные нужды, и уже потом – судить о быстродействии, эффективности и простоте использования. И самое главное в самом начале – понять, что же мы хотим получить в итоге, какую систему, для решения каких задач.



А еще MOSS очень интересно рассматривать в качестве платформы интеграции бизнес-приложений! Но это, как писали братья Стругацкие, уже совсем другая история… И совсем другой пост, который, возможно, тут появится в скором времени… Можно делать заявки :)






А что же происходит в не самом лучшем случае? Представьте такую ситуацию – Вы купили партию стройматериалов: цемент, камень, брус, кирпич, арматура, песок, пеноблоки, стекло, доски, шифер… огромную кучу всего подряд. Затем пытаемся использовать эти материалы сразу как есть: шифером пытаемся укрыться от дождя, доски пытаемся сложить вокруг себя так, чтобы не дуло и не морозило, а пеноблоки начинаем класть, не посчитав их количество и не представляя, что хотим из них сложить в итоге. Ну, какие отзывы мы услышим от того, кто всем этим будет заниматься? :)









Ну вот, собственно, такие мысли о предназначении ПО и стройматериалов :) Удачи Вам и бесперебойного функционирования Вашей ИТ-инфраструктуры, а главное – светлой и ясной погоды в личной жизни!

Active Directory - что такое хорошо и что такое плохо.

Эникейщик к нам пришел
И сказал нам кроха:
"Active Directory - хорошо,
А развернули плохо."

Мы часто слышим "плохая AD", "грамотная AD", "кривая AD" и много других самых разнообразных эпитетов в адрес того или иного частного случая развертывания данной службы каталогов. Если попытаться спросить, что же означает на деле то или иное определение - то администратор (а зачастую, как бы ни было печально, и инженер) с трудом могут сформулировать, "что такое хорошо и что такое плохо".
Попытаемся прикинуть данные определения хотя бы на верхнем уровне. Итак, что же такое оптимальная структура AD?
Это служба каталогов Microsoft Active Directory, которая:

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

Значит это ровно следующее: спроектирована структура AD, в которой учитывается существующая инфраструктура LAN предприятия, связи всех территориальных подразделений, а также заранее спланированы все изменения, которые в эту инфраструктуру придется внести перед внедрением AD. Как пример - от того, чтобы найти и исключить банальный "перехлест" адресации (если в компании существуют изолированные подсети с одинаковой адресацией - в тех подразделениях, которые планируются к объединению), вплоть до того, чтобы найти какое-нибудь отдаленное подразделение, где IP-адреса хостам выдаются вручную системными администраторами.
На этой стадии - стадии исследований - также необходимо уберечь себя от потенциальной дальнейшей беготни по поставщикам оборудования и ПО; необходимо тщательно продумать и спланировать закупки и спецификации аппаратного и программного обеспечения с учетом роста инфраструктуры и обеспечения ее отказоустойчивости.
Отдельной строкой необходимо подойти к исследованию организационной структуры предприятия, иерархии отделов, структуры подчинения, размещению ИТ-отделов и специалистов в филиалах и так далее - исходя из этого мы будем планировать количество лесов, доменов, а также количество и структуру Organizational Units.

И вот у нас появляются результаты предпроектных исследований, оформленные в красивый отчет. Но этого мало для начала внедрения. Нам необходимо, чтобы проектируемая структура AD соответствовала не только требованиям организации, но и рекомендациям и лучшим практикам от производителя - Microsoft, так как нам необходимо обеспечить еще и отказоустойчивость, масштабируемость и надежность внедренной Системы. Best practicies переписывать особой нужды не вижу - все они доступны в открытых источниках. Пользуясь случаем, хочу еще раз настоятельно порекомендовать к прохождению курсы от Microsoft по планированию, дизайну и проектированию архитектуры Active Directory. Собственно, разобравшись в ней, вы поймете, что все описанное в данном посте - лишь краткие заметки о замечательной, красивой и интересной работе - организации единой службы каталогов предприятия.

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

• Что вы будете делать, если не дай Бог (тот, в которого Вы верите) - полыхнет контроллер домена? Железо не вечно, а данные каталога имеют намного ценность намного более высокую, чем это железо. Как вы производите резервное копирование AD? Сколько раз и в скольких различных ситуациях вы тестировали аварийное восстановление служб каталогов? На сколько тысяч рублей будет урезана Ваша зарплата, если сотрудники предприятия на один день останутся без доступа к корпоративным ресурсам?
  
• Какие Вы предпримете действия, если ваша компания будет приобретена другой компанией, или, дай вам Бог (тот, в которого Вы верите) - ваша компания приобретет пару-тройку предприятий? Выдержит ли ваша структура AD расширение и объединение с другими предприятиями-модулями? Сколько ночей Вам придется провести на работе, "руками" перенося данные о пользователях из другого домена?
  
• Разрешения на ресурсы выдаются отдельным пользователям или группам пользователей? Если отдельным пользователям - представьте, сколько времени Вы убьете на выдачу разрешений на какой-нибудь узел корпоративного портала, когда ваша компания вырастет раза хотя бы в два.
• И многое, многое, многое другое. Надеюсь, что у меня получилось разбудить Вашу фантазию! Проблемы с вводом новых сервисов, трудноотлавливаемые проблемы в работе бизнес-приложений, неработающие схемы аутентификации (привет, Kerberos!), головная боль с паролями пользователей и назначением им прав, разруливание ситуаций со сложным трастами между десятками доменов и вообще проблемы со ВСЕЙ ИТ-инфраструктурой... В общем, мрак и ужас.
  

Желаю Вам удачной работы и беспроблемного функционирования Вашей ИТ-инфраструктуры. Полюбите планировать изменения и нововведения - и ИТ-инфраструктура полюбит Вас и поможет успешно заниматься производственными задачами.
Хорошей погоды всем!

AIIM ECM Practitioner, MCTS и прочее интересное.

Здравствуйте.
17го сентября сего года отправляюсь в Москву с целью прохождения курса AIIM ECM Practitioner. С нетерпением жду сего события, программа обучения обещает быть весьма интересной. Рекомендую к ознакомлению:
http://www.docflow.ru/ecm_practitioner/
Также хотелось бы подчеркнуть, что данный именитый курс впервые читается в России. Более подробно с данным видом обучения можно ознакомиться у авторов:
http://www.aiim.org/Education/ECM-Enterprise-Content-Management-Training-Courses.aspx
На данный момент регистрация закончена, но если вдруг Вам очень хочется туда попасть - ко мне можно обратиться в комментариях, могу помочь с продлением регистрации.
В дальнейшем в блоге будет размещен отчет о курсе - краткое ревью, а также описание моего дальнейшего пути в части получения сертификата ECM Practitioner - по окончанию курса дается три попытки сдать экзамен в течение трех месяцев.
Надеюсь в ближайшем будущем присовокупить данные компетенции к своим MCTS и MCBMSS -) Пожелайте удачи)

Механизмы резервного копирования и восстановления службы каталогов Microsoft Active Directory

Для обеспечения резервного копирования и восстановления Active Directory служит ряд стандартных технологий, методов и инструментов.
Одним из основных гарантов работоспособности любой информационной системы (в разрезе целостности и сохранности данных) является тщательно и разумно разработанный механизм резервного копирования данных и план по их восстановлению в различных ситуациях.
Рекомендуемый инструмент резервного копирования и восстановления AD – стандартный инструмент в поставке Windows 2003 – ntbackup. Для того, что сохранить текущее состояние контроллера домена, достаточно выполнять регулярную архивацию System State (состояние системы), которое включает в себя такие компоненты:
1. Файл ntds.dit – база данных AD
2. Реестр контроллера домена
3. База данных Certification Authority (служб сертификации)
4. Папка SYSVOL, хранящая сценарии входа в систему и шаблоны групповых политик домена
5. Системные файлы, необходимые для загрузки операционной системы
6. База данных регистрации классов COM+, которая содержит информацию о приложениях COM+
7. Сведения Cluster Services (служб кластеров), в том случае, если данный сервер является компонентом кластера.
Восстановление состоянии домена контроллера из архива проводится при помощи все той же утилиты ntbackup. В зависимости от того, какую цель мы ставим перед этой операцией, можно провести восстановление различного характер – Primary и Normal; соответственно основное и обычное. Обычно также именуется непринудительным.
Primary, основное – используется в том случае, когда мы преследуем цель восстановить информацию AD в рамках всего домена. Может применяться в ситуации, когда один или несколько контроллеров домена выходят из строя.
Выполняется это восстановление при помощи утилиты ntbackup, в расширенных свойствах восстановления необходимо установить атрибут пометки восстанавливаемых данных как основных для всех реплик.
Normal, обычное (непринудительное) - этот тип восстановления используется тогда, когда необходимо восстановить состояние одного контроллера-домена к предыдущему (то есть к состоянию на момент последней архивации, которая производилась во время штатной, корректной его работы). Данные на восстановленном домене будут актуализированы после первого же сеанса репликации (если, само собой, в домене наличествуют другие контроллеры домена и корректно настроена репликация). У объектов AD существует свойство USN – Update Sequence Numbers, номер последовательного восстановления. Он определяет «свежесть» информации об объекте. При репликации объект с более низким USN будет перезаписан объектом с более высоким USN (по абсолютному значению).
Кроме уже описанных видов восстановления, применимых касательно утилиты ntbackup, существует также еще один тип восстановления – принудительное (authoritative). Данную функциональность обеспечивает утилита командной строки ntdsutil. Это восстановление используется в сочетании с вышеописанными методами, когда имели место, к примеру, ошибки в администрировании AD, повлекшие за собой потерю важных данных. Скажем, был ошибочно удален объект или группа объектов на одном из контроллеров домена. Затем это изменение было среплицировано на все остальные контроллеры домена, в итоге чего организация теряет сведения, удаление которых не было легальным образом предусмотрено. Выходом может стать принудительное восстановление, которое помечает восстановленные из архива объекты как достоверные – и в дальнейшем эти объекты и их свойства реплицируются на все остальные контроллеры домена, в результате чего мы восстанавливаем удаленное доселе подразделение, объект. (Стоит помнить, что AD отслеживает удаленные объекты только в течение времени жизни их захоронения. По истечении этого срока объекты не могут быть восстановлены.)
Принудительное восстановление производится при помощи утилиты командной строки ntdsutil, причем проводится это в DSRM (Directory Services Restore Mode, режим восстановления службы каталогов). Восстановить можно как всю базу данных (команда restore database утилиты ntbackup), так и ее часть, поддерево (restore subtree). Отмеченные объекты восстановления претерпевают изменение USN – авторитативное восстановление увеличивает этот параметр. После выполнения необходимых операций по принудительному восстановлению и перезапуска контроллера домена принудительно восстановленные объекты реплицируются на остальные контроллеры домена. В остальном репликация протекает по обычному сценарию.

Попытка познания концепции Active Directory

Active Directory - что это вообще такое? Периодически такой вопрос задают инженерам. Или у инженеров возникает такой вопрос. Его полезно задать самому себе, дабы это такая вещь, которую, как ни странно, далеко не все могут внятно объяснить в силу неясного осознания самой концепции.
Ниже приведена моя собственная попытка осознания вышеупомянутой технологии. Ни в коем случае не претендует на абсолютную правильность и праведность, а представляет именно мою проекцию сознания в данном вопросе :) (Подкреплено http://technet.microsoft.com и незабвенным курсом 70-297)
***

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

Служба каталогов – средство представления структуры ресурсов организации в виде иерархического описания сущностей. Сущности (объекты) обладают определенными свойствами и функциями, по которым они группируются в классы. Типы ресурсов, классы и определяемые ими атрибуты, а также их взаимосвязи описываются схемой службы каталогов.

ИТ-инфраструктура предприятия включает в себя такие ресурсы как аппаратные платформы (серверы, рабочие станции…), приложения, человеческие ресурсы (персонал)

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

Организацией ISO были определены стандарты служб протоколов – DAP и LDAP, последняя получила широкое распространение и стала стандартным протоколом служб каталогов в Интернете. Active Directory – реализация службы каталогов для сети под управлением ОС Windows Server 2000\2003\2008, соответствующая стандартам LDAP.

Active Directory представляет собой централизованную службу каталогов с базой данных сетевых ресурсов. База данных может быть разбита на разделы и распределена по доменам сети для обеспечения оперативного доступа к данным из любой точки сети, сохраняя возможность управлять ей как единой. AD расширяема – набор информации о ресурсах, хранимый в каталоге, можно расширить в соответствии с индивидуальными потребностями. Кроме того, согласно вышеописанным требованиям к службе каталогов, Active Directory обеспечивает прозрачность обращения к ресурсам и их администрирование, так как абстрагирует логику сети и ресурсов от их физической структуры.

Службы Active Directory устанавливаются и работают на серверах под управлением ОС Windows Server 2000\2003\2008 (контроллеры домена). Базовая организационная структура и административная единица Active Directory – домен, члены которого (серверы и рабочие станции) делят между собой общую базу данных безопасности и пространство имен. Каждый домен может быть разделен на организационные единицы – зоны административного управления внутри домена, позволяющие делегировать административные задачи для этих групп, не предоставляя таких полномочий в рамках всего домена.

Организационная структура уровня выше домена – деревья, в которые организуются несколько доменов. Деревья объединяются в лес, который является крайней границей организационной структуры Active Directory.

Осознание принципов репликации Active Directory

Внутрисайтовая репликация выполняется по протоколу удаленного вызова процедур (RPC) поверх IP. Для обеспечения безопасности используется протокол Kerberos V5 (проверка подлинности) и шифрование данных. Проводится репликация следующим образом. На одном контроллере домена внесены изменения. Он сообщает своим соседям о том, что есть изменения. Затем другие контроллеры обращаются к нему с запросами об изменениях и происходит собственно репликация.
Мастер-копия базы данных Active Directory хранится в файле ntds.dit (каталог хранения указывается в реестре в ветке HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\DSA Database File), файлы журналов транзакций хранятся в каталоге, указываемом в реестре (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\Database Log Files Path)
Файлы SYSVOL (SYSVOL – директория; присутствующее на каждом контроллере домена централизованное хранилище объектов групповой политики и сценариев, распространяемых службой FRS на другие контроллеры доменов):
Рабочая папка службы репликации файлов (FRS – службы, использующейся контроллерами доменов для репликации сценариев входа и информации групповых политик), хранится в разделе, указанном в реестре: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Working Directory
Журналы транзакций базы данных службы FRS хранятся в директории, указанной в HKEY_LOCAL_MACHINE\system\currentcontrolset\services\NtFrs\Parameters\DB Log File Directory
Локальная копия базы данных на контроллере домена разделена на части (как минимум, на три, их хранит на себе каждый контроллер домена), которые называются контекстами именования (NC, Naming Context). Их виды
· NC «Схема»
Хранит информацию о схеме Active Directory. Распространяется в масштабе всего леса.
· NC «Конфигурация»
Также распространяется в масштабе леса, хранит информацию о его топологии, топологии репликации и относящиеся к ней метаданные, данные об уровне домена, «осиротевших» объектах (перемещенных в удаленный контейнер), информация о таких сервисах, как FRS, Exchange, и самой Active Directory.
· NC «Домен»
Содержит наиболее часто используемую информацию – об объектах (пользователи, компьютеры), группах, членстве в группах, распространяется в масштабе домена.
База данных Active Directory состоит из порождающих (внесенных на данный домен-контроллер) и реплицированных записей (полученных с другого ДК в результате репликации)
Типы конфликтов, возникающих при репликации
1. Конфликтующие изменения свойств – когда в приблизительно одно и то же время, к примеру, два администратора на двух разных контроллерах домена производят изменение одного и того же свойства одного и то же объекта. При репликации возникнет конфликт данного свойства.
2. Создание конфликтующих объектов (например, опять-таки создание двумя администраторами на разных контроллерах домена двух одноименных пользователей)
3. Размещение объекта в OU, который одновременно подвергся удалению – к примеру, администратор филиала на своем контроллере домена переносит объект «сервер Exchange» в OU «Почтовые серверы», и примерно в это же время администратор головного офиса производит удаление OU «Почтовые серверы». (этот конфликт наиболее просто разрешается – перемещенный объект в случае удаления целевого контейнера помещается в контейнер LostAndFound)
Существуют способы разрешения всех этих конфликтов. В метаданных у каждого изменения есть атрибут версионности – versionID, который при создании свойства объекта (атрибута) имеет значение единицу и увеличивается на единицу же при каждой операции изменения свойства (атрибута). При репликации превалирующим будет то свойство объекта, у которого versionID имеет наибольшую величину.
Кроме того, есть еще одна составляющая метаданных – временная метка (обозначающая время, в которое было внесено изменение). При совпадении versionID конфликтующих изменений свойства превалирующем станет изменение, временная метка которого указывает на самое позднее время. Если же у изменения совпадает и versionID, и временные метки, тогда решение выносится на основе глобального идентификатора (GUID) контроллера домена. Запись, порожденная тем контроллером, GUID которого по абсолютной величине является наименьшим, перезаписывает при репликации конфликтующую запись собой.
Когда имеет место создание объектов с конфликтующими свойствами (например, одноименных), тогда производится оценка из трех шагов по описанному выше механизму, на ее основе выносится решение, какой объект превалирует. Но другой объект не удаляется – ему присваивается статус конфликтного – путем переименования по шаблону «CNF:<значение GUID контроллера, на котором был создан объект>имя объекта»
Собственно управление репликацией включает в себя следующее:
Настройка межсайтовых связей и присвоение цен этим связям
Служба KCC автоматически выстраивает топологию связей сайтов, создает объекты-соединения на сторонах-партнерах репликации (что, собственно, можно сделать и вручную). Настраивать связи между сайтами можно через оснастку Active Directory Sites and Services путем определения свойств связей (цены связи, т.к. путь репликации выбирается по аналогии выбора пути наименьшей стоимости в графе)
Частота репликации
Пользуясь оснасткой Active Directory Sites And Services посредством изменения свойств объекта связи сайтов можно задать частоту межсайтовой репликации. По умолчанию автоматически задается период репликации в 180 минут, его можно изменять в диапазоне от 15 до 10080 минут
Настройка расписания доступности межсайтовых связей
При помощи вышеупомянутой оснастки можно составлять расписание доступности связей между сайтами. Исключением является репликация по SMTP – она не использует данное расписание.
Настройка межсайтовых мостов связей
Мост – это связь между сайтами, которые связаны между собой цепочкой транзитивных связей через другие сайты. По умолчанию автоматически все сайты имеют между собой транзитивные связи. В случае необходимости игнорирования транзитивности некоторых межсайтовых связей (к примеру, для исключения определенного маршрута репликации) необходимо создавать мосты самостоятельно.
Настройка основных серверов-плацдармов
Напомним, что сервером-плацдармом называется домен-контроллер, выполняющий роль сервера межсайтовой репликации (т.е. партнерами межсайтовой репликации являются сервера-плацдармы сайтов, которые в дальнейшем реплицируют полученные данные каждый внутри своего сайта).
Для установки основного сервера-плацдарма сайта необходимо воспользоваться все той же оснасткой AD Sites & services. В свойствах контроллера домена необходимо выбрать один (или более) межсайтовых транспортов, для которых он и будет являться сервером-плацдармом. При таком способе назначения (вручную) необходимо помнить, что в случае сбоя сервера служба Knowledge Consistency Checker не переназначит ему роль сервера-плацдарма автоматически, что, как следствие, повлечет за собой проблемы с репликацией.