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 !!
- Marked as answer by KarloX2 Wednesday, October 31, 2012 12:43 PM
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 Community Support
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.
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
- Marked as answer by KarloX2 Wednesday, October 31, 2012 12:43 PM
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!
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 :).
- Edited by Tymex_Computing Friday, November 02, 2012 9:01 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?
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.
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.
P.S. I also have Windows 7 Professional x64 on my host computer.
- Edited by Cosmin G. Petrenciuc Thursday, November 08, 2012 11:56 AM
Try this fix I suggested to someone else to help with the normalnetwork drive speed. TCP Offloading can cause all sorts of networkslowdowns.http://social.technet.microsoft.com/Forums/en-AU/w7itprovirt/thread/0727541f-415d-4edf-9925-808cfa3f8636Turning off TCP Auto tuning can also make a difference if your routerdoesn't properly support it, but try the above first.
Bob Comer - Microsoft MVP Virtual Machine
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.
- Edited by Cosmin G. Petrenciuc Thursday, November 15, 2012 1:31 PM
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. :-)
you can change that setting with netsh utility.
Here description: http://support.microsoft.com/kb/951037/en-us
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
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.
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.
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
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 ******* ****** !!!!
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
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!
I was able to get it working:
- Go to Settings for the Windows XP Mode VM.
- Integration Settings
- Uncheck Drives.
- Login to the VM and Shut Down the Guest OS.
- Boot it back up and login.
- Recheck Drives in Integration Settings.
- Shut Down the Guest OS again.
- 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
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.
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
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.
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"?)
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.
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:
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:
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.
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?