Azure: ExpressRoute

ExpressRoute is a service that enables you to create private connections between Azure datacenters and infrastructure that’s on your premises or in a colocation environment. ExpressRoute connections don't go over the public internet, and offer more reliability, faster speeds, lower latencies, and higher security than typical connections over the internet.

Ref: https://azure.microsoft.com/en-us/pricing/details/expressroute/

Azure: ASP.NET Session State Provider for Azure Redis Cache

Azure Redis Cache provides a session state provider that you can use to store your session state in-memory with Redis Cache instead of a SQL Server database. To use the caching session state provider, first configure your cache, and then configure your ASP.NET application for cache using the Redis Cache Session State NuGet package.

It's often not practical in a real-world cloud app to avoid storing some form of state for a user session, but some approaches impact performance and scalability more than others. If you have to store state, the best solution is to keep the amount of state small and store it in cookies. If that isn't feasible, the next best solution is to use ASP.NET session state with a provider for distributed, in-memory cache. The worst solution from a performance and scalability standpoint is to use a database backed session state provider. This topic provides guidance on using the ASP.NET Session State Provider for Azure Redis Cache. For information on other session state options, see ASP.NET Session State options.

Store ASP.NET session state in the cache

To configure a client application in Visual Studio using the Redis Cache Session State NuGet package, click NuGet Package Manager, Package Manager Console from the Tools menu.

Run the following command from the Package Manager Console window.

Install-Package Microsoft.Web.RedisSessionStateProvider

 Important

If you are using the clustering feature from the premium tier, you must use RedisSessionStateProvider 2.0.1 or higher or an exception is thrown. Moving to 2.0.1 or higher is a breaking change; for more information, see v2.0.0 Breaking Change Details. At the time of this article update, the current version of this package is 2.2.3.

The Redis Session State Provider NuGet package has a dependency on the StackExchange.Redis.StrongName package. If the StackExchange.Redis.StrongName package is not present in your project, it is installed.

 Note

In addition to the strong-named StackExchange.Redis.StrongName package, there is also the StackExchange.Redis non-strong-named version. If your project is using the non-strong-named StackExchange.Redis version you must uninstall it, otherwise you get naming conflicts in your project. For more information about these packages, see Configure .NET cache clients.

The NuGet package downloads and adds the required assembly references and adds the following section into your web.config file. This section contains the required configuration for your ASP.NET application to use the Redis Cache Session State Provider.

XML

<sessionState mode="Custom" customProvider="MySessionStateStore">
  <providers>
    <!-- Either use 'connectionString' OR 'settingsClassName' and 'settingsMethodName' OR use 'host','port','accessKey','ssl','connectionTimeoutInMilliseconds' and 'operationTimeoutInMilliseconds'. -->
    <!-- 'throwOnError','retryTimeoutInMilliseconds','databaseId' and 'applicationName' can be used with both options. -->
    <!--
      <add name="MySessionStateStore" 
        host = "127.0.0.1" [String]
        port = "" [number]
        accessKey = "" [String]
        ssl = "false" [true|false]
        throwOnError = "true" [true|false]
        retryTimeoutInMilliseconds = "5000" [number]
        databaseId = "0" [number]
        applicationName = "" [String]
        connectionTimeoutInMilliseconds = "5000" [number]
        operationTimeoutInMilliseconds = "1000" [number]
        connectionString = "<Valid StackExchange.Redis connection string>" [String]
        settingsClassName = "<Assembly qualified class name that contains settings method specified below. Which basically return 'connectionString' value>" [String]
        settingsMethodName = "<Settings method should be defined in settingsClass. It should be public, static, does not take any parameters and should have a return type of 'String', which is basically 'connectionString' value.>" [String]
        loggingClassName = "<Assembly qualified class name that contains logging method specified below>" [String]
        loggingMethodName = "<Logging method should be defined in loggingClass. It should be public, static, does not take any parameters and should have a return type of System.IO.TextWriter.>" [String]
        redisSerializerType = "<Assembly qualified class name that implements Microsoft.Web.Redis.ISerializer>" [String]
      />
    -->
    <add name="MySessionStateStore" type="Microsoft.Web.Redis.RedisSessionStateProvider"
         host=""
         accessKey=""
         ssl="true" />
</sessionState>

The commented section provides an example of the attributes and sample settings for each attribute.

Configure the attributes with the values from your cache blade in the Microsoft Azure portal, and configure the other values as desired. For instructions on accessing your cache properties, see Configure Redis cache settings.

• host – specify your cache endpoint.
• port – use either your non-SSL port or your SSL port, depending on the ssl settings.
• accessKey – use either the primary or secondary key for your cache.
• ssl – true if you want to secure cache/client communications with ssl; otherwise false. Be sure to specify the correct port.
  • The non-SSL port is disabled by default for new caches. Specify true for this setting to use the SSL port. For more information about enabling the non-SSL port, see the Access Portssection in the Configure a cache topic.
• throwOnError – true if you want an exception to be thrown if there is a failure, or false if you want the operation to fail silently. You can check for a failure by checking the static Microsoft.Web.Redis.RedisSessionStateProvider.LastException property. The default is true.
• retryTimeoutInMilliseconds – Operations that fail are retried during this interval, specified in milliseconds. The first retry occurs after 20 milliseconds, and then retries occur every second until the retryTimeoutInMilliseconds interval expires. Immediately after this interval, the operation is retried one final time. If the operation still fails, the exception is thrown back to the caller, depending on the throwOnError setting. The default value is 0, which means no retries.
• databaseId – Specifies which database to use for cache output data. If not specified, the default value of 0 is used.
• applicationName – Keys are stored in redis as {<Application Name>_<Session ID>}_Data. This naming scheme enables multiple applications to share the same Redis instance. This parameter is optional and if you do not provide it a default value is used.
• connectionTimeoutInMilliseconds – This setting allows you to override the connectTimeout setting in the StackExchange.Redis client. If not specified, the default connectTimeout setting of 5000 is used. For more information, see StackExchange.Redis configuration model.
• operationTimeoutInMilliseconds – This setting allows you to override the syncTimeout setting in the StackExchange.Redis client. If not specified, the default syncTimeout setting of 1000 is used. For more information, see StackExchange.Redis configuration model.
• redisSerializerType - This setting allows you to specify custom serialization of session content that is sent to Redis. The type specified must implement Microsoft.Web.Redis.ISerializerand must declare public parameterless constructor. By defaultSystem.Runtime.Serialization.Formatters.Binary.BinaryFormatter is used.

For more information about these properties, see the original blog post announcement at Announcing ASP.NET Session State Provider for Redis.

Don’t forget to comment out the standard InProc session state provider section in your web.config.

XML

<!-- <sessionState mode="InProc"
     customProvider="DefaultSessionProvider">
     <providers>
        <add name="DefaultSessionProvider"
              type="System.Web.Providers.DefaultSessionStateProvider,
                    System.Web.Providers, Version=1.0.0.0, Culture=neutral,
                    PublicKeyToken=31bf3856ad364e35"
              connectionStringName="DefaultConnection" />
      </providers>
</sessionState> -->

Once these steps are performed, your application is configured to use the Redis Cache Session State Provider. When you use session state in your application, it is stored in an Azure Redis Cache instance.

 Important

Data stored in the cache must be serializable, unlike the data that can be stored in the default in-memory ASP.NET Session State Provider. When the Session State Provider for Redis is used, be sure that the data types that are being stored in session state are serializable.

ASP.NET Session State options

• In Memory Session State Provider - This provider stores the Session State in memory. The benefit of using this provider is it is simple and fast. However you cannot scale your Web Apps if you are using in memory provider since it is not distributed.
• Sql Server Session State Provider - This provider stores the Session State in Sql Server. Use this provider if you want to store the Session state in persistent storage. You can scale your Web App but using Sql Server for Session has a performance impact on your Web App. You can also use this provider with an In-Memory OLTP configuration to help improve performance.
• Distributed In Memory Session State Provider such as Redis Cache Session State Provider - This provider gives you the best of both worlds. Your Web App can have a simple, fast, and scalable Session State Provider. Because this provider stores the Session state in a Cache, your app has to take in consideration all the characteristics associated when talking to a Distributed In Memory Cache, such as transient network failures. For best practices on using Cache, see Caching guidance from Microsoft Patterns & Practices Azure Cloud Application Design and Implementation Guidance.

For more information about session state and other best practices, see Web Development Best Practices (Building Real-World Cloud Apps with Azure).

Ref: https://docs.microsoft.com/en-us/azure/app-service/app-service-mobile-how-to-configure-active-directory-authentication

AZURE: Migration checklist when moving to Azure App Service

I have been continuously getting requests from customers, colleagues and partners around what to consider when migrating applications to Azure PaaS service but more specifically to the App Service.

This post tries to cover the majority of those cases and aims to provide a checklist and ready reckoner for customers/partners intending to migrate their existing applications to Azure App Service.

To start, let’s have a look at various considerations before you consider migrating your applications to Azure App Service

• Port Bindings - Azure App Service support port 80 for http and port 443 for HTTPS traffic. If you have sites using any other port after migration to Azure App Service, do remember that these are the only ports that will be used.
• Usage of assemblies in the GAC (Global Assembly Cache)- This is not supported. Consider bin placing the assemblies in the local bin.
• IIS5 Compatibility Mode- IIS5 Compatibility Mode is not supported. In Azure App Service each Web App and all the applications under it run in the same worker process with a specific set of application pool settings.
• IIS7+ Schema Compliance- One or more elements and/or attributes are being used which are not defined in Azure App Service IIS schema. Consider using XDT transforms.
• Single Application Pool Per Site- In Azure App Service each Web App and all the applications under it, run in the same application pool. In case you have applications with different application pool in IIS, consider establishing a single application pool with common settings or creating a separate Web App for each application.
• COM and COM+ components- Azure App Service does not allow the registration of COM components on the platform. If your site(s) or application(s) make use of any COM components, these would need to be rewritten in managed code and deployed with the site or application.
• ISAPI Extensions- Azure App Service can support the use of ISAPI Extensions, however, the DLL(s) need to be deployed with your site and registered via the web.config.

Once the above limitations have been taken into consideration, you will need to migrate your applications. The easiest form of migrating is through Azure App Service Migration Assistant. The Azure App Service Migration site and the tool can be utilized to migrate sites from Windows and Linux web servers to Azure App Service. As part of the migration the tool, this will create Web Apps and databases on Azure and publish content and publish your database.

This tool is available for both Windows server and Linux servers. The migration tool for Windows Server works either from the local machine or from a remote machine. It allows you to migrate sites from IIS running on Windows Server 2003 onwards.

Please refer to Windows Site Migration Tool for details.

The Linux site migration tool allows you to migrate sites from Linux web servers running Apache to the cloud. Only Apache is supported at this point in time.

Please refer to Linux Site Migration Tool for details.

Once you have decided to migrate, the following areas need to be considered for migrating applications to Azure App Service.

• On-premises integration - In case your applications are communicating with other applications which will not be migrated to Azure, you have to consider how the communication will happen when your application moves to Cloud. One solution is to enable the other application to communicate over the internet using REST. This may require changes in both the applications, not to mention the additional risk of exposing the server onto internet. Another approach would be to establish a secure connectivity to your on-premises server from Azure App Service, where your application is hosted. This can be done in any of the following ways depending on your requirement – Deploying your apps in an App Service Environment using an Isolated App Service Plan; enabling VNET integration with an Azure VNet , establish a Site to Site VPN between this Azure VNET and on-premises, and then enable routes between your App Service and the on-premises VM; and establishing hybrid connections. A detailed comparison of all the approaches would warrant a separate blog post.
• Authentication – When on-premises, you could be okay with no-authentication or windows authentication as there was mutual trust with AD. When you migrate to Azure you will need to enable authentication with Azure Active Directory. This means modifying some of your configuration to be able to authenticate your users via Azure AD. Complete details here on our documentation site.
• Session State – In an ideal case, you can make your application stateless in order to scale/switch at will. In case it is not possible, please have your session state configured to be persisted in Azure Redis Cache.
• File Persistence – Usually, websites might have a need for uploading files that need to be persisted. On Azure App Service, it is recommended to persist any files outside of the App Service into say something like a blob store. Modify the application to now use either the Azure Storage SDK or the REST APIs for saving and accessing files.
• App Settings/Connection Strings – There will be App Settings and Connection Strings that will change based on environment, whereas there will be somethings that will stay same. For the ones that change based on environment, also define them on the portal/template so that they can be overridden for different deployment slots.
• Logging –  If your logging framework is logging to files saved locally you will need to update them to either log it to Azure Diagnostics, or to a centralized blob store. You can also include Azure App Insights to get deeper insights into how your application is performing.
• Certificates – Certificates are not migrated directly. You will need to explicitly upload your certificates to be able to work on Azure. Details here in Bind SSL Certificate documentation. You can also purchase certificates directly from Azure. Details here in buy SSL cert documentation.
• Custom Domains – Custom domains can be associated to Azure Web Apps via a CNAME record change. You also need to update App Service to validate the DNS. Details here in map custom domain documentation.
• Email – Sending Emails requires an SMTP server. App Service does not provide you with the same and there is no way that you can configure it within App Service. While you can setup a SMTP server to send emails on Azure IaaS VMs, we do put in restrictions. We recommend using relay services to send email – ex: Office 365.
• LDAP Queries – In case you are building internal applications that are querying your LDAP store such as AD, those may not work on Azure App Service. Specifically, in case of Active Directory you can move AD to Azure AD and then use the graph APIs to make the necessary queries to Azure. For this, you will need to register your application with Azure AD to permit querying Directory Objects. Complete list of graph APIs are here.
• Shared/Linked Database queries - An application that has multiple databases needs to be given additional thought. If there are cross database queries, we will need to move the databases to Elastic Pools and then use Elastic Queries to query across the databases. If there is a linked database inside your database statements then this will not be permitted on Azure. This may require a re-architecture of the solution to avoid linked database queries.
• SQL Server features -  There are a number of server level features that are not supported on Azure SQL Database. There is a limited preview of SQL Managed Instance, but until then you may have to consider the following
  • SQL Agents – We see a number of databases having SQL Agents that would perform certain scheduled activities. Some functionality of this can be implemented via Elastic Jobs. For the remaining part, you would need to setup Web Jobs and/or Azure Functions.
  • SSIS – You can either go ahead and deploy SSIS on VMs or use Azure Data Factory to load/migrate data.
  • SSRS – You can deploy SSRS on VMs, use customized reporting in your application or use Power BI to generate intuitive reports.
  • SSAS – SSAS is available as a separate service called Azure Analysis Services.

Do note that all of the above solutions will require connecting to the Azure SQL Database over public DNS. You can ensure that the necessary sources are explicitly allowed connections via SQL Firewall.

• SQL Firewall – This is often overlooked, but you should provide explicit IP that will connect to the Azure SQL Database to enable connectivity. This includes client IPs that will manage using SSMS as well as Azure App Service.

Ref:https://azure.microsoft.com/en-us/blog/migration-checklist-when-moving-to-azure-app-service/