Баллада о SharePoint

Предисловие

Важно! Если Вам хочется побыстрее приступить к технической стороне дела – просто пропустите эту главу.

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

Кстати картинка «человека дождя» на заглавной не просто для привлечения внимания и именно для этого в повествование добавлена «лирика», все события, имена и прочее есть суть фантазии автора. Как обычно, никто ни за что не несет ответственности :)

Просьба к читателю согласиться с рядом приведенных ниже допущений. В повествовании речь пойдет о SharePoint Server 2013, но иногда будут упомянуты и другие, более старые версии. Новая 2016-я платформа на момент написания статьи была в статусе Preview, ее официальный релиз ожидается уже совсем скоро, этой весной. Однако, судя по всему, 2016-я версия является довольно минорным релизом, ее основные «фишки» — более тесная интеграция с облаком Azure и «облагороженный» процесс развертывания и обновления, что не уж так сильно изменит сам процесс внедрения, а потому данный опус не должен потерять актуальности.

Автор постарался обобщить в статье свой опыт внедрения платформы SharePoint в разных отраслях бизнеса начиная со старого доброго WSS 3.0. Несмотря на опыт – автор живой человек, всем априори свойственно ошибаться.

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

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

Технический уровень читающих данный труд должен прощать автору опускание описания некоторых тривиальных вещей, вроде «запустите setup.exe» или скриншоты с кнопками NEXT и OK.

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

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

В последней части повествования будет предоставлен сводный список всех необходимых ссылок.

Любителям сухого технического текста – для Вашего удобства вся лирика убрана под спойлеры и выделена курсивом. Для тех же, кто осмелится прочесть все, от начала и до конца – отключитесь от всего, наденьте наушники, поставьте на повтор что-то вроде «Clubbed To Death» Rob Dougan-а и запаситесь терпением. Мы начинаем…

Глава 1. О SharePoint – как он есть. Ответ на вопрос «Зачем?».

Коммерческие компании – это живые организмы. У них есть молодость, юность, период интенсивного роста, взросление, старость (упадок) и гибель.

Только что созданная небольшая фирма с дюжиной сотрудников вполне обходится рабочей группой Windows и парой сетевых папок, зачастую размещенных на ПК сотрудников, а не на отдельном сервере.

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

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

Решить проблемы обмена информацией, вовлеченности в общие процессы, упорядочивания и уменьшения документооборота как раз и призваны системы, обобщенно называемые системами построения интранет (от слова intro – внутренний) порталов и документооборота. Это то, что наши западные коллеги называют терминами Collaboration и Workflow. Эти системы позволяют упорядочить потоки информации на предприятии, облегчить общий доступ к важным данным, обеспечить простой поиск в различных форматах документов и предоставить наиболее востребованные разделяемые ресурсы типа актуальных справочников контактов сотрудников и их должностей, т.е. прозрачной структуры организации. Эти же системы реализуют возможность построения довольно гибких центров внутренней документации и хранения отчетности во всевозможных форматах от любых подразделений предприятия, что очень ценится собственниками бизнеса и топ-менеджментом, которые в этом случае навсегда избавляются от необходимости просмотра всей своей объемной почты либо персональных ПК и мобильных устройств в случае, когда необходимо поднять отчет по прибыли за какой-то квартал пятилетней давности.

Именно топ-менеджмент обычно и является первым заинтересованным лицом компании в вопросе внедрения системы наподобие SharePoint, так как они первые, кто начинают чувствовать, что бизнес-процессы в компании и отношения между подразделениями раздулись, усложнились и стали терять свою прозрачность.

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

Если на этапе роста компании руководителю достаточно было самому глянуть в какую-то 1С-ку, запустить там отчет об остатках или реализации и получить ответ на свой вопрос, то позже, по мере роста компании этих 1С-ок может стать банально несколько, либо добавиться и вовсе не 1С-ка. Поэтому он вынужден полагаться на своих подчиненных сотрудников, которые будут подготавливать ему всю отчетную базу и учитывая вкусы шефа, бережно и оперативно предоставлять ему всю актуальную информацию и ключевые параметры бизнеса (KPI). Человеческие возможности не безграничны и технический прогресс не стоит на месте. Тот же Гай Юлий Цезарь, помести мы его в наше время – навряд-ли смог бы напрямую руководить современным предприятием в своей легендарной манере, делая несколько дел одновременно.

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

• по итогам мирового конкурса 2013 интранет-систем более 70% победителей используют платформу SharePoint [источник];
• Стив Балмер (бывший CEO Microsoft) назвал в свое время SharePoint краеугольным камнем в бизнес-стратегии Microsoft [источник];
• практически все компании из Fortune 500, выбравшие платформу Microsoft для построения своих систем, используют SharePoint [источник].

Емко и кратко, цель, зачем внедряют SharePoint, заключена в следующих двух предложениях (взято со стартовой страницы продукта в TechNet Library):

SharePoint 2013 is a collaboration environment that organizations of all sizes can use to increase the efficiency of business processes. SharePoint 2013 sites provide secure environments that administrators can configure to provide personalized access to documents and other information. Search features enable users to find content efficiently regardless of the physical location of data.

Вольный литературный перевод:

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

Что же мы получим по факту, если решимся внедрить данный продукт?

1. Внутренний интранет-сайт или даже интранет-портал организации, который можно будет изменять по вкусу, наполнять любым офисным контентом и сделать доступным из любой точки земного шара.
2. Формировать в рамках данного портала функционал автоматизированной обработки документов, например, подписывать документы либо автоматически делать рассылку новых приказов по предприятию.
3. Обеспечить поиск по строке внутри любого документа на портале, причем с учетом прав пользователя.
4. Получить многоуровневую сетевую корзину для удаляемых документов.
5. Обеспечить возможность формализации задач (Tasking) для сотрудников и контроля степени их выполнения, а в перспективе – органично перейти на продукты семейства MS Project Server.
6. Реализовать полноценный электронный документооборот, управлять цепочками жизни документов, обеспечить совместное их редактирование.
7. Разнообразить жизнь офисов компании, решить проблему разделяемых ресурсов (переговорных комнат, курьерских служб, автопарка).
8. Облегчить адаптацию новых сотрудников за счет автоматизации контактной информации и отображения структуры подразделений.
9. Обеспечить безопасность всех хранящихся на портале документов и данных, строить отчеты об доступе к ним и получать всевозможные статистические данные об их использовании.
10. Устраивать опросы и анкетирование сотрудников по каким-либо важным вопросам.
11. Обеспечить интеграцию портала с другими системами на предприятии: CRM, ERP, пропускная система, кадровые БД и т.п.
12. Возможность просмотра документов наиболее популярных офисных форматов прямо в окне браузера, что особенно удобно в нашу эпоху массового использования всевозможных относительно маломощных электронных «гаджетов»: смартфонов, планшетов, портативных нетбуков и т.п.
13. Построения персонального «облака» данных и функционала интранет-портала.

Многие из функций Вы конечно же не получите прямо из коробки. Однако в последней (на момент написания данной статьи) версии SharePoint 2013 средства интеграции с другими продуктами и системами значительно улучшились и расширились. Продукт наконец-то получил огромный дополнительный функционал в виде командлетов powershell, в его серверной и Enterprise-редакции значительно улучшились средства подключения к внешним информационным базам аналитики и визуализации таблиц данных. Появление отдельной роли сервера рабочих процессов с реализацией практически полноценных алгоритмов обработки элементов списков и реакции на внешние события с циклами и ветвителями дало возможность описывать и автоматизировать довольно сложные бизнес-процессы. Наконец появилась долгожданная возможность не традиционного развертывания в виде набора серверов на своей тех-площадке, а использования как сервиса по подписке либо в облачной среде Microsoft Azure, что значительно сокращает затраты на развертывание, упрощает администрирование и повышает надежность внедряемого решения.

В то же время платформа SharePoint представляет собой по сути конструктор с большим количеством generic-объектов, которые можно взять за основу и «доточить» под нужды конкретного предприятия. Довольно большое количество компаний-интеграторов по всему миру пользуются этим и создают отраслевые решения под конкретные виды бизнеса.

Редакции.

Как и любой подобный продукт, SharePoint имеет ряд редакций, различающихся возможностями и, конечно, стоимостью.

Всего существуют три редакции:

• SharePoint 2013 Foundation – базовая версия, предназначена для малого бизнеса, бесплатна (при наличии лицензии на Windows Server);
• SharePoint 2013 Server Standard – стандартная версия, расширена коллекция шаблонов сайтов, добавлены коннекторы к внешним системам и БД для визуализации бизнес-логики и отображения всевозможных отчетов, добавлена новая серверная роль фермы рабочих процессов (Workflow 2013), синхронизация внутренних профилей SharePoint с Active Directory, и другой функционал, востребованный в среднем и большом бизнесе.
• SharePoint 2013 Server Enterprise – максимальная версия, рассчитана на крупные компании, обладает еще большей интеграцией с внешними источниками данных, расширенными возможностями поиска (например умеет искать внутри видеофайлов), еще более расширена коллекция шаблонов для сайтов, доступных из коробки, функционал для создания целых порталов отчетов (Business Intelligence Center) и т.д.

Подробнее о возможностях каждой редакции: статья на MS TechNet

Помимо редакций, разворачиваемых In-Site (локально) конечно же существует редакция использования продукта по подписке как SaaS сервиса. Microsoft активно продвигает в последнее время это направление. У этого подхода есть ряд несомненных плюсов, особенно для малого и среднего бизнеса: экономия на железе и ЗП сотрудников поддержки, значительно снижены возможные проблемы с безопасностью, минимальные риски касательно надежности и возможного простоя. Нет нужды заморачиваться обновлением или апгрейдом аппаратных мощностей. Затраты на внедрение также будут минимизированы. Из минусов — Ваша организация будет подсажена на иглу постоянной абонплаты, Вы будете целиком зависеть от вендора в любом случае, скорость работы с портальным решением будет всецело зависеть от пропускной способности Ваших линков на CDN сеть Microsoft-а.

Насчет рекомендуемых курсов и литературы по сабжу.

Из последних, доступных на момент написания статьи:

Для администрирования: курсы № 331 и 332, соответственно базовый (core) и продвинутый (advanced). Для сертификации MCSE потребуются оба.

Для полного понимания задач архитектуры, администрирования и развертывания, пожалуй, стоит еще прослушать № 488, его должно быть достаточно, чтобы при надобности влезть в мозги к продукту и быть подготовленным в случае крупного внедрения, когда нужно общаться с командой разработчиков под SharePoint «на своем» языке и формировать соответствующие ТЗ на доработки и расширение функционала под конкретные бизнес-задачи.

Кстати, обратите внимание, Microsoft считает курсы по SharePoint-у сложнее, чем какой-то «MCSA: Windows Server 2012», что лишний раз подтверждает тезис о сложности продукта.

Из старых, но не сильно потерявших в актуальности курсов:

M10174 – администрирование и M10175 – разработка приложений.

Оба по SharePoint 2010, но повторюсь, различий с редакцией 2013 именно в администрировании будет не много.

По литературе – тут к сожалению все довольно грустно. Англоязычной литературы довольно много и она хорошего качества, например, «Inside Microsoft SharePoint 2013» и «Microsoft SharePoint 2013 Administration Inside Out», но для ее полноценного чтения нужен хорошо поставленный технический английский. С нормальными переводными изданиями, честно, пока не сталкивался, на моей полке мирно пылится старый добрый «Microsoft Office SharePoint Server 2007. Справочник администратора».

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

Глава 2. Планирование и подготовительная работа. То, что у нас никогда не делают.

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

SharePoint – сложный продукт, я еще не раз в статье буду повторять эту фразу. Его внедрение – очень комплексное мероприятие, которое потребует достаточно серьезной подготовки и предварительного аудита. Устойчиво ли работают каналы связи между офисами, достаточна ли их пропускная способность? Какие поколения операционных систем Windows используются на Вашем предприятии? В каких браузерах работают пользователи, обновляются ли они? Что с мобильными клиентами, какие гаджеты они пользуют и с каких из них они надеются просматривать документы на портале? Много ли из пользователей работают «в поле»? Есть ли в штате подразделения ИТ сотрудники, которые оказывают им поддержку? Как планируется проводить обучающие мероприятия? Есть также вопросы чисто организационного характера: в каком порядке внедрять продукт по подразделениям? Какие из них больше нуждаются во внутреннем портале, а каким он наоборот, осложнит жизнь? На эти и многие другие вопросы необходимо найти ответы ДО внедрения и развертывания.

Мы будем рассматривать следующий сценарий развертывания.

1. Нам необходимо развернуть именно редакцию SharePoint Server 2013. Редакция Foundation является по сути подмножеством серверной и если вы освоите серверную, то развернуть более простое решение не составит для вас труда. Альтернативно можно развернуть Foundation и затем расширить редакцию.
2. У нас есть бюджет на отдельный физический сервер, который мы сделаем фермой виртуальных машин (гипервизором) и на котором мы развернем три виртуальных сервера: роли Web-Frontend и WebApplication, MS SQL Database и MS Office WebApps. В перспективе там же можно будет поднять отдельный сервер рабочих процессов, если бизнес их осилит и ощутит реальную потребность.
3. Структура нашей организации представляет собой главный офис и один либо более филиальных офисов. Ферма интранет-портала будет физически располагаться в главном офисе.
4. На предприятии используется сеть с доменами MS Windows, между офисами реализована связь в виде VPN тунелирования, физическое, либо MPLS соединение, между доменами настроены трасты либо домены являются частью одного AD леса.

Каковы же лучшие практики, как подготовить свое предприятие к началу внедрения? На самом деле многое достаточно очевидно и давно присутствует в том же ITIL, написанном «потом и кровью» системных администраторов и IT-менеджеров.

Стандартизация клиентского ПО.

В идеале – одна-две версии Windows (причем намного лучше, если это будет Windows 7 или выше), не более двух браузеров (один из которых – IE), в качестве офисного ПО – MS Office 2007 (а лучше Office 2010 или выше), умеренное количество мобильных платформ и особенно диагоналей экрана.

Почему это все так важно? По поводу версий Windows – в давние времена внедрение старого SharePoint 2007 на одной только Windows XP был поистине испытанием, кто хоть раз сталкивался с этим, не забудет до сих пор: системную службу веб-клиента, WebDav, жалобы на представление проводника и табличное представление списка, магически ломающееся после очередного обновления MS Office и почему-то зависящее от компонента MS Access… С SharePoint 2013 все уже намного лучше, но подводных камней все равно хватает. Например, достаточно вкусная его фишка загрузки документов в библиотеку простым перетаскиванием оных с рабочего стола в окно браузера в Windows XP в IE вы не заставите работать. Все просто – максимальная версия IE для XP – 8-я, в нем не работает соответствующий javascript-код, поэтому под этот User-Agent SharePoint рендерит страницу без него. Способ конечно есть, но он не совсем лицензионно чист…

Бороться с глюками отображения какого-то контента, например, воспроизведения видеоролика с портала SharePoint – лучше в паре браузеров, например, в IE и Google Chrome. А не дополнительно в Mozilla FireFox, Opera, Vivaldi, Amigo, Yandex Browser, Edge и черте-в чем еще… Если на предприятии есть убежденные свидетели секты «яблочников» – оказываем им должное внимание и почтение, называем их исключительными, видящими истинный путь… но ставим им Google Chrome и убеждаем пользоваться порталом через него. Пусть на все остальное они по-прежнему смотрят через свой Safari, но не на наш портал.

Тема использования браузеров – вообще, довольно больной вопрос для всего семейства SharePoint, поэтому мы поговорим о ней дополнительно в специальной главе.

Хорошие каналы связи и подключения к сети Интернет.

Это — само собой. Если Вы разместите ферму SharePoint на своей офисной площадке и не озаботитесь нормальной, качественной связью с филиалами – готовьтесь к худшему. Не взлетит. Вам будет сложно объяснить директору удаленного филиала, почему у него долго открывается архиважный отчет в PDF с красивыми картинками, порожденный совместным сумрачным гением финотдела и маркетологов, весящий несколько десятков мегабайт. Он (директор) промучается один раз, потом второй, а на третий накапает на ваш портал Вашему высокому руководству и… все. Ой, все.

По этой же причине крайне желательно также иметь резервирование и балансировку каналов связи.

Порядок в AD.

Типичные системные администраторы довольно ленивы. Типичные отечественные офисы – рассадники полного пофигизма пользователей. Что, секретарша Маша вышла (в очередной раз) замуж и поменяла фамилию? Никому об этом не сказала, думала сами догадаетесь? А теперь гневно звонит к Вам в отдел и требует, чтобы на портале ее фамилия была срочно исправлена? Уже исправили? А, уже не надо, надо вернуть все взад, она уже развелась. И еще — ее повысили, перевели в другой отдел и ей не хватает прав и она по старой традиции, вложила все свое недовольство в уши шефу? Ну-ну…

Гигиена Active Directory – залог здоровья и безопасности организации. Пользователь уволился, принес обходной лист? Сразу заблокировать. НЕ УДАЛЯТЬ! Есть такие адепты секты параноиков от ИБ. Удаляют пользователей из AD… Дескать, только так пользователь полностью теряет свои полномочия в системе. А потом — сидят и гадают, чей это UID висит в свойствах безопасности какой-то сетевой папки, кто имел к ней доступ пять лет назад? Есть паранойя еще круче – был свидетелем, как в одной, весьма формализованной конторе (где все по СРП да по СРМ) были разработаны штатные, довольно объемные процедуры по вытиранию ушедших сотрудников из всего, где только можно и по вписыванию персонально туда же новых…

Вместо кучи непонятной технической работы и бюрократизма заведите себе очень простое и хорошее правило. Для каждой штатной должности на предприятии – создавать отдельную группу. Это будет олицетворением его роли, его полномочий в электронном океане предприятия. И везде, где требуется указать пользовательские разрешения – используйте ТОЛЬКО эти группы. И пусть для большинства групп внутри них будет всего по одному пользователю – магия всего нескольких кликов, которые Вам понадобятся, чтобы снять все полномочия с ушедшего в мир иной, тьфу, с Вашего предприятия, пользователя на новичка путем простого редактирования группы его должности, покорит Вас один раз и навсегда. Нужно дать перекрестные полномочия между двумя и более подразделений для одного сотрудника? Добавьте группу в группу. И тогда в любой момент можно будет устроить автоматизированный аудит, который соберет для Вас информацию по группам и предоставит наименования должностей, а не ФИО всех тех сотен и тысяч несчастных, которые работали у Вас последние десять лет. Нагрузка на AD будет небольшая, не лопнет, не бойтесь.

Правильное именование доменных имен для ресурсов организации в Интернете и локальные имена доменов Active Directory.

Ооо, это на самом деле сложный и очень ответственный момент.
Возможны целых два варианта.

Вариант первый.
Для начала наглядная иллюстрация этого варианта:

Active Directory стоит уже давно. Лет десять, а то и больше, с родословной постепенных повышений уровня леса аж от дедушки Windows 2000. С огромной долей вероятности именование доменов AD в этом случае представляет собой <что-то-там>.local.

Последние несколько лет Microsoft всячески ругает в документации и обучающих курсах данное наименование, призывая делать так, как описано во втором варианте. Однако в данном случае лукавству «мелкомягких» нет предела, ситуация очень похожа на бородатый анекдот о фразах Била Гейтса касательно размера памяти в персональных ПК и протоколов стека TCP/IP. Дело в том, что во времена вывода на рынок Windows 2000 Server, презентации Active Directory и шумихи вокруг всего этого Microsoft не успела или не посчитала нужным объяснить системным администраторам как им правильно именовать свои AD домены. В результате произошел интересный казус с фактически распределенной DOS-атакой на корневые DNS сервера всей сети Интернет из-за того, что администраторы Windows-серверов массово стали использовать так называемые single-label наименования своих доменов – названия доменов состояли всего из одного слова. Бородатые и в шерстяных свитерах, истинные UNIX-администраторы «корневиков» в свою очередь недвусмысленно покрутили в ответ пальцем у виска. В спешном порядке «мелкомягкие» родили рекомендацию переименовать такие имена локальных доменов, например, просто добавив после имени точку с неким словом «local». Windows-администраторы восприняли инструкцию буквально, с тех пор мы имеем огромное поголовье локальных сетевых доменов в виде «company.local».

Чем это нам грозит при внедрении? SharePoint – это по сути сайт. Сайт имеет имя. Сайтом предполагается пользоваться как изнутри локальных сетей предприятия и филиалов, так и снаружи, с мобильных клиентов либо ноутбуков. Причем скорее всего без использования корпоративного VPN-а.

Если пользователь, который находится со своим ноутбуком вне офиса но имеет линк на Интернет, например в гостинице, кафе или посредством мобильной связи, введет в своем браузере адрес, то ему ответит DNS сервер провайдера, которому в конечном случае в итоге ответит уже ns-сервер, обслуживающий конкретный домен. Если этот же пользователь будет находиться в офисе компании в зоне действия офисного WiFi либо подключаясь в розетку – ему ответит уже DNS сервер контроллера домена либо другой внутренний DNS сервер.

Можно дать два имени интранет-порталу. Скажем изнутри он будет доступен как intranet.company.local, а снаружи – уже как intranet.company.com. И прописать эти два разных имени на разных DNS серверах – внутри офиса и снаружи на NS. Вроде и здорово, проблема решена, но… некрасиво. Да и пользователям неудобно, особенно тем, кто с ноутом то в офисе, то в поле. Это ж две ссылки делать надо, да и стартовой страницей два сайта не сделать. В случае корпоративного VPN-а, либо использования всякого разного корпоративно-энтерпрайзового софта либо клиентов Sophos-вских, Cisco-вских, да Fortinet-овских это конечно обойти можно, обслуживать пользователя внутри и вне офиса будет в таком случае один набор доменных DNS серверов на контроллерах домена. Да вот только не всегда подобные плюшки доступны по бюджету либо какой иной причине. Например, яблочные девайсы очень любят при очередном обновлении своей iOS-и сносить настройки мобильной связи и заодно VPN-подключений, прописанных в системе. А в Android-е только в последних версиях появился вменяемый контроль устройства и «мультиюзерность», что позволяет бить пользователю по рукам, правда не в случае с BYOD…

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

Как же этого добиться в случае, если имеем «.local» домены, переименовывать которые не сильно хочется?
Придется пойти на хитрость. Нужно каким-то способом заставить либо браузер пользователя направлять сразу на нужный IP адрес сервера WFE роли SharePoint, либо объяснить офисному доменному DNS серверу что он тоже полномочен обслуживать зону «intranet.company.com». Первый способ – совершенно «топорный», править на ПК пользователя (или что уж мелочиться, сразу доменного DNS сервера) файл %SYSTEMROOT%system32driversetchosts – и это в наше-то время? Второй – более элегантный, заключается он в том, чтобы добавить зону «intranet.company.com» в перечень зон доменного DNS сервера и прописать там как @ зоны нужный IP адрес сервера WFE.

Аналогичную операцию будет необходимо проделать на всех доменных DNS серверах во всех филиалах.

Теперь все здорово: у нас одна ссылка на корпоративный интранет-портал и домены переименовывать не нужно.

Кстати SharePoint 2013, как и многие другие продукты, тесно интегрируемые с Active Directory, официально не поддерживает single-label домены.

Вариант второй.

Иллюстрация:

Мы имеем «новомодный» лес, в котором есть отдельный сервер, обслуживающий корневой домен леса и некоторое количество доменов офисов. DNS сервер леса прекрасно осведомлен о том, где находится ферма SharePoint, а внешний NS сервер продолжает отсылать пользователей на Real IP адреса публикации фермы на периметре главной офисной площадки.

Здесь все понятно, хотя тоже возможны «неидеальные» варианты, когда офисные домены не являются частью одного леса. В этом случае – см. первый вариант.

Наличие SSL сертификатов.

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

Сделать это можно разными способами, например, используя классический VPN, либо технологию MS DirectAccess, либо стандартный SSL. Последний способ наиболее универсален и легок в развертывании и поддержке, хотя и не идеален.

Для того, чтобы использовать SSL, нам потребуется соответствующий сертификат. Он может быть куплен в одном из сервисов-центров сертификации (CA) типа Thawte, Verisign, RapidSSL и прочих, либо сгенерирован самостоятельно. В последнем случае такой сертификат называется самоподписным и с ним связан ряд потенциальных проблем. Дело в том, что браузер, чтобы доверять какому-либо сайту, защищенному с помощью сертификата, должен в первую очередь доверять центру сертификации, выдавшему этот сертификат. Доверять он может только в случае, когда этот центр явно прописан как доверенный в настройках самого браузера (особенно справедливо для Mozilla Firefox), либо браузер обращается к системному хранилищу сертификатов и получает из него подтверждение, что этому CA доверяет сама операционная система, а значит может доверять и он. По такой схеме работает IE в Windows и некоторые другие браузеры, например, Google Chrome.

Получить информацию о сертификате, какому сайту (для какого доменного имени) он выдан и какой CA его выдал можно прямо из любого браузера. Например, ниже показан сертификат, выданный сайту Google центром сертификатов GeoTrust Global [24-25]:

Большие, известные центры сертификатов помещаются в хранилище Windows самой Microsoft, их обновление (а центры сертификатов представлены также сертификатами, а значит имеют срок годности) происходит вместе с обновлениями самой операционной системы.

Для кроссплатформенных браузеров, полагающихся на свое локальное хранилище сертификатов, их обновление происходит вместе с обновлением самого браузера.

Сами сертификаты различаются также по типу: выданные на один домен (одинарные, single-domain) либо т.наз. wild-овые, выданные на субдомены. Т.е. сертификат, выданный на домен company.com будет одинарным, а вот выданный на *.company.com – уже «вайлдовым», мультидоменным. Разницам между ними конечно же в цене.

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

В случае, когда нам нужно обеспечить беспроблемную работу пользователей, находящихся вне офиса и работающих с ПК, не введенных в домен либо с мобильных «гаджетов» этот вариант конечно же не подходит.

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

Интерес в интранет-портале как таковом со стороны бизнеса.

Бизнесу должен быть действительно НУЖЕН портал. И не только топам и собственникам, которые жаждут получить дополнительное средство контроля и collaborate-шна своих сотрудников.

Чем больше сотрудников и руководителей Вы заинтересуете его возможностями – тем успешнее и проще будет внедрение. Человеческая натура так устроена, что попытка навязать что-то новое без объяснения причины как это новое может облегчить ему повседневную жизнь – скорее всего наткнется на открытую антипатию или, чего хуже, на скрытый саботаж. Также ошибкой будет навязывание пользователям пользования портала со вздохом, будто оно надо только высокому руководству, а вы совсем не при делах, вы просто исполнитель их воли. Пользователи Вас конечно пожалеют, но саботировать станут с удвоенной энергией, в них проснется Стокгольмский синдром.

Заинтересуйте HR-ов возможностью разместить на портале контакты всех сотрудников предприятия, дайте им возможность повесить на видное место какой-нить «Справочник новичка», где они распишут fresh-meat-у все прелести и преимущества работы на Вашем предприятии, а себе в резюме добавят отдельной строкой скилл создания программы адаптации для новичков и использования для этой программы аж собственного интранет-портала. Пообещайте сделать страничку интранет-портала стартовой в браузерах по умолчанию. Удобно же будет пользователям, да и красиво выглядит, корпоративно. Дайте им («хрен-манагерам») возможность совместно поучаствовать во внедрении продукта, поделитесь частичкой славы.

За чашечкой кофе в офисном кафе заикнитесь руководителю field-force-а насчет интересной возможности создания некоего единого онлайнового хранилища всех документов, в которых нуждаются его сотрудники в поле, а в перспективе нарисуйте ему сказку постановки планов сотрудникам тоже через интранет-портал.

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

Придя в царство маркетинга и пробравшись прямо к его руководителю мимо пафосных лиц маркетологов, витающих в облаках и мечтающих об освоении очередных бюджетов на интересные проекты, поведайте о грядущем функционале портала, который поможет проводить внутреннее анкетирование, презентации новых продуктов (сразу в «инсту», прямо в службу fielforce-а, больше никакой электронной почты и фраз «да не была письмааа»), вывешивать красивые картиночки новых продуктов прямо на главной и прочих «эпиках» и потугах маркетологии.

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

Совсем немного грамотной подготовительной работы – и руководители отделов на очередном совещании сами будут хором волать перед топом фразы в духе «нам нада портал!».

Планирование аппаратных и программных ресурсов.

Требования к программной платформе.

Требования к операционной системе — Windows Server 2008 R2 Service Pack 1 (SP1) Standard или выше, учтите, что для установки на Windows 2012R2 ролей WFE и WebApplication Вам потребуется соответствующий установочный образ SharePoint 2013 with SP1.
Требования к MS SQL Server — 64-bit edition of SQL Server 2008 R2 Service Pack 1.

Требования к аппаратной платформе.

Для нашего сценария я бы настоятельно рекомендовал использовать единый аппаратный сервер в качестве платформы виртуализации. На данный момент Microsoft сделал довольно сильный ход, предложив бесплатную версию Windows Hyper-V Server 2012 R2 в качестве подобной платформы.

В этом случае довольно стандартных аппаратных средств в виде одного Intel Xeon 3.7 Ghz, 64 Gb RAM и гибридной дисковой (SATA/SSD диски с хорошим аппаратным контроллером дисковой, правильно понимающим SSD) вполне хватит, чтобы развернуть три виртуальных сервера (WFE&WebApps + SQL-Database + OWAps) и обслуживать до 1000 пользователей при, порядка 50-100 одновременно запрашивающих страницы.

Процессор значительно больше будет утилизироваться серверами «веб-фронтенда» и «офис-апа» вследствие ресурсоемкости процессорного времени со стороны платформы .NET. Требования к памяти также больше у серверов данной роли по тем же причинам – фреймворк и веб-сервер IIS используют развитое кеширование для ускорения отклика.

Нормальным будет распределение памяти фермы примерно в следующей пропорции:

• роль WFE & WebApp – 24 Gb
• роль SQL-Database – 24 Gb
• роль OWAps – 8 Gb

Остальное отдадите под саму хост-систему Hyper-V.

Дисковая будет узким местом для сервера роли SQL-Database. Будет правильным грамотно подойти к построению дисковой для сервера виртуальных машин будущей фермы SharePoint. Скажем, два обычных SATA диска объединить в RAID1 для развертывания на этом разделе системы гипервизора (Windows Hyper-V Server 2012R2), еще два, а лучше четыре объединить в RAID1 (RAID10) для использования его в качестве тома для хранилища конфигураций виртуальных гостевых систем, а также для хранения контейнеров их дисков и, наконец, еще один RAID1 раздел из двух SSD накопителей использовать в качестве подключенного напрямую к виртуальной машине с ролью SQL-Database для хранения на этом томе контентных БД с SharePoint, которые нуждаются в максимальном быстродействии.
Проще понять принцип построения дисковой можно на иллюстрации ниже:

Есть еще небольшие хитрости, как оптимизировать использование ресурсов. Например, для сервера роли SQL-Database целесообразно использовать три контейнера дисков – один для системы, один (большой) для контентных БД для данных, имеющих большой размер, но мало используемых (классический пример – медиатеки) и, наконец, напрямую подстегнутый физический SSD том для конфигурационной БД фермы (SharePoint_Config) и контентных баз, требующих максимальной доступности и скорости обращения. Кстати разметку файловой системы на томах с виртуалками лучше сразу делать максимального для NTFS размера, аналогичное правило действует и для разметки томов с БД внутри самих виртуалок. Прирост производительности конечно получите небольшой, в пределах статистической погрешности, зато спать будете спокойно, уверенные в том, что все сделали правильно.

Ферма SharePoint 2013, виртуализированная целиком, дает массу преимуществ:

1. Значительно проще наращивать аппаратные ресурсы при росте потребностей, балансировать утилизацией ресурсов при просчетах с планированием и в моменты пиковых нагрузок. Также значительно упрощается кардинальный апгрейд или переезд на новое железо в случае необходимости.
2. Ускорение внутриферменных сетевых задержек – серверам ролей необходимо «общаться» между собой – с WFE&WebApps идут запросы к СУБД. В случае виртуализации весь внутриферменный сетевой трафик будет происходить по сути в памяти, без задействования физической сети.
3. Потенциальная возможность выполнения полного резервного копирования средствами самой платформы виртуализации. Да, SharePoint и MS SQL Server обладают собственными средствами резервного копирования, но соблазн слить в бекап целые образы виртуальных машин хотя-бы раз в месяц – слишком велик.

Напоследок пару слов о антивирусной защите платформы. Категорически не следует использовать на серверах фермы стандартные серверные или сетевые антивирусы, не учитывающие специфику фермы SharePoint. По моим оценкам, развертывание на серверах антивирусных агентов продуктов Symantec, TrendMicro или любого другого вендора приводит к катастрофическому падению производительности – субъективно порядка 20% и более. Особенно «страдают» сервера ролей SQL-Database, причем даже при настройке исключений файлов БД либо папок, где они размещаются. Аналогично резко падает производительность серверов роли OWAps, которые архитектурно имеют распределенный файловый кеш – разница в скорости открытия одного и того же документа может достигать нескольких раз!

Ведущими вендорами антивирусных систем разработаны специальные продукты, ориентированные именно к SharePoint: TrendMicro PortalProtect, Symantec Protection for SharePoint, McAfee Security for SharePoint, Kapersky Security for SharePoint Server и т.д. Эти антивирусные системы понимают, как SharePoint хранит документы в контентных базах данных, какие из его системных сервисов являются критическими для быстродействия фермы и как правильно проверять приложения из пулов веб-приложений на IIS.

Достаточно информативная статья на эту тему.

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

Глава 3. Архитектура – просто о сложном.

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

Старослужащие говорят, в самом Microsoft-е в свое время первое внедрение SharePoint-а с треском провалилось. Типа продукт получился слишком гибким, а пользователям дали слишком много прав, но не дали квотирование и вследствие этого очень быстро сервера перестали справляться с наплывом контента и всяких сайтовых структур, порожденных пользователями. В этом случае нужно отдать MS должное – как истинные врачи сперва попробовали на себе, а только затем выпустили в массы.

Кто любит IT археологию – вот Вам ссылка на неофициальную историю продукта.

С тех пор прошло довольно много времени, появились новые технологии, возможности браузеров возросли многократно, появились новые потребности в повышении комфорта и удобства работы пользователей. Возможности SharePoint также на порядки возросли – в WSS (Windows SharePoint Services) мы даже мечтать не могли о технологии AJAX и о том, что при работе с списком на странице больше не нужно будет ее постоянно запрашивать заново с сервера, а документы MS Office и даже PDF (Карл!) отныне мы сможем просматривать прямо в окне браузера.

Физическая архитектура.

Техническим языком SharePoint представляет собой набор сайтов, динамически генерируемых с помощью технологии MS ASP.NET, с контентом, хранящимся в БД MS SQL Server и способном взаимодействовать с другими приложениями или платформами, например, с MS Office Web Apps, MS Exchange, MS Project Server, MS Dynamix и т.д., причем не обязательно с приставкой «MS» — сторонних продуктов также хватает.

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

Совокупность данных серверов называется фермой SharePoint (SharePoint Farm). Минимально существуют следующие роли (серверы) фермы:

1. Роль Web Front-End Server: сервер(ы) этой роли отвечают за прием и обработку пользовательских запросов. По сути это сервер(ы) MS IIS, которые обслуживают поступающие от пользователей веб-запросы.
2. Роль Web-Application Server: сервер(ы) этой роли отвечают за динамическое формирование страниц и ответов серверов путем обработки сценариев, написанных на языке ASP.NET и использующие для этого .NET Framework. Страницы и ответы формируются на основе данных из БД. Для проектирования небольших ферм, рассчитанных на обслуживание небольшого количества пользователей (несколько тысяч пользователей, одновременно работают несколько сотен) данную роль часто совмещают с предыдущей ролью.
3. Роль SQL-Database Server: практически ВЕСЬ контент и ВСЯ структура портала/сайтов SharePoint хранится внутри БД.

Все это – базовые роли. Еще возможно развертывание ролей отдельного сервера поиска и индекса, сервера новых рабочих процессов (в SharePoint 2013 появилась отдельная роль сервера с расширенными возможностями, при сохранении возможности использования старого механизма). Данные роли потребуется развернуть в случае построения действительно больших ферм, либо если возникнет необходимость использования дополнительного функционала новых Workprocess.

В целом архитектура фермы – горизонтально и вертикально масштабируемая, при необходимости можно как апгрейдить оборудование, либо выделять больше ресурсов серверам ролей в случае виртуальных машин, так и добавлять серверы для каждой роли по мере потребностей. Возможности кластеризации решаются исходя из конкретной роли – для IIS/WebApps это стандартные средства системы, а для роли SQL-Database функционалом MS SQL.

В своем повествовании мы рассмотрим отдельно еще одну роль – т.наз. OWAps: Office Web Apps. На самом деле это не совсем роль SharePoint, по-простому это – отдельный сервер рендеринга документов MS Office в веб-страницы (веб-версия Microsoft Office). Ранее его предок действительно входил в комплект поставки SharePoint Server 2010 и обладал довольно скромными возможностями, однако для 2013-й версии Microsoft принял логичное решение выделить данный функционал в виде отдельно развертываемого сервера, с возможностью подключения к нему других приложений, не только SharePoint, например, того же OWA в Exchange. По сути это – локальный вариант облачного сервиса Office 365. Политика лицензирования его проста, в бесплатном варианте продукт позволяет только визуализировать документы в браузере и просматривать их. В платном варианте Вы получаете более-менее полноценный Office 365, т.е. документы можно будет уже и редактировать прямо в браузере, совсем как в 365-м. Коллеги говорят, что в данный момент продукт вроде бы уже недоступен для свободного скачивания, но в подписке MSDN он все еще есть и политика его лицензирования не изменилась. Продукт интенсивно развивается и на самом деле действительно интересен, т.к. подымает функционал платформы SharePoint 2013 как системы документооборота на новый уровень. Также с данным продуктом связан еще один казус – его часто переименовывают. Я привык называть его Office Web Apps и использовать акроним OWAps, но сейчас Microsoft кличет его просто Office Online.

Немного слов о том, как SharePoint 2013 устроен физически.
Поскольку интранет-портал – это по сути обычный ASP.Net сайт, то разумеется без сервера IIS у нас не обошлось. Версия MS Internet Information Server (IIS) у нас может быть разная, напомню, продукт можно развернуть, начиная с версии Windows 2008R2. Т.е. имеем версии IIS с 7.5 до 8.5. Общее для всех версий будет одно – необходимо будет присутствие платформы Microsoft .NET Framework версии 4.5.

Веб-сервер корпорации Microsoft под названием IIS – довольно сложный, модульный продукт. Детально его архитектура (для разных версий) описана в данном документе. У нас нет времени его читать, трубы горят от нетерпения приступить к установке, тем более документ на английском, поэтому попытаюсь упрощенно объяснить, как оно работает в последних версиях для самых неторопливых.

В ядре Windows висит в качестве драйвера HTTP.sys, который иначе еще называют веб-слушателем (web-listener). Он отвечает за получение и обработку всех поступающих на сервер запросов. Висит он путем прикрепления (bind-а) на определенные порты, по дефолту для HTTP и HTTPS это 80 и 443 соответственно. Висит он в ядре не просто так – сделано это для максимального ускорения обработки запросов, повышения доступности, приоритет для драйвера как бы максимален, да и не нужно переключаться в контекст пользовательского режима, в доках также пишут, что он там может юзать некие низкоуровневые процедуры кеширования и прочего. В общем MS очень хотелось сравняться в популярности своего веб-сервера с признанными столпами индустрии, а потому они «запилили» все максимально быстро, как могли.

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

Далее есть два системных сервиса (их уже можно увидеть в services.msc) инкапсулируемых в svchost.exe:

• World Wide Web Publishing Service (он же W3SVC или по-новому WWW Service): отвечает за управление HTTP.sys – делает ему stop/start, обслуживает всякие штуки вроде iisreset/noforce в консоли, обновляет настройки HTTP.sys при изменении конфигурации, собирает статистику и прочее;
• Windows Process Activation Service (он же WAS, не имеет никакого отношения к службе активации Windows): служит прокладкой между HTTP.sys и тем, что происходит дальше, обслуживает и управляет т.наз. пулами приложений (application pools) – рабочие процессы пользовательского режима, которые обрабатывают входящие запросы, запуская хранящиеся на хосте веб-фильтры, модули различных типов (нативные, расширения и (чаще всего) ASP-сценарии и COM-объекты.

Поступающие от службы WAS запросы переадресуются в пулы приложений, в нашем случае конкретно к .NET Framework, который вызывается изнутри порождаемого службой WAS процесса w3wp.exe.

Всю эту сборную солянку современной архитектуры IIS можно увидеть на скриншоте сервера роли WFE&WebApps с рабочей (боевой) фермы SharePoint 2013 Server:

Пулы приложений работают в пользовательском режиме, а значит, могут стартовать под некой пользовательской учетной записи, чаще всего специально для этого созданной локально либо в домене Active Directory. Именно поэтому на приведенном выше скриншоте они закрыты желтыми прямоугольниками – сервер то боевой…

Запомните этот важный момент – мы к нему еще не раз вернемся в следующих главах.
Помимо, собственно, IIS-а в состав SharePoint входит также ряд довольно важных системных сервисов, автоматически развертываемых на серверах роли WFE.

Вот эти сервисы:

Эти серверы выполняют довольно важные функции. Они по сути формируют одиночные, по требованию и периодические по таймеру служебные запросы к IIS, которые требуются для нормального и автоматического функционирования фермы SharePoint.

Необходимо пояснить их назначение отдельно:

• SharePoint Administration — Служба, отвечающая за выполнение административных задач
• SharePoint Search Host Controller — Служба функционала поиска
• SharePoint Server Search 15 — Служба функционала поиска
• SharePoint Timer Service — Управляет одним из важнейших компонентов фермы SharePoint – внутренним планировщиком задач, запускаемых по расписанию. К этим задачам относятся многочисленные задачи внутреннего обслуживания, например, очистка внутренних корзин от старых документов.
• SharePoint Tracing Service — Отвечает за встраивание в выдаваемые страницы панели разработчика (Dushboard), обеспечивает функционал для отладки и счетчиков производительности и статистики
• SharePoint User Code Host — Используется для запуска в песочнице пользовательских расширений и приложений
• SharePoint VSS Writer — Volume Shadow Copy Writer – участвует в процессах резервного копирования

Логическая архитектура.

SharePoint представляет собой по сути Content Management System (CMS). Как и тот же Drupal, WordPress или MODx внутри него весь контент делится на определенные логические блоки.

Самой большой, фундаментальной структурой является семейство сайтов (Site Collection). Семейство сайтов – это сущность SharePoint, которая напрямую связывает такие понятия как URL стартовой страницы сайта и веб-приложение на сервере IIS, которое занимается рендерингом этого семейства и хранит весь контент семейства в какой-то базе на сервере MS SQL. Почему именно «семейство»? Потому что базово семейство состоит минимум из одного (корневого) сайта, обладающего определенным URL именем, но может содержать произвольное количество подсайтов, URL (имя) которых добавляется к базовому. Например, семейство сайтов имеет имя (URL) intranet.company.com, в котором есть два «подсайта» site1 и site2, которые автоматически получат URL вида intranet.company.comsite1 и intranet.company.comsite1.

Итак, семейство сайтов – это один корневой сайт либо корневой сайт и несколько подсайтов. Сайты – это конечно хорошо, но по факту это просто шаблонные страницы с определенным оформлением. Внутри страниц сайтов должен находиться контент – текст, изображения, какие-то другие объекты. За сохранением контента в SharePoint отвечают т.наз. списки различных типов. Эти списки могут визуально выглядеть как собственно списки – некие табличные текстовые данные, так и как «библиотеки» — особые списки, которые могут хранить внутри себя файлы документов различных типов, изображения, мультимедийные файлы, календари, задачи и т.д. Зачем внутри SharePoint так много различных типов списков? Все просто, каждый тип контента нужно как-то показывать на странице: календарь должен выглядеть именно календарем, да еще и с возможностью редактирования, библиотека документов – отображать документы в духе Windows Explorer и давать возможность их добавлять, переименовывать и удалять, библиотека изображений – отображать картинки не только в виде таблички списка, но и в виде миниатюр и так далее.

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

Кстати внутри корневого сайта помимо подсайтов также могут содержатся различные списки и библиотеки.

Семейств сайтов внутри одной портальной фермы SharePoint также может быть произвольное количество, важно помнить, что каждое семейство имеет собственное имя URL и за ним закреплено определенное веб-приложение (Web Application) ASP.Net, которое крутится на сервере роли WFE и Web-Application. Веб-приложения могут объединяться в так называемые пулы приложений (Web Application Pools), в архитектуре SharePoint понятия веб-приложения и пула приложений являются синонимами. Несколько семейств сайтов могут использовать одно веб-приложение, чуть ниже мы обсудим стратегию построения семейств сайтов исходя из конкретных потребностей.

Понимание структуры сайтов SharePoint очень важно с точки зрения грамотного построения URL именований, которые в свою очередь напрямую опираются на DNS имена интранет-портала.

Также логическая структура сайтов напрямую влияет на выдачу прав для пользователей – по аналогии с любой файловой системой, в SharePoint используется механизм наследования прав, который включен по умолчанию для каждого объекта, будь то сайт или список, но который можно выключить на любом из объектов. Выдав права какой-то группе пользователей на корневой сайт семейства сайтов при включенном наследовании приведет к тому, что пользователи этой группы автоматически получат доступ к любому объекту внутри этого семейства. Мы остановимся на моменте Best-practice выдачи прав пользователям в соответствующей главе.

В нашем сценарии будет использовано минимум одно семейство сайтов, URL имя которого будет intranet.company.com. Создание других семейств сайтов может быть необходимо в следующих случаях:

• когда необходимо разбить весь портал на отдельные структурные элементы на уровне URL адресации;
• когда требования дисковой требуют разнесения контента по различным SQL базам внутри одного веб-приложения;
• когда необходимо физически разделить сайты по разным веб-приложениям, это может быть продиктовано вопросами нагрузки фермы SharePoint, утилизации ее ресурсов, удобством обслуживания и отказоустойчивостью;
• когда есть потребность простого и жесткого разделения прав пользователей между двумя и более подразделениями (офисами) компании, например, выделить дать возможность «полевикам» (Field-Force) вариться в собственном информационном поле.

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

Как же правильно планировать данную логическую архитектуру?

В следующей главе в процессе создания портала мы непосредственно этого коснемся, а пока для простоты запомним следующие правила:

1. Назначение каждому семейству сайтов персонального веб-приложения и соответственно одной персональной контентной базы упрощает URL этих семейств сайтов (почему – читайте в следующей главе), упрощает и облегчает администрирование (принадлежность каждого веб-приложения сразу видно в том же «Диспетчере задач» по имени учетной записи, из под которой работает пул приложений, можно останавливать/перезапускать конкретную часть общего портала без вреда для других семейств сайтов), но значительно более требовательное к ресурсам сервера – требуется намного больше оперативной памяти и процессорного времени.
2. Назначение нескольких семейств сайтов одному веб-приложению (без разницы с одной либо несколькими контентными базами) снижает и аппаратные требования (нет дополнительных накладных расходов со стороны платформы .Net Framework, которая является CIL/CLR, в одном пуле происходит однократный запуск и предварительная компиляция), но усложняет и удлиняет URL сайтов семейств и приводит к неудобствам в администрировании, особенно на больших фермах SharePoint, призванных обслуживать большие портальные решения.
3. Разные семейства сайтов могут иметь разные контентные базы внутри одного веб-приложения, однако к сожалению, для SharePoint 2013 управлять этим через его штатную веб-консоль невозможно, только через консоль PowerShell.

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

Обратите внимание на вторые (зеленые) семейства сайтов, вернее на их URL – правила именования семейств сайтов в SharePoint требуют второе и последующие семейства сайтов, использующих одно веб-приложение, размещать после имени «первичного» семейства и зарезервированной части URL «…/sites/…».

Глава 4. Процесс установки или алгоритм «эксперимент, пи@#%ц, чтение документации».

SharePoint 2013 – сложный продукт. Нельзя просто взять и, нажав на инсталлятор, нажать десяток «Next» чтобы сразу получить результат из коробки. Вернее, конечно можно, но один раз и для версии Foundation. Еще есть вариант развернуть серверную редакцию в виде Stand-Alone (все роли фермы на одном сервере), но такая конфигурация по сути предназначена больше для одиночных разработчиков либо для тестовой фермы, но не для «продакта».

В общем, развертывание фермы SharePoint можно свести к ряду этапов:

1. Установка MS SQL Server.
2. Установка самого SharePoint, вернее его ролей Web Frontend и Web Application.
3. Первичная настройка, построение портальной структуры.
4. Интеграция SharePoint с другими сервисами компании: Office Web Applications, Exchange, Project, Dynamix и т.д.

Почему «сиквелл» на первом месте? Да потому, что мастер установки SharePoint Server почти сразу спросит Вас о его наличии. Его первым и поставим.

Установка MS SQL Server 2014.

С установкой MS SQL Server 2014 не должно возникнуть трудностей, тут таки то самое «Next-Next-Next», разве что не стоит забывать сразу перед установкой выключить Windows Firewall и предварительно добавить .NET 3.5 в Futures, иначе при развертывании сервера его мастер инсталляции выдаст соответствующее предупреждение:

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

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

Наименование экземпляра (Instance) сервера не имеет значения, можно оставить по умолчанию.

Все компоненты сервера для начала ставить нет смысла, достаточно следующих:

• Database Engine Services
• Client Tools Connectivity
• Management Tools Basic & Complete

Учетные данные служб и «коллейшн» оставляем по умолчанию. Если SQL сервер не предполагается в будущем использовать для каких-то других нужд кроме фермы SharePoint (что в принципе не желательно), то выбираем предлагаемый по умолчанию Windows authentication mode.

Очень важно производить установку и MS SQL Server, и SharePoint Server из-под одного доменного административного аккаунта, в этом случае вы сразу избежите кучи неочевидных проблем с авторизацией и правами в процессе установки SharePoint. Поэтому сразу указываем данную учетную административную запись в качестве первичного администратора сервера.

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

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

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

Последним шагом необходимо не забыть для тома «D» добавить в его корень полный доступ для служебной учетной записи «NT ServiceMSSQLSERVER» – по сути учетной записи, под которой крутится служба самого Database Engine.

Установка MS SharePoint Server 2013.

Развертывание продукта также следует начать с обновления операционной системы «до упора». SharePoint – очень гибкий продукт. Структура, конфигурация портала, и само его наполнение живут в базе данных, а поэтому сам процесс установки ролей Web FrontEnd и Web Application двухэтапный: сначала нам необходимо собственно установить эти роли, которые создадут стартовый «скелет» системы в виде папок и основных стартовых сценариев и шаблонов в веб-папке IIS, прогнать обновление системы (в который раз) и только затем запустить мастер конфигурирования продукта, который собственно создаст всю необходимую стартовую структуру непосредственно в базе данных MS SQL, которая в станет называться … и будет хранить конфигурацию (настройки) всей фермы SharePoint.

Итак, в директории инсталляции жмем заветный «Hello World!», тьфу, «setup.exe». Естественно, сразу наступаем на грабли:

А вот не надо было спешить… Разные продукты в MS делают разные группы людей, естественно присутствует принцип несообщающихся сосудов. Нам на самом деле нужен неприметный файлик default.hta, на который указывает autorun.inf, который конечно же у всех нормальных людей отключен либо руками, либо доменной политикой, либо вообще политикой сетевого антивируса.

Запускаем:

Как видим, здесь тоже есть установка пре-реквизитов. Делать нечего, ставим сперва их.

Если при попытке их установки выпрыгнуло нечто вроде этого:

Значит Вы живете на Windows 2012, не послушались автора, либо были невнимательны, скачали «SharePoint Server 2013» (без SP1) и Вам настоятельно необходим KB2771431, который не ставится самостоятельно через Windows Update. Элегантно проверить его наличие в системе можно через powershell: systeminfo | findstr «KB2771431».

Если же Вы запускаетесь на Windows 2012R2 с аналогичной проблемой – Вам необходим именно инсталляционный набор «SharePoint Server 2013 with SP1», который вышел уже после появления 2012R2 и учитывает новые грабли от MS. Иначе придется ставить все необходимые пререквизиты руками через сценарий PowerShell. Взять можно, например, отсюда.

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

Что затем? Правильно, снова обновляшки! Скорее всего залетит что-то вроде обновлений для ADRMS Client – ставьте, пригодится. Избежите одного очень противного бага, в случае если ваша портальная ферма будет обслуживать несколько доменов из разных деревьев…

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

Связано это с тем, что добрый дядя MS постоянно создает головную боль администраторам и радость программистам – занимается творчеством с обновлением .NET Framework. Проблема в том, что в вашей системе стоит его версия 4.6 (или уже даже выше), а инсталлятор SharePoint 2013, даже с SP1 на свою беду умеет работать только с 4.5.

Подробнее об этой проблеме, как ее точно определить и способе ее лечения. Вкратце – сносим фичу .NET 4.5 (на самом деле 4.6) с помощью утилиты MS DotNET CleanUp Tool, качаем и ставим ее ручками. После установки SharePoint 2013 можно будет с легким сердцем доверится Windows Update, которая вновь повысит ее до 4.6. Дальше ферма SharePoint будет работать с ней нормально. Вроде бы…

Кстати в одной из недавних боевых ситуаций наткнулся на кейс, когда удаление фичи .NET Framework 4.5 через стандартный системный мастер на Windows 2012 R2 начисто снесло весь GUI и PowerShell в придачу. То есть Вы правильно поняли, нас оставили в 2012 R2 даже без Core-режима ОС. Оболочка Explorer также не загружалась. Слава Богу, MS предусмотрел альтернативный консольный вариант загрузки, когда нечему грузится – альтернативно загрузится старый добрый cmd.exe. Тем, кто попал в аналогичную ситуацию — сюда. К слову, в том случае и CleanUp утилита не отрабатывала свое. Потому пришлось немного поразмыслить, сходить в панель управления и руками удалить KB, ответственное за появление в системе злополучного 4.6-го Framework-а. После перезагрузки ключ в реестре указал понижение версии и инсталлятор SharePoint-а заработал без проблем. Странно, что в MS не додумались указать этот вариант как вполне рациональный способ решения проблемы, а вместо этого предпочли выстрелить себе в ногу удалением критического компонента из системы…

Сама инсталляция продукта проста.

Выбираем режим установки (нормальная продакт-ферма или все на одном сервере). Наш выбор очевиден – первый вариант:

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

Через некоторое время установщик предложит запустить конфигурационный мастер:

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

Правильным шагом будет снова (в который раз) прогнать Windows Update с включенной настройкой поиска обновлений для других продуктов MS.

Когда все обновления установлены, настает черед собственно финального развертывания SharePoint. Ищем в меню START мастер конфигурирования под названием «SharePoint Products Configuration Wizard», запускаем его, соглашаемся с предупреждением что мастер перезагрузит некоторые посторонние системные сервисы и доходим до вопроса о создании новой или подключении к существующей ферме.

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

Нам естественно нужна новая ферма. Выбираем ее и получаем от мастера второй серьезный вопрос:

С именем сервера – все понятно, мы уже подготовили его. Имя конфигурационной БД лучше оставить по умолчанию, не будет потом путаницы при чтении документации. Мастер также спрашивает Вас о учетной записи, под которой будет выполняться подключение приложения конфигурации фермы с IIS на SQL сервер. Поскольку на этапе установки SQL сервера мы выбрали режим Windows аутентификации и мы работаем в домене, значит мы можем (и должны по Best-Practice) создать в домене отдельную служебную учетную запись для этой цели.

Поскольку в будущем мы не раз будем создавать подобные учетки, целесообразно выделить под них отдельный контейнер OU (Organization Unit или Подразделение) на который особо опытные и параноидальные товарищи смогут в дальнейшем еще и дополнительно накрутить групповую политику, ужесточающую безопасность.

Насчет прописывания данной учетки в SQL Server беспокоиться не стоит – мастер конфигурации SharePoint все корректно сделает за нас (когда-то, во времена WSS 3.0 и SharePoint Server 2007 это нужно было делать руками).

Единственное, чем сейчас действительно стоит озаботиться перед нажатием заветной кнопки «Next», так это дополнительной юстировкой SQL сервера. Пришло время залезть к нему в конфигурацию и переопределить расположение файлов новых БД по умолчанию. Напомню, в нашем сценарии развертывания мы условились все БД фермы SharePoint складировать на том «D» сервера SQL, который специально развернут на быстром RAID-е. Его и вписываем:

Все, можно нажимать педаль «Next». Вас спросят парольную фразу, которая будет использоваться для шифрования некоторых критически важных данных. Чем-то это напоминает аналогичное окно с вопросом при развертывании Active Directory. Рекомендуется ее запомнить, т.к. в отличие от AD здесь она потребуется не только на этапе восстановления при сбое, но и при любых серьезных изменениях в структуры фермы, например, при добавлении нового сервера.

Далее Вас спросят об порте и режиме аутентификации административного веб-приложения и пользователя. Порт лучше оставить сгенеренный рэндомно дефолтный, только не забыть проковырять под него отверстие в системном Windows FireWall, если Вы используете его в доменной среде. Насчет аутентификации — по умолчанию стоит NTLM. Для большинства сценариев этого более чем достаточно, т.к. после развертывания и настройки собственно конфигурирование всей фермы будет выполняться редко, возможно и вовсе в режиме RDP подключения к WFE серверу (т.е. Вы будете запускать браузер и открывать страничку конфигурации фермы на самом же сервере, где крутится IIS с ней) и достоинства Kerberos аутентификации будут оправданы только в случае повышенной паранойи. Если же Вы все-таки решитесь выбрать вариант Kerberos – будьте готовы вносить руками нужные spn атрибуты в AD. Мой совет – не создавайте себе лишних проблем. С Kerberos-ом мы еще не раз столкнемся при создании семейств сайтов.

Кстати некоторые, не слишком опытные администраторы интеграторов таки выбирают этот вариант и затем ничего не настраивают и при этом у них почему-то вроде все работает… Только на самом деле в этом случае идет попытка аутентификации через Kerberos первым, она успешно проваливается и веб-приложение переходит на резервный вариант – NTLM. Это прекрасно видно через консольную команду klist – билет (ticket) не выдается.

Вернемся к нашему мастеру конфигурирования SharePoint. Далее он в последний раз даст нам посмотреть на введенные нами параметры и начнет делать свою работу. За ее результатами можно наблюдать не только в окне мастера, но и периодически поглядывая в сервер SQL – там будут созданы две первые базы, в настройки безопасности сервера будет внесен новый «логинс» в SQL, ему будут выданы необходимые серверные роли и права.

Когда мастер успешно отработает, настанет время запуска заветной консоли администрирования «SharePoint 2013 Central Administration»:

Если при запуске выскочило стандартное окно IE запроса логина и пароля – не расстраивайтесь. Просто MS кое-что поменял в локальной политике безопасности в Windows 2012 / 2012R2[16]:

Проблема в включенной по умолчанию проверке на т.наз. Loop Back check. Если оно Вам надоедает, от него можно избавится путем создания нового ключа реестра BackConnectionHostNames типа Multi-String Value в HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaMSV1_0, в котором перечисляем все адреса всех семейств сайтов, на которые предполагается заходить локально на данном сервере SharePoint WFE.

Все, основные сервера фермы SharePoint Server 2013 успешно развернуты, поздравляем. Настало время наполнить их смыслом.

Глава 5. Создаем портал. Муки творчества.

Настало время необузданно предаться творчеству.
Так же, как театр начинается с вешалки, наш портал начнется с веб-консоли администрирования:

Консоль администрирования в SharePoint 2013 очень похожа на старую Панель управления Windows – весь функционал разбит логически на группы. Этим она отличается от консоли старого SharePoint 2007, которая была больше похожа какую-нибудь старую классическую CMS.
На стартовую панель выведены только самые основные функции управления, гораздо больше их скрыто внутри каждой из групп. Нам нужна группа «Application Management»:

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

Создание веб-приложения.

В Application Management идем в Manage web applications:

Как видим, у нас в наличии пока только одно веб-приложение, да и то обслуживает сам центр администрирования. Мы видим ссылку (URL), на которой вертится сайт, обслуживаемый веб-приложением и порт, на котором висит данный сайт. Если мы посмотрим на адресную строку браузера, то увидим некоторое сходство.

Нужно создать веб приложение. Основным отличием SharePoint 2013 от своего предшественника SharePoint 2010 является компоновка интерфейса. Microsoft остался верен своей политике последовательной модернизации интерфейсов в своих программных продуктах, поэтому дизайн меню в стиле Ribbon, впервые представленных в пакете MS Office 2007 – постепенно добрался и до веб-интерфейса SharePoint.

Найдите на ленте слева вверху кнопку New и нажмите на нее. Откроется страница создания нового веб-приложения:

Пробежимся по всем полям формы и заполним их.

Нам предлагают выбрать существующий на сервере сайт IIS либо создать новый, задать его имя (на сервере IIS, не путать с URL), порт, на котором он будет висеть, заголовок (собственно URL) и путь к папке сайта внутри веб-дерева IIS в файловой системе.

Нам по дефолту предлагают создать сайт, не использующий SSL. Давайте сразу делать все правильно.

Давно прошли те времена, когда SSL использовался только на некоторых сайтах в Интернете, да и то на них не везде, а только для тех страниц, через которые выполнялась авторизация. Это было продиктовано соображениями уменьшения нагрузки, вызванной необходимость выполнять шифрование, как на веб-серверах, так и на стороне ПК пользователей. Времена те давно прошли, вычислительных мощностей в избытке и сейчас стоит вопрос уже о том, чтобы вообще отказаться везде в Интернете от чистого HTTP в пользу HTTPS.

Для теста я уже сгенерировал самоподписный сертификат для доменного имени intranet.company.com и прописал его в корневые локального центра сертификатов на сервере роли WFE&WebApp. Если Вы хотите сделать то же самое – Вам дорога в оснастку IIS, в Server Sertificates – справа в панели выбираем Create Self-Signed Certificate…:

Поскольку в статье мы имеем дело с тестовой фермой SharePoint, доменное имя intranet.company.com является вымышленным и наш доменный DNS сервер об этом не знает.

Помогаем ему в этом:

Заполняем поля согласно скриншота:

Обратите внимание, в Claims Authentication Types нам предлагают выбрать по умолчанию метод аутентификации пользователей NTLM, но я выбрал Nogotiate (Kerberos). Дело в том, что метод NTLM более универсален в силу отсутствия необходимости какой-либо настройки, т.е. будет работать из коробки. Портал на базе SharePoint умеет «спрашивать» браузер (или любую другую программу, выполняющую запрос ресурса с него) об учетных данных пользователя в системе Windows, из-под которых он работает, для того, чтобы не задавать лишних вопросов в духе «введите имя и пароль».

Почему же я выбрал именно Kerberos, а не NTLM? Если знать, как работает авторизация в доменах Windows, то ответ напрашивается сам собой: авторизация «по керберу» быстрее, меньше «шумит» по сети и технически более безопасна и надежна. Есть и обратная сторона медали – она требует ручной настройки и не работает вне пределов леса. Т.е. если мы имеем в наличии два офиса с развернутыми внутри доменами в разных лесах, но с настроенными трастами и Site-To-Site VPN подключением между ними (типичная ситуация), то к сожалению, работать Kerberos для запросов из второго офиса не будет.

Хорошая новость в том, что в случае выбора Kerberos-а в качестве основного метода аутентификации NTLM продолжает использоваться как запасной. Если «кербер» в силу каких-то причин не отработает – будет автоматически произведена попытка через NTLM.

Настройка домена для Kerberos не так уж сложна. Все, что нам потребуется – исправить настройку и атрибут в Active Directory.

Вначале идем в оснастку управления Active Directory Users and Computers, в ее меню View переключаем в расширенный (Advanced Features) вид, идем в свойства сервера с ролью WFE и включаем ему возможность делегирования:

После этого идем в свойства учетной записи, из-под которой будем крутить веб-приложение на сервере IIS. Для простоты для первого семейства сайтов и его пула приложений я выбрал того же пользователя, которого мы создавали на этапе установки SharePoint.

Active Directory – это на самом деле объектная база данных, внутри нее все объекты имеют некоторый набор атрибутов – полей, которые могут хранить какие-то значения. Нам необходимо для учетной записи изменить атрибут servicePrincipalName – вписать туда в определенном формате доменные имена сайтов:

Всё, все необходимые для авторизации по Kerberos настройки успешно выполнены.

Проматываем форму создания веб-приложения ниже, до следующих настроек, которые нам интересны:

Здесь все довольно интуитивно понятно. Нам автоматически сформировали URL на основе введенных ранее данных, предложили создать новый пул приложений с определенным именем (которое я для красоты немного подкорректировал), посоветовали выбрать пользовательский аккаунт (и автоматом подсунули туда тот, что мы как раз приготовили под Kerberos), предложили указать SQL сервер, имя контентной БД и учетные данные для подключения. Имя контентной БД выбирайте любое по своему вкусу, я бы рекомендовал давать ей осмысленное имя, прямо указывающее какое семейство сайтов или веб-приложение ее использует.

Жмем в самом конце кнопку OK и ждем результата. Нас радуют надписью, что это не займет много времени. Кстати подобные надписи Вы в SharePoint 2013 вы будет видеть постоянно. Разработчики перед Вами все время будут извиниться за невысокую производительность продукта. Что-ж поделаешь, .NET Framework и выбранная архитектура с прицелом на большую гибкость и масштабирование всему виной.

По окончанию процесса мы получим готовое веб-приложение, которое можно будет лицезреть в виде строчки в списке веб-приложений в админке SharePoint, а в оснастке IIS в виде сайта и в виде пула приложений.

Поскольку у нас уже появился сайт на сервере IIS, мы можем привязать к нему созданный нами самоподписный сертификат. Нажимаем на сайте ПКМ, выбираем Edit Bindings, подхватываем сертификат:

Настало время сделать семейство сайтов.

Создание семейства сайтов.

Снова идем в Application Management и там в Create Site Collection:

Выбираем название (заголовок) корневого сайта семейства, выбираем совместимость с версией (SharePoint 2013 обратно совместим с SharePoint 2010 и по сути позволяет создавать сайты старой версии), выбираем шаблон, при желании добавляем учетные записи дополнительных административных учетных записей сотрудников, которым мы разрешим делать что угодно в рамках этого конкретного семейства сайтов и выбираем шаблон квоты:

Про администраторов уровня семейства сайтов и квотирование пользователей мы поговорим детально в следующей главе.

Жмем ОК.

Идем на наш новый портал. При попытке захода будет ругаться на самоподписный сертификат. Борем любым методом – просто соглашаемся, добавляем в локальное хранилище сертификатов либо сразу в доменную групповую политику.

При попытке зайти на сайт будет спрашивать учетные данные – добавляем сайт в зону Local Intranet или в Trusted Sites в настройках IE в системе. Чтобы не надоедало, можем также сразу добавить сайт в настройки зон для разных версий браузера в доменной групповой политике.
Радуемся:

На показанном выше скриншоте мы видим стартовую страницу нашего портала. Анатомия страницы очень проста, Microsoft в этот раз довольно много сделал для «чистоты» и лаконичности интерфейса, впервые оптимизировав дизайн портала под новый METRO интерфейс и под портативные планшетные экраны и управление при помощи прикосновений.

Многие элементы по умолчанию скрыты, например, вверху слева во вкладках притаились панели кнопок в стиле Ribbon:

Справа вверху находятся кнопки управления своим локальным профилем в SharePoint (кнопка с названием учетной записи), кнопка настроек (Settings, в виде шестеренки), кнопки «социальных» действий, кнопка редактирования страницы и, наконец, кнопка переключения режима отображения страницы (включения/выключения боковой панели ссылок слева).

Все остальное поле страницы кроме вышеназванной панели «быстрых ссылок» занимает собственно контент страницы, т.е. пользовательские данные.

Самая часто используемая в нашем случае кнопка будет естественно «шестеренка» — Settings:

Настало время заняться локализацией.

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

Microsoft выпустил для SharePoint 2013 большое количество языковых пакетов (Language Pack’s), которые можно скачать совершенно бесплатно. Качаем с сайта microsoft.com и ставим:

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

SharePoint 2013 обладает способностью автоматически подстраивать локализацию интерфейса под пожелания пользователя. Пожелания могут выражаться в двух видах: пользователь может прямо задать предпочитаемую локализацию в своих персональных настройках (нажав на «кнопку» с именем своей учетной записи справа вверху страницы) либо портал по умолчанию может считывать локаль системы и при наличии развернутого языкового пакета сразу выдавать страницы на нужном языке.

Администратор должен предварительно указать в настройках сайта используемые языковые пакеты, если они будут установлены. Для этого учимся редактировать настройки сайт – жмем на «шестеренку» справа вверху, выбираем в открывшемся меню Site Settings и поражаемся богатству возможных настроек:

Нам нужна настройка Site Administration – Language settings:

Как видим, явно после нашей установки здесь появился второй пункт альтернативного языка. Активируем его.

Также не лишним будет сходить в Site Administration – Regional settings и подкорректировать общие настройки локали сайта: единицы измерения, календарь, дни недели, регион и прочее.

После всего этого, если у Вас стоит в Windows русская локаль – Вы увидите интерфейс сайта на родном языке:

Если у Вас русской локали по какой-то причине нет, но очень хочется интерфейс на русском – как писалось выше, можно исправить отображаемый язык в персональных настройках (кнопка с именем учетной записи – My Settings — My Language And Region – выбираем нужный язык по вкусу в My Display Languages. Естественно будет работать, только при условии установленных языковых пакетов и их подключения в конкретном сайте:

Анатомия сайта SharePoint.

Как мы выяснили ранее, сайт SharePoint – это по сути контейнер контента в семействе сайтов. В нем могут размещаться другие страницы (минимум одна из которых присутствует изначально и является корневой) и списки различных типов.

Для начала научимся управлять внешним видом сайта. Подобно многим другим CMS страница SharePoint представляет собой набор шаблонов с определенной тематикой управления. В 2013-й версии Microsoft довольно много сделала для удобной возможности правки внешнего вида страницы сайта прямо на месте, не прибегая для этого к каким-то специальным инструментам.
Стиль сайта одним махом можно поменять, если зайти в Settings – Change the look:

Обратите внимание, мы можем менять не только саму тему, но и базовые параметры ее оформления в виде фона страницы, гарнитур шрифтов и цветовой палитры [44]:

Тут-же можно и попробовать тему в деле. Очень похоже на тот же WordPress.

Помимо выбора темы теперь (в 2013-й версии) присутствует встроенный WYSIWYG-редактор страниц. Опять таки, теперь нет надобности в стороннем приложении. Кстати на будущее, под сторонним приложением обычно понимают MS SharePoint Designer 2013 – специальный веб-редактор, заточенный под SharePoint. Программа эта с «славной» родословной, ее прямой предок – FrontPage, если кто не знает, это название среди веб-верстальщиков когда-то было именем нарицательным – очень он любил вставлять при верстке массивные шаблоны кода где надо и где не надо. Ходят слухи, что 2013-я – это последняя версия этого многстрадальца и либо его больше не будет, либо его функционал, как расширенный инструмент для MS SharePoint, встроят в MS Visual Studio.

Вернемся к редактированию страницы. Редактировать ее просто, достаточно либо нажать на кнопку EDIT справа вверху, под шестеренкой, либо в меню Settings выбрать аналогичный пункт:

Редактор очень похож внешним видом на MS Office Word – тот же Ribbon.

Обратите внимание, что на канве страницы появились видимые прямоугольные рамки вокруг элементов контента – два блока приветственного «баннера» Get started with your site и библиотеки документов Documents. Это включилась подсветка так называемых «веб-частей» (Web Parts) — объектов страницы, которые отвечают за визуализацию чего-либо.

Эти веб-части можно двигать на странице путем простого перетаскивания. Поначалу это не так легко и требует сноровки, но вполне удобно. Например, ниже представлена эта же страница, только переделанная в двух-колоночный вид:

Помимо веб-частей, на странице также можно впечатывать в произвольном месте текст, размещать изображения и прочие элементы. Поверьте, по сравнению с предыдущими версиями SharePoint, в 2013-й это прямо прорыв в возможностях.

По окончанию редактирования страницы необходимо нажать на кнопку сохранения SAVE – внесенные Вами изменения смогут видеть Ваши пользователи.

Веб-части бывают двух типов: простые, которые «живут» самостоятельно на странице и веб-чести «приложений» (App Parts). Под приложениями в SharePoint 2013 понимают пользовательские хранилища контента – те самые списки всевозможных типов.

К примеру, веб-часть «Get started with your site» — это самостоятельная веб-часть, она присутствует только на странице и играет роль баннера для новичков. Если Вы удалите ее со страницы, то она удалится «с концами», вместе со своими настройками, если они были изменены. Конечно, ее можно добавить вновь:

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

Займемся этим.

Пожалуй, одно из самых важных пунктов меню, куда Вы будете поначалу заглядывать, это пункт «Site contents»:

Здесь отображаются все приложения данного сайта, отсюда же можно создать новое приложение, а также дочерний к данному сайт. Обратите внимание, что в ново-созданном семействе сайтов в корневом сайте уже содержится ряд приложений. Некоторые из них являются служебными, как например Site Pages и Site Assets, их удалять не рекомендуется.

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

Попробуем добавить новое приложение и разместить его на странице.

Нажимаем «add an app». Кстати быстро добавить приложение можно также и из основного меню Settings сайта:

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

Библиотека изображений умеет показывать сразу миниатюры картинок и даже устраивать показы их как слайдов. Календари, задачи и контакты – синхронизироваться с Microsoft Office Outlook, что очень удобно для коллективной работы. Есть приложение с функционалом простого форума, есть список новостей с рассылкой, есть приложение для сбора и визуализации результатов голосования, есть простой список с ссылками на внутренние или внешние ресурсы. В серверной и энтерпрайзовой редакции присутствуют приложения для подключения к внешним источникам данных, библиотеки отчетов и так далее. Описывать все это в статье нет смысла, достаточно самим попробовать поиграться со всеми этими приложениями.

Попробуем создать простейший список.

Выбираем его (Custom List) из перечня приложений, от нас попросят ввести его имя. Одним из замечательных изменений в SharePoint 2010-2013 по сравнению со старыми версиями продукта является то, что имя приложения теперь не является частью его URL ссылки. Проще всего это пояснить на примере:

Здесь я создал список и присвоил ему имя. Он отобразился в контенте сайта, SharePoint для нашего удобства подсветил его зеленым флажком «new!». Если навести на него курсор мыши, браузер подскажет ссылку, по которой будет выполнен переход, если мы сделаем щелчок мышью на нем: intranet.company.com/Lists/List/AllItems.aspx. В нашем случае приложение списка получило имя URL «List», таким образом полный путь URL к содержимому списка получился, как написано ранее. В более старых версиях SharePoint имя URL приложения формировалось на основе его имени как элемента, введенного пользователем. В результате, особенно в отличных от английского названиях, включался юникод и длина URL списка могла получиться чрезмерно большой, ведь URL автоматически учитывал вложенность сайтов и их элементов.

С точки зрения администрирования SharePoint это выливалось в проблему превышения допустимой длины URL, которая разная для разных браузеров. Да и работать с такими ссылками довольно неудобно и пугающе для пользователя. К этому следует добавить проблему работы других приложений, например, MS Office до 2007-й версии включительно категорически не хотел открывать по ссылке документы с портала, если длина их URL был более 256 символов – очевидно стояла проверка на длину для защиты переменной от переполнения. Приходилось идти на всякие малоочевидные хитрости, например, сперва давать приложениям короткие названия на английском языке, а затем их редактировать на желаемый – адрес URL формировался автоматически на этапе создания и при изменении собственно имени приложения уже не менялся.

В последних версиях SharePoint с этим полный порядок – всем создаваемым приложениям автоматически присваиваются короткие английские «типовые» имена URL и группируются в наборы подобных элементов.

В качестве иллюстрации — вот как будет выглядеть имя URL для второго нового списка:

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

Хорошая привычка — научиться сразу продуманно именовать URL сайтов. Лучше всего одним словом, на английском языке.

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

Управление навигацией.

Базово почти любой стандартный шаблон сайта предполагает наличие двух навигационных панелей – верхней, главной и левой, боковой, так называемой панели быстрого запуска «quick launch».

Функционал верхней панели не изменился с времен старых выпусков SharePoint, однако добавилась возможность более удобной его правки прямо на странице, причем для этого даже не надо заходить в режим ее редактирования. Панель также может автоматически быть общей для всего семейства сайтов (наследываться), либо быть уникальной для какого-то конкретного подсайта.

Функционал панели быстрого запуска также может редактироваться «не отходя от кассы», однако сама панель стала интеллектуальной. Теперь на нее автоматически могут добавляться ссылки последних посещенных списков, библиотек и прочего. Это на самом деле довольно удобно и стоит отметить это для себя на будущее, как одна из «плюшек», которую можно упомянуть в обучении пользователей.

Последнее, что хотелось бы рассмотреть в данной главе – изменение параметров сайта.

Чтобы зайти на страницу с ними – необходимо выбрать в меню Settings пункт Site Settings:

Богатству настроек нет предела. Можно настроить все – начиная от имени сайта и заканчивая дублированием редактирования его навигации.

Стоит обратить внимание на то, что настройки корневого сайта семейства сайтов будут сильно отличаться от количества доступных настроек подчиненных сайтов:

Связано это с тем, что настройки корневого сайта затрагивают все семейство сайтов в целом, поэтому там и присутствует отдельная, большая группа настроек Site Collection Settings.

 

В следующих частях статьи:

Глава 6. Разделяй и властвуй: права пользователей и администраторов. Как их делегировать правильно, чтобы в будущем не иметь головной боли.
Глава 7. Браузерные войны.
Глава 8. Как сделать так, чтобы вашим порталом действительно пользовались.
Глава 9. Делаем сопряжение с другими системами и платформами на примере Office WebApps.
Глава 10. Продвинутое администрирование.
Глава 11. Второе правило системного администрирования (резервное копирование).
Глава 12. Как не спать ночами или что вы должны знать об обновлении портальной фермы.
Глава 13. Таинственные рабочие процессы.

Автор: AllanStark

Источник