Так уж получилось, что у нашей компании есть доступ к службе поддержки Микрософт и нет-нет нам приходится прибегать к ее услугам.
Все началось как обычно, нежданно-негаданно. В удаленном офисе вдруг завалился сервер, пользователи побежали за пирожками или принялись рубиться в шашки, а локальный helpdesk стал обрывать мой телефон с одним вопросом: «Это надолго?”
А случилось вот что. Как известно, Exchange хранит свою служебную информацию в AD. У нас AD разбросана по двум Windows сайтам в разных городах. Офисы соединены каналом 256к.
Мы выключили один из DC у себя, а сервер завалился в удаленном офисе. Оказывается, Exchange не хотел работать со своим локальным GC/DC в своем сайте и полез в наш сайт. Причем ему подходил только наш старый GC/DC, который мы выводили из эксплуатации. В логах Exchange было написано черным по белому: «Вижу локальный DC/GC, но работать с ним отказываюсь. Работаю с удаленным DC/GC» Пришлось на время включить старый DC/GC в нашем сайте и начать изучение Knowledge Base. Поиск ни к чему не привел. Пришлось открывать Trouble Ticket у Microsoft.
В связи с тем, что из 10-15 наших запросов к российской службе поддержки Микрософт нам реально помогли только один раз, мы попросили Микрософт направлять наши запросы сразу к буржуям. Ответы приходят от самых разных людей со странными именами и фамилиями. Сначала мы думали, что это китайцы. Потом пришли к мнению, что индусы. Им, конечно, большой респект, иногда диву даешься их знаниям.
На первой ступени мне прислали ссылку на hotfix. Мы его скачали, поставили. В Event log написано, что hotfix установлен successfully. НО! В списке установленных программ его нет, а в логах установки hotfix в c:\winnt\KBномерхотфикса.log сплошные ошибки. Реально hotfix не был установлен. Затем меня попросили проделать стандартную процедуру сбора информации – MS Report. Это софт, который запускает всевозможные утилиты, складывает результаты их работы в cab файл и этот 4-меговый ужатый файл нужно отослать службе поддержки.
Затем началась долгая переписка о том, что во всем виноват APC Powershut и сертификат Java машины, остатки которых обнаружены на сервере. Обновление, удаление этого софта и применение хотфикса заново ситуацию не изменили.
Вчера звонок в 9 вечера: «Хай, ит из Хумпур Бумпур фром Микрософт и т.д.» Оказывается, что нас перевели на новый уровень обслуживания и теперь будем общаться по телефону, т.к. по e-mail долго и непродуктивно. Договорились, что он перезвонит мне утром на работу. Можно сверять часы. Ровно в 10 началась наша 4х!!!-часовая беседа.
Сначала Хумпур Бумпур долго меня просил запускать dcdiag и netdiag, nslookup, ping и т.д. Я ему отослал результаты тестов и пошел на обед.
Вернувшись с обеда он перезвонил и сообщил мне, что проблема вышла за рамки ее компетенции и еще нужен спец по AD - Josh. Он задал пару вопросов и сказал, что без удаленного доступа продолжать работу нельзя. Для этого у Микрософта есть отличное решение – Microsoft Office Live Meeting. C помощью него можно расшарить доступ к своему рабочему столу, зайдя на страничку браузера и установив спец. компонент в Windows. В принципе это безопасно, т.к. ты видишь, что делают спецы Микрософта и можно им просто не давать управление, да они и сами не особо хотели.
В общем, находясь в одном российском городе, я зашел через RDP на сервер в другом городе и запустил туда спецов из ... Индии. Интернет воистину стирает границы. В конце концов в телефонной конференции сидело одновременно 5 человек из Микрософт и я. Все пялились на экран и один из них говорил мне, что делать, и я набирал команды и ставил галочки. Они это анализировали. Потом их осталось двое – спец по Exchange и спец по AD. Крутили, вертели - не работает и все тут. Начали устранять ошибки, полученные в результате работы DSDIAG. Последняя ошибка была такая: DC located is not Domain Controllers OU. Да, это правда. Каждый офис имеет свое OU и туда же перенесены все серверы. Переместив сервер в OU Domain Controllers, Exchange после рестарта сервиса System attendant увидел локальный DC, и воцарилось на земле счастье.
Итог всего этого. Хорошо, когда есть поддержка Микрософт. Методы работы этой службы и знания специалистов впечатляют. Затраты Микрософт – работа 5 человек, оплата за телефонную линию Индия-Россия в течении 4 часов. Впечатляет.
Очень понравился Microsoft Office Live Meeting. Они в нем как рыба в воде. Чувствуется богатый опыт по работе с клиентами, все вопросы ко мне сводились к Да/Нет. И все указания по запуску программ расчитаны на полных чайников.
Завтра меня ждет звонок в службу поддержки RedHat в России. Первое знакомство с ними закончилось фразами: «Ну? Ага!» с их стороны. Вот и сравним.
4 комментария:
А насчет MS Report подробной информацией не поделитесь. А то по поиску Microsoft мусора много
Я приведу отрывок из стандартного письма службы поддержки Microsoft
Please collect MPS Report by following the instruction below, on your Exchange server and domain controllers (all three GCs):
Please download the tool MPS Report at the URL: (http://download.microsoft.com/download/b/b/1/bb139fcb-4aac-4fe5-a579-30b0bd915706/MPSRPT_Exchange.EXE). Run this tool on the Exchange server and the DC to gather detailed information regarding your system's current configuration. The reporting tool does not make any registry changes or modifications to the operating system. On your system a CAB file will be generated for your convenience in the %systemroot%\MPSReports\Setup\Report Type\Cab directory called %COMPUTERNAME%_MPSReports.CAB. The CAB file will contain the reports generated by the MPS Reporting Tool. Please send the cab file to me.
Павел, приветствую.
очень полезная информация. благодарю вас за рассказ.
А нет ли более подробной информации о том, почему Exchange повел себя именно таким образом при таком раскладе? говорит ли это о том, что все DC нужно хранить в OU Domain Controllers?
Микрософт приводил кусок из документации, где четко написано, что не рекомендуется переносить DC из OU Domain Controllers.
Отправить комментарий