Thursday, October 25, 2012 9:42 AM
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 !!
Friday, October 26, 2012 9:01 AMModerator
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
Friday, October 26, 2012 12:41 PM
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.
Monday, October 29, 2012 9:48 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
Tuesday, October 30, 2012 7:45 AMModerator
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.
TechNet Community Support
- Marked As Answer by KarloX2 Wednesday, October 31, 2012 12:43 PM
Tuesday, October 30, 2012 5:01 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!
Wednesday, October 31, 2012 8:02 AMHello 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
Wednesday, October 31, 2012 12:42 PM
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 6:41 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.
Thursday, November 08, 2012 11:55 AM
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
Thursday, November 08, 2012 1:59 PMTry 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
Thursday, November 15, 2012 1:22 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:30 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.
- Edited by Cosmin G. Petrenciuc Thursday, November 15, 2012 1:31 PM
Thursday, November 15, 2012 1:48 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 4:36 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. :-)
Monday, November 19, 2012 4:14 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 ?
Tuesday, November 20, 2012 4:45 PM
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
Tuesday, November 20, 2012 5:17 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
Wednesday, November 21, 2012 7:59 AM
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.
Saturday, November 24, 2012 12:44 AM
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.
Wednesday, November 28, 2012 10:05 AMSame problem here! Will Microsoft ever acknowledge the issue and fix it? In KB2592687 section "Known issues" it is not mentioned up to now: http://support.microsoft.com/kb/2592687/en-us
Wednesday, November 28, 2012 10:52 AM
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 12:25 PM
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 9:24 PM
The solution offered by Amjad175 worked for me. You need to share all drives or none...
Sunday, December 02, 2012 3:35 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:37 PM
DO NOT TROLL BUT FIX THIS !!!
that is not true, Amjad175 "solution" is no solution but security risk.
Sunday, December 02, 2012 10:38 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
Monday, December 03, 2012 9:53 PMAmjad175: 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
Tuesday, January 08, 2013 2:55 PM
Is there a way to track the status of this bug?
Saturday, April 27, 2013 12:55 AMIf 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!
Wednesday, May 15, 2013 5:55 PM
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.