You may have discovered the 'Compatibility View Settings' workaround for making your SBS 2008 Remote Web Workplace 'connect to a computer' section stops 'working around' after a Windows 10 client upgrade. That can be fixed so it 'works around' again!
If, when you open up your Remote Web Workplace (RWW) site and it doesn't look like the image below (you are missing the 'connect to a computer' section entirely,) then
- You are using MS Edge and not IE 11, or
- You don't have the site in the Compatibility View Settings List.
Ensure that you are using IE 11.
MS has done a good job of hiding IE 11 in Windows 10 - but if you use the new handy-dandy search box, you can find it by typing in 'Internet Explorer.'
At that point you can right-click it and pin it to the Start Menu and/or taskbar if that floats your boat.
Once you've opened your RWW site in IE 11, check to see if the 'connect to a computer' section is now visible.
Ensure that the site is listed in the Compatibility View Settings
If the desired section still isn't listed, then you don't have the site in your compatibility view sites!
Add it by opening the Settings 'gear', choosing Compatibility View Settings and adding your site.
The dialog pictured below automagically adds the whole top level, so don't get fussed over trying to add http://servername.yourdomain.com
is all that's going to be saved.
Once you have it in Compatibility mode, the RWW site will work quite nicely in Windows 7, 8 and 8.1 to get your site displaying AND working correctly.
In Windows 10 however, the RDP session will throw script errors.
In Windows 10, the site will display correctly but not work.
The required ActiveX control needed for you to 'connect to a computer' will not load and throw a VBScript error.
MS and their half-baked releases (or subtle prods to spend thousands on upgrades) can drive you mad.
The new MS Edge browser doesn't support ActiveX controls and therefore is no good for the purpose of opening the RWW site and using Remote Desktop.
MS has a shiny new Remote Desktop client app, very reminiscent of the Android RD Client they've released (same name, same icon, same color scheme, same functionality)
Fine. But your users have muscle-memory and the RD Client still is not the same look and feel as a Remote Desktop.
So, you want to make your site work for all your users.
But what changed between Windows 8.1 and Windows 10 to break the site that worked previously?
What MS did is re-version the ActiveX control used in Windows 10.
The RWW site now thinks you aren't running the correct version.
The version number has been bumped to 10.
That makes some sense -- but the RWW site checks version by using this code:
strcomp(version,"6.0.6000") < 0
That's real nice -- right up until 10.x.x is less that 6.0.6000
because it's doing a frigging string comparison!
After all 1 < 6, so in a string comparison "10.0.0" < "6.0.6000" is bang on correct.
I wonder how many other things will subtly break because we skipped Windows 9?
If YOU control your SBS 2008 server (and why wouldn't you?) you can fix the problem.
The message box about the wrong RDP version is a VBScript prompt.
Time to tell the page not to bother checking the RDP version and just load the control and page already!
- On your server's hard drive navigate to
C:\Program Files\Windows Small Business Server\Bin\webapp\Remote\
- In there are the various aspx files that load the Remote Desktop sessions.
- tsweb.aspx is the one of interest.
- Open it with Notepad, CTRL-F and find sub window_onload()
Comment out this section:
'if strcomp(version,"6.0.6000") < 0 then
'msgbox IncorrectClientVersion_ErrorMessage, 0, RemoteDesktopCaption_ErrorMessage
(Side-effects: If you are still running something pre-Win 7 on the internet, God help you, you may actually need this check for some ancient RDP ActiveX control version, but other than that specific instance, it should be irrelevant)
- Save the file and close it.
Windows 10 using IE 11 will now open the Remote Desktop ActiveX windows like previous clients did.
It took me a while to Google out this solution -- so hopefully an article makes this solution more easily found.
The solution's original source can be found here