Комментарии 100
Вот это полезный пост! И несмотря на то, что я сторонник OpenSource, всё же как бывший win-админ ставлю вам большой виртуальный плюс (чем могу, увы), очень многим начинающим админам этот топик поможет сориентироваться в продуктах MS и построить правильную инфраструктуру.
НЛО прилетело и опубликовало эту надпись здесь
Здесь не нужны ни одни ни другие. Пост не для них.
Автору спасибо
Автору спасибо
Как один из помешанных «фанатиков-линуксоидов», смею заявить от лица части себе подобных, что пост хоть и во многом рассказывает о весьма повседневных и очевидных вещах, но вскопе, очень четко и грамотно. И уж точно не несет никакой привязки к M$ и сиеподобному. Можно было написать вместо конкретных продуктов просто названия использованых технологий, но я думаю автору намного комфортнее было оперировать именно продуктами. Найти аналоги в *nix не трудно. Не нужно пытаться искать холивар там где им и не пахнет, исключительно потому что вы «первонах» и увидели в посте слова Microsoft.
спасибо, было интересно!
в целом полезно, сейчас планирую ит структуру компании, как раз так у буду делать… Самому план не придется писать, хехе
Все расписано довольно грамотно, соглашусь. Хороший пост.
Хотя основной потребитель такой структуры софта — фирмы с количеством ПК от 200-300.
Для небольших, контор многое избыточно.
Разве что лично я предпочитаю строить гетерогенные среды — мне какие-то вещи проще и удобнее получить на видне, а какие-то на линухах/бсде (большинство именно на линухах).
Хотя основной потребитель такой структуры софта — фирмы с количеством ПК от 200-300.
Для небольших, контор многое избыточно.
Разве что лично я предпочитаю строить гетерогенные среды — мне какие-то вещи проще и удобнее получить на видне, а какие-то на линухах/бсде (большинство именно на линухах).
Согласен. Но масштаб при котором то или иное решение становится актуальным весьма индивидуален всё таки. Да и инфраструктура подобная, как правило, не строится за месяц. Я бы сказал, что это путь который постепенно должна пройти инфраструктура при росте фирмы от 20 до 200 человек.
Кстати, совсем забыл.
Для конторы от 300 и более пользователей уже актуальна система заявок на ремонт/техобслуживание, в общем некий трак.
Я обычно использовал какой-нибудь фриваный багтрак, добавляя просто ссылку на главную страницу шарепоинта.
Есть какие-то готовые аналоги от MS?
Для конторы от 300 и более пользователей уже актуальна система заявок на ремонт/техобслуживание, в общем некий трак.
Я обычно использовал какой-нибудь фриваный багтрак, добавляя просто ссылку на главную страницу шарепоинта.
Есть какие-то готовые аналоги от MS?
Мы все реализовали с помощью рабочих процессов на Sharepoint, но там уже начинаются некотороые заморочки с их построением, правами и т.д., поэтому я не стал включать это в статью. Но замечание абсолютно верное. При таких масштабах людям уже очень хочется знать, когда наконец будет перезалит его любимый компьютер и кого персонально пнуть :)
Пожалуй допишу свою статью немного. :)
Пожалуй допишу свою статью немного. :)
Еще добавлю 17 пунктом, для организаций от 500 и более рабочих мест вполне уже стоит подумать о внедрении SMS (или как он там точно называется?).
Там всевозможное централизованное управление, в т.ч. всусом, автоматическая установка винды на новый комп, и т.п. вкусности. Плюс мониторинг на MOM, позволяющий по исходу месяца сказать как работал сотрудник, сколько времени он провел в интернете или за пасьянсом, а сколько занимался непосредственно работой.
Там всевозможное централизованное управление, в т.ч. всусом, автоматическая установка винды на новый комп, и т.п. вкусности. Плюс мониторинг на MOM, позволяющий по исходу месяца сказать как работал сотрудник, сколько времени он провел в интернете или за пасьянсом, а сколько занимался непосредственно работой.
Я имел ввиду вот это: ru.wikipedia.org/wiki/Microsoft_SMS
Сейчас всё что касается управления инфраструктурой переехоло в System Center
Судя по вики, это один и тот же продукт, просто раньше назывался System Management Server, а теперь System Center Configuration Manager или System Center Essential (расширенная версия).
Я эго немного эксплуатировал. С одной стороны понравился централизацией многих вещей, с другой, конечно немного монстроват, и хочет быстрого сервера.
Я эго немного эксплуатировал. С одной стороны понравился централизацией многих вещей, с другой, конечно немного монстроват, и хочет быстрого сервера.
Немного неверно. SMS стал System Center Configuration Manager. А SCE — это слепленная вместе функциональность трех продуктов SCCM + SC Operation Manager + WSUS. SCE позиционируется ка кпродукт для мелкого и среднего бизнеса поэтому в нем ряд ограничений: только 1 сервер SCE который выполняет все роли, максимум обслуживание 500 раб. станций и 30 серверов. Поэтому он и Essential
такая инфраструктура может свободно подойти конторе 50 и конторе 10000 пользователей, а может и не подойти и конторе 100 пользователей все зависит как на эту статью посмотреть. здесь нет ни какой конкретики, а описаны базовые сервисы которые присутствуют в любой инфраструктуре. Вообще на мой взгляд статья ни о чем. Проектировать и внедрять подобные системы нельзя давать людям которые не в курсе того о чем здесь пишется, я не раз видел что из этого получается…
Да, раз уж вы внедряете шарепоинт для внутреннего документооборота, есть смысл сразу отказаться от «Расшариваем на сервере файловые ресурсы».
И вирусораспространения через шары поменьше будет.
И вирусораспространения через шары поменьше будет.
Угу, но до шарепоинта как правило фирма долго растёт, хотелось осветить и наболевшую тему файловой свалки.
а если дизайн-макеты шарить надо? гигов по 20?
в шарупоинту такое запихнуть можно, но лучше не надо :)
проходил лично
в шарупоинту такое запихнуть можно, но лучше не надо :)
проходил лично
Понимаю.
Все равно вести серьезную работу, в которой участвует множество людей на разных стадиях в файловой шаре — не слишком хорошее решение.
У нас, конечно, не было макетов по 20 гигов, но были 3д модели деталей для производства от 0.5 до 3-4 гигов. Для «документо»оборота таких вещей была использована все равно некая цмс(или как ее правильно назвать) с аналогичным шарепоинту принципом работы, с которой работали все отделы. Пока деталь на доработке у тебя — скачай и пили ее локально, потом заливай обратно, дальше она идет на утверждение, сверки, доработки, и т.п. вплоть до того, что на станок она экспортируется прямо из программы. Контроль версий, визирование начальства и различных промежуточных комиссий — это все сложно и неудобно делать только в рамках фаилшары.
Все равно вести серьезную работу, в которой участвует множество людей на разных стадиях в файловой шаре — не слишком хорошее решение.
У нас, конечно, не было макетов по 20 гигов, но были 3д модели деталей для производства от 0.5 до 3-4 гигов. Для «документо»оборота таких вещей была использована все равно некая цмс(или как ее правильно назвать) с аналогичным шарепоинту принципом работы, с которой работали все отделы. Пока деталь на доработке у тебя — скачай и пили ее локально, потом заливай обратно, дальше она идет на утверждение, сверки, доработки, и т.п. вплоть до того, что на станок она экспортируется прямо из программы. Контроль версий, визирование начальства и различных промежуточных комиссий — это все сложно и неудобно делать только в рамках фаилшары.
В закладочки, весьма интересно в некоторых аспектах.
Вы забыли упомянуть телефоны с Windows Mobile, в данном контексте мне кажется это удобное мобильное решение.
Мне, как человеку не сильно связанному с администрированием, было очень интересно почитать и узнать ЧТО могут продукты Майкрософт (и очередной раз убедиться, что они не зря кушают свой хлеб:). Хоть я сам и приверженец OS.
Иллюстрация очень качественно подобрана :)
Я не люблю Microsoft и мы почти не используем Windows на работе (небольшой провайдер) но статья мне очень понравилась.
Она показывает что с грамотным подходом IT администраторов — все системы хороши.
Она показывает что с грамотным подходом IT администраторов — все системы хороши.
Точно такую-же структуру и ведем. ПК всего 50. в других точках по 20 и 15. Работает более 4-х лет, год назад обновляли железо и лицензировались хехе.
4. При необходимости ограничиваем доступ ко внешним накопителям, например с помощью Device Lock.
>>Вроде это через GP можно разрулить.
9.2 Если у нас есть филиалы — тоннель между ISA серверами, если у нас есть удаленные пользователи — VPN доступ в нашу сеть.
>>Поднимаем IPv6 и Direct Access. Пользователям удобно, да и Win7 + 2008R2 уже становятся общепринятыми.
Но ВПН тоже обязательно нужен для обратной совместимости.
Статья хорошая, так и надо описывать технологии. Чтобы люди понимали «что эта штука может».
>>Вроде это через GP можно разрулить.
9.2 Если у нас есть филиалы — тоннель между ISA серверами, если у нас есть удаленные пользователи — VPN доступ в нашу сеть.
>>Поднимаем IPv6 и Direct Access. Пользователям удобно, да и Win7 + 2008R2 уже становятся общепринятыми.
Но ВПН тоже обязательно нужен для обратной совместимости.
Статья хорошая, так и надо описывать технологии. Чтобы люди понимали «что эта штука может».
«DHCP. Фиксированных адресов быть не должно.» — это для десктопов и сетевых принтеров или вообще для всего, кроме сервера AD/DNS/DHCP?
Желательно чтобы вообще для всего. Привязки в DHCP позволяют всегда иметь один и тот же адрес на любом устройстве, заходя в DHCP вы видите полную картину сразу, не вспоминая какие у каких серверов адреса.
по поводу пункта 1.2 DHCP и конкретно резервации адресов. есть проблема (win 2003) когда зарезервированный адрес кто-то пытается присвоить ручками то резервация в DHCP портится. Приходится лезть руками и править. Может подскажете как решать эту проблему и существует ли она на win 2008? Я эту проблему решил запустив ipguard в сетке и написав экспорт данных из dhcp в конфиг ipguarda. теперь никто ручками адрес себе присвоить не может. точнее присвоив несанкционированный адрес он не может работать в сетке, а тот, кто имеет этот адрес по праву, продолжает оставаться в сетке и резервация в dhcp не перетирается.
Еще читал что могут возникнуть проблемы при dhcp relay. реализация в нект. устройствах не корректно работает с виндовыми dhcp. сам пока релай не использую.
за топик спасибо.
Еще читал что могут возникнуть проблемы при dhcp relay. реализация в нект. устройствах не корректно работает с виндовыми dhcp. сам пока релай не использую.
за топик спасибо.
Хотелось бы услышать про организацию сетевой инфраструктуры на предприятии. А то одноранговая сеть себя скоро изживет — ипушники закончатся =)
Вы путаете понятия. Но в любом случае, если у Вас намечается проблема с доступными для локальной сети IP адресами прочитайте про CIDR. Проблема нехватки IP адресов у нас вставала, хочу сказать что наши Windows системы, начиная с Win2000 (более ранние не проверяли) и серверы, как выяснилось, с CIDR очень даже дружат. Спокойно сделали нулём ещё один октет в маске, всё оборудование отработало нормально.
на роутерах cisco (думаю не только у них) есть такая волшебная штука — ip helper. Выступает чем-то вроде proxy для DHCP, таки образом можно применять один (условный) DHCP-сервер на множество подсетей.
как вы умудрились забить 65к адресов??? (я имею ввиду базовую маску класса С для внутривенных нужд)
Разбейте на подсети, это решит проблему. Пример: 172.16.8.0/24 — серверы, 172.16.9.0/28 — все высшее начальство, 172.16.10.0/24 — бухгалтерия и т.д. Если выделят достаточно средств — организуйте все на Цисках — для каждой подсети свой влан + свой акцесс-лист. Благодаря первому бухгалтера будут в своем сетевом окружении видеть только компьютеры бухгалтерии, начальство — только друг друга. Второе же защитит от кулхацкеров разобравшихся в адресации сети.
А что скажете по поводу Sharepoint Services — как оно работает в корпоративной среде?
Не разворачивали, но не вижу причин почему бы им не работать.
Работает замечательно, но при наличии прямых рук у программистов портала. Имхо почти всё можно сделать самим, не покупая SharePoint Server.
SharePoint Services бесплатные, так почему бы не использовать их? (тем более раз уж MS отняли у нас в аутлуке общие папки =)). В 100 раз лучше обычной файловой помойки.
SharePoint Services бесплатные, так почему бы не использовать их? (тем более раз уж MS отняли у нас в аутлуке общие папки =)). В 100 раз лучше обычной файловой помойки.
«Каждому подразделению выделяем Organizational Unit в соответствии с иерархией организации. Распихиваем пользователей по OU.» — ерунда. Пользоваться консолью управления AD как проводником бессмысленно. Единственное назначение OU — разные групповые политики. Все равно пользователей ищете поиском, а не по юнитам.
Вот в группы включать — правильно. Тогда групповые политики нужно накатывать на верхний уровень. И указывать в security filtering требуемую группу. Тогда не нужно смотреть, в какой OU помещена УЗ, а достаточно включить в нужную группу для отката требуемой политики.
Вот в группы включать — правильно. Тогда групповые политики нужно накатывать на верхний уровень. И указывать в security filtering требуемую группу. Тогда не нужно смотреть, в какой OU помещена УЗ, а достаточно включить в нужную группу для отката требуемой политики.
OU используют как группы привязаные к иеарихии организации. Сколько я встречал организаций всегда это было удобно.
А какие плюсы от этого?
много разных, почитайте офф гайды по планированию АД.
:) Человек вам хорошие мысли говорит. Очень часто, если по иерархии отделов политики безопасности (не права доступа, а именно настройки безопасности) не различаются, то и городить огород из ОУ смысла нет. Можно конечно, но дополнительной функциональности он не добавит потому что как правильно было замечено ОУ полезны только дляпривязки объектов ГП.
А вот группы — совсем другое дело. На группы завязаны все механизмы раграничения доступа.
А «почитайте офф гайды по планированию АД» = мне не чего вам возразить, но я не хочу так легко сдаваться :)
А вот группы — совсем другое дело. На группы завязаны все механизмы раграничения доступа.
А «почитайте офф гайды по планированию АД» = мне не чего вам возразить, но я не хочу так легко сдаваться :)
вот вам простейший пример из повседневного администрирования, вам надо создать кастом адрес лист в чанге для бухгалтерии, он привязывается к оушке… Это так из банальных вещей администрирования, просто глобальные вещи писать долго, а я ленивый ;)
Хммм… Кастом листы не создавал, спорить не буду. Над опосмотреть, стало интересно. Но из всех остальных задач в ЭКсче (создание кастомной политик адресов, рассылки) что-то еще с чем приходилось сталкивать ни разу не получилось завязать этот функционал на Оу-шки. Было очень неудобно и раздражало. Где-то приходилось привязывать к группа, где-то руководствоваться атрибутами учеток ользователей типа Компания. Поэтому сильно удивлен, что ОУ где-то оказались полезны для администрирования Эксченджа.
Основное назначение OU — разные групповые политики и делегирование прав.
В случаях когда права делегировать не нужно, политики правильнее накатывать группами, а не юнитами.
Если Вы не планируете на каждое подразделение выдавать права разным людям, то и затевать раскладывание УЗ по «подпапкам» нет.
В случаях когда права делегировать не нужно, политики правильнее накатывать группами, а не юнитами.
Если Вы не планируете на каждое подразделение выдавать права разным людям, то и затевать раскладывание УЗ по «подпапкам» нет.
Плюсы в удобном представлении иерархии обьектов организации и в возможности делегировать права администрирования.
Например предприятие может быть территориально разбросано, скажем отдел сбыта может частично находиться в основном здании, частично — в десятке километров, чтобы иметь возможность этот самый сбыт контролировать. В таком случае целесообразно дать кому-то одному больше прав, переложить на него часть обязанностей, дать возможность создавать пользователей, модифицировать и т.д. Можно конечно поднять поддомен, но это все равно что стрелять из пушки по воробьям. А делегировав права на отдельный OU решаем проблему легко и изящно.
Или ситуация описанная автором. Секретарши должны следить за номерами тел. сотрудников и при необходимости вносить изменения. Дергать админа это не вариант. Можно просто наделить секретарш правом изменять этот атрибут в пределах ведомств которыми они заведуют.
Например предприятие может быть территориально разбросано, скажем отдел сбыта может частично находиться в основном здании, частично — в десятке километров, чтобы иметь возможность этот самый сбыт контролировать. В таком случае целесообразно дать кому-то одному больше прав, переложить на него часть обязанностей, дать возможность создавать пользователей, модифицировать и т.д. Можно конечно поднять поддомен, но это все равно что стрелять из пушки по воробьям. А делегировав права на отдельный OU решаем проблему легко и изящно.
Или ситуация описанная автором. Секретарши должны следить за номерами тел. сотрудников и при необходимости вносить изменения. Дергать админа это не вариант. Можно просто наделить секретарш правом изменять этот атрибут в пределах ведомств которыми они заведуют.
Если я правильно помню, при ограничении доступа к папке/шаре нельзя указать организационную единицу. То есть, использовать лдаповский OU в качестве «группы» невозможно.
Лично у меня пользователи побиты на организационные единицы только для того, чтобы в телефонном справочнике симпатично всё отображалось.
Лично у меня пользователи побиты на организационные единицы только для того, чтобы в телефонном справочнике симпатично всё отображалось.
умилительная статья как всё хорошо на МС…
я работаю в крупной конторе с распред АД.
не всё так гладко, как излагает автор :) не всё так быстро и красиво.
автор, как тут принято говорить — кэп Очевидность.
я работаю в крупной конторе с распред АД.
не всё так гладко, как излагает автор :) не всё так быстро и красиво.
автор, как тут принято говорить — кэп Очевидность.
Уважаемое сообщество, не знаю, как тут принято задавать вопросы, поэтому пишу в комментарии. Уже давно я начинал писать нечто большее, чем просто статья про сетевые технологии. Хотелось просто и доступно описать что зачем, и так далее. По роду своей деятельности много чего приходилось объяснять сотрудникам, убедился что лучше всего усваиваются не готовые знания, а то как ситуация пришла к текущему положению вещей, почему всё так сложно и почему проще никак нельзя :) Довольно быстро я понял, что сил моих не хватит и дело это забросил. Но если мне удастся собрать единомышленников, готовых совместно потрудиться — буду рад возобновить усилия. Кстати пока слово Microsoft там не упоминается ни разочку — дошел только до модели OSI. Пишите мне на oskolade@gmail.com, как минимум всем отвечу. Пожалуйста не минусуйте комментарий, хотя он никакого отношения к топику не имеет :)
Хороший пост, показывает что Microsoft предлагает solution по полной ИТ-инфраструктуре. Единственно хорошо бы поподробней о цене не в варианте Enterprise Agreement, а для скажем офиса из 100 рабочих мест. Думаю 90 процентов не! ИТ-компаний такого масштаба откажутся увидев конечную цену всего этого великолепия.
К пункту 0.1. Отдельно хочу отметить: важно не просто делать бэкапы, а продумать схему, по которой эти бэкапы будут восстанавливаться. Мало иметь дамп базы данных, нужно ещё документировать схему СУБД, чтобы знать, куда дамп разворачивать. Ну и так далее.
В любом случае, статья очень понравилась, спасибо!
В любом случае, статья очень понравилась, спасибо!
Я Вам обязательно плюсик поставлю, когда (и если) у меня появится такая возможность
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Во многом да, да не совсем. Отдельная железка может и не понадобиться — уже вовсю есть провайдеры, подающие телефонию сразу через Ethernet с помощью SIP. Поэтому не стал расписывать подробности — нужно разбираться с конкретным случаем.
Выкинуть АТС — хорошо бы, но телефонные аппараты для OCS пока стоят заоблачных денег. Всех с гарнитурами посадить не получается — поэтому это тоже отдельный вопрос. Если АТС на данный момент нет, то очень подумал бы, нужно ли её покупать, но так как она у всех есть и работает… К тому же я сторониик эволюции, а не революций. Сосуществование OCS и АТС позволяет плавно перетаскивать пользователей, не лишая их старых привычных сервисов.
Большое спасибо за очень компетентные комментарии
Выкинуть АТС — хорошо бы, но телефонные аппараты для OCS пока стоят заоблачных денег. Всех с гарнитурами посадить не получается — поэтому это тоже отдельный вопрос. Если АТС на данный момент нет, то очень подумал бы, нужно ли её покупать, но так как она у всех есть и работает… К тому же я сторониик эволюции, а не революций. Сосуществование OCS и АТС позволяет плавно перетаскивать пользователей, не лишая их старых привычных сервисов.
Большое спасибо за очень компетентные комментарии
Хороший план, годится при необходимости проектировать инфраструктуру компании «с нуля». В случае необходимости расчищать «авгиевы конюшни» от предидущих «строителей» добавляется масса промежуточных пунктов по переводу с старых систем на новые и по обучению/переучиванию сотрудников.
1) Хуливарщеги, идите нахуй;
2) Аффтару респект — теперь есть лапидарный текст от практика, в который можно тыкать носом злоебучих недоадминов-еникейщиков, чтобы они наконец перестали играть в свой квейк или что там у них, и начали наконец хоть ЧТО-ТО реализовывать из этого простого и понятного списка;
3) Аффтару МЕГАРЕСПЕКТ за краткость и нормальное описание процесса и системы — именно того, чего не хватает ебанутым на всю голову линуксятникам, и бездарным упырям-виндоЕниКейщикам; очередное доказательство того, что система — она или есть, или ее нет; и неважно где ты ее реализуешь, в сетке из трех компов или в сети филиалов из тыщи станций.
4) Да, кстати, Хабр охуенный сайт, просто пиво и пятница дают просраться ганглиям пролетария умственного труда, гыгы :D
5) Сисадмины, спасибо что вы есть — ну бля, в натуре, реально! :)
2) Аффтару респект — теперь есть лапидарный текст от практика, в который можно тыкать носом злоебучих недоадминов-еникейщиков, чтобы они наконец перестали играть в свой квейк или что там у них, и начали наконец хоть ЧТО-ТО реализовывать из этого простого и понятного списка;
3) Аффтару МЕГАРЕСПЕКТ за краткость и нормальное описание процесса и системы — именно того, чего не хватает ебанутым на всю голову линуксятникам, и бездарным упырям-виндоЕниКейщикам; очередное доказательство того, что система — она или есть, или ее нет; и неважно где ты ее реализуешь, в сетке из трех компов или в сети филиалов из тыщи станций.
4) Да, кстати, Хабр охуенный сайт, просто пиво и пятница дают просраться ганглиям пролетария умственного труда, гыгы :D
5) Сисадмины, спасибо что вы есть — ну бля, в натуре, реально! :)
Я большой сторонник решений от MS, и знаю множество из них на профессиональном уровне. Позволю внести себе несколько комментариев.
1. «Поднимаем SQL сервер» — это сильно сказано. В большинстве случаев на ровном месте он не нужен. Не следует поднимать что-то, для того, «чтоб было». Особенно если «оно» стоит несколько килобаксов. Для смолл-медиум организаций вполне хватит встроенной базы данных приложения или экспресс версии сиквела. В случае 1с есть свои нюансы, в любом случае тем, кто только начинает развивать инфраструктуру — не торопитесь с SQL.
2. ISA мне никогда не нравилась. Равно как и новоявленный форефронт. Да, это очень мощный продукт, но поверьте, не каждому он нужен. Обычно нужно решать более простые задачи, нежели NLB кластер шлюзов и тонкая настройка политик доступа. Я его тестировал 2 месяца, для смолл-сайз организации он не подходит. Попробуйте Kerio — намного понятнее и сильно дешевле. И вообще, не нужно зацикливаться на софте микрософта, как пытался я. Не повторяйте моих ошибок — выбирайте то, что подходит именно Вам.
3. Про юнифид комьюникейшнс почитайте конечно, лишним не будет. Но поверьте, пересадить на это пользователей — раз в 10-15 сложнее, чем приучить к шарепойнту.
4. Про систем центр — даже говорить не хочу. Если у вас меньше 200 компов — даже не старайтесь. Только если у фирмы очень много денег, а у вас очень много свободного времени. Это очень тормозная и тяжелая штука, которую к тому же не просто освоить. Сначала отточите базовые вещи, чтобы все работало как часы. А потом уже — упрощалки жизни.
Ну и самое главное — не пренебрегайте чтением мануалов, техподдржкой (у микрософта она ОЧЕНЬ качественная). Поверьте, все их продукты отлично документированы, и на любой Ваш вопрос найдется ответ. Досконально разберитесь во всем, не торопитель поставить все сразу.
1. «Поднимаем SQL сервер» — это сильно сказано. В большинстве случаев на ровном месте он не нужен. Не следует поднимать что-то, для того, «чтоб было». Особенно если «оно» стоит несколько килобаксов. Для смолл-медиум организаций вполне хватит встроенной базы данных приложения или экспресс версии сиквела. В случае 1с есть свои нюансы, в любом случае тем, кто только начинает развивать инфраструктуру — не торопитесь с SQL.
2. ISA мне никогда не нравилась. Равно как и новоявленный форефронт. Да, это очень мощный продукт, но поверьте, не каждому он нужен. Обычно нужно решать более простые задачи, нежели NLB кластер шлюзов и тонкая настройка политик доступа. Я его тестировал 2 месяца, для смолл-сайз организации он не подходит. Попробуйте Kerio — намного понятнее и сильно дешевле. И вообще, не нужно зацикливаться на софте микрософта, как пытался я. Не повторяйте моих ошибок — выбирайте то, что подходит именно Вам.
3. Про юнифид комьюникейшнс почитайте конечно, лишним не будет. Но поверьте, пересадить на это пользователей — раз в 10-15 сложнее, чем приучить к шарепойнту.
4. Про систем центр — даже говорить не хочу. Если у вас меньше 200 компов — даже не старайтесь. Только если у фирмы очень много денег, а у вас очень много свободного времени. Это очень тормозная и тяжелая штука, которую к тому же не просто освоить. Сначала отточите базовые вещи, чтобы все работало как часы. А потом уже — упрощалки жизни.
Ну и самое главное — не пренебрегайте чтением мануалов, техподдржкой (у микрософта она ОЧЕНЬ качественная). Поверьте, все их продукты отлично документированы, и на любой Ваш вопрос найдется ответ. Досконально разберитесь во всем, не торопитель поставить все сразу.
НЛО прилетело и опубликовало эту надпись здесь
Всегда было интересно, чем пользуются для удаленного администрирования? В пингвинах и линуксах вот ssh, а тут? Power shell плюс какой-то аналог ssh?
Солько человек должно быть в службе ИТ для создания и поддержания всего этого хозяйства?
Сразу скажу, что реальная инфраструктура развесистей, чем описано в статье. Есть большое число сервисов написанных нами самими. Есть три офиса в других городах 5-20 человек, всё это администрируется из центрального офиса.
Поддержка и развитие всего, что описано выше + дополнительные сервисы осуществляется 6 человеками:
4 техника, и 2 инженера. Загрузка сотрудников поддержкой — менее 50 процентов в отсутствие авралов, отпусков и так далее.
Поддержка и развитие всего, что описано выше + дополнительные сервисы осуществляется 6 человеками:
4 техника, и 2 инженера. Загрузка сотрудников поддержкой — менее 50 процентов в отсутствие авралов, отпусков и так далее.
отлично, спасибо
давно искал подобный материал для развития :-)
давно искал подобный материал для развития :-)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Строим инфраструктуру на базе продуктов MS