Microsoft Introduces Location Based Conditional Access for Office 365

Office 365 has always had a concept of access controls based on users and groups.  Microsoft has now taken the concept much further to restrict access not just based on identity but also device profile and location.

Using a set of policies in Office 365 that control access to SharePoint and OneDrive documents, Administrators will be able to restrict access to documents based on IP address or network location.  For example, this would allow administrators to restrict sensitive documents from access outside of the corporate network.

Enhanced conditional access controls encryption controls and site classification in SharePoint and OneDrive 2

Read More

Office 365 Site Collection Limit Expands to 25 Terabytes!

Microsoft has announced the increase of the site collection size limit from 1 TB to 25 TB for Office 365.

Image result for site collection

A Site Collection in SharePoint is an important logical boundary in that it provides a separated zone for sites and content.  The Site Collection in SharePoint controls a number of settings, taxonomy features, permissions and navigation concepts. 

In previous versions of SharePoint, the Site Collection size was limited by the size of the content database.  Content databases were stored in SQL Server and the recommended limit for SharePoint 2007 and 2010 was 100 GB in order to facilitate easy backup and restore of the database.  In SharePoint 2013, the recommended limit was increased to 200 GB with no hard limits on the database size.  In SharePoint 2016, the content database can be 1 TB or greater, with the limitation being your backup/restore solution’s ability to manage the size of the database.

With smaller Site Collection boundaries, organizations were sometimes forced to carve up their collaboration sites into multiple site collections in order to fit within the recommended size limits.  This created some odd governance issues as organizations split up site collections by department, function, etc. without understanding the complexity of doing so.  In many organizations where conduct migrations from previous versions, we found hundreds of site collections. 

With Office 365, Microsoft is now raising the bar again so that a single site collection can store up to 25 TB.  This should simplify collaboration site deployment in particular so that all site collections can be managed within a single site collection if desired.  Given files are also increasing in size (for example, with large video files or engineering files that can take up hundreds of megabytes) the additional room will be welcome to some organizations.

Read More

SharePoint Framework Developer Preview Just Released

In May 2016, Microsoft unveiled a new SharePoint Framework for creating responsive, modular presentation components as a replacement for web parts, app parts, etc.  The framework will be initially released to a new portal experience in Office 365 – I would expect it to be released for SharePoint 2016 on premise as well at some point in the future.

The SharePoint framework-an open and connected platform 3

The new framework is preview only and is available on GitHub here.

Read More

Microsoft Adds Excel Support to the Office 365 REST API

Microsoft has added support for interacting with Excel documents, formulas and reporting through the Office 365 REST API.

Breakdown of tasks in a pie chart

Key scenarios that this could enable include:

  • Reading and writing data to an Excel document stored within Office 365
  • Calling an Excel formula for calculations
  • Having Excel online render a chart or graph based on Excel data

Code samples and documentation are available here.

Read More

Microsoft Unveils New Bookings App for Office 365

Microsoft has unveiled a new application as part of Office 365 that enables businesses to provide bookings for appointments, orders or service requests online as a service to their customers.

Bookings Gif

Bookings is available for First Release customers with roll-out world wide in the next few months. 

Bookings 2

Bookings represents an interesting return to anonymous, public facing web sites since Microsoft shut down the public facing web site as a service option in Office 365.  Customers will not need to authenticate or be an Office 365 customer themselves – they can book with a name and an email address.

Bookings also represents a move by Microsoft to provide more specialized, fit for purpose applications within Office 365 instead of focusing on generic platforms such as document management, search, etc. 

Read More

Microsoft Revamps Office 365 Video Portal with new Microsoft Stream

Microsoft has revamped its Office 365 Video Portal, transitioning it to a new Azure based video services called Microsoft Stream.  In a similar way to how Microsoft has moved Power BI into its own service, Microsoft Stream represents an independent video service that can be used in conjunction with Office 365 or independently as an pure streaming service.

Getting started

The Office 365 Video Portal was baked into the Office 365 subscription plan – it’s not clear how the new Microsoft Stream will be priced either in conjunction with an existing Office 365 subscription plan or independent of such a plan. 

Read More

Updated Visio Stencil for Office 365 Just Released

Microsoft has updated its Visio Stencil for Office 365 that includes a number of symbols for building diagrams related to Office 365.   The stencils can be downloaded here.

image

image

image

The stencils seem to work much better in this version in that the captions appear at the bottom instead of in the middle and they work properly with themes.

Old Version

image

New Version

image

However, I also notice that some of the shapes from the 2012 and 2014 versions have not been carried forward so you may still want these versions of the stencil and they are still available for download.

Read More

Key Considerations when Migrating from SharePoint 2003

We have completed a number of migrations recently, including several from SharePoint 2003 to either Office 365 or SharePoint 2016.  With such an old platform, one is bound to have challenges and any SharePoint migration requires significant planning and testing to ensure content comes over appropriately.

With SharePoint 2003, there are a few additional quirks due to the original architecture of the platform that we have run into that need some additional planning and testing.

Good Luck with Database Migration

In theory, you can do a straight database migration of your SharePoint 2003 content database to SharePoint 2016.  However, there is no direct route – you have to migrate through each version of SharePoint.  From 2003 to 2016, these means you need to hop from 2003 to 2007 to 2010 to 2013 to 2016.

In our experience, leveraging a good third party tool such as Metalogix will help because these tools allow for a direct copying from SharePoint 2003 to 2016 with no steps in between.  We have used this approach successfully and recommend it for very old versions of SharePoint.

Weird URL Structure

SharePoint 2003 doesn’t have the modern friendly URL structures and site paths that you see in modern web sites or later versions of SharePoint.  If you do an inventory of sites, you will see a lot of URLs that are not user friendly such as http://xxx.com/C1/C16 or http://xxx.com/C3/C20.  In our experience, these URLs are not even consistently organized hierarchically, e.g. you cannot assume that C1/C16/default.aspx is a subsite of C1/default.aspx.

This will pose a challenge when migrating because it means your sites will need to be remapped as they are copied over – ideally replacing these arbitrary URLs with more friendly ones.

This is also a change management problem because SharePoint 2003 didn’t have any concept of social bookmarks or favourites.  End users now likely have bookmarks in their browser or email that will no longer work properly.  As these URLs change, you’ll need a communications strategy to ensure that end users can still find their sites.

One Page per Site

SharePoint 2003 didn’t have the WCMS features of future versions such as SharePoint 2007 or 2010.  Each site in 2003 is a collaboration site only with one default page per site.  In future versions of SharePoint, you can have publishing turned on and enable multiple pages per site.

As a result, you’ll see lots of site proliferation as users created a new site every time they needed a page.  When you move to the latest version of SharePoint, you’ll have to make some decisions on how to rationalize all these sites into a simpler site map that can now support multiple pages in a single site.

Invalid Users and Permissions

How many employees in your organization were working there in 2003?  When we inventory SharePoint 2003 farms, we find many cases where site permissions are assigned to users who no longer work for the organization.  In addition, we find key fields such as Created By or Modified By where the user in SharePoint 2003 doesn’t exist in the new SharePoint 2016 environment. 

Using a good third party migration tool, we can remap these users so that we can flag them for further analysis.  For example, we can create a user called “Invalid” and map any documents or sites that have invalid permissions to that user so that we can find these documents and update them.  We can also provide these tools with mapping so that if in SharePoint 2003 I’m “cwoodill” and in SharePoint 2016 I’m “chriswoodill” we can map the old user permissions to the new account.

Lots of Customizations

SharePoint 2003 was pretty limited, which led to many customizations as users added their own branding, site templates, and views.  These customizations included custom site templates, list templates, site definitions, etc.  In moving to the latest versions of SharePoint, many of these customizations can be retired or replaced with new techniques and designs. 

However, this doesn’t solve the challenge of having thousands of sites which are currently utilizing these customizations and will need to be updated to leverage either new out of the box functionality, migrated customizations or new customizations. 

Migrations are Always High Risk

Migrations are always high risk because they involve a significant amount of technical challenges as well as testing requirements.  With SharePoint, there are multiple layers in the platform that need to be migrated including settings, permissions, customizations, sites and content.  Each of these can require significant testing especially for sites that were heavily customized.

Having migrated several SharePoint implementations in the past 12-18 months, I can attest that migrations are not easy and require significant expertise.  If you need help with yours, feel free to contact me and we can share our experience.

Read More

For SharePoint Development, the Future (and Present) is Clearly JavaScript

We have been working on a custom branded SharePoint intranet and interviewing SharePoint developers as we expand our team.  The historical SharePoint developer who has been working with C#, ASP.NET, farm based solutions, etc. is being clearly replaced by developers who see SharePoint and Office 365 as just another web based JavaScript platform.  When we interview SharePoint developers, we’re asking them about their experience with JavaScript frameworks, CSS styling, MVVM modular design and working with JSOM, REST, etc.  Right now, we’re hiring folks who have experience with CSS, HTML and JavaScript frameworks such as Knockout JS, Angular, React, etc. because this is the type of customizations we are developing.  We haven’t done a lot of C# development lately, except for clients who are still running older versions of SharePoint and want to migrate to SharePoint 2016 but keep their existing farm based solutions, custom workflows, InfoPath forms, etc.

Microsoft has been encouraging this shift from server side to client side development for several years, starting with SharePoint 2010 and dramatically accelerated with Office 365.  When Office 365 banned farm based solutions and server based code, the community shifted to 100% client side development using JavaScript, HTML, CSS, etc.

In SharePoint 2016, you can still use C# or ASP.NET to create farm based solutions but this is primarily for backwards compatibility.  In order to support both Office 365 and SharePoint 2016, it is recommended to use client side based customizations only.

SNAGHTML37902c8c

In the upcoming SharePoint Framework, Microsoft is pushing even further into the JavaScript world.  Gone are web parts / app parts / add-ins as IFrame component containers, replaced by inline JavaScript extensions that are dynamically included in the page.  These JavaScript extensions can be deployed either to Office 365 or loaded from an external CDN.  The SharePoint Framework leverages 100% JavaScript code and tools such as TypeScript, Node.JS, React, JSON, and Gulp for building customizations.  Unlike the current Add-in model, the code is included directly into a page with none of the older IFrame based container frameworks that older versions of SharePoint used. 

The SharePoint framework-an open and connected platform 3

If you are one of these SharePoint/C# developers who still thinks JavaScript is an after-thought language, think again – it should now be considered a first class language.  Microsoft is pushing it hard and SharePoint development is already primarily client side development and will continue to be in the future. 

Read More

Microsoft Releases new SharePoint Client Side Library to Simplify API Use

The Patterns and Practices team at Microsoft has been working for several years on publishing guidance on how to use JavaScript to interact with SharePoint and Office 365.  They have come out with recommendations for replacing old server side farm solutions with pure JavaScript solutions as required as developers transition to Office 365.

The team has just released a new client side library that wraps the SharePoint REST API with a modern JavaScript API layer using TypeScript.  The goal of the library is simplify common developer scenarios and support typical JavaScript constructs such as promises, functions, etc.

Compared to using the raw REST layer and parsing through the complex JSON structures provided by Office 365, this should help simplify the development interaction with the underlying API.

Read More