Архив

Archive for Январь 2011

Migration Preparation Tool в новом SBS 2011 Standard

Сегодня мы поговорим о новой (или очень обновленной) утилите, которая включена в SBS 2011, а именно об Migration Preparation Tool. Основная задача этой утилиты – подготовить существующий сервер и домен для миграции на SBS 2011. Выполняет она 2 важные задачи:

  • проверяет состояние существующего домена, идентифицирует всяческие инциденты, которые могут помешать успешной миграции
  • непосредственно подготавливает домен для SBS 2011
  • Учтите, нельзя запустить установку нового сервера в режиме миграции, не запустив эту утилиту на существующем сервере в существующем домене. После запуска утилиты есть 14 дней, чтобы провести миграцию. Но лучше не затягивать, а запускать утилиту непосредственно перед началом процесса миграции, это позволит избежать появления новых инцидентов.

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

  • повышение уровня домена и леса до Windows Server 2003
  • выполнение ADPREP для расширения схемы Active Directory до Sever 2008 R2
  • установка обновления KB943494 для продления совместного использования двух SBS до 21 дня (необходимо только для SBS 2003)
  • конвертация Exchange в Native Mode (только для SBS 2003)
  • Migration Preparation Tool во время своей работы также проверяет домен и исходный сервер на предмет ошибок или неправильных параметров, которые могут помешать успешной миграции. Анализируются многие аспекты, вот несколько основных из них:

  • Journal Wrap
  • функциональный уровень домена и леса
  • выключенные сервисы
  • неустановленные обновления
  • прерванные репликации
  • отключение IPv6
  • и многое другое…
  • Учитывая результаты своего анализа, утилита может выдавать либо предупреждения, либо ошибки. Ошибки необходимо устранить перед миграцией, а предупреждения в общем случае можно и проигнорировать. Однако, следует относиться к такому “игнорированию” очень аккуратно. Рекомендуется исправлять все ошибки и предупреждения перед началом миграции. Экономия нескольких минут на эти исправления не может сравниться с потерянными часами на восстановление из бекапов и начала процедуры миграции по новой.

    Для установки утилиты и последующей работы на существующем сервере необходимо наличие на нем:

— установленного программного обеспечения

  • .Net 2.0 SP1
  • Microsoft PowerShell 2.0
  • Microsoft Baseline Configuration Analyzer
  • — прав пользователя

  • Enterprise Admin
  • Schema Admin
  • Domain Admin
  • — ролей сервера

  • Schema Master FSMO Role
  • Infrastructure Master FSMO Role
  • Если не выполняется хотя бы одно из условий – ошибка. Утилита не будет установлена.

    После установки можно смело запускать. Сразу же будет предложено скачать и установить обновления. Очень рекомендую именно так и сделать. Это поможет избежать проблем в миграции.
    Как только обновления установлены, можем начинать. Утилита предупредит о необходимости создания и тестирования бекапа, вдруг что-то пойдет не так.

После подтверждения наличия бекапов утилита начнет непосредственно подготавливать ваш домен (может быть выполнено от 0 до 4 задач, в зависимости от вашего домена). Зеленые индикаторы покажут, что всё в порядке, красные же будут сигнализировать об ошибках, которые надо будет устранить. Выяснить причину ошибок можно по логу, который доступен в папке C:\Users\<UserName>\AppData\Local\Temp\Migration Preparation Logs.

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

Если сканирование не выявило никаких ошибок, финальное окно Migration Preparation Tool предложит ознакомиться с Migration Guide и создать Answer File, который будет необходим для установки нового SBS 2011.

Реклама

О том, как НЕ НАДО писать статьи

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

На данный пост меня сподвигло чтение сего чудного опуса, который претендует, исключительно по мнению автора, на объективность и всенепременное использование – “Идеальный корпоративный почтовый клиент”. В понимании любого здравомыслящего человека, связанного с ИТ, Mozilla Thunderbird таким не являет в принципе. Но мне было интересно почитать аргументы и доводы автора. Да, речь пойдет в основном о цитатах автора в комментариях, его объяснении своих действий, а также его глубоких, фундаментальных и исчерпывающих знаниях в сфере ИТ. Орфография автора сохранена. Было лень править чужие ошибки. Давайте начнем уже…

Плагины + автоконфигуратор всего-чего-угодно, лёгкий удалённый доступ и т.д. — большинство мелочей на outlook сделать просто невозможно. Да, предложенный механизм более «расхлябанный», в том плане, что тут нет кнопки «сделай мне зашибись то-то». Зато сделать можно всё, что угодно. А outlook+exchange — это целостное решение, но умеет оно только базовый функционал, в него заложенный. А в сторону ни шагу ступить не даёт.

Уже эти фразы сказали о многом. Последние два предложения (для тех, кто в теме) сразу сдали автора.

Аутлук мне нравится больше внешне. Но тандер функциональнее. В итоге — аутлук+екс — это очень хорошо. но шаг в сторону — и всё ломается чуть менее, чем полностью. А тандер+давкот — это универсально и функционально.

Оцените профессиональный подход к оценке почтовых клиентов. Опять голые слова, которые не подтверждаются ничем. Я так и не понял, о каком шаге в сторону идет речь, а также о критериях универсальности.

Купленная лицензия как бы остаётся, да. Но есть ещё 1000 и 1 всяких мелочей, которые постоянно сосут деньги. поработайте в крупных фирмах-клиентах мс, увидите. в этом нет ничего плохого, просто один раз купил — и потом вечно пользуешься — это очень далеко от истины. OSS проигрывает, да. Но каждый выбирает для себя. Я один раз настроил, написал документацию — вот и всё, все пользуются и екс не нужен.

По опыту могу сказать, что этой 1001 причиной является некомпетентный администратор, который на каждый новый функционал или сервис городит очередной огород из кучи программ/сервисов/серверов. Понимания сути лицензирования нет также и в помине. Ключевой аргумент, как погляжу, именно в “екс не нужен”. Иначе нет способа повысить ЧСВ такому администратору.

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

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

Ну вот звонит вам бухгалтер из магазина и говорит — мне нужен мой ящик в моём клиенте. Что делаете вы? Скорее всего, подключаетесь удалённо через RDP, выгоняя бухгалтершу нафиг с компа, или через что-то более нормальное, вроде тимвьювера, и подключаете. Бухгалтерша на нервах, вы тормозите её работу, отвлекаете от раскладывания пасьянса, она идёт жаловаться шефу. У меня постоянно так было, может вам больше с бухгалтершами везло. ничего страшного, но куча нервов. Что делаю я: за полминуты добавляю три строчки в конфиг и всё. Бухгалтерша довольна и никто не капает на мозг.

Вот мы добрались уже до примера из жизни пользователя “корпоративного почтового клиента”. Мало того, что ни в одной приличной организации такая ситуация не будет решаться в связи с её абсурдностью, так автор показывает свое полное непонимание принципов работы удаленного доступа. Но и это всё. Как вам ситуация, когда по просьбе, не имеющей ничего общего с задачами компании, бухгалтера вносятся правки в конфиги? А вот так! Я бы выгонял сразу обоих таких работников.

Вот круто! Теперь расскажи мне, мил человек, как удалённо подключить IMAP Yandex ящик к Outlook, как в примере? Как удалённо безопасно работать в корпоративной сети без VPN? Как подключить терминалки с Linux к почтовой системе? Причём тут СПО? Thunderbird описанный механизм поддерживает почти с рождения. Хочешь пользоваться абсолютно негибкой технологией, платя за неё кучу бабок — пользуйся, тебе никто не запрещает. Я целенаправленно искал решение, способное обеспечить большую гибкость, чем Exchange+Outlook. И нашёл. Да, самописные скрипты. Но хороший сисадмин обязан уметь писать скрипты и разбираться в них. Зато максимально возможная гибкость.

Хорошо приводятся задачи linux-администратора. Только вот ответа нет, как в linux работать удаленно без VPN, да и не ясно, зачем “терминалки с linux подключать к почтовой системе”. О какой бОльшей гибкости идет речь? Ну и в конце притча о скриптах. Зачем учиться и что-то знать, если на скриптах всё будет работать. Зато свобода.

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

Типичный бред про то, что каждый новый администратор должен улучшать и оптимизировать всё и вся. Как обычно речь идет об амбициях админов, но никак не о потребностях бизнеса. Да, порог входа в “админство” сейчас очень занижен. Но писание самописных скриптов для бизнес-приложений, которые имеют очень сомнительную надежность (впрочем как и сами используемые открытые программные продукты), это явно не выход. Заменить такого “горе-админа” безболезненно у компании не получится. Зачем любому здравомыслящему руководителю ставить свой бизнес в зависимость от “настроения” и лояльности администратора?

Сотрудники ездят в командировку с собственными ноутами, в которых стоит настроенный тандер — удобней этого быть не может ничего, ибо что внутри корп. сети, что извне — почта совершенно одинакова. Календарь да, надо прошаривать, как там его, CalDAV сервер. Это займёт день-два. В общем, я не согласен с вами. Сисадмин нужен для того, чтобы выбирать оптимальное решение, а не самое удобное в плане кнопочек. ИМХО, в подавляющем большинстве случаев описанное решение намного оптимальней екса. Если конечно сисадмин достаточно компетентен, чтобы его поднять. Сейчас покупать Екс — это привязывать себя к инфраструктуре МС и добровольно соглашаться постоянно платить МС бабки за всё. Какой стратегический смысл? Проще начальная настройка? Вы никогда не сможете нормально использовать Linux в организации, если купите екс. Любите тратить деньги впустую — не мне вас судить. Я не люблю, мне платят зарплату для того, чтобы я делал всё максимально оптимально для фирмы.

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

Ну и перл про невозможность нормально использовать linux в организации после покупки Exchange также стоит отметить.

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

Золотые слова – “мне больше никогда ничего не надо было” – прозвучали и здесь. И таких “новшеств” в интернете хоть пруд пруди. А мне надо совсем другое. Приведенное автором решение абсолютно бесполезно. Плагины для “допиливания” использовать тоже не особо по уму.

Давайте глянем, что автор преследовал написанием данной технической (?) статьи.

1. Для начала — кросплатформенность. Глупо использовать стандартизированные технологии, но привязываться изначально к одной ОС, тогда уж проще сразу купить Exchange и навсегда забыть о какой-либо гибкости разворачиваемой инфраструктуры.

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

3. Возможность централизованной настройки клиента через сервер.

4. Гибкость настроек клиента и удобство в использовании.

1. Супер фраза про глупость использования стандартизированных технологий. Объясните мне, зачем почтовому серверу кроссплатформенность? Почему покупка Exchange влияет на гибкость инфраструктуры?

2. Остальные три пункта есть в Exchange + Outlook уже очень давно.

Вот и напрашивается вывод, а зачем вообще статья? Как самому написать пару скриптов, чтобы попытаться смоделировать функционал Exchange Server? Ну удобство и простота такого решения вызывает очень большой вопрос и целесообразность. Помните, мы же о корпоративном сегменте говорим… Поднять ЧСВ автора? Наверное… Из статьи я так и не понял, чего хотел добиться автор и чего не умеет, по его пониманию, Exchange. Внятно это сформулировать не удалось. Попытаться open source продуктами подражать функционалу Exchange? Наверное… Ни одна компания не будет использовать такой вновь изобретенный велосипед для корпоративной почты, хотя наверное у нас абсолютно разные понимания о “корпоративности”…

Не хочу начинать Holly War по поводу Exchange vs Open Source. Заметьте, я ни слова не написал об Exchange, о том, что он умеет и может. Я просто хотел акцентировать внимание на самом принципе написания псевдотехнической статьи, на понимании основ ИТ автором, на адекватности мышления в сфере ИТ. Не пишите такие статьи, мой вам совет. Хотя если целью статьи было рассмешить – это автору удалось на все 100%.

2010 in review

The stats helper monkeys at WordPress.com mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:

Healthy blog!

The Blog-Health-o-Meter™ reads Wow.