1. Cached
2. Internal Load Balancer

The Essential Guide to Microsoft Teams End-User Engagement

We take you through 10 best practices, considerations, and suggestions that can enrich your Microsoft Teams deployment and ensure both end-user adoption and engagement. All sound recorder vista 1.3.

Since you say your NSGs allow traffic, check to ensure that your Firewalls on the VM itself are not blocking anything. In the Firewall settings check the boxes next to 'enable file and printer sharing.' Azure Application Gateway enables you to build highly scalable and available web sites by providing HTTP load balancing and delivery control. Web Application Firewall Application Gateway provides you with all the benefits of a basic Application Gateway, as well as protection against malicious web requests. The Azure Application Proxy supports a number of application types: Web applications that use Integrated Windows Authentication for authentication. Web applications that use form-based or header-based access. Web APIs that you want to expose to rich applications on different devices. Play dreamcast games online, free. Applications hosted behind a Remote Desktop Gateway.

Cached

Azure Application Gateway is a powerful Microsoft Azure PaaS service that is providing HTTP load balancing, reverse proxy, SSL termination and web application firewall capabilities. It’s very well documented there: https://docs.microsoft.com/en-us/azure/application-gateway/.
However, there a a few not-that-obvious things that could be easily missed in the provided documentation. I recently spent some time working with Azure Application Gateway (AAG), and I’d like to share a few lessons from my experience.

Internal Load Balancer

1. Different deployment models. Like many other Azure services, AAG could be deployed using Classic or Resource Manager (ARM) deployment models. However, Classic deployment could only be performed using PowerShell scripts. There is no way to deploy AAG using Classic portal (it’s not listed there). ARM deployment could be done using either ARM template or ARM portal (portal.azure.com). When using PowerShell, AAG configuration is defined in XML document. When using ARM deployment, gateway configuration is defined in JSON (like everything in ARM template). Keep in mind that Classic AAG will only have access to Classic VNets while ARM AAG will only have access to ARM VNets.
2. Deployment model considerations. Even if all of your network resources are Classic, it’s still better to deploy gateway using ARM model:
   • Classic deployment is considered to be legacy. All new deployments are recommended to be ARM.
   • ARM is much better scriptable than Classic.
   • If gateway is deployed as ARM then you’ll be able to manage it in portal.
   • You can still connect ARM gateway to your classic VNet if you set up peering from gateway VNet to Classic VNet.
3. Always use ARM templates! Even though most AAG configuration tasks could be accomplished using portal user interface, it’s much more convenient to configure gateway using ARM template. Gateway configuration can get really complex (with multiple backend pools, custom probes, and multiple sites) and it’s much easier to have an overview of entire configuration in one script. Also, updates to gateway could take a long time. It’s not unusual for AAG configuration update to run for 20-30 minutes! Now imagine that you need to update multiple settings in your gateway (like, for example, update expired SSL certificates on all of our sites). If you using portal, then you’ll have to update these settings one-by-one and wait for each change to be complete before making another one. With ARM template you can make all changes at once in the template (no matter how complex they are) and then deploy the template once.
4. ARM schema. Microsoft didn’t publish ARM schema for application gateway yet (at least not at the moment this post is being written), but there are plenty of examples of application gateway templates here: https://github.com/Azure/azure-quickstart-templates
5. Supported security protocols. Application gateway doesn’t support SSL 3.0 (or any previous versions), but it does support TLS 1.0, TLS 1.1 and TLS 1.2 by default. If you desire to turn off support for TLS 1.0 and TLS 1.1 (as considered to be less secure than TLS 1.2) then you’ll have to do this with PowerShell script. Protocol support options are not available in portal UI or in ARM templates at the moment. There is a script:
6. WAF doesn’t seem to be playing well with Traffic Manager. Azure Application Gateway also supports web application firewall (WAF) which is currently in preview mode. Maybe because it’s in preview mode, I had problems with it – WAF was blocking Azure Traffic Manager health monitoring traffic as being malformed (request was missing “accept” header). Not sure if it’s an issues with WAF or Traffic Manager.
7. Limit to a number of SSL certificates installed on gateway. AAG supports multi-site configuration and each site could have it’s own SSL certificate. However, I run into a problem where AAG deployment was failing once I added more than 12 certificates. Error message was really obscure, so I’m not 100% sure if the problem is with the number of certificates I was trying to install. However, once I limited myself with just 12 certificates, everything was deploying smoothly.
8. You may need to use custom health probes. Application gateway is using default health probes unless you specifying your custom probe. Default probe is periodically pinging you backend servers, executing HTTP GET request and it’s expecting to receive 2XX response. If your backend server is not set up to return 2XX code to HTTP GET / (root) which could happen, for example, if your web application is redirecting user from root to some other page (like Login page, for example), then you’ll need to specify a custom health probe.
9. Pay attention to health probe timeouts. Default health probe timeout is 30 seconds. If you application takes more than 30 seconds to respond then it wold be considered unhealthy. You may want to increase that timeout.
10. Pay attention to request timeouts. Default request timeouts are 30 seconds and that may be too short for some applications. If gateway is not receiving response from backend in 30 seconds then it would abort the HTTP request is return error 502 (bad gateway) to the caller. Request timeouts are configured in AAG Http Settings.