HungerMountain
asked on
KB2923392 update BREAKS Gateway function on domain controller
Hello,
We have three domain controllers that each can serve as a Gateway and DNS server to our client computers. We configure the workstations to list all three domain controllers under both DNS and Gateway settings, so if one goes down, the others are available.
I installed updates on two of the three domain controllers yesterday and some but not all client computers began having serious issues browsing the Internet. Some computers were unaffected, some could not browse out all; others could load pages but not all components on the page.
By reconfiguring TCP/IP on workstations to point to only one of the domain controllers we determined that one of them (which got updates) was no longer functional as a Gateway. The other domain controller that got updates continues to function. (The third was not updated.) We began removing updates, first KB2930275, which did not have any affect after the reboot. Then we removed KB2923392. After the reboot, the domain controller was again functional as a Gateway. BAD BAD BAD UPDATE!
1. We don't at all understand why the update did not affect the Gateway functionality of one domain controller but completely broke the Gateway function on the other domain controller. Both were completely up-to-date with updates.
2. We know the command "echo %logonserver%" to determine which domain controller was used to authenticate, but this does not seem to have any bearing on which domain controller is currently used as the Gateway and which the DNS server. We also don't know if a workstation picks a gateway and sticks with it or uses multiple gateways in a round robin manner, which might explain why some components of a web page displayed and others did not; and why some computers seemed unaffected. How does it work?
3. Assuming a workstation picks a Gateway and DNS server from its configured static list, and sticks with it, is there an equivalent command to determine which server is its current Gateway and which server is its current DNS server?
Thanks,
Ravi
We have three domain controllers that each can serve as a Gateway and DNS server to our client computers. We configure the workstations to list all three domain controllers under both DNS and Gateway settings, so if one goes down, the others are available.
I installed updates on two of the three domain controllers yesterday and some but not all client computers began having serious issues browsing the Internet. Some computers were unaffected, some could not browse out all; others could load pages but not all components on the page.
By reconfiguring TCP/IP on workstations to point to only one of the domain controllers we determined that one of them (which got updates) was no longer functional as a Gateway. The other domain controller that got updates continues to function. (The third was not updated.) We began removing updates, first KB2930275, which did not have any affect after the reboot. Then we removed KB2923392. After the reboot, the domain controller was again functional as a Gateway. BAD BAD BAD UPDATE!
1. We don't at all understand why the update did not affect the Gateway functionality of one domain controller but completely broke the Gateway function on the other domain controller. Both were completely up-to-date with updates.
2. We know the command "echo %logonserver%" to determine which domain controller was used to authenticate, but this does not seem to have any bearing on which domain controller is currently used as the Gateway and which the DNS server. We also don't know if a workstation picks a gateway and sticks with it or uses multiple gateways in a round robin manner, which might explain why some components of a web page displayed and others did not; and why some computers seemed unaffected. How does it work?
3. Assuming a workstation picks a Gateway and DNS server from its configured static list, and sticks with it, is there an equivalent command to determine which server is its current Gateway and which server is its current DNS server?
Thanks,
Ravi
Mahesh
What do you mean by gateway, its confusing term in case of domain controllers
ASKER
By "Gateway" I mean that in TCP/IP settings on the workstations, for "Default Gateways" we list the IP addresses of our three domain controllers instead of the router (192.168.1.1). The "gateway" address is used by workstations to reach the Internet. The Domain Controllers themselves list the router as their Gateway, so workstation traffic to the Internet passes through the domain controllers, and packets are then forwarded to the router. We think that if we list the router as the gateway for workstations, they don't get the default domain security policy.
-r
-r
Ok
According to me you should not put DC ip as gateway
What I understood from your explanation, your DC I think are directly going to internet for internet
The best practice is to set default DNS forwarder on domain controllers and not to set DC ip on client machines as gateway
OR
you could place some kind of Proxy server \ firewall and add it as web proxy on workstations
All you need to do is just put up domain controller IP as Preferred and secondary IP on client machines and change default gateway to some router \ switch IP which enables their connectivity between subnets through internal routing
Internet and name resolution needs to be handled by either Domain controllers through ISP forwarders or through web proxy solution
Mahesh
According to me you should not put DC ip as gateway
What I understood from your explanation, your DC I think are directly going to internet for internet
The best practice is to set default DNS forwarder on domain controllers and not to set DC ip on client machines as gateway
OR
you could place some kind of Proxy server \ firewall and add it as web proxy on workstations
All you need to do is just put up domain controller IP as Preferred and secondary IP on client machines and change default gateway to some router \ switch IP which enables their connectivity between subnets through internal routing
Internet and name resolution needs to be handled by either Domain controllers through ISP forwarders or through web proxy solution
Mahesh
ASKER
Hi Mahesh,
Thanks for your comments. I believe I agree with your advice regarding DNS. We have forwarders to an external DNS server set up on each of our three domain controllers that also serve as DNS servers. We list all three for our workstations, which allows the workstations to resolve internal LAN computer names and domain names (our internal SharePoint site) as well as external domains. However you did not address my question as to how to determine WHICH of our domain controllers has been selected by the workstation as its DNS server at any given time.
Regarding the Internet Gateway, we will have to do some more testing regarding the impact of a workstation receiving the computer domain policy when it starts up if the gateway is not set to a domain controller. It is certainly possible that I am wrong to think that is necessary. But we have set our workstations to use a domain controller as the gateway for the last ten years. I'm not inclined to change that without more investigation. It occurs to me that when I came here 10 years ago, we had a Small Business Server as the domain controller, which might have been the compelling reason why workstations used that server as the gateway. That server may have had the role of proxy server/firewall. Regardless of best practices it certainly DOES work to use a domain controller as a gateway (current issue with the Microsoft update notwithstanding). And it certainly is supported to use multiple gateways for redundancy. So my second question also remains: how do we determine WHICH IP of the listed Gateways is being used by a workstation at any point in time.
Your advice to change our network configuration to point workstations to the router for the gateway may indeed be best practice, but in our current configuration it would be very handy to know which domain controller is serving up the gateway and DNS for our workstations that list three possibilities.
You also did not address the issue of why the update broke the gateway function. I'm surprised we haven't seen other postings about the issue. Perhaps most people do NOT use a domain controller as a Gateway so it isn't a common problem.
Regards,
Ravi
Thanks for your comments. I believe I agree with your advice regarding DNS. We have forwarders to an external DNS server set up on each of our three domain controllers that also serve as DNS servers. We list all three for our workstations, which allows the workstations to resolve internal LAN computer names and domain names (our internal SharePoint site) as well as external domains. However you did not address my question as to how to determine WHICH of our domain controllers has been selected by the workstation as its DNS server at any given time.
Regarding the Internet Gateway, we will have to do some more testing regarding the impact of a workstation receiving the computer domain policy when it starts up if the gateway is not set to a domain controller. It is certainly possible that I am wrong to think that is necessary. But we have set our workstations to use a domain controller as the gateway for the last ten years. I'm not inclined to change that without more investigation. It occurs to me that when I came here 10 years ago, we had a Small Business Server as the domain controller, which might have been the compelling reason why workstations used that server as the gateway. That server may have had the role of proxy server/firewall. Regardless of best practices it certainly DOES work to use a domain controller as a gateway (current issue with the Microsoft update notwithstanding). And it certainly is supported to use multiple gateways for redundancy. So my second question also remains: how do we determine WHICH IP of the listed Gateways is being used by a workstation at any point in time.
Your advice to change our network configuration to point workstations to the router for the gateway may indeed be best practice, but in our current configuration it would be very handy to know which domain controller is serving up the gateway and DNS for our workstations that list three possibilities.
You also did not address the issue of why the update broke the gateway function. I'm surprised we haven't seen other postings about the issue. Perhaps most people do NOT use a domain controller as a Gateway so it isn't a common problem.
Regards,
Ravi
Yes, Ravi, you are right
Most of the organizations (Even smallest one) will have network router \ windows standalone server acting as router with RRAS role installed (LAN Routing enabled), but directly domain controller is setup as gateway \ router is the 1st time I heard \ see in your case.
Now to answer your question:
how to determine WHICH of our domain controllers has been selected by the workstation as its DNS server at any given time
Since you have DNS forwarders on all 3 servers, its really difficult to understand which DNS server will be used by client at a time since DNS behavior is dynamic and it will try to load balance the queries with round robin
What it means, queries can be routed to any DNS server for internet
The best way to tackle this situation, set dns forwarders (ISP DNS) to any one server and add that server as forwarder on other two servers
Now queries must need to be routed through single server
I really need more explanation on above question as I don't think I understood it correctly
Are you using all 3 gateways on workstations ?
Also what do you mean by installing update broke gateway functionality ?
May be DNS service got unresponsive post update installation and it might be \ can be solved after restarting DNS service on server
I never heard that due to update installation, internet has stopped working
Mahesh
Most of the organizations (Even smallest one) will have network router \ windows standalone server acting as router with RRAS role installed (LAN Routing enabled), but directly domain controller is setup as gateway \ router is the 1st time I heard \ see in your case.
Now to answer your question:
how to determine WHICH of our domain controllers has been selected by the workstation as its DNS server at any given time
Since you have DNS forwarders on all 3 servers, its really difficult to understand which DNS server will be used by client at a time since DNS behavior is dynamic and it will try to load balance the queries with round robin
What it means, queries can be routed to any DNS server for internet
The best way to tackle this situation, set dns forwarders (ISP DNS) to any one server and add that server as forwarder on other two servers
Now queries must need to be routed through single server
So my second question also remains: how do we determine WHICH IP of the listed Gateways is being used by a workstation at any point in time.
I really need more explanation on above question as I don't think I understood it correctly
Are you using all 3 gateways on workstations ?
Also what do you mean by installing update broke gateway functionality ?
May be DNS service got unresponsive post update installation and it might be \ can be solved after restarting DNS service on server
I never heard that due to update installation, internet has stopped working
Mahesh
ASKER
RE DNS: OK, if a workstation has three DNS servers listed and will alternate among them, I can see why there would not be an equivalent command like echo %logonserver% to determine the DNS server in use.
Yes, we list all three domain controllers as gateways in our workstation tcp/ip config.
We don't think the gateway problem was a DNS issue because we pointed the workstation to an external DNS server while testing our domain controllers as gateways.
We found the source of our problem by listing on a workstation only one domain controller as the gateway at a time for testing and found that two of our domain controllers were functional as a gateway (i.e., allowed the workstation to browse the internet), but the third domain controller which had the update installed did NOT function at all anymore (workstation could not browse the internet). Hence those workstations that were using that domain controller as a gateway were not able to browse, while other workstations that had selected one of the other two domain controllers as their gateway were fully functional. We then uninstalled two updates on the problematic domain controller. After uninstalling the second one and rebooting the domain controller, it again functioned as a gateway for the workstation that only listed it as the gateway. From this we conclude that the update "broke" the gateway functionality of the domain controller. It would appear that workstations do NOT use the multiple gateways in a round robin fashion, once they have selected one. They don't seem to always use the first one listed. We don't think this was a DNS issue because we pointed the workstation to an external DNS server for testing.
-r
Yes, we list all three domain controllers as gateways in our workstation tcp/ip config.
We don't think the gateway problem was a DNS issue because we pointed the workstation to an external DNS server while testing our domain controllers as gateways.
We found the source of our problem by listing on a workstation only one domain controller as the gateway at a time for testing and found that two of our domain controllers were functional as a gateway (i.e., allowed the workstation to browse the internet), but the third domain controller which had the update installed did NOT function at all anymore (workstation could not browse the internet). Hence those workstations that were using that domain controller as a gateway were not able to browse, while other workstations that had selected one of the other two domain controllers as their gateway were fully functional. We then uninstalled two updates on the problematic domain controller. After uninstalling the second one and rebooting the domain controller, it again functioned as a gateway for the workstation that only listed it as the gateway. From this we conclude that the update "broke" the gateway functionality of the domain controller. It would appear that workstations do NOT use the multiple gateways in a round robin fashion, once they have selected one. They don't seem to always use the first one listed. We don't think this was a DNS issue because we pointed the workstation to an external DNS server for testing.
-r
I am really surprised that you are having 3 default gateways defined on workstations, initially i am just thought that but now it is confirmed
Every route for every default gateway must be having some metric defined
Out of 3 gateways, the route which has minimum metric value will be used by machine
I bet this is not a good practise really and best you can do is to get simple router and define its IP as single gateway on client computers
To do what you are trying to achieve, alternate DNS server is sufficient and no need to place multiple gateways on clients
if your primary server fails your alternate server can provide AD authentication and also you can add ISP DNS forwarders on secondary dns server in that case.
Please check below thread regarding multiple gateway
http://social.technet.microsoft.com/Forums/en-US/75a28ee4-9b67-49db-8f9e-4a226a8fe644/server-2008-r2-multiple-default-gateways-manually-set-metrics?forum=winserverNIS
Mahesh
Every route for every default gateway must be having some metric defined
Out of 3 gateways, the route which has minimum metric value will be used by machine
I bet this is not a good practise really and best you can do is to get simple router and define its IP as single gateway on client computers
To do what you are trying to achieve, alternate DNS server is sufficient and no need to place multiple gateways on clients
if your primary server fails your alternate server can provide AD authentication and also you can add ISP DNS forwarders on secondary dns server in that case.
Please check below thread regarding multiple gateway
http://social.technet.microsoft.com/Forums/en-US/75a28ee4-9b67-49db-8f9e-4a226a8fe644/server-2008-r2-multiple-default-gateways-manually-set-metrics?forum=winserverNIS
Mahesh
ASKER
We use "automatic" metric for the multiple gateways. Since all the domain controllers are on the same switch it is not clear which one might be used by a workstation. Perhaps using automatic metric is just one more bad practice....
I'm still investigating whether there is any impact on the security policy being applied to a computer that doesn't use a domain controller as a gateway. So far, we have not yet proven that it is necessary to set the gateway to a domain controller. We DO use the router as the gateway on machines like the POS registers that are not a member of the domain. We also installed a new SonicWALL router including a "high availability" unit; if the master router goes down, the HA backup takes over using the same 192.168.1.1 IP address. And if the router, or its backup, isn't working, no one is going to make it to the Internet anyway. So in that regard, having multiple domain controllers as the gateway would not be needed anyway.
If there is no adverse affect on the application of the domain security policy it would simplify our configuration, and we would never have had the issue with the Microsoft update impacting the domain controller functioning as a gateway in the first place.
I'm just having a hard time accepting that we have been unnecessarily using the domain controllers as gateways for the 10 years I have worked here and before. LOL
-ravi
I'm still investigating whether there is any impact on the security policy being applied to a computer that doesn't use a domain controller as a gateway. So far, we have not yet proven that it is necessary to set the gateway to a domain controller. We DO use the router as the gateway on machines like the POS registers that are not a member of the domain. We also installed a new SonicWALL router including a "high availability" unit; if the master router goes down, the HA backup takes over using the same 192.168.1.1 IP address. And if the router, or its backup, isn't working, no one is going to make it to the Internet anyway. So in that regard, having multiple domain controllers as the gateway would not be needed anyway.
If there is no adverse affect on the application of the domain security policy it would simplify our configuration, and we would never have had the issue with the Microsoft update impacting the domain controller functioning as a gateway in the first place.
I'm just having a hard time accepting that we have been unnecessarily using the domain controllers as gateways for the 10 years I have worked here and before. LOL
-ravi
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks Mahesh.
My former colleague agrees with you and thinks that our habit of using domain controllers as the gateway does date back about 9 years to when our domain controller was a Small Business Server functioning as the firewall.
We plan to point all the workstations at the router for the gateway, which removes the need to determine which of the domain controllers is the active gateway, because it will always be the router.
Regards,
Ravi
My former colleague agrees with you and thinks that our habit of using domain controllers as the gateway does date back about 9 years to when our domain controller was a Small Business Server functioning as the firewall.
We plan to point all the workstations at the router for the gateway, which removes the need to determine which of the domain controllers is the active gateway, because it will always be the router.
Regards,
Ravi