Ошибка групповой политики server 2003

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I am not sure if this is the right place to put this question but hopefully someone can move it for me if it isn’t.

I am receiving the following two events in the system event log on one particular machine, I have already re-installed this from scratch once (I didn’t remove the AD computer object, it just reused it as I thought it might be a computer related problem at first not AD, but I’m beginning to think otherwise now).

The TERMSRV mentioned in the second event log is an old server which has been removed from the domain a long long time ago now, I think about two years ago. The object no longer exists in AD or DNS and I don’t know where else to look to ensure it’s no longer present.

The event logs are:

The processing of Group Policy failed because of lack of network connectivity to a domain controller. This may be a transient condition. A success message would be generated once the machine gets connected to the domain controller and Group Policy has succesfully processed. If you do not see a success message for several hours, then contact your administrator.

Source: Group Policy

The terminal server cannot register ‘TERMSRV’ Service Principal Name to be used for server authentication. The following error occured: The specified domain either does not exist or could not be contacted.

Answers

as you are now stating this machine is SBS version please use the SBS forum instead this one:

Too many steps are different when it goes into detailed configuration settings.

I have not understood well what is the problem exactly.

For the faulty computer try to re-join it to the domain and check if all is okay or not.

For event ID 1129, refer to this Microsoft article:

For event ID 1067, refer to this Microsoft article:

Please make sure that you client computer is pointing to the correct internal DNS server as primary one and use nslookup to check that you don’t have DNS resolution problems.

Microsoft Student Partner

Microsoft Certified Professional
Microsoft Certified Systems Administrator: Security
Microsoft Certified Systems Engineer: Security
Microsoft Certified Technology Specialist: Windows Server 2008 Active Directory, Configuration
Microsoft Certified Technology Specialist: Windows Server 2008 Network Infrastructure, Configuration

Event id 1129 says about failed DC connectivity, it can be bad NIC or firewall blocking the ports or issue in the port at the swicth, so its better you need to verify the connectivity issues.

Event ID 1067 is more related to Spn issue.

Regards

Disclaimer : This posting is provided AS-IS with no warranties or guarantees and confers no rights.

the machine you are talking about is a DC and was it already before reinstalling, please elaborate especially about the not removeal of it in AD UC?

If TERMSRV is not longer existing use metadata cleanup to remvoe it. This name you can NOT use as DC without having problems:

If you have used the TERMSRV again for anew DC when the old exist in the database remove it run metadata cleanup and do a format of this server and start fresh after checking that the name no where exist anymore, AD UC, AD sites and services and DNS zones and zone properties.

Thank you for your replies. As requested I will supply further information:

The client workstation is running Windows 7 Professional SP1 (I had experienced problems before SP1 was installed with regards to connecting to the domain).

There is only one DC and it runs Server 2008 Standard SP2.

No other machines in the network suffer from this problem, the NIC is an integrated wired NIC on a laptop so I really hope that the NIC isn’t faulty, any way I can determine this?

The DC is up and running and ready for the domain before the client machines attempt to connect.

TERMSRV was an old DC back when our network used 2003, it was removed from the domain before moving to 2008 – is it possible it didn’t get cleaned up on 2003 properly and it is still existing in the Active Directory database somewhere? How can I check? There is no other DC, or any other object in the domain by that name.

Have checked it doesn’t exist in AD UC, sites and services, DNS areas – no mention of it anywhere.

When the laptop loads up, sometimes it is not possible to log in because it says something like” the domain is not available”, or “there is no authority to process the request” (I forget the exact message sorry). It also doesn’t show as being online or available on the network at all. 99% of the time a simple restart of the machine will then fix the problem and allow a user to authenticate and log in, I just don’t understand why it is happening with this one machine and having a reference to an old DC in the event logs is a bit concerning. The other 1% of the time more than 1 restart is required to fix it.

Leave it a little while (as short as a few hours sometimes) and the problem will happen all over again.

Источник

Netlogon event ID 5719 или событие групповой политики 1129 регистрируется при запуске участника домена

В этой статье решается ID события Netlogon 5719 или событие групповой политики 1129, которое регистрируется при запуске участника домена.

Применяется к: Windows 10 — все выпуски, Windows Server 2012 R2
Исходный номер КБ: 938449

Симптомы

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

Рассмотрим этот сценарий:

В этом сценарии при запуске компьютера в Windows 8.1 и более ранних версиях в журнале System регистрируется следующее событие. В Windows 10 и более поздних версиях событие 5719 больше не регистрируется в этой ситуации. Вместо этого в Netlogon.log записывают следующие строки:

После возникновения этой проблемы компьютеру назначен IP-адрес:

В Windows 10 и более поздних версиях вы увидите только события по компонентам в зависимости от подключения контроллера домена (например, групповой политики). В журнале отлагки групповой политики записывают следующие записи:

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

Во втором разделе показано, что осведомленность о расположении сети (NLA) не сообщает о рабочей сети в допустимом интервале ожидания, а обработка запуска групповой политики не удается. В третьем разделе показано, что двигатель групповой политики запускает фоновую процедуру, а затем ждет одну минуту после того, как сеть станет доступной.

Причина

Эта проблема может возникнуть по любой из этих причин:

Group Policy в Windows Vista и более поздних версиях написана для переговоров о сетевом состоянии с включенной поддержкой NLA. И она ждет сеть с подключением к DC. Однако групповая политика может начаться преждевременно из-за приложения политики. Это особенно актуально, когда задержка в поиске сети чередуется между стартапами.

При неправильном изменении реестра с использованием редактора реестра или другого способа могут случиться серьезные проблемы. Для решения этих проблем может потребоваться переустановка операционной системы. Компания Microsoft не может гарантировать, что эти проблемы могут быть решены. Вносите изменения в реестр на ваш страх и риск.

Разрешение 1

Чтобы устранить эту проблему, установите самый текущий драйвер для сетевого адаптера Gigabit. Или включить параметр PortFast в сетевых переключателях.

Разрешение 2

Чтобы устранить эту проблему, используйте реестр для изменения связанных параметров, влияющих на подключение к DC. Для этого используйте следующие методы.

Способ 1

Настройка параметров брандмауэра или политик IPSEC, которые изменены, чтобы разрешить подключение к dc. Эти изменения внесения, когда клиент получает IP-адрес, но требуется больше времени для доступа к контроллеру домена, например после успешной проверки через Cisco NAC или Microsoft NPS Services.

Способ 2

Настройте параметр реестра на значение, которое безопасно выходит за пределы требуемой времени, Netlogon позволяя подключаться к DC.

Это эффективно только в том случае, если на компьютере уже есть IP-адрес. Это относится к сценариям, когда решение NAP помещает машину в карантинную сеть. В качестве руководства используйте следующие параметры.

Подкайка реестра: HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNetlogonParameters
Имя значения: ExpectedDialupDelay
Тип данных: REG_DWORD
Значение данных в секундах (по умолчанию= 0)
Диапазон данных составляет от 0 до 600 секунд (10 минут)

Способ 3

Стек IP пытается проверить IP-адрес с помощью ARP-трансляции. Это задерживает время, которое требуется IP для того, чтобы выйти в интернет. Вы можете установить запись реестра ArpRetryCount до одной (1), поэтому ожидание уникальности сокращается. Для этого выполните следующие действия:

Откройте редактор реестра.

Найдите и выберите следующий подкай:
HKEY_LOCAL_MACHINESystemCurrentControlSetServicesTcpIpParameters

В меню Редактирование указать значение New, а затем выберите значение DWORD.

Щелкните правой кнопкой мыши ArpRetryCount запись реестра, а затем выберите Изменение.

В поле Значение данных введите 1, а затем выберите ОК.

Диапазон данных составляет от 0 до 3 (по умолчанию — 3).

Закройте редактор реестра.

Способ 4

Уменьшите период отрицательного кэша Netlogon, изменив запись реестра NegativeCachePeriod в следующем подкайке:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParametersNegativeCachePeriod

После этого изменения служба Netlogon не ведет себя так, как будто контроллеры домена отключены в течение 45 секунд. Событие 5719 по-прежнему регистрируется. Однако это событие не вызывает каких-либо других существенных проблем. Этот параметр позволяет участнику попробовать контроллеры домена раньше, если процесс не удалось ранее.

Предложение. Попробуйте установить низкое значение, например три секунды. В локальной среде можно использовать значение 0, чтобы отключить отрицательный кэш.

Дополнительные сведения об этом параметре см. в Параметры для минимизации периодического трафика WAN.

Метод 5

Настройте параметр реестра на значение, которое безопасно выходит за пределы требуемой времени, Kerberos позволяя подключаться к DC. В качестве руководства используйте следующие параметры.

Этот параметр применяется только к Windows XP и Windows Server 2003 или более ранних версий этих систем. Windows Vista и Windows Server 2008 и более поздние версии используют значение по умолчанию . Это значение отключит функции протокола пользовательских данных (UDP) для клиента Kerberos.

Подкайка реестра: HKEY_LOCAL_MACHINESystemCurrentControlSetControlLsaKerberosParameters
Имя значения: MaxPacketSize
Тип данных: REG_DWORD
Данные значения: 1
По умолчанию: (зависит от системной версии)

Метод 6

Отключить значение мультимедиа для TCP/IP, добавив следующее значение в подкайку Tcpip реестра:

Подкайка реестра: HKEY_LOCAL_MACHINESystemCurrentControlSetServicesTcpipParameters
Имя значения: ОтключениеDHCPMediaSense
Тип данных: REG_DWORD
Данные значения: 1
Диапазон значений: Boolean ( 0 =False, 1 =True)
По умолчанию: 0 (False)

Дополнительные сведения см. в дополнительных сведениях о том, как отключить функцию зондирования мультимедиа для TCP/IP в Windows.

Метод 7

Group Policy имеет параметры политики для управления временем ожидания для обработки политики запуска:

Корпоративный LAN или WLAN:

Папка политик: «Конфигурация компьютераАдминистративные шаблоныSystemGroup Policy»
Имя политики: «Укажите время ожидания обработки политики запуска»

Внешний LAN или WLAN:

Папка политик: «Конфигурация компьютераАдминистративные шаблоныSystemGroup Policy»
Имя политики: «Укажите время ожидания подключения к рабочим местам для обработки политики»

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

Метод 8

Если параметр реестра на месте и имеет неправильное значение DisabledComponents 0xfffffff, удалите ключ или измените его на предназначенное значение 0xff.

Версия 6 протокола Интернета (IPv6) является обязательной частью Windows Vista и более поздних версий Windows. Мы не рекомендуем отключить IPv6 или его компоненты. Если это так, некоторые Windows могут не функционировать. Кроме того, запуск системы будет отложен на пять секунд, если неправильно отключен IPv6, установив параметр реестра на DisabledComponents значение 0xfffffff. Правильное значение — 0xff.

Метод 9

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

Можно установить значение реестра, чтобы отложить применение групповой политики:

Откройте редактор реестра.

Найдите и выберите следующий подкай:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon

В меню Редактирование указать значение New, а затем выберите значение DWORD.

Щелкните правой кнопкой мыши GpNetworkStartTimeoutPolicyValue запись реестра, а затем выберите Изменение.

В базовой статье выберите десятичной знак.

В поле Данных Значения введите 60 и выберите ОК.

Закройте редактор реестра и перезагрузите компьютер.

Если сценарий запуска групповой политики не работает, увеличите значение GpNetworkStartTimeoutPolicyValue записи реестра.

Дополнительная информация

Если вы можете войти в домен без проблем, можно смело игнорировать ИД события 5719. Поскольку служба Netlogon может начаться до того, как сеть будет готова, компьютер может не найти контроллер домена logon. Поэтому регистрируется ИД события 5719. После того как сеть будет готова, компьютер снова попытается найти контроллер домена logon. В этой ситуации операция должна быть успешной.

В журнале Netogon.log записи, похожие на следующий пример, могут быть зарегистрированы:

Аналогичные ошибки могут быть допущены другими компонентами, которые требуют правильной работы контроллера домена. Например, групповая политика может не применяться при запуске системы. В этом случае сценарии запуска не запускают. Сбои групповой политики могут быть связаны с ошибкой Netlogon найти контроллер домена. Можно настроить групповую политику на более чувствительную реакцию на позднее подключение к сети.

Источник

Netlogon event ID 5719 or Group Policy event 1129 is logged when you start a domain member

This article solves the Netlogon event ID 5719 or Group Policy event 1129 that’s logged when you start a domain member.

Symptoms

Follow the steps in this section carefully. Serious problems might occur if you modify the registry incorrectly. Before you modify it, back up the registry for restoration in case problems occur.

Consider this scenario:

In this scenario, the following event is logged in the System log when you start the computer in Windows 8.1 and earlier versions. In Windows 10 and later versions, event 5719 is no longer logged in this situation. The following lines are recorded in Netlogon.log instead:

After this issue occurs, the computer is assigned an IP address:

On Windows 10 and later versions, you’ll see only events by components, depending on the Domain Controller connectivity (such as Group Policy). The following entries are recorded in the group policy debug log:

The first section shows the calculation for the time-out to use to bring up the network. It can be based on previous fast startups.

The second section shows that Network Location Awareness (NLA) fails to report a working network within the wait interval that’s allowed, and group policy startup processing fails. The third section shows that the Group Policy engine starts a background procedure, and then waits for one minute after a network becomes available.

Cause

This issue may occur for any of these reasons:

Group Policy in Windows Vista and later versions is written to negotiate the network status that has NLA enabled. And it waits for a network that has DC connectivity. However, Group Policy may start prematurely because of a policy application. This situation is especially true when the delay in finding a network alternates between startups.

Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

Resolution 1

To resolve this issue, install the most current driver for the Gigabit network adapter. Or, enable the PortFast option on the network switches.

Resolution 2

To resolve this issue, use the registry to change the related settings that affect DC connectivity. To do it, use the following methods.

Method 1

Adjust the firewall settings or IPSEC policies that are changed to allow DC connectivity. These changes are made when the client receives an IP address but requires more time to access a domain controller, for example, after a successful verification through Cisco NAC or Microsoft NPS Services.

Method 2

Configure the Netlogon registry setting to a value that is safely beyond the time that is required allow DC connectivity.

This is only effective if the machine already has an IP address. This applies to scenarios where a NAP solution puts the machine into a quarantine network. Use the following settings as guidelines.

Registry subkey: HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNetlogonParameters
Value Name: ExpectedDialupDelay
Data Type: REG_DWORD
Data Value is in seconds (default= 0 )
Data Range is between 0 and 600 seconds (10 minutes)

Method 3

The IP stack tries to verify the IP address using an ARP broadcast. It delays the time that the IP takes to come online. You can set the ArpRetryCount registry entry to one (1), so the wait for uniqueness is shortened. To do it, follow these steps:

Start Registry Editor.

Locate and select the following subkey:
HKEY_LOCAL_MACHINESystemCurrentControlSetServicesTcpIpParameters

On the Edit menu, point to New, and then select DWORD Value.

Right-click the ArpRetryCount registry entry, and then select Modify.

In the Value data box, type 1, and then select OK.

The Data Range is between 0 and 3 (3 is default).

Exit Registry Editor.

Method 4

Reduce the Netlogon negative cache period by changing the NegativeCachePeriod registry entry in the following subkey:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParametersNegativeCachePeriod

After you make this change, the Netlogon service doesn’t behave as if the domain controllers are offline for 45 seconds. The event 5719 is still logged. However, the event doesn’t cause any other significant problems. This setting allows member to try domain controllers earlier if the process failed previously.

Suggestion: Try to set a low value, such as three seconds. In LAN environments, you can use a value of 0 to turn off the negative cache.

For more information about this setting, see Settings for minimizing periodic WAN traffic.

Method 5

Configure the Kerberos registry setting to a value that is safely beyond the time that is required allow DC connectivity. Use the following settings as guidelines.

This setting applies only to Windows XP and Windows Server 2003 or earlier versions of these systems. Windows Vista and Windows Server 2008 and later versions use a default value of . This value turns off User Datagram Protocol (UDP) functionality for the Kerberos client.

Registry subkey: HKEY_LOCAL_MACHINESystemCurrentControlSetControlLsaKerberosParameters
Value name: MaxPacketSize
Data Type: REG_DWORD
Value Data: 1
Default: (depends on the system version)

Method 6

Disable media sense for TCP/IP by adding the following value to the Tcpip registry subkey:

Registry subkey: HKEY_LOCAL_MACHINESystemCurrentControlSetServicesTcpipParameters
Value Name: DisableDHCPMediaSense
Data Type: REG_DWORD
Value Data: 1
Value Range: Boolean ( 0 =False, 1 =True)
Default: 0 (False)

Method 7

Group Policy has policy settings to control the wait time for startup policy processing:

Corporate LAN or WLAN:

Policy Folder: «Computer ConfigurationAdministrative TemplatesSystemGroup Policy»
Policy Name: «Specify startup policy processing wait time»

External LAN or WLAN:

Policy Folder: «Computer ConfigurationAdministrative TemplatesSystemGroup Policy»
Policy Name: «Specify workplace connectivity wait time for policy processing»

The time it takes Netlogon to acquire a working IP can be the basis for the setting. For Direct Access scenarios, you can measure the typical delay your user base has until the connection is established.

Method 8

If DisabledComponents registry setting is in place and has an incorrect value of 0xfffffff, either delete the key or change it to the intended value of 0xff.

Internet Protocol version 6 (IPv6) is a mandatory part of Windows Vista and later versions of Windows. We do not recommend that you disable IPv6 or its components. If you do, some Windows components may not function. Additionally, system startup will be delayed for five seconds if IPv6 is disabled incorrectly by setting the DisabledComponents registry setting to a value of 0xfffffff. The correct value is 0xff.

Method 9

The behavior may be caused by a race condition between network initialization, locating a Domain Controller and processing Group Policy. If the network isn’t available, a Domain Controller won’t be located, and Group Policy processing will fail. Once the operating system has loaded and a network link is negotiated and established, background refresh of Group Policy will succeed.

You can set a registry value to delay the application of Group Policy:

Start Registry Editor.

Locate and select the following subkey:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon

On the Edit menu, point to New, and then select DWORD Value.

Right-click the GpNetworkStartTimeoutPolicyValue registry entry, and then select Modify.

Under Base, select Decimal.

In the Value data box, type 60, and then select OK.

Exit Registry Editor, and then restart the computer.

If the Group Policy startup script doesn’t run, increase the value of the GpNetworkStartTimeoutPolicyValue registry entry.

More information

If you can log on to the domain without a problem, you can safely ignore event ID 5719. Because the Netlogon service may start before the network is ready, the computer may be unable to locate the logon domain controller. Therefore, event ID 5719 is logged. After the network is ready, the computer will try again to locate the logon domain controller. In this situation, the operation should be successful.

In a Netogon.log, entries that resemble the following example may be logged:

Similar errors might be reported by other components that require Domain Controller connectivity to function correctly. For example, the Group Policy may not be applied at system startup. In this case, startup scripts don’t run. The Group Policy failures may be related to the failure of Netlogon to locate a domain controller. You can set Group Policy to be more responsive to late network connectivity arrival.

Источник

Netlogon event ID 5719 or Group Policy event 1129 is logged when you start a domain member

This article solves the Netlogon event ID 5719 or Group Policy event 1129 that’s logged when you start a domain member.

Symptoms

Follow the steps in this section carefully. Serious problems might occur if you modify the registry incorrectly. Before you modify it, back up the registry for restoration in case problems occur.

Consider this scenario:

In this scenario, the following event is logged in the System log when you start the computer in Windows 8.1 and earlier versions. In Windows 10 and later versions, event 5719 is no longer logged in this situation. The following lines are recorded in Netlogon.log instead:

After this issue occurs, the computer is assigned an IP address:

On Windows 10 and later versions, you’ll see only events by components, depending on the Domain Controller connectivity (such as Group Policy). The following entries are recorded in the group policy debug log:

The first section shows the calculation for the time-out to use to bring up the network. It can be based on previous fast startups.

The second section shows that Network Location Awareness (NLA) fails to report a working network within the wait interval that’s allowed, and group policy startup processing fails. The third section shows that the Group Policy engine starts a background procedure, and then waits for one minute after a network becomes available.

Cause

This issue may occur for any of these reasons:

Group Policy in Windows Vista and later versions is written to negotiate the network status that has NLA enabled. And it waits for a network that has DC connectivity. However, Group Policy may start prematurely because of a policy application. This situation is especially true when the delay in finding a network alternates between startups.

Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

Resolution 1

To resolve this issue, install the most current driver for the Gigabit network adapter. Or, enable the PortFast option on the network switches.

Resolution 2

To resolve this issue, use the registry to change the related settings that affect DC connectivity. To do it, use the following methods.

Method 1

Adjust the firewall settings or IPSEC policies that are changed to allow DC connectivity. These changes are made when the client receives an IP address but requires more time to access a domain controller, for example, after a successful verification through Cisco NAC or Microsoft NPS Services.

Method 2

Configure the Netlogon registry setting to a value that is safely beyond the time that is required allow DC connectivity.

This is only effective if the machine already has an IP address. This applies to scenarios where a NAP solution puts the machine into a quarantine network. Use the following settings as guidelines.

Registry subkey: HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNetlogonParameters
Value Name: ExpectedDialupDelay
Data Type: REG_DWORD
Data Value is in seconds (default= 0 )
Data Range is between 0 and 600 seconds (10 minutes)

Method 3

The IP stack tries to verify the IP address using an ARP broadcast. It delays the time that the IP takes to come online. You can set the ArpRetryCount registry entry to one (1), so the wait for uniqueness is shortened. To do it, follow these steps:

Start Registry Editor.

Locate and select the following subkey:
HKEY_LOCAL_MACHINESystemCurrentControlSetServicesTcpIpParameters

On the Edit menu, point to New, and then select DWORD Value.

Right-click the ArpRetryCount registry entry, and then select Modify.

In the Value data box, type 1, and then select OK.

The Data Range is between 0 and 3 (3 is default).

Exit Registry Editor.

Method 4

Reduce the Netlogon negative cache period by changing the NegativeCachePeriod registry entry in the following subkey:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParametersNegativeCachePeriod

After you make this change, the Netlogon service doesn’t behave as if the domain controllers are offline for 45 seconds. The event 5719 is still logged. However, the event doesn’t cause any other significant problems. This setting allows member to try domain controllers earlier if the process failed previously.

Suggestion: Try to set a low value, such as three seconds. In LAN environments, you can use a value of 0 to turn off the negative cache.

For more information about this setting, see Settings for minimizing periodic WAN traffic.

Method 5

Configure the Kerberos registry setting to a value that is safely beyond the time that is required allow DC connectivity. Use the following settings as guidelines.

This setting applies only to Windows XP and Windows Server 2003 or earlier versions of these systems. Windows Vista and Windows Server 2008 and later versions use a default value of 0. This value turns off User Datagram Protocol (UDP) functionality for the Kerberos client.

Registry subkey: HKEY_LOCAL_MACHINESystemCurrentControlSetControlLsaKerberosParameters
Value name: MaxPacketSize
Data Type: REG_DWORD
Value Data: 1
Default: (depends on the system version)

Method 6

Disable media sense for TCP/IP by adding the following value to the Tcpip registry subkey:

Registry subkey: HKEY_LOCAL_MACHINESystemCurrentControlSetServicesTcpipParameters
Value Name: DisableDHCPMediaSense
Data Type: REG_DWORD
Value Data: 1
Value Range: Boolean ( 0 =False, 1 =True)
Default: 0 (False)

Method 7

Group Policy has policy settings to control the wait time for startup policy processing:

Corporate LAN or WLAN:

Policy Folder: «Computer ConfigurationAdministrative TemplatesSystemGroup Policy»
Policy Name: «Specify startup policy processing wait time»

External LAN or WLAN:

Policy Folder: «Computer ConfigurationAdministrative TemplatesSystemGroup Policy»
Policy Name: «Specify workplace connectivity wait time for policy processing»

The time it takes Netlogon to acquire a working IP can be the basis for the setting. For Direct Access scenarios, you can measure the typical delay your user base has until the connection is established.

Method 8

If DisabledComponents registry setting is in place and has an incorrect value of 0xfffffff, either delete the key or change it to the intended value of 0xff.

Internet Protocol version 6 (IPv6) is a mandatory part of Windows Vista and later versions of Windows. We do not recommend that you disable IPv6 or its components. If you do, some Windows components may not function. Additionally, system startup will be delayed for five seconds if IPv6 is disabled incorrectly by setting the DisabledComponents registry setting to a value of 0xfffffff. The correct value is 0xff.

Method 9

The behavior may be caused by a race condition between network initialization, locating a Domain Controller and processing Group Policy. If the network isn’t available, a Domain Controller won’t be located, and Group Policy processing will fail. Once the operating system has loaded and a network link is negotiated and established, background refresh of Group Policy will succeed.

You can set a registry value to delay the application of Group Policy:

Start Registry Editor.

Locate and select the following subkey:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon

On the Edit menu, point to New, and then select DWORD Value.

Right-click the GpNetworkStartTimeoutPolicyValue registry entry, and then select Modify.

Under Base, select Decimal.

In the Value data box, type 60, and then select OK.

Exit Registry Editor, and then restart the computer.

If the Group Policy startup script doesn’t run, increase the value of the GpNetworkStartTimeoutPolicyValue registry entry.

More information

If you can log on to the domain without a problem, you can safely ignore event ID 5719. Because the Netlogon service may start before the network is ready, the computer may be unable to locate the logon domain controller. Therefore, event ID 5719 is logged. After the network is ready, the computer will try again to locate the logon domain controller. In this situation, the operation should be successful.

In a Netogon.log, entries that resemble the following example may be logged:

Similar errors might be reported by other components that require Domain Controller connectivity to function correctly. For example, the Group Policy may not be applied at system startup. In this case, startup scripts don’t run. The Group Policy failures may be related to the failure of Netlogon to locate a domain controller. You can set Group Policy to be more responsive to late network connectivity arrival.

Источник

Устранение проблем с профилями пользователей с помощью событий

Область применения: Windows Server 2022, Windows 10, Windows 8, Windows 8.1, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012.

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

Шаг 1. Проверка событий в журнале приложений

Первый шаг в устранении проблем, связанных с загрузкой и выгрузкой профилей пользователей (в том числе перемещаемых профилей пользователей), заключается в использовании компонента «Просмотр событий» для проверки всех событий предупреждений и ошибок, которые записываются службой профилей пользователей в журнал приложений.

Вот как можно просмотреть события служб профилей пользователей в журнале приложений.

Можно спокойно проигнорировать событие службы профилей пользователей 1530 «Windows detected your registry file is still in use by other applications or services.» (Система Windows обнаружила, что файл реестра все еще используют другие приложения или службы).

Шаг 2. Просмотр операционного журнала для службы профилей пользователей

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

Журнал приложений и операционный журнал службы профилей пользователей Windows включены по умолчанию во всех установках Windows.

Вот как просмотреть операционный журнал для службы профилей пользователей:

Шаг 3. Включение и просмотр журналов аналитики и отладки

Если требуется больше сведений, чем в операционном журнале, можно включить журналы аналитики и отладки на затронутом компьютере. Эти журналы предоставляют более подробные сведения. Они должны быть отключены, за исключением случаев, когда вы пытаетесь устранить проблему.

Вот как включить и просмотреть журналы аналитики и отладки:

Шаг 4. Создание и декодирование трассировки

Если не удается устранить проблему с помощью событий, можно создать журнал трассировки (ETL-файл) при воспроизведении проблемы, а затем декодировать его с помощью общедоступных символов с сервера символов (Майкрософт). Журналы трассировки предоставляют конкретные сведения о том, что делает служба профилей пользователей, и могут помочь выявить место возникновения сбоя.

Оптимальная стратегия использования трассировки ETL — сначала записывать наименьшие возможные журналы. После декодирования журнала выполните поиск ошибок в нем.

Вот как создать и декодировать трассировку для службы профилей пользователей:

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

В командной строке с повышенными привилегиями введите следующие команды, где

— это путь к локальной папке, созданной ранее, например, C:logs:

На начальном экране выберите имя пользователя, а затем выберите команду Переключить учетную запись, будьте внимательны и не выходите из учетной записи администратора. Если вы используете удаленный рабочий стол, закройте сеанс администратора, чтобы установить сеанс пользователя.

Воспроизведите проблему. Эта процедура обычно заключается в том, чтобы войти в систему в качестве пользователя, испытывающего проблему, выйти из системы, или и то, и другое.

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

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

Введите следующую команду, чтобы экспортировать ETL-файл в файл, доступный для чтения, в текущем каталоге (возможно, в домашней папке или папке %WINDIR%System32):

Источник

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I am not sure if this is the right place to put this question but hopefully someone can move it for me if it isn’t.

I am receiving the following two events in the system event log on one particular machine, I have already re-installed this from scratch once (I didn’t remove the AD computer object, it just reused it as I thought it might be a computer related problem at first not AD, but I’m beginning to think otherwise now).

The TERMSRV mentioned in the second event log is an old server which has been removed from the domain a long long time ago now, I think about two years ago. The object no longer exists in AD or DNS and I don’t know where else to look to ensure it’s no longer present.

The event logs are:

The processing of Group Policy failed because of lack of network connectivity to a domain controller. This may be a transient condition. A success message would be generated once the machine gets connected to the domain controller and Group Policy has succesfully processed. If you do not see a success message for several hours, then contact your administrator.

Source: Group Policy

The terminal server cannot register ‘TERMSRV’ Service Principal Name to be used for server authentication. The following error occured: The specified domain either does not exist or could not be contacted.

Answers

as you are now stating this machine is SBS version please use the SBS forum instead this one:

Too many steps are different when it goes into detailed configuration settings.

All replies

I have not understood well what is the problem exactly.

For the faulty computer try to re-join it to the domain and check if all is okay or not.

For event ID 1129, refer to this Microsoft article:

For event ID 1067, refer to this Microsoft article:

Please make sure that you client computer is pointing to the correct internal DNS server as primary one and use nslookup to check that you don’t have DNS resolution problems.

Microsoft Student Partner

Microsoft Certified Professional
Microsoft Certified Systems Administrator: Security
Microsoft Certified Systems Engineer: Security
Microsoft Certified Technology Specialist: Windows Server 2008 Active Directory, Configuration
Microsoft Certified Technology Specialist: Windows Server 2008 Network Infrastructure, Configuration

Event id 1129 says about failed DC connectivity, it can be bad NIC or firewall blocking the ports or issue in the port at the swicth, so its better you need to verify the connectivity issues.

Event ID 1067 is more related to Spn issue.

Regards

Disclaimer : This posting is provided AS-IS with no warranties or guarantees and confers no rights.

the machine you are talking about is a DC and was it already before reinstalling, please elaborate especially about the not removeal of it in AD UC?

If TERMSRV is not longer existing use metadata cleanup to remvoe it. This name you can NOT use as DC without having problems:

If you have used the TERMSRV again for anew DC when the old exist in the database remove it run metadata cleanup and do a format of this server and start fresh after checking that the name no where exist anymore, AD UC, AD sites and services and DNS zones and zone properties.

Thank you for your replies. As requested I will supply further information:

The client workstation is running Windows 7 Professional SP1 (I had experienced problems before SP1 was installed with regards to connecting to the domain).

There is only one DC and it runs Server 2008 Standard SP2.

No other machines in the network suffer from this problem, the NIC is an integrated wired NIC on a laptop so I really hope that the NIC isn’t faulty, any way I can determine this?

The DC is up and running and ready for the domain before the client machines attempt to connect.

TERMSRV was an old DC back when our network used 2003, it was removed from the domain before moving to 2008 – is it possible it didn’t get cleaned up on 2003 properly and it is still existing in the Active Directory database somewhere? How can I check? There is no other DC, or any other object in the domain by that name.

Have checked it doesn’t exist in AD UC, sites and services, DNS areas – no mention of it anywhere.

When the laptop loads up, sometimes it is not possible to log in because it says something like” the domain is not available”, or “there is no authority to process the request” (I forget the exact message sorry). It also doesn’t show as being online or available on the network at all. 99% of the time a simple restart of the machine will then fix the problem and allow a user to authenticate and log in, I just don’t understand why it is happening with this one machine and having a reference to an old DC in the event logs is a bit concerning. The other 1% of the time more than 1 restart is required to fix it.

Leave it a little while (as short as a few hours sometimes) and the problem will happen all over again.

Источник

Ошибки Userenv возникают и события регистрируются после применения групповой политики к компьютерам, работающим Windows Server 2003, Windows XP или Windows 2000 г.

В этой статье данная статья позволяет решить проблемы, из-за которых компьютеры в сети не могут подключаться к объектам групповой политики (GPO) в папках Sysvol на контроллерах сетевых доменов.

Применяется к: Windows 10 — все выпуски, Windows Server 2012 R2
Исходный номер КБ: 887303

Сводка

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

Симптомы

Вы испытываете один или несколько следующих симптомов на компьютере с microsoft Windows Server 2003, Microsoft Windows XP или Microsoft Windows 2000:

Параметры групповой политики не применяются к компьютерам.

Репликация групповой политики не завершена между контроллерами домена в сети.

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

Если вы пытаетесь открыть оснастку групповой политики, вы получите одно из следующих сообщений об ошибке:

Не удалось открыть объект групповой политики. Возможно, у вас нет соответствующих прав.
Сведения. Учетная запись не разрешена для входа с этой станции.

У вас нет разрешения на выполнение этой операции.
Сведения. Доступ отказано.

Не удалось открыть объект групповой политики. Возможно, у вас нет соответствующих прав.
Сведения. Система не может найти указанный путь.

Если вы пытаетесь получить доступ к общим файлам на любом контроллере домена, вы получите сообщение об ошибке. Этот симптом возникает, даже если вы вошли на сервер, и вы пытаетесь получить доступ к локальной акции. В частности, этот симптом может повлиять на доступ к совместной информации Sysvol контроллера домена.

Если вы пытаетесь получить доступ к файлу, вам неоднократно был предложен пароль.

Если вы пытаетесь получить доступ к файлу, вы получите сообщение об ошибке, аналогичное одному из следующих сообщений об ошибке:

Server_Name Share_Name недоступны. Возможно, у вас нет разрешения на использование этого сетевого ресурса. Обратитесь к администратору этого сервера, чтобы узнать, есть ли у вас разрешения на доступ.
Учетная запись не разрешена для входа с этой станции.

Server_Name Share_Name недоступны.
Учетная запись не разрешена для входа с этой станции.

Если просмотреть журнал приложения в viewer событий на Windows XP или Windows Server 2003, вы увидите события, аналогичные следующим событиям:

Источник событий: Userenv
Категория событий: Нет
ID события: 1058

Сообщение об ошибке, которое отображается в Error_Message в Event ID 1058, может быть любым из следующих сообщений об ошибке:

Сведения о конфигурации не могут быть прочитаны с контроллера домена либо из-за недоступности компьютера, либо отказано в доступе.

Как правило, если происходит событие ID 1058 и Event ID 1030, они регистрируются на клиентских компьютерах и серверах-участниках при старте компьютера. Контроллеры домена регистраторы этих событий каждые пять минут.

Если вы просматривали журнал приложения в viewer событий на компьютере Windows 2000, вы увидите события, аналогичные следующим событиям:

Тип события: Ошибка
Источник событий: Userenv

Код ошибки, который отображается в Error_Code в Event ID 1000, может быть любым из следующих кодов ошибок:

Причина

Эти проблемы возникают, если компьютеры, подключенные к сети, не могут подключиться к определенным объектам групповой политики. В частности, эти объекты находятся в папках Sysvol в контроллерах домена вашей сети.

Решение

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

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

Шаг 1. Изучение параметров DNS и свойств сети на серверах и клиентских компьютерах

В свойствах подключения к локальной области клиент для Microsoft Networks должен быть включен на всех серверах и клиентских компьютерах. Компонент Общего доступа к файлам и принтерам для Microsoft Networks должен быть включен на всех контроллерах домена.

Кроме того, каждый компьютер в сети должен использовать DNS-серверы, которые могут разрешать записи SRV и имена хостов для леса Active Directory, в котором компьютер является участником. Как правило, частой ошибкой конфигурации для клиентских компьютеров является использование DNS-серверов, принадлежащих поставщику интернет-услуг (ISP).

На всех компьютерах, которые зарегистрировали ошибки Userenv, изучите параметры DNS и свойства сети. Кроме того, проверьте эти параметры на всех контроллерах домена, регистрировка ошибок Userenv или нет.

Чтобы проверить параметры DNS и свойства сети на Windows компьютерах на основе XP в сети, выполните следующие действия:

Чтобы проверить параметры DNS и свойства сети на Windows 2000 компьютеров в сети, выполните следующие действия:

Выберите Начните, указать Параметры, а затем выберите панель управления.

Дважды щелкните подключение к сети и диалогу.

Щелкните правой кнопкой мыши локальное подключение к области, а затем выберите свойства.

На вкладке Общие щелкните, чтобы выбрать поле «Клиент для Microsoft Networks».

Если компьютер является контроллером домена, щелкните, чтобы выбрать файл и обмен принтерами для microsoft Networks.

На серверах удаленного доступа с несколькими домами и серверах microsoft Internet Security and Acceleration (ISA) server можно отключить компонент File and Printer Sharing for Microsoft Networks для сетевого адаптора, подключенного к Интернету. Однако компонент Client for Microsoft Networks должен быть включен для всех сетевых адаптеров сервера.

Выберите протокол Интернета (TCP/IP) и нажмите кнопку Свойства.

Если выбраны следующие DNS-адреса сервера, убедитесь, что IP-адреса предпочтительных и альтернативных DNS-серверов являются IP-адресами DNS-серверов, которые могут разрешать записи SRV и имена хостов в Active Directory. В частности, компьютер не должен использовать DNS-серверы, принадлежащие вашему isP. Если адреса DNS-сервера не верны, введите IP-адреса правильных DNS-серверов в предпочтительных DNS-серверах и альтернативных DNS-серверах.

Выберите Расширенный, а затем выберите вкладку DNS.

Щелкните, чтобы выбрать адреса этого подключения в поле DNS, а затем выберите ОК три раза.

Запуск командной подсказки. Чтобы сделать это, выберите Начните, выберите Выполнить, введите cmd в поле Открыть, а затем выберите ОК.

Введите ipconfig /flushdns и нажмите кнопку ENTER. Введите ipconfig /registerdns и нажмите кнопку ENTER.

Чтобы проверить параметры DNS и свойства сети на компьютерах на Windows Server 2003 в сети, выполните следующие действия:

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

Щелкните правой кнопкой мыши локальное подключение области, а затем выберите Свойства.

На вкладке Общие щелкните, чтобы выбрать поле «Клиент для Microsoft Networks».

Если компьютер является контроллером домена, щелкните, чтобы выбрать файл и обмен принтерами для microsoft Networks.

На нескольких домашних серверах удаленного доступа и серверах на основе ISA Server можно отключить компонент File and Printer Sharing for Microsoft Networks для сетевого адаптора, подключенного к Интернету. Однако компонент Client for Microsoft Networks должен быть включен для всех сетевых адаптеров сервера.

Выберите протокол Интернета (TCP/IP) и выберите свойства.

Если выбраны следующие DNS-адреса сервера, убедитесь, что IP-адреса предпочтительных и альтернативных DNS-серверов являются IP-адресами DNS-серверов, которые могут разрешать записи SRV и имена хостов в Active Directory. В частности, компьютер не должен использовать DNS-серверы, принадлежащие вашему isP. Если адреса DNS-сервера не верны, введите IP-адреса правильных DNS-серверов в предпочтительных DNS-серверах и альтернативных DNS-серверах.

Выберите Расширенный, а затем выберите вкладку DNS.

Щелкните, чтобы выбрать адреса этого подключения в поле DNS, а затем выберите ОК три раза.

Запуск командной подсказки. Чтобы сделать это, выберите Начните, выберите Выполнить, введите cmd, а затем выберите ОК.

Введите ipconfig /flushdns и нажмите кнопку ENTER. Введите ipconfig /registerdns и нажмите кнопку ENTER.

Перезапустите компьютер, чтобы изменения вступили в силу.

Если клиентские компьютеры в вашей сети настроены на автоматическое получение IP-адресов, убедитесь, что компьютер, на который работает служба DHCP, назначает IP-адреса DNS-серверов, которые могут разрешать записи SRV и имена хостов в Active Directory.

Чтобы определить IP-адреса компьютера для DNS, выполните следующие действия:

Если компьютеры, настроенные для автоматического получения IP-адресов, не используют правильные DNS-серверы, просматривайте документацию для сервера DHCP для получения сведений о настройке параметра DNS-серверов. Кроме того, убедитесь, что каждый компьютер может разрешить IP-адрес домена. Для этого введите пинг-Your_Domain_Name. Your_Domain_Root по командной подсказке, а затем нажмите кнопку ENTER. Вместо этого введите nslookup Your_Domain_Name. Your_Domain_Root и нажмите кнопку ENTER.

Ожидается, что это имя хоста будет разрешать IP-адрес одного из контроллеров домена в сети. Если компьютер не может разрешить это имя, или если имя уладит неправильный IP-адрес, убедитесь, что зона передовая проверка домена содержит допустимые (такие же, как и родительские папки) записи host (A).

Чтобы убедиться в том, что зона forward lookup для домена содержит допустимые (такие же, как и родительские папки) записи host (A) на компьютере на Windows 2000 года, выполните следующие действия:

На контроллере домена, который работает DNS, выберите Начните, указать на программы, указать на административные средства, а затем выберите DNS.

Раздвигайте Your_Server_Name, раздвигайте зоны досмотра, а затем выберите зону forward lookup для вашего домена.

Наймите (то же самое, что и родительские папки) Записи хоста (A).

Если записи host (A) (так же, как и родительской папки) не существует, выполните следующие действия, чтобы создать одну из них:

(как и родительская папка) не является допустимым именем хоста. Вы уверены, что хотите добавить эту запись?

Дважды щелкните запись (так же, как и родительская папка) Host (A).

Убедитесь, что правильный IP-адрес указан в поле IP-адресов.

Если IP-адрес в поле IP-адреса не является допустимым, введите правильный IP-адрес в поле IP-адрес, а затем выберите ОК.

Вместо этого можно удалить запись host (A), содержащей IP-адрес, который не является допустимым. Чтобы удалить запись (так же, как и запись родительской папки) Host (A), нажмите правой кнопкой мыши и выберите Удалить.

Если DNS-сервер является контроллером домена, который также является сервером маршрутиза и удаленного доступа, см. в нем проблемы с разрешением имен и подключением на сервере маршрутов и удаленного доступа, который также выполняет DNS или WINS.

На всех компьютерах, на которых вы добавляете, удаляете или измените записи DNS, введите ipconfig/flushdns по командной подсказке и нажмите кнопку ENTER.

Чтобы убедиться, что зона forward lookup для домена содержит допустимые (такие же, как и родительские папки) записи host (A) на компьютере на Windows Server 2003, выполните следующие действия:

На контроллере домена, который работает DNS, выберите Начните, указать на административные средства, а затем выберите DNS.

Раздвигайте Your_Server_Name, раздвигайте зоны досмотра, а затем выберите зону forward lookup для вашего домена.

Наймите запись (так же, как и родительская папка) Host (A).

Если записи host (A) не существует (так же, как и родительской папки), выполните следующие действия, чтобы создать одну из них:

(как и родительская папка) не является допустимым именем хоста. Вы уверены, что хотите добавить эту запись?

Дважды щелкните запись (так же, как и родительская папка) Host (A).

Убедитесь, что правильный IP-адрес указан в поле IP-адресов.

Если IP-адрес в поле IP-адреса не является допустимым, введите правильный IP-адрес в поле IP-адрес, а затем выберите ОК.

Вместо этого можно удалить запись (так же, как и родительская папка) Host (A), содержащей IP-адрес, который не является допустимым. Чтобы удалить запись Host (A), щелкните правой кнопкой мыши (так же, как родительская папка) и выберите Удалить.

Если DNS-сервер является контроллером домена, который также является сервером маршрутиза и удаленного доступа, см. в нем проблемы с разрешением имен и подключением на сервере маршрутов и удаленного доступа, который также выполняет DNS или WINS.

На всех компьютерах, на которых вы добавляете, удаляете или измените записи DNS, введите ipconfig/flushdns по командной подсказке и нажмите кнопку ENTER.

Шаг 2. Просмотр параметров подписи блока сообщений сервера на клиентских компьютерах и серверах-членах

Параметры подписи блока сообщений сервера определяют, подписывают ли компьютеры в сети цифровые сообщения. Если параметры подписи SMB настроены неправильно, клиентские компьютеры или серверы-члены могут не подключиться к контроллерам домена.

Например, для подписания SMB могут потребоваться контроллеры домена, но подписание SMB может быть отключено на клиентских компьютерах. Если эта проблема возникает, групповая политика не может быть применена правильно. Таким образом, клиентские компьютеры журнал пользовательской среды (Userenv) ошибки в журнале приложения. Иногда параметры подписи SMB для службы Server и службы рабочих станций на контроллере домена могут конфликтовывать друг с другом.

Например, подписание SMB может быть отключено для службы рабочих станций контроллера домена, но для службы сервера контроллера домена требуется подписание SMB. В этом сценарии нельзя открыть одну или несколько локальных файлов контроллера домена, если вы вошли на сервер. Кроме того, нельзя открывать оснастки групповой политики, если вы вошли на сервер.
Дополнительные сведения о том, как устранить эту проблему на контроллере домена, см. в материалах, которые нельзя открыть в контроллере домена.

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

По умолчанию подписание SMB включено, но не требуется для клиентской связи на клиентских компьютерах и серверах-участниках, которые работают Windows XP, Windows 2000 или Windows Server 2003. Мы рекомендуем использовать конфигурацию по умолчанию, так как клиентские компьютеры могут использовать подписку на SMB, когда это возможно, но будут по-прежнему взаимодействовать с серверами, у них отключено подписание SMB.

Чтобы настроить клиентские компьютеры и серверы участников так, чтобы регистрация SMB включена, но не требуется, необходимо изменить значения для некоторых записей реестра. Чтобы изменить реестр на клиентских компьютерах, выполните следующие действия:

После изменения значений реестра перезапустите службы Server и Workstation. Не перезапуска компьютеров, так как это может привести к применении групповых политик, а параметры групповой политики могут снова настроить противоречивые значения.

После изменения значений реестра и перезапуска служб серверов и рабочих станций на затронутых компьютерах выполните следующие действия:

На компьютере, который Windows Server 2003, параметры групповой политики подписи SMB имеют следующие имена:

На компьютере, на Windows сервере 2000, параметры групповой политики подписи SMB имеют следующие имена:

Как правило, параметры групповой политики подписываемых SMB настроены как «Not Defined». Если вы определяете параметры групповой политики подписи SMB, убедитесь, что вы понимаете, как эти параметры могут повлиять на подключение к сети.
Дополнительные сведения о параметрах подписи SMB см. в статью Клиент, служба и программа, если вы измените параметры безопасности и назначения прав пользователей.

Если вы измените параметры GPO на контроллере домена, который работает Windows 2000 Server, выполните следующие действия:

Если вы измените параметры GPO на контроллере домена, который работает Windows Server 2003, выполните следующие действия:

Если значения подписи SMB в реестре неожиданно изменяются после перезапуска клиентских компьютеров, используйте один из следующих методов, чтобы просмотреть параметры политики, применяемые на клиентский компьютер:

На компьютере Windows XP используйте набор привязки MMC политики resultant (Rsop.msc). Дополнительные сведения об итоговом наборе политики см. в дополнительных сведениях о наборе политики resultant.

В Windows 2000 г. используйте Gpresult.exe командной строки для изучения результатов групповой политики. Для этого выполните следующие действия:

Установка Gpresult.exe из набора Windows 2000 ресурсов.

В командной подсказке введите компьютер gpresult/scope и нажмите кнопку ENTER.

В разделе Объекты прикладной групповой политики вывода обратите внимание на объекты групповой политики, которые применяются к учетной записи компьютера.

Сравните объекты групповой политики, которые применяются к компьютерной учетной записи, которая имеет параметры политики подписи SMB на контроллере домена для этих объектов групповой политики.

Шаг 3. Убедитесь, что служба помощника TCP/IP NetBIOS запущена на всех компьютерах

Все компьютеры в сети должны запускать службу помощника TCP/IP NetBIOS.

Чтобы убедиться, что служба помощника TCP/IP NetBIOS работает на компьютере Windows XP, выполните следующие действия:

Чтобы убедиться, что служба помощника TCP/IP NetBIOS работает на компьютере на Windows Server 2003, выполните следующие действия:

Чтобы убедиться, что служба помощника TCP/IP NetBIOS работает на компьютере на Windows 2000, выполните следующие действия:

Кроме того, убедитесь, что вы не отключили одну или несколько необходимых системных служб с помощью объектов групповой политики. Просмотр этих параметров политики с помощью редактора объектов групповой политики в Computer Configuration/Windows Settings/Security Settings/System Services папке.

На Windows Server 2003 и Windows XP можно использовать набор результативных MMC политики snap-in (Rsop.msc) для проверки всех примененных параметров политики, применяемых к компьютеру. Для этого выберите Начните, выберите Выполнить, введите rsop.msc в поле Открыть, а затем выберите ОК.

В Windows 2000 г. используйте Gpresult.exe командной строки для изучения результатов групповой политики. Для этого выполните следующие действия:

Если служба помощника TCP/IP NetBIOS отключена на многих настольных компьютерах, вы можете использовать следующий пример сценария Microsoft Visual Basic для запуска службы помощника TCP/IP NetBIOS на всех компьютерах в организационном подразделении (OU) одновременно.

Корпорация Майкрософт предоставляет примеры программирования только в целях демонстрации без явной или подразумеваемой гарантии. Это включает в себя, но не ограничивается, подразумеваемые гарантии торговой доступности или пригодности для определенной цели. В этой статье предполагается, что вы знакомы с демонстрируемого языка программирования и с средствами, используемыми для создания и отлагирования процедур. Инженеры службы поддержки Майкрософт могут помочь объяснить функциональность конкретной процедуры, но они не будут изменять эти примеры, чтобы предоставить дополнительные функциональные возможности или создать процедуры для удовлетворения ваших конкретных требований.

Шаг 4. Убедитесь, что распределенная файловая система (DFS) включена на всех компьютерах

Все контроллеры домена должны запускать службу распределенной файловой системы, так как доля Sysvol — это объем DFS. Кроме того, клиент DFS должен быть включен в реестр на всех компьютерах.

Чтобы убедиться, что служба распределенной файловой системы работает на контроллерах домена на Windows Server 2003, выполните следующие действия:

Чтобы убедиться, что служба распределенной файловой системы работает на Windows контроллеров домена на основе сервера, выполните следующие действия:

Чтобы убедиться, что клиент распределенной файловой системы включен на всех клиентских компьютерах, выполните следующие действия:

Шаг 5. Изучение содержимого и разрешений папки Sysvol

По умолчанию папка Sysvol расположена в %systemroot% папке. Папка Sysvol содержит объекты групповой политики домена, акции Sysvol и Netlogon, а также папку постановок службы репликации файлов (FRS).

Если разрешения на папку Sysvol или на совместной основе Sysvol слишком строгие, групповые политики не могут применяться правильно и вызывают ошибки среды пользователя (Userenv). Кроме того, ошибки Userenv могут возникать, если отсутствуют объекты совместной или групповой политики Sysvol.
Чтобы убедиться, что доля Sysvol доступна, запустите команду чистой доли по командной подсказке на каждом контроллере домена. Для этого выполните следующие действия:

Дополнительные сведения о восстановлении доли Sysvol в Windows Server 2003 см. в разделЕ Как восстановить дерево SYSVOLи его содержимое в домене.

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

Кроме того, Windows 2000 Server группе Everyone должно быть предоставлено полное разрешение на полный контроль в корневой папке тома, который содержит папку Sysvol. На Windows Server 2003 группе Everyone необходимо предоставить специальное разрешение На чтение & Выполнить специальное разрешение на «Только эта папка», а группе domainUsers должны быть предоставлены следующие стандартные разрешения:

Кроме того, Windows Server 2003 группа domainUsers должна иметь следующие специальные разрешения:

После проверки разрешений Sysvol убедитесь, что папка Sysvol содержит необходимые объекты групповой политики. Чтобы найти необходимые объекты групповой политики, используйте Gpotool.exe из Windows 2000 или набора ресурсов Windows Server 2003.

Если вы запустите Gpotool.exe без каких-либо параметров, она сканирует все объекты групповой политики на всех контроллерах домена в домене. Если включить переключатель, средство также сканирует список управления доступом /checkacl Sysvol (ACL). Для подробных выводов при Gpotool.exe программы используйте /verbose переключатель.

Вместо этого можно вручную проверить отдельный GPO в папке SYSVOL. Например, если в описании события Userenv 1058 указано имя GPO, можно вручную проверить отдельный GPO в папке SYSVOL. Это можно сделать, чтобы убедиться, что она содержит папку USER, папку MACHINE и Gpt.ini файл. Чтобы вручную проверить отдельный GPO в папке SYSVOL, выполните следующие действия:

Если один или несколько объектов групповой политики отсутствуют в папке Sysvol, запустите утилиту восстановления групповой политики по умолчанию Windows Server 2003 (Dcgpofix.exe) или средство восстановления групповой политики по умолчанию 2000 Windows (Recreatedefpol.exe), чтобы повторно создать объекты групповой политики по умолчанию.

Программа Dcgpofix.exe включена в Windows Server 2003. Дополнительные сведения о программе Dcgpofix.exe, запустите dcgpofix /? команду по командной подсказке.

Не забудьте установить рекомендуемые исключения при сканировании диска Sysvol с помощью антивирусного программного обеспечения. Сканирование с помощью антивирусного программного обеспечения может блокировать доступ к требуемой папке, например к Gpt.ini файлу. Эти исключения необходимо настроить для всех запланированных и ручных антивирусных сканов в режиме реального времени.

Шаг 6. Убедитесь, что право проверки обхода обхода предоставляется требуемой группе

Право проверки обхода обхода должно предоставляться следующим группам контроллеров домена:

Чтобы убедиться, что право проверки обхода обхода предоставлено на контроллере домена на Windows Server 2003, выполните следующие действия:

Чтобы убедиться, что право проверки обхода обхода предоставлено на контроллере домена Windows 2000 на основе сервера, выполните следующие действия:

Шаг 7. Убедитесь, что контроллеры домена не в состоянии обертки журнала

Чтобы узнать, находится ли контроллер домена в состоянии обертки журнала, просмотреть журнал службы репликации файлов в viewer событий и найти ID события NTFRS 13568. Event ID 13568 похож на следующий ID события:
Если ID событий NTFRS 13568 регистрируется в контроллере домена, дополнительные сведения о том, как устранить ошибки обертки журнала, см. в journal_wrap устранения ошибок в наборах реплик Sysvol и DFS.

Источник

• Is your Domain Controller multi-homed? If so try disabling the network adapter that is not connected to your domain and see what happens. If the secondary NIC is required try changing the preferences order and see if that helps with the issues.

  
  Was this post helpful?
  thumb_up
  thumb_down
  

• Sean Donnelly wrote:

  Is your Domain Controller multi-homed? …

  You never want to multi-home a DC. That can cause all kinds of replication and many other errors.

  
  Was this post helpful?
  thumb_up
  thumb_down