Перемещаем информацию о пользователях в Active Directory и Sharepoint c помощью PowerShell

[mtp]

После нескольких лет появления нативных майкрософтовских методов работы с AD всякие квестовские и лдаповские обходные манёвры смотрятся жутким анахронизмом.

Манипуляции с select-string вызывают подозрение, что вы не слышали про регулярные выражения в Powershell. Попробуйте, это куда удобнее.

С Sharepoint еще не работал — спасибо, любопытно взглянуть.

[foxmuldercp]

У товарища на прошлой работе 1с-кадры были интегрированы прямо в ad. При создании сотрудника в 1С требовалось только дополнительно ввести фио латиницей, автоматически создавалась учётка в нужном OU в AD, пользователь добавлялся в группы, ну и ящик в Exchange с соответствующими рассылками. По уходу в отпуск/больничный учётка блокировалась, но был флаг, позволяющий удалённую работу, т.е учётка оставалась активной, и по увольнению учётка блокировалась.
Ну и уходило письмо в ИТ отдел для того, тчтобы комп можно было банально забрать, почистить, винт отдефрагметнировать и все такое.

[Pavel7]

А зачем вы грузите пользователей вначале в AD, а потом еще и в SharePoint (причём еще и в список, зачем-то, вместо профиля)? Не проще ли грузить данные из xls в профили пользователей (если у вас, конечно, не Foundation), а оттуда просто настроить репликацию нужных аттрибутов в AD?

> $objExcel=New-Object -comobject Excel.Application

Для файла такой простой стурктуры хватило бы и значительно более легкого OdbcConnection, которому не нужен клиентский Excel.

> if (!($item=$list.Items | where {$_[«Sid»] -eq $line.Sid})) {

Это не очень хорошая идея для больших списков. Вы будете каждый раз получать на клиент весь список и только после этого фильтровать его. Powershell еще не настолько умён, чтобы самому по этой строчке строить CAML.

> $item=$list.Items.Add()

Аналогично предыдущему. Если у вас шарик не ниже 2010 юзайте $list.AddItem(), если 2007ой — получайте CAML-ом пустую коллекцию и вызывайте Add у неё.

[Goblinoid]

Потому что:
1) исторически сложилось — что нам данные нужны были только в AD, шарика изначально не было;
2) Списки в Шарике — нужны в разных местах — для создания рабочих процессов (например утверждения заявок) — но это совсем другая тема.

За советы спасибо — будем смотреть.

[Pavel7]

В любом случае, советую всё-таки использовать службу профилей и SPFieldUser вместо списков с пользователями и SPFieldLookup. Служба профилей за вас заполнит служебный скрытый список «Список сведений о пользователях» на корневом узле каждой сайт-коллекции.

[mtp]

Про OdbcConnection можно поподробнее?

[Pavel7]

Через Microsoft Jet OleDB провайдер можно читать и писать xls и dbf файлы, без необходимости создавать Excel.Application. Создаёте обычный OleDbConnection и работаете с ним, например через OleDbAdapter.

Пример строчки подключения для OleDbConnection:

Provider=Microsoft.Jet.OLEDB.4.0;Extended Properties=Excel 8.0;Data Source=C:\Temp\afgd1234.xls

Пример кода (из dbf pipeline компоненты для biztalk):

OleDbConnection oConn = new OleDbConnection();
oConn.ConnectionString = odbcConnectionString;

// Create the Select Statement for the ODBC File
OleDbDataAdapter oCmd;
// Get the filter if there is one
string whereClause = "";
if (Filter != null && Filter.Trim() != "")
    whereClause = " Where " + Filter.Trim();
if (this.TypeToProcess == odbcType.Excel)
    oCmd = new OleDbDataAdapter(this.SqlStatement.Trim() + whereClause, oConn);
else // dbf
    oCmd = new OleDbDataAdapter(this.SqlStatement.Trim() + " From " + fileName + whereClause, oConn);
oConn.Open();
// Perform the Select statement from above into a dataset, into a DataSet. 
DataSet odbcDataSet = new DataSet();
oCmd.Fill(odbcDataSet, this.DataNodeName);
oConn.Close();

[Goblinoid]

я сейчас дома — сижу с макбука — винды под рукой нет — но что-то мне подсказывает, что этот код не будет работать в powershell? Строка — подключения — понятно — стандартная! а вот — код — че-то я сомневаюсь, Михалыч! :)

[Pavel7]

Ну это c# синтаксис, понятное дело. Не думаю, что его сложно переписать на синтаксис powershell.