NotAllAboutCode

Once you setup the service in Azure and add all your APIs, you should make sure you have a good Backup strategy in place, in case things go wrong. If you do regularly backup the service, then you can also use those backups for a couple of purposes: you can for example deploy more than one instance and put a Traffic Manager in front of them, in order to handle geographical distribution . But you can also restore a specific backup to a different Subscription , and create a separate environment, as per the DTAP street . Azure API Managemen t provides a REST API that you can use to automate things; unfortunately that works for most features and activities, but not for backing up and restoring the whole service. For this you need to use the good "old" ARM , which also provides a REST API with specififc API Management operations. By reading the article above, you might think that this is as easy as getting a token , backing up and restoring the service... Well,

Here's a diagram to show what are the main components involved in an Azure AppService deployment and configuration, between the actual application and the Azure Active Directory setup. For those not familiar with Azure, it can get confusing between the concepts of Directory , Tenant , Subscription , and all the sub-components that need to be properly configured when deploying to Azure . Hopefully this high-level diagram can clarify a bit more. A few notes: you can create several Tenants under a single Directory . you can use Azure Active Directory in any Tenant (not necessarily the one where the application is deployed). you can use the basic Azure Active Directory authentication and authorization features for free (without a Subscription attached to it), but as soon as you need advanced features (let's say MFA ), then you need to buy one of the AAD Premium plans. You do need a Subscription for deployment of apps in this setup, a SSL Certificate is

So here's another rant about Microsoft inconsistency and UN-usability of their products (sorry but I cannot hold this anymore).. Since it's been introduced years ago, Microsoft Powershell looked very promising, with its CMDLet approach to reuse scripts, not only for sysadmin tasks, but for almost everything Microsoft . There is only one problem with it (still nowadays): inconsistency . The reason why I say this, is because most of the times (I am serious, most of them) I try to use Powershell , I get the famous error message: The term '[ Put your Powershell Module name here]' is not recognized as the name of a cmdlet, function, script file, or operable program. That seems like a trivial error, so the next thing to do is to install the missing module. This generally requires a few steps: Figure out which module contains the command you are trying to run (not always straightforward). Figure out which version of the module contains the exact comman

I mentioned before about the Azure and Microsoft Graph APIs , and the fact that Microsoft recommends to use the latter one. In fact, every page of documentation related to the Azure Graph API contains this disclaimer: We strongly recommend that you use  Microsoft Graph   instead of Azure AD Graph API to access Azure Active Directory resources. Our development efforts are now concentrated on Microsoft Graph and no further enhancements are planned for Azure AD Graph API. There are a very limited number of scenarios for which Azure AD Graph API might still be appropriate; for more information, see the  Microsoft Graph or the Azure AD Graph I can see this disclaimer in articles dated back as much as June 2017. Still, as of now ( February 2018 ), the Microsoft Graph API only supports a tiny bunch of operations in its official version 1.0 , and a few more in its beta version , while most of the operations that are supported on the Azure Graph API (soo ma