Office Communicator 2007 + Outlook

При развертывании клиента Office Communication Server 2007 R2 столкнулся со следующей проблемой. Клиент нормально стартует, показывает список контактов, но говорит о том, что не может интегрироваться с моей учетной записью Outlook. Выглядит это вот так:
"There was a problem connecting to Microsoft Office Outlook. Your Outlook profile is not configured correctly. Contact your system administrator with this information."
Как было замечено на том же social.microsoft.com: the problem is... i'm system administrator. В результатах выдачи гугля много решений, и ковыряние реестра, и переустановка всего Office, и перенастройка профиля пользователя. Однако в большинстве случаев идут отписки, что ничто из этого не помогает. Как быть?
На одном из форумов нашлось решение, которое помогло лично мне. Оно до безобразия простое:
1. Закрыть Outlook и Communicator;
2. Выполнить в командной строке fixmapi.exe;
3. Снова запутить Outlook и Communicator.

После этого ошибка исчезла, коммуникатор смог предоставить весь функционал работы с Outlook.

@музыка: En Voice - Orange Moon

@темы: MS Exchange

---

Cached Files

Кэш. Не тот, что наличный, а тот, что временное хранилище файлов. Хорошая вещь, помогающая сэкономить на трафике, но только в том случае, если за ним следить. А пользователи, как правило, вообще не в курсе, что это такое, зачем оно нужно. Более того, они не в курсе, что он вообще существует. Но обязанности следить за ним это не отменяет.
Если не ограничивать в размерах временные папки - они склонны раздуваться, раздуваться и раздуваться. Плодитесь и размножайтесь, так вроде было? Значит, нужно как-то эти папки чистить, потому что пользователя не допросишься это делать.
Основные два рассадника "времянки" - браузер и почтовый клиент - IE и Outlook. И если в первом еще можно размер обозначить, то второй чрезвычайно любит покушать. Суть идеи проста - удалять содержимое этих хранилищ когда пользователь выходит из системы. Расположения кэшей известны:
C:\Documents and Settings\%username%\Local Settings\Temporary Internet Files\Content.IE5\ - браузер
C:\Documents and Settings\%username%\Local Settings\Temporary Internet Files\Content.Outlook\ - Outlook 2007
C:\Documents and Settings\%username%\Local Settings\Temporary Internet Files\OLK*\ - Outlook 2003

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

Clean Cache.cmd

Clean Cache.cmd

rem delete IE cache
del /f/s/q "C:\Documents and Settings\%username%\Local Settings\Temporary Internet Files\Content.IE5\*.*"

rem delete outlook 2007 cache
del /f/s/q "C:\Documents and Settings\%username%\Local Settings\Temporary Internet Files\Content.Outlook\*.*"
rd /s /q """C:\Documents and Settings\%username%\Local Settings\Temporary Internet Files\Content.Outlook"""

rem delete outlook 2003 cache
for /d %%a in ("C:\Documents and Settings\%username%\Local Settings\Temporary Internet Files\OLK*") do (
del /f/s/q "%%a\*.*"
rd /s /q """%%a"""
)

Одним из плюсов постоянной очистки, по крайней мере, кэша браузера видится тот факт, что это позволит стирать с жестких дисков пользователей всякую вредоносную дрянь, которая сидит в Temporary Internet Files, и запускается c User-level правами на старте системы. Антивирус все же не панацея.

@музыка: Moya Brennan - Tara

@темы: Scripting

---

Oneliners #2

Возникла сегодня интересная задачка: узнать, у кого из пользователей нашего домена стоит перенаправление почты на древнючий ящик. Лет тому ящику уже много, пора бы это дело и снять. Решение оказалось простым:
$user = (get-qaduser 'USERNAME').directoryEntry.DistinguishedName; get-qaduser -oa @{altrecipient = "$user"}
Входной параметр - имя того пользователя, на которого поставлено перенаправление. Выход - список пользователей, которые заваливают несчастный ящик своими сообщениями.
Конечно, можно было бы огульно сменить у всех в домене параметр altrecipient на NULL, но это порушило бы нужные перенаправления (а их немало).
Самым любопытным здесь является параметр {altrecipient = "$user"}. Переменную $user нужно обязательно заключать в парные кавычки. Именно в парные. Без них команда будет ошибочной, потому что переменная не распознается. Если же заключить переменную в одинарные кавычки - в скрипт вместо значения переменной будет передано ее имя.

@темы: PowerShell, MS Exchange

---

Kido #5 - Aftermath

Уже год, как отгремела волна заражений поганцем Kido. Эпидемия сошла если и на нет, то количество инцидентов уж точно значительно снизилась. Тем не менее, периодически то тут, то там еще видно сообщения о том, что нашелся зверь и пытается пакостничать. Как же выяснить, откуда прет зараза?
Антивирусные средства видят факт попытки заражения и успешно отстреливают вредоносные файлы, но источника не показывают, а ведь он и нужен. На помощь может прийти лог контроллера домена - ведь в нем фиксируются все попытки авторизации под какой-либо учетной записью (компьютера, пользователя - не имеет значения). Нужно лишь суметь этот лог настроить и проанализировать.
Первое, что нужно сделать - это включить регистрацию о неуспешных попытках авторизации, об этом уже было написано. Второе - собственно наблюдение. Нужно вывести лог безопасности контроллера домена, а для облегчения работы настроить в нем фильтр следующим образом:

Event types - Failure Audit
Event ID - 680

А дальше смотреть на ошибочные записи. Если Кидо пытается пролезть по сети, то все его проваленные попытки будут формировать событие именно с кодом 680. Причем таких событий в секунду будет очень много (до 20). Дальнейшие действия тривиальны - раскрываем любое из таких событий, смотрим, какая система их генерирует, и идем выкорчевывать поганца.

P.S. И снова повторюсь, реалия сегодняшнего дня - не должно быть ни одной машины, где не установлены заплатки, описанные в бюллютенях безопасности MS08-067, MS08-68, MS09-001.

@музыка: Moya Brennan - Tara

@темы: Viruses and Spam

---

IE 6,7,8

Гром таки грянул. Сколько пришлось попариться для того, чтобы обновить IE на компьютерах домена до версии выше, чем 6 - почти все напрасно. Выяснилось, что один из компонентов используемого бизнес-приложения стабильно работать может только в версии 6. Во всех других он может завесить браузер намертво, что приводит к лишнему расстройству, потери набранных в форму данных (браузер нужно будет перезапустить без сохранения состояния). В общем, обещается много-много неприятного. В связи с чем встал вопрос - как бы версии 7+ снести с порядочного количества компьютеров максимально быстро и по возможности без лишних телодвижений и звонков. Немного ковыряния в предметной области показало, что у приложения Windows Internet Explorer 7/8 есть так называемая строка деинсталляции (в общем и целом, эта строка есть почти у всех продуктов, которые прописываются в апплете "Установка и удаление программ"). Оно и понятно, системе ведь нужно что-то запускать для процесса удаления ненужного приложения.
Что ж, это радикально меняет дело. Строка известна, стало быть нам нужен еще один скрипт, который будет запускаться на нужных компьютерах. В итоге получается следующий vbs-файл:

'Internet Exploer 7,8 Uninstallation
on error resume next
Set WshShell = CreateObject("WScript.Shell")
'Uninstall IE 8
WshShell.Run "C:\WINDOWS\ie8\spuninst\spuninst.exe /quiet /norestart",1,true

'Uninstall IE 7
WshShell.Run "C:\WINDOWS\ie7\spuninst\spuninst.exe /quiet /norestart",1,true

Вот такой небольшой сценарий.
Последний момент - после удаления всех старших версий компьютер нужно перезапустить. Проблема в том, что пользователи на это чаще всего забивают. Что делать? Выход прост - этот скрипт нужно выполнить в момент завершения работы компьютера.
Таким образом получаем довольно простой сценарий: групповая политика, область действия - выбранные компьютеры (а они известны), параметры политики - Shutdown sсript, именно туда нужно будет подставить указанный выше сценарий. Дело за малым, перезагрузить машины - и задача выполнена.

@музыка: Clannad - From Your Heart

@настроение: Scripts are my best friends

@темы: Scripting

---

Support

Есть на этом свете славная компания HTC, выпустившая немало славных коммуникаторов. Дорогих и не очень, навороченных, и менее функциональных. WM-based и Android-based. Вот о последних речь и пойдет.
Недавно возникла задача - подключить коммуникатор сотрудника (HTC Hero) к корпоративной почте. Все бы ничего, но при проверке соединений используется самоподписанный сертификат. Знающие люди поймут сразу, о чем сыр-бор, а для незнающих поясню. Дело в том, что таким сертификатам не доверяет ни одна система. Даже та, которая этот сертификат и подписала для себя. И для того, чтобы она стала ему доверять, корневой сертификат центра сертификации (сорри за тавтологию), должен быть напрямую импортирован в систему. Тогда последняя начнет доверять этому корневому, а следом за ним и всем сертификатам, которые этот корневой подписал.
Чем это неудобно для владельцев коммуникаторов. Эти устройства при обнаружении самоподписанного сертификата просто отвергают соединение с выводом сообщения об ошибке. WM-based коммуникаторы "пролечиваются" очень просто - сертификат копируется на них в их файловую систему, после чего в стандартном Проводнике добавляются в хранилище сертификатов. Все, устройство готово к работе.
В случае Android-based устройства (коим и является HTC Hero) получили самый настоящий геморрой. Дело в том, что у данной конкретной модели просто НЕТ Проводника или любого другого метода просмотра файловой системы. Можно обратиться к музыке, к картинкам, но только через соответствующие программы. Они работают на основе каталогов, которые сами же и составляют. Всякий, кто работал с библиотекой Windows Media Player - меня поймет. Но сертификат, лежащий на карте памяти телефона - это не картинка, не музыка, даже не какой-либо офисный документ. И никакая программа из поставляемых "в коробке" его не видит.
В интернете лежит куча шаманских методов сертификата, но 100%-но работающего нет ни одного. В итоге решил, как самый обычный пользователь обратиться в поддержку компании HTC, благо, на сайте есть специальная веб-форма. По логике вещей, уж компания-производитель должна что-то дельное подсказать. Сказано - сделано, написал, нажал кнопку отправить, и стал ждать. Дождался, ниже привожу запрос и ответ. Это феерия!

Запрос
Добрый день. Хотелось бы уточнить, каким образом можно настроить телефон HTC Hero так, чтобы он доверял самоподписанному сертификату Exchange, используемом в организации. В настоящее время телефон при попытке доступа к серверу через защищенное соединение выводит сообщение о том, что сертификат не является доверенным, и предлагает либо продолжить, либо отменить соединение. При продолжении снова появляется окно о недоверенном сертификате, и так повторяется бесконечно.
В общем случае для решения проблемы нужно импортировать на устройство корневой сертификат, но как это можно сделать на данном телефоне?
Заранее благодарен за ответ.

Ответ
Добрый день!
Спасибо за обращение в HTC.
Коммуникатор на базе ОС Android автоматически прописывает сертификаты. Если Ваш аппарат показал извещение об ошибке сертификата, то обязательно выбирайте пункт "продолжить" и коммуникатор загрузит нужные данные.
Пожалуйста, обратите ваше внимание, что вы можете также связаться с нами по телефону.Для более детальной информации пожалуйста перейдите по ссылке www.htc.com/uk/CA_Hotline.aspx
С уважением, НТС.

Если честно, после подобного ответа у меня не остается никакого другого выбора кроме закрытия запроса. И заодно я уверился во мнении, что если даже когда-то и приобрету себе смартфон, это не будет Android-based.

@темы: Этот безумный мир, Android

---

Oneliners

Oneliner - сценарий, состоящий из одной строки (one line). Их удобство в том, что для решения какой-то задачи достаточно открыть консоль, набрать нужную команду, запустить ее на выполнение и получить результат. Нет необходимости писать текст скрипта, сохранять его, затем писать команду на вызов этого сохраненного файла. Все просто.

Недавно понял, что нужно привести в порядок в нашем домене ограничения на максимальный размер передаваемого через почту сообщения. У кого-то стоит одно, у кого-то другое, у некоторых вообще десятое. Это неправильно. Два параметра (размер входящего письма и размер исходящего письма) хранятся непосредственно в записях Active Directory, следовательно, вытащить их достаточно просто. Вариантов довольно много, но в итоге я остановился на Powershell и его сторонней оснастке Quest Management Shell. Quest - это отдельный набор команд, облегчающих работу с Active Directory и делающих ее более прозрачной, чем обычные команды Powershell. Сами параметры зовутся так:
SubmissionContLength - размер исходящего сообщения;
DelivContLength - размер входящего сообщения.

После непродолжительного чтения справки удалось набросать сценарий, шаблон которого выглядит так:

foreach ($name in get-qaduser -searchroot 'INSERT IGNORE_ROOT_OF_SEARCH') {set-qaduser $name -objectattributes @{SubmissionContLength='INSERT IGNORE_VALUE';DelivContLength='INSERT IGNORE_VALUE'}}

Пара слов о том, что он делает.
foreach - это команда, которая выполняет определенный набор действий с каждым объектом какой-либо выборки. в общем случае она записывается так:
foreach (selection) {sсriрt}
где selection - это выборка, а sсript - то самое действие (или несколько действий), которые нужно произвести с объектами выборки.
$name - переменная, хранящая в себе имя пользователя.
get-qaduser - одна из ключевых команд сценария. она вытаскивает из Active Directory полную информацию о пользователе, чье имя хранится в переменной $name
-searchroot - модификатор, задающий область поиска. Сюда нужно подставить путь к ветке в Active Directory, в которой сценарий будет искать нужного нам пользователя. Формат записи: 'OU=TestOU,DC=Domain,DC=com'

Таким образом, первая часть сценария создает выборку объектов Active Directory, у которой нужно будет сменить пару свойств. Непосредственно сменой свойств занимается вторая часть скрипта, заключенная в фигурные скобки.
set-qaduser $name - изменить параметры учетной записи, имя которой указано в переменной $name,
-objectattributes @{SubmissionContLength='INSERT IGNORE_VALUE';DelivContLength='INSERT IGNORE_VALUE'} - здесь задается, что именно меняеть, как раз те самые два параметра. Следует обратить внимание, что набор параметров заключается в фигурные скобки.

@темы: PowerShell, Scripting, MS Exchange

---

Ключи...

... от квартиры, где деньги лежат.
Нет, на самом деле речь пойдет о ключах другого рода, лицензионных. Первое, что приходится учитывать компаниям, это ключи на ОС и офисный пакет, если используется MS Office. И может сложиться такая ситуация, когда нужно быстро собрать информацию о ключах на довольно большом количестве машин. Как это сделать?
На помощь может прийти утилита под названием Produkey. Свободно распространяемое мелкое приложение, которое позволяет узнать ключи Windows, MS Office и некоторых других пакетов. Сама эта утилита содержит в себе возможность сканирования удаленных машин с целью сбора информации о лизензиях. Но есть один момент - компьютер для этого должен быть включен. Другой же вариант решения проблемы - запустить Produkey в момент запуска компьютера. Это можно сделать сценарием запуска машины.
Групповые политики, Параметры компьютера, Сценарии запуска. Сюда нужно будет положить сценарий, шаблон которого представлен ниже:

GetKeys.vbs

'Get Keys on startup sсript
'set network-based Computer name - определяем имя компьютера
Set objNetwork = CreateObject("Wscript.Network")
strComputer = objNetwork.ComputerName

'set WshShell - определяем командную оболочку
Set WshShell = CreateObject("Wscript.Shell")

'Set objFSO - определяем объект "файловая система"
Set objFSO = CreateObject("Scripting.FileSystemObject")

'set local file for output - задаем имя файла, в который будет выводиться информация о компьютере
strOutputFileName = "produkey-" & strComputer & ".txt"

'Disable Security Warning for Network Files - на время отключаем предупреждение об открытии файла из нелокального источника
set oEnv = WshShell.Environment("PROCESS")
oEnv("SEE_MASK_NOZONECHECKS") = 1

'set command to execute - определяем команду, которая и будет выполняться при запуске системы (отчет создается в корне диска С
strCommand = "\\NETWORK-SHARE\produkey.exe /WindowsKeys 1 /OfficeKeys 1 /IEKeys 0 /SQLKeys 0 /ExchangeKeys 0 /stab c:\" & strOutputFileName

'execute command - исполнение команды.
WshShell.run strCommand,,true

'set source for copiyng report - переменная с расположением файла-источника для копирования отчета
strSource = "c:\" & strOutputFileName

'set destination for report - переменная с расположением файла отчета в папке отчетов
strReport = "\\REPORTS-FOLDER-SHARE\" & strOutputFileName

'copy report and delete local file - скопировать файл в папку отчетов и удалить локальный файл
objFSO.CopyFile strSource, strReport, true
objFSO.DeleteFile strSource

'Enable Security Warning for Network Files - возобновить предупреждения об открытии файлов из нелокальных источников
oEnv.Remove("SEE_MASK_NOZONECHECKS")

Что делает этот сценарий? При загрузке компьютера из папки \\NETWORK-SHARE\ вызывается программа produkey.exe с определенным набором параметров. Результатом ее выполнения будет созданный в корне диска С: файл с информацией об установленном на компьютере ПО (в той части, которую "распознает" produkey). Далее этот файл копируется в сетевую папку "\\REPORTS-FOLDER-SHARE\", после чего из корня диска С: файл будет удален. Таким образом в папке "\\REPORTS-FOLDER-SHARE\" создается набор файлов, каждый из которых соответствует одному компьютеру. Этот набор файлов уже можно анализировать в спокойной обстановке.
Отдельно об анализе этого набора файлов. Например, требуется узнать, что творится с ключами ОС (типичная в России ситуация для нового системного администратора на предприятии). Известно, что в отчетах produkey информация об ОС идет первой строкой. Значит, задача сводится к тому, чтобы пробежать по всему набору отчетов, вытащить из каждого отчета первую строку и внести ее в файл итоговой таблицы. Эту задачу можно легко решить при помощи Powershell, например:

$ReportPath = "\\REPORTS-FOLDER-SHARE\"
foreach ($name in ls $ReportPath) {get-content $ReportPath\$name -totalcount 1 | Out-file winkeys.txt -append}

Этот нехитрый сценарий пройдет по всем файлам в папке \\REPORTS-FOLDER-SHARE\, прочитает по одной строке из каждого файла в ней, после чего результат скинет в файл winkeys.txt, находящийся в домашней папке пользователя. Работать с единой таблицей же куда проще, чем с набором файлов.

@музыка: Stone Age - Maribrengall

@темы: PowerShell, Scripting, Security

---

Спам и антиспам.

Праздники кончились, начались суровые трудовые будни.
На корпоративную почту свалилось письмо. На первый взгляд - ничем не примечательный спам. Но только на первый. Читаем содержание письма и понимаем, почему оно было пропущено всеми фильтрами:

Spam detection software, running on the system "carin.vtelecom.ru", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details.

Content preview: Bêëaäûâàéòe â ðåkëàìó - áóäåò ìíîãî êëèeíòoâ. Ñeðèÿ èç 3 ìaññoâûõ
ðàñcûëoê (Ìîñkâa è ÌÎ BÑÅÃO çà 5.000 ðóá. PACCÛËKA ïo ëþáoìó PEÃÈÎÍÓ Ðoñcèè
- ÂÑEÃO ça 1.800 póá. Ãoðÿ÷àÿ ëèíèÿ: 92O ____ I9 _ _ 98[/cyrlat] [...]

Content analysis details: (14.7 points, 8.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
[Blocked - see ]
0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL
[85.15.81.128 listed in zen.spamhaus.org]
3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL
3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100%
[score: 1.0000]
0.0 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d
2.4 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr
1)
3.2 FH_DATE_PAST_20XX The date is grossly in the future.
0.0 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date
0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS
-0.4 AWL AWL: From: address is in the auto white-list

И приложение к этому письму - другое письмо с уже типичным спам-заголовком "Кризис закончился!".
Признаться, это сообщение на минуту меня ввело в ступор. Все дело в том, что приведенный выше текст - типичный ответ антиспам-системы о том, что письмо, которое вы, якобы, отправили, расценено как спам. И единственное, что мне помогло опознать в этом письме спам - адрес отправителя, потому как в реальных ответах от антиспама будет стоять назначенный адрес этой системы, но никак не сочетание букв вида [email protected].
Вывод - уж если есть необходимость проверки спама - проверять надо все, и очень внимательно.

@темы: Viruses and Spam

---

Symantec Backup Exec

Система резервирования и архивирования информации. Очень мощная, довольно удобная, но требующая серьезной доработки напильником, то есть настройки. Причем настройка процесса резервирования - это отдельная песня, а сейчас хотелось бы рассказать о вот такой напасти:
The job failed with the following error: The media operation was terminated by the user.

Приход отчета с таким диагнозом для меня стал шоком, потому что я не мог физически отменить бекап. У меня доступа к серверу в тот момент не было.
Первоначальное курение мануалов подсказало, что нужно проверить настойки автоматической отмены заданий. Проверил - ничего не включено, все по-умолчанию, то есть работать до конца. Победного или нет, другой вопрос. Что ж, придется ковырять лог более подробно.
Открываем раздел Job History и смотрим, что происходило во время бекапа. Видно, что бекап снялся, но на стадии его проверки прошел какой-то сбой:
Set Detail Information - Backup
Set type: Backup
Set status: Completed

Set Detail Information - Verify
Set type: Verify
Set status: Completed
Error: e0000602 - A query for media on which the data set being read is continued was unsuccessful. Ensure that all media in the family have been inventoried and cataloged.
Byte count: 0
bytesRate: 0,00 MB/Min
Files: 0
Directories: 0
Skipped files: 0
Corrupt files: 0
Files in use: 0

К чему это приводит? К тому, что при формировании задачи восстановления этот бекап не виден среди всех остальных. Он есть, но к нему нет доступа.
Начинаем шерстить по указанной ошибке гугл, и только гугл, яндекс по ней не знает вообще ничего (надеюсь, теперь узнает). Все ссылки ведут на форумы Symantec, где внятного ответа нет в половине случаев, а то и больше. Но из всей информации ясно одно, проблема возникает на стадии составления каталога кассеты. Предлагается сбросить эти каталоги, сказав Backup Exec'у брать информацию непосредственно читая ленты - как это сделать, описано здесь: seer.entsupport.symantec.com/docs/200962.htm Попытка выполнить эту операцию заканчивается неудачей со следующим вердиктом:
Final error: 0xe0000900 - The requested media is not listed in the media index and could not be mounted. To add the media's catalog information to the disk-based catalogs, run an inventory operation on the media and resubmit the Catalog operation.
Получается цикл, в котором я провертелся в общем и целом около месяца, что является непозволительным сроком. Что делать - непонятно. Виноваты ли кассеты, виновато ли ПО, учитывая, что оно работало, может быть всему виной и сбойный накопитель (самый паскудный сценарий). Все это время пришлось полагаться на встроенный ntbackup, который, в принципе, спасает. Одновременно прокуривал форум Symantec на наличие сходных случаев. И только в одном топике натолкнулся на комментарий сотрудника компании Symantec - "проверьте системные логи на наличие ошибок с кодами ... Они говорят о неисправности с оборудованием"
Чем черт не шутит, не питая особой надежд на то, что это поможет (сам накопитель исправен, в этом я был уверен) открыл логи приложений в самой ОС. Каково же было мое удивление, когда причина всего бардака с каталогизацией появилась прямо перед глазами:
Event Type: Error
Event Source: Backup Exec CatErrorHandler Server
Event Category: None
Event ID: 34323
Date: 26.12.2009
Time: 11:10:31
User: N/A
Computer: %servername%
Description:
Update to catalog file C:\Program Files\Symantec\Backup Exec\Catalogs\%servername%\{01F7A24D-8B4B-4F36-9FDD-E627C9FE7575}_1.fh failed.
Reason: There is not enough space on the disk.
r:\corsica\2213r\becat\beplugins\commonfh\fhbuilder.cpp(772)

For more information, click the following link:
eventlookup.veritas.com/eventlookup/EventLookup...

Вот оно! Проблема была действительно на стадии каталогизации, потому что новосозданный каталог просто не мог записаться на диск, места не хватало. Окинув взглядом папку каталогов, понял, что ее жизненно необходимо убрать с системного раздела. Перенес на другой раздел, перезапустил службы, и заставил Backup Exec перестроить каталоги по описанному выше по ссылке методу. Итогом стало то, что все бекапы, которые были сняты за период сбоев, стали доступны. Что и требовалось.

Мораль истории - даже если приложение ведет достаточно подробные логи само по себе, забывать о логах ОС не рекомендуется. Иногда они все же информативнее.
Надеюсь, эта запись поможет людям, обслуживающим Symantec Backup Exec, сберечь много нервных клеток.

@музыка: Uttara - Winter Dance

---

WSUS and SQL Server

Во время развертываения WSUS на сервере в филиале случилось странное - установщик выдал ошибку о невозможности продолжения и послал изучать логи. В логах обнаружилось следующее:
Error 0x80070643: Fatal error during installation
Такая ошибка обычно говорит о том, что у пользователя, выполняющего установку WSUS нет необходимых прав в базе данных, в которую WSUS будет складывать все сведения. Решение довольно простое - добавить этому пользователю роль в базе SysAdmin и повторить установку. Не тут-то было, не помогло.
При повторной установке выянсяется, что, действительно, падение происходит на стадии Configuring Databasе, стало быть, нужно смотреть и логи SQL Express. Читаю и нахожу фееричное - невозможно создать файл базы, так как он уже есть, и он используется. Стереть файл базы так просто не получится, потому что его всегда использует служба сервера баз данных SQL Server. Но можно отключить службу, тогда файл будет освобожден. Проверка состояния службы показала, что последняя действительно запущена. Для верности решаю сделать еще одну чистую установку, только на этот раз не запуская службу. Все устанавливается с пол-пинка.
Сижу, хихикаю, и много думаю... Получается, что в процессе установки WSUS сам запускает службу базы данных, но тогда как быть с тем случаем, если используется не SQL Express, как у меня, а большой SQL, службу которого просто так не остановить...

@темы: WSUS

---

Ghosts

Привидения. Фантомы, оставшиеся от когда-то существовавших объектов. Подчас их искать довольно утомительно, зато интересно.
Суть ситуации в следующем. При попытке отправки приглашения на встречу через Outlook отправителю приходит уведомление, что данное приглашение не может быть доставлено одному адресату. Вся соль ситуации в том, что этого адресата никто не указывал. Если объяснить на пальцах, то получится, что приглашение было направлено людям A, B, C, D, а не получил приглашение человек Е. Дополнительный разбор полетов (просмотр логов Exchange) показывает, что вместе с основным письмом было направлено еще одно, как раз тому самому Е. Но ни одного следа этого дополнительного письма в ящике отправителя. Забавно, правда? А самое смешное, что учетной записи, куда отсылается второе письмо, уже нет в AD, и само письмо почему-то отправляется не по SMTP-адресу, а по протоколу X400.
Вроде и забавно, но когда с этим сталкивается человек из руководства, становится не до смеха. Это проблема, и ее надо решать.
На первый взгляд все банально - где-то стоит перенаправление. Стоять оно может в следующих местах:
1. Безусловное перенаправление всей почты человека в учетной записи AD
2. Перенаправление писем посредством правила Outlook.
3. Назначение представителей.

Первым делом была проверена учетная запись в AD - все чисто. В представителях тоже ничего не значится. Остается проверка правил Outlook. Заход к пользователю и просмотр правил также ничего не дал - все пусто. В чем же дело?
Ковыряние гугля в первые два дня ничего не дало, но потом все же сообразил, что запрос можно поставить иначе. Вторая же ссылка привела к нужному результату. Все дело в представителях. У Outlook есть особенность, заключающаяся в том, что он не всегда корректно отображает список представителей, даже после того, как они были удалены. В итоге проблема решается следующим образом: через AD назначается представитель, после чего открывается Outlook и уже в нем этот представитель удаляется. Это приводит к полному обновлению информации о представителях в AD и в Outlook, после чего письма привидениям исчезают, равно как и сами привидения.

@музыка: En Voice - Hall of Dreams

@темы: MS Exchange

---

Exchange 2007 CAS

Вчерашний день был из разряда "Срыв покровов". Обсуждалось расположение серверов Exchange 2007 в сети, кто и в каком сегменте сети будет стоять. В голове прочно сидит положение о том, что сервер переднего плана располагается в DMZ. Копаю материалы по установке Client Access Server, который заменяет собой сервер переднего плана. После захода по ссылке: technet.microsoft.com/en-us/library/bb232184.as... волосы встали дыбом. Да и не только у меня. Ключевым моментом статьи было следующее:

Installation of a Client Access server in a perimeter network is not supported. The Client Access server must be a member of an Active Directory directory service domain, and the Client Access server machine account must be a member of the Exchange Servers Active Directory security group. This security group has read and write access to all Exchange servers within your organization. Communications between the Client Access server and the Mailbox servers within the organization occurs over RPC. It is because of these requirements that installing a Client Access server in a perimeter network is not supported.

Проще говоря, в плане установки CAS DMZ теперь в прошлом, подобная организация сети поддерживаться самим МС не будет. А при PSS звонке первое, что будут рекомендовать - перевести CAS в доверенную сеть. Причиной тому работа CAS с серверами почтовых ящиков через RPC, динамические порты с номерами выше 1024. Так что, лучше этот момент учитывать до того, как организация на базе платформы 2007 будет развернута.

@музыка: стук клавиш

@настроение: рабочее

@темы: MS Exchange

---

Windows 2008 Server RODC

RODC - Контроллер домена в режиме "Только для чтения". Новый режим работы КД, появившийся в Windows 2008. Предназначен для установки в филиалы, где нет достаточного уровня безопасности хоста контроллера (читай, самого компьютера). Этот режим выгоден тем, что не хранит на себе пароли пользователей, за исключением специально выбранных - как правило, работников того самого филиала. Чем выгодно? В самом паскудном сценарии - краже хоста (и такое бывает), нужно будет сбросить пароли только тех учетных записей, пароли которых кэшированы на этом контроллере, а не всего домена. Удобно? Удобно.
Еще одно преимущество работы контроллера в таком режиме кроется в самом его названии - Только для чтения. Это значит, что никакие операции над структурой домена с этого контроллера невозможны, он способен только читать информацию, но не изменять ее. Случайное удаление каталогов, атрибутов в этом случае исключается. Опять же - удобно? Да.
Однако, как и довольно часто, при установке такого контроллера есть свои нюансы. Про режим работы леса в целом и отдельных его доменов я говорить не буду. Это расписано в документации по RODC достаточно подробно.
Первый и главный момент - в домене уже должен быть полный КД уровня Windows 2008 Server. Полный - это значит способный записывать информацию в Active Directory. RODC в процессе своей работы будет общаться именно с таким контроллером, на КД предыдущих версий он даже не посмотрит. Если устанавливается новый домен на базе Windows 2008 Server - это требование будет выполнено автоматически. В случае же перехода с КД Windows 2003 Server этот момент нужно учитывать.
Второй момент - перед установкой RODC ко всему лесу нужно применить команду adprep /rodcprep. Эта команда расширяет текущую структуру каталога, добавляя в нее элементы, обеспечивающие репликацию данных с обычного контроллера на RODC. Если этого не выполнить, в процессе установки будет выдана ошибка следующего содержания:

You will not be able to install a read-only DC in this domain because "adprep /rodcprep" was not yet run.

Информативность текста ошибки стопроцентная. Что делать - ясно без подсказок.
И вот тут-то кроется главный подводный камень, рассчитанный на тех, кто переходит с домена 2003 на домен 2008. Для того, чтобы установить RODC в смешанной среде (где есть и КД 2003, и КД 2008), просто выполнить adprep /rodcprep недостаточно. После ее выполнения вы будете снова натыкаться на приведенную ошибку. В документации по RODC описания подобной проблемы мне найти не удалось, решение откопалось на одном из блогов - Клац!
Интерес на этой странице представляет следующий комментарий:
Just adding a Windows Server 2008 DC to the domain doesn’t mean that you can install RODC in it too – actually you can and that’s when you will experience problems. You have to make sure that the Windows Server 2008 DC is configured (and is really functioning) as a GC and the PDC master role has been transferred to it.
Если это перевести на русский язык, то получаем следующее: простой установки КД 2008 в текущую среду недостаточно. Для получения возможности установки RODC в текущий домен на контроллер домена под управлением Windows 2008 Server нужно передать роль Глобального Каталога (GC) и роль эмулятора первичного контроллера домена (PDC Emulator). Только в этом случае установщик RODC опознает текущий домен, как удовлетворяющий всем требованиям, и согласится на установку RODC.
Как всегда - все дело в волшебных пузырьках одной волшебной галочке. Но нужно знать, где ее искать. Надеюсь, кому-то эта информация позволит сэкономить свое время на поиск решения проблемы.

@музыка: Sleepthief - World Gone Crazy

@темы: Security

---

Море между городами - по колено, океан между континентами - по пояс.

Любопытная история. Как всегда - разбор полетов письма, почему не доходит до адресата. Все началось с получения отбойника вот такого вида:
**********************************************
** THIS IS A WARNING MESSAGE ONLY **
** YOU DO NOT NEED TO RESEND YOUR MESSAGE **
**********************************************
В общем-то, все просто и понятно. Письмо задержано, повторная попытка его доставить все таки будет. Проблема в том, что письмо срочное. Выискиваем номер телефона компании, в которую это письмо улетело, и начинаем выцарапывать информацию.
Приятный женский голос в трубке сказал, что по проблеме вряд ли что сказать сможет, ибо не в курсе, но может переключить на специалиста. Ну что же, спасибо, подожду. Разговор со специалистам позабавил. Суть в том, что письмо ушло на ящик [email protected]. На что с той стороны после минутного раздумья (видимо тоже у кого-то справлялся человек, что и как) был задан вопрос: А откуда вы узнали о существовании этого адреса?
Опа! Вот что б я еще знал, откуда наш сотрудник его узнал. На том конце меня просвещают, что все электронные адреса компании имеют вид [email protected], так что можно продублировать письмо, и оно должно дойти до места назначения. Благодарность за информацию и вежливое прощание. Стороны беседой удовлетворены.
А дальше - дальше трубку к уху и вызванивать сотрудника, где и как на адрес в RU домене напали. Ответ порадовал. Девушка на телефоне в той компании, куда письмо летит до сих пор, сообщила, что можно прислать информацию на адрес %login%. А на уточнение по поводу полного адреса был получен ответ вида: "ну %login%, а после собачки - как всегда". Поскольку звонили по России, легко предположить, что и адреса будут российские. Вот и полетело письмо "на деревню дедушке Константин Макарычу".
Люди, когда диктуете кому-то электронный адрес - диктуйте его полностью. Всегда. Это может сократить кучу времени и нервов в дальнейшем.

@темы: Этот безумный мир, MS Exchange

---

IE Error

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

И это при том, что буквально день назад ему был установлена совершенно свежая машина. В логах системы все чисто, ошибок больше никаких. Сеть работает нормально, все ключи на месте. Вопрос - что бы это могло быть...
Быстрое гугление результатов почти не дает. Почти, потому что все сходятся в одном, это ошибка исключительно IE, и после такого его надо переустанавливать. Переустановка! Спрашиваю, КОГДА это начало происходить? Ответ обнадежил - во второй половине сегодняшнего дня. В этот же момент взлядом выхватываю желтенький щит в панели задач. Во второй половине дня проходит установка обновлений через WSUS. А щит говорит о том, что обновления установились, но требуют перезагрузки (на что пользователи практически всегда забивают, что плохо). Перезапускаем систему, вижу, что IE обновился до следующей версии, после чего все исправно заработало.
Вывод из истории - если система говорит о том, что ей надо перезапуститься, лучше предоставить ей эту возможность.

@темы: WSUS

---

Limits.

And I push her to the limit
to see if she will break.
---
(c) Pink Floyd - Take it Back

Согласно политике почта сотрудников, покинувших компанию, не удаляется. Она перемещается из оперативной базы данных в специально выделенную, это снижает нагрузку на сервер. Лимитов на почтовые ящики нет. Пока нет, скоро будут, ибо размеры оперативной базы лично меня уже пугают. Буквально вчера перемещал хороший такой ящичек на 4 Гб весом, смотрю, какие папки перемещаются, сколько писем в них. 19 с плюсом тысяч сообщений, 6 тысяч из них находятся в папке Удаленные. Хочется сказать матерно, но сдержусь. Больше всего повеселил тот факт, что последней была перемещена папка "Важное", в которой находилось всего 14 писем. 14. важных. писем. Из более чем 19 тысяч. Получается, что вся остальная масса сообщений - есть ненужный балласт. Полагаю, после такого есть, над чем подумать.
Люди, пожалуйста, если у вас нет ограничений на размер почтового ящика на работе - не стоит хранить в нем переписку буквально за все время вашей работы. Пожалейте ваших админов, пожалейте ваши серверы, пусть даже вы их никогда не видите, и они железные. Чем больше база писем, тем она медленнее и неповоротливее. Тем хуже она будет проходить резервирование, и тем больше шансы на то, что в случае краха восстановить ДЕЙСТВИТЕЛЬНО важные письма не удастся. Пожалуйста, подумайте над этим.

@темы: Этот безумный мир, MS Exchange

---

Есть компьютеры...

... а есть люди.
Хорошая статья на эту тему - Клац!. Рекомендуется к ознакомлению и осмыслению.

@музыка: Aion OST - Attack the Unsion

---

Mailflow

Слежение за тем, как ходит почта от одного адресата к другому - занятие весьма интересное. Интерес там представляют ошибки, если таковые имеются. Совсем недавно пришлось разбираться с уникальным случаем в моей практике.
Ситуация: звонок сотрудника А с сообщением о проблеме: его письма доходят до стороннего человека Б. Но когда Б нажимает кнопку "ответить" и отправляет ответ, письмо уходит в ящик сотрудника В, о котором Б не имеет никакого понятия.
Вот такая вводная, дальше идет собственно разбор полетов.
Первое - ключевыми словами здесь для меня явились Б нажимает кнопку "ответить", это действительно важно. Те, кто использовал в своей практике почтовик The Bat, и помнят, как там настраиваются учетные записи почты, меня поймут. Для непосвещенных объясню. В The Bat можно менять значение поля Reply-to. Это поле содержит в себе тот адрес, на который будут отсылаться ответы на пришедшее письмо. Если объяснять на пальцах, получится следующее:
Вы настраиваете учетку на работу с адресом [email protected], это ваш основной адрес. В поле Reply-to ставите другой: [email protected]. Все. Ответы на все письма (именно ответы), будут идти к вам на адрес [email protected], в то время как в поле From будет светиться по-прежнему [email protected].
Навскидку я не смогу придумать примеров использования этой схемы, но если ее реализовали, стало быть кому-то это было нужно.
Второе - по уверению сотрудника А, человек Б использует веб-интерфейс Яндекса.
Третье - у нас на предприятии The Bat не используется, стало быть поле Reply-to можно списывать со счетов, тем более, что по-умолчанию оно содержит в себе основной адрес, а я не помню, чтобы хоть для кого-то когда-то его меняли специально.
Четвертое - после проверки учетной записи А выяснилось, что никаких пересылок, перенаправлений и тому подобного добра не установлено. Почта ДОЛЖНА приходить в почтовый ящик А.

Что ж, проводим следственный эксперимент. Отсылаю тестовое письмо с ящика А на свой собственный, расположенный на стороннем сервере. Письмо приходит. Давлю кнопку "ответить", вбиваю "Тест" в тело сообщения, жму "Отправить". Письмо падает в ящик А, как ему и положено. Уведомляю сотрудника, что с его учетной записью все в порядке, и он может спокойно отсылать почту. А сам думаю, ЧТО было не так.
Для того, чтобы письмо попало в какой-либо ящик вообще, необходимо, чтобы в этом письме было хоть одно упоминание адреса, куда это письмо доставить надо. В тексте письма нигде ящик В не встречался, но ведь текст - это еще далеко не все.
Опять же - спасибо почтовику The Bat и его полезнейшей функции Исходное Сообщение. Знаем, помним, любим. Благо, мой сторонний ящик поддерживает эту возможность - открываю код сообщения и в поиск вбиваю адрес ящика В. Нашелся. Угадайте, где. В ПОДПИСИ СОТРУДНИКА А!
В подписи по стандарту компании указывается электронный адрес каждого сотрудника. Обычно это ссылка почтового стандарта mailto:. Как правило пользователи не в курсе, что ссылка состоит из двух частей - текста ссылки и цели ссылки. В нашем случае текстом в подписи был прописан ящик А, а целью был ящик В. После того, как это было замечено в коде письма, все стало ясно.
Вот честно, я бы очень, ОЧЕНЬ хотел посмотреть на человека Б, который утверждал, что отсылал ответ на письмо А, используя функцию "Ответить". НЕ ИСПОЛЬЗОВАЛ ОН ЕЕ, ни разу. Он тупо клацал мышкой на ссылке в конце письма от А, а ссылка, как выяснилось, была битой.
И второй вопрос - кто и как настраивал распроклятую подпись у сотрудника А? Этого узнать, к сожалению, не удалось, хотя обычно сотрудники сами себе подписи ваяют...

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

@музыка: Rian Farish - Breakthrough

@темы: Этот безумный мир, MS Exchange

---

PsExec

Программа PsExec является частью пакета PSTools, разработанного компанией SysInternals. Представляет собой утилитку, которая способна запускать произвольные процессы на удаленной системе, чем и полюбилась системным администраторам. Ее удобство может превзойти разве что ssh протокол. Но есть и несколько подводных камней, одним из которых является вот такая ошибка:

Error establishing communication with PsExec service on XXX:
All pipe instances are busy.

Меня эти слова преследовали полтора года. Самое удивительное, что утилита процесс на удаленной машине запускает, но результат выполнения получить не может. А чаще всего именно результат и важен. Ковыряние интернета и гугля выдало одну из возможных причин: блокирование данной программы антивирусными средствами. В целях проверки истинности предположения антивирус на целевом компьютере был снесен, после чего была выполнена чуть ли не классическая команда:
psexec \\xxxx ipconfig

Результатом стали все те же строки об ошибке. Что за дьявольщина? Затем вспомнилось, что многие антивирусы считают практически весь набор PsTools зараженным вирусом вида Remote Admin. Вирусов там нет, но сами программы как раз и являются средствами удаленного администрирования. Дальше взгляд упал на красную букву K в системном трее на исходном компьютере, после чего файл psexec.exe был внесен в список доверенных. Ошибка исчезла.

Полтора года со мной был касперский. Полтора года он меня защищал от всякой напасти. Надо сказать, хорошо защищал )

@музыка: Runestone - The Well of Secrets

@темы: Security