Code Library

A few years ago, our team had a big dilemma. We had two products in the market: Forefront Threat
Management Gateway and Forefront Unified Access Gateway. Both of these products had been around for many years and had been deployed by tens of thousands of customers. Both of them
had evolved since they were first introduced during the 1990s.

However, both products had similar issues: They were very complex products that were difficult to
deploy, troubleshoot, and maintain. This was partly because over the years they accumulated many
capabilities that became irrelevant. At the same time, they lacked or had limited support for modern technologies such as federation and OAuth2. On top of it all, they were expensive products that had their own licenses.

It was a tough decision, but we decided to start from a blank page, to examine all the functionalityof reverse proxy, to pick and choose only the technologies that matter today, and to implement them by using a fresh code base built on the most modern standards. A big part of this decisionwas that we wanted to embed the reverse proxy into Windows Server. We wanted to make it justlike any other role service available to install from Server Manager. For us, this meant adhering tothe strictest standards regarding code and management. Microsoft customers expect that allWindows Server role services are managed the same way, including in Windows PowerShell, the administrator UI, the remote administrator UI, performance counters, the System Center OperationsManager pack, event logs, and so on.

This is how Web Application Proxy was born in Windows Server 2012 R2. We made no compromise
on code security, management, and standardization. And, we were happy that customers got it. Companies were able to deploy and integrate Web Application Proxy into their infrastructure very
easily.

The downside of this approach is that we were not able to include all of the functionality we wanted
to have—functionality that would make it possible for all customers to move from Threat Management Gateway and Unified Access Gateway to the new solution. However, now that we
have built a solid foundation, it is easier to add more functionality to make Web Application Proxy
the obvious choice to publish on-premises resources such as Microsoft SharePoint, Lync, and Exchange to remote users. This version marks an important milestone in the journey we began quite a few years ago.

Now, it is time for us to begin another journey to bring remote access to the cloud era. We have
created Azure Active Directory Application Proxy as another tool for customers to publish applications in cloud-based solutions. Fortunately, Web Application Proxy in Windows Server and
Azure Active Directory Application Proxy share a lot of code. More than that, they share the same
concepts and perception of remote access and how to make it simple to deploy and easy to maintain.

Going forward, we will continue to develop both products. We plan to offer Microsoft customers a
choice with regard to which architecture to use. The cloud offers users a unique and highly efficient
way to implement remote access utilizing the rich functionality and robust security mechanisms of
Azure Active Directory, without the need to change their perimeter network. The same service that
takes care of 18 billion authentication requests per week handles your on-premises applications.

Source of Information : Microsoft Introduction Windows Server 2016