Pull to refresh

Строим инфраструктуру на базе продуктов MS

Reading time 8 min
Views 18K
image После публикации своего первого поста «Почему я люблю Microsoft. Заметки Зомби» я получил достаточно много писем с похожей просьбой — написать подробнее об используемых продуктах.
Просили — получите. При написании статья я поставил себе цель — описать основной маршрут. Расписывать тонкости установки и настройки нет смысла — их достаточно в Интернет. Я старался, чтобы прочитав этот пост администратор знал названия продуктов и технологий, для чего они нужны и потом уже мог ловко нагуглить всё остальное. Для того, чтобы облегчить поиск ключевые названия будут на английском. Если какая-то аббревиатура незнакома — это повод про неё почитать. И, да, я буду описывать решения от Microsoft, так как что-то смыслю только в них. Хочу сразу предупредить что топик очень конспективный.


До того как я начну — справка и воззвание :)
После первой статьи мне много раз написали, что я не прав, не указывая сколько стоит удовольствие. Пинки законные, стоит дорого. Спрашивали — отвечаем. Грубо вы можете оценить это так — лицензия Enterprise Agreement (покупать её можно имея от 250 ПК) будет вам стоить 1000 уёв на рабочее место. Сервера в это всё войдут. То есть, очень грубо, лицензирование развесистой инфраструктуры для 300 ПК будет стоить 300 тысяч $. Выплачивать нужно будет по 100 тысяч в год в течение 3 лет, в течение этого времени вы можете ставить все последние версии купленного ПО.
Это самый дорогой и безгеморойный способ лицензирования, другие дешевле. Кстати, если будете покупать ПО Микрософт в таких масштабах — мой совет торгуйтесь.
Насколько это дорого решайте сами. Конкретно для моей организации одно только внедрение Project Server позволило, за счёт эффективного планирования сотрудников работающих на проектах, не нанимать ещё 7 сотрудников к имеющимся 40 и таким образом сэкономить примерно 7*1300$*12 то есть те самые 100 тысяч в год, это стало очевидным аргументом эффективности решения.
Сразу хочу оговориться. Я не призываю воровать или напротив покупать ПО Microsoft. Я призываю к другому: Неважно, приверженец ли вы бесплатного ПО или проприетарного — подумайте как построить что-то большее чем инфраструктуру, обеспечивающую только базовые сервисы. Постройте хорошую инфраструктуру, дружественную к людям, постарайтесь минимизировать количество бумаг в офисе, берегите леса и пусть ваша карма вознесётся к светлым вершинам.

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

Итак, собственно руководство. Начинаем.
0. Я очень люблю Hyper-V. Ставим Server 2008 в core mode и при прочих равных разворачиваем инфраструктуру на виртуальных машинах.
0.1 Бэкапы бэкапы бэкапы. Не вводим в строй ни одну систему не разобравшись как мы будем проводить резервное копирование.
1. Ставим сервер, поднимаем Active Directory. Поднимаем основные службы DNS, DHCP. При первой возможности ставим второй серер, на котором также поднимаем AD. Хотя многие мелкие организации этим пренебрегают, это очень важно, ибо если помрёт единственный контроллер домена будет очень очень грустно. <update 12.04.10 10:15> Назначаем второй контроллер домена также сервером Глобального Каталога. /update Настраиваем синхронизацию времени на контроллере домена с внешими источниками эталонного времени. NTP.
1.1 DNS. Подумайте заранее про то, как будет называться ваш домен, будет ли название совпадать со врешним именем или отличаться от него. Почитайте про Split DNS. Людям удобно запоминать единые адреса для сервисов. Например mail.yourdomain.ru — всегда должно быть почтой вне зависимости снаружи или изнутри сети компании работает сотрудник. Если DNS имена наружней и внутренней сети различаются — поднимите внутри сети зону yourdomain.ru
1.2 DHCP. Фиксированных адресов быть не должно. Используйте Reservation для MAC адресов устройств. Это нужно чтобы вы могли в любой момент владеть полной информацией по распределению адресов в сети.
1.3 Заводим в AD всех пользователей. Каждому подразделению выделяем Organizational Unit в соответствии с иерархией организации. Распихиваем пользователей по OU. Для каждого OU создаём группу, в которую включаем всех пользователей. Каждому пользователю — по учётной записи. Никаких записей «Кладовщик» для 12 кладовщиков разом. Для учетных записей компьютеров также желательно иметь отдельную иерархию OU в соответствии с иерархией организации — так легче привязывать групповые политики для всех ПК отдела.
1.4 Даём секретарям права на изменения полей номера телефонов в AD. Обучаем. Заполнять и поддерживать эти данные в актуальном состоянии теперь их обязанность. Они-же или HR должны поддерживать в актуальном состоянии название должности и отдела в AD у всех сотрудников. Также, при переводах сотрудников, администратор перетаскивает учетки в нужный OU, меняет членство в группах. Делаем регламент — как пользователь попадает в нашу сеть при приёме на работу, что мы делаем при его увольнении, при переводе в другой отдел. Вводим стандарты на формирование Login name и почтовых адресов сотрудников.
2. Загоняем компьютеры пользователей в домен.
3. По возможности лишаем пользователей прав администратора. Часть ПО при своей рядовой работе хочет писать данные в запрещённые по умолчанию места — отлавливаем это с помощью специального ПО, например Process Monitor, тонко настраиваем права. Единожды разобравшись с программой — выписываем к каким ветвям реестра и каталогам у неё дополнительно должен быть доступ, делаем настройки, распространяем их с помощью Group Policy на подходящий OU. С помощью GP цепляем людям ближайшие принтеры. Добавляем в логин скрипт ПО, собирающее данные по нашим ПК — название, кто логинился, какое стоит железо, IP адрес, МАС адрес и так далее и складывающее всё это добро на сервер.
4. При необходимости ограничиваем доступ ко внешним накопителям, например с помощью Device Lock.
<update 9.04.10 15:55> Также можно настроить это с помощью групповых политик. /update
5. Настраиваем корпоративный антивирус, следим за его обновлениями
6. Поднимаем и настраиваем WSUS. Не бойтесь, расставляться будут только обновления, утверждённые Вами.
7. Расшариваем на сервере файловые ресурсы. Бъёмся смертным боем, чтобы ресурсы расшаривались на группы, а не на персональных сотрудников. Иначе очень скоро система прав превращаются в кашу, невозможно дать новому сотруднику права аналогичные другому сотруднику, уже работающему и так далее. Очень важно донести до руководства почему нужно делать именно так и получать от них заявки на изменения прав в таком разрезе.
8. Поднимаем SQL сервер. Он нам понадобится, чтобы хранить там базы 1С и вообще вещь хорошая.

Все наши пользователи работают с расшаренными ресурсами на сервере. Мы неплохо защищены от вторжений вирусов. Таким образом мы более менее обустроили рабочие места сотрудников.

9. Поднимаем и настраиваем ISA сервер для доступа в Инет. Сейчас его преемник ForeFront TMG, мы пока не внедряли. Настраиваем Proxy autodiscovery и/или прописываем всем наш прокси в IE групповыми политиками, прописываем внутреннюю сеть в адресе исключений — доступ к ней мимо прокси. Не забываем подумать и проверить, как будут работать ноутбуки вне нашей сети. Не будут ли они пытаться лезть в инет через проки?
9.1 Нстраиваем правила для доступа пользователей наружу. Правил, разрешающих доступ куда угодно исходя из IP адреса сотрудника — такого по минимуму, только для коммуникатора директора. Создаём группы в AD по типу доступа, например: «только по белому списку», «куда угодно». Засовываем в эти группы группы подразделений. Например группу «Склад» запихиваем в группу «Только белый список». Создаем на ISA белый список сайтов, чёрный список сайтов, настраиваем правила с правами доступа в соответствии с группами AD и списками сайтов. Для клиент-банков и прочего ПО, которое не умеет авторизоваться на нашем сервере — в ISA включаем монитор, смотрим куда ОНО ломится и разрешаем весь трафик на IP сервера клиент-банка не на базе учетной записи пользователя, а на базе IP компьютера, в идеале прописываем ещё и протоколы.
Общая логика правил на ISA — весь трафик за очень редкими исключениями должен ходить через наш шлюз по правилам, которые привязаны к доменной учетке пользователя.
Лично я не люблю ISA Firewall Client, мы всегда обходимся без него и вам советую. Все настройки на сервере это централизация.
9.2 Если у нас есть филиалы — тоннель между ISA серверами, если у нас есть удаленные пользователи — VPN доступ в нашу сеть.
9.3 Если нужны хорошие ограничения для пользователей — например Иванов может качать не больше 200Мб в день — Bandwith Splitter
9.4 Все логи, конечно, храним на SQL сервере и не за семь дней, а минимум за 45 — когда-нибудь точно понадобится сформировать отчет кто сколько скачал за месяц.

Наши пользователи работают в Инете. Доступ в Интернет чётко разграничен правилами. Все ходы у нас записаны для последующих разборов. Удалённые пользователи имеют возможность подключаться и работать внутри нашей сети.

10. Поднимаем сервер терминалов. Загоняем на него пользователей, работающих из дома, тех кто активно работает с нашими ресурсами из удалённого филиала, возможно часть офисных пользователей.
11. Поднимаем Certification Authority, оно будет нужно.
12. Поднимаем Exchange Server. Почта пользователей должна лежать на нём, никаких Личных Папок — только для давних архивов. Работа пользователей — через Outlook. Если организация помешана на безопасности — Message Mirror почты на отделный адрес, задумываемся о том, как часто мы будем очищать его и куда будем архивировать его содержимое. Проверяем работу Global Address List, создаём его offline версию. Настраиваем ограничения на размер письма, ящика и так далее. Настраиваем на сервере антивирус и антиспам. Настраиваем коллективные почтовые ящики типа support@yourdomain.ru, даём ответственным права писать от имени саппорта, обучаем их. Настраиваем Public Folders запихиваем туда общие календари переговорных, демостендов и так далее, думаем что ещё у нас есть коллективного. Если сочтёте удобным — ведём личные календари в Оutlook и шарим их начальству. Общую систему задач на базе задач Outlook делать не нужно — задачи Outlook неудобны для коллективной работы.
13. Публикуем наш Exchange через ISA, проверяем прохождение внешней почты в обе стороны, не забываем про open relay, подписываем всё что нужно сертификатами, проверяем работу Outlook Web Access, включаем OMA, публикуем RPC over HTTP. У пользователей ноутбуков настраиваем Outlook на RPC over HTTPS, кэширование и offline address book. Если нужно кэшировать содрежимое общих папок — их нужно в Outlook добавить в Избранные папки, а затем в Избранное.

У нас работает почта, люди могут подключаться с помощью Outlook как изнутри сети, так и извне — достаточно только доступа в Интернет. Мы можем работать с помощью Web интерфейса, а также с наших мобильных устройств. Отовсюду мы видим одно и то же содержимое ящика.
Мы научились коллективно работать с адресами типа Support@yourdomain.ru


14. Читаем про Unified Communications. Настраиваем Office Communications Server, дружим его с нашей офисной АТС. Настраиваем маршрутизации и номерные планы. Настраиваем его дружбу со списком пользователей из AD.
Расставляем заинтересованным пользователям Office Communicator, выдаём гарнитуры.

Звонки через office communicator на другие офис коммуникаторы, внутренние телефоны, город. Всё без дополнительных префиксов. Коммуникатор знает всех пользователей из AD, вместе с их внутренними и мобильными телефонами.

15. Поднимаем Sharepoint Server. Засовываем туда красивый список сотрудников, данные о днях рождения сотрудников, но без года рождения (девушки волнуются), новости компании. Потом начинаем создавать там структурированное хранилище информации, пытаемся, чтобы основная часть файловой помойки плавно переехала туда. Позже подтягиваем туда рабочие процессы, заявки и так далее. Перекидываем туда резервирование переговорных и прочее, что держали в общих папках.
16. Если мы активно работаем с проектами — разворачиваем Project Server

У нас появился корпоративный портал — единое место для справочной информации, основных рабочих процессов, структурированное файловое хранилище.

<update 9.04.10 14:25> Когда организация подросла реализуем на нашем портале систему обработки заявок. Делаем это с помощью Workflow на Sharepoint. Почитайте про InfoPath и Sharepoint Designer. Заявки должны приходить в единое место, закрепляться за сотрудниками, автор заявки должен видеть её текущий статус, получать по ней уведомления. /update

Описываем основные приёмы работы с нашей инфраструктурой, а лучше делаем видеокурсы. Выкладываем в места общего пользования (я про сервер), тренируем людей туда заглядывать по оповещениям на портале — там будет описываться работа с новыми сервисами. Вносим ознакомление с этими документами одним из обязательных пунктов для первого дня работы нового сотрудника.
Описанных действий должно хватить, чтобы реализовать все примеры использования, приведённые в этом топике. Если что-то забыл — пишите. Неосвещённой осталась тема Microsoft System Center, обязательно почитайте про него, но это продукт нацеленный нести блага не рядовым пользователям, а системным администраторам.
<update 9.04.10 14:25> Спасибо за комментарии. В целом, при таком масштабе организации уже самое время задумываться об облегчении жизни IT отдела, для этого присутствуют все необходимые технологии. Читайте про System Center. /update

Удачи.
Tags:
Hubs:
+104
Comments 100
Comments Comments 100

Articles