Cloud Decoded

Lets take a look at a scenario which is getting more and more prominent with many organizations deciding to move their SharePoint environment out of their own data center to host of MS Azure VMs. This is more seen in smaller/medium size companies who completely want to do away with their data centers by moving most/all such services (like Exchange, Lync etc.) to cloud.

This article is for VMs created using Classic Model in Azure, If your VMs are created using Azure Resource Manager (ARM), read this article instead

Well, when running a medium sized SharePoint farm in-premise, mostly organizations have a reverse proxy (ISA, F5 etc.) mechanism in place, so, if they wanted all the traffic to be on HTTPs, that reverse proxy used to take care of this translation. Also, this problem is not that relevant for in-premise deployments as mostly users from within the internal network are allowed to access the sites over HTTP and HTTPS translation is required only if they try to access from outside their office network, like home.

Once they move their SharePoint farm to Azure VMs –

1. They don’t want to continue using the reverse proxy, as it does not make sense to route all the traffic first to organization’s network and then route to MS data centers
2. They want everyone to access the sites over HTTPS only, including from within office network to avoid any security issues, since content is now hosted outside organization’s firewall in an external data center.
3. They want the HTTP to HTTPS redirection working as it was with their in-premise setup, where any user requesting a URL over HTTP coming from Internet would get redirected to HTTPS by the reverse proxy
4. In many cases, they would look to use a federated identity (like ADFS) to achieve SSO, if there are more than one web application hosted in SharePoint, or if they also have Office 365 setup.

1.  Let’s say they have 2 web applications in SharePoint – one for their collaboration (say collab.mycompany.com) and another for their mysites (my.mycompany.com). Both hosted in port 80 with corresponding IIS Host Headers and uses Windows Authentication (NTLM) that will be used by Search and other services to access the sites internally. This will be in Default zone of AAM
2. For users, both of these sites will be extended on port 443 with proper SSL Certificates with same host headers. This could be in Internet Zone.
3. Now, the port 443 would be added to Azure End Point of front end servers and users would be able to access the sites over HTTPS, if everything is configured properly.
4. BUT: when they try to access the sites over HTTP, they will get something like “Page cannot be found”, as Azure won’t allow port 80 traffic to be passed, because it’s not added in Azure End Points.

So, the issue is apparent, users who are used to or may have some URLs stored in their browser favorites as HTTP, which they were able to access earlier (with in-premise setup, thanks for reverse proxy), won’t be able to access those links now, until they manually change the links from HTTP to HTTPS.

Solution:

So, what can we do about it. Well, there is no straightforward solution. As, you can think of, adding port 80 to Azure endpoints, will result in users being able to access the sites over HTTP itself, which is not desired.

We need to make use of Azure End Points + URL Rewriting module of IIS to make this work.

• Create an Empty Web Site in IIS on some random unused port, say 7780, with the same host headers as of your SharePoint sites and map it to any folder. you can add both the SharePoint hosts (collab.mycompany.com & my.mycompany.com) in the host header of this site on port 7780

• Allow port 7780 in Inbound Windows Firewall rule, if that’s enabled
• Add a web.config file in the root folder of this new IIS web site with following content

              

• What essentially, it is doing is to access users request on http and redirect the traffic to IIS site hosted on port 7780 and since the IIS site on port 7780, is just doing a redirection, users will see their browser address bar getting changed to https 🙂
• This also, resolves an issue, where I found that SharePoint alerts were sending mails with Default zone URLs only, regardless of the zone from where they were subscribed. So, now even though users receive alerts with http URLs, when they click on those links, they get redirected to correct https URL.

Hope this helps 🙂