Why did remote desktop performance drop when switching from Windows Server 2012R2 to Windows 7?
I have a desktop computer that I remote into on a regular basis. Prior to last week, the host OS was Windows Server 2012R2. Last week, I installed Windows 7, and I immediately noticed that the computer was more sluggish over remote desktop, especially when watching YouTube videos, which skip every half second or so for the entire video. Last night, I added an SSD and doubled the RAM in the computer (things I have been wanting to do anyway) and the performance still sucks.
The current stats of the RDP host:
- Windows 7 Ultimate
- 240GB Crucial M500 SSD
- 32GB DDR2 RAM
- NVIDIA GeForce GTX 560 Ti
- Intel Xeon X5365
The client computer was the same the entire time, but here are its stats:
- Windows 7 Ultimate
- 500GB 10K HDD
- 64GB DDR3 RAM
- NVIDIA Quadro K4000
- Intel Xeon E5-2687W
The internet connection on both sides exceeds 10Mbps upload and download. (I realize latency is the main concern, but I don't know how to measure this, and regardless it was the same with Windows Server as it is with Windows 7.)
I have tried changing the RDP performance settings on the client side from "Detect" to "Modem (56kbps)" but the "YouTube Test" still fails with an unusable, low frame rate video.
As per the suggestion from another Superuser question, I have tried both netsh interface tcp set global autotuninglevel=highlyrestricted
and netsh interface tcp set global autotuninglevel=disabled
, restarting the computer each time and re-testing. I did not see any difference in the performance.
My question: Why did the performance drop? My current theory is that the cause is the change in operating system. Is there anything else I can try to get the performance back to what it was?
windows-7 remote-desktop windows-server-2012-r2
add a comment |
I have a desktop computer that I remote into on a regular basis. Prior to last week, the host OS was Windows Server 2012R2. Last week, I installed Windows 7, and I immediately noticed that the computer was more sluggish over remote desktop, especially when watching YouTube videos, which skip every half second or so for the entire video. Last night, I added an SSD and doubled the RAM in the computer (things I have been wanting to do anyway) and the performance still sucks.
The current stats of the RDP host:
- Windows 7 Ultimate
- 240GB Crucial M500 SSD
- 32GB DDR2 RAM
- NVIDIA GeForce GTX 560 Ti
- Intel Xeon X5365
The client computer was the same the entire time, but here are its stats:
- Windows 7 Ultimate
- 500GB 10K HDD
- 64GB DDR3 RAM
- NVIDIA Quadro K4000
- Intel Xeon E5-2687W
The internet connection on both sides exceeds 10Mbps upload and download. (I realize latency is the main concern, but I don't know how to measure this, and regardless it was the same with Windows Server as it is with Windows 7.)
I have tried changing the RDP performance settings on the client side from "Detect" to "Modem (56kbps)" but the "YouTube Test" still fails with an unusable, low frame rate video.
As per the suggestion from another Superuser question, I have tried both netsh interface tcp set global autotuninglevel=highlyrestricted
and netsh interface tcp set global autotuninglevel=disabled
, restarting the computer each time and re-testing. I did not see any difference in the performance.
My question: Why did the performance drop? My current theory is that the cause is the change in operating system. Is there anything else I can try to get the performance back to what it was?
windows-7 remote-desktop windows-server-2012-r2
add a comment |
I have a desktop computer that I remote into on a regular basis. Prior to last week, the host OS was Windows Server 2012R2. Last week, I installed Windows 7, and I immediately noticed that the computer was more sluggish over remote desktop, especially when watching YouTube videos, which skip every half second or so for the entire video. Last night, I added an SSD and doubled the RAM in the computer (things I have been wanting to do anyway) and the performance still sucks.
The current stats of the RDP host:
- Windows 7 Ultimate
- 240GB Crucial M500 SSD
- 32GB DDR2 RAM
- NVIDIA GeForce GTX 560 Ti
- Intel Xeon X5365
The client computer was the same the entire time, but here are its stats:
- Windows 7 Ultimate
- 500GB 10K HDD
- 64GB DDR3 RAM
- NVIDIA Quadro K4000
- Intel Xeon E5-2687W
The internet connection on both sides exceeds 10Mbps upload and download. (I realize latency is the main concern, but I don't know how to measure this, and regardless it was the same with Windows Server as it is with Windows 7.)
I have tried changing the RDP performance settings on the client side from "Detect" to "Modem (56kbps)" but the "YouTube Test" still fails with an unusable, low frame rate video.
As per the suggestion from another Superuser question, I have tried both netsh interface tcp set global autotuninglevel=highlyrestricted
and netsh interface tcp set global autotuninglevel=disabled
, restarting the computer each time and re-testing. I did not see any difference in the performance.
My question: Why did the performance drop? My current theory is that the cause is the change in operating system. Is there anything else I can try to get the performance back to what it was?
windows-7 remote-desktop windows-server-2012-r2
I have a desktop computer that I remote into on a regular basis. Prior to last week, the host OS was Windows Server 2012R2. Last week, I installed Windows 7, and I immediately noticed that the computer was more sluggish over remote desktop, especially when watching YouTube videos, which skip every half second or so for the entire video. Last night, I added an SSD and doubled the RAM in the computer (things I have been wanting to do anyway) and the performance still sucks.
The current stats of the RDP host:
- Windows 7 Ultimate
- 240GB Crucial M500 SSD
- 32GB DDR2 RAM
- NVIDIA GeForce GTX 560 Ti
- Intel Xeon X5365
The client computer was the same the entire time, but here are its stats:
- Windows 7 Ultimate
- 500GB 10K HDD
- 64GB DDR3 RAM
- NVIDIA Quadro K4000
- Intel Xeon E5-2687W
The internet connection on both sides exceeds 10Mbps upload and download. (I realize latency is the main concern, but I don't know how to measure this, and regardless it was the same with Windows Server as it is with Windows 7.)
I have tried changing the RDP performance settings on the client side from "Detect" to "Modem (56kbps)" but the "YouTube Test" still fails with an unusable, low frame rate video.
As per the suggestion from another Superuser question, I have tried both netsh interface tcp set global autotuninglevel=highlyrestricted
and netsh interface tcp set global autotuninglevel=disabled
, restarting the computer each time and re-testing. I did not see any difference in the performance.
My question: Why did the performance drop? My current theory is that the cause is the change in operating system. Is there anything else I can try to get the performance back to what it was?
windows-7 remote-desktop windows-server-2012-r2
windows-7 remote-desktop windows-server-2012-r2
asked Apr 22 '14 at 21:42
Logical FallacyLogical Fallacy
208410
208410
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Windows Server is an OS designed to be doing this. Windows 7 is a client based OS that has this feature for convenience.
In other words, a windows server doesn't use the same remote desktop server as windows 7 uses. In a server environment, you can have many concurrent connections, and there are many tweaks to enhance the performance, such as disabling Aero, where as in windows 7, it is much more oriented in brining the "known" desktop to the user instead. There are tweaks for Windows server to enable Aero on the remote desktop, and one of the things it does is decrease performance. I bet it is this what has the most impact.
That the server environment is more performant for RDP is an interesting suggestion, but I have never heard of this. Can you find a source for RDP performance being impacted? As I said, I have tried the RDP session with all visual styles disabled ("Modem (56kbps)" setting) but this did not improve things.
– Logical Fallacy
Apr 23 '14 at 22:10
add a comment |
The problem is the RDP (protocol) version.
Windows Server 2012R2 is the latest and greatest from the the RDP team and uses RDP v8.1 (server side). There are many fixes exactly in this area - video playback regarding encoding and decoding in H.264 format (which is faster and not laggy). See here: http://blogs.msdn.com/b/rds/archive/2013/10/31/remotefx-h-264-codec-improvements-in-windows-8-1-and-windows-server-2012-r2.aspx
Windows 7 (equivalent to Windows Server 2008) ships with RDP stack (server side) v7, there is a package to update to RDP v8 (I know it applies to Windows Server, not sure if it applies to clients as well), but there is no update to RDP v8.1.
From your description, your client is most likely Windows 8.1 and therefore can take advantage of the new features in the protocol with WS2012R2. With Windows 7, it automatically falls back to the RDP version on the host you are connecting to (v7 or v8).
Actually both the client (which is Windows 7, not Windows 8.1) use RDP v8.1 since this has been released to Windows 7 through Windows Update. See blogs.msdn.com/b/rds/archive/2013/11/12/…
– Logical Fallacy
Apr 23 '14 at 22:02
Yes, but there is a difference between the client stack and the server stack. The client stack might run 8.1 (as you say), but Windows 7 (the host you are connecting to, behaving as server) most likely does not have the 8.1 RDP server stack (because it does not exist).
– cdavid
Apr 23 '14 at 23:37
I checked the About dialog for RDP on both computers. Both specify v8.1. Did you read the MSDN article I linked to? v8.1 clearly is available for Windows 7.
– Logical Fallacy
Apr 23 '14 at 23:59
Yes, RDP v8.1 is available for the client. But the element that has changed in your setup is the server side (the remote host to which you are connecting). This is not the version of MSTSC (that is the client) - it is the version of the termsrv service. And while WS2012R2 has termsrv v8.1, Windows 7 does not.
– cdavid
Apr 24 '14 at 4:01
What you're saying sounds plausible, but please find a source or some way to confirm this. The article you linked to and the article I linked to both seem to suggest otherwise. I do understand your claim that the service version is different than the MSTSC version, but I'd like some way to confirm this. Thanks for your patience.
– Logical Fallacy
Apr 24 '14 at 16:54
|
show 1 more comment
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f744808%2fwhy-did-remote-desktop-performance-drop-when-switching-from-windows-server-2012r%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Windows Server is an OS designed to be doing this. Windows 7 is a client based OS that has this feature for convenience.
In other words, a windows server doesn't use the same remote desktop server as windows 7 uses. In a server environment, you can have many concurrent connections, and there are many tweaks to enhance the performance, such as disabling Aero, where as in windows 7, it is much more oriented in brining the "known" desktop to the user instead. There are tweaks for Windows server to enable Aero on the remote desktop, and one of the things it does is decrease performance. I bet it is this what has the most impact.
That the server environment is more performant for RDP is an interesting suggestion, but I have never heard of this. Can you find a source for RDP performance being impacted? As I said, I have tried the RDP session with all visual styles disabled ("Modem (56kbps)" setting) but this did not improve things.
– Logical Fallacy
Apr 23 '14 at 22:10
add a comment |
Windows Server is an OS designed to be doing this. Windows 7 is a client based OS that has this feature for convenience.
In other words, a windows server doesn't use the same remote desktop server as windows 7 uses. In a server environment, you can have many concurrent connections, and there are many tweaks to enhance the performance, such as disabling Aero, where as in windows 7, it is much more oriented in brining the "known" desktop to the user instead. There are tweaks for Windows server to enable Aero on the remote desktop, and one of the things it does is decrease performance. I bet it is this what has the most impact.
That the server environment is more performant for RDP is an interesting suggestion, but I have never heard of this. Can you find a source for RDP performance being impacted? As I said, I have tried the RDP session with all visual styles disabled ("Modem (56kbps)" setting) but this did not improve things.
– Logical Fallacy
Apr 23 '14 at 22:10
add a comment |
Windows Server is an OS designed to be doing this. Windows 7 is a client based OS that has this feature for convenience.
In other words, a windows server doesn't use the same remote desktop server as windows 7 uses. In a server environment, you can have many concurrent connections, and there are many tweaks to enhance the performance, such as disabling Aero, where as in windows 7, it is much more oriented in brining the "known" desktop to the user instead. There are tweaks for Windows server to enable Aero on the remote desktop, and one of the things it does is decrease performance. I bet it is this what has the most impact.
Windows Server is an OS designed to be doing this. Windows 7 is a client based OS that has this feature for convenience.
In other words, a windows server doesn't use the same remote desktop server as windows 7 uses. In a server environment, you can have many concurrent connections, and there are many tweaks to enhance the performance, such as disabling Aero, where as in windows 7, it is much more oriented in brining the "known" desktop to the user instead. There are tweaks for Windows server to enable Aero on the remote desktop, and one of the things it does is decrease performance. I bet it is this what has the most impact.
answered Apr 22 '14 at 22:36
LPChipLPChip
35.8k55185
35.8k55185
That the server environment is more performant for RDP is an interesting suggestion, but I have never heard of this. Can you find a source for RDP performance being impacted? As I said, I have tried the RDP session with all visual styles disabled ("Modem (56kbps)" setting) but this did not improve things.
– Logical Fallacy
Apr 23 '14 at 22:10
add a comment |
That the server environment is more performant for RDP is an interesting suggestion, but I have never heard of this. Can you find a source for RDP performance being impacted? As I said, I have tried the RDP session with all visual styles disabled ("Modem (56kbps)" setting) but this did not improve things.
– Logical Fallacy
Apr 23 '14 at 22:10
That the server environment is more performant for RDP is an interesting suggestion, but I have never heard of this. Can you find a source for RDP performance being impacted? As I said, I have tried the RDP session with all visual styles disabled ("Modem (56kbps)" setting) but this did not improve things.
– Logical Fallacy
Apr 23 '14 at 22:10
That the server environment is more performant for RDP is an interesting suggestion, but I have never heard of this. Can you find a source for RDP performance being impacted? As I said, I have tried the RDP session with all visual styles disabled ("Modem (56kbps)" setting) but this did not improve things.
– Logical Fallacy
Apr 23 '14 at 22:10
add a comment |
The problem is the RDP (protocol) version.
Windows Server 2012R2 is the latest and greatest from the the RDP team and uses RDP v8.1 (server side). There are many fixes exactly in this area - video playback regarding encoding and decoding in H.264 format (which is faster and not laggy). See here: http://blogs.msdn.com/b/rds/archive/2013/10/31/remotefx-h-264-codec-improvements-in-windows-8-1-and-windows-server-2012-r2.aspx
Windows 7 (equivalent to Windows Server 2008) ships with RDP stack (server side) v7, there is a package to update to RDP v8 (I know it applies to Windows Server, not sure if it applies to clients as well), but there is no update to RDP v8.1.
From your description, your client is most likely Windows 8.1 and therefore can take advantage of the new features in the protocol with WS2012R2. With Windows 7, it automatically falls back to the RDP version on the host you are connecting to (v7 or v8).
Actually both the client (which is Windows 7, not Windows 8.1) use RDP v8.1 since this has been released to Windows 7 through Windows Update. See blogs.msdn.com/b/rds/archive/2013/11/12/…
– Logical Fallacy
Apr 23 '14 at 22:02
Yes, but there is a difference between the client stack and the server stack. The client stack might run 8.1 (as you say), but Windows 7 (the host you are connecting to, behaving as server) most likely does not have the 8.1 RDP server stack (because it does not exist).
– cdavid
Apr 23 '14 at 23:37
I checked the About dialog for RDP on both computers. Both specify v8.1. Did you read the MSDN article I linked to? v8.1 clearly is available for Windows 7.
– Logical Fallacy
Apr 23 '14 at 23:59
Yes, RDP v8.1 is available for the client. But the element that has changed in your setup is the server side (the remote host to which you are connecting). This is not the version of MSTSC (that is the client) - it is the version of the termsrv service. And while WS2012R2 has termsrv v8.1, Windows 7 does not.
– cdavid
Apr 24 '14 at 4:01
What you're saying sounds plausible, but please find a source or some way to confirm this. The article you linked to and the article I linked to both seem to suggest otherwise. I do understand your claim that the service version is different than the MSTSC version, but I'd like some way to confirm this. Thanks for your patience.
– Logical Fallacy
Apr 24 '14 at 16:54
|
show 1 more comment
The problem is the RDP (protocol) version.
Windows Server 2012R2 is the latest and greatest from the the RDP team and uses RDP v8.1 (server side). There are many fixes exactly in this area - video playback regarding encoding and decoding in H.264 format (which is faster and not laggy). See here: http://blogs.msdn.com/b/rds/archive/2013/10/31/remotefx-h-264-codec-improvements-in-windows-8-1-and-windows-server-2012-r2.aspx
Windows 7 (equivalent to Windows Server 2008) ships with RDP stack (server side) v7, there is a package to update to RDP v8 (I know it applies to Windows Server, not sure if it applies to clients as well), but there is no update to RDP v8.1.
From your description, your client is most likely Windows 8.1 and therefore can take advantage of the new features in the protocol with WS2012R2. With Windows 7, it automatically falls back to the RDP version on the host you are connecting to (v7 or v8).
Actually both the client (which is Windows 7, not Windows 8.1) use RDP v8.1 since this has been released to Windows 7 through Windows Update. See blogs.msdn.com/b/rds/archive/2013/11/12/…
– Logical Fallacy
Apr 23 '14 at 22:02
Yes, but there is a difference between the client stack and the server stack. The client stack might run 8.1 (as you say), but Windows 7 (the host you are connecting to, behaving as server) most likely does not have the 8.1 RDP server stack (because it does not exist).
– cdavid
Apr 23 '14 at 23:37
I checked the About dialog for RDP on both computers. Both specify v8.1. Did you read the MSDN article I linked to? v8.1 clearly is available for Windows 7.
– Logical Fallacy
Apr 23 '14 at 23:59
Yes, RDP v8.1 is available for the client. But the element that has changed in your setup is the server side (the remote host to which you are connecting). This is not the version of MSTSC (that is the client) - it is the version of the termsrv service. And while WS2012R2 has termsrv v8.1, Windows 7 does not.
– cdavid
Apr 24 '14 at 4:01
What you're saying sounds plausible, but please find a source or some way to confirm this. The article you linked to and the article I linked to both seem to suggest otherwise. I do understand your claim that the service version is different than the MSTSC version, but I'd like some way to confirm this. Thanks for your patience.
– Logical Fallacy
Apr 24 '14 at 16:54
|
show 1 more comment
The problem is the RDP (protocol) version.
Windows Server 2012R2 is the latest and greatest from the the RDP team and uses RDP v8.1 (server side). There are many fixes exactly in this area - video playback regarding encoding and decoding in H.264 format (which is faster and not laggy). See here: http://blogs.msdn.com/b/rds/archive/2013/10/31/remotefx-h-264-codec-improvements-in-windows-8-1-and-windows-server-2012-r2.aspx
Windows 7 (equivalent to Windows Server 2008) ships with RDP stack (server side) v7, there is a package to update to RDP v8 (I know it applies to Windows Server, not sure if it applies to clients as well), but there is no update to RDP v8.1.
From your description, your client is most likely Windows 8.1 and therefore can take advantage of the new features in the protocol with WS2012R2. With Windows 7, it automatically falls back to the RDP version on the host you are connecting to (v7 or v8).
The problem is the RDP (protocol) version.
Windows Server 2012R2 is the latest and greatest from the the RDP team and uses RDP v8.1 (server side). There are many fixes exactly in this area - video playback regarding encoding and decoding in H.264 format (which is faster and not laggy). See here: http://blogs.msdn.com/b/rds/archive/2013/10/31/remotefx-h-264-codec-improvements-in-windows-8-1-and-windows-server-2012-r2.aspx
Windows 7 (equivalent to Windows Server 2008) ships with RDP stack (server side) v7, there is a package to update to RDP v8 (I know it applies to Windows Server, not sure if it applies to clients as well), but there is no update to RDP v8.1.
From your description, your client is most likely Windows 8.1 and therefore can take advantage of the new features in the protocol with WS2012R2. With Windows 7, it automatically falls back to the RDP version on the host you are connecting to (v7 or v8).
answered Apr 23 '14 at 17:17
cdavidcdavid
78548
78548
Actually both the client (which is Windows 7, not Windows 8.1) use RDP v8.1 since this has been released to Windows 7 through Windows Update. See blogs.msdn.com/b/rds/archive/2013/11/12/…
– Logical Fallacy
Apr 23 '14 at 22:02
Yes, but there is a difference between the client stack and the server stack. The client stack might run 8.1 (as you say), but Windows 7 (the host you are connecting to, behaving as server) most likely does not have the 8.1 RDP server stack (because it does not exist).
– cdavid
Apr 23 '14 at 23:37
I checked the About dialog for RDP on both computers. Both specify v8.1. Did you read the MSDN article I linked to? v8.1 clearly is available for Windows 7.
– Logical Fallacy
Apr 23 '14 at 23:59
Yes, RDP v8.1 is available for the client. But the element that has changed in your setup is the server side (the remote host to which you are connecting). This is not the version of MSTSC (that is the client) - it is the version of the termsrv service. And while WS2012R2 has termsrv v8.1, Windows 7 does not.
– cdavid
Apr 24 '14 at 4:01
What you're saying sounds plausible, but please find a source or some way to confirm this. The article you linked to and the article I linked to both seem to suggest otherwise. I do understand your claim that the service version is different than the MSTSC version, but I'd like some way to confirm this. Thanks for your patience.
– Logical Fallacy
Apr 24 '14 at 16:54
|
show 1 more comment
Actually both the client (which is Windows 7, not Windows 8.1) use RDP v8.1 since this has been released to Windows 7 through Windows Update. See blogs.msdn.com/b/rds/archive/2013/11/12/…
– Logical Fallacy
Apr 23 '14 at 22:02
Yes, but there is a difference between the client stack and the server stack. The client stack might run 8.1 (as you say), but Windows 7 (the host you are connecting to, behaving as server) most likely does not have the 8.1 RDP server stack (because it does not exist).
– cdavid
Apr 23 '14 at 23:37
I checked the About dialog for RDP on both computers. Both specify v8.1. Did you read the MSDN article I linked to? v8.1 clearly is available for Windows 7.
– Logical Fallacy
Apr 23 '14 at 23:59
Yes, RDP v8.1 is available for the client. But the element that has changed in your setup is the server side (the remote host to which you are connecting). This is not the version of MSTSC (that is the client) - it is the version of the termsrv service. And while WS2012R2 has termsrv v8.1, Windows 7 does not.
– cdavid
Apr 24 '14 at 4:01
What you're saying sounds plausible, but please find a source or some way to confirm this. The article you linked to and the article I linked to both seem to suggest otherwise. I do understand your claim that the service version is different than the MSTSC version, but I'd like some way to confirm this. Thanks for your patience.
– Logical Fallacy
Apr 24 '14 at 16:54
Actually both the client (which is Windows 7, not Windows 8.1) use RDP v8.1 since this has been released to Windows 7 through Windows Update. See blogs.msdn.com/b/rds/archive/2013/11/12/…
– Logical Fallacy
Apr 23 '14 at 22:02
Actually both the client (which is Windows 7, not Windows 8.1) use RDP v8.1 since this has been released to Windows 7 through Windows Update. See blogs.msdn.com/b/rds/archive/2013/11/12/…
– Logical Fallacy
Apr 23 '14 at 22:02
Yes, but there is a difference between the client stack and the server stack. The client stack might run 8.1 (as you say), but Windows 7 (the host you are connecting to, behaving as server) most likely does not have the 8.1 RDP server stack (because it does not exist).
– cdavid
Apr 23 '14 at 23:37
Yes, but there is a difference between the client stack and the server stack. The client stack might run 8.1 (as you say), but Windows 7 (the host you are connecting to, behaving as server) most likely does not have the 8.1 RDP server stack (because it does not exist).
– cdavid
Apr 23 '14 at 23:37
I checked the About dialog for RDP on both computers. Both specify v8.1. Did you read the MSDN article I linked to? v8.1 clearly is available for Windows 7.
– Logical Fallacy
Apr 23 '14 at 23:59
I checked the About dialog for RDP on both computers. Both specify v8.1. Did you read the MSDN article I linked to? v8.1 clearly is available for Windows 7.
– Logical Fallacy
Apr 23 '14 at 23:59
Yes, RDP v8.1 is available for the client. But the element that has changed in your setup is the server side (the remote host to which you are connecting). This is not the version of MSTSC (that is the client) - it is the version of the termsrv service. And while WS2012R2 has termsrv v8.1, Windows 7 does not.
– cdavid
Apr 24 '14 at 4:01
Yes, RDP v8.1 is available for the client. But the element that has changed in your setup is the server side (the remote host to which you are connecting). This is not the version of MSTSC (that is the client) - it is the version of the termsrv service. And while WS2012R2 has termsrv v8.1, Windows 7 does not.
– cdavid
Apr 24 '14 at 4:01
What you're saying sounds plausible, but please find a source or some way to confirm this. The article you linked to and the article I linked to both seem to suggest otherwise. I do understand your claim that the service version is different than the MSTSC version, but I'd like some way to confirm this. Thanks for your patience.
– Logical Fallacy
Apr 24 '14 at 16:54
What you're saying sounds plausible, but please find a source or some way to confirm this. The article you linked to and the article I linked to both seem to suggest otherwise. I do understand your claim that the service version is different than the MSTSC version, but I'd like some way to confirm this. Thanks for your patience.
– Logical Fallacy
Apr 24 '14 at 16:54
|
show 1 more comment
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f744808%2fwhy-did-remote-desktop-performance-drop-when-switching-from-windows-server-2012r%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown