Tip #1 You don’t need Tenant Admin rights to add a new Site Collection App Catalog
I have seen many blogs, forum threads etc that state that only Global Tenant Administrators can add new Site Collection App Catalogs. The truth is that a SharePoint Admin rights are enough. The trick is to make that SharePoint Admin Account to a site collection administrator of the app catalog site. To be precise the account that adds a new SCAC must have Manage Web Permissions, as stated in error message:
Add-SPOSiteCollectionAppCatalog : Must have Manage Web Site permissions or be a tenant admin in order to add or remove sites from the site collection app catalog allow list
Tip #2 List all Site Collection App Catalogs
To list all the SCACs in your tenant navigate to that url:
Currently, it’s not possible to list all site collections in the tenant that have the site collection app catalog enabled.
The fun fact was that I sherlocked it since I knew my account needed access to the main App Catalog site. So there must be some information that is stored. How is it done a là SharePoint – yes, it is stored in a hidden list. Like in the olden days. 🧐
This is about a topic brought up by Waldek Mastykarz: Just because you can should you use the Office 365 CDN. In my post I want to take a closer look at the private CDN option in Office 365. Please note, the whole thing is subject to change, and it reflects the circumstances at the time of writing – 2019-08-26.
I use Modern Team Sites and Communication Sites. Is the Private Office 365 CDN something for me?
No, the urls are changing. You cannot “hardcode” them. Automatic URL Rewrite works only on classic Publishing Sites.
I have Provider Hosted Add-Ins. Is the Private Office 365 CDN something for me?
No, the referrer needs to be a subdomain of sharepoint.com.
The whole point of having a private CDN is that it is not available for strangers. But when you enable it, you’ll see an eligible warning:
WARNING: This is a feature built on a 3rd party application with privacy and compliance standards that differ from the commitments outlined by the Microsoft Office365 Trust Center. Any data cached through this service does not conform to the Microsoft Data Processing Terms (DPT) and is outside of the Microsoft Office365 Trust Center compliance boundaries.
If you remove an asset from the private cdn origins, it takes up to 15 minutes for the link to be invalidated. Opposed to an immediate effect for a direct link to an asset in a document library.
To keep it more secure, the default private cdn origins should not be included, especially */SITEASSETS, Because site assets can have important information, and this makes every single site assets library vulnerable, asterisk means all.
Even the CDN Policies should be restrictive.
Overall, if the usage area is small, the performance gain is little, we should not enable it at all. Because: any cached data in a private Office 365 CDN is outside of the Microsoft Office365 Trust Center compliance boundaries.
I have tried the private CDN. My setup was a document library with three versions of a picture that was 2,4MB that I put to three different libraries:
On the publishing site I inserted three images on a page and compared the load time in the DevTools. During this test I had Cache Disabled. I got following results:
private, public, nocdn
3.04s, 3.03s, 3.24s
1.78s, 1.77s, 1.75s
1.99s, 1,95s, 3.32s
1.67s, 0.73s, 0.72s
1.73s, 1.71s, 1.97s
1.60s, 1.58s, 1.67s
So only once I got a bigger difference, otherwise it took the same time to load a picture from a document library without CDN.
To be fair, it is a very simple performance test. Tests with bigger files, different geographical locations would probably give a more detailed view of that. And still, without a URL Rewrite that is only present on Publishing sites, you cannot take use private cdn origins.
Private CDN in Office 365 can be interesting in future, but today, the usage is narrow (only publishing sites can refer to assets in a private CDN), the performance gain is little and lower security makes it to a bad choice.
Yesterday I participated in the Hackathon at European SharePoin Conference in Stockholm. The main goal was to learn more about Office Add-Ins. I wanted to create a very very simple app to learn the basics. Here in this post I’ll provide some links and describe the steps needed to start developing your Office Add-Ins.
The Add-in I created is an Outlook Add-In, it is called “Joke Inserter” and with it you can insert a random Chuck Norris joke. It is just for fun, but it demonstrated how an add-in can be installed, made available in “New E-mail” and interact with the e-mail you are writing.
All the code is on github. The random jokes come from The Internet Chuck Norris Database. As I said, the jokes were just for fun, this add-in is of course, not a business app. During the hackathon I got help from Pretish Abraham, Jeremy Thake and …
This is the result:
Any OS, I happened to have Windows 🙂
git, nodejs, npm (they should be in the $env:PATH)
Install following npm packages globally:
npm install -g tsd yeoman generator-office gulp
Creating the Add-In
Now with the yeoman support it is very easy:
Create a folder and scaffold an app:
After that update the manifest file: Icon Url, and Support Url
We want to make an app available in SharePoint OnPrem, we want to onpremify it. Rethink SharePoint apps and provisioning SharePoint artifacts.
It has been a while since I updated my blog – Chuvash.eu. I had my vacation, I visited the sunny and green Chuvashia. Now I am back and I am looking forward to an awesome SharePoint Autumn. One of the first things I had to deal with in this SharePoint Autumn was Onpremifying of a SharePoint Online App. We have an app that has gained popularity and we want to make it available for SharePoint OnPrem. There is no such word Onpremify (yet?), I know, it is a Swenglish happy word making (onpremifiera), but I like the word “onpremify” a lot.
There is still uncertainty around the purpose of SharePoint apps. One app type, though, has been used a lot in our company: an app that provisions SharePoint Artifacts – that creates SharePoint Applications. What I mean by SharePoint Applications can be read in my blog post:
The successful app type creates SharePoint Applications – by provisioning needed SharePoint artifacts (Fields, Content Types, Lists, Page Layouts, Styles, Scripts, Web Parts, Pages…). Often it is a one time job: When the SharePoint application is provisioined, it is finished.
When you’re about to onpremify such an app, you have three main choices:
Install app in OnPrem. Requires the App Infrastructure in place and a separate build of the app (220.127.116.11 version)
Make a parallel version of the app using a farm solution (not good at all)
Invoke the provisioning code from a console app (I recommend this one)
The choice 1 might seem obvious, but not all companies have a functioning app infrastructure (a dedicated server for Provider Hosted apps, S2S Trust and Governance around it). The choice 2 splits your app into two variants and makes it hard to maintain.
On the other hand, the choice 3 might seem crazy, when you hear it for the first time. A Console App? But give it time, think about it. The idea comes from the awesome SharePoint Provisioning Library SPMeta2, where the Model (SharePoint Artifacts) and Executing are separated. Your model for Fields, Content Types, and Lists and so on, is an agnostic code based definition that can be used for SSOM and CSOM, for SharePoint 2013, SharePoint Online, SharePoint 2016 and SharePoint 2010. SPMeta2 eliminates the need for XML and wsp packages.
So my recommended approach for onpremifying SharePoint apps where the main goal is to provision SharePoint Applications is to move the provisioning code into a separate VS Project. The SharePoint App Project (mainly AppManifest.xml) remains the same, The App Web Project is made to a “stupid” interface that invokes the Provisioning Library. We also create a new interface – a Console App. You can replace the console app with a Windows Application, a Web Application, PowerShell Script, An admin page in Central Admin – whatever suits you. The Console app can be used not only in OnPrem, but also in SharePoint Online.
SPMeta2 vs. PnP vs. Own Framework
Every developer with Self-Respect uses a framework for provisioning SharePoint artifacts. It might be some own utilities or preferably public framework, because you don’t want to repeat yourself, especially in SharePoint. When SPMeta2 and PnP are available it is not smart to reinvent the wheel. I usually recommend to use one of them. I personally prefer SPMeta2 because… mainly because it is more complete and consistent. Read more about SPMeta2 vs. PnP comparison.
The blog post below describes the technical details about how Web Parts can be exported using a hidden tool in OOB SharePoint, though this requires manual assembling of a special url. If you are just interested in a solution for an easy Web Part Export function, just proceed directly to my new blog post where you can download my tool that you can add to your web browser.
Almost all web parts can be exported from a SharePoint page. An exported web part can be imported on another page or it can be used as a source in a module to provision pages. An exception is the XsltListViewWebPart, there you cannot enable exporting. I have used Glyn Clough’s method before which has worked although it is a complicated process. Now I have found another way for exporting any web part (even ListViewWebPart and XsltListViewWebPart) present on a page. A method that only involves a web browser.
How to export any web part
First, we need to find out the webpartid. To do so inspect the html markup with the web browser dev tools of your choice.
In SharePoint there is a hidden application page that exports web parts: /_vti_bin/exportwp.aspx. This page takes two query parameters:
pageurl. The absolute url of the page where the web part resides that you want to export
guidstring. The guid that is called webpartid in the markup on the page
Paste it into the web browser address bar and you’ll download an xml file with your web part definition. This method works in SharePoint 2010 and SharePoint 2013 and even in SharePoint Online (Office 365).
In this post I want to share an unusual, nevertheless interesting conceptual idea of loading content from SharePoint 2013 apps on many pages. The original awesome concept was proposed and developed by my colleague Martin Villysson at Bool.
The problem we are trying to solve
SharePoint apps are great to extend functionality in SharePoint and integrate other systems (full page apps available through Site Contents), they also provide tools to enrich the default SharePoint experience by App Parts (Client Web Parts) and Custom Actions (additional menus).
One of the biggest shortcomings of that model is the need to add app parts on all pages where it is needed. Let’s say, we want to have some app parts present on every single page in our whole SharePoint tenancy, to provide a consistent look and feel (e.g. navigation, notifications). Traditionally, on premises, we have added user controls in our customized master page. In SharePoint Online that is impossible. The complicated workaround is to add those client web parts (app parts) on every page, be it manually or by automating it (powershell or app). It will require updating all pages. Nevertheless, it will not work on Out-of-the-box application pages (pages from layouts folder). It becomes even more unacceptable when you realize that your app must be added as an app instance on every single site (SPWeb) in your tenancy.
Towards a solution
After we had created a working Proof-of-Concept of the AppLoader concept, I met Vesa Juvonen at the SharePoint Conference in Las Vegas and introduced this idea to him (although I didn’t call it AppLoader). He liked it although he pointed out that this TenantAppInfo.ashx is an internal utility only in SharePoint and it is not supported by Microsoft. That’s correct. There is even almost no information about it on the Internet. But I got a feeling of Microsoft that they are willing to hear feedback and improve the product. Vesa encouraged me also to blog about it. So now I am telling about this idea. I hope to hear feedback about it. Unfortunately I cannot share the source code of the working Proof-of-Concept solution.
AppLoader Concept in colors
The AppLoader Concept is quite simple. Look at this picture:
The steps in the AppLoader process:
Make an ajax request to TenantAppInfo.ashx using XHR (XmlHttpRequest)
Receive the app list
Reading what to render on the page
Usage and Limitations
This bright idea takes advantages from a huge SharePoint API (that contains a lot of good but not supported parts) to make using of apps in Client Application Model solutions more pragmatic and still provide a consistent design and behavior. By consistent design I mean same parts like additional navigation, notifications etc in the whole Intranet. The AppLoader renders and injects whatever you have rolled out to your whole tenancy (Tenant Scoped Apps) and that on every page (!). It also improves the perceived performance of the page load, because it renders app parts (iframes) after the main page has been loaded preventing freezing of the page.
There are of course some limitations in the AppLoader Concept. Today we cannot rely on the TenanAppInfo.ashx API (because it is not supported and future updates can break solutions). We have to define our own custom actions in the apps. That means we can only use our own apps, it will hardly work with the apps installed from the Office Store. On the other hand, your customer will not want to have generic apps from the Office Store to be a part of every page on their intranet.
You must configure a new name in Domain Name Services (DNS) to host the apps. To help improve security, the domain name should not be a subdomain of the domain that hosts the SharePoint sites. For example, if the SharePoint sites are at Contoso.com, consider ContosoApps.com instead of App.Contoso.com as the domain name.
Does it apply to SharePoint Online? Well, apparently not 🙂 So why should we do it on premises?
As we all know, sharepoint.com is used for our Office 365 tenancies and for apps.
Recently I had an exciting mail conversation with Thomas Deutsch. He came up with an idea how to fasten the development of apps. This smart approach is called “Provider Hosted First”. See Thomas’ original blog post. Here are some highlights:
What you actually do is a local website which runs in grunt server:
Then a SharePoint-hosted app is created with an SPAppIframe that refers to that local app site. Genious!!!
Some key features of this approach:
This local app contains a livereload script. Your sharepoint app is updated every time you save your css, js, html file in your IDE
Grunt minifies, bundles your assets
Grunt runs your tests automatically when your content is modified
The SharePoint app can be on Premises, on Office 365, wherever you want it.
See the video how it looks like to develop using this approach