We rise up for the things we believe in over and over again

Сделано. Решение "влоб" отменяется. MS XML оказался намного проще, чем я полагал все это время.
На вход - csv c полем Name (в нашем случае - ищется файл printers.csv в папке Документов текущего пользователя), где будут перечислены отображаемые имена принтеров. На выходе - заполненные политики по разливке этих принтеров пользователям на основе групп доступа. Принтеры будут расставляться членам групп с именами, равными названиям принтеров.
Политик две. Предполагается, что принтеры на первой площадке попадают в политику Map-Printers-01 и крутятся на принт-сервере ps1, принтеры второй площадки разливаются через политику Map-Printers-02 и сидят на сервере с названием ps2.
Если вдруг скрипт обнаружит, что для какого-то принтера не создана группа доступа, скажет об этом и пропустит принтер.
Если будет обнаружено, что в целевой политике уже есть запись для добавляемого принтера - будет предложено ее (или их, если их много - бывает и так) пересоздать. Если отказаться от этого - принтер будет пропущен.
И важный момент. Обе политики уже должны существовать, и в них должен быть заведен хотя бы один принтер. В противном случае в каталоге политики в SYSVOL будет отсутствовать файл Printers.xml, а создавать его политика не обучена (мне было лень).
Поехали!
:}
Кстати, идеи для расширения (правда, на примере WSH, поскольку я не знаю, как там у PoSH оно вызывается):
С передачей исходного файла все интересно. Этот скрипт для работы с политикой является четвертым в общей цепочке скриптов, которые все вместе решают одну довольно крупную задачу. Входными данными для него явлеется файл, сгенерированный самым первым из этой четверки. А он всегда генерится в одной и той же папке - документы пользователя, работающего со скриптами.
А вот с передачей исходных данных в первый скрипт - да, я думал над тем, чтобы передавать расположение входного файла через параметры. И даже сделал именно так. В итоге отказался, потому что меня задолбало каждый раз набирать имя этого файла. Поэтому исходный файл я тоже пришпилил к папке документов текущего пользователя. Сугубо из соображений удобства и скорости работы.
Передача аргументов при вызове скриптов в PSH выглядит так:
.\my-sсript.ps1 input.csv - тут мы вызываем скрипт с именем файла в качестве параметра
$data = import-csv -path $args[0] - тут уже в скрипте мы обрабатываем первый аргумент из массива $args, в котором хранятся все переданные параметры.
Я для тестов скриптов обычно BAT файл делаю ^^ Или делаю какой фоллбэк, если имя файла не передано в командной строке. Но это всё просто из академического интереса было предложено.
Поэтому исходный файл я тоже пришпилил к папке документов текущего пользователя.
Текущий пользователь может ругаться ^^ Лучше делать это через Temp имхо.
Передача аргументов при вызове скриптов в PSH выглядит так:
Всегда есть шанс, что в каком-нибудь BAT файле скрипт будет не распознан за что-то исполняемое. Поэтому я и говорю о екзешнике интерпритатора.
От батников я ушел окончательно два года назад
Текущий пользователь может ругаться ^^
Текущий пользователь - это я (а с самим собой я ругаться точно не буду) и пара моих коллег, с которыми расположение файлов обсуждалось. Сошлись на доках.
Поэтому я и говорю о екзешнике интерпритатора.
См. выше по поводу отказа от BAT
Для вызова программы с параметром, BAT файл – идеальный вариант без залпов линкора Ямато по воробьям.
Текущий пользователь - это я (а с самим собой я ругаться точно не буду) и пара моих коллег, с которыми расположение файлов обсуждалось. Сошлись на доках.
Я обычно не люблю мусор в той папке, хотя сама рабочие файлы там храню ограниченно ^^'
См. выше по поводу отказа от BAT
Например, запуск может происходить из FAR, и там тоже с этим может быть не совсем гладко.
1. Ручной запуск самой среды (powershell.exe) и в нем исполнение .\sсript-name.ps1. В этом случае можно и параметры передать. В подавляющем большинстве случаев именно так и делается. В принципе, ничто не мешает ровно то же самое оформить и в батнике, тогда никаких казусов вида скрипт будет не распознан за что-то исполняемое возникнуть не должно.
2. Правая кнопка на скрипте, Run with Powershell. Скрипт выполнится, но параметры в таком случае не передашь никак.
Полагаю, что в Far будут действовать те же ограничения, хотя наверняка не могу утверждать (так и не осилил его).
И это я еще про политику запуска скриптов не заикался