PowerShell *

Предыстория

Началась вся история с того, что подошло время очередного IT аудита. Пришли серьезные дяденьки из Price Waterhouse Coopers, дали нам массу указаний и пару скриптов, которые надо было запустить на контроллере домена чтобы потом выслать им логи. После ознакомления с текстами скриптов (а мало-ли что там, безопасность превыше всего) логи были им предоставлены. И тут началось.

Предыстория

До недавнего времени я работал эникейщиком в крупной российской компании, имеющей множество офисов по всей стране. В моём ведении были одиннадцать площадок, находящихся в разных городах Дальнего востока (это важно). В каждом из этих офисов была своя, не связанная с другими, сетевая инфраструктура — свой домен AD, своя подсеть и т.д.

Однажды руководство поставило мне задачу организовать процесс автоматического обновления ОС и программ от MS и разрешило развернуть на подотчётных площадках WSUS.

Проблема

После того, как WSUS был развернут, политики привязки компьютеров к группам WSUS настроены, синхронизация каталогов содержимого с серверами MS проведена и т.п., возник вопрос: а кто же, и, главное, как, будет одобрять обновления?

Представьте себе: 11 городов, связь с которыми настолько «быстра» и «стабильна», что редкие минуты, когда задержки ICMP-ответов составляют всего 800 мс, воспринимаются, как неслыханное везение. И в каждом необходимо проводить тестирование всех обновлений перед развертыванием. При этом доступ к серверам на площадках был только по RDP, т.е. нужно было еженедельно (распоряжение устанавливало именно такую периодичность) подключаться к серверу каждого города и вручную одобрять использование новых обновлений в тестовых группах и, соответственно, переводить испытанные обновления в промышленную эксплуатацию:

Я думаю, многие сталкивались с задачей, когда к Вам приходят и спрашивают: «У нас тут файл пропал на общем ресурсе, был и не стало, похоже кто-то удалил, Вы можете проверить кто это сделал?» В лучшем случае вы говорите, что у вас нет времени, в худшем пытаетесь найти в логах упоминание данного файла. А уж когда включен файловый аудит на файловом сервере, логи там, мягко говоря «ну очень большие», и найти что-то там — нереально.
Вот и я, после очередного такого вопроса (ладно бекапы делаются несколько раз в день) и моего ответа, что: «Я не знаю кто это сделал, но файл я Вам восстановлю», решил, что меня это в корне не устраивает…

В передыдущей статье я опубликовал свой первый пост на хабре. В продолжении темы собрался написать вторую часть.

В комментариях к первой части я вскользь упомянул о том, что расширил функционал скриптов мониторинга за подключениями к серверам. В частности добавил уведомления в сервис мгновенных сообщений XMPP (Jabber), а так же запись лога в отдельный текстовый файл.

Начну серию публикаций по мониторингу Active Directory.
В данных статьях я приведу самые основные проблемы и пути их решения. На основе этих данных функционал легко расширяется до тех требований, которые Вам необходимы.
Учитывая, что сейчас для всех ОС, начиная с Windows Server 2003 R2 и Windows XP SP3 доступен Powershell. Думаю, что данная статья окажется полезным подспорьем, т.к. не требует от администратора введения никаких дополнительных средств, т.е. по сути – мониторинг штатными средствами.

Доброе время суток, Хабражители.

Данный пост повествует Вам о том, как с помощью PowerShell мы опять смогли немного облегчить нам жизнь и автоматизировать поиск оборудования и портов, на которых сидят компьютеры пользователей. Это необходимо в тот момент, когда надо пробросить vlan`ы (ну или просто для информации).
"

Вступление

Не так давно передо мной возникла задача рендерить из PowerShell скрипта различные HTML отчеты для дальнейшей отсылки по e-mail. Поиск готовых решений дал не очень много. Кто-то подключает Razor, кто-то свои самописные сложноватые велосипеды движки.
Скромный список требований был такой:

1. Код вьюх должен быть в отдельных файлах.
2. Внутри вьюх должна быть поддержка вложенности, и вставок кода на PowerShell.
3. Должен работать на любых хостах с PowerShell 2.0 без дополнительных настроек.

Так как ничего подобного не удалось найти, то был реализован простой (и одновременно мощный) движок рендеринга вьюх в стиле классического Asp.

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

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

На улице сейчас прекрасные солнечные дни, так что большую часть своего времени я стал проводить вне своего дома с широким каналом, а где-нибудь в парке с нетбуком и 4g модемом. Это несомненно лучше для моего здоровья, но, тем не менее, большие файлы скачивать все-таки хочется, так что пришлось искать варианты способов для организации доступа в мою домашнюю сеть извне. Замечу сразу, что мой провайдер выдает своим пользователям динамические белые IPv4 адреса (к счастью, при вводе в эксплуатацию IPv6 необходимость в такого рода извращениях автоматически пропадет).

Доброго времени суток, %habrauser%!
Недавно мне подкинули довольно простенькую на первый взгляд задачку: Надо перемешать около 1000 фотографий для системы голосований.
Вручную заниматься этим — дело неблагодарное. Нужен какой-нибудь миленький скрипт.
PowerShell оказался идеальным вариантом: ставить что-то стороннее вроде python не хотелось, а с .bat файлами я за свою жизнь так и не подружился.

Во многих проектах требуется инсталляционный скрипт либо пакет, который выполняет обновление серверной части приложения. Необходимость, в первую очередь, обусловлена отсутствием прямого доступа к производственному серверу у разработчиков.
Инсталлятор в виде скрипта лучше всего подходит для установки без явного входа на сервер (RDP). Также скрипт может быть выполнен в виде одного загрузчика, который и выполнит все остальное. В текущих проектах мы реализовали что-то наподобие PsGet^[1], только для внутреннего билд-сервера.
Приложение большое и состоит из ряда компонентов, одним из которых является модуль отчетности, построенный на базе SSRS.

Доброе время суток, хабраграждане!

Спешу с Вами поделиться одной из своих вещиц, которые были призваны облегчить работу мне, как системного администратора, который разбирается в, доставшимся ему по наследству, хламе в Active Directory.
Самые проблемные из доставшегося добра, по моему мнению, это группы. О них и пойдет речь в данной статье.
А именно: заходим в Active Directory, бороздим просторы подразделений и видим группы, совершенно с безликими названиями (например Ugin, Vassa, Opel, www etc) и без описания. Внимание вопрос: определите для чего нужны эти группы.

Проблема

Когда задача, требующая решения, небольшая, совсем не хочется писать для её решения отдельную утилиту, особенно, если ты — .NET-программист.
Скрипт? Однозначно, да, но ставить на боевую машину под управлением Windows сторонний интерпретатор совсем уж не по-христиански. Так почему бы не воспользоваться Windows Powershell? Готов сразу честно признаться: практически никакого опыта с ним не было, но уж больно заманчиво выглядел.
Скрипт, решающий задачу, был готов через 15 минут, если не учесть одно «но». Скриптом пока назвать это было сложно, потому что это был набор инструкций, непригодный для выполнения в виде скрипта. Непригодный, с точки зрения PowerShell.

В ходе деятельности любой организации, у нее возникают и исчезают временные союзники, она дружит и разрывает дружбу с партнерами, она реорганизуется, поглощает другие организации и наоборот, разделяется на несколько. С точки зрения ИТ часто возникает необходимость в создании общих ресурсов, доверительных отношений между лесами Active Directory, в налаживании vpn-туннелей сеть-сеть и прочих «объединительных» процедурах. Ниже я рассмотрю одну такую процедуру, копирование контактных сведений о пользователях чужого доверенного домена.

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

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



Ну что ж, ставим рядом два компа, устанавливаем на них Teamviewer’ские программулины – чтобы вживую сразу видеть, получается или нет.

Многие помнят то чувство, когда компания расширяется до тех размеров, когда рабочих групп недостаточно, и поднимается первый домен Active Directory: «О, уж теперь-то все будет как следует!» Ан нет, домен потихонечку разрастается, создаются новые учетки, блокируются старые, добавляются, удаляются компьютеры, девушки выходят замуж, меняют фамилии и, в конце концов, база данных службы каталогов выглядит, как полный швах. В этом топике мы наладим связь между базой Active Directory и кадровой системой предприятия, а также создадим механизм для поддержания данных сотрудников в AD в актуальном состоянии.

Мне нравится время от времени писать на PowerShell. В основном это задачи администрирования и развертывания. В этой заметке я хочу рассказать о решении одной интересной проблемы связанной с работой модуля WebAdministration. Итак, суть проблемы: при выполнении любого командлета из этого модуля возникает ошибка:

Cannot retrieve the dynamic parameters for the cmdlet.
Retrieving the COM class factory for component with CLSID {688EEEE5-6A7E-422F-B2E1-6AF00DC944A6} failed due to the following error: 80040154.


Всех приветствую.

Еще только в начале своего познания профессии системного администратора мой начальник поведал мне о такой профессии (вернее ее направлении) как дизайнер AD. Эти люди наводят порядок в домене и приводят в порядок учетные записи. Кто с этим сталкивался и возился может понять то раздражение, которое вызывают корявые имена учетных записей, созданных каким-нибудь сотрудником, который чихал на твой порядок.
Взяв в руки PowerShell мы дали им бой!

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

И так, было решено перекрасить окошко PowerShell в стандартный цвет cmd и параллельно настроить автозапуск собственных функций и алиасов. Так же, слегка, напрягало предложения ввода с надписью — PS, которое, совместно с цветом, напоминает лого Adobe Photoshop ( Ничего против Adobe не имею ).

Итак, информация следом исключительно для новичков.