Well, this used to be an easy one but things have changed slightly in Server 2016 Essentials. In the past, you could just redirect remote.yourdomain.com but, with 2016 Essentials, the address is now remote.yourdomain.com/remote (redundant, right?). Fortunately, tackling this redirection isn’t too difficult…

The problem and one thing to avoid!

So, the problem is that if you redirect the root of the domain/subdomain, you end up at the default IIS webpage in all it’s blue checkered glory. This is because RWW is now called from the /remote folder so you have to include that in the redirect. “Easy! I’ll just change the root of the of the website in default.aspx or I’ll update the physical path!” is what you’re thinking… HORRIBLE IDEA! DO NOT DO THIS. This is a horrible idea because the default website and the remote app use different AppPools and identities (Remote AppPool with NetworkService for the former and DefaultAppPool with ApplicationPoolIdentity for the latter). This means that if you change the root, you’ll be trying to access the remote app using the wrong set of permissions and you’ll just bung the whole thing up. Let’s go for an easier solution.

Let IIS handle the redirect

This is actually remarkably simple using the built-in IIS redirect feature just as you may have done in earlier versions of Server Essentials or Small Business Server (SBS). This time though, you have to remember to include the new folder reference and make sure you’re only redirecting calls to the root folder and not explicitly requested subfolders.

Let’s start by opening IIS and selecting the root of the Default Website. Open the ISS snap-in, expand your server and select “Default Web Site”. Remember, we are redirecting calls to the root of the domain/subdomain that your default website is located in and not the location of the default website itself. If your RWW isn’t housed in your default website (for some reason) then you’ll have to adjust these instructions as needed.  (SCREENSHOT)

In the features window that shows up on the righthand pane of IIS, go ahead and double-click on “HTTP Redirect” to open up that feature.  (SCREENSHOT)

Alright, here’s where the magic happens. Check the “Redirect requests to this destination” box and fill in the fully-qualified domain name to which you want the user redirected. In this example, I’m redirecting anyone going to remote.mydomain.com to https://remote.mydomain.com/remote. This way, they are moving from HTTP to HTTPS and are simultaneously going to the remote app (/remote)… that’s everything we want to accomplish in one easy step! (SCREENSHOT)

A little note: Make sure you check the “Only redirect requests to content in this directory (not subdirectories)” box. This makes sure that specifically requested subdirectories such as /printers or /myfolder still go where they’re supposed to and only calls to the root domain are redirected to the remote app. Failing to do this will frustrate your users, ruin any bookmarks and break a few other features of RWW (such as if you run web-certificate enrollment, etc.)

You’ll notice that I selected a “Found (302)” status code. I do this so that search-engines don’t re-index the main (default) page and so that it’s recognized as a temporary redirect. That way, I can quickly change it as needed. You can just as easily select “Permanent (301)” as your status code if you’d like. Google is your friend in learning the differences and deciding on what suits you best. As far as the redirect and IIS are concerned, there is really no difference between a 301 and 302 in this case.

That’s it! All done. Your redirect works properly now and doesn’t break anything else. Simple, right? Thanks for reading my techie-thoughts on this issue. Have any comments? Suggestions? Want to add your tips? Things you want me to cover in a future article? Comment below!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Close Menu