Все заморочки

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

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

У меня частенько возникает необходимость добавить несколько пользователей в AD. Если этих пользователей 2-3, то это можно сделать и через стандартную оснастку, но при необходимости добавить сотню другую учетных записей, лучше сделать это через Power Shell. В принципе, ничего военного нет, но запишу сюда, чтобы не терялось: 

Все же, странные люди эти пользователи. Вот, совсем недавно, кое-кто из этих самых пользователей пожаловался, что наша утилита для резервного копирования падает, если бекап стартует во время создания VSS (Volume Shadow Copy) копии. Это, вобщем-то, неудивительно, поскольку сия утилита тоже использует VSS для создания резервной копии нужных ей файлов. Странно другое...

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

Я достаточно часто использую консоль,  и всегда считал, что знаю все что нужно для эффективной работы с ней: жмешь Enter – команда выполняется, жмешь стрелку вверх/вниз получаешь предыдущую/следующую команду из истории, жмешь стрелку вправо — получаешь один символ из последней введенной команды, жмешь Tab – получаешь название следующей директории или файла. Вроде бы все? А вот и нет. Оказывается этот аскетичный черно-белый интерфейс командной строки умеет реагировать на куда большее количество клавиш. О них я и расскажу ниже.

Довелось мне недавно на какой-то богом забытой машине обновлять SharePoint 2010 Beta до RTM. И, как полагается, не обошлось без проблем. В общем, удалилось и установилось все без каких-либо неожиданностей, но, когда дело дошло до конфигурации, то мастер с завидным постоянством стал падать на третьем шаге вот с такой ошибкой:

  Казалось бы, что может быть проще, чем написать .bat файл? И действительно, ничего сложного — запомни три-четыре ключевых слова и вперед. Но, оказывается, даже нехитрый batch-синтаксис может преподнести свои сюрпризы. Лично я был слегка удивлен, увидев нечто подобное: 

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

Наверняка, любой тестировщик знает способы отслеживания изменений в файлах. Но, скорее всего, не каждый знает о том, как проследить за операциями чтения, при которых никаких изменений в файловой системе не происходит. Я, к своему стыду, до недавних пор тоже об этом не знал. Не знал ровно до того момента, пока у меня не возникло необходимости выяснить кто, когда, сколько раз и к каким файлам обращался. После обследования Resource Monitor'а, скачивания парочки бесполезных программ, попытки написания собственного скрипта и пяти минут отчаяния, выяснилось, что эта проблема прекрасно решается стандартными средствами. Впрочем, как всегда