locked
Mapped drives and DNS. RRS feed

  • Question

  • We've encountered a weird problem recently while we've been migrating shares from one SAN to another.

    We have a bunch of shares setup that users connect their homedrives to. Now the home drives point to a CNAME which then points to another CNAME which goes to the A record of the server hosting the share.

    What has happend on a few servers but specifically on our Terminal Servers is that the CNAME was updated to reflect the changes and the TTL set to 15 minutes. When logging on to a Terminal Server the CNAME hadn't updated in the local cache even after it's reached TTL. Doing nslookup returns the correct results because the DNS server is queried directly. Restarting the "DNS Client" service doesn't update the record either.

    Browsing to the share takes you to the old share because the local cache is called which still points to the older CNAME mapping. My question basically is this... if a drive is mapped or a file is open in \\share and the CNAME for that changes will the servers' local cache be updated while the drive is mapped or a file in that share is open or will it only do this once all connections to that older share is broken and no longer in use.

    My gut tells me that it won't update the record because it is currently in use ie. there's a file open in that share or it is mapped to a drive in one of the users' profiles. Is this the case? Is there some MS article somewhere that explains this behaviour?

    Wednesday, February 1, 2012 12:29 AM

Answers

  • Okay, that being the case, you're not looking at a DNS issue at all, so you can move on from that. That's the only thing I'm certain of at this stage though.

    On the surface of things it sounds like either a Computer Browser related issue, or perhaps network discovery. The one assumption I'm making here is that you're not running WINS. If you are then that's a separate troubleshooting process.

    If it's a computer browser issue, then you might want to wrap your head around these two articles:

    These are very old support articles, but they do illustrate how the service works. The one thing you can forget about are the mentioned support tools - in particular browstat.exe, as it will not function post Server 2003/XP.

    The first thing to check though is whether or not the Computer Browser service has been enabled on the Terminal Server (it's set to manual by default at installation time, so it won't be running unless someone went out of their way to enable it).

    If it's not running, then the issue may link back in with the network discovery behaviour of Windows 2008, which also renders lists of resources that can be contacted.

    I don't have any profound advice on troubleshooting the network discovery side of things, since I've been turning off browsing regardless of how it's implemented for over a decade, which predates this approach. However, here are a couple of basic links that may assist:

    The first link is potentially helpful insofar as it lists the services involved in conducting network discovery:

    • DNS client
    • Function discovery resource publication
    • SSDP discovery
    • UPnP device host

    I don't know if bouncing any of these may prompt a re-initialisation of the discovery process, but it's worth looking into.

    The second explains how network discovery can be enabled or disabled, which may be another avenue for "resetting" the view. I.e. if you were to disable it then immediately re-enable it, perhaps that may restart the process.

    I'm sorry I don't have anything more concrete to offer now that we've moved past DNS. Hopefully something here helps point you in the right direction though.

    Cheers,
    Lain

    • Proposed as answer by Aiden_Cao Friday, February 3, 2012 1:49 AM
    • Marked as answer by Aiden_Cao Wednesday, February 8, 2012 7:45 AM
    Wednesday, February 1, 2012 3:28 AM

All replies

  • Which server do you get if you use the FQDN? I.e. \\<cname>.domain.com\share?

    I'm curious about this as browsing is a separate subject, and it if comes back to that then you might be facing a different issue altogether.

    Cheers,
    Lain

    Wednesday, February 1, 2012 1:10 AM
  • I'll see if I can find another machine still having this problem and try it out.

    I want to avoid this happening in future when we do other migrations or at least have a plan ready to tackle the problem if can document this behviour and workaround.


    <<EDIT>>

    Just tried and browsing to the same share using FQDN works... just using the short name it still goes to old location.

    Wednesday, February 1, 2012 1:15 AM
  • Okay, that being the case, you're not looking at a DNS issue at all, so you can move on from that. That's the only thing I'm certain of at this stage though.

    On the surface of things it sounds like either a Computer Browser related issue, or perhaps network discovery. The one assumption I'm making here is that you're not running WINS. If you are then that's a separate troubleshooting process.

    If it's a computer browser issue, then you might want to wrap your head around these two articles:

    These are very old support articles, but they do illustrate how the service works. The one thing you can forget about are the mentioned support tools - in particular browstat.exe, as it will not function post Server 2003/XP.

    The first thing to check though is whether or not the Computer Browser service has been enabled on the Terminal Server (it's set to manual by default at installation time, so it won't be running unless someone went out of their way to enable it).

    If it's not running, then the issue may link back in with the network discovery behaviour of Windows 2008, which also renders lists of resources that can be contacted.

    I don't have any profound advice on troubleshooting the network discovery side of things, since I've been turning off browsing regardless of how it's implemented for over a decade, which predates this approach. However, here are a couple of basic links that may assist:

    The first link is potentially helpful insofar as it lists the services involved in conducting network discovery:

    • DNS client
    • Function discovery resource publication
    • SSDP discovery
    • UPnP device host

    I don't know if bouncing any of these may prompt a re-initialisation of the discovery process, but it's worth looking into.

    The second explains how network discovery can be enabled or disabled, which may be another avenue for "resetting" the view. I.e. if you were to disable it then immediately re-enable it, perhaps that may restart the process.

    I'm sorry I don't have anything more concrete to offer now that we've moved past DNS. Hopefully something here helps point you in the right direction though.

    Cheers,
    Lain

    • Proposed as answer by Aiden_Cao Friday, February 3, 2012 1:49 AM
    • Marked as answer by Aiden_Cao Wednesday, February 8, 2012 7:45 AM
    Wednesday, February 1, 2012 3:28 AM