Join our community. Excellent content, great people! Like what you see? Join us for free
I have four Windows 7 clients which are working just fine with our Server 2012 R2 Essentials machine, but I would like to replace them over next few months. As a trial, I built a Windows 10 Pro client (Version 1803) and installed all updates. Next step is to connect to server. I know this has been problematic in the past, but I read this article:
All is well until I enter http://servername/connect into the Win10 machines browser, at which point I receive this error:
"502 Bad Gateway
The server returned an invalid or incomplete response"
Show stopper I'm afraid. If anyone can shed any light on where I go from here I'd be most grateful.
I'm wondering if it's possible to bypass the browser issue and simply download the connector software from our Server? If someone could give me the path to the connector software file I'd be much obliged.
No, you can't. IIS is a part of the installation sequence so it must be functional.
Is your server fully updated with the latest updates?
So kind of you to reply so quickly, thank you! Yep, checked for updates on the server before I started the client-connect procedure - most recent installed updates are:
- Update for Server 2012 R2 - KB4033428
- 2018-10 Security monthly quality rollup for Server 2012 R2 - KB4462926
So all looks fine there. Could it be an IIS issue I'm wondering?
What happens if you are on the server and run from an elevated command prompt 'iisreset'. After that launch a browser on a workstation that is successfully joined and browse to http://server/connect.
Did you use Edge on the Windows 10 client to run http://server/connect? If not, try that.
Ah, I thought you might say that IIS has to be functional, at least I know I need to get that working properly before I can go anywhere with this! As suggested in your very helful guide, I did use Edge but to no avail.
I'm not on site at the moment, but do have remote access - is the iisreset likely to cause any additional issues would you think or is it reasonably benign? Although, having said that, we host our website externally so not sure we use IIS directly anyway.
Once again, thanks for sticking with me on this :-)
I ran iisreset from elevated command prompt - that was fine and it tells me the Internet services are successfully stopped and then restarted. However, attempting http:/fs-server/connect from IE (note this is a Win7 system so no Edge!) from a Win7 client which has been connected to domain for years still results in error "502 Bad Gateway".
Not sure where to go now. Not urgent short term, but will escalate as soon as I need to add a new client to domain :-( I realise now that this isn't just a problem for adding new Win10 clients, it would be a problem even if I were to try to add a new (or rebuilt old) Win7 client. Getting nervous now!
Not something to get nervous from! Computer problems can always be fixed.
I'm sure they can, but possibly not by me in this case! Looks like someone has had this issue before (see https://social.technet.microsoft.com/Forums/lync/en-US/3d60bac9-264a-4d68-9c2d-7990d8813725/2012r2-essentials-connect-site-is-down?forum=winserveressentials), but the end of the thread still shows no solution I'm afraid, although it does date back to 2016. As I mentioned, it's not a big issue at the moment as the IIS issue doesn't seem to affect any other normal server-based use. It will be a big issue as soon as I need to add a new client to the system and that's why I'm nervous :-(
To narrow the problem down, I simply opened IE on the WSE 2012R2 box and entered HTTP://fs-server/connect and that gave 'HTTP Error 500.19 - Internal Server Error' so it's definitely IIS that is at the root of things.
If this was Server 2010 Std then I'd go ahead and rip out IIS and set up again from scratch, but things never seem to be that straightforward with Essentials editions as they have weird dependencies and customisation all over the place - the price we pay I guess for the system being mostly easy to maintain. It suddenly goes the opposite way in this kind of situation.
Would you have any advice on what my next step could/should be? Any links to on-line docs would be a real help, I'm more than happy to spend time on this issue to get it resolved. The only good thing is that I do actually have time at the moment so I'm keen to fix it in advance of it being a stressful issue at the point where I need to replace a failed client PC.
I appreciate your help here in this thread (I'm not sure where else to get help on an Essentials-centric issue like this) , but perhaps I should be looking at requesting paid-for help from you, is that possible?
Before we get you on Premier Support let's try something else. Do you get more than just the 'HTTP Error 500.19' error?
I do indeed, I've just been looking at that as it happens! Opening IE direct on the server and going to HTTP://localhost (HTTPS://localhost gives same result) produces HTTP error 500.19 with an error code of 0x8007007e - see attached image for more details.
I then Googled and found this link:
from 2016 with a reply from your good self suggesting:
" Did you also install WSUS on your server? If so, disable compression on the WSUS site will fix this "
Not gone any further yet.
Yes, that is an error I see sometimes. Did you install WSUS and uninstall?
This issue is because of the XPress compression schema module (suscomp.dll) which gets installed with WSUS. Compression schemes are defined globally and try to load in every Application Pool. It will result in this error when the 64bit version of suscomp.dll attempts to load in an Application Pool which is running in 32bit mode [enable32BitAppOnWin64]. 32bit mode is needed for SafeGuard Enterprise Server to run.
1. Navigate to %WINDIR%\system32\inetsrv\config\
2. Create a backup copy of the file applicationhost.config and save it to a different location.
3. Open the applicationhost.config in Notepad.
4. Search for the following entry:
<scheme dll="C:\Windows\system32\inetsrv\suscomp.dll" dodynamiccompression="true" dostaticcompression="false" dynamiccompressionlevel="0" name="xpress" staticcompressionlevel="10"></scheme>
5. Remove / Disable the XPress compression schema from the configuration using the command below:
%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression /-[name='xpress']
6. Verify if the compression schema has been removed from the applicationhost.config.
7. Save the applicationhost.config and restart IIS services.
This sounds hopeful! I'm not able to carry out your recommened procedure at the moment, but will do as soon as I get back to the office.
I've inherited this server so not sure if WSUS was ever installed - it might have been installed and then removed, it might still be there, or it might not ever have been installed. It should be easy enough to check if it's still there, but how would I know if it was there but has since been removed? Presumably if it's installed then removed it still leaves this little time-bomb that clobbers any subsequent client-connect procedure?
This seems like a disaster waiting to happen for ServerEss 2012R2 systems that install WSUS, is it just another example of MS getting it wrong?
Will report back my findings asap. Thanks for this :-)
Microsoft is a fantastic company and they make wonderful software but nothing is perfect. Like I said before, anything can be fixed. You just need to know how and I understand that can sometimes be a problem. I spend at least one-third of my time studying and reading Technet documentation to keep up with developments.
Point taken ;-) OK, I've taken a look via Server Manager and it shows WSUS role is unticked so is not currently installed. If the WSUS role has never been added (and I suspect that will be the case) is it still worth running through the 7-step procedure or would that now be unlikely to resolve my core issue and that the cause lies elsewhere?
I SO wanted to see the WSUS role currently active!
Just do what is in the above solution. If that XPress compression schema module is not listed in your ApplicationHost.config we have to look for other solutions. Just open that file with Notepad and press CTRL-F and search for suscomp.dll