Ask Learn
Preview
Ask Learn is an AI assistant that can answer questions, clarify concepts, and define terms using trusted Microsoft documentation.
Please sign in to use Ask Learn.
Sign inThis browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Now that the SharePoint 2016 is also arriving relatively soon, we are getting more and more questions around the on-premises setup around the SharePoint add-in/app model. Target of this blog post is to address some of the most common questions around the infrastructural setup for on-premises and to clarify what are the options from the infrastructure perspective. We will continue providing additional information for these topics also from MSDN based on community demand, which clearly is growing.
Let’s start with few common clarifications for top questions around hosting provider hosted environments in on-premises for SharePoint 2013 and SharePoint 2016
Provider hosted add-in environment is basically just a typical ASP.net web application hosting environment without any additional technical requirements. In fact, you do not need to use even Microsoft platform to make this work, since just as well your provider hosted environment could be hosted in Linux. Only difference between technical hosting environment is the requirements for actual add-in implementation. There are ready to use templates for Microsoft platform, so any other technical platform would require additional work for the developers.
I do understand that some of the above statement could need more additional information and we’ll address them more detailed in the future in blog posts either in dev.office.com or in MSDN guidance in general.
This is one of those questions which depends on numerous factors, like how many add-ins you are planning to host and who will operate or administer these add-ins. Some of the considerations for the overall architecture would be for example following.
As you can see from many of the above questions, this is more around the overall IT governance of your deployments and is highly dependent on the hosting model of these servers.
Let’s move to the actual meat of the blog post. Following chapters are clarifying the different models for the provider hosted environment architectures. These are relatively simple setups, but whole point is to reduce the confusion on supported models. Notice that especially in larger deployments you will see mixture of these models based on the types of provider hosted add-ins which are actually hosted in the environment.
In this model you are sharing same hardware for multiple different provider hosted add-ins. This is the most typical setup for on-premises SharePoint due the simplicity and cost efficiency. It basically means that you have few servers in high available mode hosting the needed provider hosted add-ins. Provider hosted add-ins are load balanced between servers and you are hosting multiple add-ins in same platform.
In this model you have dedicated servers for specific provider hosted add-in, meaning that provider hosted add-in has dedicated hardware to host them in the environment. This is really rarely used model, since typically there’s no performance or resource requirements for this kind of setup. This is relatively theoretical setup which could be used when you have really performance intensive operations performed in the provider hosted add-in.
In this model we have isolation in the server levels in a way that for example organizational add-ins are hosted in dedicated servers or that add-ins which are coming from specific provider are hosted in dedicated servers. This kind of setup is relatively typical when you want to isolate organization add-ins or alternatively add-ins which are managed or operated by specific providers or partners.
Techniques showed in this blog post are part of the Office 365 Developer Patterns and Practices guidance, which contains guidance and reusable solutions for demonstrating different patterns and practices related on the add-in/app model development for Office 365 and SharePoint on-premises.
Check the details around PnP from dev.office.com at https://aka.ms/OfficeDevPnP. Please join us on sharing patterns and practices for the community for the benefit of the community. If you have any questions, comments or feedback related on this sample, blog post or anything on PnP, please use the Office 365 Developer Patterns and Practices Yammer group at https://aka.ms/OfficeDevPnPYammer.
If you are interested on using above graphics in your presentations, they are included in the PnP presentation graphics deck available from Office 365 Dev PnP section at docs.com. Feel free to re-use these graphics anyway you want in your own presentations.
“Sharing is caring”
Anonymous
December 07, 2015
You mention that you do not need a wildcard domain for SP Hosted Add-Ins. I consult for the federal Government. They really don't like wildcard certs. So, I've been tasked with researching how to setup SharePoint Hosted Add-Ins without a wildcard cert. Every article we find from MS says you need one. We even brought MS (from our premier support) and they said we need one. I was wondering if you can point us to any article or anything from Microsoft that shows how to setup SP Hosted Add-Ins, in an https environment, without wildcard certs? Thanks in advance.
Anonymous
December 08, 2015
Greg,
The wildcard domain is a mechanism to allow for the routing of requests to the PHA environment (or indeed SPH Apps). This is entirely separate from a wildcard certificate used to secure that traffic.
You cannot practically implement SPH Apps without a wildcard certificate because due to the approach for addressing, as one cannot know the address of the apps before they are provisioned. As the Common name of the certificate must match the url of the request, a wildcard cert is the only practical approach. Technically it is possible not not use wildcards, but that then means you need a certificate for each app - that is possible to configure but it is a huge and unworkable management overhead and thus it is not something that is likely to ever be documented.
This requirement really should be considered a fundamental flaw in the design of SPH. But it is (sadly) what it is.
hth.
Spence - www.harbar.net
Anonymous
December 08, 2015
How to interpret the following sentence: "You do not need to have app web with provider hosted add-ins and in provider hosted add-ins it really not the right model anyway due numerous reasons." ?
Even in PnP there are samples which require an add-in web (like people picker or taxonomy picker). How should cases like these solved without an add-in web?
Anonymous
December 10, 2015
"You can use exactly the same code in both on-premises and in cloud." Does that mean i can use the SharePoint online client sdk assemblies to target onprem when 2016 is out? So i can use the exactly same app that i wrote for SPO to run onprem using the low-trust model? Or do i have to change the assemblies and use the onprem assemblies for my solution?
Anonymous
December 18, 2015
"How to interpret the following sentence: "You do not need to have app web with provider hosted add-ins and in provider hosted add-ins it really not the right model anyway due numerous reasons." ? "
Also interesting what does that mean?
Anonymous
December 22, 2015
The comment has been removed
Anonymous
December 22, 2015
The comment has been removed
Anonymous
January 12, 2016
The comment has been removed
Anonymous
January 28, 2016
Hi Oliver.
technically you can use newer CSOM in older version. SP2016 is using CSOM 16.0 version and SPO is using 16.1 version. There are small differences between the capabilities, but as long as you do not call an API which does not exist in the on-premises, this does work fine. So - technically you could use the exact same version of the add-in without re-compiling between different environments.
Anonymous
February 08, 2016
The comment has been removed
Anonymous
March 04, 2016
In the beginning of SP2013 there was a misunderstanding: contoso.com would use "a completely different domain name - contoso-apps.com. What you are saying in this post, makes more sense. I agree that using spapps.contoso.com (still having "contoso.com") is better. I have seen many companies who really invested in additional second-level domains, like company-apps.com, theappsdomain.com and so on. Thank you for clarifications, Vesa, they will be useful in my work.
Anonymous
April 01, 2017
Hi Vesa,If it is the recommended way to host multiple Add-ins in a single App Web ?Thanks,MsSPJ
Ask Learn is an AI assistant that can answer questions, clarify concepts, and define terms using trusted Microsoft documentation.
Please sign in to use Ask Learn.
Sign in