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

    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

    Удачи.
    Share post

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 100

      +3
      Вот это полезный пост! И несмотря на то, что я сторонник OpenSource, всё же как бывший win-админ ставлю вам большой виртуальный плюс (чем могу, увы), очень многим начинающим админам этот топик поможет сориентироваться в продуктах MS и построить правильную инфраструктуру.
        0
        полностью согласен. Несмотря на то что мы делаем решения на линуксах, структура и подход очень похожи.
        Стиль изложения лаконичен.
      • UFO just landed and posted this here
          +6
          Здесь не нужны ни одни ни другие. Пост не для них.
          Автору спасибо
            +5
            Как один из помешанных «фанатиков-линуксоидов», смею заявить от лица части себе подобных, что пост хоть и во многом рассказывает о весьма повседневных и очевидных вещах, но вскопе, очень четко и грамотно. И уж точно не несет никакой привязки к M$ и сиеподобному. Можно было написать вместо конкретных продуктов просто названия использованых технологий, но я думаю автору намного комфортнее было оперировать именно продуктами. Найти аналоги в *nix не трудно. Не нужно пытаться искать холивар там где им и не пахнет, исключительно потому что вы «первонах» и увидели в посте слова Microsoft.
            • UFO just landed and posted this here
                0
                Видимо, это были Вы соми.
                • UFO just landed and posted this here
            0
            спасибо, было интересно!
              +1
              в целом полезно, сейчас планирую ит структуру компании, как раз так у буду делать… Самому план не придется писать, хехе
                0
                Все расписано довольно грамотно, соглашусь. Хороший пост.
                Хотя основной потребитель такой структуры софта — фирмы с количеством ПК от 200-300.
                Для небольших, контор многое избыточно.
                Разве что лично я предпочитаю строить гетерогенные среды — мне какие-то вещи проще и удобнее получить на видне, а какие-то на линухах/бсде (большинство именно на линухах).
                  +1
                  Согласен. Но масштаб при котором то или иное решение становится актуальным весьма индивидуален всё таки. Да и инфраструктура подобная, как правило, не строится за месяц. Я бы сказал, что это путь который постепенно должна пройти инфраструктура при росте фирмы от 20 до 200 человек.
                    +1
                    Кстати, совсем забыл.
                    Для конторы от 300 и более пользователей уже актуальна система заявок на ремонт/техобслуживание, в общем некий трак.
                    Я обычно использовал какой-нибудь фриваный багтрак, добавляя просто ссылку на главную страницу шарепоинта.
                    Есть какие-то готовые аналоги от MS?
                      +1
                      Мы все реализовали с помощью рабочих процессов на Sharepoint, но там уже начинаются некотороые заморочки с их построением, правами и т.д., поэтому я не стал включать это в статью. Но замечание абсолютно верное. При таких масштабах людям уже очень хочется знать, когда наконец будет перезалит его любимый компьютер и кого персонально пнуть :)

                      Пожалуй допишу свою статью немного. :)
                        0
                        скоро будет
                        System Center Service Manager 2010
                        0
                        Еще добавлю 17 пунктом, для организаций от 500 и более рабочих мест вполне уже стоит подумать о внедрении SMS (или как он там точно называется?).
                        Там всевозможное централизованное управление, в т.ч. всусом, автоматическая установка винды на новый комп, и т.п. вкусности. Плюс мониторинг на MOM, позволяющий по исходу месяца сказать как работал сотрудник, сколько времени он провел в интернете или за пасьянсом, а сколько занимался непосредственно работой.
                          +1
                          Я имел ввиду вот это: ru.wikipedia.org/wiki/Microsoft_SMS
                            0
                            Сейчас всё что касается управления инфраструктурой переехоло в System Center
                              0
                              Судя по вики, это один и тот же продукт, просто раньше назывался System Management Server, а теперь System Center Configuration Manager или System Center Essential (расширенная версия).
                              Я эго немного эксплуатировал. С одной стороны понравился централизацией многих вещей, с другой, конечно немного монстроват, и хочет быстрого сервера.
                                +1
                                Немного неверно. SMS стал System Center Configuration Manager. А SCE — это слепленная вместе функциональность трех продуктов SCCM + SC Operation Manager + WSUS. SCE позиционируется ка кпродукт для мелкого и среднего бизнеса поэтому в нем ряд ограничений: только 1 сервер SCE который выполняет все роли, максимум обслуживание 500 раб. станций и 30 серверов. Поэтому он и Essential
                                  0
                                  Когда его только презентовали он больше напоминал гибрид МОМ05 и wsus, после этого я на этот обрубок не смотре, возможно за пару лет что-то изменилось.
                                    0
                                    Ну я бы не называл его обрубком, для небольших контор решение очень интересное. Все в одном и легко разворачивается. Я не использовал его на все 100, но то чем пользовался нравилось.
                          –1
                          такая инфраструктура может свободно подойти конторе 50 и конторе 10000 пользователей, а может и не подойти и конторе 100 пользователей все зависит как на эту статью посмотреть. здесь нет ни какой конкретики, а описаны базовые сервисы которые присутствуют в любой инфраструктуре. Вообще на мой взгляд статья ни о чем. Проектировать и внедрять подобные системы нельзя давать людям которые не в курсе того о чем здесь пишется, я не раз видел что из этого получается…
                          +1
                          Да, раз уж вы внедряете шарепоинт для внутреннего документооборота, есть смысл сразу отказаться от «Расшариваем на сервере файловые ресурсы».
                          И вирусораспространения через шары поменьше будет.
                            +4
                            Угу, но до шарепоинта как правило фирма долго растёт, хотелось осветить и наболевшую тему файловой свалки.
                              0
                              а если дизайн-макеты шарить надо? гигов по 20?
                              в шарупоинту такое запихнуть можно, но лучше не надо :)
                              проходил лично
                                0
                                Понимаю.
                                Все равно вести серьезную работу, в которой участвует множество людей на разных стадиях в файловой шаре — не слишком хорошее решение.
                                У нас, конечно, не было макетов по 20 гигов, но были 3д модели деталей для производства от 0.5 до 3-4 гигов. Для «документо»оборота таких вещей была использована все равно некая цмс(или как ее правильно назвать) с аналогичным шарепоинту принципом работы, с которой работали все отделы. Пока деталь на доработке у тебя — скачай и пили ее локально, потом заливай обратно, дальше она идет на утверждение, сверки, доработки, и т.п. вплоть до того, что на станок она экспортируется прямо из программы. Контроль версий, визирование начальства и различных промежуточных комиссий — это все сложно и неудобно делать только в рамках фаилшары.
                                  0
                                  согласен со всем, за файловые шары не пропагандирую :)
                                  я к тому, что шарик он для офисных документов (желательно порожденных MS Office) — тогда он идеален
                              +1
                              В закладочки, весьма интересно в некоторых аспектах.
                                0
                                Вы забыли упомянуть телефоны с Windows Mobile, в данном контексте мне кажется это удобное мобильное решение.
                                  +1
                                  Это в кучу к Exchange Web Access. К тоже же к нему и Symbian/Android/iPhone цепляется, с некоторыми оговорками.
                                  –6
                                  Мне, как человеку не сильно связанному с администрированием, было очень интересно почитать и узнать ЧТО могут продукты Майкрософт (и очередной раз убедиться, что они не зря кушают свой хлеб:). Хоть я сам и приверженец OS.
                                    +1
                                    microsoft.com вам в помощь. Дублировать — значит не целесообразно тратить время. Если вам интересен какой то определенный продукт или возможность, тогда можно заморочиться и описать при чем если по продукту то тоже только базу или самые интересные возможности.
                                    +4
                                    Иллюстрация очень качественно подобрана :)
                                      0
                                      Спасибо, долго копался в поисках каких нибудь красивых схематических изображений инфраструктуры, а потом осенило :)
                                      +1
                                      Я не люблю Microsoft и мы почти не используем Windows на работе (небольшой провайдер) но статья мне очень понравилась.

                                      Она показывает что с грамотным подходом IT администраторов — все системы хороши.
                                        0
                                        OK. Извините. Она показывает что кроме системы очень важно само проектирование и организация структуры.
                                          +1
                                          А за что Вы извиняетесь? Есть грамотный персонал — будет хорошая, устойчивая инфраструктура и неважно на чем она построена.
                                            0
                                            Точно. Именно это и имел ввиду.
                                        +1
                                        Точно такую-же структуру и ведем. ПК всего 50. в других точках по 20 и 15. Работает более 4-х лет, год назад обновляли железо и лицензировались хехе.
                                          0
                                          4. При необходимости ограничиваем доступ ко внешним накопителям, например с помощью Device Lock.
                                          >>Вроде это через GP можно разрулить.

                                          9.2 Если у нас есть филиалы — тоннель между ISA серверами, если у нас есть удаленные пользователи — VPN доступ в нашу сеть.
                                          >>Поднимаем IPv6 и Direct Access. Пользователям удобно, да и Win7 + 2008R2 уже становятся общепринятыми.
                                          Но ВПН тоже обязательно нужен для обратной совместимости.

                                          Статья хорошая, так и надо описывать технологии. Чтобы люди понимали «что эта штука может».
                                            0
                                            4. Честно говоря не разбирался и не знал. Если практически реализовывали и всё гладко — допишу топик.
                                            9.2 Очень интересно. Спасибо. До сих пор не знал, кто вообще пользуется IPv6, почитаю!
                                              0
                                              зарезать можно было даже в 2к3 — xp( в 2к8 — 7 и подавно) за счет использования некоторых ключей реестра, я когда-то даже адамку для этого выкладывал.
                                            0
                                            «DHCP. Фиксированных адресов быть не должно.» — это для десктопов и сетевых принтеров или вообще для всего, кроме сервера AD/DNS/DHCP?
                                              +1
                                              Желательно чтобы вообще для всего. Привязки в DHCP позволяют всегда иметь один и тот же адрес на любом устройстве, заходя в DHCP вы видите полную картину сразу, не вспоминая какие у каких серверов адреса.
                                                0
                                                по поводу пункта 1.2 DHCP и конкретно резервации адресов. есть проблема (win 2003) когда зарезервированный адрес кто-то пытается присвоить ручками то резервация в DHCP портится. Приходится лезть руками и править. Может подскажете как решать эту проблему и существует ли она на win 2008? Я эту проблему решил запустив ipguard в сетке и написав экспорт данных из dhcp в конфиг ipguarda. теперь никто ручками адрес себе присвоить не может. точнее присвоив несанкционированный адрес он не может работать в сетке, а тот, кто имеет этот адрес по праву, продолжает оставаться в сетке и резервация в dhcp не перетирается.
                                                Еще читал что могут возникнуть проблемы при dhcp relay. реализация в нект. устройствах не корректно работает с виндовыми dhcp. сам пока релай не использую.
                                                за топик спасибо.
                                              0
                                              Хотелось бы услышать про организацию сетевой инфраструктуры на предприятии. А то одноранговая сеть себя скоро изживет — ипушники закончатся =)
                                                0
                                                Вы путаете понятия. Но в любом случае, если у Вас намечается проблема с доступными для локальной сети IP адресами прочитайте про CIDR. Проблема нехватки IP адресов у нас вставала, хочу сказать что наши Windows системы, начиная с Win2000 (более ранние не проверяли) и серверы, как выяснилось, с CIDR очень даже дружат. Спокойно сделали нулём ещё один октет в маске, всё оборудование отработало нормально.
                                                  0
                                                  на роутерах cisco (думаю не только у них) есть такая волшебная штука — ip helper. Выступает чем-то вроде proxy для DHCP, таки образом можно применять один (условный) DHCP-сервер на множество подсетей.
                                                    +1
                                                    Это dhcp relay. На многих свичах тоже есть. Действительно полезная штука.
                                                    0
                                                    как вы умудрились забить 65к адресов??? (я имею ввиду базовую маску класса С для внутривенных нужд)
                                                      0
                                                      Разбейте на подсети, это решит проблему. Пример: 172.16.8.0/24 — серверы, 172.16.9.0/28 — все высшее начальство, 172.16.10.0/24 — бухгалтерия и т.д. Если выделят достаточно средств — организуйте все на Цисках — для каждой подсети свой влан + свой акцесс-лист. Благодаря первому бухгалтера будут в своем сетевом окружении видеть только компьютеры бухгалтерии, начальство — только друг друга. Второе же защитит от кулхацкеров разобравшихся в адресации сети.
                                                      0
                                                      А что скажете по поводу Sharepoint Services — как оно работает в корпоративной среде?
                                                        0
                                                        Не разворачивали, но не вижу причин почему бы им не работать.
                                                          0
                                                          Работает замечательно, но при наличии прямых рук у программистов портала. Имхо почти всё можно сделать самим, не покупая SharePoint Server.
                                                          SharePoint Services бесплатные, так почему бы не использовать их? (тем более раз уж MS отняли у нас в аутлуке общие папки =)). В 100 раз лучше обычной файловой помойки.
                                                          0
                                                          «Каждому подразделению выделяем Organizational Unit в соответствии с иерархией организации. Распихиваем пользователей по OU.» — ерунда. Пользоваться консолью управления AD как проводником бессмысленно. Единственное назначение OU — разные групповые политики. Все равно пользователей ищете поиском, а не по юнитам.
                                                          Вот в группы включать — правильно. Тогда групповые политики нужно накатывать на верхний уровень. И указывать в security filtering требуемую группу. Тогда не нужно смотреть, в какой OU помещена УЗ, а достаточно включить в нужную группу для отката требуемой политики.
                                                            0
                                                            OU используют как группы привязаные к иеарихии организации. Сколько я встречал организаций всегда это было удобно.
                                                              0
                                                              А какие плюсы от этого?
                                                                0
                                                                много разных, почитайте офф гайды по планированию АД.
                                                                  +1
                                                                  :) Человек вам хорошие мысли говорит. Очень часто, если по иерархии отделов политики безопасности (не права доступа, а именно настройки безопасности) не различаются, то и городить огород из ОУ смысла нет. Можно конечно, но дополнительной функциональности он не добавит потому что как правильно было замечено ОУ полезны только дляпривязки объектов ГП.
                                                                  А вот группы — совсем другое дело. На группы завязаны все механизмы раграничения доступа.
                                                                  А «почитайте офф гайды по планированию АД» = мне не чего вам возразить, но я не хочу так легко сдаваться :)
                                                                    0
                                                                    вот вам простейший пример из повседневного администрирования, вам надо создать кастом адрес лист в чанге для бухгалтерии, он привязывается к оушке… Это так из банальных вещей администрирования, просто глобальные вещи писать долго, а я ленивый ;)
                                                                      0
                                                                      Хммм… Кастом листы не создавал, спорить не буду. Над опосмотреть, стало интересно. Но из всех остальных задач в ЭКсче (создание кастомной политик адресов, рассылки) что-то еще с чем приходилось сталкивать ни разу не получилось завязать этот функционал на Оу-шки. Было очень неудобно и раздражало. Где-то приходилось привязывать к группа, где-то руководствоваться атрибутами учеток ользователей типа Компания. Поэтому сильно удивлен, что ОУ где-то оказались полезны для администрирования Эксченджа.
                                                                        0
                                                                        Вы все еще админите 2003? пора уже избавляться от этого мастадонта, 2010 уже во всю пашет.
                                                                          0
                                                                          Смесь из 2007 и доживающего последние дни 2003.
                                                                    +1
                                                                    Основное назначение OU — разные групповые политики и делегирование прав.
                                                                    В случаях когда права делегировать не нужно, политики правильнее накатывать группами, а не юнитами.
                                                                    Если Вы не планируете на каждое подразделение выдавать права разным людям, то и затевать раскладывание УЗ по «подпапкам» нет.
                                                                      0
                                                                      мне лень вас переубеждать, а тем более учить.
                                                                        0
                                                                        И правильно, меня учить — только портить :)
                                                                    0
                                                                    Плюсы в удобном представлении иерархии обьектов организации и в возможности делегировать права администрирования.

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

                                                                    Или ситуация описанная автором. Секретарши должны следить за номерами тел. сотрудников и при необходимости вносить изменения. Дергать админа это не вариант. Можно просто наделить секретарш правом изменять этот атрибут в пределах ведомств которыми они заведуют.
                                                                      0
                                                                      Да, но «Каждому подразделению выделяем Organizational Unit в соответствии с иерархией организации» — это слишком много OU. Во всяком случае в больших компаниях.
                                                                      Я не говорю, что они вообще не нужны, просто надо меру знать :)
                                                                    0
                                                                    Если я правильно помню, при ограничении доступа к папке/шаре нельзя указать организационную единицу. То есть, использовать лдаповский OU в качестве «группы» невозможно.
                                                                    Лично у меня пользователи побиты на организационные единицы только для того, чтобы в телефонном справочнике симпатично всё отображалось.
                                                                  –3
                                                                  умилительная статья как всё хорошо на МС…
                                                                  я работаю в крупной конторе с распред АД.

                                                                  не всё так гладко, как излагает автор :) не всё так быстро и красиво.

                                                                  автор, как тут принято говорить — кэп Очевидность.
                                                                    +6
                                                                    Уважаемое сообщество, не знаю, как тут принято задавать вопросы, поэтому пишу в комментарии. Уже давно я начинал писать нечто большее, чем просто статья про сетевые технологии. Хотелось просто и доступно описать что зачем, и так далее. По роду своей деятельности много чего приходилось объяснять сотрудникам, убедился что лучше всего усваиваются не готовые знания, а то как ситуация пришла к текущему положению вещей, почему всё так сложно и почему проще никак нельзя :) Довольно быстро я понял, что сил моих не хватит и дело это забросил. Но если мне удастся собрать единомышленников, готовых совместно потрудиться — буду рад возобновить усилия. Кстати пока слово Microsoft там не упоминается ни разочку — дошел только до модели OSI. Пишите мне на oskolade@gmail.com, как минимум всем отвечу. Пожалуйста не минусуйте комментарий, хотя он никакого отношения к топику не имеет :)
                                                                      0
                                                                      Про OSI и первые три её уровня лучше, чем в книге «основы организации сетей cisco», по-моему, не написать. А вот про варианты построения инфраструктуры, показанные на конкретных примерах, почитать было бы очень интересно.
                                                                      0
                                                                      Хороший пост, показывает что Microsoft предлагает solution по полной ИТ-инфраструктуре. Единственно хорошо бы поподробней о цене не в варианте Enterprise Agreement, а для скажем офиса из 100 рабочих мест. Думаю 90 процентов не! ИТ-компаний такого масштаба откажутся увидев конечную цену всего этого великолепия.
                                                                        0
                                                                        Если новые версии для всех купленных систем в течение 3 лет не нужны (без Software Assurance) — получится дешевле, чем Enterprise Agreement. Если нужны — примерно та же цифра.
                                                                          0
                                                                          ~50000$, два года назад считал некую среднюю компанию со средними нуждами, не думаю что кардинально поменялось
                                                                          +1
                                                                          К пункту 0.1. Отдельно хочу отметить: важно не просто делать бэкапы, а продумать схему, по которой эти бэкапы будут восстанавливаться. Мало иметь дамп базы данных, нужно ещё документировать схему СУБД, чтобы знать, куда дамп разворачивать. Ну и так далее.
                                                                          В любом случае, статья очень понравилась, спасибо!
                                                                            +1
                                                                            ага, я бы в этот список советов внес бы backupexec от Symantec. Очень удобное ПО и стоит не очень дорого.
                                                                              0
                                                                              У win2008 и выше тоже неплохой встроенный архиватор.
                                                                                0
                                                                                А еще есть MS Data Protection Manager. Если необходимо бэкапить только мастдайные серверные продукты — достаточно интересное решение. Хотя несомненно у Symanteca функционал будет покруче. Пользовался и тем и другим.
                                                                                  0
                                                                                  У symantec есть полноценная работа с vmware и это очень важно.
                                                                            –3
                                                                            Я Вам обязательно плюсик поставлю, когда (и если) у меня появится такая возможность
                                                                              –1
                                                                              не судьба) кибергопники минусуют)
                                                                            • UFO just landed and posted this here
                                                                              • UFO just landed and posted this here
                                                                              • UFO just landed and posted this here
                                                                                • UFO just landed and posted this here
                                                                                    0
                                                                                    Во многом да, да не совсем. Отдельная железка может и не понадобиться — уже вовсю есть провайдеры, подающие телефонию сразу через Ethernet с помощью SIP. Поэтому не стал расписывать подробности — нужно разбираться с конкретным случаем.
                                                                                    Выкинуть АТС — хорошо бы, но телефонные аппараты для OCS пока стоят заоблачных денег. Всех с гарнитурами посадить не получается — поэтому это тоже отдельный вопрос. Если АТС на данный момент нет, то очень подумал бы, нужно ли её покупать, но так как она у всех есть и работает… К тому же я сторониик эволюции, а не революций. Сосуществование OCS и АТС позволяет плавно перетаскивать пользователей, не лишая их старых привычных сервисов.
                                                                                    Большое спасибо за очень компетентные комментарии
                                                                                    +1
                                                                                    Хороший план, годится при необходимости проектировать инфраструктуру компании «с нуля». В случае необходимости расчищать «авгиевы конюшни» от предидущих «строителей» добавляется масса промежуточных пунктов по переводу с старых систем на новые и по обучению/переучиванию сотрудников.
                                                                                      –3
                                                                                      1) Хуливарщеги, идите нахуй;

                                                                                      2) Аффтару респект — теперь есть лапидарный текст от практика, в который можно тыкать носом злоебучих недоадминов-еникейщиков, чтобы они наконец перестали играть в свой квейк или что там у них, и начали наконец хоть ЧТО-ТО реализовывать из этого простого и понятного списка;

                                                                                      3) Аффтару МЕГАРЕСПЕКТ за краткость и нормальное описание процесса и системы — именно того, чего не хватает ебанутым на всю голову линуксятникам, и бездарным упырям-виндоЕниКейщикам; очередное доказательство того, что система — она или есть, или ее нет; и неважно где ты ее реализуешь, в сетке из трех компов или в сети филиалов из тыщи станций.

                                                                                      4) Да, кстати, Хабр охуенный сайт, просто пиво и пятница дают просраться ганглиям пролетария умственного труда, гыгы :D

                                                                                      5) Сисадмины, спасибо что вы есть — ну бля, в натуре, реально! :)
                                                                                        +2
                                                                                        Я большой сторонник решений от MS, и знаю множество из них на профессиональном уровне. Позволю внести себе несколько комментариев.

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

                                                                                        2. ISA мне никогда не нравилась. Равно как и новоявленный форефронт. Да, это очень мощный продукт, но поверьте, не каждому он нужен. Обычно нужно решать более простые задачи, нежели NLB кластер шлюзов и тонкая настройка политик доступа. Я его тестировал 2 месяца, для смолл-сайз организации он не подходит. Попробуйте Kerio — намного понятнее и сильно дешевле. И вообще, не нужно зацикливаться на софте микрософта, как пытался я. Не повторяйте моих ошибок — выбирайте то, что подходит именно Вам.

                                                                                        3. Про юнифид комьюникейшнс почитайте конечно, лишним не будет. Но поверьте, пересадить на это пользователей — раз в 10-15 сложнее, чем приучить к шарепойнту.

                                                                                        4. Про систем центр — даже говорить не хочу. Если у вас меньше 200 компов — даже не старайтесь. Только если у фирмы очень много денег, а у вас очень много свободного времени. Это очень тормозная и тяжелая штука, которую к тому же не просто освоить. Сначала отточите базовые вещи, чтобы все работало как часы. А потом уже — упрощалки жизни.

                                                                                        Ну и самое главное — не пренебрегайте чтением мануалов, техподдржкой (у микрософта она ОЧЕНЬ качественная). Поверьте, все их продукты отлично документированы, и на любой Ваш вопрос найдется ответ. Досконально разберитесь во всем, не торопитель поставить все сразу.
                                                                                        • UFO just landed and posted this here
                                                                                        • UFO just landed and posted this here
                                                                                            0
                                                                                            Чем именно вам не нравится Kerio?
                                                                                            +1
                                                                                            Всегда было интересно, чем пользуются для удаленного администрирования? В пингвинах и линуксах вот ssh, а тут? Power shell плюс какой-то аналог ssh?
                                                                                            0
                                                                                            Солько человек должно быть в службе ИТ для создания и поддержания всего этого хозяйства?
                                                                                              0
                                                                                              Сразу скажу, что реальная инфраструктура развесистей, чем описано в статье. Есть большое число сервисов написанных нами самими. Есть три офиса в других городах 5-20 человек, всё это администрируется из центрального офиса.
                                                                                              Поддержка и развитие всего, что описано выше + дополнительные сервисы осуществляется 6 человеками:
                                                                                              4 техника, и 2 инженера. Загрузка сотрудников поддержкой — менее 50 процентов в отсутствие авралов, отпусков и так далее.
                                                                                              0
                                                                                              отлично, спасибо
                                                                                              давно искал подобный материал для развития :-)

                                                                                              Only users with full accounts can post comments. Log in, please.