Comments 100
Вот это полезный пост! И несмотря на то, что я сторонник OpenSource, всё же как бывший win-админ ставлю вам большой виртуальный плюс (чем могу, увы), очень многим начинающим админам этот топик поможет сориентироваться в продуктах MS и построить правильную инфраструктуру.
UFO just landed and posted this here
Здесь не нужны ни одни ни другие. Пост не для них.
Автору спасибо
Автору спасибо
Как один из помешанных «фанатиков-линуксоидов», смею заявить от лица части себе подобных, что пост хоть и во многом рассказывает о весьма повседневных и очевидных вещах, но вскопе, очень четко и грамотно. И уж точно не несет никакой привязки к 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. Отдельно хочу отметить: важно не просто делать бэкапы, а продумать схему, по которой эти бэкапы будут восстанавливаться. Мало иметь дамп базы данных, нужно ещё документировать схему СУБД, чтобы знать, куда дамп разворачивать. Ну и так далее.
В любом случае, статья очень понравилась, спасибо!
В любом случае, статья очень понравилась, спасибо!
Я Вам обязательно плюсик поставлю, когда (и если) у меня появится такая возможность
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Во многом да, да не совсем. Отдельная железка может и не понадобиться — уже вовсю есть провайдеры, подающие телефонию сразу через 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 компов — даже не старайтесь. Только если у фирмы очень много денег, а у вас очень много свободного времени. Это очень тормозная и тяжелая штука, которую к тому же не просто освоить. Сначала отточите базовые вещи, чтобы все работало как часы. А потом уже — упрощалки жизни.
Ну и самое главное — не пренебрегайте чтением мануалов, техподдржкой (у микрософта она ОЧЕНЬ качественная). Поверьте, все их продукты отлично документированы, и на любой Ваш вопрос найдется ответ. Досконально разберитесь во всем, не торопитель поставить все сразу.
UFO just landed and posted this here
Всегда было интересно, чем пользуются для удаленного администрирования? В пингвинах и линуксах вот ssh, а тут? Power shell плюс какой-то аналог ssh?
Солько человек должно быть в службе ИТ для создания и поддержания всего этого хозяйства?
Сразу скажу, что реальная инфраструктура развесистей, чем описано в статье. Есть большое число сервисов написанных нами самими. Есть три офиса в других городах 5-20 человек, всё это администрируется из центрального офиса.
Поддержка и развитие всего, что описано выше + дополнительные сервисы осуществляется 6 человеками:
4 техника, и 2 инженера. Загрузка сотрудников поддержкой — менее 50 процентов в отсутствие авралов, отпусков и так далее.
Поддержка и развитие всего, что описано выше + дополнительные сервисы осуществляется 6 человеками:
4 техника, и 2 инженера. Загрузка сотрудников поддержкой — менее 50 процентов в отсутствие авралов, отпусков и так далее.
отлично, спасибо
давно искал подобный материал для развития :-)
давно искал подобный материал для развития :-)
Sign up to leave a comment.
Строим инфраструктуру на базе продуктов MS