When you install the SharePoint BI stack, you need to create a PowerPivot Service application that will manage the PowerPivot workbooks via a very nice dashboard which unfortunately was empty in my Central Admin. no error, nothing in the ULS, just an empty page.

To fix that, I activated the PowerPivot Administration feature in Central Administration :

 

And I got this :

Hope this will help somebody.

How to move a content db from a SharePoint Dev farm to a SharePoint test farm.

step 1. backup the dev farm content db

step 2. go to your test farm, copy the backup to the SQL Server backup location

If you don’t know the default SQL server backup location, start SQL Server Management Studio (SSMS), right click on the SQL Server Instance (in my case :CONTOSOSERVE\SHAREPOINT); and select “Default Settings” as illustrated below:

step 3.Restore the db by using the sql server restore tool (in SSM)

Click Devices, select your backup file.

Go to Options

• select  “overwrite the existing database”
• unselect “take tail-log backup before restore”
• select “close existing connection to destination database”

Click ok to start the restore.

When the restore is done, make sure the db shows up in SSMS (refresh the window).

Step 4 Fix the security

Now if you take a look at the restored db, you will quickly notice that the security associated with the previous farm is still there :

the dev farm domain is DC07, the users DC07\SPFarm (in this case the developer uses the farm admin account for the application pool account, which is of course not recommended in production)

So we need to fix that AND we also need to associate this database with a clean web application (let’s say that you just created a new clean web application , then use Central Admin-Application Management-Manage Content Database, select you web application, click on you content database name, select remove the db and click ok ).

the powershell commandlet Mount-SPContentDatabase is supposed to do that :

in the SharePoint PowerShell command line, type

 

[For your info, if the database is already mounted, you will get en error message, use Dismount-SPContentDatabase before using Mout-SPContentDatabase ]

Now the interesting step is to take a look at the database security folder : the web application pool service account CONTOSO\sp-d-content AND the farm account CONTOSO\sp-d-farm are now authorized in the db.

CONTOSO\sp-d-content has the SPDataAccess role membreship and

CONTOSO\sp-d-farm has dbowner and SPDataAccess role memberships

 

To make sure that your content db is logically associated with the web application, go to Central Admininistration and as we dit before select the Manage Content Databases menu item in Application Management-Databases.

In order to use the site collection(s) in the new content database, you still have to go to Central Administration and specify the site collection administrators.

 

Step 5. It can happen that some list items are not visible in the new farm even if you are site collection administrator : in this case, make sure that the option Manage files which have no checked in version in your document library settings :

 

This option is tricky because it doesn’t show just the checked out documents, but it shows the document that haven’t been checked in yet ( like versions O.1).

Easy…

A week after the SharePoint Summit (Quebec) I had the pleasure last week to present a session on SharePoint 2013 and Business Intelligence with my partner in crime and colleague isabelle Van Campenhoudt (SQL Server MVP); the slide deck can be downloaded here.

les slides de ma session worflow SharePoint 2013; il est très rare que je donne des sessions en français… 

At the moment you will find many examples illustrating how to call external JSon web services from  SharePoint Designer 2013 workflows by using the Call activity, but we should keep in mind that the Call action works very well with the SharePoint REST api and this opens the door to plenty of possibilities. However you won’t find many examples illustrating this. Sooo let’s go  ; –)

• Create an announcements list and let’s say we want to create a workflow that returns the first one by using the REST api.
• Add a few announcement
• Start SharePoint Designer 2013 and add a list workflow on this announcement list; make sure the workflow is a SharePoint 2013 workflow

• Test your REST call in the browser, for instance mine is the following :

http://litware/_api/web/Lists/GetbyTitle(‘announcements’)/items

You should get something like this:

 

You will notice that the response is encoded in xml format; since the $json option  is not supported in the SharePoint 2013 REST api, to get the the response in a JSON format you will have to update the Accept and Content-Type http headers of your Rest http call; more specifically :

Accept : application/json;odata=verbose

Content-Type : application/json;odata=verbose

Even if my favorite browser is IE10, I will user Google Chrome to achieve it; start Chrome and install the following Chrome add-in :

 

When the add-in is installed, you should be able to find the following icon that will allow you to set up your headers

After typing your request request in Chrome you should get the info encoded in JSON

To have a better understanding of structure of the Json response , I usually paste the results in the following JSon parser available online : http://Json.parser.online.fr

 

d/results(0)/Title should be the path of the first announcement title.

Now, let’s get back to our workflow in SharePoint Designer 2013 :

we need to create the Request header, and this is possible by using a Dictionnary :

• In the existing Stage type Build…

• rename the variable dictionnary as JSonRequestHeader :

• Click on this and click on Build your dictionnary ; add the Accept and the Content-Type headers :

• Now let’s focus on the Http request by adding a Call action

• Click on this and paste your http request

 

• To associate the JSonRequestHeader variable, select the Call action property:

• set the RequestHeaders property to JSonRequestHeader:

Click ok.

• In the  Call action, click on response and associate the response to a new variable : JSonResult (of type Dictionnary).
• After the Call action add a new Get action.

• Add a log activity and display the myTitle variable in the log :

• The final Stage should look like this :

Publish and run the workflow; in the workflow history, you should find your first title :

Creating and using content types in SharePoint is often considered as the best practice; however SharePoint workflows created for SharePoint 2013 cannot be associated anymore with content types.

This is a very important point to consider if you are moving to the new platform

In MSDN you can read “Unlike previous versions, SharePoint 2013 does not support workflows that are scoped to a content type (SPContentType). However, the messaging infrastructure is extensible, so it can support any arbitrary scope. As a developer, you can set the EventSourceId property on a given WorkflowSubscription instance to any guid. You can then use that EventSourceId value to call PublishEvent(Guid, String, IDictionary<String, Object>), which triggers a new workflow instance of the specified WorkflowSubscription.”

I will illustrate this in a future post.

If you want to get content types support out of the box, you have to create SharePoint 2010 workflows in SP 2013.

SharePoint 2013 provides a new and improved SharePoint Designer action the Start a Task Process.

To learn more about it, just follow the excellent youtube video authored by SharePoint MVP Laura Rogers.

I’ve recently tried this activity and one of the issue I’ve faced is that when you assign this task process to a (SharePoint) group of people, the workflow get suspended or cancelled (with an error).

For instance, I’ve tested the following very basic workflow on my Office 365 preview site collection :

 

 

In my specific case Approvers is a SharePoint group containing the following users :

When I start my workflow as a site collection admin everything works well, but when a simple contributor (member) starts the workflow, he get the following error :

TYpe this request( _vti_bin/client.svc/Web/SiteGroups/GetById(12)/Users)  in the browser returned this :

This is clearly a permission issue; therfore the best way to fix it is to use the new App Step provided in SharePoint Designer 2013

Basically the App Step is a great way to provide elevation of privilege in SharePoint 2013 workflows (at least in SPD 2013).

Even if a workflow is not an SharePoint App, it can behave like an app (and can be part of an app)

To provide more privilege to your workflow, go to your site settings and select site app permissions :

 

All workflows are associated with the (virtual) app named workflow; select the appid (between the second | and the @)

 

Copy this string on the clipboard, and  invoke the page appinv.aspx :

 

The following form will show up :

 

Past your app Id in the app id textbox and click on the Lookup button:

Now in the App permission textbox, provide the permission you need For instance if you want the workflow step to have full control on the site collection, just provide this :

 

<

AppPermissionRequests>

<

AppPermissionRequest Scope="http://sharepoint/content/sitecollection" Right="FullControl" />

</

AppPermissionRequests>

 

Click Create and trust the workflow:

Now, go back to SharePoint Designer 2013, edit your workflow and you will notice that the App Step action is now available in the ribbon :

Reorganize your workflow by moving the Start a task process into an App Step :

Publish your workflow and test it with a Contributor and it should work now.

 

I just did follow the 4 hour (live from Redmond & free) course available here and I really enjoyed it :

Here are the slides of my presentation on Apps for SharePoint 2013 @Ephec (Ecole Pratiques des Hautes Etudes Commerciales), Brussels.

3 years in a row, I kinda feel home in Canada: next month, I’ll present the following session :