Updating your Azure AD Application Proxy Connectors


Hello folks,

A lot of you ask us about the process we follow when updating connectors and releasing it to you. So, I figured I’d use today’s post to clarify what we do in this regard. I’d also like to cover the improvements we’ve made to make the process more stable and predictable for you.

As you know, we support automatic updates for any connector that you deploy and have had this capability for some time now. This was a key focus for us because we did not want you to have the burden of watching out for updates and keeping the connectors updated with the latest changes. With automatic updates, we offer you a simple way to keep up-to-date and get the advantage of all the feature, security and performance enhancements we make.

We’re constantly looking for ways to make our offering even better and we have made some improvements in this regard to better serve your needs. I’ll let Harshini, a Program Manager on the team, share more information about this new update process.

As always, if you have any feedback on this please send us a note at aadapfeedback@microsoft.com. We look forward to hearing from you.

Thanks,

Girish Chander.

@chander_girish


Hello everyone,

I’m Harshini Jayaram and I’m a Program Manager in the Azure Active Directory team, focusing on Application Proxy. We’ve recently released the next update for your connectors, and wanted to give some transparency into that process.

Connector Updater Service

When you installed your application proxy, you may have noticed that two services were added to your server – Microsoft AAD Application Proxy Connector (the core connector service), and Microsoft AAD Application Proxy Connector Updater (the updater service). As long as the second service is running, your connectors will update automatically with no downtime and no manual steps required.

If you don’t see the connector updater service on your server, you will need to reinstall your connector in order to get any updates. You can learn more about installing connectors in our setup documentation.

Update Rollout Process

Our updates happen using a gradual rollout process, intended to minimize any impact to you. Any rollout we make is first tested out in our test environments. Once successful there, we roll it out into our production environments. In our production environments, we first release it to our own test tenants to ensure there are no surprises. Again, the goal here is to prove out the stability of the update to ensure there is no downtime to your environment.

Next, we target customer tenants; starting with customers that have multiple connectors in their connector groups. In each of those groups, one connector is selected at random for an update. This way, in the unlikely event of a connector going down as a result of the update, there will be other connectors in the connector group that could take the load. This ensures that your users don’t see any impact to their application access.

Finally, we update the remaining connectors – those in connector groups with just one connector, and the remaining connectors in multiple-connector groups.

In each phase of the rollout we proceed gradually across our customer segment in that phase and ensuring that the rollout is successful, before proceeding. And we move between these phases only after the successful rollout of the preceding phase.

Update Impact

Tenants with One Connector: If you only have one connector, that connector will be updated as part of the last group. Because there is no other connector to reroute traffic through, the service will be down during the update. To avoid this downtime and more broadly ensure high availability, we recommend installing a second connector and creating a connector group. For details on how to do so, please see our documentation on connector groups.

Other Tenants: During the connector update, traffic will be rerouted to your other connectors for minimal disruption. However, any transactions in progress when the update starts may be dropped. Your browser should automatically retry the operation, making this potential drop transparent to you. Otherwise you may need to refresh your page to work around this.

We know it can be painful to have even the minute of downtime, but these updates allow us to give you an even better connector with numerous improvements that we think are worth it.

If you’d like more details on the changes in our recent Connector update, you can look at this page with the details on our latest update. We will update that page along with each update.


Comments (6)

  1. Tom De Santis says:

    Hi – quick question regarding installation issues we have encountered with the Azure App Proxy connector:

    We believe we have met all the pre-reqs required for the app proxy connector to be installed on our domain joined member server which includes having outgoing access via the main firewall from this server to the ports listed in the pre-req document which also includes the following DNS names:

    *.msappproxy.net
    *.servicebus.microsoft.net
    login.windows.net
    login.microsoftonline.com

    The connector installation routine does not prompt us for any azure AD credentials and ends with a message indicating that the setup failed and to make sure we are a global admin of our “active directory” and that we have the application proxy feature enabled.

    1. Surely the error message should mean being a global admin of our Azure AD instance and NOT the AD on prem domain that the member server is a member of?
    2. more importantly, it appears that the list of DNS /URL names that the server needs outgoing access to appears to not be complete. Attempting to access “login.windows.net” via a web browser on the server seems to result in the web browser being redirected to other DNS/URL names that are not in the pre-req list. Is there an officially published list of DNS/URL names that is actually required over and above the 4 listed in the pre-req docs?

    Thanks in advance.

    Tom.

    1. Jean-Philippe says:

      Hi Tom, we have the same issue, the list of URL is not complete. You can follow this discussion : https://azure.microsoft.com/en-us/documentation/articles/active-directory-application-proxy-troubleshoot/#comment-2983310695

      1. Steven Wire says:

        I had the same problem and went though a number of things to try and resolve it. I ended up finding the MSI log and the error in the log was that the Powershell script could not be run (even though it was signed). I enabled all scripts to execute via GPEdit, and then the install completed in 30 seconds.

        Steven

  2. Chris Cundy says:

    Does the Certificate issues by connectorRegistrationCA.msappproxy.net automatically renew on its expiration date as I have said certificate set to expire on 25th April 2017.

  3. Tony says:

    Hello,

    This article was published in October and there have been no updates on Azure Application Proxy still. Is this product still actively being developed. Although it is a great product it lacks the maturity that would come with some additional features, such as the ability to choose which Azure Region you’d like the public-facing application to reside in. That way, if I have an application hosted in the UK and my Azure tenant is in the US, my UK users don’t have to cross the ocean twice before they can reach a published app.

    This was also discussed in the comments in a previous post from August:

    https://blogs.technet.microsoft.com/applicationproxyblog/2016/08/16/network-topology-considerations-when-using-azure-ad-application-proxy/

    Thanks,
    Tony

Skip to main content