Event ID 5719 and event ID 1129 may be logged when a non-Microsoft DHCP Relay Agent is used

Applies to: Windows 7 EnterpriseWindows 7 ProfessionalWindows 7 Ultimate


Windows 7 clients experience a three to five second delay in obtaining an IP address through Dynamic Host Configuration Protocol (DHCP) at restart. This behavior occurs when the clients are DHCP-enabled and domain-joined. This results in Netlogon event ID 5719 and Group Policy event ID 1129. You may experience this issue if the Windows 7 DHCP client is communicating with a Microsoft Windows-based DHCP Server through a non-Microsoft Relay Agent, such as a Layer 3 network switch.

DHCP-Client Operational logs, if it is enabled, will record event ID 50024 at restart time. This indicates that a DHCP Request time-out occurred.

The issue does not occur if the Windows 7 DHCP client communicates with a Microsoft Windows DHCP Server through a Microsoft relay agent.

When this issue occurs, an event that resembles the following is logged in the System event log:
An event that resembles the following is logged in the System log:
An event that resembles the following is logged in the Microsoft-Windows-DHCP-Client Applications and Services Operational log:


As the Windows 7 client starts, it sends a DHCP-REQUEST or DHCP-DISCOVER packet together with a Broadcast Flag of 0. Then, the DHCP server responds with a Unicast DHCP-ACK or DHCP-OFFER packet. This response is dropped by the boot-time firewall policy.

After the time-out period of three to five seconds, the DHCP client retries and obtains an IPv4 address. This occurs because the computer has completely started, and Windows Firewall has taken over the filtering from the boot-time policy. Windows Firewall enables the DHCP Unicast response. In the meantime, the Netlogon service starts and records an event ID 5719 because the service cannot locate the domain.


Hotfix information

A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing the problem described in this article. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.

If the hotfix is available for download, there is a "Hotfix download available" section at the top of this Knowledge Base article. If this section does not appear, contact Microsoft Customer Service and Support to obtain the hotfix.

Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft website: Note The "Hotfix download available" form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.


To apply this hotfix, you must be running one of the following operating systems:
  • Windows 7
  • Windows 7 Service Pack 1 (SP1)
  • Windows Server 2008 R2
  • Windows Server 2008 R2 Service Pack 1 (SP1)
For more information about how to obtain a Windows 7 or Windows Server 2008 R2 service pack, click the following article number to view the article in the Microsoft Knowledge Base:

976932 Information about Service Pack 1 for Windows 7 and for Windows Server 2008 R2

Registry information

To use the hotfix in this package, you do not have to make any changes to the registry.

Restart requirement

You must restart the computer after you apply this hotfix.

Hotfix replacement information

This hotfix does not replace a previously released hotfix.


To work around this issue, configure the DHCP Client on Windows 7 to request Broadcast responses from non-Microsoft DHCP Servers or Relay Agents. This is a two-part solution to this issue.

In Part 1, you must make a registry change that forces the DHCP Client in Windows 7 to always set the broadcast flag in DHCP DISCOVER messages. The change is based on the network adapter type that is inside the computer.

In Part 2, you must delete the registry entries that currently exist for the broadcast flag for each adapter. This applies the new instance of the network adapters that are installed in the client. After you restart the client at the end of Part 2, Windows then uses the global setting that you created in Part 1 to re-create the needed registry entries according to the interface. If a restart of Windows is not possible, please refer to the Note at the end of Part 2 for a method that creates the correct registry entries for each interface without restarting the computer.

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
322756 How to back up and restore the registry in Windows

Part 1: Create a global registry entry that is based on the network adapter type

Follow these steps, and then exit Registry Editor:
  1. Click Start, click Run, type regedit, and then click OK.
  2. Locate and then click the following subkey in the registry:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325 -11CE-BFC1-08002BE10318}
    Note Under this subkey, there is a sequence of subkeys. For example, you see "0000, 0001."
  3. Select the subkey that matches the network adapter that is being used by the computer.

    Note To determine the network adapter, match the "Driver Desc" entry to the name of the physical network adapter that is installed.
  4. If this entry is present, note the type that is listed for the MediaType and PhysicalMediumType registry entries. This represents the kind of network interface (Ethernet, for example). However, you may instead see the registry entries *MediaType and *PhysicalMediumType, and each entry has a value of 0. If this is the case, you must be familiar with the kind of network adapter that is installed in the computer to create the correct registry entries in the following steps.
  5. Locate and then click the following subkey in the registry:
  6. On the Edit menu, point to New, and then click Key.
  7. Type DhcpGlobalForceBroadcastFlag for the subkey's name.
  8. On the Edit menu, point to New, and then click Key.
  9. Type MediaType, and then press Enter.

    The placeholder MediaType corresponds to the entry for the MediaType registry entry that you found in step 4.
  10. On the Edit menu, point to New, and then click DWORD Value.
  11. Type PhysicalMediumType, and then press Enter.

    The placeholder PhysicalMediumType corresponds to the entry for the PhysicalMediumType registry entry that you found in step 4.
  12. On the Edit menu, click Modify.
  13. Type 1, and then click OK.
Example: For an Ethernet adapter, the following registry subkey would have the following values:
Registry entry and value: DWORD = 1
PhysicalMediumType can have the following values:
  • 0 (Unspecified), value 0 or 1
  • 9 (Wireless), value 0 or 1
  • 14 (Ethernet), value 0 or 1
For more information and detailed values for MediaType and PhysicalMediumType, see the corresponding tables in the following Microsoft Developer Network article:Note If you are performing a fresh image deployment of Windows 7 computers, you can directly add the global flag in the VIM image. This global flag will take effect when the interfaces are initialized on deployment.

Part 2: Delete the existing keys for broadcast flag according to the network interface

  1. Click Start, click Run, type regedit, and then click OK.
  2. Locate the following registry subkey:
    Note The placeholder <GUID> represents the GUID for the appropriate network interface.
  3. Delete the following registry entry:
  4. Restart the computer.
  5. After the computer starts, you see that the client has successfully received an IP address through DHCP.
If you examine the registry subkey that you located in step 2, you find that the registry value DHCPConnForceBroadcastFlag is restored, and it has the value 1.

Note Restarting the computer is the recommended method. If you do not want to restart the computer, first stop and then disable the DHCP Client service. Then, delete the interface-specific subkey because the DHCP Client service backs up the registry when the service is stopped and started. However, the DHCP Client service does not back up the registry when the service stops during shutdown.

Wireless Adapters

Windows 7 maintains a cache of settings for every unique wireless network that Windows 7 connects to. This information is stored in a subkey that represents each wireless service set identifier (SSID) under the specific wireless adapter interface GUID. Together with other information about the wireless network, Windows 7 also maintains a specific value for DHCPConnForceBroadcastFlag. Therefore, for a wireless adapter, other than deleting the interface-specific registry entry, you must also visit every unique wireless network cache and delete the entry for DHCPConnForceBroadcastFlag. The location is stored in the following registry subkey:
After you delete the DHCPConnForceBroadcastFlag entry, it is re-created based on the value of the global flag.

Note The placeholder <wirelessSSID> is the hexadecimal string that represents a wireless network.


Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

More Information

This issue does not occur on Windows Vista. By default, Windows Vista sets the DHCP broadcast flag to 1. However, because of some issues that were reported with that behavior, the Windows 7 behavior was changed. For more information about this behavior in Windows Vista, click the following article numbers to view the articles in the Microsoft Knowledge Base:
928233 Windows Vista cannot obtain an IP address from certain routers or from certain non-Microsoft DHCP servers

933340 You cannot use a remote access server to apply DHCP options to a Windows Vista-based computer

Windows 7 also has DhcpConnEnableBcastFlagToggle set to 1. Therefore, if the client cannot obtain an IP address after four attempts, the DHCP client toggles the DHCP broadcast flag and tries to obtain the IP address. The DHCP client also remembers the flag that was last used to obtain the IPv4 address.

For more information about software update terminology, click the following article number to view the article in the Microsoft Knowledge Base:

824684 Description of the standard terminology that is used to describe Microsoft software updates