Why SharePoint Can't Be Hosted on Azure App Service?

I've been working with SharePoint in more than half of my entire career since SharePoint 2003, that is now after the Online version is getting more recognized by organizations, sometimes we get questions from those who are very much expert in the on-premises version but unaware of the features of Online one. This is understandable because some organizations still want to keep their data on-premises and possibly not ready to move to the cloud becoming unaware of Microsoft cloud environment.

Now, a question in particular was about whether or not SharePoint can be migrated to Azure App Service, and if not, is there any particular documentation from Microsoft that clearly states that it can't be done.

This post hope to help anyone trying to understand why it can’t be done, in my personal opinion.

I did my little research - which I know it can't be done - to find any explicit statement from Microsoft docs that says so. Unfortunately, as I thought before, I couldn't find any. Or maybe somewhere under the rock. Okay, so I have to explain on what is Azure App Service and what are needed in order to run SharePoint any where.

In a nutshell, SharePoint can’t run on Azure App Service because of the complex services it serves, as most of these services aren’t just simply HTTP just like a web application/web service.

Azure App Service essentially is exactly the same like your typical web application sitting in your IIS in Windows Server or Apache in Linux. It serves files stored under IIS folder such as HTML, JavaScript, or compiled .NET code as DLL to be served via HTTP/S protocol. From the infrastructure perspective, Azure App Service basically same like your Windows Server, or Linux. One big advantage of using the App Service is that you don’t need to care the server configuration, setting up join domain, authentication provider, ports, so you can focus on building the application you like and serve it directly. Just like staying in a hotel, you just come, pay, and lie down literally.

Of course come to the disadvantage, you can’t roam freely to the kitchen where the chefs work, you can’t force the hotel appearance and ambience you like, or sleeping in the reception area much like your living room, much towards altering the entire hotel itself. App Service doesn’t allow you to install Window Service, dictate how many IIS sites you need to add, or connect to other servers you want. Your space is only that little tiny folder assigned to you via Azure App Service.

To take on the same analogy, SharePoint on the other hand, is not just you moving in but also your furniture, electronics, appliances, cupboard, and kitchen area that has a very specific requirements to operate it.

For instance, SharePoint User Profiles that is used to crawl users in your Active Directory, Timer Jobs that runs essential scheduled job for SharePoint, not to mention SharePoint Search to crawl the content of this SharePoint. These are under Window Service and served via particular ports and consumed by other SharePoint servers in the same farm.

For SharePoint SQL Server database however, you have the option to use Azure SQL Managed Instance (MI), with caveats. Forget about Azure SQL MI if your SharePoint farm was configured using Windows Authentication, but you can if it’s SQL Authentication. I saw some articles too that you can convert SharePoint database from Windows authentication to SQL, but let’s not talk about this for now.

What’s feasible then if you ask? SharePoint on Azure is the answer, not via App Service but the traditional Virtual Machine (VM). Lift and shift, load your existing VM to Azure (require downtime), then set your networking properly and make sure the servers can communicate each other, and ensure connection to Domain Controller is also established.

With this explanation, you will not get any complain from the hotel for bringing your own fridge and kitchen appliances down to hotel because you can’t do so. 😉

References:

https://docs.microsoft.com/en-us/sharepoint/administration/sharepoint-server-in-microsoft-azure

https://azure.microsoft.com/en-us/services/app-service/#overview

https://docs.microsoft.com/en-us/sharepoint/install/hardware-and-software-requirements-2019

Top 4 Fundamental Knowledge To Master Power Automate

Now you want to learn Power Automate but you have no idea where to start? Below are the keys to mastering Power Automate in no time!

You can go to Microsoft Learn to take on self-paced courses on dealing with Power Automate in Get started with Power Automate - Learn | Microsoft Docs. But before that, here are the top 4 fundamental topics you need to master before jumping into Power Automate.

1. JSON

JSON, short for JavaScript Object Notation, is merely a lightweight data transportation format. Quoted from json.org, JSON is easy for humans to read and write. Mainly because the data structure is simple but can fit into different types of data. Imagine JSON is water, very fluid, and can fit into many different containers. The entire IT standards are now revolving around JSON as the format of the data transportation from one system to another.

In Power Automate, JSON plays a crucial element when coming to developing a system. Often we face an error while developing and it's important to pinpoint the core of the issue before we take action to fix it.

Power Automate, even the entire suite of Microsoft Azure products and Office 365, were built around JSON as the data payload. Calling a SharePoint site with API, getting data from Dataverse, and even working with NoSQL databases such as CosmosDB, they're using JSON. Below is an example.

{
  "glossary": {
    "title": "example glossary",
    "GlossDiv": {
      "title": "S",
      "GlossList": {
        "GlossEntry": {
          "ID": "SGML",
          "SortAs": "SGML",
          "GlossTerm": "Standard Generalized Markup Language",
          "Acronym": "SGML",
          "Abbrev": "ISO 8879:1986",
          "GlossDef": {
            "para": "A meta-markup language, used to create markup languages such as DocBook.",
            "GlossSeeAlso": [
              "GML",
              "XML"
            ]
          },
          "GlossSee": "markup"
        }
      }
    }
  }
}

My only reference for learning about JSON is from json.org.

2. Expression

You must also learn how to make Power Automate expression, which is essentially a code you call to get the value you want in every part of Power Automate. If you already know Power Automate, oftentimes you get data directly from the Dynamic content just like below.

But here's a secret, NOT ALL data are presented in the dynamic content. You sometimes have to run the flow to get the precedent actions/trigger data presented in JSON format, and then consume it.

  triggerOutputs()['headers']['x-ms-user-name-encoded']
  

The example above is the code for getting data from the Power Automate trigger, of the username in encoded format.

What if you want to check if the trigger came from a specific IP address that is stored in X-Forwarded-For header? Well, it's the same process.

  triggerOutputs()['headers']['X-Forwarded-For']
  

Now, what if you want to get a value that sometimes exists, but another time doesn't? Just put a question mark in between.

  triggerOutputs()['headers']?['X-Forwarded-For']
  

By giving a question mark, your code will not turn into an error if in the future X-Forwarded-For is not always there, the value returned will be null or empty.

3. OData

Now you know the data is transported using JSON format, how did it get transported? Some systems - if not, every system nowadays - are transported via an API, essentially a web service that you can call using a specific URL. OData itself is a standard most organizations follow including Microsoft, to build RESTful API.

SharePoint Online and Microsoft Dataverse use OData standards to communicate or get the data. This includes all administrative tasks such as get site collection, get environment (of Dataverse), and even the underlying Power Automate designer tool when you are working also uses OData standards. You can try pressing F12 in your browser, open up a Power Automate designer, and see it under the Network tab. That's a whole bunch of OData.

What makes OData unique is the ability to select, filter, expand, and sort, and of course it all depends on whether the vendor conforms to the OData standard. My go-to place to learn about OData is always SharePoint Online, with the reference from Get to know the SharePoint REST service | Microsoft Docs. If you don't have one, you can create an Office 365 Developer tenant via this link Developer Program | Microsoft 365 Dev Center.

Now, you can use Chrome or Edge (whichever you like), and install ModHeader - Chrome Web Store (google.com). This tool helps you to send an HTTP Web Request header along with your URL query. You need this tool because SharePoint Online uses XML to transport the data.

Set the request header just like above, and you're good to go.

4. HTTP Web Request

Knowing the concept of HTTP Web Request is also crucial to better understand how things work in Power Automate. Every single action in Power Automate is essentially a block that will run HTTP Web Request depending on how it was developed.

Most importantly, the concept of different types of requests, to understand how to set a setting of your HTTP Web Request in the Request Header or Body, to retrieve the data you want according you your specification.