Contents tagged with SharePoint

  • The SharePoint Framework (SPFx) is here!

    Tags: SharePoint, SharePoint 2016, SharePoint Online, SharePoint Framework

    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.

    That feeling when you use the SharePoint Framework the first time...

    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!).

    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!

  • SharePoint Framework - Questions and Answers

    Tags: SharePoint, SharePoint Framework, SharePoint Online, SharePoint 2016

    Me at The Village in San FranciscoAt 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…

    [1] 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 a client-side web part the feature contains a .webpart file that is being added to the Web Part gallery. The client-side web parts actually use a new .NET web part class called Microsoft.SharePoint.WebPartPages.ClientSideWebPart. This web part has one important property that references the client-side web part Id. The elements file for the Feature also contains a new CAML element (ClientSideComponent) that is used to point to the bootstrap JavaScript file that we use. That file can be hosted locally (for development), in SharePoint or any other CDN (for more information see below).

    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.
    [1] Note that client-side applications is not part of the initial release.

    Note that none of your actual logic (JavaScript etc) is stored in the .spapp package.

    (Once again this might very well change over time when we get closer to release)

    Q: How do I deploy my solution?

    Deployment is two steps; one is to deploy the JavaScript files and artefacts (see below) and from that you get a bootstrap URL, that URL is used to package the solution (.spapp) which you then deploy to the App Catalog in your SharePoint tenant.

    Q: How do I deploy my JavaScript files and other artefacts?

    You have three options of hosting all your files:

    1. 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.
    2. You can deploy to a SharePoint library. A good option if you want full control of the artefacts in your tenant
    3. 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

    This is an answer that some might be scared of. If you only need to update the logic or code in your app you only have to update the source files, you do not have to redeploy the .spapp package. The "only" time you would need to do that is if you change the URL to the location of where you host the bootloader JavaScript file.

    Since the app package and app registration only contains a reference to the bootloader JavaScript file, there is nothing preventing a user, vendor or similar to actually modify that file (and thus giving the app full access to the page/site - see question about isolation below). But, this is exactly the same way we have it with any jQuery or Angular files hosted on a CDN.

    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

    The SharePoint Framework runs in the context of your page, and will also have all the privileges of the user of the page. This might sound scary, but it works in the same way as any Script Editor Web Part or Custom Action with JavaScripts. If you truly need isolation in your app you have two options; 1) Go back and use the Add-in model and host your application in an iFrame or 2) build your new client-side application using an iFrame.

    Q: I don't want everyone to be able to see my business logic in JavaScript!

    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.
    [1] 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?

    Short answer Yes. The tooling right now is built using TypeScript and uses class inheritance etc. It is possible to write using plain JavaScript but that would just be a waste of time and more error prone. And just because of that we'll probably see people doing this. And this makes me bring up the old SharePoint mantra - Just because you can, doesn't mean you should!

    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…
    [1] 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 likely be 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.
    [1] 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).
    [1] 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:

    1. Build and host your solution locally (node.js Express web engine) using the local Workbench, without any real SharePoint data just using mock objects
    2. 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
    3. Iterate 1 and 2 until you are happy
    4. Pack and deploy your JavaScripts and assets and deploy either to CDN or to SharePoint
    5. Package your solution, now pointing to the CDN location, and upload that to the App Catalog to distribute it to a SharePoint tenant
    6. Repeat 4 and 5 in dev, stage or production
    7. Go back to 1 to build your next version/update

     

    Do you have any more questions? Let me know!

  • Web Parts are back at the center of SharePoint development!

    Tags: SharePoint, Office 365, Web Parts

    Today at The Future of SharePoint event Microsoft have announced the next iteration in SharePoint development - the SharePoint Framework. As one of the old ones who started with the Digital Dashboard Resource Kit, to the COM+ event handlers in SharePoint 2001, over to custom built DDFs, to WSP's to Apps and Add-ins - this new framework is a very welcome change.

    For years SharePoint Developers have been forced to walk in shame in the outer rims of the developer guild. It's been so hard to get over the threshold and once you were over it, there was very few who actually returned to a normal life. I've been struggling for years to get ASP.NET or web developers to get on over to SharePoint development with no luck. The Add-in model did not help in any sense here and just introduced new pitfalls and confusions.

    Introducing the SharePoint Framework

    Last year at the MVP summit we were introduced by Jeff Teper (I'm so glad that he's back on the team) that they had some cool things cooking in Redmond. He, and the team, told us that they were here for the long run and that they were building something new that would supersede the current existing extensibility model. And in February this year I went over to Redmond to try this out with my own set of hands at an event called the DevKitchen. This event where we all were introduced to this new model is one of my top moments in my Microsoft developer career and the interaction we had with the engineers was just phenomenal, looking forward to the next one Dave! I do believe that our trial and errors and feedback made the end result so much better.

    What we got our hands at that DevKitchen was the new extensibility model, now called the SharePoint Framework. In my opinion this is an evolution of SharePoint, adapting to a more modern way of building applications. It's not replacing Add-ins, and they are not replacing WSP's and server side code. It's another tool in our toolbox - albeit it might be the one I will use first hand from now on.

    This new SharePoint Framework consists of a couple of different parts. You can read more about it in Bill Baers post - The SharePoint framework - an open connected platform.

    Web Parts are back!

    The one thing that excites me the most about this new SharePoint Framework is that Web Parts are back, with a bang! Web Parts was what brought me into SharePoint. In the previous millennium we built our Web Parts using VBScript and was pure client side code, until they appeared in SharePoint as a server side component, and then adopted in ASP.NET as a standard feature. Unfortunately Web Parts has had some very dark times, and that was when the Apps/Add-ins entered the scene and introduced App Parts - an abomination.

    Well, let's forget the past and look at the new client-side Web Parts. Web Parts are back as a client side thing. Client-side Web Parts are now built in (preferably and initially) in TypeScript. They are very similar in construct as you know Web Parts; they can be initialized, persisted, have properties and of course a way of rendering them. These new client-side Web Parts will live side by side with the old and traditional Web Parts.

    Fun fact is that I think I was the one, external from Microsoft, that actually built a client-side Web Part that worked.

    Using client-side technologies isn't something new, the only new thing here is that we now have a proper and supported framework for it. Client-side technologies isn't perfect either, with access to the DOM we are given great powers, but we do this all the time today.

    The SharePoint Framework is all built on open technologies and you can use whatever platform you prefer. The initial release of the SharePoint Framework will be built for TypeScript, node.js  Yeoman and npm. These are four technologies that you should read up on before the SharePoint Framework is starting to roll out this summer. All you need to build you solution is then an command prompt and Visual Studio Code.

    Since this is all client side rendering (ie JavaScript) you can use any framework of your choice; Knockout, Handlebars, jQuery, React, Angular 1.x and 2 you name it.

    The very first client-side Web Part

    Just to give you an example on how these client-side Web Part works and so that you can see how similar they are to the Web Parts we are used to build, here's how you would create a simple client-side web part.

    Disclaimer: things below here can most certainly change until GA of the SharePoint Framework.

    To prepare your environment you need to install node.js and npm and the Yeoman generator, which will take care of the project scaffolding for you. Then you download the specific SharePoint generator using Yeoman and start the scaffolding (exact command to be determined; hopefully yo sharepoint).

    What you get is the a set of files, just like when creating a new project in Visual Studio. All code files are TypeScript files and the Yeoman generator will create one specific file for your Web Part TypeScript class. This TypeScript class will inherit from a base class as follows:

    export class FutureOfSpWebPartWebPart 
       extends BaseClientSideWebPart<IFutureOfSpWebPartWebPartProps>{ 
        ...
    }

    As you can see, my client-side Web Part extends the BaseClientSideWebPart abstract class. The generated code also includes overrides of some of the methods. Also notice how there's an interface definition passed in as an template argument to the base class:

    export interface IFutureOfSpWebPartWebPartProps { 
        description: string
    } 

    This interface is used to define the properties of your Web Part, in this case only a description property of the type text.

    client-side web part in TypeScript

    In the generated file there are by default three overridden; the constructor, the render method and a property called propertyPaneSettings. For this post, let's just focus on the rendering of the Web Part.

    public render(mode: DisplayMode, data?: IWebPartData) {
        this.domElement.innerHTML = 
           `The Future of SharePoint is <b>awesome</b>!`;
    }
    

    This method is responsible for rendering the client-side Web Part, and in order to do that we have access to the actual DOM element, through the this.domElement object. WIth that we can manipulate the DOM as we will and in this case just insert HTML directly into the element. We can also in this method setup any bootstrapping we want for our favorite framework, we can check the mode to see if we're in edit mode or not, and we can get properties using the data argument.

    Once we're done building our client-side Web Part we of course would like to take it for a test ride. And now over to something really cool. Remember building Web Parts and you need either your own virtual machine or an Office 365 subscription with internet connection. No more! You can sit on an airplane (like I do now) and just run the gulp task called serve. This task will wire everything up, start your browser and open up the Workbench, which is a local offline canvas for the new page model and you can work with your client-side Web Part. If you need any changes to it, just modify the TypeScript file and the task will take care of compilation and reload your browser. Can't be easier.

    Client-side Web Part in the Workbench

    Of course this method has no access to SharePoint data or the Graph, so you need to work with mock data - which generally is a good idea anyway!!

    Then when you're ready to go test with live data you can use the Workbench that will be present in SharePoint (not available until later this summer I'm told) and there's also gulp tasks for packaging it properly so that you can either upload and host your client-side Web Part script files in either a CDN or in SharePoint itself.

    I think this is more or less exactly what I've been longing for in this area. SharePoint team - you nailed it!

    Make sure to check in this video by Daniel Kogan in which he walks through the new framework, page model and how to to build a client-side web part.

    Client-side applications

    There's also a concept called client-side applications. This is the new way of customizing lists and libraries. In a nutshell you register a client-side application for a list or a library and then you are solely responsible for rendering the user interface, in a similar fashion as above. Can't wait to see what awesome stuff people builds with this. But, that's for someone else to write about, or me at another time.

    Impressed?

    How do you feel about this? I think this is a fresh re-start of the SharePoint oil tanker and I welcome all the new thinking in this space. Yes we have to re-learn quite a lot of stuff, but I love that. And honestly people, SharePoint developers has been the laziest group of developers out there (except some Cobol veterans) and been very afraid of changes (remember when all people screamed for their life when the App model came?). Get out of your comfort zone, learn new stuff, build cool stuff and enjoy SharePoint land once again.

    SharePoint is back and Web Parts are back!

  • SharePoint Team Sites are back - stronger than ever!

    Tags: SharePoint, Office 365, Office 365 Groups

    SharePointAbout a year ago I wrote a blog article called SharePoint Team sites are dead. An article that stirred up many feelings in the community and started an interesting (and somewhat harsh) discussion - which was kind of the point. Fast forward to May 2016 and this is a totally different ball game! SharePoint Team Sites are back!

    Modern team sites

    Jeff Teper, CVP at Microsoft, writes in the just now published The Future of SharePoint blog post: "Team sites has always been at the heart of collaboration with SharePoint", a statement I absolutely agree with. Team Sites is what made SharePoint such a successful product. The post I wrote about how Team Sites are supposed to be dead are still true though - Team Sites are not what they used to be, they have transformed and merged with Office 365 Groups into something more powerful - the new Modern Team sites.

    For the last year or so I've been fortunate and been part of a smaller group that has had a continuous interaction with the product team (both marketing and engineering) and we've been shown what they have been working on and we've given them feedback. The product team has been awesome in this dialogue, and in the way they have taken Team Sites out of the dark ages and into a new more modern way of working and at the same time listening to our opinions.

    Team Sites and Office 365 Groups

    If you've been following my blog or me on Twitter, or met me in person, you couldn't have ignored the fact that I've been a huge fan of Office 365 Groups. Although I also been very transparent that they have not been the silver bullet, given some of their shortcomings, of which almost all has been resolved over the last few months. And the Roadmap of features and improvements of Office 365 Groups are just top notch. The power of these new Modern team sites is the fact that they have merged with Office 365 Groups, giving team sites many of the features that we previously had to build and customize.

    SharePoint team site and mobile app

    Yes, this new experience will prevent some customizations that we've previously been used to doing. But this is a good thing. This allows for a much better life cycle management of SharePoint Team Sites. We all know what's the most expensive part of any SharePoint project - the upgrade piece, the thing that happens a couple of years after the initial project. In this new world of evergreen services - I expect to see this coming to the on-premises version of SharePoint as well - we are in a continuous upgrade mode. We don't have time to spend on upgrades, it should just work. This new model; including the new page experience and extension framework; allows for this.

    SharePoint home and the SharePoint mobile app

    SharePoint homeAlso back in December 2013 I wrote another blog post (seems like ages ago) in which I questioned the fact that the brand SharePoint was going to survive. At that time there was no mention of SharePoint at all in the end user interface in Office 365 - it was just known as Sites and Microsoft was very mellow on the whole on-premises piece. Worth noting is at that time the leadership of the SharePoint team was not as it is today.

    Fast forward to 2016, Sites will be renamed to SharePoint. Finally! This is something that I have been longing for. But this is not only a rename of the tile in the waffle. SharePoint home is your new start page, an aggregated view of your most active sites as well as the ones recommended to you by the Office graph, from both the cloud and on-premises. Not only that, the SharePoint home is also a new entry point for enterprise search and I also believe that this is just the first of many steps.

    This SharePoint home experience is also the heart of the new SharePoint mobile app. Another experience that I've been trying out for a while. The "Intranet in your pocket" is what Microsoft calls this app. It's not really there yet (as an Intranet), but the vision and ideas they have look great. Currently the app gives me great insights in the Team sites I'm participating in, the activities happening in them, the documents and even plain ol' SharePoint lists, and I can search for documents and people. Another great feature is that they by default have built-in account switching and it works for Office 365 and on-premises. Good job!

    Intranet!

    I find it very interesting that Microsoft finally talks about SharePoint as an Intranet. They haven't done that for a long time. The versatile SharePoint development platform is now being more streamlines to a specific set of workloads within the Digital Workplace and employee experience. I think this is a good move and hopefully customers can get started with SharePoint without spending to much money and time on building the Intranet features. I wouldn't be surprised if we see more Intranet features, like news and portals, in the near future.

    The SharePoint Framework

    Not only is this new modern team sites equipped with a great user experience, it is also customizable through the new page model and the new extension model called The SharePoint Framework. This new model allows you to still do the the customizations that once made SharePoint so famous and feature rich. This time the improved extension model is all based on client side technologies; no WSP, no sandbox, no weird SharePoint hosted apps. What we get is something more modern that potentially can attract new developers to the realm of SharePoint. This part I'm particularly excited about and please read this post I've written, that is dedicated to the SharePoint Framework.

    One of the most important aspects of the SharePoint Framework and the approach to base it on solely client side technologies, is that this allows the SharePoint team to slowly move away from the (deprecated) ASP.NET Web Forms model that has over the years caused us so much headaches.

    And what about Yammer

    These new announcements are all about SharePoint. Yammer is not a part of SharePoint. None of the blog posts from today mention the Yammer service and during the virtual event today, Yammer was just mentioned briefly. I draw my own conclusions from this and you have draw your own.

    Summary

    What we've seen today and moving forward is just the beginning of the Future of SharePoint. I'm very excited about what we will get over the next few months and following that.

  • SharePoint Team Sites are dead!

    Tags: Office 365, SharePoint, SharePoint Online, Exchange Online

    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.

    SNAGHTML6f3a7c[7]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

  • SharePoint Online: App Only policy PowerShell tasks with ACS

    Tags: SharePoint, Office 365, PowerShell, Apps

    Here’s a little nugget that I’ve planned to blog about for some time, that I needed today for a small task. I needed to do a background job to SharePoint Online that at a scheduled interval downloads list data, process them and optionally updates some data in my site. This can of course be done by creating an executable storing username and password combos, and with the help of the TokenHelper.cs class from the App for SharePoint Web Toolkit NuGet package and some stored username and password combos we can make the Auth pieces quite easy. I don’t like that approach. There’s two big drawbacks with that approach. The first one is storing the username and password – we can solve that with an AppOnly policy, which I blogged about in the SharePoint 2013: Using the App Only policy and App Principals instead of username and password combos post. The second issue is that I very much prefer to script these kind of tasks, it makes it more flexible. Problem with that approach is that we need to manually do the Auth pieces. But from now on you just copy and paste from this post.

    Creating the App Principal

    In order to create our PowerShell script we need to create an App for it. This step is exactly the same as we did in the blog post mentioned above. But let’s repeat it. Note! I do use the traditional way of registering apps in this scenario using ACS – I do not use an Azure AD app. The reason for this is I want every Site Collection admin to be able to script like this. Azure AD apps requires way to much permissions for the normal user.

    imageIn your site collection, navigate to /_layouts/15/appregnew.aspx. Click on both Generate buttons, so that you get one Client Id and one Client Secret. Next enter a Title, an App Domain and the Redirect URI. The App Domain and Redirect URI can be basically anything in this scenario. Then click Create to create the App Principal. On the next screen you will get all the details of your App. Copy and paste that data so you don’t loose it.

    Next head on over to /_layouts/15/appinv.aspx. Paste your Client Id in the App Id (Microsoft has never been good in naming conventions) text box and click Lookup. This will retrieve the rest of the app details. Since we will not have any UI or install any App we need to manually ask for permissions and then grant the permissions. What we do is that we create a permission request XML. Depending on your requirements your XML may be different from the one below. The following permission request XML asks for Full Read permissions on the whole web.

    <AppPermissionRequests AllowAppOnlyPolicy="true">
      <AppPermissionRequest
        Scope="http://sharepoint/content/sitecollection/web"
        Right="Read"/>
    </AppPermissionRequests>

    Note the AllowAppOnlyPolicy=”true” attribute – that one is the key to allowing the App to run without username and password. Once you paste the XML into the permission request XML textbox and then click on Create. You will see the Trust screen for your app. Make sure the permission request is what you expect and if so, click on Trust it!.

    Auth in PowerShell

    Now, let’s get to the core of this post and let’s create a PowerShell script that uses this app to read items from a list. I split it up in a few different parts to make it easier to follow. In the end of the post you will get a link to the full code sample.

    Defining some constants

    Let’s start by defining some constants:

    $clientId = "16119847-8ac7-4a3a-a2e5-18debd9fc9d2"
    $secret = "KuZj5UD22oy2.....=";
    $redirecturi = "https://localhost"
    
    $url = "https://tenant.sharepoint.com/sites/thesite/"
    $domain = "tenant.sharepoint.com"
    $identifier = "00000003-0000-0ff1-ce00-000000000000"
    
    

    The $clientId, $secret and $redirecturi are copied directly from the results of my app registration. The $url parameter is the URL of the site where I registered the app, and $domain is just the server part of that URL. Finally the $identifier is a static Guid value, which represents SharePoint (Exchange, Lync, Workflow etc has their own Id’s).

    Retrieving the Realm

    The next step is to retrieve the Realm or Tenant Id. You might already know this or you might just run these commands once and store it as a static variable.

    $realm = ""
    $headers = @{Authorization = "Bearer "} 
    try { 
        $x = Invoke-WebRequest -Uri "$($url)_vti_bin/client.svc" -Headers $headers -Method POST -UseBasicParsing
    } catch {
        #We will get a 401 here
          $realm = $_.Exception.Response.Headers["WWW-Authenticate"].Substring(7).Split(",")[0].Split("=")[1].Trim("`"")
    }
    

    What we do here is to send a request to the client.svc endpoint and actually expect to get thrown a 401 back. When we get the 401 we’ll locate the WWW-Authenticate headers and retrieve the Realm property. Yea, that PoSh line could be a bit more prettier and failsafe, but it works on my machine.

    Retrieving the access token

    When we have the realm we can create the authorization code. This is how we combine all our variables into an authorization code:

    [System.Reflection.Assembly]::LoadWithPartialName("System.Web") | Out-Null
    $body = "grant_type=client_credentials"
    $body += "&client_id=" +[System.Web.HttpUtility]::UrlEncode( $clientId + "@" + $realm)
    $body += "&client_secret=" +[System.Web.HttpUtility]::UrlEncode( $secret)
    $body += "&redirect_uri=" +[System.Web.HttpUtility]::UrlEncode( $redirecturi)
    $body += "&resource=" +[System.Web.HttpUtility]::UrlEncode($identifier + "/" + $domain + "@" + $realm)
    

    Let’s walk this through. First of all I load the System.Web assembly, if you run this as a scheduled task this assembly is not loaded in your app domain, compared to when running it in PowerShell ISE for instance, and we need that assembly for some encoding.

    The actual authorization code starts with a grant_type which we set to the static variable of client_credentials, which means that we do not pass any user credentials or refresh tokens. Client_Id is not exactly the same Client Id as above, here we need to append “@” and the realm to scope the request to our tenant. The Client secret and redirect Uri is the same as when creating the app. Finally we have the resource token which is a combination of the SharePoint identifier, the domain and the realm. Note that if you’re targeting the anything in a Personal Site, you not only have to update the $url variable but also the $domain variable.

    We send all this data to the Azure Access Control Services (ACS), remember we did not use Azure AD, endpoint like this:

    $or = Invoke-WebRequest -Uri "https://accounts.accesscontrol.windows.net/$realm/tokens/OAuth/2" `
        -Method Post -Body $body `
        -ContentType "application/x-www-form-urlencoded"
    $json = $or.Content | ConvertFrom-Json
    
    When invoking the endpoint, using our authorization code above, we will get a JSON formatted string back. We convert this string into an object using ConvertFrom-Json.

    Use the access token

    Finally we can use the result from the ACS endpoint and get our access token which we’ll pass into the REST end point (as an Authorization Bearer token) of the site where we want to do operations.

    $headers = @{
        Authorization = "Bearer " + $json.access_token;
        Accept ="application/json"
    } 
    
    Invoke-RestMethod -Uri "$($url)_api/lists/GetByTitle('Documents')/Items" -Method Get -Headers $headers
    

    Summary

    That wasn’t to hard right? All we needed to know was the basic process of OAuth 2.0 and know how to create and pars the requests and responses. The full code sample can be found here: https://gist.github.com/wictorwilen/db67725a66a3e40789e3

  • Finally time for another SSUG meeting in Stockholm

    Tags: User Group, SharePoint

    It’s been way to long since we had a Sweden SharePoint User Group meeting in Stockholm, but the wait is now over.

    On the 26th of February we are all invited to the local Microsoft offices to learn more about SharePoint. Specifically this evening we will be able to hear from Erwin van Hunen, who will talk about the Office 365 Patterns and Practices project. We will also be able to hear from Microsoft about their Hybrid OneDrive for Business experiences. If this doesn’t get you fired up, then what would!

    We are limited to 100 seats, but have a waiting list. You can sign up for the event, starting at 12:00 today (2015-02-11) at the following link:

    https://www.eventbrite.com/e/ssug-mote-stockholm-26e-februri-2015-biljetter-15723746148

    Remember. If you register and don’t plan to show up, please unregister so someone else can take your place. If you don’t unregister, then we’ll call you out on the meeting!

    See you all there!

  • Summing up the year of 2014 and embracing 2015

    Tags: Personal, SharePoint, Microsoft Azure, Office 365, SharePoint 2013

    The time has come for me to do, as I’ve done now for eight years (2013, 2012, 2011, 2010, 2009, 2008, 2007 and 2006), my annual post to sum up the year. It is always fun to look back to what happened the past 12 months. This past year has been a somewhat “in-betweeners” year.

    We (me, my clients, colleagues etc.) are standing on the edge of something big and the bridge over to the other side is really, really long. Some hesitate to pass the bridge, thinks it is to steep down, some people are running across it in fear, some take it just easy and some pass it half-ways and then stalls there not knowing which direction to go. Microsoft has already passed the bridge to the other side, they ran as fast as they could. But, they dropped so many things on the way over, things that I and others need to pick up and fix and very often even remind Microsoft that they dropped it at all!

    Confusing – yes, stressing – hell yea, annoying – yup, new opportunities – oh YEA, wanting to go back – nope!

    Writing

    I think I hit an all-time low in blog postings this year. Not that it has been so little to write, rather that I’ve been having to little time. I have a bunch of posts in the works, that never has been published, due to various reasons.

    According to my telemetry this is what you peeps liked this year:

    I’m really glad that the last two of those posts ended up that high. Really liked working those scenarios out.

    Speaking

    I’ve been fortunate to be invited to a number of conferences the past year as well. The highlight of course is the SharePoint Conference 2014, where I had a total of three sessions. The most awesome experience from that conference was when the room after one of my sessions were empty and people stayed for an hour and a half just asking questions!

    See you in May at the new Microsoft Ignite conference. You can keep up to date on my past and future presentations on this page.

    MVP

    For the fifth time I was awarded the Microsoft MVP Award for my community contributions. Always an honor and passing the five year mark was a bit special.

    Predictions

    Each year I try to predict what is going to happen to us and our business in the future. Last year I talked a lot about SharePoint being a service (six years after the SharePoint Services announcement at PDC08), Azure dominating the cloud space and Microsoft focusing everything on Services. SharePoint may not yet be dead, this product has more lives than a cat. Azure is still growing faster than I can keep up with and I like it! And the Services piece – I think this is the most important of all my predictions last year. Microsoft is focusing on owning the services and the data – the device, product etc. is not the top prio. Take a look at the Microsoft Band – an awesome device but the service behind it is what makes the big difference, no other vendor is even close to competing in that space.

    So, 2015, what will happen? I think I stick to my Services, services, services prediction. 2015 is all about the services! I’ll leave it to that. If you don’t understand how the services will change our business you better look for a career change.

    What’s next?

    I have to admit that 2014 was not one of my favorite years, due to multiple reasons. I’ve been pretty tired of this whole “SharePoint & Office 365” situation and it has taken me some deep reflections and analysis to get my inspiration back. But 2015 will be a really interesting year. Too keep you on the hook a little bit more, head back to this blog on Friday!

    Happy New Year!

    I whish all of you a Happy New Year and I hope that your 2015 will be an awesome ride!

  • SharePoint MVP AMA on October 29th

    Tags: SharePoint, Office 365

    You should mark the 29th of October at 1pm EST (18:00 CET) in your calendar. The MVP Chats are back!

    A couple of years back we regularly held MVP chats where anyone could ask SharePoint MVPs anything (almost at least). These chats was really successful and we received really good feedback. Unfortunately the tool we used for the chats was abandoned and we have been looking for a new way to do this. We think we’ve found a really interesting format for this by using the AMA format at Reddit (/r/sharepoint).

    [Update 2014-10-29]: The thread is located here: http://www.reddit.com/r/sharepoint/comments/2kojof/ama_time_we_are_a_bunch_of_microsoft_mvps_for/

    There will be at least fifteen SharePoint MVP’s answering YOUR questions so feel free to tune it the 29th. We will try to make sure that at least one MVP answers your question, the ones most skilled in the topic of the question, and we’ll make sure that not everyone answers it (which normally is an issue with forums like this).

    We will have experts from infrastructure, to design, to development, to no-code (all definitions of that!) solutions and more, for both SharePoint and Office 365 This will be a great opportunity for all of you to finally get that hard question answered.

    If this turns out to be a successful event I’m pretty sure we will do it again! And to get as much questions as possible, spread the word and use the hashtag #spmvpchat.

  • Speaking at Share-The-Point Southeast Asia 2014

    Tags: Conferences, SharePoint, Microsoft Azure

    See you there!I’m so excited to be once again going to Singapore and speak at the Share-The-Point Southeast Asia 2014, held November 25-26 2014. It is one of my favorite conferences and this will be my third time in the awesome country and city of Singapore! Everything is just great about this; the people, the speakers, the attendees, the city, the food – you name it!

    This year I will have two sessions:

    • Using Microsoft Azure for your SharePoint and Office Apps
      One of my personal favorite sessions, scenario based and packed with demos showing you tips and tricks, awesome Azure features and lots of code.
    • Building out your SharePoint Infrastructure using Azure
      Another really interesting session where I’ll walk you through the pros and cons, the do’s and don’ts of hosting your SharePoint infrastructure in Azure.

     

    If you are planning to be close to Singapore during those days you should make sure to get your conference passes as soon as possible! OR, if you have trouble convincing your boss about what you and your company will miss if you bail out of this, leave a comment (with your e-mail) and the first three persons will get a free pass (full attendance to the 2 day event, including catering and access to the exhibition area and all sessions) – what are you waiting for?

About Wictor...

Wictor Wilén is the Nordic Digital Workplace Lead working at Avanade. Wictor has achieved the Microsoft Certified Architect (MCA) - SharePoint 2010, Microsoft Certified Solutions Master (MCSM) - SharePoint  and Microsoft Certified Master (MCM) - SharePoint 2010 certifications. He has also been awarded Microsoft Most Valuable Professional (MVP) for seven consecutive years.

And a word from our sponsors...