Преамбула

Казалось бы — если система закрытая, то должны быть удобные инструменты? Ну, или хотя бы API для возможности написания этих удобных инструментов самостоятельно.

К сожалению, обычно все плохо: инструменты есть, но настолько неудобные, что от их наличия — никакого счастья. Приходится выкручиваться.

Итак, дано — система DocsVision (далее DV) версии 4.5 SR1. И, стоит задача переместить базу с одного сервера на другой (скажем, клиенты купили новый). Проблема, которая при этом возникает — ровно одна.

Права на объекты для локальных учетных записей при переносе базы на новое место превратятся в тыкву. А так как стандартные группы DV являются именно локальными — то проблем не избежать.

Кто заинтересован — прошу пожаловать под кат.

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

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

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

Некоторое время назад в компании была развернута терминальная ферма.
Первым делом в неё были выселены пользователи некой желтой программы.
После чего отдел поддержки желтой программы спросил меня, можно ли отсылать сообщения пользователям фермы всем сразу. XaocCPS посоветовал мне играться в сторону WPF. Нужный скрипт был написан, но его работой я неудовлетворился:
1. Надо ставить внешний компонент PowerShellPack.
2. Компонент ставиться на сервера фермы (х64) отказался.
3. Распространять такое решение из за пункта 1 всем желающим не очень удобно.

Xaegr подсказал что я могу избавиться от прослойки WPF.
Писать можно, можно даже писать красиво. Скрипт выполняется везде где есть .Net Framework — XP, Win7 и скорее всего пойдет даже на х64 серверах фермы.
Как писать — под катом.

UPD по просьбам скрипт выложен на SkyDrive, ссылка в конце

Проблема

Когда задача, требующая решения, небольшая, совсем не хочется писать для её решения отдельную утилиту, особенно, если ты — .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 мы дали им бой!