1. I tried modifying the Launcher RDP file I had downloaded as you described.  The ‘gatewayhostname:s:’ parameter was already set to the correct URL, but other fields such as ‘full address:s:’ and ‘alternate full address:s:’ were set to the server name EC2AMAZ-H….  When I tried to connect after modifying these fields to match the URL, it came up with the same errors as before “There was a problem connecting to the remote session…”.
2. If I tried the ‘Devices’ gadget RDP – that file has the same issue, although that file isn’t digitally signed (no ‘signscope’ stuff at the bottom).  Same error when trying to connect after modifying the RDP in similar fashion to the one above.

Unfortunately, there’s no “trial” version available for the WSEE Installer. You’ll just need to manually install it using the steps provided here. If it works, then as you mentioned, WSE RemoteApp 2016 “should” work as well.

Good luck, and please do let us know how it goes.

If I could be allowed access to the WSEE installer, I’d like to try it out on AWS Lightsail.  If it’s successful, then the WSE RemoteApp 2016 product should work on AWS.

The steps for a manual install of WSEE on WS 2019 appear to be quite complex and even your website grays out the complex steps and recommends using your installer.  Not practical for me to spend hours going through a difficult setup like that.  Since it appears, I won’t be given access to the your installer (even though it would be ideal test case that could result in a lot more sales of your RemoteApp product), it appears that I only have 2 choices (please let me know if there other alternatives):

1) risk $55 on your ‘student edition’ of WSE RemoteApp 2016 to gain access to your WSEE installer or

2) create another AWS Lightsail instance using Windows Server 2016 (which if I understand correctly), allows adding the WSEE directly from Server Manager (or something like that).  Once WSEE is installed, I can try out the RemoteApp trial version.

From the sounds of it, the settings given within the RDP file are correct. If you’d like to post the entire contents of the RDP file here (after clearing out all of your private info), I’ll confirm that for you.

As I mentioned previously, if the ‘Devices’ gadget produces the same result when you attempt to remotely connect to your server Dashboard from the resulting RDP file, then that most likely indicates that the problem is with your server configuration (and not with WSE RemoteApp).

I’ve personally never come across an ISP that blocks both ports 80 and 443. The blocking of port 80 is fairly common (but it doesn’t matter one bit since you never want to connect to your Essentials server via an unsecure HTTP connection anyway). However, if port 443 is being blocked, then you’ll never get the remote connection stuff in Essentials (or in WSE RemoteApp) working I’m afraid.

I’m sorry to hear that you can’t get the Essentials remote domain join feature working with your clients. Guess it was worth a try though. I’ve never personally tested it before, but I do know that it relies upon the client being domain joined to the server, and it takes place over a VPN connection (Essentials requires the clients to be domain joined when using its built-in VPN feature).

As for WSE RemoteApp… It works no matter how the clients are connected to the server (i.e. using the default domain join connection method, or using Microsoft’s well documented SkipDomainJoin connection method). Again though, I’ve never tested it on a client that has been remotely domain joined (although I can’t see why it wouldn’t work seeing as once you’ve connected the client to the server over the VPN connection, WSE RemoteApp would just see it as if you were locally connected to your network).

Strange…

I have no way of being able to test this stuff out over here since I don’t use AWS. Thus, I’m not exactly sure why the downloaded RDP files are using the server’s name instead of the Internet domain name as they should be. My guess there is that the code is failing to retrieve the Internet domain name from the server (for whatever reason) and so it’s simply falling back to using the server’s name as a last resort (again though, I don’t know for sure since I can’t test it here).

As for the RDP files themselves… They are digitally signed for security purposes, and so you can’t edit them (as you’ve mentioned). However, if you open them in Notepad and manually delete all of the gobbledygook (from the “signscope” line downward), you will then be able to edit them (in order to change the “gatewayhostname:s:mydomain.remotewebaccess.com” line, etc.) as desired. They will simply no longer be signed is all (but will still work fine).

Unfortunately, I have no idea about the issue that you’re having when attempting to remote domain join your client computers. That has nothing whatsoever to do with WSE RemoteApp, and falls under the “general” Windows Server Essentials support category (which I don’t offer). I’ve personally never attempted to remote domain join a client computer to an Essentials server before, and so I can’t offer you anything much in that area anyway. Your best bet there would be to post the issue up on Microsoft’s Essentials support forum to see if someone over there can offer you any assistance in that area. You could also try searching the old (and now defunct) TechNet Essentials support forums here and here.

Lastly, if you don’t want to wait for your questions to be approved, then you should register on this site. Once you’re registered (and logged in), and have at least one previously approved post, then all of your posted questions/answers will show up immediately (without needing to wait for me to get around to manually approving them).

EDIT (4/23/2021): BTW, what happens when you attempt to remotely connect to the server (Dashboard) from the “Devices” gadget on your server’s built-in RWA website (assuming that you’ve granted the user you’re signing in as the permission to do so)? Does the downloaded RDP file have the exact same issue where the server’s name is used instead of the Internet domain name? The reason I ask is that WSE RemoteApp is using the exact same underlying code to create its RDP files. Thus, if that built-in functionality of the server isn’t working for you, then neither will WSE RemoteApp (i.e. you’ll need to figure out why that’s happening for the built-in functionality before WSE RemoteApp will work for you).

Yes, the manual installation steps are indeed complex (took me hundreds of hours to figure all that stuff out for folks). Unfortunately, you’re in a bit of a “chicken vs egg” conundrum here for sure (especially if you don’t want to commit the time to doing the installation manually). I’m just not able to grant folks “trial” access to the WSEE Installer, and so the two options that you’ve listed are indeed your only choices (outside of doing the installation manually). If it were me, I’d definitely go with the second option seeing as you’ll gain nothing by using 2019 over 2016 as far as Essentials itself goes (and 2016 is still fully supported by Microsoft for many years to come). Just be aware that the multiple simultaneous connections feature of WSE RemoteApp is not available when it’s running in its 21-day evaluation mode (nor is it available for the licensed two user “Student Edition”, since two simultaneous connections are already allowed by default).

BTW, I seriously doubt that there’s more than one or two other people out there in your Essentials running on AWS position. In all my years of working with Essentials (over a decade now), you’re probably about the only one that I can recall who’s ever approached me with such a request, and so you’re most definitely a rare/outlying case. Typically, folks who want to use Essentials with a hosted server use Windows Server 2016 running under Microsoft’s Azure cloud platform instead (and even those are super rare as far as WSE RemoteApp is concerned).

Good luck with whichever route you decide to take.

Sorry, didn’t see the notification email that you had responded until now.

I don’t recall if I had enabled VPN during WSEE setup on the last try – I don’t think it’s enabled by default (or possibly I had unchecked it for troubleshooting purposes).  I remember at first trying both ways, with and without VPN enabled.

In your last paragraph, you mentioned that your app can work with the SkipDomainJoin method, but in the prior paragraph you had mentioned that it (or perhaps only the ‘remote join domain’ feature) depends on the client being domain joined.

Here’s the <servername>.rdp file (3 dots inserted to mask connection URL), below this is the WSE RemoteApp Launcher.rdp file:

screen mode id:i:2
use multimon:i:0
desktopwidth:i:0
desktopheight:i:0
disable wallpaper:i:1
allow font smoothing:i:0
allow desktop composition:i:0
disable full window drag:i:1
disable menu anims:i:1
disable themes:i:0
bitmapcachepersistenable:i:1
full address:s:ac…nv.remotewebaccess.com
audiomode:i:0
redirectprinters:i:1
redirectdrives:i:0
redirectclipboard:i:1
alternate shell:s:||RemoteDashboard
remoteapplicationprogram:s:||RemoteDashboard
remoteapplicationname:s:Dashboard
remoteapplicationcmdline:s:
remoteapplicationmode:i:1

negotiate security layer:i:1
gatewayhostname:s:ac…nv.remotewebaccess.com
gatewayusagemethod:i:1
gatewaycredentialssource:i:4
gatewayprofileusagemethod:i:1
promptcredentialonce:i:1

username:s:AC…ED\admin

WSE RemoteApp Launcher.rdp:

screen mode id:i:1
use multimon:i:1
desktopwidth:i:800
desktopheight:i:600
disable wallpaper:i:0
allow font smoothing:i:1
allow desktop composition:i:1
disable full window drag:i:0
disable menu anims:i:0
disable themes:i:0
bitmapcachepersistenable:i:1
full address:s:ac…nv.remotewebaccess.com
audiomode:i:0
redirectprinters:i:0
redirectdrives:i:0
redirectclipboard:i:1
alternate shell:s:||WSERemoteAppLauncher
remoteapplicationprogram:s:||WSERemoteAppLauncher
remoteapplicationname:s:WSE RemoteApp Launcher
remoteapplicationicon:s:C:\Program Files\The Office Maven\WSE RemoteApp\Images\wseral32.ico
remoteapplicationcmdline:s:/ra_launcher -rwa -rc -rs -cs:7 -rnd:9431
remoteapplicationmode:i:1
negotiate security layer:i:1
gatewayhostname:s:ac…nv.remotewebaccess.com
gatewayusagemethod:i:1
gatewaycredentialssource:i:4
gatewayprofileusagemethod:i:1
promptcredentialonce:i:1
username:s:AC…ED\admin
span monitors:i:1
prompt for credentials:i:0
connection type:i:6
networkautodetect:i:1
bandwidthautodetect:i:1
alternate full address:s:ac…nv.remotewebaccess.com

I chose AWS vs Azure because AWS is a fraction of the cost and the remote users just need to run a few apps on the server.  Once a server instance is created in AWS, I doubt there’s much functional difference between Azure and AWS.

I have created a WS 2016 instance in AWS and I’ve successfully installed and configured WSEE.  It appears I’ve run into another obstacle…can’t test any RemoteApp connections since web access is denied during trial period and since this is a cloud server, can’t connect via Launchpad since there are no local clients.  Sorry if I missed something, but I checked your documentation and didn’t see any other way for remote clients to connect.

I imagine that you’re correct there seeing as everything Microsoft does via the cloud is crazy expensive. I’ve never personally messed about with an Azure hosted server before, and so I can’t personally speak to any of that either. I only know that folks seem to migrate towards Azure since Essentials is (or once was) fully supported on it.

Unfortunately, as you’ve found, WSE RemoteApp’s RADC web feed functionality is not available while running in its 21-day evaluation mode. Thus, the only way that you’ll be able to test out remote connections to WSE RemoteApp in the “trial” is via the server’s built-in Remote Web Access (RWA) website, which will require you to configure Anywhere Access on the server and set up a free Microsoft personalized domain name (e.g. https://YourDomainPrefix.remotewebaccess.com) on it. Once you’ve done that, you should then be able to sign in to your server’s built-in RWA website and remotely connect to WSE RemoteApp from there (via the WSE RemoteApp gadget on https://YourDomainPrefix.remotewebaccess.com/remote OR via the WSE RemoteApp homepage at https://YourDomainPrefix.remotewebaccess.com/remote/WSERemoteApp).

For a bit more info see:

Manage Remote Web Access in Windows Server Essentials

Secure Remote Web Access

Understand Microsoft personalized domain names

Configuring and Customizing Remote Web Access on Windows Server 2012 R2 Essentials (this one is for an older version of Essentials, but has images)

EDIT (4/19/2021): BTW, once you’ve set up Anywhere Access/Remote Web Access on the server, you can then connect client PCs to it remotely (i.e. instead of using the LAN address http://YourServerName/connect to install the connector software (i.e. Launchpad) on your clients, you would use the WAN address https://YourDomainPrefix.remotewebaccess.com/connect instead). After doing that, you can connect to WSE RemoteApp via the Launchpad that’s installed on the client computer. See: Remote Domain Join in Windows Server 2012 Essentials (again, this one is for an older version of Essentials, but still applies)

I’m able to connect with https://mydomain.remotewebaccess.com/remote.  If I choose any of the visible RemoteApp ‘gadgets’, it prompts to download an RDP file that points to the wrong location (the server name instead of the proper URL.  The RDP file cannot be edited.

I then used https://mydomain.remotewebaccess.com/connect and was able to download the connector software (Launchpad), but when I click install, it has the correct URL to connect via RWA.  It then prompts for network username/password (I enter the same user/password I did with the previous attempt that was successful with …/remote). but then it denies the connection with ‘The server is not available…’.  The user is set up under WSEE/Users and also under WSEE/WSE RemoteApp and has permissions on Launchpad, RWA and RDA.  The only guide I could refer to was at https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-essentials-sbs/jj635102(v=ws.11) and I did verify that the time was set properly on the server.