DHCP server authorisation failure Windows Server 2008

Question

Hi
Our network: Windows 2008 standard server (domain controller holding all FSMO roles, DHCP, DNS), Windows 2003 standard server (DNS, WINS), domain functional level = 2003. Windows storage server 2008 (file server), Windows server 2012 (WSUS, Remote access).
One site, one 192.168.0.xxx subnet. Mixture of XP and Win 7 clients and one Vista client. None of the servers are multi-homed.
The DHCP server is configured with a scope that assigns addresses between 100 and 200. All the clients (35 of them) have reserved addresses. The 2012 server grabs a block of ten or so addresses for VPN connections. DHCP server also specifies DNS server, router,
time server, domain name, WINS server, NetBIOS over TCP/IP, and WINS node type. Address duration is 6 days.
Clients' DHCP settings are configured as normal, except that APIPA address assignment has been customised so they get an address 192.168.0.2xx and the DNS server is the gateway not the domain controller.
Last week, everything was fine.
Monday morning and all the Windows 7 clients are unable to browse the network. I checked and saw that each W7 client had the APIPA address assigned. The XP machines were fine.
The DHCP management console snap-in showed the IPV4 node with a red symbol. I restarted the DC but it did not help. The DHCP custom event log under Server Roles has no events at all. In the past there have been startup events present.
When I started the DHCP snap-in it said that the server was not authorised. Selecting the server then clicking the action menu shows an unauthorise option.
The system log has event 1059 logged:
Log Name:      System
Source:        Microsoft-Windows-DHCP-Server
Date:          16/12/2013 08:31:02
Event ID:      1059
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      Phobos.htlincs.local
Description:
The DHCP service failed to see a directory server for authorization.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-DHCP-Server" Guid="{6D64F02C-A125-4DAC-9A01-F0555B41CA84}" EventSourceName="DhcpServer" />
    <EventID Qualifiers="0">1059</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2013-12-16T08:31:02.000Z" />
    <EventRecordID>823779</EventRecordID>
    <Correlation />
    <Execution ProcessID="0" ThreadID="0" />
    <Channel>System</Channel>
    <Computer>Phobos.htlincs.local</Computer>
    <Security />
  </System>
  <EventData>
    <Data>
    </Data>
    <Data>htlincs.local</Data>
    <Data>0x    203a</Data>
    <Binary>3A200000</Binary>
  </EventData>
</Event>
This was followed by event 1044: The DHCP/BINL service on the local machine, belonging to the Windows Administrative domain htlincs.local, has determined that it is authorized to start. It is servicing clients now.
Then event 1059 (above) was repeated.
After 12 minutes event 1044 was repeated, but no other DHCP events have been logged since that time.
I assigned static IP addresses to the clients and they are now able to browse the network
There was just one system change made to the domain controller that hosts DHCP and that was the installation of Netwrix File Server Change Reporter. The installation required a new GPO being created and configured as shown on pp 16/17 of this guide http://www.netwrix.com/download/documents/NetWrix_File_Server_Change_Reporter_Administrator_Guide.pdf.
I uninstalled this program and removed the GPO this morning.
I checked the DHCP server about 3 hours later and the IPV4 node was green. Also, when the snap-in loaded it did not display a message saying that the server needs to be authorised.
Anyone have any idea what may have caused the DHCP server to behave this way? It seems to be OK now (Win 7 clients with DHCP address assignment enabled are OK when restarted), and I wouldn't expect the Netwrix application to have this adverse effect on it.
Also, I don't understand why the Win 7 clients could not simply retain their existing address. Why were the alternate configuration addresses used? I doubt very much that all those machines' address leases had expired by this morning (though, of course, it
is remotely possible).
Thanks!

Answer 1

Hi,
Firstly, thanks for sharing your experience with us and it would be greatly helpful to others who has similar issue.
Based on my knowledge, for a DHCP client it will ask the DHCP server to obtain an IP address firstly. If the DHCP server is not available,
it will be assigned an IP from 169.254.0.0/16 by APIPA. If APIPA is disabled, it will check the alternate configuration to get an IP address. Otherwise, no IP address will be assigned to the client.
Besides, event 1044 is a normal condition
and no further action is required for it. However, the event 1059 is usually due to the connectivity issue between the DC and DHCP server. In addition, it is not recommended to install the DHCP server on a DC.
More information:
Event ID 1044 — DHCP Authorization and Conflicts
http://technet.microsoft.com/en-us/library/cc726927(v=ws.10).aspx
Event ID 1059 — DHCP Server Active Directory Availability
http://technet.microsoft.com/en-us/library/cc774849(v=ws.10).aspx
Best regards,
Susie
Hi, Susie
Thanks a lot for responding.
I had used the links you provided when I was trying to figure out what had happened. Using ping to test the connectivity from/to the DC worked fine, the XP clients were able to browse the network and connect to the Internet without issue.
My question is why the Windows 7 clients suddenly began using the alternate addresses. I think it too much of a coincidence for their leases to have expired at the same time and for it to not have affected the XP clients.
My point is that DHCP leases addresses for a set period - in our case, 6 days. The clients should contact the DHCP server when 3 days have elapsed and then at regular intervals thereafter. They should not use the alternate configuration address or the APIPA
address unless the lease has expired and they are unable to contact a DHCP server or a DHCP server refuses the request.
In this case they were unable to contact the DHCP server. Connectivity was not an issue while this occurred for the remainder of the clients. As I said, DNS is hosted on the DC that also hosts DHCP. I forgot to mention that the same DC also hosts the DFS
root. It was only the DHCP server that had the issue contacting the DC. DNS was working fine, DFS was working fine. If the DC that hosts these services has any sort of connectivity issues it affects everyone.
I was hoping that someone might be able to help explain why the Win 7 clients behaved as they did so that I could take steps to prevent/minimise this happening in the future.
Regarding the issue of hosting DHCP on a DC, does anyone know if there would be any problems hosting DHCP on a member server that also hosted WSUS and Routing and Remote Access? I have never seen anything that states there might be issues regarding this
but it's best to ask :)
Thanks again.