locked
Windows Server 2008 R2 loses ability to connect to network share RRS feed

  • Question

  • Hi,

    I have the following environment.
    Server 1: Windows Server 2003 SP2, file server
    Server 2: Windows Server 2008 R2, Terminal Server.

    Server 1 is in OldDomain and Server 2 is in NewDomain.
    Users are migrated from olddomain to new domain using ADMT so that they have a SID history.

    Users in newdomain have a home dir configured in the AD that is pointing to a share on Server 1.

    When Server 2 is newly rebooted users logging into server 2 using a RDP client will get a personal home drive mapped to the share on server 2.

    After a while users will no longer get a home drive mapped when they logon to server 2.

    If I try to map the home drive manually I can sometimes map it on the UNC DNS name (FQDN used) and sometimes using the IP address of server 1.

    When I cannot map the home drive on the UNC name I will get the following error:
    System error 53 has occurred. "The network path was not found"

    When I cannot map the home drive using the IP address I will get the following error:
    System error 59 has occurred. "An unexpected network error occurred."

    In both cases I can ping Server 1 on both the DNS name and on the IP address.

    If I then restart Server 2 then everything is working again as it should for a while.

    Does anybody have a clue what is going wrong and how I can debug the problem?


    Edit: Forgot to write that Server 2 is a virtuel server running in a HyperV Cluster.
    Thomas Forsmark Soerensen
    Sunday, January 17, 2010 10:02 PM

Answers

  • Good news - a hotfix is in the works and a workaround has been identified:

    Root cause is that since this is SMB1 all user sessions are on a single TCP connection to the remote server.  The first user to initiate a connection to the remote SMB server has their logon-ID added to the structure defining the connection.  If that user logs off all subsequent uses of that TCP session fail as the logon-id is no longer valid.   As a workaround for now to keep the issue from happening you will want to have the user not logoff the Terminal Server only disconnect their sessions.

    Monday, June 7, 2010 2:11 PM

All replies

  • Exact same issue here, using Remote Desktop Services on Win2008 R2.  Using FQDN or IP address also works, but just the hostname fails with "Device is not functioning (error 59)". Rebooting fixes it for a while.

    I think this may be a bug.
    Wednesday, January 27, 2010 5:58 PM
  • Good to see I am not the only one.

    Same senario happens to me.


    Also you can restart the server and this function works but then after a period of time it will quit working.

    This is a real problem as I cannot backup to a network share.
    Monday, February 1, 2010 7:22 PM
  • Are any of you running Symantec EndPoint Protection v11.0.4 or lower?
    Monday, February 1, 2010 7:26 PM
  • No we are using McAfee Virus Scan Ent



    Also this does not happen on any of our Xp, Windows 7, or 2003 Server. It does happen sometimes on a 2008 box, but the problem is daily on the 2008 R2 boxes
    Monday, February 1, 2010 7:30 PM
  • There is no Antivirus on our server.


    Thomas Forsmark Soerensen
    Tuesday, February 2, 2010 5:38 AM
  • I have a case open with MS on this.  We are currently now removing various hotfixes and security updates to see if one is causing the issue.

    Friday, February 5, 2010 10:21 PM
  • Looking forward to hear what you will find out.
    Thomas Forsmark Soerensen
    Saturday, February 6, 2010 8:44 AM
  • We still are experiencing the issue after removing several patches.  My guess is that this is a bug that will require more advanced engineers to solve..I'll let you know when I have more information.

    Monday, February 8, 2010 8:42 PM
  • How many of you, besides Forsmark, are having this issue with a Win2008 R2 Terminal / Remote Desktop Services server? 

    Conagher?

    Wednesday, February 10, 2010 12:15 AM
  • I am having this same issue and this time with Server 2008 R2 on Vmware esxi.

    I spoke to Microsoft and they said they cannot support me if it is on Vmware.

    So what hope do I have now?

    Really odd issue and the only resolution is a server reboot once a day.

    Please help me Microsoft as this is critical to our business and after spending £9000 on licencing I do at least expect your product to do what it says on the tin!

    Regards



    Wednesday, February 10, 2010 2:00 PM
  • Just to add to this, I have an error logged in system log :

    Source : DNS Clients Events
    Event ID : 1006

    The client was unable to validate the following as active DNS server that can service this client. The server may be temporarily unavailable or maybe incorrectly configured. (IP of DC)

    I know it's not true as it was working fine, then produced this error, then went off and have just noticed it is working again.

    Just replaced Gigabit switch too but still got same issue. Very temporamental and no idea what is causing it. All my 2003 servers are fine and have no issues. I know that my DNS and WINS is configured correctly.

    Help ......................

    Wednesday, February 10, 2010 3:52 PM
  • Robert, this does not match the symptoms of what others are experiencing..it is likely unrelated.  Try creating a new thread describing your issues.

    Thanks.

    ** Edit - your first post is not specific enough to determine whether it is the same issue, but nobody else has reported DNS-related errors.  Also, Microsoft will support you with a "best-effort" resolution for VMware machines..they should still try to help.
    Wednesday, February 10, 2010 5:48 PM
  • I beg to differ, my problem is almost identical.

    I will give you my config :

    Server 1 : Windows 2003 Server Std SP2 (Active Directory, DNS, Exchange, WINS)
    Server 2 : Windows 2003 Server Std SP2 (Terminal Services)
    Server 3 : Windows 2008 R2 Std (Remote Desktop Services)

    When the problem occurs I cannot access shares on the Windows 2003 server from the Windows 2008 R2 server.

    I can however, ping the other servers and access the shares via IP address.

    if I do net view \\<IP ADDRESS> all is ok. If I do net view \\<HOSTNAME> then it does not work and the above DNS event is logged.

    Also, is I do net view \\<FQDN of other servers> then it works!

    The error I get at the prompt is :

    System error 53 has occurred. "The network path was not found"

    A reboot of the 2008 R2 server sorts it out for a few hours and then it happens again. My only solution at the moment is to reboot.

    Server 2 has no issues what soever so I know that DNS on my local network is fine.

    The other odd thing is that the Server 2008 R2 error doesn't always occur on the same network share. Sometimes it cannot access Server1 and today it was Server2 it could not access via hostname. IP address and FQDN always work.

    I did nothing to the server today whilst trying to get support off Microsoft then it just started working again. Very frustrating.

    Very odd and not DNS related. Seems there is a bug in 2008 R2 server somewhere.

    Regards




    Wednesday, February 10, 2010 8:49 PM
  • Can you disable all power saving settings, esp. any associated with NIC hardware?
    Wednesday, February 10, 2010 9:40 PM
  • Robert,

    the best way to get help with this is to open a Support Case. Premier Support should be able to help you with this issue.

    Besides that I would recommend that you create a Network Trace from the "Bad Case" (when the net view \\hostname is failing) on the R2 Server to check why it is failing.

    Some basic questions:
    Any Antivirus/Firewall/Fancy Filter Drivers on the R2 Server?
    Are you using NIC Teaming?
    Are you using the latest NIC Drivers?

    Thanks
    Philipp
    Wednesday, February 10, 2010 10:30 PM
  • I am pretty sure the power settings are all off and in particular I remember unticking the Nic power save option. Firewall is off and am using vmware remember so using their latest driver. Mcafee enterprise is on server but it was producing the fault before I installed that. Hopefully get to the bottom of this soon.
    Wednesday, February 10, 2010 11:10 PM
  • I apologize Robert, you are correct - it sounds like the same issue everyone is having.

    My existing case number is SRX110012765672890 if you decide to open your own ticket; you can have them look this one  up as well.  My support tech is currently evaluating traces, but we've determined when the issue occurs, the server simply stops trying to go out over the network to access the remote server - no packets are sent.

    Thursday, February 11, 2010 12:55 AM
  • The other common factor in all of this is that we are all using Virtual Machines (although the original poster is Hyper-V, the rest are VMware), and we are all running Terminal Services.
    Thursday, February 11, 2010 12:56 AM
  • I am getting the same DNS error as well..you may be onto something, Robert.  It is easily missed. Forsmark, are you getting the same thing in the System log, event 1006?


    The client was unable to validate the following as active DNS server(s) that can service this client. The server(s) may be temporarily unavailable, or may be incorrectly configured. 10.32.10.19

    Thursday, February 11, 2010 12:59 AM
  • I am currently on a support call with Microsoft so hopefully we can get to the bottom of this.

    Thanks for your help so far.

    Rob


    Thursday, February 11, 2010 9:41 AM
  • ok, latest update. The problem happened this morning and this time the NetBios net view works but the IP doesn't.

    so net view \\<HOSTNAME> works

    net view \\<IP ADDRESS> does not.

    Very odd

    :(

    Thursday, February 11, 2010 12:02 PM
  • Hi Rob,

    What did Microsofting say. Did you call them?
    Thomas Forsmark Soerensen
    Thursday, February 11, 2010 12:55 PM
  • I am still on phone, they are logged into server looking as I type this!

    Thursday, February 11, 2010 1:01 PM
  • ok.. great... Looking foreward for a soulition.
    Thomas Forsmark Soerensen
    Thursday, February 11, 2010 1:02 PM
  • He did some packet captures but doesn't seem to know what is causing it.

    Funny thing is, is that it started working again whilst he was logged in and nothing logged in event viewer.

    the saga continues ...............

    Thursday, February 11, 2010 1:36 PM
  • My tech has been troubleshooting for a week(!) with no resolution.  Eventually they will escalate to a top-level engineer..we'll see who gets there first lol.
    Thursday, February 11, 2010 3:43 PM
  • I mentioned your case ID and the guy I spoke to said he didn't recoqnise it on the system. Obviously must be using Server 2008 R2 :)


    Thursday, February 11, 2010 3:50 PM
  • Same issue here.  Glad I found this thread, I might have thought I was going nutz. Just rebooted the server and voila, it works, but for how long. Customer doesn't like TS anyway, don't want to give them another reason to dump it.  Anything new on the find it fix it front ? Oh and we're using Hyper V.
    Thursday, February 11, 2010 5:16 PM
  • I mentioned your case ID and the guy I spoke to said he didn't recoqnise it on the system. Obviously must be using Server 2008 R2 :)




    Are you in the UK?  I am in the US.  I wonder if the support systems are different.  From the email:

    SR number 110012765672890.


    Thursday, February 11, 2010 5:51 PM
  • This issue just started on my server 2 days ago, was working ok for 3 months. IP and FQDN work ok Host name stopped working.
    I am not using a virtual machine, but use remote desktop service(terminal server).
    I found this thread with a search on "The client was unable to validate the following as active DNS server" error I received.
    Thursday, February 11, 2010 6:19 PM
  • Our client just started using the Terminal server. We stood it up maybe 2 weeks ago. It was fully patched at that point, but does not yet have the latest patches released on Tuesday. So they just start to use it and this shows up. Not very warm and fuzzy for 2008 R2, considering how long the server package has been out. Lousy testing if you ask me.
    Thursday, February 11, 2010 6:57 PM
  • Hi,

    Experiencing the exact same issue as stated about except we have 2 Windows Server 2008 R2's acting as Terminal Servers connecting to Server 2003 Shares.  Rebooting the terminal servers seems to resolve the problem for about 2-4 days and then re-appears.  The XP/Vista/Win7 workstations on the network has no problem accessing the shares on the 2003 Server, only the 2008 R2 servers.

    Connecting the the 2003 Shares using the FQDN or IP address works, but using \\servername returns network path not found.  Setting up WINS on the network did not resolve this, or adding a static entry in the hosts file to the server.

    There is no firewall software installed on the servers and we don't use Symantec products on the network (No Symantec Endpoint security). 

    Viewing of the eventlog also turned up the Event ID: 1006, could not validate DNS server, even though name resolution appears to be functioning without a problem.


    Friday, February 12, 2010 1:18 PM
  • Todays update :

    No word from Microsoft today after they said they would call back and I am unable to upload the capture files as they are too big.

    The server today has worked fine and have had no reported issues. Server has not been rebooted since Tuesday so not sure if anything has changed.

    Will have to wait until Monday for more updates.

    Regards

    Friday, February 12, 2010 4:31 PM
  • Microsoft have told me to look at this kb article :

    http://support.microsoft.com/kb/929851






    Friday, February 12, 2010 5:34 PM
  • Hello,

    I also have a 2008 R2 terminal server that loses it's ability to browse network shares on our 2003 file server.  I looked at the kb article and this does not apply because I am not running a firewall on any of the servers involved.  Has Microsoft suggested any other ideas on what might be causing the issue.  I have Trend Micro virus protection.  I have disabled it for now to see if that make a difference.  I will report back later this week if the shares stay connected.

    Thanks
    Monday, February 15, 2010 9:15 PM
  • My MS tech made some registry changes and we rebooted; it's been several days without the issue reappearing.  I'm trying to get the registry changes from him, and will post them for others to try.

    Monday, February 15, 2010 11:18 PM
  • Hi GrandMasterPhil,

    That would be great. The problem is very annoying.
    Thomas Forsmark Soerensen
    Tuesday, February 16, 2010 12:04 PM
  • My server hasn't failed in the past few days and I have done nothing to it or even rebooted it.

    I still want to get to the bottom of this issue as it will no doubt rear its ugly head again!


    Tuesday, February 16, 2010 12:14 PM
  • Hi GrandMasterPhil,

    That would be great. The problem is very annoying.
    Thomas Forsmark Soerensen

    Unfortunately the issue DID reappear today, so the registry changes don't appear to have worked.  Also, no correlating DNS entries.  Hoping for an escalation today to a higher-level team within MS.
    Tuesday, February 16, 2010 6:37 PM
  • I have opened a case wit microsoft as well.
    Thomas Forsmark Soerensen
    Wednesday, February 17, 2010 9:43 PM
  • Try and reference my existing case number above to your tech; hopefully if enough of us open up cases they will escalate the issue.
    Wednesday, February 17, 2010 11:05 PM
  • My case is being escalated...yay...

    Thursday, February 18, 2010 5:59 PM
  • I'm keeping an eye on this thread too as I'm having a similar issue.  Added an NFS share which I'm able to see from every client (workstation and user) except from our 2003-based file server.  Also running Endpoint Protection which isn't the problem (disabling it didn't work).  No firewall on the server.  Whenever I try to connect to the share's IP address or via a UNC path, I get a "unexpected network error occurred."  Nothing reported in the Event Viewer.  DNS is fine on the AD domain.  Flushed the DNS on the file server.  Even performed a dcdiag on the two domain controllers and all checks out.  Thanks for keeping us in the loop.  :)
    Thursday, February 18, 2010 8:35 PM
  • Just happened again, after about 3 days.  Waiting patiently to hear of a fix, all the client sees is no access to the drives and it's p(&&(ng them off.  Then they put in a ticket and have to wait til we pick it up during working hours and do the reboot.  Don't think they'll ever want us to roll out another TS box.
    Friday, February 19, 2010 6:26 PM
  • Why don't each of you having this problem summarize in one line what your issue is, include another line for setup summary that includes what Service pack level and what updates are applied on the system.  From my vantage point thios sounds like an issue that started recently so I would suspect a recent update could be causing the issue.

    Don Murphy
    Friday, February 19, 2010 7:39 PM
  • Why don't each of you having this problem summarize in one line what your issue is, include another line for setup summary that includes what Service pack level and what updates are applied on the system.  From my vantage point thios sounds like an issue that started recently so I would suspect a recent update could be causing the issue.

    Don Murphy

    Hi Don,

    During my troubleshooting session, we removed all recent patches, but the issue persisted.  There are no service packs for Win2008 R2.

    Phil

    Friday, February 19, 2010 8:20 PM
  • Just happened again, after about 3 days.  Waiting patiently to hear of a fix, all the client sees is no access to the drives and it's p(&&(ng them off.  Then they put in a ticket and have to wait til we pick it up during working hours and do the reboot.  Don't think they'll ever want us to roll out another TS box.

    Hi Bruce,

    One thing you can do for your client is to change any scripts, drive mappings, etc. to use the FQDN for the computer rather than the NetBios/Computer name.  This should work around the issue until we are able to resolve it with Microsoft.

    Phil

    Friday, February 19, 2010 8:21 PM
  • I thought of doing that but that is the reason we are using a terminal server. We have an old legacy app which relies on the NetBios UNC path for the app to actually work. If the ability to access the share via NetBios breaks then the whole app does too. To change the code of this app would be way to expensive and to be honest, not worth it. As I have previously said the problem didn't occur this week, no idea why but no doubt it will come back.
    To just add insult to injury, just noticed another problem. Not related but if you try and use the R2 server as a terminal server and connect to it with dual screens you now get dual screen remote desktop which is cool. However, as an adminitrator you cannot connect to sessions anymore. You can if on single screen, just not dual. I think this is more of a feature missing than a bug and hopefully MS will add it.

    I will keep you posted if anything happens.

    Rob

    Saturday, February 20, 2010 12:22 AM
  • I am having the exact same issue. The network shares on Windows 2008 R2 (working as a Terminal Server) are dropping randomly. Using FQDN does not always work. It is going in a cycle. After a fresh reboot, \\servername\Share works. After a while, it does not work and we need to use \\servername.domain\Share or \\ip-address\share. Then after a while, that does not work again, and we have to go back to \\servername\Share. 

    So for the time being, we just put 2 lines (instead of 1) in the drive mapping scripts in order to workaround it.

    net use U: \\servername.domain\Share
    net use U: \\192.168.1.1\Share

    Hopefully this will be resolved soon. Its driving me crazy for the past few weeks.

    Edchy



    Edchy Tsoi
    Tuesday, February 23, 2010 2:24 AM
  • Hi Edchy,

    Thank you for the feedback.  It is interesting that you have a problem with the FQDNs and the IP addresses as well..I wonder if that would be the case for the rest of us, if we were to switch to that method.  I'm guessing the answer is Yes.  The issue is not NetBIOS, because I've disabled NetBIOS entirely and the issue still remains.

    Unfortunately my escalated technician is being very poor at returning my telephone calls.  Hopefully I will touch base with him tomorrow.

    Phil
    Tuesday, February 23, 2010 4:13 AM
  • My case is escalated, but I'm waiting for my issue to return again. 

    I did learn that 3 other similar cases have also been escalated, so I'm sure we'll get a resolution eventually.
    Thursday, February 25, 2010 12:08 AM
  • I am having this same issue and this time with Server 2008 R2 on Vmware esxi.

    I spoke to Microsoft and they said they cannot support me if it is on Vmware.

    So what hope do I have now?

    Really odd issue and the only resolution is a server reboot once a day.

    Please help me Microsoft as this is critical to our business and after spending £9000 on licencing I do at least expect your product to do what it says on the tin!

    Regards



    That is wrong!

    According to: http://support.microsoft.com/kb/957006 and http://www.windowsservercatalog.com/svvp.aspx Microsoft supports Windows Server 2008 R2 on VMware Virtualization.
    Thursday, February 25, 2010 8:53 AM
  • Has anyone recieved a fix from microsoft on this problem yet. I'm in the exact same boat. Windows RDS running on Hyper-V core server.
    Thursday, February 25, 2010 6:10 PM
  • Hi,

    I have just installed a new Server 2008 R2 acting as terminal server this week.
    It's linked to a domain with SBS 2003 SP2 server installed.

    Exactly the same issue happened this morning. All mapped network drives which had been working yesterday stopped working.

    Pinging the hostname resolved to the FQDN.
    Pinging the IP address responded.
    Pinging the hostname failed to respond.

    I tried browsing on the network and was able to see all the other servers on the network however as soon as you try to access the main domain controller or another 2003 standard server on the network - you get the error.

    Fully that as soon as you restart the server, everything starts working fine...

    I am proposing that a 'solution' in the short term is to schedule a reboot of the server out of hours to ensure that the restart is happening on a daily basis so that the users don't experience any issues...

    However it would be really good if MS could respond with a solution to this - clearly there are a number of cases where this has been proved.
    Friday, February 26, 2010 1:48 PM
  • I have the same issue, except a little different I have 2 2003 servers W2003-01, and W2003-02, and 2 2008 R2 Terminal Servers RD001 and RD002.

    When I goto command prompt on RD001 and type net view \\W2003-01 it says network path denied

    When I goto command prompt on RD001 and type net view \\W2003-02 it shows all of my shares

    When I goto command prompt on RD002 and type net view \\W2003-01 it shows all of my shares

    When I goto command prompt on RD002 and type net view \\W2003-01 it says network path denied

    It does not follow one 2008 server or one 2003 server.

    Does any one know which MS Patch broke the world this time?

    I have opened a case with MS as well, I will reference you guys cases and provide mine as soon as they call back.

    Friday, February 26, 2010 5:20 PM
  • Just an update .............. Problem just happened again after about 2 weeks of uptime. Time to reopen case with M$

    :(


    Monday, March 1, 2010 5:08 PM
  • Had the same issue as before where I get the 1006 DNS Clients Events logged in event viewer but by the time Microsoft logged in the problem had resolved itself again ........ grrrrrrrrrrr.

    I will have to keep monitoring it all day.

    Tuesday, March 2, 2010 9:53 AM
  • I am, is there something wrong with it?
    Having all the same issues as everyone here, cant seem to find an answer anywhere.
    Tuesday, March 2, 2010 9:06 PM

  • Not sure this is the answer but Microsoft directed me to this hotfix :

    <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:1; mso-generic-font-family:roman; mso-font-format:other; mso-font-pitch:variable; mso-font-signature:0 0 0 0 0 0;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4; mso-font-charset:0; mso-generic-font-family:swiss; mso-font-pitch:variable; mso-font-signature:-520092929 1073786111 9 0 415 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin:0cm; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin;} a:link, span.MsoHyperlink {mso-style-noshow:yes; mso-style-priority:99; color:blue; text-decoration:underline; text-underline:single;} a:visited, span.MsoHyperlinkFollowed {mso-style-noshow:yes; mso-style-priority:99; color:purple; mso-themecolor:followedhyperlink; text-decoration:underline; text-underline:single;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt;} @page Section1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;} div.Section1 {page:Section1;} -->

    http://support.microsoft.com/kb/978738


    It does not describe my problem exactly but I have applied anyway. Will let you know how I get on.

    Rob

    Thursday, March 4, 2010 9:38 AM
  • Just an FYI.  We are experiencing this same bug.  Have applied the hotfix  http://support.microsoft.com/kb/978738 and this has not addressed / fixed the issue.  It just happened to us this morning again.

    Hoping one of you that have a ticket with MS on this will find the answer soon...

    Russ
    Tuesday, March 9, 2010 4:02 PM
  • I didn't think that hotfix would fix it as it didn't describe the problem I was having. My server hasn't faulted for a few days but it will.


    Tuesday, March 9, 2010 4:29 PM
  • I am so glad I came across this post.  I have been experiencing this problem on a development environment (VMware) for a while.  Originally we were not running R2 but I upgraded the environment to R2 hoping this release would resolve our issues but with no luck.  Essentially we have folks who log on to a Windows 2008 R2 server where an M drive is mapped to another Windows 2008 R2 server.  Works for a few days and then developers report the M drive is no longer available.  Only way to resolve is to reboot.  Now it is happening in their QA environment (Dedicated servers).  I'm stumped.  I can't find anything or find any reason for this to occur.
    Wednesday, March 10, 2010 10:43 PM
  • It appears that In my case the issue is reproducable, when my users repeatedly try to add a printer that it cannot communicate to. According to MS there is a list called the "Unavailable Server List" This list is part of the SMB and is only stored in memory, not in the reg or in a file any where.
    They claim this list is designed to speed up the time out of server requests.
    Microsoft does not know why but for some reason in 2008 once your DNS name gets on the "Unavailable Server List" it is not purging its self properlly. The only remedy at this point is a reboot.
    However I am having users that are having printer issues and are trying over and over again to add these printers Thus creating a large number of failed connections. Which explains why we are only seeing this on terminal services.

    MS please release a patch where a printer connection is excluded from the unavailable server list or a utilty that will allow us to purge the entries manually.
    Thursday, March 11, 2010 5:00 PM
  • My issue has just reoccured. This time I could not access the share via NetBios or IP. I got Microsoft to login to do some network traces and it just starting working again.
    I am still getting the DNS event 1006 logged in Event Viewer.
    I am not sure it is printer related as we don't have any on our system.
    Frustrating problem and obviously a bug in the IP or SMB stack.

    I will keep you updated .......................

    Rob

    Friday, March 12, 2010 3:53 PM
  • I am going to test my theory tonight, but have any of you noticed if this problem occurs when the server hosting the mapped/network drive is rebooted while the RDS server is up? I'm having the exact same issues as everyone else here. I have a 2008 R2 server running RDS. All of my other servers are 2003 R2.

    I think that once the other server is restarted, somehow my RDS server forgets about it, and can no longer connect unless full ip or FQDN is entered. Still, this doesnt help with the solution.

    Monday, March 15, 2010 6:12 PM
  • Just came across this thread tonight as I thought I was losing my mind.

    Windows 2008 R2 Terminal Server
    Windows 2003 R2 File Server

    All servers running on Vmware ESXi 4 and Dell PowerEdge R710 boxes with local storage.

    The 2008 Terminal Server will lose the ability to access the 2003 File Server by hostname.  IP address and FQDN work fine.  All DNS etc. responds normally.  Rebooting the server restores functionality. 

    Haven't noticed this with any 2008 to 2008 shares.

    Other 2008 R2 servers can access the 2003 server by hostname no problem, it only seems to be the terminal server.

    Chris

    Tuesday, March 16, 2010 4:30 AM
  • An update:

    My issue reoccurred finally, and I was able to send Microsoft the diagnostic information they requested.  Hopefully more to follow later this week.  As I mentioned earlier, Microsoft is tracking several of these cases, so the issue has their attention.

    Phil

    Tuesday, March 16, 2010 11:19 AM
  • I am going to test my theory tonight, but have any of you noticed if this problem occurs when the server hosting the mapped/network drive is rebooted while the RDS server is up? I'm having the exact same issues as everyone else here. I have a 2008 R2 server running RDS. All of my other servers are 2003 R2.

    I think that once the other server is restarted, somehow my RDS server forgets about it, and can no longer connect unless full ip or FQDN is entered. Still, this doesnt help with the solution.


    Good idea, but I just checked my server, and it hasn't restarted for nearly 24 days.  The issue just came back a few days ago ;/
    Tuesday, March 16, 2010 11:22 AM
  • My MS support guy also said there are a few cases with similar symptoms being logged so hopefully we will get a resolution soon.

    Tuesday, March 16, 2010 11:59 AM
  • exact same problem here with my 2008 R2 TS and my 2003 SP2 Print server.
    Tuesday, March 16, 2010 3:38 PM
  • Hi again,

    I have been running this as a case with Microsoft. They had me doing the following:

    I haven't seen the issue since. (For over a week now. Before the issue came nearly every day)

    Can any of you confirm that the same changes will solve the problem for you?

    One pain though. MS sees the problem as solved and will not do further investigation. So even though that I had to change settings away from the default settings set by the Windows Server 2008 R2 installation MS will not do anymore to solve the problem for any new installations. :-(

     


    Thomas Forsmark Soerensen
    Monday, March 22, 2010 9:08 AM
  • I have not done the above but have had Microsoft change settings here and there. I have had the problem go away and then reappear after about 10 days for no apparent reason. The MS guy said that several cases of similar issues had been logged so a fix should be on its way soon. I really hope so as it is really beginning to irriate me and the end users.

     

     

    Monday, March 22, 2010 9:26 AM
  • hi! i've got the same problem.it just started last week. but somehow since yesterday, i have to restart every 1hr, if not we could not connect to the network... if someone have an answer to this problem, it would be a great help! thank you!
    Tuesday, March 23, 2010 8:53 AM
  • Hi, we also have the same problem...

    Windows 2008 R2 x64 Terminal Services running in a virtual (hyper V)
    It's the second time this has happend..reboot the server and we're good to go.

    Tuesday, March 23, 2010 11:16 AM
  • Same problems here with 2008r2 ts and a Netapp fas2020. (hyper-v)

    sometimes it works, sometimes it wont.

    Events:

    The client was unable to validate the following as active DNS server(s) that can service this client. The server(s) may be temporarily unavailable, or may be incorrectly configured. <IPNUMBER>

    NtpClient was unable to set a domain peer to use as a time source because of DNS resolution error on ''. NtpClient will try again in 3473457 minutes and double the reattempt interval thereafter. The error was: The requested name is valid, but no data of the requested type was found. (0x80072AFC).

    When the mappings succeed, they become disconnected after a short time. Both ip mapping or dns name mapping

     

    Thursday, March 25, 2010 9:19 AM
  • Same issue here. Windows 2008 R2 TS with Windows 2003 and SQL server 2005.
    Thursday, March 25, 2010 8:02 PM
  • Experiencing the same issue. And not only on Win 2008 R2 servers that contain RDS roles. Also experiencing this issue on a Win 2008 R2 machine out of the box with no patches and no GPO linked to it on a Hyper-V cluster.

    When we move the machine in question away from the Hyper-V cluster onto a single Hyper-V host we can connect to the share without any issues. In our case it seems to be related to the hyper-v cluster.

    Did anyone get any feedback on the cases they opened at MS support?

    Friday, March 26, 2010 2:36 PM
  • I am still waiting for feedback...my case has been escalated to the networking team within MS, but haven't heard anything.  It does not appear to be Hyper-V or VMware related..my guess is that this issue would happen on a physical server as well.

    Phil

    Monday, March 29, 2010 6:02 PM
  •  

    This is my latest response from Microsoft :

     

     

    I hope you are doing well. I wanted to update you that our Product team is investigating further on the issue and still performing analysis. I will update you as soon as I get response from them. I appreciate your response and apologize for the time being taken however since this issue seems to be a trend currently our teams are working on it in-depth.

     


     

    Tuesday, March 30, 2010 3:18 PM
  • I am also having the same problem.  In my case, my Windows 2008 R2 terminal servers are losing network connectivity to one particular server running Windows 2003.  The 2003 server handles printers, among other things, so I agree that it may have something to do with printer connections.

    The 2008 R2 terminal servers are guests on the same Hyper-V host.  The 2003 server is a physical machine.

    I assume someone from MS is monitoring this thread, so I'll share a few other things that may be relevant:

    • I have also seen the same problem on Windows 7 systems, but much more rarely.  (only 5 cases out of 200 Win7 systems in the last two months)
    • It seems to happen more on systems where users log on and log off frequently.
    • I have seen error codes 0x80040005 and 0x80070035 trying to access the server from Windows Explorer, and 0x80070bc4 trying to connect printers with vbscript.
    • I have a Windows 2008 (not R2) terminal server running on the same Hyper-V Host as the 2008 R2 servers.  The 2008 server does not experience this problem.
    • If I am already logged on to the computer before the problem starts, and I have a connection open to \\server\share1, and then the problem happens, I can continue using \\server\share1 but cannot open a connection to \\server\share2.  Additionally, users who logged on later cannot access \\server\share1.
    • In a couple of cases, I was able to resolve the problem by restarting the Workstation service--although this doesn't always work.
    • I have a hunch the problem may be triggered if the server is under heavy load and a printer connection takes a long time to connect.  For testing, I moved the printer to a different server.  I'm waiting to see if the connectivity issue moves too.
    Tuesday, March 30, 2010 7:57 PM
  • Problem reoccured, MS had me run command nbtstat -RR as a possible resolution. This solution did not work.

    Wednesday, March 31, 2010 3:06 PM
  • It may or may not be related, but I found your long thread while trying to solve another problem with some similar configs:

    When logged on to 2008 R2 in a terminal server session: could sometimes see, sometimes not, shares on a 2003 file server.
    When we could 'see' the shares, enumerating them in Windows Explorer was EXTREMELY slow. Multiple reboots made no difference.

    So, refer to this other thread:  http://social.technet.microsoft.com/Forums/en-US/winservergen/thread/8ac892c8-42b6-4b59-b48c-0629865378eb

    In short, on the 2003 server, open the Properites of the network adapter, and, if not there, "Install | Service | QoS Packet Scheduler".

    - worth a try.

    Cheers

    Thursday, April 1, 2010 4:32 AM
  • Rob, et al,

    Have you made any progress on this issue with MS? 

    We have two 2008R2 servers setup as RDS servers.  Suddenly users lost the ability to map shares on an older NT server.  Tried above suggestions using the IP address and FQDN and both seem to work.  Since I have 100+ users, I am not relishing changing their mappings. 

    I noticed this error after running into problems with users' inability to launch Word or Excel on one of the servers.  I rebooted the server but then the mapped drives to NT shares were Xed out. 

    A couple of days before this, I loaded .NET 3.5 on each server since an app I was loading, DWG TrueView, required it.  Wonder if this causes some kind of registry change.  The other server has been running ok but worry it too will exhibit this problem if it is rebooted.

    Bob Kann

    Monday, April 5, 2010 3:10 PM
  • Hi nothing back from MS. My issue seems to change in symptoms regularly. Mostly though, I can't access shares via netbios names but sometimes I cannot access on the IP address and the netbios works. FQDN seems to always work. Very random and also random as to what server it won't access. I have approx 5 servers in this setup and have setup a share on each server to test whenever the problem occurs.

    MS have taken logs and traces etc but nothing has come back yet. I will update here on any new info.

     

    Rob

     

     

    • Proposed as answer by rkann Wednesday, April 7, 2010 3:18 PM
    Monday, April 5, 2010 4:31 PM
  • I received a response from Microsoft today - it appears they have isolated the issue and are requesting additional diagnostic information.  Definitely looking like a bug, but hope is on the horizon.

    Phil

     

    Monday, April 5, 2010 4:41 PM
  • What are the A and PTR records look like on the DNS server for this problem server?
    MCSA Windows 2003 MCP Windows NT 4 Workstation
    Tuesday, April 6, 2010 2:24 PM
  • Ugh, nevermind, I'm an idiot.  I had the the iDrac6 Express set to the same IP as the server.
    Tuesday, April 6, 2010 8:55 PM
  • i have got new main server running 2008 r2

    after a few updates i now cant access shares on nas box (netgear 1100) or the 2000 servers

    any help would be very welcome

    Wednesday, April 7, 2010 2:27 PM
  • Rob, et al,

    Oops, clicked on "Propose as an answer" on your post, my bad!

    Anyhow, I seem to have solved this problem, at least for now.  Quite simple really,  under Network Connections, TCP/IP Properties | Advanced.  I added the WINS server addresses, and under NetBios settings, checked "Enable NetBios over TCP/IP".  This alone did not do it though.  After hours, I rebooted the server and viola, I can now map drives using the NetBios name.  So I don't know which action actually solved it but it's working for now! 

    Bob Kann

    • Proposed as answer by rkann Wednesday, April 7, 2010 3:30 PM
    Wednesday, April 7, 2010 3:30 PM
  • Bob,

    It will come back.  The issue is not related to NetBIOS, Wins, or DNS - it has to do with how the OS is remembering invalid Share names.  According to the MS tech I am working with, Windows is supposed to expire the list every 30 seconds.  For whatever reason, in our situations, the name is being added, but the name is not  ever expiring from the list.

    Keep rebooting everyone..they are still working on a solution.

    Phil

     

    Wednesday, April 7, 2010 7:15 PM
  • Hello Gentlemen,

    I read another post and it seems the issue is related to the NIC drivers and Virtual machine. If possible, try disablig the VM NIC and see what ahppens. I too am experiencing issues with it losing connection to a WIN XP machine. I have a few VMS installed as this is my Workstation and test machine. But I rarely run the VMS.

     

    http://social.technet.microsoft.com/Forums/en-US/winserverPN/thread/14ee8c6c-8cfe-41e4-9e63-95a69176bd55/

    Wednesday, April 14, 2010 6:57 AM
  • Hello Gentlemen,

    I read another post and it seems the issue is related to the NIC drivers and Virtual machine. If possible, try disablig the VM NIC and see what ahppens. I too am experiencing issues with it losing connection to a WIN XP machine. I have a few VMS installed as this is my Workstation and test machine. But I rarely run the VMS.

     

    http://social.technet.microsoft.com/Forums/en-US/winserverPN/thread/14ee8c6c-8cfe-41e4-9e63-95a69176bd55/

    There are people with Hyper-V, VMware, and physical boxes in this thread, and it looks like a different issue.  For a majority of the people in this thread, Microsoft has already acknowleged a bug in the software. 

    MS looks like they are in the final stages of collecting diagnostic info from my server, the a fix is in sight!  This would go a lot faster if the issue wouldn't take a week to reappear (sigh).

     

    Wednesday, April 14, 2010 5:57 PM
  • It looks that we solved the problem with the routing in our case which i worked on with Freek Berson (also in this treath)

    We had the same problem with a hyper-v cluster. Microsoft said  to disable the ip.fastpath option at the Netapp commandline

    This is what Freek receveid from Microsoft:

    From what I have researched, with this option enabled the NetApp storage system attempts to use MAC address and interface caching (fastpath) to try to send back responses to incoming network traffic by using the same interface as the incoming traffic and (in some cases) the destination MAC address equal to the source MAC address of the incoming data.

     

    Since NLB spoofs the MAC address every time it responds back to the client, in our case the Netapp server might not be able to map the MAC correctly.

    So this was a routing problem right here. It is solved now. For the pepole who are using vmware, just try to use one nic within vmware for routing, maybe this wil help you to understand where it is going wrong.

     

     

    Tuesday, April 20, 2010 11:01 AM
  • It looks that we solved the problem with the routing in our case which i worked on with Freek Berson (also in this treath)

    We had the same problem with a hyper-v cluster. Microsoft said  to disable the ip.fastpath option at the Netapp commandline

    This is what Freek receveid from Microsoft:

    From what I have researched, with this option enabled the NetApp storage system attempts to use MAC address and interface caching (fastpath) to try to send back responses to incoming network traffic by using the same interface as the incoming traffic and (in some cases) the destination MAC address equal to the source MAC address of the incoming data.

     

    Since NLB spoofs the MAC address every time it responds back to the client, in our case the Netapp server might not be able to map the MAC correctly.

    So this was a routing problem right here. It is solved now. For the pepole who are using vmware, just try to use one nic within vmware for routing, maybe this wil help you to understand where it is going wrong.

     

     

    How is a NetApp storage system related to being unable to access a remote file share?  Everyone else in this thread (including myself) finds that access to the remote server works by IP and not by name, which wouldn't be the case if it involved MAC addresses.


    This still doesn't seem like it would apply to most situations with a guest operating system.  For one, I'm not using any MAC spoofing.  Second, our guest OS (the Win2008 R2 server having an issue) does not have any direct access to storage, nor do any of the other 20 virtual machines (running various versions of Windows) experience any issues similar to what is in this thread.  I think Freek was experiencing something different from the rest of us.

    Tuesday, April 20, 2010 10:33 PM
  • Hello Phil, in our case the Netapp acts as a Microsoft CIFS Share server en is added to active directory. So you have to see this as a Windows server serving a share.
    By ip things are fine, but that is simple routing. In our case the Netapp option fastpath adresses by mac adres.The problem only occured at the HYPER-V cluster windows 2008 R2. We had the exact same event id's and error messages like the topic starter. We are using RDS.

    Due to the advanced options of a hyper-v cluster it could not access the share. Other Hyper-v hosts (not in a cluster) can access the share. It has something to do with NLB and routing. Our Netapp setting did the trick. I wrote this post to attend everybody to our conclusion. Maybe this helps you to solve your case.


    It might be possible that a router, switch or whatever is a problem with your Hyper-V cluster in terms of routing. Just trying to help here. You might want to add a simple switch beteween your servers to see if this is the case. In mine opinion routing techniques could be your problem. In our case it was the Netapp, it could have been a cisco switch, or whatever.

     

    regards,

     

    Tomas

     

     

    Wednesday, April 21, 2010 7:30 AM
  • Hello Tomas,

    Your issue is different from the others in this thread.  We all are using Terminal Services within a guest VM, and have no issues on the host computer.  Microsoft is actively working on a patch for this.

    Phil

     

    Wednesday, April 21, 2010 4:15 PM
  • I will quote Robert:

    "When the problem occurs I cannot access shares on the Windows 2003 server from the Windows 2008 R2 server."

    We have 2008R2 terminal services (RDS server) in a Hyper-V cluster we cannot reach shares at a 2003 server.

    Seems to me to be the exact same problem

    Thursday, April 22, 2010 6:56 AM
  • I will quote Robert:

    "When the problem occurs I cannot access shares on the Windows 2003 server from the Windows 2008 R2 server."

    We have 2008R2 terminal services (RDS server) in a Hyper-V cluster we cannot reach shares at a 2003 server.

    Seems to me to be the exact same problem


    It isn't.  This issue is already escalated to Microsoft's highest techs and they have already identified the bug.  The issue is not platform dependent and appears in a variety of different configurations.  In all of our situations, everything works correctly for ~1 week, and then we start to have issues.  It does not sound like this was the case in your configuration.

    Phil

     

    Monday, April 26, 2010 6:05 PM
  • Not sure if what I'm experiencing is the same issue or not, but we have 2 2008 R2 servers in a clustered environment that we just deployed for doing Hyper-V clustering onto a SAN. We were anticipating being able to map network shares on other servers (outside of the domain that the 2008 R2 servers are in) to be able to bring other data into the new SAN/Clustered environment, but we are unable to map any drives to any other outside systems.

    The 2008 R2 servers all seem to be able to communicate with themselves fine and drives can be mapped between them, but when you attempt to map a drive to any other system (2008 or 2003 in our case), it just sits there and continues to prompt for the right login credentials. The other servers we're attempting to map to are all stand alone systems not joined to any domain, so I doubt this is a authentication issue and from reading through the posts here, our symptoms seem to emulate what everyone else is seeing.

    We also seem to be experiencing random connectivity issues too. We can ping from the 2008 R2 servers to the other servers, but it appears to have issues to. When you do an initial ping, it first reports that the destination host is unreachable and then it starts to respond to pings. You try again a few minutes later and the same thing happens again. Wasn't sure if anyone else had seen this also in their testing.

    Thanks for any feedback and/or suggestions.

    Tuesday, April 27, 2010 2:16 AM
  • H Panther04,

    Sorry, but doesn't quite to be the same issue, especially the authentication prompt.  It may be related to security authentication mechanisms (e.g. kerberos, strict name checking) or problems with mismatched passwords since you are not in a domain environment.  You might want to try a separate thread.

     

    For reference:

    The poster of this thread and many responders  have the following common points:

    - A Windows 2008 R2 terminal services environment running in a Hyper-V or VMware guest

    - After ~1 week, problems accessing a single file server by name.  Access by IP continues to work.  Access to other file servers (presumably, ones that were not accessed frequently during the week) continue to work.

    - No problems when the server is restarted, lasting for ~1 week.

     

    Tuesday, April 27, 2010 11:20 PM
  • I have the same problem with Remote desktop services (Terminale server) on a physical machine with network load balancing.

    Tuesday, April 27, 2010 11:54 PM
  • GrandmasterPhil,

    I have the exact problems you are describing. However, my problem happens almost daily. A few times I have had to reboot 2 times in one day. I wonder if there are some steps I can take to help cut down on the problem. If this only happened every week or so, it wouldn't be nearly as unbearable.

    Wednesday, April 28, 2010 2:10 PM
  • Same problem here. Deployed 5 2008 R2 AD-DS/DNS just to act as local file servers. Worked fine for a month or two, and now, all but one unit does the same thing. Random workstations will save to a share, and the share gets hung. I can access the share from RDP, and find the last file that caused the problem...as if it doesn't release the transfer/save process. Anyhow, it requires a hard restart, as it always gets hung during the shutdown. Sucks with all them being remote from my office.

     

    Anyhow, all are physical boxes, very basic, intranet only. Turned off all offloading on NIC'S, RSS, disabled the OS netsh inface goodies (autotuning, chimney etc), set transfers to 100M half, even allowed everyone all permissions for the share. Once it's hung, the other users can't get to it, though different shares are accessible. I'm restarting them all, nearly once a day, and have a very upset group of users... and most of them have the ability to fire me, so MS, get this together! I need this job! lol

     

    Lord I'm glad I found this thread and know I'm not the only one scratching their head over this one.

     

     

     

    Thursday, April 29, 2010 4:57 PM
  • So... no new updates in the past few days?
    Monday, May 3, 2010 8:17 PM
  • Well, I did apply the newest Norton Endpoint 11.0.6 that was just released. I did have 11.0.4something on it but disabled. There was a fix applied to a problem with SMB.

     

    Also applied the latest MS update KB980408 for Server 2008 R2. Didn't really say much about the update...stability and reliability update concerning windows crashes with 3rd party software (but I don't have any).There were a few other fixes that were unrelated to my problems.  Haven't had another crash but it's still early.Have to give it a few days.

     

     

    Monday, May 3, 2010 9:03 PM
  • Well, I did apply the newest Norton Endpoint 11.0.6 that was just released. I did have 11.0.4something on it but disabled. There was a fix applied to a problem with SMB.

     

    Also applied the latest MS update KB980408 for Server 2008 R2. Didn't really say much about the update...stability and reliability update concerning windows crashes with 3rd party software (but I don't have any).There were a few other fixes that were unrelated to my problems.  Haven't had another crash but it's still early.Have to give it a few days.

     

     


    Hi TPW,

    I don't think anyone else has seen a server hang/crash, so that may be a different symptom.  For most of us, the only major issue is the inability to continue to access a single remote share from a Win2008 R2 Terminal Server. 

    I learned that several other individuals also have special debugging code installed by MS to narrow this down, but nobody's issue has come back yet.  Mine hasn't reappeared for a few weeks.

    Phil

     

    Monday, May 3, 2010 9:34 PM
  • Hello all, I just want to report that I am experiencing the same issue. In my case:

    Client Computer: Windows Server 2008R2, Exchange Server 2010, running on ESX4i attempting to connect to a Windows Server 2003 computer. Sometimes, in Explorer, I can connect to \\servername\ but cannot connect via fqdn to the server. I can connect via IP to the server. Other times, I can connect via fqdn to the server, but not by just the hostname. Name resolution is not the issue; the IP resolves with both fqdn and hostname. The error reported is good old 0x80004005.

    I also have colleagues experiencing the issue on multiple Windows Server 2008R2 terminal servers.

    So, I know it's an MS bug, hope they get it fixed soon.

    Tuesday, May 4, 2010 4:03 PM
  • I've been experiencing the same issue with my Windows 2008 R2 Terminal Server losing share connections to Windows 2003 R2 Server.

    The problem has evolved.  When it first started, I had to reboot the server before it would connect to the shares.  After I disabled SNP and IP6 the problem disappeared (about two weeks) until this last weekend when I ran Windows Update on both boxes. 

    The problem returned with a vengeance, but now once all my users log off the TS, the shares become accessible again.

    The problem occurred quite often (multiple times per day) on Monday and Tuesday.  Last night I changed my scripts to FQDN's and this morning I logged on the Terminal Server console with an admin account, opened up a share on the 2003 server, and locked the desktop.  So far, today (Wednesday) has been uneventful.

    Not sure if this is going to work around the problem or not.  I will post once the problem reoccurs.  

     

     

    Wednesday, May 5, 2010 8:33 PM
  • Update :

     

    Server had been ok but I had to reboot it due to a software install. Anyway, after the reboot the server is again showing the problems of not been able to connect to shares on other servers.

    Microsoft still havn't come back to me with any kind of fix or time frame for it and now the boss has got involved say it is outrageous that this should happen and there is no fix!

    I have had to resort to rebooting the server once a day now just to keep everyone happy.

    I am not happy :(

    Rob

     

    Thursday, May 6, 2010 8:23 AM
  • I have the exact same issue as others have reported on a 2008 R2 server. This server just happens to be my SCCM server. I noticed errors in SCCM of not being able to update DP's with packages. After some troubleshooting I tried to just map to the drive of the W2K3 server that is my DP. It gave me an access denied. Other servers that were W2K3 I could map to fine. Just not this one particular box. I could map to it using the FQDN or the IP. I have another 2008 server just like this one, except it is not running SCCM, and I can map to the D$ of the same W2K3 server that I can't get too from my SCCM box.

    This is driving me crazy. All the NIC settings and configurations are the same on both 2008 servers. All was working fine for a few months, as the distribution points have been setup and working correctly up until this week. I think it is related to the SCCM box, but not sure what is up. Also both of these servers on running as VM's.

    Chip

    Thursday, May 6, 2010 2:32 PM
  • The issue just happened to us again.  Here are the details:

    Shortcuts with FQDN's failed.  Shortcuts using netbios or IP address remained working.

    Shortcuts with FQDN's started working before everyone logged out this time.

    I've been dealing with this ____ for over 90 days, MS needs to get on the ball and provide a real solution for this. 

    Thursday, May 6, 2010 3:24 PM
  • VRogers64,

    The issue has to do with repeated attempts using the same access method (FQDN, IP, or Netbios name) and is related to the server not properly expiring an invalid attempt to access the server (e.g. the server attempts to access the share, gets an error of some sort, but rather than retrying..it gets stuck in an error state until you reboot).

    I would open up a ticket with MS if you haven't already; you can reference the SRX number above.  Unfortunately, ever since I applied a test patch which was supposed to provide diagnostic information (not actually fix the issue), the issue hasn't re-appeared, and we're twiddling our thumbs until a customer can get MS the information they need to release a patch.

    Phil

     

    Friday, May 7, 2010 12:47 AM
  • I have the exact same issue as others have reported on a 2008 R2 server. This server just happens to be my SCCM server. I noticed errors in SCCM of not being able to update DP's with packages. After some troubleshooting I tried to just map to the drive of the W2K3 server that is my DP. It gave me an access denied. Other servers that were W2K3 I could map to fine. Just not this one particular box. I could map to it using the FQDN or the IP. I have another 2008 server just like this one, except it is not running SCCM, and I can map to the D$ of the same W2K3 server that I can't get too from my SCCM box.

    This is driving me crazy. All the NIC settings and configurations are the same on both 2008 servers. All was working fine for a few months, as the distribution points have been setup and working correctly up until this week. I think it is related to the SCCM box, but not sure what is up. Also both of these servers on running as VM's.

    Chip


    Same issue as everyone, Chip..it isn't your config.  Hold tight and hopefully we'll get a resolution sooner or later.

     

    Friday, May 7, 2010 12:49 AM
  • I am having a similar issue;

    VMware 4.0; Server 2003 R2, Server 2008 SP2, and Vista all attempting to map from Netgear ReadyNAS 1100; The ReadyNAS is a member of the Domain.

    However, my mapping doesn't work by IP or by FQDN;  All I get are the error 59 and the error 53. 

    Friday, May 7, 2010 2:00 PM
  • I am having a similar issue;

    VMware 4.0; Server 2003 R2, Server 2008 SP2, and Vista all attempting to map from Netgear ReadyNAS 1100; The ReadyNAS is a member of the Domain.

    However, my mapping doesn't work by IP or by FQDN;  All I get are the error 59 and the error 53. 


    If the error doesn't go away on a reboot, it is definitely a different issue and should be placed in a different thread.

    Friday, May 7, 2010 3:39 PM
  • GrandmasterPhil,

    Thanks for the insights.  I replaced all the NIC firmware, drivers, and software on both my DL380G5 and DL380G6 boxes in preparation for getting Microsoft involved.  Right now the server has lost all it's shares to NETBIOS names but the ones mapped with FQDN's and IP's are working.  It did go almost all morning before it losts it's mind.

    I found the SRX number above, but I was wondering if there was a particular tech you've been working with at MS so I can ask for them.  Also, I'm finding different phone numbers and "classes" of support.  What telephone number did you use???

    Thanks again,

    VRogers64

    Monday, May 10, 2010 6:12 PM
  • Hello VRogers64,

    Almost any of the numbers should get you to the same place - try (800) 936-4900.

    Explain your issue to the first level tech, and when you get a call back from the engineer, indicate that your problem is the same as several existing cases being held by the Network Team, and reference my SRX number and send him this thread.  If he checks into it, he should be able to quickly see the similarities and pass you along, but it's up to him to get you escalated.  Hopefully this issue is common enough to where you won't have to spend too much time with the first level tech.

    Good luck,

    Phil

     

    Monday, May 10, 2010 6:25 PM
  • GrandmasterPhil,

    Thanks again, I'll probably call MS first thing tomorrow morning. 

    There is certainly something going on that is weird - Today, when I put the server in bleed down mode in preparation for rebooting with about 40 users connected, it was able to reconnect to the NETBIOS share names before anybody logged out or I rebooted the system.  Coincidence????  Maybe, but it's like if you jolt it the right way at the right time, it must start polling it's connections because it will reconnect the shares without restarting.

    It's a good thing I had this thread to how my boss last Friday, I might have found myself looking for a job!!!

    • Proposed as answer by MBiarsky Tuesday, May 11, 2010 6:12 PM
    Monday, May 10, 2010 7:19 PM
  • Hi,

    I had a similar issue with Windows 2008 SPx. After spending a week with Microsoft, we discovered the following:

    The Network Provider tab was missing. This was caused by changeing the providor order. Editing the registry, revealed the LanmanWorkstation provider was also missing.

    Add LanmanWorkstation to the providor list:

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order]
    "ProviderOrder"="LanmanWorkstation,vmhgfs,RDPNP,hgfs,SnacNp"

    It dynamically updates the following key as well:

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\HwOrder]
    "ProviderOrder"="LanmanWorkstation,vmhgfs,RDPNP,hgfs,SnacNp"

    Reboot!

    Below are comments from my Microsoft ticket (note the comments about hgfs providor):

    [1] LanmanWorkstation is missing from the provider order on the failing machines.  This is what causes all outbound SMB to fail.

     

    [2]  Having the provider called "hgfs" at the end of the provider list was causing the Provider tab to not appear.  Each time we move this to a position other than the end of the list, the Provider tab shows back up immediately without reboot.

     

    For now the workaround is to add the LanmanWorkstation provider at the beginning of the list, and make sure that hgfs is not at the end.

    I hope this helps!

    Regards, Mitchell

     

     

    Tuesday, May 11, 2010 6:33 PM
  • Hi,

    I had a similar issue with Windows 2008 SPx. After spending a week with Microsoft, we discovered the following:

    The Network Provider tab was missing. This was caused by changeing the providor order. Editing the registry, revealed the LanmanWorkstation provider was also missing.

    Add LanmanWorkstation to the providor list:

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order]
    "ProviderOrder"="LanmanWorkstation,vmhgfs,RDPNP,hgfs,SnacNp"

    It dynamically updates the following key as well:

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\HwOrder]
    "ProviderOrder"="LanmanWorkstation,vmhgfs,RDPNP,hgfs,SnacNp"

    Reboot!

    Below are comments from my Microsoft ticket (note the comments about hgfs providor):

    [1] LanmanWorkstation is missing from the provider order on the failing machines.  This is what causes all outbound SMB to fail.

     

    [2]  Having the provider called "hgfs" at the end of the provider list was causing the Provider tab to not appear.  Each time we move this to a position other than the end of the list, the Provider tab shows back up immediately without reboot.

     

    For now the workaround is to add the LanmanWorkstation provider at the beginning of the list, and make sure that hgfs is not at the end.

     

    I hope this helps!

    Regards, Mitchell

     

     

     


    Hi Mitchell,


    Thanks for the suggestion.  In our case, however, SMB works for a period of time, sometimes a day, up to several weeks, before failing.  It is fixed upon reboot.  I just checked my particular machine and did not have the "hgfs" key, or LanmanWorkstation missing.  Microsoft is still looking into the issue on their end.

    Phil

     

    Tuesday, May 11, 2010 6:38 PM
  • Just out of curiosity, has anyone tried manually modifying the host file of the 2008 server? manually putting in the hosts that it loses connection to?
    Wednesday, May 12, 2010 2:44 PM
  • Just out of curiosity, has anyone tried manually modifying the host file of the 2008 server? manually putting in the hosts that it loses connection to?


    Yes, it doesn't make a difference.  You are always able to ping the remote computers using their NetBIOS, FQDN, and IP addresses.

    Wednesday, May 12, 2010 5:03 PM
  • This Morning Microsoft emailed me this :

     

    Hi Robert,

     

    I have a new Private Build that I need you to test and submit the logging if that is possible.  They seem to be narrowing down the problem and we should be able to get a solution sometime soon.  Let me know if you have any question about using the checked build or the logging and I will be glad to help out.  Also let me know if you do not get the attachment.

     

    Regards

    Microsoft

     

    I have applied the patch and will post results here

     

    Rob

     

    Saturday, May 15, 2010 2:06 PM
  • This Morning Microsoft emailed me this :

     

    Hi Robert,

     

    I have a new Private Build that I need you to test and submit the logging if that is possible.  They seem to be narrowing down the problem and we should be able to get a solution sometime soon.  Let me know if you have any question about using the checked build or the logging and I will be glad to help out.  Also let me know if you do not get the attachment.

     

    Regards

    Microsoft

     

    I have applied the patch and will post results here

     

    Rob

     


    I don't think the patch is meant to fix the issue, rather, only provide additional diagnostic information.  Hopefully your issue returns; mine has been absent for several weeks.

     

     

    Saturday, May 15, 2010 6:04 PM
  • Seeing the same issue here. After a short period of time, connecting to a share stops working and doesn't start working again. Using another name to access the share (i.e. IP instead of netbios name or visa versa) will usually work for a short time before failing. Checking the network traffic shows that no attempt is made to connect to the remote server or do a DNS lookup.

    However, we have found that the issue can be resolved consistently by restarting the Workstation service. I would be interested if this works for anyone else.

    Monday, May 17, 2010 1:55 AM
  • Seeing the same issue here. After a short period of time, connecting to a share stops working and doesn't start working again. Using another name to access the share (i.e. IP instead of netbios name or visa versa) will usually work for a short time before failing. Checking the network traffic shows that no attempt is made to connect to the remote server or do a DNS lookup.

    However, we have found that the issue can be resolved consistently by restarting the Workstation service. I would be interested if this works for anyone else.


    My issue finally returned, and I've sent diagnostic information to MS..they hopefully should have what they need to release a fix.


    I'll try the Workstation trick once I verify that MS doesn't need me to do anything else on my box while it is in the error state.

    Monday, May 17, 2010 7:21 PM
  • Seeing the same issue here. After a short period of time, connecting to a share stops working and doesn't start working again. Using another name to access the share (i.e. IP instead of netbios name or visa versa) will usually work for a short time before failing. Checking the network traffic shows that no attempt is made to connect to the remote server or do a DNS lookup.

    However, we have found that the issue can be resolved consistently by restarting the Workstation service. I would be interested if this works for anyone else.


    Seeing the same issue as well.

    I restarted the workstation service and was then able to reconnect to the mapped drive again. Others might be able to use this to temporarily reconnect instead of restarting.

    Still waiting for a fix from MS.

     

    Tuesday, May 18, 2010 3:28 PM
  • Jaaay

    My SCCM server, which is W2K8 R2 just started having this same error again after a couple of weeks since since rebooting because of the same error. The reason I notice it is because of SCCM which is running on this server needed to update a package on one of my distribution points. I found sort of through trial and error if you can't update your DP's, you can't map to the share either. I have about 8 distribution points running on a mixture of W2K3 and W2K8. A couple of weeks ago the problem was on a W2K3 server, this time on a different W2K8 R2 server. Seems sort of hit and mis. To make a long stort short I was getting ready to reboot again to see if that resolved the problem as it did before on my SCCM server. I though I had better check this post and see if anyone had updated. I saw your recent update and tried it. It resolved the issue. Much better than a reboot. Thanks for info.

    Chip

    Tuesday, May 18, 2010 5:12 PM
  • I have also the problem for 4-5 weeks I not have any issue, but tomorow I have the problem, but the event 1006 it's logged

    16 hours ago I have run Windows Update for install:

  • Strumento di rimozione malware di Windows x64 - maggio 2010 (KB890830)
  • Definition Update for Windows Defender - KB915597 (Definition 1.81.1898.0)

    I think than the new sign of Defender it's the cause (I not have any Antivirus on this RDS Sever because use only a .NET custom application, on a share, and not the desktop environment)

    Restart the workstation service resolve the problem


  • Ermanno Goletto - Sysadmin.it
    MCTS - MCSA - MCP - MCBMSP - MCBMSS
Thursday, May 20, 2010 8:44 AM
  • We just created a new virtual environment and are experiencing this same issue with drive mapping though GP's on our citrix servers.  Also a question, if we move our data shares to 2008R2 servers will this resolve the problem?
    Thursday, May 20, 2010 3:39 PM
  • Yes, I move my file share data to a 2008 R2 DFS box, so all the files are now behind a DFS-N Domain Namce space.  Not a single error in over a week.  I used to have multiple user errors every single day.
    Thursday, May 20, 2010 8:16 PM
  • ok, so the problem reoccured and have run the logging program MS sent me.  A nice 111Mb logfile created so just FTP'd it to MS. Lets see what they find ............

     

    Rob

     

     

     

    Friday, May 21, 2010 11:26 AM
  • Any update on this issue? I'm having the same problem with both my R2 Remote Desktop servers.
    Monday, May 24, 2010 5:24 PM
  • i seem to have the same issue...i'm kinda glad that i found this thread now!

     

    here's my situation:

    physical box, windows server 2008 r2 rds can't access windows storage server 2003 sp2 via \\hostname, but via \\hostname.domain and \\ip (but that stops working after a few days/weeks)

    i can ping the storage server and everything that was said before....

     

    PS: did anyone notice the same issue on Windows 7 ? we have 3 windows 7 clients and one of them has the same issue...although it didn't stop working until now.

    Thursday, May 27, 2010 1:16 PM
  • I try to disable Windows defender service and for now I not have the problem..
    Ermanno Goletto - Sysadmin.it
    MCTS - MCSA - MCP - MCBMSP - MCBMSS
    Thursday, May 27, 2010 2:01 PM
  • today it works with \\ip and \\hostname but NOT with \\hostname.domain

     

    WEIRD!

    Friday, May 28, 2010 9:02 AM
  • As mentioned by LBarrin, putting the offending share(s) behind a DFS share appears to have resolved the issue for me.
    Monday, May 31, 2010 1:23 AM
  • Great tip this one!

    Has solved our problems for now.

    Monday, May 31, 2010 1:54 PM
  • I had the same problem with my SMB shares failing.  It didn't matter if they were behind a DFS or not.  It didn't matter if you tried \\share or \\ip.  I had a microsoft engineer on my server for 5 hours and he finally made these adjustments to make it work.

    1.  He changed the provider order to list the MS windows network before the remote desktop network on the advanced tab of the Network Connections.

    2. He uninstalled Rising Anti-virus which he claims had used up all of the server ports and were in Closed Wait status.

    3. He made all of the NIC cards Weak Host Send and Weak Host Receive.

    I can't pin it down to which of these 3 was causing the problem or was it all of them???  Either way, our sharing problem is a thing of the past!!  I hope this helps because I was an unhappy camper for a few weeks.

    JDEmrick

    Tuesday, June 1, 2010 9:42 PM
  • I had the same problem with my SMB shares failing.  It didn't matter if they were behind a DFS or not.  It didn't matter if you tried \\share or \\ip.  I had a microsoft engineer on my server for 5 hours and he finally made these adjustments to make it work.

    1.  He changed the provider order to list the MS windows network before the remote desktop network on the advanced tab of the Network Connections.

    2. He uninstalled Rising Anti-virus which he claims had used up all of the server ports and were in Closed Wait status.

    3. He made all of the NIC cards Weak Host Send and Weak Host Receive.

    I can't pin it down to which of these 3 was causing the problem or was it all of them???  Either way, our sharing problem is a thing of the past!!  I hope this helps because I was an unhappy camper for a few weeks.

    JDEmrick


    Thanks JDEmrick - it sounds like you have a different issue than the original poster, though.   There are dozens of similar issues, but in this particular case, a bug has already been identified by Microsoft.  It sounds like restarting the Workstation service or using a DFS share might work around the issue, but we are still waiting for an actual fix.

    For reference:

    The poster of this thread and many responders have the following common points:

    - A Windows 2008 R2 terminal services environment or something similar

    - After ~1 week, problems accessing a single file server by name.  Access by IP continues to work.  Access to other file servers (presumably, ones that were not accessed frequently during the week) continue to work.

    - No problems when the server is restarted, lasting for a varying period (1 day to several weeks, presumably based on load)


    Phil

     

    Tuesday, June 1, 2010 10:38 PM

  • Thanks JDEmrick - it sounds like you have a different issue than the original poster, though.   There are dozens of similar issues, but in this particular case, a bug has already been identified by Microsoft.  It sounds like restarting the Workstation service or using a DFS share might work around the issue, but we are still waiting for an actual fix.

    For reference:

    The poster of this thread and many responders have the following common points:

    - A Windows 2008 R2 terminal services environment or something similar

    - After ~1 week, problems accessing a single file server by name.  Access by IP continues to work.  Access to other file servers (presumably, ones that were not accessed frequently during the week) continue to work.

    - No problems when the server is restarted, lasting for a varying period (1 day to several weeks, presumably based on load)


    Phil

    Exactly - any news from those who have a ticket for this at MS?
    Wednesday, June 2, 2010 5:56 AM
  • I am having this exact problem at one of my customer sites.  Hyper-V R2, with 2008 R2 terminal servers running as VMs.
    Thursday, June 3, 2010 5:38 PM
  • Add me to the list. No virtual servers, all real. Windows 2008 R2 Terminal servers.
    Monday, June 7, 2010 11:13 AM
  • We're also having the same problem.  Any news from those MSFT tickets?
    Monday, June 7, 2010 1:15 PM
  • Good news - a hotfix is in the works and a workaround has been identified:

    Root cause is that since this is SMB1 all user sessions are on a single TCP connection to the remote server.  The first user to initiate a connection to the remote SMB server has their logon-ID added to the structure defining the connection.  If that user logs off all subsequent uses of that TCP session fail as the logon-id is no longer valid.   As a workaround for now to keep the issue from happening you will want to have the user not logoff the Terminal Server only disconnect their sessions.

    Monday, June 7, 2010 2:11 PM
  • Thanks GrandmasterPhil.

    We have been experiencing the same issue, and have been watching this thread for some time. Please let us know when the hotfix is released.

    Monday, June 7, 2010 3:43 PM
  • Phil, thanks for all the work you have put in on this case. I too am having the same issues you are describing. Please let us know when/if you get a workaround/hotfix.
    Wednesday, June 9, 2010 4:05 PM
  • Phil, thanks for all the work you have put in on this case. I too am having the same issues you are describing. Please let us know when/if you get a workaround/hotfix.


    Thanks Bakinnan.


    The current workaround from MS would be something similar to the following:

    - Reboot the server.

    - Log into the server with an unneeded account (one that doesn't usually log into the server)

    - Access the remote share.

    - Disconnect your terminal server session by clicking the "X" - do not log off.   Make sure you do not have any auto-logoff policies in effect.

    As long as the first user is still logged in, the issue should not return.

    Phil

     

    Wednesday, June 9, 2010 5:02 PM
  • Hey Phil, are you still going to post the hostfix when it comes out?
    Thursday, June 10, 2010 2:08 PM
  • I can confirm that the above workaround does not work!

     

     

    Wednesday, June 16, 2010 9:28 AM
  • Any Idea when the Hotfix is going to be released for this issue, i have two servers that have the issue.

     

    Thursday, June 17, 2010 6:59 AM
  • Same issue occuring an a clents environment. Ihave disabled IP6 and installed QoS on 2003 server.

    Hope MS releases hotfix soon.

     

    Cheers

    Damien

    • Proposed as answer by P.Williams Wednesday, June 23, 2010 6:08 AM
    Sunday, June 20, 2010 6:04 AM
  • Greetings,

    I had a similar issue and found a solution.

    Problem: Can not connect to \\SERVERNAME with net use, net view or map network drives on Windows 2008  with Remote Desktop Services.  Could ping server, dns was good, tried LMHosts, Hosts entries etc.  Could browse server using \\IPADDRESS could browse server with \\servername.fqdn.  After further research the Error 80070035 occurs when attempting to connect to this server.  This specific problem was also isolated to a few user logins and caused problems with folder redirection.

    Diagnosis: I found that if I changed folder redirection policy to point to \\ServerName.FQDN, I now get different error 502 in the event log.  Error Details:"This security ID may not be assigned as the owner of this object."

    Solution: Browse to the folders for the user profile and make sure the user is the owner of the folders.  In this case My Document, Application Data, and Desktop were redirected to a central server. 

    Notes:  The user had rights to his folders and could log into other Windows 2003 terminal servers without a problem.  It appears that the user must be owner of his profile folders with Windows 2008 Remote Desktop Services.

    Wednesday, June 23, 2010 6:22 AM
  • All,

    MS is still developing a hotfix and there are no new updates at this time..I will let you know when I hear something.

    Phil

     

    Wednesday, June 23, 2010 10:51 PM
  • Hi,

    I was told by MS (like Phill wrote) that they are developing a hotfix at the moment and it will not be avaible as a beta hotfix until late July. Then they expect the official release to be sometime in August.

    I was told that the hotfix would not be automaticly installed through WSUS/Windows update but we have to go and download the hotfix manually.


    Thomas Forsmark Soerensen
    Thursday, June 24, 2010 10:16 AM
  • I am currently testing a 'Test Package' Which Microsoft had me install on my server.

     

    So far so good ..........................

     

    Rob

    Tuesday, June 29, 2010 11:06 AM
  • Is there any ETA on release of Test Package?  How can I be a part of the testing?

     

    Negolis

    Wednesday, June 30, 2010 1:23 PM
  • I don't think they need any additional testers at the moment   The "Test Packages" that Robert referred to are usually used to gather diagnostic information and are not true fixes.  As Forsmark mentioned, the current timeline is for a beta hotfix towards the end of July, so we'll need to wait until then.  I'll be sure and post any updates as they arrive.

    Phil

     

    Wednesday, June 30, 2010 10:22 PM
  • I have used the diagnostic gatering patch and sent plenty of logs to MS. I am now on a 'PRIVATE TEST FIX' which is a version of the patch before being deployed.

    I have installed it and so far I have not had the problem re-occur, however, the server has not been up long enough for the problem to occur so I will give it another week before I report back to MS.

     

    Regards

     

    Rob

    Thursday, July 1, 2010 10:01 AM