27.03.2012 01:49:24

Максим

Exchange 2010 и сетевая карта

На днях переносили виртуальную машину с Exchange 2010 на новый сервер. Точнее переносили только VHD диски. Сама виртуальная машина ушла безвозвратно. На новом сервере сделали виртуальную машину, подключили диски, загружаемся, и все виснет. Вообще это старые грабли по которым ходили не один раз. Exchange2010 не работает без включенного IP6. Если он не включен, то Exchange2010 просто не поставится, но в процессе работы нам никто не мешает выключить IP6. Если это сделать, то попасть в настройки сети уже не возможно, а сервер начнет тормозить. В нашем случае не то что небыло IP6 сетевой карты не существовало потому что не устанавливались драйвера на нее. Получился замкнутый круг: для работы сервера нужна сеть, а для того чтобы настроить сеть нужен работающий сервер.

Решение проблемы следующее:

• Перезагружаемся в безопасный режим без поддержки сети
• Выключаем службы Exchange
• Перезагружаемся в обычном режиме
• Настраиваем сетевую карту
• Включаем службы Exchange
• И для верности перезагружаемся еще раз

Excahange2010 IP6 сеть

26.03.2012 11:17:17

Эраст Костюк

Встречаясь с новым клиентом в части построения его IT инфраструктуры (а проще говоря - компьютерной системы) часто приходится сталкиваться с ситуацией,  когда "ничего не работает".  То есть IT система доведена до состояния полного упадка. Именно тогда руководитель компании задумывается над тем, чтобы обратиться к специалисту.

В ситуации, когда мы выступаем в качестве системных администраторов, понятно, что наша цель - это добиться устойчивой работы системы, когда все сервисы доступны пользователям, и выход из строя того или иного оборудования - это скорее исключение чем правило.  Все согласятся, что хороший системный администратор, это тот, кого не видно и не слышно. Когда создается ощущение, что все компьютерное оборудование работает само по себе, и не задает лишних вопросов.

Но - чтобы добиться такого результата - часто приходится выстаивать компьютерную систему клиента практически заново. Один из примеров - это клиент у которого было около 30-ти компьютеров, а так же несколько серверов - файловый сервер с внешним хранилищем, доменный контроллер, почтовый сервер Microsoft Exchange,  Сервер - шлюз в интернет ISA,  а так же еще множество различных сервисов, поднятых на трех физических серверах серверной группы.

На моменте входа к этому клиенту - IT система работала крайне неустойчиво. Считалось, что в системе живет множество вирусов.  Но на самом деле - система идеологически была собрана так, что устойчивой работы добиться было невозможно.

В результате был придуман целый проект - как скомпоновать серверную группу, какие сервисы разместить на том или ином сервере, как правильно организовать работу пользователей -  и после революционной перестройки компьютерной системы - все заработало устойчиво и с минимальными проблемами.

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

Однако, случился кризис 2008 года.

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

Есть еще несколько случаев, когда клиенты отказались от договора абонентского обслуживания IT системы, так как все работает и ничего не ломается.

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

Итого: в чем все же преимущество Абонентского обслуживания IT системы - против разовых выездов?

1. При разовом выезде мы устраняем проблему. Завтра будет другая - устраним другую - главное оплачивайте.

При абонентском обслуживании компьютеров мы заинтересованы выстроить IT Систему так, чтобы проблем не возникало в принципе. Это в разы снижает время простоя у клиента

2. При абонентском обслуживании решается еще целый спектр задач мониторинга состояния системы:

- резервное копирование и отслеживание наличия резервной копии и правильности работы системы

- антивирусная защита и отслеживание проблем с вирусами и другими нарушениями защиты

3. При абонентском обслуживании компьютеров ведется документация, значит сокращается время решения проблемы

4. При абонентском обслуживании компьютеров периодически проводится аудит IT Системы и делаются предложения по улучшению системы. Клиенту нет необходимости следить за новинками IT рынка - мы часто можем предложить более оптимальные и более дешевые решения.

5. Если нет договора, то нет линии поддержки.  Пользователей клиента ни кто не консультирует по множеству мелких вопросов, а срок реакции на проблемы может быть не 2 часа, а значительно больше, так как разовые задачи будут иметь наименьший приоритет.

6. В случае договора - за компанией закрепляется один или несколько, но постоянных специалиста, которые знают что и как устроено в системе.  Решение же разовых проблем может быть поручено тому специалисту, который свободен

Самое главное.  Если у нас с Вами будет договор абонентского обслуживания, это означает, что наша главная задача думать о том, чтобы у Вас все работало безотказно, и с минимальными затратами.

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

Э.В.Костюк. Руководитель компании                                       

сервер шлюз в интернет | файловый сервер | почтовый сервер | сервер | Обслуживание компьютеров

24.03.2012 08:55:10

Максим

Установка Zimbra

Zimbra это почтовый сервер, являющийся достойной заменой Exchange. Есть платная и opensource версия с достойным функционалом. Скачать можно с www.zimbra.com Установку делал на CentOS5.8 Процесс довольно простой:

• Распаковываем скачанный архив
• Перед установкой мне нужно было поставить 2 пакета yum install gmp sysstat При установки скрипт проверит наличие нужных пакетов и напишет чего не хватает.
• Запускаем скрипт инсталяции ./install.sh --platform-override
Параметр нужно указать, чтобы zimbra дала себя поставить на CentOS вместо Redhat
• На все вопросы скрипта установки можно отвечать по умолчанию.
• После установки пакетов попадаем в меню конфигурации. Из обязательных действий: задать пароль администратора. Без этого мы не можем продолжить. Вводим "3" и попадаем в подменю, вводим "4" и у нас спрашивают пароль (сложный пароль за нас уже сгенерили), вводим пароль и жмем "r" для возврата в предыдущее меню
  
• Вводим "a" чтобы применить настройки
• На этом установка заканчивается. Открываем в браузере http://localhost:7780 чтобы войти в админку

На самом деле после установки нужно будет провести еще ряд настроек:

• Если zimbra стоит внутри домена и отвечает за домен вида mydomain.local то нужно, чтобы при отправке писем подменялся домен в адресе отправителя
• Если мы отправляем почту через smtp сервер провайдера, то это нужно настроить
• Если мы хотим забирать почту от провайдера по pop3, то нужно настроить fetchmail
• Ну и конечно нужно настроить политики и пользователей внутри zimbra

установка zimbra почта linux centos