Remote Web Access login page Redirect
October 31, 2016 4 Comments
This post comes courtesy of Susan Bradley, in that she highlighted the issue to me. In turn it was highlighted to her via TechSpeeder.
The issue is a relatively simple one, in previous versions of Essentials, visiting http://server or http://server.remotewebaccess.com it would automatically redirect you to the RWA Login page at /remote. In 2016 this is not occurring.
In 2012 R2 this behaviour is controlled via default.aspx in particular, this line.
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="Microsoft.WindowsServerSolutions.Web.RootSite._Default" %>
Looking at the Content of the Default Web Site in 2016, we can see the standard IIS InetPub wwwroot folder. This is odd because usually in Essentials that path has been updated to C:\Program Files\Windows Server\Bin\WebApps\Site.
I had previously posted that we should update the PhysicalPath of the Remote Web App web site to match previous versions of Essentials. Doing so corrected the Redirect, however resulted in the below message.
I opened a support case with Microsoft regarding this behaviour and after some time was informed this behaviour was by design. Without any explanation or documentation of changing this feature.
The ‘correct’ way to solve this, is using an HTTP Redirect as shared originally by TechSpeeder, or by educating the user to enter the correct address.
We are still (some months later) yet to hear back from anyone at Microsoft about this or any other issue we have raised with Essentials 2016.
About Robert Pearman
Title (Required) 
How are you liking WSE16 over WSE12R2? Am still loving 2012E R2 and don’t want to reinstall OS all over again and reconfigure DirectAccess unless there are significant benefits in 2016. Thanks.
What are the complete Physical paths for ht old incorrect and the new correct strings?
I had ti install IIS Manager to do this , as the default 2016 Essentials install did not.
Thanks for the post. I used the temporary redirect as a workaround as well. Glad is wasn’t something I messed up in IIS. My migration to WS2012E to new server hardware went smoothly though. Customer rollout is next.