\\TSClient\C not available any more in Virtual PC after installing RDP8 Protocol Update


  • Hello!

    Yesterday I installed KB2592687 Update (RDP 8.0 Protocol Update) on my Win 7 x64 box. Afterwards the \\TSClient\C Share was not available any more in a Virtual PC Windows 7 x86 Guest OS running on that box. After unstalling that update it works again. Took 1/2 a day !!


    Thursday, October 25, 2012 9:42 AM


  • Hi,

    Thanks for your report.

    OK, I recorded this issue. Also, please temporarily define a Shared Folder if you need C shared after you install this KB.

    Juke Chou

    TechNet Community Support

    • Marked as answer by KarloX2 Wednesday, October 31, 2012 12:43 PM
    Tuesday, October 30, 2012 7:45 AM

All replies

  • Hi,

    Does the \\TSClient\C Share appear in Shares under Shared Folders Management Console when it cannot be accessable? What kind of error do you get?

    I think you need to check the share status first or use IP address instead of Netbios name for a test.

    TechNet Subscriber Support
    If you are TechNet Subscription user and have any feedback on our support quality, please send your feedbackhere.

    Juke Chou

    TechNet Community Support

    Friday, October 26, 2012 9:01 AM
  • I had the same problem as the OP, running Win7 x64 with a Virtual PC configured to run XP.  The settings for the Virtual PC are configured to enable Integration Features so that the C: drive of the x64 environment is available to the virtual machine.  This configuration worked perfectly well without any need to explicitly share the C drive until earlier this week.  Installing KB2592687 breaks this configuration so that the XP virtual machine can no longer access the shared drive.  Uninstalling KB2592687 (which takes over an hour BTW) restored normal service.  Unfortunately, the Windows Automatic Update process keeps trying to re-install KB2592687 after it has been removed...

    The solution seems to be to define a share on the C: drive, restricting access permissions to the applicable users (in this case, myself) and then map a network drive from within the XP virtual machine.

    Friday, October 26, 2012 12:41 PM
  • I also had the same problem and fixed it by uninstalling KB2592687.

    I really think that MS should either issue a fix for this today or make some announcement to help the many people whom this is affecting.  This has taken me half a day to resolve.

    • Proposed as answer by rogajones Thursday, November 15, 2012 1:20 PM
    Monday, October 29, 2012 9:48 PM
  • Hi,

    Thanks for your report.

    OK, I recorded this issue. Also, please temporarily define a Shared Folder if you need C shared after you install this KB.

    Juke Chou

    TechNet Community Support

    • Marked as answer by KarloX2 Wednesday, October 31, 2012 12:43 PM
    Tuesday, October 30, 2012 7:45 AM
  • Thank you for reporting this issue Karlo, We've lost a whole day of production thanks to this ****** update. Tried everything to get my XP back up and running and finally came across this thread.

    I suppose it's too much to think that Microsoft will ever bother testing their patches and or consider the impact they will have on people?!

    ... and Juke, no, why should I add a share to my C drive? This is just adding an unnecessary level of security risk on what has been working perfectly up until now, I dont want unnecessary shares on my drive!

    Tuesday, October 30, 2012 5:01 PM
  • Hello Global - if You think that "adding a share to my C drive is unnecessary level of security risk", then what do you think about a security risk of accessing a \\tsclient\C share from within a VPC guest machine??? Only the default scope of accessing machines is different but both methods should not be used :).

    Wednesday, October 31, 2012 8:02 AM
  • The behavior on my box is exactly what SurlyTroll described, except that my guest OS is Win7 x86. I see TSClient in my network neighborhood but not the C share. I don't like to use a regular network share instead, because of the bad performance. So for the time being I won't use the RDP8 and I skipped the update that caused to trouble.

    Will we get informed once that update has been fixed?



    Wednesday, October 31, 2012 12:42 PM
  • KB2592687 is a real issue when using TSCLIENT mapped drives.  We have over a dozen machines running non-Windows 7 supported applications via Windows Virtual Machine XP Mode on Windows 7 machines.  All are using TSCLIENT maps to network drives to the Windows 7 host, server mapped drives.  This is helpful since we do not have enough server connections licenses to permit direct mapping via the virtual XP Mode machines.

    All was working fine until this update!  None of the local (C: drive) or server (J:, S:, etc.) mapped drives are working now!!!

    TO FIX: I had to uninstall the Windows update KB2592687.

    Please address this ASAP!!!  With updates applying to machines automatically via a policy, this issue is extra trouble.  Mapping to our Windows 2008 server via XP Mode is business critical.

    • Proposed as answer by rogajones Thursday, November 15, 2012 1:19 PM
    • Unproposed as answer by rogajones Thursday, November 15, 2012 1:20 PM
    Wednesday, October 31, 2012 6:41 PM
  • Unfortunately, accessing the host drives through network shares has very poor performance. It takes too long only to list the content of a folder. It's like I'm being routed through half of world for several times.

    What’s more interesting is that accessing network from other computers in the same domain does not have the same performance issues. I don’t understand why accessing a network share created on my host computer takes four-five times more time than accessing a network share on computer from our data-center which is actually located in another building.

    I’m experiencing the same performance issue even when I access a web application deployed on the IIS installed on my host computer.

    It’s nightmarish.

    P.S. I also have Windows 7 Professional x64 on my host computer.

    Cosmin Petrenciuc

    Thursday, November 08, 2012 11:55 AM
  • Try this fix I suggested to someone else to help with the normal
    network drive speed.  TCP Offloading can cause all sorts of network
    Turning off TCP Auto tuning can also make a difference if your router
    doesn't properly support it, but try the above first.

    Bob Comer - Microsoft MVP Virtual Machine
    Thursday, November 08, 2012 1:59 PM
  • I'm also really annoyed by wasted time on this, I think that the best answer is to uninstall KB2592687 as bugfreecoder suggests

    Hopefully someone will post back here when there is an update that works with XP mode.

    Thursday, November 15, 2012 1:22 PM
  • I have tried to find this "TCP Offloading" option using Device Manager but I was unsuccessful. I have an Intel 82578DM Gigabit Network Card and I have no "Advanced" button in the properties window.

    My computer runs Windows 7 Professional x64.

    Thank you.

    Cosmin Petrenciuc

    Thursday, November 15, 2012 1:30 PM

  • I think the "TCP Offloading" is a bit of a red herring for getting back \\TSClient\ functionality and really applies if you are using other methods such as standard network shares.
    Thursday, November 15, 2012 1:48 PM
  • Hello,

    I have the same issue and came across this thread, I have found a temporary solution which works for me.

    Tick the "Drives" button in settings to share all drives, don't know how feasible this is for you from a security point of view but it works for now. :-)


    Thursday, November 15, 2012 4:36 PM
  • I have same problem. Why MS decided to break this functionality ? Will it be fixed ? And why op question is marked as "Answered" when it is not ?

    Monday, November 19, 2012 4:14 PM
  • Dear Cosmin,

    you can change that setting with netsh utility.

    Here description:

    I do not remember how I did that in the past because I use different OS language, but you can see all options with this command: netsh int tcp show global

    If you find something which looks like "TCP Offloading", then you can disable that setting with the corresponding disable command: netsh int tcp set global [setting]=disabled

    Tuesday, November 20, 2012 4:45 PM
  • One more who lost half a day because of this sh**** update!!!

    Thanks for posting your problems

    Would have searched for a solution for some more hours or days...

    • Edited by Pi9506 Tuesday, November 20, 2012 5:18 PM
    Tuesday, November 20, 2012 5:17 PM
  • Thank you for the advice. I have disabled TCP offloading for my host computer (Windows 7 Professional x64). Its state was automatic, now is disabled. Unfortunately when I access my host disks from Windows XP Mode Virtual PC, using \\<host netbios name>\c$ or \\<host netbios name>\d$ the connection is very-very-very slow.<o:p></o:p>

    So nothing has changed after I disabled TCP offloading.

    Cosmin Petrenciuc

    Wednesday, November 21, 2012 7:59 AM
  • Cosmin,

    my advice was not for VirtualPC. From what I know, this change will bring no optimization directly for you. The information was only a hint on how to disable that TCP setting. What I can tell you for sure, is that this setting can make a big difference when you copy very big files. At least only then it was a big advantage for me.

    At this moment there is no better solution than "VPC Share Folders". In my case, I just configured my VM to bridge over the local network adapter, so VM and PC are in the same net, and I have used "webdav" folders (using Xampp for Windows on my host pc) and not "windows file sharing". This may lower security but I am quite satisfied with my connection speed.

    Saturday, November 24, 2012 12:44 AM
  • Same problem here! Will Microsoft ever acknowledge the issue and fix it? In KB2592687 section "Known issues" it is not mentioned up to now:
    Wednesday, November 28, 2012 10:05 AM
  • Hi,

    Out of interest; where did you record the issue?  is there a bug tracking ref or something?

    This is a real problem, and I'm surprised it wasn't picked up in testing.  As others have mentioned, net share access to the local machine is painfully slow from a VM, so a proper fix would be much appreciated :)


    BTW;  win7 pro x64 with XP Mode VM

    • Edited by gjpalmer Wednesday, November 28, 2012 10:53 AM
    Wednesday, November 28, 2012 10:52 AM
  • noticed these people released kb2762895 yesterady. Anybody knows it fixes tclient issue or is it another bug ?

    • Edited by rebelll Wednesday, November 28, 2012 12:25 PM
    Wednesday, November 28, 2012 12:25 PM
  • The solution offered by Amjad175 worked for me. You need to share all drives or none...

    Wednesday, November 28, 2012 9:24 PM
  • that is not true, Amjad175  "solution" is no solution but security risk.

    This is 2nd update in last few months that breaks well working functionality in Widnows 7 for only reason I guess to force people to buy Windows 8.

    Earlier these ******** broke https on home routers and other LAN equipment.

    WHEN WILL IT BE FIXED YOU ******* ****** !!!!

    Sunday, December 02, 2012 3:35 PM

    that is not true, Amjad175  "solution" is no solution but security risk.

    Sunday, December 02, 2012 3:37 PM
  • Do not share the operating system drive, only do so within a closed system setting, IE. no internet, no portable device's.

    All shared devices on their own partition or seperate drives.

    • Edited by larsel Sunday, December 02, 2012 10:39 PM
    Sunday, December 02, 2012 10:38 PM
  • Amjad175: Share all drives did not work for me.  Also, the proposed workaround of sharing the host machine drives as network shares does not work if you are using the VM to host a VPN that takes over your network and prevents local network connections.
    • Edited by MrPhilTX Monday, December 03, 2012 9:55 PM Clarity
    Monday, December 03, 2012 9:53 PM
  • Is there a way to track the status of this bug?


    Tuesday, January 08, 2013 2:55 PM
  • If only for the grace of god I found this web page. For a non-techie... when my VM stops working I spend hours and hours searching for something I (stressing "I") did wrong when the whole time it was MICROSOFT!  I am quite upset by this, as i spent hours of my time and my sons, looking at installs, malware, etc. Felt compelled to share my frustration. Thanks all for sharing this relatively easy solution!
    Saturday, April 27, 2013 12:55 AM
  • I was able to get it working:

    1. Go to Settings for the Windows XP Mode VM.
    2. Integration Settings
    3. Uncheck Drives.
    4. Login to the VM and Shut Down the Guest OS.
    5. Boot it back up and login.
    6. Recheck Drives in Integration Settings.
    7. Shut Down the Guest OS again.
    8. Boot it back up and it should be working.

    Hope this helps.

    • Proposed as answer by James Newton Tuesday, April 07, 2015 12:03 AM
    Wednesday, May 15, 2013 5:55 PM
  • Thanks Holmp_

    I wouldn't have believed, but your 8 steps have just worked form me despite of installed KB2592687 :)

    Tuesday, June 18, 2013 10:58 PM
  • Please help -- I'm just starting with running a Windows XP Virtual machine in Windows 7 Professional 64-bit. I can't figure out how to access files on what's shown as \\tsclient\C from within the virtual machine. I'm trying to run a batch file that has a shortcut on the desktop (thought the shortcut itself is shown as targeting the batch file in a \\tsclientC\ subfolder), and then run a DOS application (which does run in XP, but not in Win 7 with the compatibility box checked). To make matters more confused, when I moved the files and some applications over from an XP machine using PCMover, two large subfolders were created to represent what were Dives D and E on the original XP machine, as C:\Drive_D and C:\DriveE. The DOS application resides  on a subfolder of C:\Drive_D, so the batch file starts with a SUBST D: C:\Drive_D command.

    I'm sure that's not correct, that there's got to be some accommodation for the \\tsclient part, but I have no clue what that should be. There ought to be a tyutorial on using the \\tsclient sharing somewhere, but I've spent a couple hours fruitlessly Googling the Web, and all I fin is things like this -- messages or even tutorials that peripherally refer to the tsclient sharing, but assume that the reader knows how to handle it. It's really very frustrating! -- Dave K.

    Saturday, August 17, 2013 9:16 PM
  • Just a follow-up, due to another Windows update that causes this same problem. You will want to uninstall


    and also have Windows Update ignore this one in the future so that it won't try to install it again. This is a new update to the RDP8 Protocol which was released on 14-Nov-2013. It installed on my system on the 15th and tonight when I attempted to use XP Mode, all my tsclient drives were missing. Restarting the Virtual Machine caused XP Mode to crash, so I figured there must have been a new update similar to the previous one that caused this same issue. Sure enough, a quick web search found the above mentioned update. I uninstalled it (thankfully it took only about a minute, plus a reboot) and all is working as it was before. Hopefully this will help anyone else who has started seeing this issue.

    • Proposed as answer by rogajones Monday, November 18, 2013 2:18 PM
    Monday, November 18, 2013 1:45 AM
  • I have uninstalled KB2830477. No more error while enable integration feauture. But no tsclient drive is available. Anyone can help, please

    Monday, November 18, 2013 3:03 AM
  • Just a follow-up, due to another Windows update that causes this same problem. You will want to uninstall


    Thanks very much for alerting me about this, most helpful
    Monday, November 18, 2013 2:19 PM
  • I have uninstalled KB2830477. No more error while enable integration feauture. But no tsclient drive is available. Anyone can help, please

    Were they already mapped previously?

    Have they been selected for use in the integration settings (try the unselect/reboot/select all/reboot method suggested above)?

    Has KB2592687 also been uninstalled?

    If all answers above are yes, then I don't know what else to suggest.

    Tuesday, November 19, 2013 10:43 PM
  • OK, I also had a very similar issue here (running XP Mode under Windows 7 x86) and when I saw the information about uninstalling KB2592687 I decided to un-install KB2592687 to restore my tsclient functionality. Originally I was going to try the "8 step process" suggested by Holmp_, but just for the heck of it, I decided to try re-installing KB2592687 & see what happened... I was surprised to find that my tsclient shares still work after re-installing KB2592687... Could the issue be something to do with KB2592687 screwing something up when installed while the VPC is running? (If so, shouldn't Microsoft correct the update to check that before installing, or at least report it under "known issues"?)
    • Edited by Matt Kingsmill Wednesday, February 12, 2014 8:24 PM more details, corrected grammar
    • Proposed as answer by Matt Kingsmill Sunday, February 23, 2014 8:04 PM
    Wednesday, February 12, 2014 8:15 PM
  • Worked for me, but only after verifying the machine was shutdown between iterations of settings.

    So I'd add when in the Virtual PC Settings, verify that either



    (*) Prompt for Action are set as VM Close options.  

    So after making the above changes, one can be certain when closing the machine it isn't simply in hibernate.

    Friday, August 01, 2014 9:13 AM
  • Hello,

    I am working with Virtual PC and the XP Mode to get some old 16-bit Software running on 64-bit Win 7 machines. I use the seamless mode, so that the user don't have to think about any virtual machines. But for that I need access to the second partition (d:\) and some network drives in the virtual machine. All went well until the update KB2592687 and I decided to not distribute it. After a while problems started again, maybe the KB2830477 (don't really know it) and until now I had no solution.

    A few days ago I set up a new Windows 7 64-bit installation with all actual updates including KB2592687 and KB2830477. It bothered me that I couldn't access my drives, so I tried the solution of Holmp_. And it worked, I could see all drives in XP Mode. But if I tried only two drives and not all drives it stopped working.

    If you select all drives the line in the vmc file in the ui-options section is:

    <share_drives type="string">*</share_drives>

    If you select two drives it looks for example like this (german version) and it doesn't work:

    <share_drives type="string">Lokaler Datenträger (D:);Toshiba HDD (F:);</share_drives>

    So I compared it to a rpd file (Remote Desktop Configuration File) for all drives:


    and one if I select only two drives:


    So I changed the line in the vmc file to:

    <share_drives type="string">D:\;F:\;</share_drives>

    and now it works fine.

    So I think Microsoft changed the configuration values for RDP 8 and virtual pc configurator still uses the old format. Maybe there will be an update for virtual pc in the future, which fix this bug?

    I hope this solution will work also for others who have this problem.

    • Proposed as answer by matlabber Sunday, December 28, 2014 7:57 PM
    • Edited by matlabber Sunday, December 28, 2014 9:32 PM
    Sunday, December 28, 2014 7:56 PM
  • Thank you!  This finally fixed it for me.  What a relief.  This has been such a headache.  Appreciate you taking the time to share this.
    Monday, January 12, 2015 9:36 PM
  • Wow. Another bug / answer that isn't an answer / Answer not marked as answer. 

    KarloX2, please help out the next guy by UNmarking the Juke Chou answer as an answer (since it is NOT an answer) and instead mark the Holmp_ answer as an answer (since it's a viable workaround) and the matlabber answer as a second answer (since it appears to document the cause of the problem)? 

    Holmp_, thank you for that! Saved me yesterday.

    matlabber, Wow... nice debugging!

    Microsoft: Please fix your system using matlabbers input so the config files are created correctly and stop breaking things please?

    Tuesday, April 07, 2015 5:43 PM