none
How does DNS work inside 2016 essentials? RRS feed

  • Question

  • Hello,
    I use Windows Server 2016 Essentials with DNS. The server was set up on a DHCP IP he receives from my router
    (FritzBox 7490, always the same IP). My clients are set up with the Client Connector, the IP we assigned by
    my router and they have as DNS entry my server or my Fritzbox (depending on whether the server is on or off).
    The switching works automatically. Unfortunately, I do not know how it works at 2016.
    I found an explanation how it works in "Windows Server 2012 R2 Essentials" (separate Service).

    For new clients (checked for w10 1809 during a test update), the installation of the Client Connector does
    not work. At the end, the server will not say The computer can not connect to the network. The server is not
    available ...

    I realize that normally a DNS server runs 24 hours (has to run). But this is where the essentials are the
    solution. Therefore, I am interested in the technical details Microsoft has installed here.

    greetings
    Mammut62
    • Edited by mammut62 Thursday, March 28, 2019 11:28 PM
    Thursday, March 28, 2019 11:27 PM

All replies

  • Hi,
     
    If you mean "DNS auto-detect and configure" feature of WSE, it tries to find the server that is running Windows Server Essentials, and then it uses the server’s address as the client's DNS address after Connector is installed on clients.

    There are relate registry entities that we can configure/change such feature. Reference “Update Rollup 3 for Windows Server 2012 Essentials” for detail information, and it is also applied to later WSE OS version:
    https://support.microsoft.com/en-my/help/2862551/update-rollup-3-for-windows-server-2012-essentials

    >For new clients (checked for w10 1809 during a test update), the installation of the Client Connector does 
    not work.
    In order to have further identification about such problem, we can check log files - ClientDeploy.log and ComputerConnector.log under %programdata%\Microsoft\Windows Server\Logs on client system.

    Best Regards,
    Eve Wang

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

    Friday, March 29, 2019 6:54 AM
    Moderator
  • Hi, Eve
    thanks for your answer.

    I have no idea how that "DNS auto-detect and configure" is working. On that page is explained how I can skip domain join. But I would like to join to domain. Do you have a discription how that works?

    Regarding logs:
    I have a vm testsystem w10x64 ent 1803. I used in 2017 / 2018 and I found data from that time where domain join was ok (File ClientDeploy.log: [3992] 170727.150231.3216: ClientSetup: End of ClientDeploy: ErrorCode=0). Now I found data from this week where it failed ([2512] 190327.235904.5515: ClientSetup: End of ClientDeploy: ErrorCode=1603). I found also inside system event log exactly 40 lines with that particular error (Fehler beim Beitritt des Computers "pc1" zur Domäne "MYDOM.local". Fehlercode: "1355".). Its a german system and I found 40 lines for every retry to install connector.

    I tried to remove that system from my server console, but it still fails to join to domain.

    greetings
    mammut62

    Friday, March 29, 2019 2:07 PM
  • Hi, Eve
    thanks for your answer.

    I have no idea how that "DNS auto-detect and configure" is working. On that page is explained how I can skip domain join. But I would like to join to domain. Do you have a discription how that works?

    Regarding logs:
    I have a vm testsystem w10x64 ent 1803. I used in 2017 / 2018 and I found data from that time where domain join was ok (File ClientDeploy.log: [3992] 170727.150231.3216: ClientSetup: End of ClientDeploy: ErrorCode=0). Now I found data from this week where it failed ([2512] 190327.235904.5515: ClientSetup: End of ClientDeploy: ErrorCode=1603). I found also inside system event log exactly 40 lines with that particular error (Fehler beim Beitritt des Computers "pc1" zur Domäne "MYDOM.local". Fehlercode: "1355".). Its a german system and I found 40 lines for every retry to install connector.

    I tried to remove that system from my server console, but it still fails to join to domain.

    greetings
    mammut62

    Hi mammut62,

    I think you have some pretty fundamental issues with your install of Windows Server and in it's current config, it is doubtful you will be able to get any machine to join Your Domain.

    Basically (the way I've always done it is) I run AD, DNS and DHCP on the same server (either  VM or on Bare metal doesn't matter). The AD/DNS Server is ALWAYS on a static IP (never assigned via a router's DHCP! Router's DHCP is usually disabled). The AD server ALWAYS points to itself for DNS. You configure forwarders so client machines can access the internet - Local queries for internal machines go to your DNS server and internet request resolve via the forwarders. 

    I always use the DHCP server on the AD server because it updates the DNS servers record for internal hosts without muss or fuss. Theoretically you can use your router's (or Firewall) DCHP server, but it has to pass the correct info to the AD DNS server and not all will do that. I've never configured a router to do that, as most of the ones I work with simply cannot do it. Most of the businesses I work with are Small businesses and generally don't want to invest in an expensive router/firewall/gateway device (read: most of them are incredibly cheap LOL!). I've thought of trying to configure PFSense to do so, as a way of expanding my ability in this area, but have never done it. To me it is just a lot easier to let the Window Server's DHCP do the work. eventually I probably will tackle it though...

    If you want to have a DOMAIN, you pretty much should leave the Server always on so that it is always serving out IP's Via it's DHCP server and always updates your DNS, which is critical to the Domain/Domain functions. Don't use DHCP on your router. Use the Server's DHCP server. Also if you are using your router to hand out DHCP/DNS server info when you have you DC "down", then your clients will probably never get the correct DNS server address if you have the ISP DNS servers listed... they more than likely will get your ISP DNS which will totally wreck your AD  as the clients will never be able to resolve your DC in that case.

    Bottom line: AD DNS has to be properly configured for the Domain to work. At the very least you need to configure the server with a static IP (EDIT: or a reserved IP which the server will always get), and insure it is pointing to itself for DNS. And if you insist on your router handing out DNS info via it's DHCP, make sure it NEVR hands out the ISP DNS servers - Only that of your DNS server. There is really no way to "split the diference" and have the router hand out DNS part of the time when you have the server "down". The server ALWAYS needs to be on basically, or at least when your clients need to access the Network and the internet.



    • Edited by Aaronbav Monday, April 1, 2019 4:08 PM
    Sunday, March 31, 2019 3:30 AM
  • Hi,

    Domain join process of WSE client is same as manually domain join. Client system search DC relate DNS RRs from specific DNS server, then, client contact the DC for authentication, if it passed, client exchange message with DC and complete the domain join process.

    I have not found relate official document which describe the details of domain join. 

    About the failure, we can check ClientDeploy.log and ComputerConnector.log for more information, or, if you only want to troubleshooting domain join relate problem, you may try to manually join client to domain and check the result.

    How to troubleshoot errors that occur when you join Windows-based computers to a domain:
    https://support.microsoft.com/en-us/help/4341920/troubleshoot-errors-that-occur-when-you-join-windows-based-computers-t

    Best Regards,
    Eve Wang

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

    Monday, April 1, 2019 1:45 AM
    Moderator
  • Bottom line: AD DNS has to be properly configured for the Domain to work. At the very least you need to configure the server with a static IP (EDIT: or a reserved IP which the server will always get), and insure it is pointing to itself for DNS. And if you insist on your router handing out DNS info via it's DHCP, make sure it NEVR hands out the ISP DNS servers - Only that of your DNS server. There is really no way to "split the diference" and have the router hand out DNS part of the time when you have the server "down". The server ALWAYS needs to be on basically, or at least when your clients need to access the Network and the internet.

    Hi Aaronbav,

    thanks for your detailed answer. I can imagine that this is not the normal configuration. I was in doubt that WSE is somehow special and this will work. I found it here https://windowsserveressentials.com/2013/06/17/unravelling-the-mystery-of-client-dns-with-essentials-family-servers/

    I suppose that I have to reinstall all again if I want to use AD.

    Monday, April 1, 2019 8:02 PM
  • Hi Eve,

    I tried to manually join client to domain and it failed. In that case I set two dns server ip manually (ipv4 nic setting, first: 192.168.123.100 (mydom), second: 192.168.123.1 (my router). I have no idea why it failed...


    I can't addd my "ClientDeploy.log" because limit of 60000 chars:
    • Edited by mammut62 Monday, April 1, 2019 9:02 PM
    Monday, April 1, 2019 8:10 PM
  • I tried to manually join client to domain and it failed. In that case I set two dns server ip manually (ipv4 nic setting, first: 192.168.123.100 (mydom), second: 192.168.123.1 (my router). I have no idea why it failed...

    Hi mammut62,

    Windows Server Essentials primary recommendation is that for 25users/50 Devices you do not need addtional CAL's, so for the  cost constrained it is a good deal, but does have limitations over Server Standard. It also has additional "features" to help setting up and administering, but in terms of Active Directory, DNS is CRITiCAL and works just like any other Windows Server version. If it is broken (i.e. if you have a router supplying any other DNS server info such as your ISP's), then domain functions will generally not work (such as joining the Domain, etc) if the client machine is handed your ISP's DNS vs. your Internal DNS. You can ONLY point to an AD DNS Server, whether you are using the built-in DHCP server or the DHCP in your router.  Because the server is acting as your DNS for both LAN and WAN, you can't really shut it down.

    At this point I'm not sure you need to re-install - what I would do first is, if you keep DHCP on your router for now, is remove any reference to your ISP's DNS from the Router config. It should only hand out your DNS server for DNS. Then in the forwarder's section of DNS manager on the Server, that is where you would put your ISP's DNS (or Googles 8.8.8.8  or  8.8.4.4, etc) to resolve internet addresses.

    If that doesn't work, I would DISABLE the DHCP server in the router and install DHCP on the AD Server (if it isn't, already which it probably isn't), set up A DHCP scope ( I would use a different IP range just do differenitate), then have clients pull new IP's from the Server - you will know if it picks up the new range vs. what the router was giving out. Also be sure to change the Server's IP (it would have to be Static, as the Router will not be handing out addresses, either reserved or otherwise). Before trying to join a client to the Domain, Just for "grins" I would reboot everything just so you are starting fresh - probably not necessary, but I would do it anyway... FWIW

    Monday, April 1, 2019 9:15 PM
  • Actually, I gave you some bad advice. Got to thinking about it  - don't change the IP address of the server - Just make sure it is set to static, with the same address as it has been getting from the router.  Will cause more trouble than it is worth to try and change the subnet (I've actually never done that before and there was something niggling in the back of my mind on doing that). Just disable DHCP on the router.

    If in the end you do end up doing a reinstall, then you could change the IP Address/subnet if you want...

    Monday, April 1, 2019 11:52 PM
  • Actually I was curious about what is involved in changing a Domain Controller's IP, so I googled for a "how-to"  and it doesn't appear to be quite as bad as I had thought. Here is a link if you decide to give it a go on yours:

    https://www.petri.com/change-ip-address-domain-controller

    Tuesday, April 2, 2019 12:01 AM
  • Hi,

    You may upload file to OneDrive (https://onedrive.live.com/) share it and provide me the access link. Please note that, log file may include private information, due to security consideration, you may choose to not share me the log files. And I will try to provide you other possible suggestion about the problem. 

    Best Regards,
    Eve Wang

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

    Tuesday, April 2, 2019 1:54 AM
    Moderator
  • Hi, Aaronbav,
    for the moment I'm not able to change dhcp server (router stlll in use, I have to find a free time window...). But I followed your link and started "dcdiag" test:
    Starting test: DFSREvent
             Für den Zeitraum der letzten 24 Stunden seit Freigabe des SYSVOL sind Warnungen oder Fehlerereignisse
             vorhanden. Fehler bei der SYSVOL-Replikation können Probleme mit der Gruppenrichtlinie zur Folge haben.
             ......................... Der Test DFSREvent für MYSERFER ist fehlgeschlagen.

    Wednesday, April 3, 2019 10:46 AM
  • Please note that, log file may include private information, due to security consideration, you may choose to not share me the log files. And I will try to provide you other possible suggestion about the problem.

    Hi Eve,
    I prefer a different solution to provide my ClientDeploy.log.

    At least I can provide a prepared version of my log to onedrive. It contains only last retry and some private informations are changed/removed (mac adresses, ipv6 adresses, servername, clientnames, usernames).

    Wednesday, April 3, 2019 11:02 AM
  • If you're running Windows Server 2016 Essentials (as opposed to regular Windows Server 2016 with the Essentials Experience role added), then that server MUST be set up as a domain controller and hold all FSMO roles.  It must also be the only Essentials box on the domain.  If you try to set it up as a member server in a domain or as a workgroup, it will start throwing errors that it is not being used in compliance with its licensing terms, and after a grace period (I think a few weeks or months), it will start shutting itself down I think every few days.

    Since the server must be a domain controller, it will need a static IP.  That's true even if that server isn't also hosting DNS, which isn't technically required on an AD domain controller, although those roles are practically always deployed together because running AD without an AD-integrated DNS environment can become a huge pain.  For one thing, the way clients discover domain controllers is by checking the SRV records for the supplied domain name in DNS, so if you're running some other solution for DNS and don't have a way to configure those records and other DNS records necessary for AD to function properly, you should expect things not to work properly.  And DNS servers are ALSO meant to be configured with a static IP, even when they're not hosting AD.

    So first, get yourself off of a DHCP IP for your Essentials box.  Then if you want redundant DNS in case your server goes down, configure your DHCP server to provide both your server's IP and your Fritzbox's IP as DNS servers.  The server's IP should always be primary because again, your Fritzbox won't have AD-related DNS records, so while having it as a secondary DNS server might be useful for maintaining Internet connectivity if your server is down, it's not a full substitute.  I use this strategy at a client running Essentials.

    • Edited by jphughan Wednesday, April 3, 2019 11:20 PM
    Wednesday, April 3, 2019 11:17 PM
  • Then if you want redundant DNS in case your server goes down, configure your DHCP server to provide both your server's IP and your Fritzbox's IP as DNS servers.  The server's IP should always be primary because again, your Fritzbox won't have AD-related DNS records, so while having it as a secondary DNS server might be useful for maintaining Internet connectivity if your server is down, it's not a full substitute.  I use this strategy at a client running Essentials.

    No. Strongly disagree with this UNLESS the "fritzbox" would be handing out ANOTHER AD integrated DNS server via it's DHCP - again IMHO the DHCP on the router should ALWAYS be disabled unless it is handing out AD DNS server Info. The reason for that is that the router is more that likely configured to hand out the ISP's (or other Public DNS servers) which, in the event that the AD DNS goes down or is briefly unavailable for a time, it is quite likely that a client(s) could get the Public DNS rather than the AD DNS, which will hose the Domain for that (those) clients. Better to deal with an immediate problem of the DNS being down/unavailable  for some reason, then possible problems later on when the clients have the wrong DNS and have issues because of it...

    • Edited by Aaronbav Thursday, April 4, 2019 1:01 AM clarification
    Thursday, April 4, 2019 1:00 AM
  • No. Strongly disagree with this UNLESS the "fritzbox" would be handing out ANOTHER AD integrated DNS server via it's DHCP - again IMHO the DHCP on the router should ALWAYS be disabled unless it is handing out AD DNS server Info. The reason for that is that the router is more that likely configured to hand out the ISP's (or other Public DNS servers) which, in the event that the AD DNS goes down or is briefly unavailable for a time, it is quite likely that a client(s) could get the Public DNS rather than the AD DNS, which will hose the Domain for that (those) clients. Better to deal with an immediate problem of the DNS being down/unavailable  for some reason, then possible problems later on when the clients have the wrong DNS and have issues because of it...

    As I explained above, the reason I suggested including the Fritzbox's IP as a secondary DNS server, behind the AD DNS server as primary, is purely to maintain Internet connectivity if the AD DNS server is down.  I realize that if the clients end up resolving against a public DNS server, it will hose domain connectivity -- but if the DC is down, then the domain is hosed anyway.  Having Internet connectivity during a server outage is better than having nothing, and when the primary DNS server comes back up, clients revert to it automatically.  Additionally, the OP already said that he doesn't even keep this Essentials server up all the time, which means that a) full-time domain functionality clearly isn't crucial to his environment, and b) his clients are going to need some other DNS server that's always available no matter what.  Many routers allow you to configure their DHCP options so that they hand out other IPs as DNS servers, including a different IP as the primary DNS server instead of their own IP.  I can do that with my consumer ASUS router at home.

    Having a second AD DNS server isn't a viable option with Essentials.  You can't have two Essentials servers in the same domain, so the second AD DNS server would have to be full Windows Server, which is expensive on its own and becomes even more expensive because its existence would then mean you'd need CALs for all of your client devices or users, and avoiding that is one of the main attractions of Essentials.  So having two AD DNS servers is not a likely path for any Essentials customer, especially one who doesn't even keep their Essentials server running full-time.

    • Edited by jphughan Thursday, April 4, 2019 9:20 PM
    Thursday, April 4, 2019 9:05 PM
  • No. Strongly disagree with this UNLESS the "fritzbox" would be handing out ANOTHER AD integrated DNS server via it's DHCP - again IMHO the DHCP on the router should ALWAYS be disabled unless it is handing out AD DNS server Info. The reason for that is that the router is more that likely configured to hand out the ISP's (or other Public DNS servers) which, in the event that the AD DNS goes down or is briefly unavailable for a time, it is quite likely that a client(s) could get the Public DNS rather than the AD DNS, which will hose the Domain for that (those) clients. Better to deal with an immediate problem of the DNS being down/unavailable  for some reason, then possible problems later on when the clients have the wrong DNS and have issues because of it...

    As I explained above, the reason I suggested including the Fritzbox's IP as a secondary DNS server, behind the AD DNS server as primary, is purely to maintain Internet connectivity if the AD DNS server is down.  I realize that if the clients end up resolving against a public DNS server, it will hose domain connectivity -- but if the DC is down, then the domain is hosed anyway.  And having Internet connectivity is better than nothing.  Additionally, the OP already said that he doesn't even keep this Essentials server up all the time, which means that a) full-time domain functionality clearly isn't crucial to his environment, and b) clients are going to need some other DNS server that's always available anyway.

    Having a second AD DNS server isn't really an option especially with Essentials.  You can't have two Essentials servers in the same domain, so the second AD DNS server would have to be full Windows Server, which is expensive especially because its existence would then mean you'd then need CALs for all of your client devices or users.  Not a likely path for someone who doesn't even keep their Essentials server running full-time.


    Agree with you about the cost of additional servers/CALS. And as I indicated to the OP above, unless he keeps the AD DNS server always up, then his Domain will NEVER function properly if his DHCP is giving out public DNS at ANY point, which makes having one essentially useless.

    You just cannot have it both ways. If he wants to have clients connect when the Server is not available, he should probably create a secondary WiFi network (by using a managed switch to create VLANs - one for the Domain and one for a secondary WiFi SSID for others to connect to. I do something like that for my internet access at home: One for the family to always connect to and one for my test Domain/Domain Clients. It would be additional cost, but it is the only way I can see for him to have a functioning Domain as well as a "backup" network for when the Server is not available. Mixing public and private DNS will just NOT work.

    Thursday, April 4, 2019 9:33 PM
  • Having Internet connectivity during a server outage is better than having nothing, and when the primary DNS server comes back up, clients revert to it automatically. 


    No they do not, unless you manually release/renew/flushdns. There is no way that the DNS would automatically be updated when the server is back up... More than likely the router will continue handing out the wrong (public) DNS info. So NO - JUST NO!

    Mixing Public and private DNS in a Domain is just BAD advice and should never be given. The AD DNS always needs to be up - PERIOD. Otherwise there is just no point in having it working only part of the time as the Domain will essentially always be broken!

    Thursday, April 4, 2019 9:49 PM
  • Hi all,
    thanks for your answers. I am sure that my wse was working before, but I have no idea what now the problem.

    I found two detailed pages to wse2012 and sbs2011e:

    • https://windowsserveressentials.com/2013/06/17/unravelling-the-mystery-of-client-dns-with-essentials-family-servers/
    • https://sbs.seandaniel.com/2011/06/basics-of-local-dns-for-small-business.html

    As I asked above I'm missing two "services" on wse2016 which are named to exist in sbs2011 and wse2012 (and I think these service no longer exist in wse2016, but are replaced somehow):
    "Windows Server LAN Configuration" service on the server
    "LAN Configuration Service" service on the clients

    These servives are adding regkeys etc. and they are responsible that a client can reach out to internet when wse is offline. I know that there was a small time window (around 2min max) until client switched to default gateway(my router).



    • Edited by mammut62 Thursday, April 4, 2019 9:58 PM
    Thursday, April 4, 2019 9:52 PM
  • Having Internet connectivity during a server outage is better than having nothing, and when the primary DNS server comes back up, clients revert to it automatically. 

    No they do not, unless you manually release/renew/flushdns. There is no way that the DNS would automatically be updated when the server is back up... More than likely the router will continue handing out the wrong (public) DNS info. So NO - JUST NO!

    "More than likely"?  I already told you that I've implemented this solution at a client, and I've confirmed that it works fine for Internet connectivity in a server outage scenario AND that the clients revert to using the server for DNS queries when the server comes back up.  But there's also no "DNS automatically updating".  The DHCP server always specifies the AD DNS server as DNS1 and the router's IP as DNS2 in its DHCP responses, even when the server is down, because that's a static configuration on the DHCP server options.  But when the server is down, the clients that received those DNS IPs from DHCP fail over to performing their lookups through DNS2, namely the router -- and then when the AD DNS server comes back up, they start using DNS1 again, namely the server.  Yes, it does work, and no it does not make the domain breakage scenario any worse than it already is with the server down, nor does it have any lasting impact after the server comes back up.  But even if it did, having to perform a flushdns or even a reboot is arguably much less painful than losing all Internet connectivity in an office for the duration of a server outage, especially since some server outages can last a while if you're waiting for replacement parts.  Even mission critical warranty contracts have 4-hour response times, or MAYBE 2 hours depending on your location and vendor (and budget).  But even if a post-outage flushdns or reboot WERE necessary, your position would have you basically telling a client, "Well we COULD give you Internet access during this potentially multi-hour outage, but that would require you to perform a flushdns or reboot later on, so instead we're going to keep you off the Internet for the duration of the outage to spare you that inconvenience."  In what world does that make sense??

    You're standing on the principle of "In an ideal world, clients will only ever use AD DNS."  I agree with that in principle, but in an Essentials deployment where there's only one server, that isn't realistic, and between the two subpar choices of using public DNS only during an outage period or having no DNS at all during that outage, the former is clearly a better choice.  In my client's case, the only DNS records exclusive to AD that they ever need to look up point to the server anyway, and everything else is public DNS queries -- so if the server is down, they don't lose anything by switching to public DNS.  And even if the workstations needed to communicate with each other (which they don't), that would continue to work through NetBIOS during an outage anyway.  And now you're trying to tell the OP he should purchase equipment to allow deploying a multi-SSID, multi-VLAN network just because he wants to take his Essentials server offline sometimes?  Again, if the only AD resource he cares about is the Essentials server, and everything else is Internet queries, then whenever the server is offline, he loses absolutely NOTHING by using public DNS instead.


    • Edited by jphughan Friday, April 5, 2019 2:17 AM
    Friday, April 5, 2019 1:47 AM
  • Hi all,
    is there nobody from the microsoft engineers who knows how server 2016 essentials works with dns magic/automatic?

    Saturday, April 27, 2019 6:50 PM