Contents tagged with SharePoint Online
Today, Mr Vesa, announced the availability of the (long awaited) CDN features for SharePoint Online. The SharePoint Online CDN features allows you to turn one or more libraries in your SharePoint tenant into a repository for assets that you want to store in a CDN for performance reasons and geo-distribution reasons.
How to set things up
I'm not going to rehash everything that is outlined in the announcement post, but rather highlight a few important things.
To get started and turn one of your libraries into a CDN enabled library you need to install the latest SharePoint Online PowerShell cmdlets to get access to some new and updated PowerShell cmdlets. Once you have that all you need to do is first enable it on your tenant and then add libraries for cdnization:
$creds = Get-Credential Connect-SPOService -Url https://contoso-admin.sharepoint.com -Credential $creds Set-SPOTenant -PublicCdnEnabled $true
Once this is done then you choose what libraries to use as the source for your CDN. You can point directly to a library or a subfolder in a library.
New-SPOPublicCdnOrigin -Url https://contoso.sharepoint.com/SiteAssets/
When you do this you get a big and yellow warning stating that everything you add in this folder from now on will be pushed to the CDN, and that CDN is publicly available and not governed by all the nice policies we have in Office 365. So, don't put your annual report drafts in there!
Note, it might take a few minutes until it is all ready for usage after adding or changing the origins. 15-20 minutes is not uncommon.
You can always retrieve all your CDN origins by using the following command:
This command will list the ID of each CDN origin as well as the origin. The ID is very important, because you need that when you construct the URL to the CDN. It's probably one or more Guids in that ID…
How to access the files in the CDN
To get access to the files in the CDN you need to construct a path using the ID for the CDN origin like this:
Yes, it's a bit long but that's how it is.
If you now try to access an image or script in this CDN by just typing the URL in the browser, you will get an error stating "Invalid referer". This is by design and you need to add a HTTP Header to see the image/script, the Referer header with the value of the URL of your tenant (see announcement blog). In cases where you embed the image in a page or load the script from a page, this is done automatically for you by the browser. An even easier way is to just create a page and insert a Picture from Address, and paste your CDN Url.
There's a couple of caveats to the CDN as of now.
One thing I had hoped was that you could use image renditions in combination with this, which would have been AWESOME. Nope, you can't. Vesa, can you add that to the todo list?
[Update 2016-09-29] The image renditions are partly supported, you can now use width, height and cropMode (fit for instance) as query string parameters for the image. But not RenditionId - once that can be done this feature is rock solid!
[Update 2016-09-29] CORS support has been enabled! Thanks you to the product group for fast and quick turnaround for these kind of features!
Another quite important thing is that the CDN isn't CORS enabled. They do a check for the referer, see above, so that the request are coming from the correct tenant. But if you try to use jQuery or some other mechanism to load scripts or assets from the CDN location you get No 'Access-Control-Allow-Origin' header is present on the
requested resource. Origin 'https://tenant.sharepoint.com' is
therefore not allowed access.
The response had HTTP status code 406.
I wish they added the possibility to allow CORS requests from the tenant, just as they only allow request refering from the tenant.
I think this feature is awesome and I have already upgraded a few tenants and customers to use this new feature for some embedded resources. Oh, did I say this is free of charge and a part of your Office 365 subscription. Free beer is good beer, despite in preview!
Today is the day many of us have been waiting for since the big SharePoint event at May the 4th. The highly anticipated SharePoint Framework (SPFx) is here and announced in at the SharePointFest, in this blog post, as well as in the new Github repo for SharePoint. Personally I've been waiting for this even longer after being involved by the product team to give early feedback and also attending the first top secret DevKitchen "hackathons" where we could try out very early bits.
The first release of many to come…
This is the initial public preview release, officially christened the SharePoint Framework Developer Preview, is a beta, maybe an alpha, of the SharePoint Framework. This is by no means something you should use or deploy to production. Things will change! Period. There are several known issues at the moment and some of them will likely incur breaking changes. But please, build stuff and give feedback to the product team, use the Issues feature in the Github repo.
This initial release focuses on client-side Web Parts which can, once released, be used in you classic SharePoint sites and pages as well as in the new modern user experience that is slowly being rolled out throughout the suite. As some of you know, I've spent quite some time on Web Parts and written a book on the topic, so this is something that gets me really excited.
How and where to get it!
All you need to do to get your hands on it is to follow the instructions on the Github repo. I'm sure we'll see tens and hundreds of blog posts on how to do it, but I recommend you to follow the one in the repo to start with. And, if you can't follow it, create an issue, make a pull request with an update - make sure we get good official documentation! Heck, I'm pretty sure I will write a couple of posts on the topic, but I will also continue to provide feedback on the framework and the documentation.
You will find samples, documentation and all you need in a set of brand new repositories in Github, also under a brand user/organization called…SharePoint (yes, no more generic Office dev, SharePoint is back!).
- SharePoint organization at Github, the main source for all your SharePoint Framework details - https://github.com/SharePoint
- SharePoint Framework documentation
- SharePoint Framework API documentation
- Office UI Fabric - the React edition
Need to know more?
Keep the conversation going on Twitter, SharePoint Stack Overflow, the new Office 365 Community network and other social media, and do use the #SPFx hashtag. I'll try to hang around at the SharePoint Stack Overflow as much as possible, since that is the best platform of the above mentioned ones.
I've previously written a Q&A on SharePoint Framework and will continue to update that post with details and changes in the current preview release.
Now, go, build something awesome!
Here's one of these real life stories that caused some headache for quite some time but was in the end very easy to resolve. I'll write it down and hopefully some of the search engines pick it up and help some other poor soul out there.
We have a solution that uses publishing pages to manage news articles and information pages in SharePoint Online. These articles and pages have a custom page layout with a custom content type, so they look decent and have proper metadata. They are all deployed using the PnP PowerShell cmdlets.
Creation of pages worked flawless and the rendered nicely. They page layouts use jQuery, some Office Fabric components (including those nasty jQuery scripts for that).
So far so good!
We wanted to roll up this News articles through a custom Web Part based on a search criteria, and also show some of that metadata, such as News category, rollup image and more. But the pages was not indexed. First thought was that well, indexing in SharePoint Online usually takes everything from a couple of minutes to a couple of days, so just wait. Then summer vacation came - I'm not complaining - and when i got back we had index. Ok, good. But then I started adding some custom managed properties to the rollup feature and was waiting for it to pick up the changes. I clicked re-index the libraries, I clicked re-index the site, added new pages and articles, I might even sacrificed the cutest little kitten you can imagine - but nothing. The pages and articles was just not picked up by the crawler. So I started to smell something fishy.
Is there something wrong with my SPO tenant? No, same issue across multiple tenants!
Can it be the page layout? No, it renders perfectly in all browsers!
Can it be the PnP PowerShell cmdlets? No, the same issue if I uploaded page layouts manually!
First of all I added the CrawlTime managed property to see when stuff was actually crawled and that there was nothing wrong with the crawler. I could see how this managed property was populated on other stuff than the pages. So there is obviously something wrong with our pages and not SPO.
Time to get my troubleshooting gloves on and I brought out my checklist for this. Since I can't check trace logs (ULS) in SharePoint Online all I could do was to inspect the crawl logs. And now I could see in plan text that my news articles could not be crawled:
"6074070", "https://contoso.sharepoint.com/news/Pages/xyz.aspx", 755", "Item Error", "The SharePoint item being crawled returned an error when attempting to download the item. ( SearchID = F2A4A5E4-AAAA-AAAA-B034-10C593EF6CCE )", "8/4/2016 7:07 AM", "https://contoso.sharepoint.com/", "Intranet",
So, the crawler can obviously not download my page! I also noticed the following cryptic error message on the site and library levels:
"755", "Container Error", "The SharePoint item being crawled returned an error when attempting to download the item. ( Unknown Error The surrogate pair (0xD8DA, 0x272) is invalid. A high surrogate character (0xD800 - 0xDBFF) must always be paired with a low surrogate character (0xDC00 - 0xDFFF).; SearchID = 00D32C87-7CD9-4350-AFF4-BBF38B8EB712 )",
Hmm, some Unicode errors?
I was out of options and I could not do an IISRESET (Rule #3) - so I called a friend (Rule #4), Doc Hodgkinson. He was almost as clueless as I but asked my to test it on a normal SharePoint 2016 on-premises installation (born in the cloud you know) and see if I could replicate the issue and also then have the option to check for more detailed crawl and trace logs.
And so I did. I ran the installer on a clean SharePoint 2016 install, started creating a page using our custom page layout and BOOM! The browser just went white!!! Nothing! It rendered fine in SharePoint Online (cloud-born innovation!)
Quickly I opened up the trace logs and reloaded the page and found this in the logs:
SharePoint Foundation General ahi1s Medium Cannot find requested file: 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\Template\layouts/https://code.jquery.com/jquery-2.1.4.min.js' SharePoint Foundation Upgrade aq775 Unexpected CannotMakeBrowserCacheSafeLayoutsUrl ArgumentException: 15/0/1033/https://code.jquery.com/jquery-2.1.4.min.js
Aha! The Page Layout contains a ScriptLink control that points to that CDN location.
I quickly changed it to a normal script tag and the page rendered fine in the SharePoint 2016 on-premises instance, and I uploaded it to SharePoint Online where it also rendered fine. And…after just a few minutes all my articles was indexed and queryable and I had my Managed Properties. And all was good!
I find this bug very interesting, SharePoint Online obviously accepts full URLs in the ScriptLink property when rendered through a browser but when the crawler sees it something weird happens (also, I wonder why it gets Unicode errors on the site and library as well). Also, the code for ScriptLink is different for SharePoint Online and SharePoint On-Premises (I have NOT tested all CU's though). Also, it's really weird that it some time during the summer actually indexed the pages.
All in all, actually using an on-premises installation for troubleshooting my SharePoint Online issues was a great idea (big thanks as always Neil) and I'll keep that option as a part of my normal routine from now on.
I have long thought that GUIDS are unique, well GUID actually stands for Globally Unique Identifier. And SharePoint is one unique product using GUIDS everywhere. There are 2^128 possible GUIDs to choose from, so there should be no need to reuse GUIDs as long as I'm alive methinks.
SharePoint uses GUIDs to uniquely identify Site Collections and Sites, and more, and this is for instance exposed through the ID property of the SPSite and SPWeb objects. If you take a look at the documentation for SPWeb.ID it actually says: "The globally unique identifier for the website" - which I interpret as this ID is unique, globally! Period.
When you create a Site Collection in SharePoint you create a new Site Collection (SPSite) and a Root Web (SPWeb). The SPSite will be given a unique identifier, a GUID, and so is the root web as well. Due to the way the API is created you cannot find a web directly using the unique Web Id, you actually need the Site Id. Even so there are multiple applications and services that has only stored the unique Web Id and used that as something unique.
Given (recent) changes and a new feature called Fast Site Collection Creation, used in SharePoint Online and to some extent in SharePoint 2016, this is no longer true and you can no longer trust in the Web Id being unique. When a site collection is created with a root web, specifically the SharePoint Team Site (STS#0), it is copied from a site master. The Site Collection is given a new GUID, but the GUID for the root web is copied from the site master. So, in SharePoint Online all your Site Collections with a root site of type Team Site will have the same id.
There is no workaround for this, you cannot change the Id - your only chance is to use a combination of Site Collection Id and the Web Id. That is a dual GUID combo - can't be more unique than that.
Some of you perhaps already knew this, some not. Hopefully you'll be aware of it now and I wish this would be different and that the Fast Site Collection Creation actually updated the Site identifier property, and since I most likely cannot have that I wish the documentation would be updated with a hint on this.
This is by no means an official support statement from Microsoft, rather an unofficial compilation of official statements.
Last week the SharePoint Online team rolled out the preview of the Modern SharePoint lists. Modern Lists are the new incarnation of ye ole Classic SharePoint lists that we all loved and hated over the last decade or so. The Classic SharePoint lists and libraries has been one amazing and powerful tool and I would say that they have been a big part of the success SharePoint has had. Customizations using XSLT, SharePoint Designer and JSLink has all contributed to its success.
The new Modern Lists (currently in preview, not even in First Release and you need special voodoo tricks to get it to work) does not support these kind of customizations, for now. Over the last week or so I've heard large cries and worried Tweets about all peoples current customizations. Microsoft has not been overly clear on the supportability for classic lists in public writing but rest assured; Classic lists will be here as long as they are used and needed. This is what I've been told by the team and what they are trying to say;
- "We have no plans to remove classic mode anytime soon"
- "We heard your feedback on extensibility and customization in particular, and we’ll have more to share in a future update. We plan to add support for customizing the page using modern techniques. Until then, customized library pages should stay in classic mode."
- "Classic mode supports your customizations today, and tomorrow."
- "In the meantime, it’s important for us to maintain continuity for our existing customers. "
Also I do think it is good that they don't set a date for supportability, which some people request, like they've done with for instance InfoPath. If they do that, they have to support Classic Lists until that date. I think it is better they make great progress in making us move to Modern Lists as soon as possible, and when they see no or minimal usage of Classic Lists, they can remove it. The same as they've done for Sandboxed Solutions - something we known coming for years! [Update] But yes, I do think a notification a little bit more than 30 days prior to shutting it down makes sense, if and when the feature gap is closed.
So, keep calm and continue to use your classic lists - however start planning for a modernization of your XSLT List View Web Parts, your JSLink customizations and more. I know that what's coming to replace these, will be much more interesting and be way more modern.
At the Future of SharePoint event in San Francisco on May the 4th Microsoft announced the new and improved customization option and/or development model called the SharePoint Framework. This is a development model that solely focused on client-side development. There's been some confusion going on on Twitter and other social medias and podcasts and I thought I should put together an Q&A post for this.
This Q&A post is totally unofficial, all of this is currently in private preview and some comes from my (awesome) DevKitchen experiences, so things can and will change and I take no responsibility of any errors in this post or any financial, physical or mental issues caused by reading this.
I will try to keep this post alive as much as possible and if you have any questions, feel free to post them and we'll try to get answer to them. I also listed some questions, that I do not have an answer to, but are working on to find out…
 Updated 2016-08-17, after initial developer preview release
Q: Is the SharePoint Framework an new development model
My point of view here is that this is not a completely new model. The framework might be new, but that is a framework that we all has been longing for for quite some time. Client-side development has been here for years and we all built our own frameworks. Now Microsoft is creating this framework for us, it is standardized and they will also build in native support for this framework in SharePoint. This model leverages techniques we are used to such as CSOM, the SharePoint REST API's, the Microsoft Graph etc and at the same time embraces open source technologies such as node.js, Gulp, Yeoman and more.
This model does not deprecate anything; if you need to do full trust code you can still do that (on-premises) and build WSP's, if you want to use the App/Add-in model you are free to do that.
Q: What's not so new in this model?
A bit of a weird question, but I wanted to highlight that this model actually piggy backs on previous development models and infrastructure in SharePoint - specifically the Add-in model. The packaging and deployment mechanism is using the add-in model. The solutions built using the SharePoint Framework are being packaged as a .spapp file, which is very similar to the .app package created when building a SharePoint add-in, and distributed using the App Catalog.
Q: Are the Feature framework, Sandbox and the Add-in models dead?
[Added 2016-05-08] Far from it! The Feature Framework (introduced in SharePoint 2007) is very much alive for on-premises deployment and is in many cases a requirement, with the caveat that it is hard to convert that to a model that works in the cloud. The Sandbox is partly dead, it is, code based Sandboxed solutions are officially deprecated, but there are still a usage for declarative Sandboxed solutions. The Add-in model is also still a very relevant way moving forward; Add-ins offers features that the SharePoint Framework doesn't (such as isolation, elevation of privileges etc).
Q: Does this replace Add-ins?
[Added 2016-05-08] No! The SharePoint Framework will NOT replace Add-ins, the will co-exist side by side. There's no need for you to migrate your Add-ins to the SharePoint Framework. That might not even be possible to do - since you want to stay in isolation, you might want to elevate privileges, you might want to do work without user interaction, you might want to use the existing store.
Q: Do I need to create those weird app keys and secrets and learn all about OAuth?
[Added 2016-05-08] No, this is not how the SharePoint Framework works You only run this as a user, within the SharePoint page context so you are already authenticated and the SharePoint Framework app are already authorized with the currently logged in users credentials and permissions.
Q: Can I call the Microsoft Graph using the SharePoint Framework?
[Added 2016-05-08] No. Not now at least. You don't get any token that you can pass to Microsoft Graph (graph.microsoft.com). The only API's you can access are the same ones as you can using any Script editor web part or script embedding. If you really want to query the Microsoft Graph, you need to create an Azure AD App and sacrifice to the gods that the Azure AD team fixed ADAL/MSAL so that it works with Internet Explorer and trusted/intranet zones, and do it the "old fashioned way".
Q: Is there any specific requirements on my infrastructure?
[Added 2016-05-08] No, there is no requirements on app-domains etc. as we have in the Add-in model. You can host your SharePoint Framework solutions on any web server anywhere or in SharePoint itself, without any extra infrastructure components. This also makes it very easy for the SharePoint team to bake this into a future Feature Pack (see below).
Q: What does the .spapp package look like?
When you package your client-side solution, an .spapp package is created. This package looks very similar to any other SharePoint Add-in you're creating. This package contains the following major things:
- An AppManifest - a regular SharePoint add-in AppManifest with the difference that the App element has a IsClientSideSolution="true" attribute
- One or more features - a normal Feature element file
For client-side applications it is a bit more complex as they are tied to lists. For the sake of uncertainty I leave that description out for now (well I got to have a reason to lure you back here). I know there are discussions on how this should be implemented/executed.
 Note that client-side applications is not part of the initial release.
(Once again this might very well change over time when we get closer to release)
Q: How do I deploy my solution?
You have three options of hosting all your files:
- For Development you host your files locally (localhost using the node.js express engine) and can take advantage of automatic reload of your app when you save files etc.
- You can deploy to a SharePoint library. A good option if you want full control of the artefacts in your tenant
- To a CDN. This is most probably the best solution for ISV's where they centrally can manage all the artefacts.
Q: How do I update a client-side solution
Q: Will the Office Store allow client-side solutions built using the SharePoint Framework.
Thank you, very good question. I do not have an answer to this right now, but I assume that the team are working hard on this, specifically regarding the topics around updates. To be continued…
Q: But hey, I'm an ISV and this looks like an Enterprise developer feature only!
[Added 2016-05-08] Thank you for asking and noting. Yes, I agree that the current initial release is focused on enterprise developers. I know one of the goals with this new framework is also to support the ISV market. I have however no timeline for this.
Q: What about isolation in my customizations
No problem! Then you just encapsulate your "secret" business logic or algorithms in web services and make sure that those are CORS enabled.
Q: What client-side frameworks are supported?
All of them. Well, I haven't tested all of them, but that's the idea. The product team does not want to limit you with what frameworks to use, so go ahead use your preferred ones. Personally I've built client-side solutions with jQuery, Angular 1.x, Angular 2, React and Knockout.
 Microsoft and the Product Team for SharePoint has taken a decision to use React in their solutions. This actually have a big effect on us developers. For instance the new Office UI Fabric version 2 - is React only! So if you want to use the new components offered you either have to use React in your client side solution or reverse engineer Office UI Fabric, since there's no "pure CSS" spec/implementation.
Q: Do I really need to learn TypeScript?
Q: Do I really need to use Visual Studio Code?
Short answer; absolutely not! You can use whatever tool you want to write the code. However I guess most of the demos and instructions from Microsoft will be based on Visual Studio Code.
Q: But I really want to use Visual Studio that I'm used to and love so much!
Yea, I'd love that option to and there's a lot of benefits of using Visual Studio. I know that the product team are aware of this and I'm pretty sure that they are working on it. But see this as an opportunity to learn Visual Studio Code meanwhile… Visual Studio is fully supported, together with the use of the Node.js tools for Visual Studio (NTVS). Please use at least version 1.2!
Q: Do I really need to use Gulp?
Short answer: Yes. The current tooling is built on Gulp tasks and I recommend you to start with that. But if needed you can configure and modify those tasks. It is also totally possible of building your own package mechanism and code structure that fits your style of coding, if you have the time. (I actually wrote my own package mechanism and gulp tasks from scratch just to understand how it all worked out and to be able to give feedback to the team - so it is possible)
Q: Does it work on my bestest device ever - my precious Mac?
[Added 2016-05-08] Yup! Use Visual Studio Code on your Mac, use whatever text editor you like, use it on a Linux box! This is one of the reasons the team choose to use Node.js npm ,gulp and Yeoman as the foundation for the development framework and that is why the go with Visual Studio Code first (instead of the full Visual Studio).
Q: Do I really need to use Git?
Short answer: Nope! Git has nothing to do with this, at all. But the code samples and the source for all the tooling will
most likelybe distributed using Git/Github so if you're interested in contributing you should learn it.
Q: Is this Open Source?
[Added 2016-05-08] From my understanding the idea is to have this Open Sourced once we get out of "closed beta". There really is no point in doing it any other way with client side components,.
Q: What is the Workbench?
The Workbench is a test rig for client-side solutions which comes in two flavors. One static html version that are used without the context of SharePoint. It is capable of rendering the page canvas and client-side solutions so that you can work with the UX components. If you need live data however you need to create mock data for your domain model. The second flavor of the Workbench is the one running in SharePoint, with that one you have access to the full page context including SharePoint data.
Q: What about SharePoint 2016 on-premises, will we ever be able to take part of all this?
Yes, I do believe so. There's nothing in here that actually locks this model to Office 365 and SharePoint Online and at the Future of SharePoint event there was announced that SharePoint 2016 will get "Feature Packs" during 2017. So, yes, this will most likely happen. Microsoft is targeting an on-premises release of the SharePoint Framework for the first half of 2017. This will be a part of a feature pack for SharePoint 2016.
Q: When can I get my hands on this??
[Added 2016-05-08] It was announced at the Future of SharePoint event that this will roll out starting this summer to first release tenants. My guess is that we will have a first version by the end of this year (2016). You can get your hands dirty right now over here:
Q: Is it SPX or SPFx?
Over the last two days I've seen the SharePoint Framework been shortened both as SPX and SPFx. I prefer the latter one. How about you?
Q: What permissions is needed to deploy a SharePoint Framework app?
[Added 2016-05-10] A really good question. This is an assumption based on the experience so far. You distribute the app/solution to the App Catalog - so you need to have permissions on the App Catalog.
Q: How does the development life cycle look like?
[Added 2016-05-10] The development life cycle is one of the things that this SharePoint Framework would like to align with the rest of modern web development. You have multiple options and how you actually do it is up to you. This is how I see it and what works great with the tools:
- Build and host your solution locally (node.js Express web engine) using the local Workbench, without any real SharePoint data just using mock objects
- Host your solution locally as above, but deploy the solution to the app catalog and then add it to a site so you can test it with real data
- Iterate 1 and 2 until you are happy
- Package your solution, now pointing to the CDN location, and upload that to the App Catalog to distribute it to a SharePoint tenant
- Repeat 4 and 5 in dev, stage or production
- Go back to 1 to build your next version/update
Do you have any more questions? Let me know!
I have to admit it I have succumbed to Visual Studio Code and now also Gulp tasks, well almost at least. I was working the other day with some display templates and page layouts and needed a more efficient way than uploading the files to SharePoint Online. Open with Explorer could have worked, but since I used a customers Office 365 tenant I did not want to store credentials and do all the required voodoo to get that to work. Instead I decided to explore Gulp and see if I could automate this, and the result is a Gulp plugin called gulp-spsync.
You can find gulp-spsync in this Github repo: https://github.com/wictorwilen/gulp-spsync
For you who have not used Gulp, the short description is that it is a task runner that runs tasks on command or at build. In this case it will copy local files to a SharePoint site.
This is how gulp-spsync looks like in practice in Visual Studio Code. As soon as I edit one of my files and saves it, the file will be uploaded to SharePoint. In the sample below it is a Display Template html file, once saved it will be uploaded, and then in SharePoint converted to the .js correspondent file.
To use this you need a copy of Visual Studio Code and full access to a SharePoint Online Site Collection. How to configure it all is documented in the repo, so I will not rehash it. But the basic outline is that you open up a folder on your local machine. Create a folder in that one where you create sub folders representing the sites libraries and catalogs. Then comes the tricky part, this task requires that you register an App in the Site Collection and give that App permissions. Once you have the App details you install the gulp-spsync plugin and then configure Gulp. All that then is left is to start working with your files.
I hope more people than me get some use of this one and any feedback is welcome.
It has been a while since Office 365 introduced the suite wide themes. These themes are applied on all services within the Office 365 suite, or at least the ones using the Suite Bar navigation. Up until the very last few weeks the suite wide theme has been something you can set but your SharePoint site owners and all end-users has been able to override them. Finally these things has been resolved and fixed (no info about this on the Office Roadmap, hence this blog post)!
In this post I will walk you through how the Office 365 Theme can and should be controlled and what specifically to think of.
Create you suite wide Office 365 Theme
Of course, the first thing you need to do is to create your Office 365 Theme. This configuration is very logically located under the Company Profile in the Office 365 Admin Portal. Once you choose "Company Profile" in the left hand menu you then choose "Custom theming".
There are a couple of things you can configure here.
The custom logo is a picture shown on each and every page, in the middle of the suite bar. It has to be 200x50 pixels and in either JPG, PNG or GIF format and it must not be larger than 10kb.
URL for clickable logo
You can also set a URL for the custom logo. Having it point to tenant.sharepoint.com is a kinda good thing - since there is still no way to "force" an "Intranet" tile into the App Launcher.
This is a background image that will be shown in the suite bar. The size should be 1366x50 pixels and in JPEG, GIF or PNG and not larger than 15kb. (The error message says 250x30 and less than 10kb though).
You have three color options:
The Accent color determines the color of the App Launcher box (red in the image below).
Nav bar background color is the background color of the suite bar (green in the image below)
Text and icons is the color of the text and icons (blue in the image below)
The last option is the App Launcher icon where you have three colors to choose from; the Text and icons color, white or black.
Note: Please be patient when applying a theme or updating a theme. The suite bar takes some time to trickle out to all services and it's also cached "hard".
Prohibit end-users to overwrite your Office 365 Theme
On the Custom theming page there is one really important check box, that should be checked on each and every tenant: Prevent users from overriding custom theming with their own theme.
When this checkbox is enabled users cannot on their Office 365 settings page override the theme you have created. Think of in a corporate world where you have a nice theme and your end-users overrides it with cute kittens or whatnot.
SharePoint themes does not longer overwrite the Office 365 Theme
So, what about SharePoint and the SharePoint themes? Up until very recently as soon as you applied a theme to a SharePoint site, that nuked the Office 365 theme on that site. Over the last few days a fix has been rolled out so no matter what despicable built-in SharePoint theme you apply, the Office 365 Theme will be there.
All this might be old news to some of you, but from the Twitter streams (SMS Rob?) I've seen that not everyone is aware of all these features.
Note: you might not have all these features/fixes in your tenant, as it takes a while for everything to roll out.
SharePoint Team Sites are dead, there you have it! The era when SharePoint Team Sites was the king of SharePoint and web based collaboration are over. SharePoint Team Sites are dead, I said it again. Ok, you might think this is a link bait, a scam or something else - it's not. This is how I foresee the future of online collaboration in SharePoint Online/Office 365.
Team Sites are based on a decade old construct in SharePoint. They allow a great flexibility and extensibility for the end users, but…
…it requires a lot of training
…it drives a lot of support
…it drives a lot of consultancy hours (yes, I am/was one of those)
…historically upgrades are extremely expensive
…[fill in your own here]
…do the end-users really need that much power?
So, what's a better option then? I'd say Office 365 Groups! Office 365 Groups has a lot of the features that we lack in Team Sites and it offers the simplicity that end-users requires from Team Sites in 95% (just made that figure up, but you get the point) of the cases.
Office 365 Groups combines the best of the Office 365 services in one single place, and Office 365 Groups have done something the SharePoint team haven't ever achieved doing with Team Sites - integrate with the Outlook client. Office 365 Groups is a mash-up of:
- An Exchange Online Inbox - that is you can send e-mail to the group. This is a killer feature in online collaboration. Yes, SharePoint 2013 had the Team Site Mailbox but we all know that feature didn't scale and to be frankly it sucked.
- A SharePoint Online Document Library - all we need to share documents, what better tool for that than a SharePoint document library. Offline sync, version history, web-based editing with Office Online, sharing, recycle bin etc etc. Using SharePoint for what SharePoint originally was designed for…
- An Exchange Online Calendar - a real calendar (compared to the one in SharePoint)
- A OneNote Online Notebook - OneNote, nuff said
- Conversations - yea, conversations and discussions and likes and what not (not based on Yammer, thank you very much).
As you can see Office 365 Groups uses the best tools available in the Office 365 service for a specific purpose. It all integrates and works extremely well in the web based user interface and you can offline sync the documents and work with it in the Outlook 2016 client.
Office 365 Groups also aligns very well with the NextGen Portals, Microsofts attempt to build killer solutions in Office 365. One of those NextGen Portals are Delve which helps you discover new and relevant information. Shortly Delve will start to recommend Office 365 Groups for you (announced at Ignite 2015) and Office 365 and the Office Graph will also be extended with really interesting collaboration analytics between groups (another awesome Ignite demo). We also will see a Office 365 Groups App for mobile devices (see public roadmap), Office 365 Groups will be integrated to CRM Online and more…
The extensibility story for Office 365 Groups has just started. Unfortunately we are not allowed to modify content types and such in the document library (see wish list below). But Office 365 Groups has made it into the new Microsoft Graph/Unified Office 365 APIs and Azure AD Apps.
For management of Office 365 Groups the story did not start well last fall, but we're continuously seeing new improvements. Such as the new naming policies for groups etc. I like it!
Yes, there are exceptions and some rough edges here and there (see my wish list below) - but overall this is something your organization should adapt as soon as possible. It will take you one step closer the digital (modern) workplace and into the future of online collaboration!
Office 365 Groups wish list
Here are a couple of things that I think should be top priority for the product team. If and when these "issues" are solved I think we have a pretty robust and future-proof solution.
- Supported management of the Document Library, so that you can for instance modify/add the content type and/or templates. We really need this for enterprise content management.
- Some extensibility hooks for customizations
- Better management of the Groups e-mail address
- A task list
- Integration with Azure AD Dynamic groups
- Notifications/events when groups are created or group creation approval
- Better discoverability, a better "Groups Portal"
- An Everyone group - so that we get an All company feed and once and for all can shut Yammer down
One very common requirement in SharePoint, and other portal solutions for that matter, is to have the possibility to target content to a dynamic audience of users and even secure information based on dynamic rules. Traditionally this has been done with Audiences in SharePoint. Audience is a dynamic set of users that is compiled, usually once a day, and at compile time the rules of the Audience is evaluated. A SharePoint Audience is used to target information, but cannot be used to protect content - ie as a security group.
The Azure Active Directory released a new feature the other week, called Dynamic Membership, which is a very similar feature to the SharePoint Audience feature. But, does it work with SharePoint Online? Let's have a look!
Enabling Dynamic Groups in Azure AD
First of all we need to enable Dynamic Membership in Azure Active Directory. To do this you need to be an Azure AD admin and you must have Azure Active Directory Premium subscription, and also the administrator you're logging in with must have an Azure AD Premium license assigned to him. Once you have the licensing sorted out you need to enable Delegated Group Management. This is done in the Azure Portal under Azure AD > Configure.
Creating a Dynamic Group
When you've enabled the Delegated Group Management you can create a new group or configure an existing group in Azure AD. Remember if you change an already existing group to dynamic that group will loose all members. Click on the created or already existing group and choose the Configure tab. On that tab you can enable Dynamic Memberships. When you do that the screen changes into an interface where you can specify the rules; either through a simple guide or using a more advanced syntax.
In the screenshot below you can see that we have a group called "CVP" (Corporate Vice Presidents) and we would like everyone with the term CVP in their title to be a part of this group. Click Save when you are done with your configuring of the dynamic group.
To create the group we can use most of the Azure AD attributes. Note that the SharePoint Online user profile specific attributes cannot be used, so there are still some reasons to use SharePoint Audiences.
Group memberships are almost immediate. You might have to wait a minute or two when you do changes. There is no way to force a recalculation of the group (as far as I know).
Does it work in SharePoint Online?
The final test - can I now use this dynamic group in SharePoint Online (Office 365). The answer is YES! The newly created dynamic security group is immediately available for usage in SharePoint Online.
Dynamic Groups in Azure AD is a really great feature. We can use it in SharePoint Online, Office 365 and even our custom applications to provide a better way to control security or target information. Although it requires you to have an Azure AD Premium subscription this is just one those small features that should make you consider that upgrade!