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

When Migrating InfoPath 2003 or 2007 Forms, Watch out For Legacy JScript

JScript is a JavaScript variant used both by Microsoft browsers (e.g. Internet Explorer) and active scripting engines such as the Macro development engine within Office.  It was originally developed back in 1996 as part of Internet Explorer 3.0 to compete and co-opt JavaScript which was originally part of Netscape, the dominant web browser at the time.  Microsoft also has VB Script which is the default scripting language found in Office products for developing macros.

When migrating InfoPath 2003 or 2007 forms from previous versions, the original developer could have included some JScript code in the form.  This code responds to various events such as the form loading, clicking on buttons, changes to the form, etc.  If you try to load this form in the “latest” (InfoPath stopped being latest in 2013 when Microsoft stopped development on it), you will see this message if you look at the code:

image

Any JScript that was embedded into the form won’t run and isn’t compatible with InfoPath 2013 – Microsoft dropped support for JScript in 2010.  You cannot even open the code to view it – the only option you have is to remove it.

If you want to keep this code, you’ll have to port it to C# by opening the form in a previous version of InfoPath (e.g. 2003 or 2007), scraping out the original JScript code and re-writing it as C# code. 

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

One of the Key New Features in Office 365: Improved Metadata Editing

Metadata is a key aspect to mature document management, yet the user experience in SharePoint has a lot to be desired and hasn’t really changed since SharePoint 2013.

In SharePoint 2013, 2016 and SharePoint Online, it takes several clicks to edit the properties of the document:

imageimageimageimage

As part of the new “modern” document library UI in Office 365, the document information panel now provides a complete history of the document and inline property editing, instead of requiring so many clicks.

Document metadata now available inline—You can now edit metadata directly from the main view in the information panel. No more clicking into multiple screens to apply an update! If you’re in a view that groups files by metadata, you can drag and drop files between groups to update the metadata. And if you miss something required, the document is no longer hidden behind enforced checkout—you just receive a reminder to enter the data when you can.

One-stop shopping for everything about your documents—Thanks to Office Online integration, you can navigate a complete document preview at the top of the information panel. The panel offers metadata, including the history of recent activity, updates to the file and who received a share to the file. You can also add more users or immediately stop all sharing. Finally, all other file properties are displayed, in case there’s anything else not already covered.

This will improve usability and make it easier to adopt taxonomies for end users.

Read More

How Do Latest SharePoint Announcements Impact Custom Branding?

With the latest announcements around SharePoint and Office 365, there are a significant number of user interface changes coming first to Office 365 and eventually SharePoint 2016.  With the latest changes, how does this impact those organizations that want to support custom branding of their intranets? 

Already a Challenge – No Consistent UI Framework

In Office 365, there are already multiple ways to apply themes and custom branding including master pages in SharePoint, themes in SharePoint, Office 365 themes, etc. 

image

In addition, there are areas within Office 365 that you cannot brand at all such as Office Delve, User Profiles, Video Portal, etc.  These “next generation” portals are off limits for custom branding and if you have invested a lot of energy into branding your corporate communications intranet, the experience breaks when they link off to one of these portals.  So my navigation, CSS styling, etc. all disappears when someone goes to Office Delve:

image

Other than changing the Office 365 suite bar colours you’re stuck with this user interface.

New SharePoint Mobile App

Microsoft has announced a new SharePoint Mobile App.  Presumably, the web mobile experience will also be updated.  For the current mobile web experience, if you use collaboration sites your users get a simplified, mobile friendly but completely unbranded user experience.

If you apply master pages and custom CSS, then you’re on your own and SharePoint provides the full original page with your custom branding.  Using this approach allows you to create your own branded pages but you’re also responsible for making them responsive – they break by default on any mobile phone.

With the new mobile app, Microsoft is imposing its own responsive framework, its own user interface, etc. in a stronger way than in the previous model.  It’s not quite clear how your custom web parts, CSS, JavaScript, etc. will be included into the page and how this will then make its way to the mobile phone so stay tuned.

New Publishing Pages Model

Microsoft is revamping the publishing pages model to be closer to sites such as Wix for creating web content pages. 

[New%2520publishing%2520framework%255B2%255D.png]

The new authoring canvas will be easier to use than the traditional SharePoint canvas – more like the new blogging tool in Office 365.

New Development Framework

Microsoft is introducing yet another framework for creating custom web parts.  The new web part (e.g. App Part, Add-In, etc.) model will be client side, TypeScript based and integrated into the new page model. 

The SharePoint framework-an open and connected platform 2

The framework includes a new page architecture that supports custom web parts using client side technologies such as JavaScript.  You’ll be able to use your favorite JavaScript frameworks such as Angular or React or KnockOut to build new web parts. 

The SharePoint framework-an open and connected platform 3

The new SharePoint Framework model also removes the horrible dependency on IFRAMES that were part of the original SharePoint 2013 and SharePoint Online app-part model, which should make it easier to support responsive sites and to embed JavaScript as custom user experience elements.

Key Recommendations on Custom Branding

Based on the current picture, we would recommend the following in regards to Custom Branding and SharePoint:

1. Be prepared for an inconsistent approach to branding – its clear that Microsoft continues to take responsibility over some key components of the user experience and not handing them back to be branded by your corporate communications team. 

2. We’re back in multiple frameworks, different experiences on Office 365 vs. on premise SharePoint, etc.  This will cause lots of headaches for developers building hybrid custom apps, add-ins, branding, etc.  in the near term until SharePoint 2016 aligns with the latest Office 365 frameworks. 

3. If you’re still on SharePoint 2003, 2007 or 2010 and you have server side based custom web parts get rid of them as part of any upgrade.  The current and future direction is 100% client side JavaScript and the sophistication of the JavaScript libraries is continually improving.

4. The new SharePoint Framework, if it isn’t buggy (a big if), could provide some noticeable improvements to the current SharePoint Add-In model.  It’s better integrated into the page, provides better support for modern JavaScript and CSS, and should be easier to deploy than the current model. 

5. You’ll have the option of still using “classic” (e.g. the current) SharePoint pages and your current web parts will continue to work.  Existing custom web parts won’t be able to be deployed to the new pages framework apparently, so be prepared to re-write these components to support the latest user experience.

Stay tuned as more announcements come out!

Read More

SharePoint Team Sites Get a Make Over in Office 365

Microsoft has provided a face lift to SharePoint team sites that enables integration with Office Graph, provides an improved sites home page and integrates team sites with Office 365 groups.

New SharePoint Home Page

“Sites” is now “SharePoint” and the home page has been redesigned to make better suggestions as to sites you can follow and discover.

SharePoint the mobile and intelligent intranet 2

The new home page provides frequently updated sites, suggested sites based on Office Graph and sites you have explicitly followed.

With the new SharePoint mobile app, you can access the same list of sites through your mobile device.

New Default Team Site Home Page

The default team site now has an improved home page that surfaces content such as important documents and activities.

SharePoint the mobile and intelligent intranet 3

Office 365 Groups Now Provides a Full SharePoint Team Site

When you create an Office 365 Group, you now are provisioned a full SharePoint team site. 

New Document Library UI with Support for Pinning

The document library in SharePoint UI has also been redesigned.

SharePoint the mobile and intelligent intranet 5

The new UI supports the ability to pin documents that are important and they show up at the top of the list.

Read More

New SharePoint Mobile App!

Microsoft has announced a new native mobile app for SharePoint.  With support for Windows, IOS and Android, users will be able to access sites, documents, links and people through a simplified mobile user experience.

SharePoint the mobile and intelligent intranet 1

The SharePoint mobile app comes first to iOS, followed by versions for Windows and Android in the second half of 2016. And a planned, future update to the app will bring company news and announcements to your device.

Read More