Ошибка при присоединении к домену внутренняя ошибка

  • Remove From My Forums

  • Question

  • hi, when i want to join the pc to the domain it says «an internal error occured» and the join process fail.

    i can ping the domain using fqdn and dns is working ok and the client is pointing to the appropriate dns server. also i have no anti virus installed and firewall is off. here is the netsetup.log file here.

    Note: when i prestage the computer the join process is ok with no problem

    can anyone help me?

    08/04 17:30:45 ——————————————————————
    08/04 17:30:45 NetpValidateName: checking to see if ‘vivaldi.au’ is valid as type 3 name
    08/04 17:30:45 NetpCheckDomainNameIsValid [ Exists ] for ‘vivaldi.au’ returned 0x0
    08/04 17:30:45 NetpValidateName: name ‘vivaldi.au’ is valid for type 3
    08/04 17:30:54 ——————————————————————
    08/04 17:30:54 NetpDoDomainJoin
    08/04 17:30:54 NetpMachineValidToJoin: ‘OMM-7687492’
    08/04 17:30:54 NetpGetLsaPrimaryDomain: status: 0x0
    08/04 17:30:54 NetpMachineValidToJoin: status: 0x0
    08/04 17:30:54 NetpJoinDomain
    08/04 17:30:54 Machine: OMM-7687492
    08/04 17:30:54 Domain: vivaldi.au
    08/04 17:30:54 MachineAccountOU: (NULL)
    08/04 17:30:54 Account: vivaldi.au\administrator
    08/04 17:30:54 Options: 0x25
    08/04 17:30:54 OS Version: 5.1
    08/04 17:30:54 Build number: 2600
    08/04 17:30:54 ServicePack: Service Pack 3
    08/04 17:30:54 NetpValidateName: checking to see if ‘vivaldi.au’ is valid as type 3 name
    08/04 17:30:55 NetpCheckDomainNameIsValid [ Exists ] for ‘vivaldi.au’ returned 0x0
    08/04 17:30:55 NetpValidateName: name ‘vivaldi.au’ is valid for type 3
    08/04 17:30:55 NetpDsGetDcName: trying to find DC in domain ‘vivaldi.au’, flags: 0x1020
    08/04 17:30:59 NetpDsGetDcName: failed to find a DC having account ‘OMM-7687492$’: 0x525
    08/04 17:30:59 NetpDsGetDcName: found DC ‘\\001-002-001-204.vivaldi.au’ in the specified domain
    08/04 17:30:59 NetpJoinDomain: status of connecting to dc ‘\\001-002-001-204.vivaldi.au’: 0x0
    08/04 17:30:59 NetpGetLsaPrimaryDomain: status: 0x0
    08/04 17:30:59 NetpGetDnsHostName: Read NV Hostname: omm-7687492
    08/04 17:30:59 NetpGetDnsHostName: PrimaryDnsSuffix defaulted to DNS domain name: vivaldi.au
    08/04 17:30:59 NetpLsaOpenSecret: status: 0xc0000034
    08/04 17:30:59 NetpGetLsaPrimaryDomain: status: 0x0
    08/04 17:30:59 NetpLsaOpenSecret: status: 0xc0000034
    08/04 17:30:59 SamLookupNamesInDomain on OMM-7687492$ failed with 0xc0000073
    08/04 17:30:59 NetpJoinDomain: status of setting machine password: 0x534
    08/04 17:30:59 NetpJoinDomain: initiaing a rollback due to earlier errors
    08/04 17:30:59 NetpLsaOpenSecret: status: 0x0
    08/04 17:30:59 NetpJoinDomain: rollback: status of deleting secret: 0x0
    08/04 17:30:59 NetpJoinDomain: status of disconnecting from ‘\\001-002-001-204.vivaldi.au’: 0x0
    08/04 17:30:59 NetpDoDomainJoin: status: 0x534
    08/04 17:30:59 ——————————————————————
    08/04 17:30:59 NetpDoDomainJoin
    08/04 17:30:59 NetpMachineValidToJoin: ‘OMM-7687492’
    08/04 17:30:59 NetpGetLsaPrimaryDomain: status: 0x0
    08/04 17:30:59 NetpMachineValidToJoin: status: 0x0
    08/04 17:30:59 NetpJoinDomain
    08/04 17:30:59 Machine: OMM-7687492
    08/04 17:30:59 Domain: vivaldi.au
    08/04 17:30:59 MachineAccountOU: (NULL)
    08/04 17:30:59 Account: vivaldi.au\administrator
    08/04 17:30:59 Options: 0x27
    08/04 17:30:59 OS Version: 5.1
    08/04 17:30:59 Build number: 2600
    08/04 17:30:59 ServicePack: Service Pack 3
    08/04 17:30:59 NetpValidateName: checking to see if ‘vivaldi.au’ is valid as type 3 name
    08/04 17:30:59 NetpCheckDomainNameIsValid [ Exists ] for ‘vivaldi.au’ returned 0x0
    08/04 17:30:59 NetpValidateName: name ‘vivaldi.au’ is valid for type 3
    08/04 17:30:59 NetpDsGetDcName: trying to find DC in domain ‘vivaldi.au’, flags: 0x1020
    08/04 17:31:03 NetpDsGetDcName: failed to find a DC having account ‘OMM-7687492$’: 0x525
    08/04 17:31:03 NetpDsGetDcName: found DC ‘\\001-002-001-201.vivaldi.au’ in the specified domain
    08/04 17:31:03 NetpJoinDomain: status of connecting to dc ‘\\001-002-001-201.vivaldi.au’: 0x0
    08/04 17:31:03 NetpGetLsaPrimaryDomain: status: 0x0
    08/04 17:31:03 NetpGetDnsHostName: Read NV Hostname: omm-7687492
    08/04 17:31:03 NetpGetDnsHostName: PrimaryDnsSuffix defaulted to DNS domain name: vivaldi.au
    08/04 17:31:03 NetpLsaOpenSecret: status: 0xc0000034
    08/04 17:31:03 NetpGetLsaPrimaryDomain: status: 0x0
    08/04 17:31:03 NetpLsaOpenSecret: status: 0xc0000034
    08/04 17:31:03 NetpManageMachineAccountWithSid: NetUserAdd on ‘\\001-002-001-201.vivaldi.au’ for ‘OMM-7687492$’ failed: 0x54f
    08/04 17:31:03 NetpJoinDomain: status of creating account: 0x54f
    08/04 17:31:03 NetpJoinDomain: initiaing a rollback due to earlier errors
    08/04 17:31:03 NetpLsaOpenSecret: status: 0x0
    08/04 17:31:03 NetpJoinDomain: rollback: status of deleting secret: 0x0
    08/04 17:31:03 NetpJoinDomain: status of disconnecting from ‘\\001-002-001-201.vivaldi.au’: 0x0
    08/04 17:31:03 NetpDoDomainJoin: status: 0x54f

    • Edited by

      Monday, August 4, 2014 1:11 PM

Источник

Добрый день!

Было 2 контроллера домена: windows 2003 (с ролью FSMO) и windows 2008.

Контроллер windows 2003 был виртуализирован, после чего на хостовую машину были установлены 2 клиентские машины: windows XP и windows 7.

windows 2003, windows XP и windows 7 в одной подсети без шлюза и выхода в интернет, разрешают имена друг-друга.

windows 2003:

ip: 10.5.5.249

mask: 255.255.255.0

dns: 10.5.5.249

windows XP:

ip: 10.5.5.5

mask: 255.255.255.0

dns: 10.5.5.249

windows 7:

ip: 10.5.5.203

mask: 255.255.255.0

dns: 10.5.5.249

При попытке ввести в домен windows 7, появляется окно с сообщением:

«При присоединении к домену «*» произошла  следующая ошибка:

Не удается завершить выполнение функции.»

При попытке ввести в домен windows XP, появляется окно с сообщением:

«При присоединении к домену «*» произошла  следующая ошибка:

Служба каталогов не смогла выделить относительный идентификатор.»

Если на DC просматривать оснастку Active Directory — users and computers, хозяева операций, то во вкладках RID, PDC и Инфраструктура — указан корректный контроллер домена.

Помогите, пожалуйста, починить контроллер домена!

В логах безопасности на DC ошибок нет: успешный сетевой вход в систему.

  • Изменено

    28 ноября 2012 г. 17:48

  • Remove From My Forums

  • Question

  • Is windows XP still supported to join the domain on windows server 2019?

    I got «an internal error occurred» while attempting to join to domain. 

    Please advise.

    Thanks.

All replies

  • «Is windows XP still supported to join the domain«

    No.  Windows XP is out of support.  No testing for compatibility/usability with 2019 has been performed by Microsoft because Windows XP is not supported.  As intimated by Clement, you might be able to get it to join by downgrading the domain,
    but that does not change the fact that it is still unsupported, even when the domain is at a lower level.  Not only does lower the settings in the domain lower the overall security of the domain, just having a Windows XP system in your environment lowers
    the overall security of your environment.

    tim

  • Windows XP is generally unsupported — you might be able to arrange a custom support contract with Microsoft, but keep in mind that this is an expensive proposition and includes only support for security updates.

    hth
    Marcin

  • It is not supported. You may be able to make it work but you should not be surprised if future updates will break it again.

  • Hello,
    We can try the following common ways to troubleshoot the issue:

    1. Check if we can ping domain or domain controller.

    2. Check whether the Windows XP points to the correct DNS server.

    3. Check whether all the Windows XP clients can not be added to the same domain.

    4. Check whether we use correct domain administrator credentials when we join Windows XP to domain.

    5. Check if we try to create the Windows XP computer name in the domain first, then if we can add it to domain.

    If all the above is OK and all the Windows XP clients can not be added to the domain. I am sorry, please understand because Windows XP is out of support. We don’t have such an environment to test. It may have potential and incompatible
    problems. It is recommended that we use the new version of Windows client.

    Thank you for your understanding and support.

    Best Regards,
    Daisy Zhou

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact
    tnmff@microsoft.com.

    • Edited by

      Tuesday, February 12, 2019 2:49 AM

    • Proposed as answer by
      Daisy ZhouMicrosoft contingent staff
      Thursday, February 28, 2019 2:30 AM

  • Hi,
    If this question has any update or is this issue solved? Also, for the question, is there any other assistance we could provide?

    Best Regards,
    Daisy Zhou

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact
    tnmff@microsoft.com.

  • Hi Daisy Zhou,

    Please see the comments below:

    1. Check if we can ping domain or domain controller.
     — Yes….

    2. Check whether the Windows XP points to the correct DNS server.
     — Yes, it’s correct..

    3. Check whether all the Windows XP clients can not be added to the same domain.
     — Unfortunately, all windows XP clients are failed to join to the domain.

    4. Check whether we use correct domain administrator credentials when we join Windows XP to domain.
     — The domain admin credentials are correct.

    5. Check if we try to create the Windows XP computer name in the domain first, then if we can add it to domain.

     — Thanks for the suggestion. However, this method is not work either. But surprisingly that, I found the computers membership is
    been disabled when I join the win p client to the domain. It’s strange!

    Btw, thanks all for your feedback, suggestion and answer, appreciate it. Anyway, i think i need to find a plan for the win XP client.

    Thanks.

    Scriven Tan.

  • Hi,
    You are welcome!

    Thanks for your understanding and time. Have a nice day!

    Best Regards,
    Daisy Zhou

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact
    tnmff@microsoft.com.

  • Hello

    I have the same problem and same error.

    According to my investigation , it seems that Windows 2019 AD controller supplies kerberos ticket to the Windows XP client  with AES encryption despite the fact that Windows XP asks and supports RC4 encryption only.

    The RC4 encryption support is enabled in policies for DC but it still doesn’t work and DC ignores this setting when 2016 and 2012 r2 and even 2008 r2 works correctly.

    I think that MS got decision to block RC4 support but no documentation about that was found. I hope that this is a bug and it will fixed whenever because this also affects other RC4 kerberos clients as various old Linux implementations being joined to AD
    domain.

  • I seriously doubt that Microsoft enforcing a higher level of security in a domain would be considered a ‘bug’ by Microsoft.  They did the same thing many years ago when they stopped supporting NT4 security in a domain out of the box.  They did
    provide a way to ‘downgrade’ the environment to allow the NT4 security.  I would hazard a guess (I have not tried it) that if you downgraded your domain to something prior to 2019 functional level, you could get by the outdated security.  But you
    are sacrificing security in order to include operating systems that most likely do not have support anymore.  The OP was asking about Windows XP.  That is definitely not supported.  So downgrading security level to add an unsupported and security
    vulnerable operating system to the environment seems counter-intuitive.

    tim

  • Hi

    Personally, I have no problem with nonsupporting of old protocols by default.  Moreover , DES and RC4 in Kerberos are not supported by default even in Win2008 R2 unless a administrator defines their supporting in policies.

    So, it is definitely OK to not support it by default but still let to admins the option to enable it on their own risk in case they do want to support old clients such as XP or old Linux. 

    But this is not the same case because theoretically Microsoft still  has left the option to enable DES and RC4 support in policies in Windows 2019 but despite this it isn’t working and no glue in MS documentations has been found about this limitation.
    So, my conclusion this is a bug or some undocumented design change.

  • If you do believe it is a bug, then you should report it to Microsoft.  Microsoft does not charge for support cases that are determined to be bugs.

    tim

  • Remove From My Forums

  • Question

  • Is windows XP still supported to join the domain on windows server 2019?

    I got «an internal error occurred» while attempting to join to domain. 

    Please advise.

    Thanks.

All replies

  • «Is windows XP still supported to join the domain«

    No.  Windows XP is out of support.  No testing for compatibility/usability with 2019 has been performed by Microsoft because Windows XP is not supported.  As intimated by Clement, you might be able to get it to join by downgrading the domain,
    but that does not change the fact that it is still unsupported, even when the domain is at a lower level.  Not only does lower the settings in the domain lower the overall security of the domain, just having a Windows XP system in your environment lowers
    the overall security of your environment.

    tim

  • Windows XP is generally unsupported — you might be able to arrange a custom support contract with Microsoft, but keep in mind that this is an expensive proposition and includes only support for security updates.

    hth
    Marcin

  • It is not supported. You may be able to make it work but you should not be surprised if future updates will break it again.

  • Hello,
    We can try the following common ways to troubleshoot the issue:

    1. Check if we can ping domain or domain controller.

    2. Check whether the Windows XP points to the correct DNS server.

    3. Check whether all the Windows XP clients can not be added to the same domain.

    4. Check whether we use correct domain administrator credentials when we join Windows XP to domain.

    5. Check if we try to create the Windows XP computer name in the domain first, then if we can add it to domain.

    If all the above is OK and all the Windows XP clients can not be added to the domain. I am sorry, please understand because Windows XP is out of support. We don’t have such an environment to test. It may have potential and incompatible
    problems. It is recommended that we use the new version of Windows client.

    Thank you for your understanding and support.

    Best Regards,
    Daisy Zhou

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact
    tnmff@microsoft.com.

    • Edited by

      Tuesday, February 12, 2019 2:49 AM

    • Proposed as answer by
      Daisy ZhouMicrosoft contingent staff
      Thursday, February 28, 2019 2:30 AM

  • Hi,
    If this question has any update or is this issue solved? Also, for the question, is there any other assistance we could provide?

    Best Regards,
    Daisy Zhou

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact
    tnmff@microsoft.com.

  • Hi Daisy Zhou,

    Please see the comments below:

    1. Check if we can ping domain or domain controller.
     — Yes….

    2. Check whether the Windows XP points to the correct DNS server.
     — Yes, it’s correct..

    3. Check whether all the Windows XP clients can not be added to the same domain.
     — Unfortunately, all windows XP clients are failed to join to the domain.

    4. Check whether we use correct domain administrator credentials when we join Windows XP to domain.
     — The domain admin credentials are correct.

    5. Check if we try to create the Windows XP computer name in the domain first, then if we can add it to domain.

     — Thanks for the suggestion. However, this method is not work either. But surprisingly that, I found the computers membership is
    been disabled when I join the win p client to the domain. It’s strange!

    Btw, thanks all for your feedback, suggestion and answer, appreciate it. Anyway, i think i need to find a plan for the win XP client.

    Thanks.

    Scriven Tan.

  • Hi,
    You are welcome!

    Thanks for your understanding and time. Have a nice day!

    Best Regards,
    Daisy Zhou

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact
    tnmff@microsoft.com.

  • Hello

    I have the same problem and same error.

    According to my investigation , it seems that Windows 2019 AD controller supplies kerberos ticket to the Windows XP client  with AES encryption despite the fact that Windows XP asks and supports RC4 encryption only.

    The RC4 encryption support is enabled in policies for DC but it still doesn’t work and DC ignores this setting when 2016 and 2012 r2 and even 2008 r2 works correctly.

    I think that MS got decision to block RC4 support but no documentation about that was found. I hope that this is a bug and it will fixed whenever because this also affects other RC4 kerberos clients as various old Linux implementations being joined to AD
    domain.

  • I seriously doubt that Microsoft enforcing a higher level of security in a domain would be considered a ‘bug’ by Microsoft.  They did the same thing many years ago when they stopped supporting NT4 security in a domain out of the box.  They did
    provide a way to ‘downgrade’ the environment to allow the NT4 security.  I would hazard a guess (I have not tried it) that if you downgraded your domain to something prior to 2019 functional level, you could get by the outdated security.  But you
    are sacrificing security in order to include operating systems that most likely do not have support anymore.  The OP was asking about Windows XP.  That is definitely not supported.  So downgrading security level to add an unsupported and security
    vulnerable operating system to the environment seems counter-intuitive.

    tim

  • Hi

    Personally, I have no problem with nonsupporting of old protocols by default.  Moreover , DES and RC4 in Kerberos are not supported by default even in Win2008 R2 unless a administrator defines their supporting in policies.

    So, it is definitely OK to not support it by default but still let to admins the option to enable it on their own risk in case they do want to support old clients such as XP or old Linux. 

    But this is not the same case because theoretically Microsoft still  has left the option to enable DES and RC4 support in policies in Windows 2019 but despite this it isn’t working and no glue in MS documentations has been found about this limitation.
    So, my conclusion this is a bug or some undocumented design change.

  • If you do believe it is a bug, then you should report it to Microsoft.  Microsoft does not charge for support cases that are determined to be bugs.

    tim

Когда не получается ввести компьютер в домен

// 8 июля, 2014 // Системное администрирование

active-directory-iconДовольно часто после всяческих экспериментов с сетевыми подключениями, переустановкой винды и прочего может возникнуть такая ситуация, что рабочая станция перестанет входить в домен. Это бывает по нескольким причинам. В этом посте я расскажу о двух из них

Ошибка при запросе DNS записи ресурса размещения службы (SRV), используемой для нахождения контроллера домена Active Directory 

Полный текст ошибки может быть такой:

Ошибка при запросе DNS записи ресурса размещения службы (SRV), используемой для нахождения контроллера домена Active Directory для домена «domain.loc»:
Произошла ошибка: «DNS-имя не существует.»
(код ошибки: 0x0000232B RCODE_NAME_ERROR)

Опрос проводился для SRV-записи для _ldap._tcp.dc._msdcs.exigeant.loc
Возможны следующие причины ошибки:
— SRV-записи DNS, необходимые для нахождения контроллера домена Active Directory в этом домене, не зарегистрированы в службе DNS. Эти записи регистрируются на DNS-сервере автоматически при добавлении контроллера домена Active Directory в домен. Они обновляются контроллером домена Active Directory через заданные интервалы. Этот компьютер настроен на использование DNS-серверов со следующими IP-адресами:

8.8.8.8
192.168.0.1
— Одна или несколько зон из указанных ниже не содержит делегирование к своей дочерней зоне:
domain.loc
loc
. (корневая зона)

Решение

  • Контроллер домена должен быть первым DNS сервером в списке. Если у вас в сетевои соединении прописано два DNS серера, например внутренний и внешний, то важно помнить, чтобы их порядок был правильным. Вы можете настроить порядок через кнопку «Дополнительно», закладку «DNS» в настройках сетевого подключения.
  • Также важным моментом является адрес DNS сервера, вы должны прописывать внутренний (а не вшешний) адрес вашего DNS-сервера (он же контроллер домена).

Active_Directory

При присоединении к домену произошла следующая ошибка: Сетевая папка недоступна

Решение

Проверьте, включена ли галочка «Клиент для сетей Microsoft» в настройках сетевого соединения.

Спасибо!

Если вам помогла статья, или вы хотите поддержать мои исследования и блог — вот лучший способ сделать это:

Источник

active-directory-iconДовольно часто после всяческих экспериментов с сетевыми подключениями, переустановкой винды и прочего может возникнуть такая ситуация, что рабочая станция перестанет входить в домен. Это бывает по нескольким причинам. В этом посте я расскажу о двух из них

Ошибка при запросе DNS записи ресурса размещения службы (SRV), используемой для нахождения контроллера домена Active Directory 

Полный текст ошибки может быть такой:

Ошибка при запросе DNS записи ресурса размещения службы (SRV), используемой для нахождения контроллера домена Active Directory для домена “domain.loc”:
Произошла ошибка: “DNS-имя не существует.”
(код ошибки: 0x0000232B RCODE_NAME_ERROR)

Опрос проводился для SRV-записи для _ldap._tcp.dc._msdcs.exigeant.loc
Возможны следующие причины ошибки:
– SRV-записи DNS, необходимые для нахождения контроллера домена Active Directory в этом домене, не зарегистрированы в службе DNS. Эти записи регистрируются на DNS-сервере автоматически при добавлении контроллера домена Active Directory в домен. Они обновляются контроллером домена Active Directory через заданные интервалы. Этот компьютер настроен на использование DNS-серверов со следующими IP-адресами:

8.8.8.8
192.168.0.1
– Одна или несколько зон из указанных ниже не содержит делегирование к своей дочерней зоне:
domain.loc
loc
. (корневая зона)

Решение

  • Контроллер домена должен быть первым DNS сервером в списке. Если у вас в сетевои соединении прописано два DNS серера, например внутренний и внешний, то важно помнить, чтобы их порядок был правильным. Вы можете настроить порядок через кнопку “Дополнительно”, закладку “DNS” в настройках сетевого подключения.
  • Также важным моментом является адрес DNS сервера, вы должны прописывать внутренний (а не вшешний) адрес вашего DNS-сервера (он же контроллер домена).

Active_Directory

При присоединении к домену произошла следующая ошибка: Сетевая папка недоступна

Решение

Проверьте, включена ли галочка “Клиент для сетей Microsoft” в настройках сетевого соединения.

Источник

пинг до DC есть, пробывал отключать и
брандмауэр и антивирус, ошибка та же самая

C:\Users\Администратор>ping srv-01

Обмен пакетами с SRV-01 [10.0.1.2] с 32 байтами данных:
Ответ от 10.0.1.2: число байт=32 время<1мс TTL=128
Ответ от 10.0.1.2: число байт=32 время<1мс TTL=128
Ответ от 10.0.1.2: число байт=32 время<1мс TTL=128
Ответ от 10.0.1.2: число байт=32 время<1мс TTL=128

Статистика Ping для 10.0.1.2:
    Пакетов: отправлено = 4, получено = 4, потеряно = 0
    (0% потерь)
Приблизительное время приема-передачи в мс:
    Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек

Вообще-то поиск контроллера в домене проверяется с помощью утилиты nltest (для Windows Server на входит в состав компонента средств управления Active Directory). Но пока и так сойдёт.

Сразу исправьте ошибку настройки на контроллере домена: уберите из списка серверов DNS шлюз 10.0.1.1 (если, конечно, шлюз — это не другой контроллер), и, для ускорения процесса, попробуйте зарегистрировать все нужные записи командами ipconfig
/registerdns и nltest /dsregdns, после чего попробуйте добавить сервер в домен заново.

Если имена из интернета после такой настройки перестали разрешаться — добавьте в настройках сервера DNS пересылку на шлюз.

Если ошибка останется та же — проверьте регистрацию записей контроллера в DNS — dcdiag /test:DNS , а также — доступность сервера DNS с вводимого в домен сервера — командой nslookup srv-01

Слава России!

Сделал все по рекомендациям ошибка так и осталась вот вывод dcdiag:

Диагностика сервера каталогов

Выполнение начальной настройки:
   Выполняется попытка поиска основного сервера…
   Основной сервер = SRV-01
   * Идентифицирован лес AD.
   Сбор начальных данных завершен.

Выполнение обязательных начальных проверок

   Сервер проверки: Default-First-Site-Name\SRV-01
      Запуск проверки: Connectivity
         ……………………. SRV-01 — пройдена проверка Connectivity

Выполнение основных проверок

   Сервер проверки: Default-First-Site-Name\SRV-01

      Запуск проверки: DNS

         Проверки DNS выполняются без зависания. Подождите несколько минут…
         ……………………. SRV-01 — пройдена проверка DNS

   Выполнение проверок разделов на: ForestDnsZones

   Выполнение проверок разделов на: DomainDnsZones

   Выполнение проверок разделов на: Schema

   Выполнение проверок разделов на: Configuration

   Выполнение проверок разделов на: goodlombard

   Выполнение проверок предприятия на: goodlombard.int
      Запуск проверки: DNS
         Результаты проверки контроллеров домена:

            Контроллер домена: SRV-01.goodlombard.int
            Домен: goodlombard.int

               TEST: Dynamic update (Dyn)
                  Warning: Failed to delete the test record dcdiag-test-record in zone goodlombard.int

               SRV-01                       PASS PASS PASS PASS WARN PASS n/a
         ……………………. goodlombard.int — пройдена проверка DNS

  • Изменено
    IronPhoen1X
    22 марта 2017 г. 11:33

Источник

Столкнулся со странным сообщением “
Произошла внутренняя ошибка
/
An internal error has occurred
” при RDP подключении к недавно развернутому серверу RDSH на Windows Server 2012 R2 из Windows 10. Буквально вчера RDP подключение к серверу работало нормально, но после установки и настройки RemotApp приложений и перезагрузки сервера, я не могу удаленно подключиться к его рабочему столу. Служба Remote Desktop Services судя по всему работает, так как пароль пользователя при подключении запрашивается.

Как я понял, сообщение RDP консоли “Произошла внутренняя ошибка” может появляться в различных случаях и иметь совершенно различные причины, связанные как с сервером Remote Desktop, так и с клиентом. В этой статье я постарался собрать все варианты решения и сценарий, который помог мне.

Произошла внутренняя ошибка при RDP подключении windows 10 к windows server 2012 RDS

В первую очередь, убедитесь, что на RDS сервере доступен RDP порт 3389, и подключение не блокируется файерволом (Test-NetConnection rdsserver –port 3389).

Изучив логи RDP подключений на удаленном RDS сервере, я не увидел никаких особенных ошибок. В журнале Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational видно, что RDP сессия создается:

The server accepted a new TCP connection from client 10.10.1.60:64379.
Connection RDP-Tcp#3 created

Но потом без какой-либо ошибки RDP сеанс завершается:

The server has terminated main RDP connection with the client.
The disconnect reason is 0

The server has terminated main RDP connection with the client

Проверьте состояние службу Remote Desktop Services на удаленном сервере и перезапустите ее. Вы можете удаленно перезапустить службу через консоль Services.msc (Connect to another computer), но гораздо проще проверить состояние службы и перезапустить ее через PowerShell:

(Get-Service TermService -ComputerName msk-ts1).status

Служба запушена (Running), перезапустим ее:

Get-Service TermService -ComputerName msk-ts1| Restart-Service –force –verbose

перезапуск службы TermService (Remote Desktop Services )

Но проблему это не решило.

Какие еще варианты решения проблемы мне удалось найти в сети:

  1. Если у вас на удаленном сервере установлен КриптоПРО, он может быть источником проблем с rdp подключением. Попробуйте отключить проверку контрольных целостности файлов (проверки контрольных сумм) в КриптоПро через реестр. Перейдите в ветку реестра
    HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\CProIntegrity
    и измените значение параметра CheckMode на 0. Перезагрузите сервер.
  2. Если в журнале событий TerminalServices-RemoteConnectionManager вы встретите событие с EventID 1057 (The RD Session Host Server has failed to create a new self signed certificate to be used for RD Session Host Server authentication on SSL connections), перейдите в каталог
    C:\ProgramData\Microsoft\Crypto\RSA
    , переименуйте папку Machinekeys в Machinekeys_bak и перезапустите службу TermService.
  3. Также нашел информацию, что RDP проблема “Произошла внутренняя ошибка” встречалась в Windows 10 1809, если на удаленном компьютере включена политика Configure H.264/AVC hardware encoding for Remote Desktop connections (находится в секции GPO: Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Remote Session Environment). Для решения этой проблемы достаточно отключить UDP протокол для RDP, создав в ветке реестра
    HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client
    параметр
    fClientDisableUDP
    со значением 1.
  4. В комментариях Ivan оставил очень полезный фикс.
    Проблема с ошибкой RDP может быть в наличии некоего счетчика учитывающего максимальное количество подключений в Windows.
    В десктопных версиях Windows — 100, в Windows Server -3000. Для сброса счетчика достаточно перезагрузить компьютер, или просто увеличить лимит через реестр:
    REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v MaxOutstandingConnections /t REG_DWORD /d 65536

Ни один из рассмотренных выше сценариев не был применим в моем случае. Я совершенно случайно обнаружил, что с других компьютеров нет проблем с подключением к этому RDS серверу. Значить проблема только с моим компьютером, а не с сервером.

Я очистил историю RDP подключений в ветке
HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers
и сбросил кэш RDP в каталоге
C:\Users\%Username%\AppData\Local\Microsoft\Terminal Server Client\Cache
(перед удалением закройте все запущенные сеансы mstsc.exe):

del "C:\Users\%Username%\AppData\Local\Microsoft\Terminal Server Client\cache"

очистка кэша rdp AppData\Local\Microsoft\Terminal Server Client\cache

После этого перезагрузил свой компьютер, и ошибка RDP подключения исчезла!

Источник

Понравилась статья? Поделить с друзьями:
  • Ошибка при преобразовании типа данных varchar к numeric
  • Ошибка при преобразовании типа данных varchar к float
  • Ошибка при преобразовании типа данных varchar к bigint
  • Ошибка при преобразовании типа данных nvarchar к real
  • Ошибка при преобразовании типа данных varbinary к numeric