Ошибка Ejabberd: максимальное количество пользователей дляConference@conference.url.com был достигнут

Мы используем ejabberd в режиме конференции. Моя конференция имеет значения по умолчанию.
Например, «Максимальное количество человек 200» и т. Д.

У нас 14 участников и 2 владельца. Когда я пытаюсь присоединиться к своей учетной записи (как второй владелец) к конференции, у меня возникает ошибка «Максимальное количество пользователей для конференции@conference.url.comКогда я удаляю старый сервер из сети (либо выключив его, либо просто потянув за сетевой кабель), у меня возникают 2 проблемы:

Ошибка при запуске «Панели мониторинга» на целевом сервере

Windows Server Essentials:
    Networking domain controller server ist not accessible, some operations in Dashboard may not succeed. 
    Please check your network and make sure you can access the domain controller server.

] Ошибка при запуске «Пользователи и компьютеры Active Directory» на целевом сервере

Active Directory Domain Services:
    Naming information can not be located because the specified domain  
    either does not exist or could not be contacted.  

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

Пока что я удалил некоторые записи в диспетчере DNS на исходном сервере, указывающие на самого себя. Но это еще не помогло, и поиск результатов в Google не дает никаких решений. Я все еще нахожу одну запись для исходного сервера на целевом сервере @ > Пользователи и компьютеры Active Directory> [домен]> Контроллеры домена .

Есть идеи, как решить эти 2 проблемы?


РЕДАКТИРОВАТЬ:

C:\Users\admin>netdom query fsmo   
Schema master           [newserver].[mydomain].local   
Domain naming master    [newserver].[mydomain].local   
PDC                     [newserver].[mydomain].local
RID pool manager        [newserver].[mydomain].local
Infrastructure master   [newserver].[mydomain].local   
The command completed successfully.

Перенос ролей fsmo на [новый сервер] был довольно ухабистой поездкой, потому что ничто не работало так, как описано в практических рекомендациях, которые мы пытались использовать. Но в итоге вывод запроса netdom был таким, как указано выше (как я понимаю, так и должно быть)

РЕДАКТИРОВАТЬ 2: не ошибки)

Protokollname: System
Quelle: Microsoft-Windows-GroupPolicy
Datum: 06.07.2018 11:12:48
Ereignis-ID: 1058
Aufgabenkategorie:Keine
Level: Error
keywords:
User: SYSTEM
Computer: [oldserver].[domain].local
Description:

Error while processing the Group policy. The attempt to read the file "\so6.local\SysVol\so6.local\Policies{3474E153-5F07-4EC3-B816-9C0405CCF68F}\gpt.ini" from a Domaincontroller was not successful.
Group policiy settings can't be applied until this event is resolved. This could be a temporay problem which could have at least one of the following causes:
a) name resolution/network connection with the current Domaincontroller
b) Waiting period of the File Replication Service
c) the DFS-Clilent has been deactivated

Event-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-GroupPolicy" Guid="{aea1b4fa-97d1-45f2-a64c-4d69fffd92c9}" />
<EventID>1058</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>1</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="2018-07-06T09:12:48.941Z" />
<EventRecordID>1643448</EventRecordID>
<Correlation ActivityID="{C8828C15-D9E9-4FC6-8DE1-927F01129AB1}" />
<Execution ProcessID="520" ThreadID="1260" />
<Channel>System</Channel>
<Computer>SO6SERVER.so6.local</Computer>
<Security UserID="S-1-5-18" />
</System>
<EventData>
<Data Name="SupportInfo1">4</Data>
<Data Name="SupportInfo2">840</Data>
<Data Name="ProcessingMode">1</Data>
<Data Name="ProcessingTimeInMilliseconds">3027</Data>
<Data Name="ErrorCode">53</Data>
<Data Name="ErrorDescription">Der Netzwerkpfad wurde nicht gefunden. </Data>
<Data Name="DCName">\SO6SERVER.so6.local</Data>
<Data Name="GPOCNName">cn={3474E153-5F07-4EC3-B816-9C0405CCF68F},cn=policies,cn=system,DC=so6,DC=local</Data>
<Data Name="FilePath">\so6.local\SysVol\so6.local\Policies{3474E153-5F07-4EC3-B816-9C0405CCF68F}\gpt.ini</Data>
</EventData>
</Event>

практически я могу прочитать упомянутый файл, когда я обращаюсь (как администратор домена)

1
задан 9 July 2018 в 17:30
3 ответа

AD - это среда с несколькими ведущими, способная определять, какой DC активен, а какой мертв. В общем, вы должны удалить все эти записи DNS в конце, но это не должно помешать вам использовать новый DC, если старый DC просто вне сети. Мне это кажется какой-то проблемой репликации. если вы перейдете к \\ newserver, вы увидите все общие ресурсы (NETLOGON и SYSVOL)? Также стоит старый сервер 2008 или 2008 R2. Если это обычный 2008, он может использовать FRS вместо DFSR, что может вызвать проблемы с новыми версиями контроллеров домена (2012 и более поздних версий). Войдите в старый DC, откройте средство просмотра событий и посмотрите, сможете ли вы найти какие-либо ошибки, указывающие на FRS (например, ошибки JOURNAL_WRAP).

1
ответ дан 3 December 2019 в 20:13

Поскольку мы пробовали разные вещи, я не могу связать решение с конкретным действием.

Я почти уверен, что это было связано с методом репликации FRS и DFSR на исходном сервере (SBS 2008). Я отмечаю ответ @expx, упоминая, что в качестве решения сейчас, хотя это было не совсем то же самое

Я думаю, что репликация, наконец, может пойти по правильному пути после того, как мы остановили FRS и запустили DFSR на исходном сервере . Я не могу объяснить подробные шаги, но не последовательность, поскольку это был метод проб и ошибок. Спасибо всем за вклад, который заставил нас в конце концов покончить с этим (по крайней мере, так это выглядит сейчас)

0
ответ дан 3 December 2019 в 20:13

Я бы начал с nltest / dsregdns на новом контроллере домена и удалил все записи DNS для старого контроллера домена из диспетчера DNS.

Если старый контроллер домена находится в AD Sites and Services, его также следует удалить оттуда.

Могут быть другие проблемы. Если вы запустите nltest / dsgetdc: <имя домена> на новом контроллере домена, он должен показать TIMESERV, а общий ресурс на новом контроллере домена должен показать SYSVOL и NETLOGON.

1
ответ дан 3 December 2019 в 20:13

Теги

Похожие вопросы