<![CDATA[непредсказуемое поведение LDAP-синхронизации в CMS во время автоматизации]]>CMS (сервер Cisco Meeting Server) версии 3.11 демонстрирует непредсказуемое поведение синхронизации LDAP во время выполнения скриптов PowerShell Здравствуйте, При настройке CMS и интеграции LDAP я заметил, что нет автоматической синхронизации для обновления информации об учетных записях пользователей. Чтобы решить эту проблему, я написал скрипт PowerShell для выполнения синхронизации. Однако я столкнулся со странной проблемой: даже если я указываю один ID источника LDAP, скрипт синхронизирует 4 случайных источника LDAP из 8 доступных. Он полностью игнорирует указанный мной ID. Еще более странно, что если я задаю скрипту все 8 идентификаторов источников LDAP, он проходит по всем из них, но для каждого идентификатора выполняет точно такое же действие, как и в случае, когда задан только один идентификатор (синхронизирует те же 4 случайных источника). Что может быть причиной такого поведения?

]]>https://sla247.ru/forum/topic/1170/непредсказуемое-поведение-ldap-синхронизации-в-cms-во-время-автоматизацииRSS for NodeThu, 14 May 2026 20:47:54 GMTMon, 16 Feb 2026 18:42:10 GMT60<![CDATA[Reply to непредсказуемое поведение LDAP-синхронизации в CMS во время автоматизации on Mon, 16 Feb 2026 18:42:12 GMT]]>Вот сценарий: $uri

"https://cms.my.domain:8443/api/v1/ldapSyncs"
$apiUser

'admin'
$apiPass

'password'
$ldapSourceID

(
"1"

"2"
,

"3"
,

"4"
,

"5"
,

"6"
,

"7"

"8"

)
$tenantID

""
$pair

"$apiUser`:$apiPass"
$sec

ConvertTo

SecureString $apiPass

AsPlainText

Force $info

New

Object System
.
Management
.
Automation
.
PSCredential
(
$apiUser
,
$sec
)
$encoded

[
Convert
]
:
:
ToBase64String
(
[
System
.
Text
.
Encoding
]
:
:
UTF8
.
GetBytes
(
$pair
)
)
[
Net
.
ServicePointManager
]
:
:
SecurityProtocol

[
Net
.
SecurityProtocolType
]
:
:
Tls12 foreach
(
$id
in
$ldapSourceID
)
{
$syncPayload

@
{
tenant

@
{
id

$tenantID
}
ldapSource

@
(
@
{
id

$id
}
)
removeWhenFinished

$
false
}
$syncPayloadJson

$syncPayload
|
ConvertTo

Json

Depth
3
$response

Invoke

WebRequest

Uri $uri

Credential $info

Method Post

Body $syncPayloadJson

UseBasicParsing
:
$
true
Write

Host
"TRIGERIUKAS source $id"
}
$job

(
$response
.
Content
|
ConvertFrom

Json
)
$jobID

$job
.
id
do
{
Write

Host
"Nu....."
Start

Sleep

Seconds
5
$statusResp

Invoke

WebRequest

Uri
"$uri/$jobId"

Credential $info

UseBasicParsing #Write

Host
"TEST: [$($statusResp.Content)]"
$statusXml

[
xml
]
$statusResp
.
Content $status

$statusXml
.
ldapSyncs
.
ldapSync
[
0
]
.
state $count

[
int
]
$statusXml
.
ldapSyncs
.
ldapSync
[
0
]
.
numUsersImported $sourcesCompleted

[
int
]
$statusXml
.
ldapSyncs
.
ldapSync
[
0
]
.
numLdapSourcesComplete
if
(
$usersImported

gt
0
)
{
$lastCount

$usersImported
}
#Write

Host
"Current sync status: $status, users imported: $count, sources complete: $sourcesComplete"
}
while
(
$status

eq
"inProgress"
)
Write

Host
"Status of sync: $status, users imported/updated: $lastCount, sources used/completed: $sourcesComplete"

]]>https://sla247.ru/forum/post/8242https://sla247.ru/forum/post/8242Mon, 16 Feb 2026 18:42:12 GMT<![CDATA[Reply to непредсказуемое поведение LDAP-синхронизации в CMS во время автоматизации on Mon, 16 Feb 2026 18:42:11 GMT]]>Вот обновленная информация по этой проблеме: я выявил проблему и реализовал решение. Основная причина была связана с тем, как Cisco Meeting Server (CMS) обрабатывает определенные параметры в запросах API, такие как LDAP ID или информация о арендаторе. CMS, похоже, полностью игнорирует эти значения. Исходя из моего текущего уровня навыков, я не смог найти способ заставить CMS принять или обработать предоставленную мной информацию. При анализе поведения API вы заметите, что даже аутентификация не выполняется напрямую через сам API — мне пришлось использовать параметр -Credentials. Поняв суть проблемы, я осознал, что большая часть исходного скрипта была ненужной, поэтому удалил ее значительную часть. Обновленный скрипт теперь выполняет следующее: Входит в CMS
Запускает запрос на синхронизацию
Автоматически извлекает все доступные источники LDAP и их идентификаторы
Синхронизирует все источники за один проход
Удаляет собственную
запись журнала
синхронизации LDAP из /api/v1/ldapSyncs после завершения (это
не
удаляет никаких пользователей — удаляется только запись журнала, чтобы предотвратить заполнение списка, если автоматическая синхронизация выполняется несколько раз в день) Вы можете увидеть результаты синхронизации только в журналах интерфейса администратора CMS, если не создадите отдельный скрипт для отслеживания хода синхронизации. Мне эта функция не понадобилась, поэтому я ее не включил. Важное примечание: если хотя бы один источник LDAP не может быть синхронизирован вручную (например, CMS не может подключиться к серверу LDAP), скрипт прервет работу на этом источнике. После сбоя он прекращает обработку остальных источников. Например, если у вас есть 10 источников и третий из них недоступен, скрипт остановится на третьем и не будет продолжать работу с остальными. После того как я удалил временно недоступный источник, скрипт смог без проблем синхронизировать все остальные источники LDAP. $uri

"https://cms.my.domain:8443/api/v1/ldapSyncs"
$apiUser

'admin'
$apiPass

'password'
$sec

ConvertTo

SecureString $apiPass

AsPlainText

Force
$info

New

Object System
.
Management
.
Automation
.
PSCredential
(
$apiUser
,
$sec
)
[
Net
.
ServicePointManager
]
:
:
SecurityProtocol

[
Net
.
SecurityProtocolType
]
:
:
Tls12 $response

Invoke

WebRequest

Uri $uri

Credential $info

Method Post

UseBasicParsing
:
$
true
Write

Host
"taking in LDAP..."
do
{
Write

Host
"Cheking..."
Start

Sleep

Seconds
1
$statusResp

Invoke

WebRequest

Uri
"$uri"

Credential $info

UseBasicParsing
}
while
(
$status

eq
"inProgress"
)
Write

Host
"Status of sync: Finished"
if
(
$status

eq
"failed"
)
Write

Host
"Status of sync: BAD" Если эта информация была вам полезна или помогла решить подобную проблему, не стесняйтесь оставлять комментарии или отзывы — ваши отзывы помогают другим пользователям легче найти решение.

]]>https://sla247.ru/forum/post/8241https://sla247.ru/forum/post/8241Mon, 16 Feb 2026 18:42:11 GMT