• Power BI Getting Started Guide : https://office.microsoft.com/en-us/office365-sharepoint-online-enterprise-help/power-bi-getting-started-guide-HA104103589.aspx?CTT=1
• Power BI Overview and learning Resources : https://office.microsoft.com/en-us/office365-sharepoint-online-enterprise-help/power-bi-for-office-365-overview-and-learning-HA104103581.aspx?CTT=1
• The Data Management Experience : https://office.microsoft.com/en-us/office365-sharepoint-online-enterprise-help/data-management-experience-in-power-bi-for-office-365-help-HA104079156.aspx

These will be a really valuable resource if you want to learn more about our new cloud-based BI offering.

For more information and registration, follow this link: https://training.partner.microsoft.com/learning/app/management/registrationex/LMS_Registration.aspx?UserMode=0&Mode=0&ActivityID=838286

I have written another sci-fi adventure, Omega Rising, and decided to self-publish. This means I'm paying for editing, copy-editing, proof-reading, typesetting, formatting, cover design and printing. In order to help contribute to the costs, I've set up a kickstarter project for the book.

Please take a look at the project and, if the book sounds interesting, make a contribution and earn a reward. If you pledge £2, you'll be rewarded with a copy of the ebook. If you pledge £10, you'll get a signed copy of the paperback. Even if it's not your sort of book, a signed copy would make a wonderful present for someone.

View the project here: https://www.kickstarter.com/projects/166261591/codename-omega-omega-rising

Picking up where I left off last year, I’m going to talk about another change in SharePoint 2013 that I think is worth shouting about. This is one of those areas where I got disproportionally excited about a new feature: you can do a loop in a SharePoint Designer workflow.

SharePoint Designer workflows made huge leaps between 2007 and 2010, but one of the things that remained a problem was creating a workflow that let you go back to an earlier point. For example, if you want to have an approval workflow where clicking not to approve goes back to an earlier editing stage. In 2013, this is easy. There is now an option in the menu to insert a loop, which can either be to loop “n” times, or to loop based on a condition. So in that approval example, you can choose to loop indefinitely as long as the document status is “not approved.” With the n times option, n can be set to a workflow variable or document/list property, so the precise number of loops could vary at the runtime of the workflow.

Within your loop, you can set a list of actions and conditions just as any other workflow. You can even have loops within loops.

That’s not the only thing that’s changed about workflow in SharePoint Designer. The visual design experience has been brought inside SharePoint Designer (as long as you have Visio installed) so you can switch back and forth between detailed and diagrammed views of your workflows.

These changes mean you can make your no-code workflows substantially more sophisticated without giving yourself a headache.

The queries that build these documents can be very simple (e.g. searching for a particular word), or very complex (e.g. a query searching for documents of a particular type, with particular properties, featuring certain keywords, filtered based on the user profile of the person viewing the page), or somewhere in between.

However the query has been built, the result looks to the user like a list of documents or list items, much in the same way as the web parts which let you display contents of a particular document library. The concept behind this is similar to the Content Query Web Part from SharePoint 2010. The difference is where the results are coming from. The Content Search Web Part lets you pull results from across sites to give a more comprehensive set of results.

When building one of these parts, you get nice tools like the preview of results so you can make sure your query is bringing back the results you expect before you put it onto the page.

Laura Rogers has written a post on configuring these web parts.

You also have the option to create files for manual translation. As part of the service, the system creates XLIFF files, which is the standard used by translation vendors. If you don’t want to make use of the automated translation, you can take these files to be translated by human beings.

The Machine Translation Services makes it much easier to have global variations. When you create or change sites, you can use Machine Translation Services to automatically translate the pages and content to provide local-language versions of files on the variation site. When creating variations, the use of automated translation is an opt-in selection. It also includes translation of managed metadata terms, so you can use your managed taxonomy but still give people terms in their own language.

Once again, Bill Baer has a nice blog post on the subject.

In SharePoint Server 2013, implementing these mixed license environments becomes a lot easier using the new User License Enforcement functionality.

SharePoint Server 2013 uses claims based authentication by default. This means you can have claims tokens associated with each user and these claims are used to determine authorisation. What you would need to do is make sure you have a claim associated with your users which sets their license level (e.g. this user only has a standard license). You can then block features at runtime based on this token.

The upshot is that you can have a single site containing standard and enterprise features. Using these claims tokens, you can determine which users are able to see which of the features. Web parts using enterprise functionality will either not appear at all or show an error (depending on how the page was built).

In a similar manner to audience targeting, you can show parts of the page based on authorisation – which could be pulled in from AD groups using the user profile sync.

You can also use User License Enforcement to control access to things like Office Web Applications and Duet Enterprise.

Bill Baer has written a nice blog post about this.

The point of Access Services is to take an Access database and put it into SharePoint – giving you the ability to manage, secure and control databases that would otherwise have existed on someone’s hard drive away from the control of IT. To make changes to the database, for example to add new tables or change the columns of a table, you need to open the database in Access, but by putting the database on Access Services, other people can get access (no pun intended) to the data and update records within the database.

This probably sounds very familiar if you’ve done anything with Access Services in SharePoint Server 2010. The difference: in SharePoint Server 2013, an Access Services database is actually a SQL Server database. When you create an Access Services app, SharePoint talks to a SQL Server instance (it has to be SQL Server 2012 but doesn’t have to be the same SQL Server that the content databases are on) and creates tables within SQL Server for the tables in the Access database. What you end up with is a SQL Server database with a user-friendly front-end in SharePoint.

It’s really easy to create an Access Services database in Access – simply choose to create a web app from the start screen of Access. There are various templates for tables, forms, views etc. to get you started. For example, if you choose to add the Orders template, it will create several tables and views for you to track not only orders but the associated products and customers, building in all the necessary relationships. You can also add tables from existing sources – for example a SharePoint list. So you could create a link to a SharePoint document library and reference those documents from within your Access Services table.

The whole Access Services database gets packaged up as an app – the official terminology refers to them as apps rather than databases. This means it’s given its own site within your site collection. It also means you can package it up – so you can develop on one environment and redeploy to another. You can also design something in Access, package it up and put it on the app marketplace.

There is a slight annoyance to the fact that it’s an isolated app. It doesn’t seem to be a direct way to embed items from the Access Services app onto an ordinary SharePoint page. For example, if you want to display an Access form in a web part, there doesn’t seem to be a straight-forward way to do it directly in SharePoint. The answer seems to be to use BCS, which is fortunately easy because, as stated above, the data is in a SQL Server database. In fact, because it’s a SQL Server database, lots of other things (like reporting and AlwaysOn high-availability) which are native SQL Server functionality suddenly gets a lot easier.

If you want to know more about Access Services in SharePoint 2013, there's an overview on TechNet.

First on my list to talk about is shredded storage. This is essentially a way for SharePoint to break documents into chunks in order to make changing documents more efficient and to reduce storage requirements where you have lots of versions of documents.

How it worked with 2010:

In SharePoint Server 2010, if you uploaded a document to SharePoint, that entire document would get stored in the content database. If you wanted make edits, you would open that document, make your changes and then save back to SharePoint. SharePoint would put the entire document into the content database – even if you only changed one typo. This means quite a lot of network traffic if documents are large. It also means that if you have version control turned on that you’re saving lots of copies of the document.

How it works with 2013:

In SharePoint 2013, large documents are broken into multiple smaller chunks, i.e. the document has been “shredded.” If you make a small change to the document, only those chunks that have changed get written back to the storage. This reduces the amount of network traffic between the SharePoint Web Front End and the database server. It also means that when you have multiple versions, those pieces of the document that are unchanged between versions can be reused – reducing your storage requirements.

The idea of this is to make the size of versions equal to the size of the change, not the size of the original document. The upshot is improved performance when there is a lot of editing activity and reduced storage when you’re using versioning.

If you want more information, check out Bill Baer's post on the subject.

As such, it's a nice balance between the whys and the hows of implementing SharePoint on a cloud infrastructure platform.

The paper can be downloaded here: https://www.microsoft.com/en-us/download/details.aspx?id=34598