File System Audit

Наверняка каждый системный администратор сталкивался с задачей - вынуть да положить руководству на стол информацию о том, кто стер какой-либо очень нужный файл с сетевого хранилища. Почти все знают, как включить аудит событий файловой системы. Если кто-то не знает, очень рекомендую ознакомиться вот с этой статьей: How do I enable auditing on certain files/directories? - это очень просто и быстро.
После включения аудита в логе безопасности файлового сервера станут появляться события о работе с файловой системой. Вот как, например, выглядит запись о запросе на удаление какого-либо файла:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          10.08.2011 15:54:17
Event ID:      4663
Task Category: File System
Level:         Information
Keywords:      Audit Success
User:          N/A
Computer:      fs-01.test.local
Description:
An attempt was made to access an object.

Subject:
	Security ID:		TEST\user01
	Account Name:		user01
	Account Domain:		TEST
	Logon ID:		0x2aca0e

Object:
	Object Server:	Security
	Object Type:	File
	Object Name:	E:\Share\Тест.txt
	Handle ID:	0x8c0

Process Information:
	Process ID:	0x4
	Process Name:	

Access Request Information:
	Accesses:	DELETE
			
	Access Mask:	0x10000

В этом сообщении видно все, что нам нужно для отчета. Единственная проблема заключается в том, что в логе безопасности сообщений будет огромное количество. И среди всего этого вороха данных нам нужно будет как-то отыскать нужную информацию. Известно, что все логи сервера - это файлы, значит, нужно каким-то образом в автоматическом режиме прочитать файл лога, вытащить оттуда записи согласно определенным критериям, и этот комплект записей выложить на стол руководству. Осталось лишь найти инструмент, которым можно этого добиться. Он есть, называется LogParser, взять можно вот здесь: LogParser @ Microsoft.com.
Инструмент этот относится к разряду CLI-утилит - вся работа осуществляется при помощи командной строки. В разборе того, что и куда вводить, чтобы прочитать нужные данные, мне очень сильно помогла вот эта страница: Log Parser - The "Swiss Army Knife" for Intrusion Investigators and Computer Forensics Examiners. По прочтению и пониманию материала был сформирован следующий ярлык вызова утилиты:

"c:\Program Files\Log Parser 2.2\logparser.exe" file:c:\DeleteEvents.sql?source=Security -o:DATAGRID

А в качестве содержимого файла запроса DeleteEvents.sql используется следующее:

SELECT
      timegenerated,
      EXTRACT_TOKEN(Strings,1,'|') AS User,
      EXTRACT_TOKEN(Strings,2,'|') AS UserDomain,
      EXTRACT_TOKEN(Strings,6,'|') AS Object,
      EXTRACT_TOKEN(Strings,9,'|') AS LocalAccessMask,
      EXTRACT_TOKEN(Strings,10,'|') AS RemoteAccessMask,
      EventID
FROM %Source%
WHERE Object LIKE '%Share%' AND (EventID='4656' or EventID='4663') AND (LocalAccessMask='0x10000' or RemoteAccessMask='0x10000')
ORDER BY timegenerated

Да, это самый обычный SQL запрос. Допустим, меня очень сильно интересовало, какой нехороший человек стер мой любимый файлик, называвшийся "тест.txt". Вводим запрос, нажимаем Enter, и в ответ получаем красивую табличку вот такого вида:

Откуда видим, что нахала, стершего файл, зовут user01, принадлежит он к домену TEST. И файл был стерт сегодня. Что ж, задача выполнена, мерзавец найден. Дальше уже пусть руководство разбирается, что с user01 делать и какие санкции к нему применять.

P.S. Все вышеописанное справедливо для Windows 2008 Server. В версии 2003 формат записей в логе безопасности был иным, поэтому файл sql запроса скорее всего нужно будет серьезно менять.
P.P.S. Небольшая хохма на десерт. Существуют платные решения из сферы аудита, одно из таких я сегодня захотел попробовать: sсript Logic File System Audit. Как всегда при запросе пробной версии нужно заполнить простыню. Ок, давайте, посмотрим, что и куда писать надо. Вот кусок этой простыни:

Ничего более подходящего, чем Вооруженные силы Европы я там не нашел. А что, хорошая страна ведь

P.P.P.S. Окинул запись взглядом анонимного пользователя - ГРАФИЧЕСКИЕ СМАЙЛЫ! УБЕЙТЕ СЕБЯ О СТЕНУ В КРОВАВЫЕ ОШМЕТКИ!!!

@музыка: KOTO - Die Klapperschlange

@темы: Security

---

PCI DSS

Original @ ServerFault.com.
Перевод истории на Хабрахабре.
Читать всем, даже если вы не имеете никакого отношения к аудиту платежных систем и процессинговых центров. Это феерия.

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

---

Oneliners #3 - Перенаправление писем

Захотелось посмотреть, а у кого и куда стоит перенаправление почтовых писем в AD. И заодно подсчитать количество таких записей. Компоненты этого скрипта известны - get-qaduser, конвейеры, оператор вывода write-host. Основная сложность в том, что ключевой параметр altrecipient, в котором и хранится информация о цели перенаправления почты, в конвейер просто так не выводится, на выходе получаем пустые значения. Немного поковырявшись в справке по командлету get-qaduser находим ключ -IncludeAllProperties. Данный параметр заставляет команду get-qaduser выбрать из AD всю информацию о пользователе, по-умолчанию этого не происходит. Вторая сложность - по конвейеру нельзя передать конструкцию вида $_.altrecipient оператору write-host. Следовательно, приходится сначала упаковывать требуемые нам значения в переменные, а потом через write-host выводить на экран значения этих переменных. Одновременно в цикле можем подсчитать, сколько таких пользователей нашлось.
Суммируя всю эту информацию, скрипт принимает следующий вид:
get-qaduser -includeallproperties -oa @{altrecipient='*'} | %{$name = $_.name;$alt=$_.altrecipient;$i=$i+1;write-host $name" -> "$alt};write-host $i;$i=0

@музыка: Faun - Iduna

@темы: PowerShell, MS Exchange

---

Orphan Virtual Machines

Если в нескольких словах - понедельник вышел жестким.
Вводная - прийти на работу, зная, что висит одна из виртуальных машин (несчастный линукс на CentOS), на пинг не отзывается, бекап с нее, соответственно, не идет. Рестарт и можно спокойно разбираться, что не так. Раньше, чем успел послать ей команду перезапуска М. произносит: "Странно, к коммуникатору не могу подцепиться..." (Коммуникатор = Office Communications Server).
- Да ну нафиг! не знаю ничего про коммуникатор, знаю только про зависшее "зеркало" (та самая виртуальная машина).
Открыть VI Client, окинуть взглядом список машин, убедиться, что все в статусе Running, перейти в консоль коммуникатора, и охренеть на месте:
Virtual machine config file does not exist
Так, стоп. Машина есть, она зарегистрирована, она запущена. Так как же? Тыкаюсь в то самое "зеркало" - перехожу на ее консоль, и получаю абсолютно то же сообщение. ОК, берем наугад третью машину, переключаемся в ее консоль, заранее зная, что получим в ответ. Остается последнее: выбрать хост esxi, перейти на вкладку конфигурации, щелкнуть Storage. Формально все на месте. Видна арена, два раздела. Нажать Rescan и подтвердить худшие опасения - СХД с виртуальными машинами не видна вообще.
Надо сказать - это финиш. Бегом в серверную, открыть дверь, и понять, что же на самом деле не так. А все банально - в серверной жарковато.
Чуть позже подтянулись еще люди, от которых и узнали мы, что в воскресенье тут в очередной раз возникла нештатная ситуация с системой охлаждения и с электропитанием. Последнее наши "железные кони" выдержали - UPSы вытянули их. А вот отсутствие охлаждения - это труба. СХД, державшая на себе весь "запас" виртуальных машин, не выдержала перегрева и "замкнулась в себе", перестав отвечать на любые запросы по любым интерфейсам. В том числе и по Fiber Channel.
Делать нечего. Рестарт СХД. Долгих несколько минут, после чего Rescan на хосте esxi. СХД послушно появилась на месте, хост снова увидел все нужные разделы. Поочередный рестарт всех виртуальных машин, и работа нормализована.
Дальнейшее уже не столь интересно - ревизия бекапов (на всякий случай), да просто огромные волны ненависти в адрес администрации бизнес-центра.

@музыка: Corvus Corax - Avanti, Najo Ratte

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

---

KVRT 11 в действии...

Нет слов. Просто нет.
История коротка - ноут, проверка на непрошенное зверье. Результаты ниже.
1. Лог задания:

2. Окончательный вердикт при попытке закрыть сам KVRT:

Вопрос - ГДЕ зараза?
Я все понимаю, денег хочется всем. Но мне это до боли напомнило принцип работы так называемых Fake-AV программ.

@музыка: Chrono Cross OST - Shadows and Forest

@темы: Viruses and Spam, Kaspersky Lab

---

Kaspersky Virus Removal Tool automatic download

UPDATE 19-07-2011:Тестирование скриптов на рабочей машине с установленной Windows XP показало, что сценарий очень плохо воспринимает пробелы, которые появляются в именах файлов при развертывании переменной %userprofile%. Выходом является заключение конструкции %userprofile%\filename.txt в кавычки. В тексте записи сценарии исправлены.

UPDATE 16-07-2011 #2: Учитывая, что на некоторых машинах наблюдались проблемы с запуском новой версии утилиты (см. здесь) - ниже выложен модифицированный скрипт для закачки старой, девятой версии KVRT (на сервере его инсталляторы лежат в отдельной папке) -

Download KVRT version 9.cmd

cls
@echo off

REM check if target KVRT folder exist
if not exist j: exit

REM writing commands to ftp sсript to get file names from site
echo open devbuilds.kaspersky-labs.com > "%userprofile%\getfilenames.txt"
echo cd devbuilds >> "%userprofile%\getfilenames.txt"
echo cd AVPTool >> "%userprofile%\getfilenames.txt"
echo cd avptool9 >> "%userprofile%\getfilenames.txt"
echo ls setup*.exe "%userprofile%\filelist.txt" >> "%userprofile%\getfilenames.txt"
echo bye >> "%userprofile%\getfilenames.txt"

REM get file list from site
ftp -s:"%userprofile%\getfilenames.txt" -A

REM get newest KVRT file name
for /f "tokens=* delims= " %%a in ("%userprofile%\filelist.txt") do set kvrtname=%%a
echo Newest KVRT installer is: %kvrtname%

REM writing commands to ftp sсript to get newest KVRT file
echo open devbuilds.kaspersky-labs.com > "%userprofile%\download.txt"
echo cd devbuilds >> "%userprofile%\download.txt"
echo cd AVPTool >> "%userprofile%\download.txt"
echo cd avptool9 >> "%userprofile%\download.txt"
echo binary >> "%userprofile%\download.txt"
echo get %kvrtname% j:\Software\Kvrt\%kvrtname% >> "%userprofile%\download.txt"
echo bye >> "%userprofile%\download.txt"

REM Delete old files from local KVRT folder
del j:\Software\Kvrt\*.* /Q

REM get newest KVRT file from site
ftp -s:"%userprofile%\download.txt" -A

REM Clean up command and temp files
del "%userprofile%\getfilenames.txt"
del "%userprofile%\filelist.txt"
del "%userprofile%\download.txt"

UPDATE 16-07-2011: В связи с обновлением KVRT, введением формы загрузки и сменой структуры папок на сервере Kaspersky Lab пришлось немного модифицировать скрипт, чтобы вновь привести его в работоспособное состояние. Изменения выделены жирным шрифтом.

Оригинальная запись:
KVRT - весьма полезный инструмент, с которым довелось вылечить уже немало систем. И Винлоков, и простых файловых вирусов, и трояснов. Но есть у него один недостаток - он не умеет обновляться автоматом. Этот функционал в него специально не закладывался. Он не видит сети, не видит никаких других источников обновленных антивирусных баз, даже намека на кнопочку "обновить" нет. Это сугубо сканер-по-требованию.
Но тем не менее, обновлять его базы все же надо. Делается это выкачкой новой версии утилитки. Каждый раз открывать браузер, щелкать на закладку на ресурс devbuilds.kaspersky-labs.com/devbuilds/AVPTool/, затем подтверждать сохранение файла. Долгое время так и делал. Наконец, мне это надоело. Антивирус (пусть даже такой специфичный) все же должен обновляться регулярно, а не как бог на душу положит. Поэтому командную строку в зубы, гугль в помощь, и вперед.

Вводные данные: папка для сохранения новой версии утилиты - j:\software\kvrt (на флешке), утилита сохраняется под тем же именем, под каким лежит на сайте.
А теперь сам скрипт:

Download KVRT.cmd

cls
@echo off

REM check if target KVRT folder exist
if not exist j: exit

REM writing commands to ftp sсript to get file names from site
echo open devbuilds.kaspersky-labs.com > "%userprofile%\getfilenames.txt"
echo cd devbuilds >> "%userprofile%\getfilenames.txt"
echo cd AVPTool >> "%userprofile%\getfilenames.txt"
echo cd avptool11 >> "%userprofile%\getfilenames.txt"
echo ls setup*.exe "%userprofile%\filelist.txt" >> "%userprofile%\getfilenames.txt"
echo bye >> "%userprofile%\getfilenames.txt"

REM get file list from site
ftp -s:"%userprofile%\getfilenames.txt" -A

REM get newest KVRT file name
for /f "tokens=* delims= " %%a in ("%userprofile%\filelist.txt") do set kvrtname=%%a
echo Newest KVRT installer is: %kvrtname%

REM writing commands to ftp sсript to get newest KVRT file
echo open devbuilds.kaspersky-labs.com > "%userprofile%\download.txt"
echo cd devbuilds >> "%userprofile%\download.txt"
echo cd AVPTool >> "%userprofile%\download.txt"
echo cd avptool11 >> "%userprofile%\download.txt"
echo binary >> "%userprofile%\download.txt"
echo get %kvrtname% j:\Software\Kvrt\%kvrtname% >> "%userprofile%\download.txt"
echo bye >> "%userprofile%\download.txt"

REM Delete old files from local KVRT folder
del j:\Software\Kvrt\*.* /Q

REM get newest KVRT file from site
ftp -s:"%userprofile%\download.txt" -A

REM Clean up command and temp files
del "%userprofile%\getfilenames.txt"
del "%userprofile%\filelist.txt"
del "%userprofile%\download.txt"

Как всегда, скрипт требует маленькой доработки напильником. В нем нужно заменить тот самый каталог j:\software\kvrt на то, куда требуется загружать новую версию программы. И еще одно замечание - блок REM check if target KVRT folder exist. Его назначение - проверить, а существует ли тот самый целевой каталог. Если его нет (читать - нет флешки) - не выполнять ничего, так как бессмысленно. Существование каталога я проверяю на уровне самой флешки. Если она есть, значит есть и каталог.
Что можно сделать с этим скриптом? Варианты использования ограничены лишь фантазией. Лично у меня он прицеплен в Планировщик задач, запускается в момент захода моего пользователя в систему или каждый день в 8:30 утра (на случай, если компьютер проработал всю ночь).

запись создана: 04.12.2010 в 18:50

@музыка: Nobuo Uematsu - Beyond the Wasteland

@темы: Viruses and Spam, Scripting, Kaspersky Lab

---

UMRA - User Manager Resource Administrator

Программирование без goto - Клац!
Я не случайно начал эту запись со ссылки на один из холиваров мира программирования - стоит ли использовать оператор goto при построении кода? Сам стараюсь его не употреблять ни в каком виде, благо, средств проверки условий и переходов по результату проверки достаточно. Но не в этот раз.
Довелось сегодня править код формы в этом самом UMRA. Форма работала, но после перегруппировки каталогов Active Directory работоспособность резко упала до нуля Ожидаемый результат, который надо исправлять. Чем и занялся.
Итак, что представляет из себя редактор кода в этой консоли? Это достаточно прямолинейный список из заранее подготовленных команд, которые можно передать службе UmraSvc, и она уже будет их выполнять. Команд не так уж много, но и немало. Даже конструкция if... then... else поддерживается, которую я очень активно собирался использовать. Не тут-то было! Да, этот заранее заготовленный блок может проверять довольно много параметров (хотя и там нашлось, к чему придраться), но в качестве действий после проверки условия можно назначить только одно единственное! Угадайте, какое именно. Правильно - пресловутый goto!
Представить все это "великолепие" в виде псевдокода можно следующим образом:

variable1 = 5
if variable1 < 10 then goto label1 else goto label2
label1: action1
goto end
label2: action2
goto end
end:

И вот таким макаром проверять кучу условий. Повторюсь, в блоке then кроме тупого перехода к метке поставить ничего нельзя, вообще. Все дело в том, что код формы редактируется не в виде исходного кода как такового, где где угодно можно записать что угодно, а через самый что ни на есть GUI - отдельная формочка для ввода всех параметров блока if... then... else. Одним словом - такого кошмара я давно не встречал, если встречал где-то вообще.
Код этой несчастной формы в итоге был выправлен, но времени на отладку в итоге ушло куда больше, чем планировалось.
И на вкусное. Механизм проверки условий UMRA, как выяснилось, совершенно не может проверить какое-либо поле формы на непустое значение. На пустое - пожалуйста, можно выбрать тип проверки null or not present, но вот not null там не поставишь. Пришлось изгаляться с вариантом if var is null then end else blah-blah-blah. Тоже не добавило радости, если честно.

@музыка: Ryan Farish - Perfect Clarity

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

---

GFI EndPoint Security 4.3 Transition

Решил посмотреть, как будет себя вести при обновлении программный комплекс GFI EndPoint Security. Вполне возможно, что придется это сделать, обновившись с 3-й на четвертую версию. В принципе, все достаточно гладко, за исключением пары-тройки моментов:
1. При обновлении 4-я версия не терпит присутствия на сервере своей старшей сестры, требует ее снести. Следовательно, бекап конфигурации должен быть. На всякий случай (впрочем, он должен быть в любом случае).
2. Для установки обязательно наличие .NET Framework версии 2.
3. Самое занятное: после установки основная служба отказалась стартовать. В окне установщика висит сообщение о том, что установщик эту службу пытается запустить, в оснастке служб она значится, как неработающая. Пробуем "помочь" установщику, запустив службу руками. Минута ожидания, и ОС выводит свое стандартное сообщение о том, что служба стартовала, но затем благополучно завершила работу, так как "ей нечего делать". Помнится, когда я с таким сообщением впервые столкнулся, оно меня очень сильно позабавило, вот тут ее пример описан: www.gotdotnet.ru/blogs/GRP/2838/
Ладно, веселье весельем, а запустить ее нужно. Лезем в базу знаний компании GFI и находим там следующее:
GFI EventsManager service does not start - Клац!
The GFI EventsManager executables are digitally signed by default. When trying to start the service, the application must download the Certificate Revocation List to authenticate. If the download fails due to network connectivity or security reasons the service will fail to start by timing out.

Это уже интереснее. Выходит, что для старта службы программы EventsManager необходим доступ в Сеть. Да, на моем сервере доступа не было (ибо зачем?). И хоть EventsManager - это не EndPoint Security, решил проверить, сработает ли рекомендация для моего случая. После обеспечения доступа во всемирную паутину и повторного запуска установки EndPoint Security служба успешно стартовала, и GFI EndPoint Security 4.3 благополучно завершил установку.
Апгрейд клиентов же просто тривиален.

@музыка: Ryan Farish - Opus (2011)

@темы: Security

---

Очередной Winlock

Принесли пациента со следующим диагнозом:
Ваш компьютер заблокирован за просмотр. копирование и тиражирование видеоматериалов содержащих элементы педофилии и насилия над детьми. Для снятия блокировки Вам необходимо
оплатить штраф в размере 400 рублей на номер телефона XXXXXXXXXX В случае оплаты суммы равной штрафу либо превышающей ее на фискальном чеке терминала будет напечатан код разблокировки. Его нужно ввести в поле в нижней части окна и нажать кнопку «Разблокировать». После снятия блокировки Вы должны удалить все материалы содержащие элементы насилия и педофилии. Если в течение 12 часов штраф не будет оплачен, все данные на Вашем персональном компьютере будут безвозвратно удалены, а дело будет передано в суд для разбирательства по статье 242 ч. 1 УК РФ.
Перезагрузка или выключение компьютера приведет к незамедлительному удалению ВСЕХ данных, включая код операционной системы и BIOS, с невозможностью дальнейшего восстановления.

Качественный лок, к диспетчеру задач не подобраться (и как водится, работали под администраторской учеткой, куда ж без этого). Разбираем по складам.
Загрузка с BartPe с параллельным поиском о зловреде в сети. Нашлось много, в основном это мольбы о том, что код нужен прямо сейчас. Среди "волн вайна" (с) отыскивается полезная информация - тело вируса заседает в каталоге пользователя (если не администратор), или в профиле All users\Application Data (если админа пробили). Удалить оттуда. Параллельно вирус модифицирует userinit.exe, как в system32, так и в dllcache - этот уже изощреннее, ага. Ну и само собой, меняется параметр Shell в реестре, чтобы сразу после входа в систему вместо explorer.exe запускался зловред.
Но есть и одно НО! Поражаются не только копии файла userinit.exe, но и taskmgr.exe, так же и в system32, и в dllcache. На это уже наткнулись, когда запустили систему после, казалось бы, успешного лечения.
Суммарная информация:
Лечение в оффлайне.
1. Удаление тел вируса из папок профилей и каталога system32.
2. Копирование на пораженную машину неинфицированных файлов userinit.exe и taskmgr.exe в каталоги system32 и dllcache.
3. Исправление пути на оболочку среды, запускающуюся после входа в систему. Как это сделать: в окружении BartPe подцепить пораженный реестр: Клац, и выправить необходимые параметры - Клац!.
4. После успешной загрузки и входа в систему обязательно запустить от имени администратора команду sfc /scannow, чтобы проверить критичные файлы.
5. Обновить базы антивирусного ПО и провести полную проверку.
6 - last, but not the least - перейти на использование ограниченной учетной записи для повседневной работы. Чинить пораженный профиль значительно проще, чем пораженную систему в целом.

@музыка: Blackmore's Night - Storm

@темы: Viruses and Spam

---

TDSS

Все же довелось столкнуться со зловредом, обозначенным в заголовке. Если быть точным, то с его модификацией TDSS.d. Очередное подтверждение тому, что азиатские антивирусы в нашей стране не могут считаться достаточной защитой.
Интересна ситуация, из-за которой и возникло подозрение на инфицирование чем-либо. При работе в IE 8 очень часто стали появляться сообщения вида:
Из-за проблемы на веб-странице IE закрыл вкладку и открыл ее снова
и перезагрузкой ранее открытой странице в той же вкладке, где она и открыта. А известно, что после двух обнаружений проблем браузер просто закрывает такую страницу и выводит сообщение об ошибке. Проявлялось стабильно на всех открываемых сайтах. Что ж, KVRT в помощь.
Результат - TDSS.d обнаружен в активном виде. Пристрелен. Последующая проверка тем же KVRT и TDSSKiller показала, что пристрелен качественно, рецидивов нет. Хотя есть мысль еще пройти по машине GMER'ом. На всякий случай...

@музыка: Amethystium - Odyssey (2006 - Emblem)

@темы: Viruses and Spam

---

Script run time

Время выполнения скрипта. Весьма важный показатель производительности системы. Ни с того ни с сего некоторые сотрудники начали жаловаться, что при загрузке компьютера уж очень много времени уходит на стадию "Выполнение сценариев запуска". Сценариев этих вообще-то к компьютерам привязано довольно много, и тот факт, что нужное на их выполнение время исчисляется далеко не секундами, а их парой-тройкой десятков - это норма. Но не 10 минут же! К тому же 10 минут - это deadline для системы, по достижении которого она (система) просто прекратит обработку сценариев и продолжит загружаться. Нужно узнать, какой из скриптов тормозит процесс.
Есть два варианта. Первый применим в том случае, если в домене не включена параллельная обработка сценариев - каждый следующий скрипт будет запускаться только по окончании выполнения предыдущего (это настройка по-умолчанию). В этом случае можно просто открыть консоль GPMC, взять интересующую нас систему и собрать с нее результирующий набор политик. Дальше на вкладке с перечисленными параметрами, которые применяются к системе из политик, можно раскрыть раздел сценраиев запуска и просто посмотреть, когда в последний раз был запущен тот или иной скрипт. Учитывая, что запускаются они последовательно - можно сразу увидеть, где узкое место.
Второй метод может пригодиться там, где параллельная обработка сценариев уже включена (это ускоряет процесс загрузки, по понятным причинам). Но для этого придется каждый выполняемый сценарий немного изменить - повесить на него "рамку":

sсript run time

'set file system and shell objects
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set WshShell = CreateObject("Wscript.Shell")

'set output file name
strUserProfile = WshShell.ExpandEnvironmentStrings("%USERPROFILE%")
'strSystemRoot = WshShell.ExpandEnvironmentStrings("%SYSTEMROOT%")
strFileName = strUserProfile + "\SCRIPTNAME.txt"
'strFileName = strSystemRoot + "\SCRIPTNAME.txt"

Set objFile = objFSO.CreateTextFile(strFileName)
objFile.Writeline Now
objFile.Close

'sсript BODY GOES HERE

Set objFile = objFSO.OpenTextFile(strFileName, 8)
objFile.Writeline Now
objFile.Close

'delete all references
Set objFSO = nothing
Set WshShell = nothing
Set strUserProfile = nothing
Set strSystemRoot = nothing
Set objFile = nothing
Эта рамка выведет время выполнения сценария в текстовый файл. Его расположение задается в блоке set output file name - в профиле пользователя (если измеряем производительность скрипта входа пользователя), либо в папке %SystemRoot% - если интересует скрипт загрузки самого компьютера. Естественно, эти пути можно и поменять под свой вкус.
Блок sсript body понятен и без объяснений.
Можно, конечно, обойтись и простым выводом на экран, а не в файл. Однако, учитывая, что лично мне придется эти изменения вносить в боевые версии сценариев, лучше лишний раз пользователям не докучать и выполнять все действия в фоне.

@музыка: El DeBarge - Who's Johnny

@темы: Scripting

---

Windows 2008 x64 Conversion to VMWare

Windows 2008 - единственная из систем, к которой пришлось применять индивидуальный подход при ее переносе с гипервизора XenServer на VMWare. Суть в том, что при удаленном переносе при помощи VMWare Converter Standalone в режиме клиент-сервер этот самый конвертер не может найти дисков исходной системы. Нет дисков - нечего конвертировать. А посему получаем ошибку.
Что делать? Выход прост - установить конвертер прямо на исходную машину и конвертировать ее. В этом случае с дисками будет полный порядок. Веселости начинаются уже после этого.
Итак, исходная система превращена в виртуальную машину, потушена. Виртуалка поднимается, устанавливает все необходимые драйверы, инструменты... Новому сетевому адаптеру назначается старый IP-адрес, сервер видит компьютеры нашей сети, компьютеры способны найти этот сервер и по имени, и по старому IP - все счастливы. А через месяц я вижу, что Windows 2008 радостно сообщает следующее:
0xC004F00F
The Software Licensing Service reported that the hardware ID binding is beyond level of tolerance.

Приехали, система "потеряла" активацию, хотя это и неудивительно. Удивительно другое - почему она не поймала ее заново? Пытаюсь вручную сказать ей, откуда брать всю необходимую информацию:
Elevated Cmd,
slmgr.vbs -skms x.x.x.x
slmgr.vbs -ato
Не выходит каменный цветок, а судя по сообщениям, приходящим в ответ на эту команду, что-то случилось с сервером KMS, который не в моем ведении:
0xC004F039
The software Licensing Service reported that the computer could not be activated. The Key Management Service (KMS) is not enabled.

Звоню ребятам, обслуживающим этого зверя, докладываю о проблеме, на том конце обещают разобраться. Ну а пока система поживет в grace-period, уж за 60 дней всяко решим проблему, и это еще без учета slmgr.vbs -rearm.
Недавно все же решил еще покопать, что же пошло не так, тем более, что эксперимент по установке нового экзепляра Windows 2008 и активации оного прошел успешно. Следовательно, KMS работает исправно, и проблему надо искать на стороне того самого сервера.
Ipconfig /all, route print - на первый взгляд все нормально. Но ведь не все же. Еще раз для верности ввожу просто ipconfig, без ключа расширенного вывода информации... результат потряс: системе был назначен IP-адрес, была назначена маска подсети, а вот шлюз по-умолчанию - не задан вовсе.
Это что же получается, я, такая умная "маша", тупо забыл поставить шлюз? Вбиваю нужный адрес, после чего выполняю принудительную активацию (сервер активации ведь уже прописан), и система радостно говорит, что ключ найден, получен, установлен, в общем - все просто замечательно. Ладно, ошибся, с кем не бывает.
Настала пора переносить второй сервер, тоже под управлением Windows 2008, причем он довольно капризен, и если что-то пойдет не так - хлопот будет много. Все как и раньше, конвертер на машину, запуск, успешное преобразование, поднятие машины, установка драйверов, назначение старого IP. И двойная проверка шлюза, специально даже на бумажке записал. Рестарт системы и... И шлюза снова нет в списках адресов! Вот же мерзавка Понятное дело, что в этом случае OCS FE просто не запустится, так как не увидит пула серверов. Ладно, хоть знаем, почему так - прописываем шлюз, еще раз перезагружаем сервер, и после этого убеждаемся, что все службы работают, все необходимые данные по сети бегают, а активация уже в автоматическом режиме пройдена.
Больше всего в этой истории смутило то, что несмотря на отсутствие шлюза сервер видел все в пределах нашей сети. Сеть же другого региона была недоступной. Да, о таблице маршрутов и on-link все же стоит помнить.

@музыка: Within Temptation - See who I am

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

---

Exchange 2003 OWA и кириллические учетные данные.

Весьма любопытный случай.
Один из сотрудников жалуется на то, что из дома не может попасть на свой почтовый ящик - система просто не принимает его учетные данные. Провожу тест у себя, сбрасывая пароль на стандартный для таких случаев - все отлично срабатывает. Ну не иначе где-то ошибся человек.
Раз, второй, третий... Умом понимаю, что что-то не так. Ну не может человек настолько упорно набирать пароль неправильно. Тем не менее, проблема заглохла, больше звонков длительное время не поступало.
Недавно эта неприятность снова голову подняла, но уже с другим сотрудником. Этот поступил умнее, пришел в отдел лично. Лично набрал свой пароль на консоли администратора - не пускает. Прямо тут же меняем ему пароль на стандартный - все проходит на ура. Сотрудник меняет пароль на свой собственный - и тут же получает отлуп. Как так?! Посмеялись, потом начали размышлять, что и к чему. В глаза бросился тот факт, что тестовый пароль на английском языке, а сотрудник свой набирал на русском. И задавал его на русском. То есть мы пришли к тому, что OWA по какой-то ей ведомой причине не принимает национальные символы в пароле. Ладно, рекомендовали сотруднику использовать англоязычный пароль, а для себя пометили задачку в выполнению, но не как горящую.
Сегодня все же дошли руки до поднятия ручного Exchange 2003 SP2. Настраиваю OWA, меняю у тестового пользователя пароль на кириллический, жму Enter - и я в ящике этого пользователя. Все чудесатее и чудесатее (с).
Форумы молчат. Есть упоминания о том, что имеется проблема в случае кириллических логинов, но здесь другой случай. На яндекс в подобных вопросах уже давно не надеемся, гугл разводит руками. Полчаса вдумчивого сравнения конфигурации... Затем мысль - а что у нас с настройками регионов и кодовых таблиц. На самом деле региональные настройки не так важны, нам деньги не мерять. А вот кодовые таблицы - это уже любопытно. Оказалось, что на боевом сервере в настройках кодировок для non-Unicode приложений стоит английский язык, на тестовом же сервере - русский. Ну что же - смена на русский на боевом, перезагрузка... Долгие 3 минуты ожидания, смена пароля тестового доменного пользователя, заход на OWA... Success!!!
Exchange 2003 SP2 и настройки не-Юникод приложений - такого я представить себе не мог. Теперь представляю.
Еще одна поставленная галочка, еще один случай в копилку. Надеюсь, кому-то эта запись сэкономит немало времени в подобной ситуации.

UPD. Если конфигурация Exchange 2003 включает в себя два сервера, front-end и back-end, менять кодовую таблицу нужно на front-end-сервере.

@музыка: Rise Against - Help Is On The Way Shift 2 Remix

@настроение: Shocked

@темы: Security, MS Exchange

---

Storage switch

По идее, еще пара седых волос, но все же нет, не такая история, как памятный мне полет KVM.
Итак, дано. Есть файловый сервер, подключенный к СХД по SCSI. Есть другая СХД, подключенная к другому серверу по FC, на которую через DFSR реплицировано порядка 2 ТБ пользовательского контента (да, да, все сетевые диски и тому подобное). Цель всего этого проста - старую СХД проапгрейдить до FC.
День Х, час Ч и... момент переключения хранилищ. В файловик установлен FC HBA, сервер подключен на место дублирующего, запуск.
Тест устройств показывает, что адаптер найден и опознан, ОС поднимается без вопросов. Свойства системы, управление дисками - раздел уже готов к работе, все данные видны, все на месте. Ради полного успокоения души набираю в командной строке: \\SERVER-NAME\... и понимаю, что что-то явно пошло не так. Из порядка 15 общих ресурсов видны всего 5. Админсистративные и пара завязанных на DFSR. Что делать? Без общих папок будет очень и очень много воплей.
В голове проносится мысль о том, что когда-то мне доводилось смотреть на описание общих ресурсов изнутри, в реестре. Вспоминаю, что Windows хранит информацию о конфигурации всех служб за 3 последних удачных старта системы. Что ж, придется покопаться в старине (файловик не перезагружался довольно долгое время):
Regedit, HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\LanmanServer\Shares
Bingo! Описание всех общих ресурсов на месте. Дальнейшее тривиально - экспортировать весь этот куст реестра в файл, заменить там раздел ControlSet001 на CurrentControlSet, сохранить, применить файл, перезапустить сервер. После перезапуска все общие папки вновь доступны.
Возможные потери очевидны - доступ пропадет у тех людей, кому разрешения были прописаны уже после теперь уже предпоследнего запуска файловика. Таких людей немного, и это радует.
Мораль истории - делать резервные копии. В данном конкретном случае - экспортировать куст реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Shares во всеми подпапками (она будет одна). Эта нехитрая операция поможет избежать несколько неприятных нервных минут.

@музыка: Yanni - Vertigo

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

---

Citrix XenServer -> VMWare ESXi

Долго я ждал этого перехода. Наконец, все подготовлено. СХД есть, пусть это все та же Арена, а не что-то монструозное, вроде EMC, сервер в наличии (планируется два для обхода отказа одного хоста), дело за малым - миграция самих машин.
У VMWare есть специальное приложение, называемое VMware vCenter Converter Standalone. Хорошая вещь, но поначалу смутило то, что файлы виртуальных машин, сделанные в Citrix, ей не поддерживаются. Не беда, всегда есть опция Convert this powered-on machine. Забавно, вроде бы машина и виртуальная, но Converter будет трактовать ее как физическую. Для нас же разницы не будет никакой.
Итак, после разбирательств с этой утилитой вердикт следующий:
Перенос машины, основанной на XP SP3 - без проблем.
Перенос машины, основанной на 2003 - без проблем.
Перенос машины, работающей под Windows 2008 x64 - а вот тут веселье. Те же параметры, что при переносе предыдущих типов систем, при нажатии на кнопку Go приводят к появлению окна, в котором написано просто прекрасное: The specified parameter was not correct: ". Да, именно с кавычкой и точкой в конце.
Ну вашу же... И ведь это не первое апреля. Ладно, откат действий назад и подробнейший разбор конфигурации. На странице свойств жесткого диска понимаем, что конвертер этого диска не видит в принципе. Ясна и природа ошибки - переносить-то нечего.
Важная деталь - сама утилита в полном варианте установлена на моей рабочей машине, используется функция переноса удаленной загруженной машины. Как видим - не работает. Ковыряние базы знаний на сайте VMWare дает следующее - попробовать установить конвертер на той машине, которую переносим, и запустить процесс локального переноса. Утилита должна быть запущена с повышенными привелегиями (Run as administrator).
Делать нечего, придется засорять виртуалку лишним ПО (потом удалять). Рассудив, что серверный процесс уже имеется, и можно попробовать поставить только клиентскую часть конвертера, поступаю именно таким образом. Результат не заставил себя ждать - злосчастное окошко все так же мешает процессу. Приходится сносить конвертер вообще, ставить с нуля в полном виде. Дальнейшее - по иструкции - Run as..., выбор параметров, запуск. Да, в такой ситуации все работает. Вроде как еще может помощь отключение UAC, но этот вариант не стал проверять. Хотя, отключить этот функционал и включить его после перемещения - куда быстрее, чем ставить и удалять конвертер целиком... Стоит рассмотреть и этот вариант, но это уже после выходных.

@музыка: David Arkenstone - Ancient Legend

---

Игры с роботами...

Да, снова на сцене мой Ведроид (так я обозвал свой новый телефон) - Ведро для краткости. Поставил на него довольно полезных программ, теперь сижу, играюсь, оцениваю. Набор таков: Dropbox, ES File Explorer, Wyse PocketCloud.
Первая (Клац!) весьма известна в ITшных около-ITшных кругах. Ставим клиент, выделяем на каждом компьютере, где клиент установлен, какую-нибудь папку, и наслаждаемся результатом - эта папка будет синхронизирована между всеми узлами. В том числе и телефонами, если к учетной записи еще и телефон подключен.
Вторая - (Клац!) - файловый менеджер для Ведроидов. Поклонники WMP и его идеологии библиотек могут меня закидывать чем угодно, но лично я предпочитаю, чтобы медиафайлы хранились в организованно дереве папок, мне так удобнее. Теги, конечно, хорошая вещь, но древовидная структура себя изживет очень нескоро. Поскольку по-умолчанию владелец телефона не имеет доступа к файловой системе напрямую, приходится ставить сторонний софт.
Третья - (Клац!) - небольшой наборчик для подключения к удаленным хостам через протоколы VNC и RDP. Веселья было море, когда увидел собственный рабочий стол на мелком (для этих целей) экране телефона. Одно могу сказать точно - работать на пальцеориентированном устройстве в окружении Windows - не самое приятное занятие, но тем не менее - пусть будет. Мало ли, в какие ситуации доведется попасть.
Все три программы есть в Ведроид-маркете в бесплатных редакциях.

@темы: Этот веселый мир, Android

---

Android.

Да, я решил "узнать своего врага в лицо". Купил себе на пробу LG-P500, он же Optimus One.
Прошло уже больше года с того памятного мне дня, как я впервые столкнулся с этой платформой. Если уложиться в несколько слов - она обрела человеческое лицо. Как ни странно, теперь работать с телефонами на базе этой системы стало действительно удобно. Быстрые, функциональные, батарею сильно не кушающие...
Но не все так гладко, как может показаться на первый взгляд. И вот почему:
SMS are intermittently sent to wrong and seemingly random contact.
По ссылке очень много иноязычного текста, рекомендуется к ознакомлению всем обладателям андроидовых телефонов.

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

Я с этим столкнулся лично. Перерыв кучу материала и проведя несколько тестов пришел к следующему выводу - не отвечать на сообщения, используя область уведомлений. Схема работы этого бага следующая. Вы принимаете сообщение от человека А, читаете его, отвечаете или нет - неважно. Затем вы получаете сообщение от человека Б, при помощи области уведомлений отвечаете на него. Дальше вариантов два: либо сообщение уйдет человеку Б, и все довольны; либо аппарат подставит в качестве адресата того самого бедолагу А, от которого вы получили сообщение ранее, и оба участника получают конфуз.
Баг непостоянен, может проявиться, может нет, но во всех случаях подставлялся именно предыдущий абонент, приславший сообщение, не случайный.

На всякий случай, информация о телефоне:
LG-P500
ver. 2.2
Kernel 2.6.32.9
Build FRF91

На сегодняшний день все, что мы имеем по этому инциденту, это признание компанией Google проблемы и обещание выпуска заплатки в ближайшее время:
www.bbc.co.uk/russian/science/2011/01/110107_go...
Смотрим на дату новости - 8 января.

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

---

Localization is EVIL (part 2)

Продолжение истории, рассказанной вот тут.
Да, да, снова возня с сетевыми адресами, снова очень хочется обеспечить абсолютную прозрачность для пользователей. В предыдущей истории пришли к выводу, что psexec можно заставить понимать русский текст в названии сетевого соединения, но каждый раз набирать команды в окне DNTU - все же удручает. Вот если бы написать скрипт.
Размышляя над этой задачкой, вспомнил, что нечто подобное мне уже делать доводилось, нужно было написать сценарий для работы исключительно в DOS-окне, в котором русский текст воспринимался так же отвратно, как и в psexec. Вспомнил и метод решения этой задачи - скрипт был написан в редакторе AkelPad. Эта штука полезна тем, что кодировок знает неисчислимое множество, в том числе и пресловутый OEM 866 Russian, в которой и писался тот скрипт.
Стащить AkelPad из сети - дело нехитрое, набросать в нем заветные строки в нужной кодировке - тоже. Получаем вот такое:

netsh interface IP set dns "Подключение по локальной сети" static %PRIMARY-DNS% primary
netsh interface IP add dns "Подключение по локальной сети" %SECONDARY-DNS% index=2
netsh interface ip set address "Подключение по локальной сети" static %ADDRESS% %MASK% %GATEWAY% 1

А вот как это выглядит, если просматривать в том же Lister из Total Commander'a:

netsh interface IP set dns "Џ®¤Є«о祭ЁҐ Ї® «®Є «м­®© бҐвЁ" static %PRIMARY-DNS% primary
netsh interface IP add dns "Џ®¤Є«о祭ЁҐ Ї® «®Є «м­®© бҐвЁ" %SECONDARY-DNS% index=2
netsh interface ip set address "Џ®¤Є«о祭ЁҐ Ї® «®Є «м­®© бҐвЁ" static %ADDRESS% %MASK% %GATEWAY% 1

Да, мы видим все те же самые "кракозябы", которые уже совершенно спокойно будут восприняты программой psexec. Дело за малым - прописать в файле нужные параметры, сохранить, скопировать на удаленную систему, после чего:
psexec \\%TARGET-SYSTEM% -s c:\changeIP.cmd
(подразумеваем, что скрипт называется changeIP.cmd и скопирован в корень диска С

Кто-то может задать резонный вопрос - а почему не резервирование по DHCP, оно же куда проще? Абсолютно корректное замечание, и сетевому отделу было об этом сказано. Но... гремлинов среди гоблинов всегда хватает (с)

@музыка: Within Temptation - Faster

@настроение: А сайт и софт от MSI - все равно зло.

@темы: Scripting

---

Trend Micro Office Scan vs Symantec Backup Exec

Переезд серверов завершен, хоть и с потерями (сижу дома и болею), надо до конца разобраться с резервированием информации. На очереди задача подружить Symantec BE и Windows 2008-based контроллер домена. И все бы хорошо, два программных продукта узнали друг друга, пожали руки и сказали - будем дружить; но не тут то было. При попытке загнать в бекап состояние системы на контроллере получили ошибку:
V-79-57344-65245 - A failure occurred accessing the object list.

Ковыряние сайта поддержки Symantec дало любопытный результат в виде статьи об антивирусе Trend Micro - Клац!
Если пересказать сжато, то проблема возникает из-за очень специфичного объявления пути к файлу одной из служб антивируса:
"C:\Program Files\Trend Micro\OfficeScan Client\..\BM\TMBMSRV.exe" (в статье рассматривается другая версия тренда, но суть та же)

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

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

---

NLA - Network Layer Authentication

Признаться, когда только вышел SP3 для Windows XP, я не до конца понимал, что же это за опция такая. Полностью ее прелесть осознал только теперь, когда появилась возможность в спокойной обстановке поковырять веб-доступ до опубликованных на сервере терминалов приложений. Суть в следующем. При попытке запустить любое из приложений TS Web App, пользователь вынужден ввести свой логин и пароль, даже несмотря на то, что в системе он авторизова. А как мы помним, Active Directory на том и стоит, что пользователь, прошедший авторизацию уже должен иметь доступ ко всем ресурсам, на которые у него есть права. SSO - Single Sign-On - так зовется этот замечательный механизм. Повторный ввод пароля же обусловлен тем, что RDP клиент, который и используется при работе с TS Web App, SSO в Windows XP не поддерживает.
SP3 поменял расстановку сил, но даже установив этот пакет обновлений, просто так SSO не получить. Для этого нужно как раз включить ту самую опцию - NLA. Именно на сетевом уровне аутентификации Windows и будет передавать учетные данные.
Сам по себе процесс включения NLA довольно прост, нужно лишь изменить два параметра в реестре каждой системы, на которой будет использоваться веб-доступ к терминальным приложениям (а в идеале - для всех рабочих станций с Windows XP SP3). Очень подробно все это описано вот тут: MS Knowledge Base. При помощи групповых политик результат достигается очень быстро и просто.
Однако, не было бы этой записи, будь все так гладко. Убеждаюсь, что рабочие станции удовлетворяют требованиям для включения NLA - сделано (долго ли проверить две тестовые виртуальные машины). Требования там, кстати, следующие:
- наличие RDP-клиента версии 6 и выше (выполняется автоматически при установке SP3)
- наличие клиентских расширений групповых политик (без этого система не получит сведения о модификации реестра). Взять эти расширения можно здесь: MS Download Center.
Пробую запустить любое приложение. И получаю вот такое:

an authenication error has occured code 0x507

В то же время тестовая Windows 7 спокойно заходит на терминал, спокойно может запустить любое из опубликованных приложений. Значит, что-то не так с включением NLA. Пробегаюсь по политике и настройкам терминального сервера. В настройках сервера было указано следующее: Allow connections from computers running any version of Remote Desktop. Рассудив, что в тестовом домене все компьютеры теперь поддерживают NLA, устанавливаю следующее: Allow connections from computers running verision of Remote Desktop with NLA. Подтверждаем изменения.
В политике же ревизия показала следующее - по идее, в параметры Security Packages и SecurityProviders нужно дописать названия соответствующего пакета и библиотеки. Однако, политика старалась дописать в значение еще и то, что там было раньше. Неверно, так как может привести к дублированию информации. Устанавливаю действие "Заменить", а в значения прописываю все то, что там должно быть. Сохраняю изменения, даю команду двум машинкам с XP SP3 на обновление политик, после чего перезагружаю их.
После всех этих операций искомый результат был получен - пользователи компьютеров под управлением Windows XP SP3 получили возможность запускать терминальные приложения в режиме прозрачной аутентификации (привет клиентам Citrix и режиму pass-through ).
Ради интереса снова переключил терминальный сервер в режим разрешения подключений от любых клиентов Remote Desktop - все прекрасно работает.

@музыка: Ryan Farish - Shine

@темы: Security