There are four parts to this article: Part 1 prepares the server for reverse proxy, Part 2 installs the Web Application and create a Windows Service for that app, Part 3 configures the Web Site and, finally, Part 4 looks at setting up the DNS record.

These instructions have been tested on Windows 2016, 2019 and 2022 servers.  

Part 1: Preparing the Server for Reverse Proxy

1. Add the Web Server Role to your server.  This is done through the Server Manager application.  Default selections have been used.

2. Download the URL Rewrite component from https://www.iis.net/downloads/microsoft/url-rewrite and install it.
3. Download the Application Request Routing (ARR) component from https://www.iis.net/downloads/microsoft/application-request-routing and install it.

Your server is now ready to host Web Applications behind IIS.

Part 2: Installing the Web Application and Configuring the Windows Service

As Xojo built applications are stand-alone, it is simply a matter of copying the application to the server. Typically, the location will be C:\Program Files\<Your Company Name>\<Your Application Name>.

To create the Windows Service, you’ll need to run CMD As Administrator and enter the following commands.  I have used Demo Company and Demo Application.

SC Create Demo binpath= “C:\Program Files\Demo Company\Demo Application\Demo Application.exe –port=8080” Start= auto
SC Description Demo “Demo Web Application”
SC Failure Demo actions=restart/2000/restart/2000/restart/2000 reset=10
SC FailureFlag Demo 1
SC Start Demo

SC Create creates the service setting the path to the binary (executable file) specifying Port 8080 and configuring the service to start with the server.

SC Description sets the long description for the service and is optional

SC Failure configures how the controller will handle service crashes.  In this case the service will be restarted after 2seconds for the first, second and subsequent failures.  The failure count will be reset after 10 seconds.

SC FailureFlag configures the service to treat app crashes as service crashes.  Without this the controller won’t execute the failure actions set previously

SC Start simply starts the service.

Part 3: Configuring the Web Site

First, you’ll need to create the website using Internet Information Server Manager:

Next, you’ll add a reverse proxy rule using the URL Rewrite function:

Select Add Rule:

Select Reverse Proxy:

And finally configure the rule:

127.0.0.1 is the local machine and 8080 is the port configured in the service.

Part 4: DNS

For the client browsers to find the site you need to add a record to your Domain Name Server.

You can see here I’m adding a CNAME record to the DNS Manager.  The fully qualified domain name matches the website name, and the site is hosted on a machine called WebServer.  We use a CNAME record which is an alias of the WebServer A record so that if the WebServer ip address was changed all the sites would automatically follow.

Wayne Golding has been a Xojo developer since 2005 and is a Xojo MVP. He operates the IT Company Axis Direct Ltd which primarily develops applications using Xojo that integrate with Xero www.xero.com. Wayne’s hobby is robotics where he uses Xojo to build applications for his Raspberry Pi, often implementing IoT for remote control.

The current A record in your DNS settings points to your existing Xojo Cloud server’s IP address and probably has a TTL (time to live) of 24 hours. At least 24 hours before you plan to move your server data and change the IP address, set the TTL to 5 minutes. Doing this means that you can change the IP address to your new server IP address and most of the DNS servers out there should pick up on the change in around 5 minutes.

After you have made the move to the new server, you should set your TTL back to 24 hours, or whatever it was set to previously. And that’s it!

After a bit of experimentation this January we were able to isolate one huge cause of this annoying behavior. Unfortunately it has to do with a misconfigured IPv6 DNS server configuration and whether or not yours is correct may be up to your service provider.

Whose bug is this?

According to the spec, IPv6 DNS servers are supposed to return immediately if they can’t fulfill the request. Unfortunately this is almost the exact opposite of what an IPv4 DNS server does, in that it may forward your request to the next server to see if it knows where your request should go. Unfortunately we found that only about two-thirds of the ones we tested were correctly configured.

On macOS and Linux, DNS requests are sent concurrently, that is, two requests are sent at the same time, one each for IPv4 and IPv6. The one that returns first is used. On Windows, the requests are unfortunately sent sequentially, IPv6 and then IPv4. What this means is that IPv6 requests just hang there, waiting for a response that will either never come or will wait until the underlying socket reaches its timeout. When that fails, the IPv4 request is sent and fulfilled and your socket request goes through.

What To Do

Here are a few things you can do to test this theory. While you can’t really ask all of your users to do this, it will tell you if this is where the problem lies.

1. Turn off IPv6.
   1. Click Start and then Settings.
   2. Search for Network Connections.
   3. Click View network connections.
   4. Right-click on the active connection and select Properties.
   5. On the Networking tab, clear the Internet Protocol Version 6 (TCP/IPv6) check box, and then click OK.
2. Change the DNS entries for IPv6 from the defaults to point to Google Public DNS or OpenDNS.
3. Make a Hosts file entry. If your installer runs as an administrator, you can make an entry in the hosts file to force the computer to use IPv4. This is not a long term solution as the world moves to IPv6.The hosts file on Windows 7/8/10 is located at:

   C:\Windows\System32\drivers\etc

   and you should add an entry which looks like this:

   Server IP Address<TAB>domain name

4. If it’s a domain that you control, make sure you only use IPv4 DNS entries and that your server is only listening on the IPv4 interface.

All in all, it’s a frustrating problem. While there’s no easy solution, the good news is that because there are no IPv4 addresses left to be distributed, the world is moving to IPv6. The more demand there is, the more likely that the incorrect DNS servers will get fixed because they’ll cause problems for other sites as well.