Bugfix: DatePicker (datovelger) mangler piler

En kunde har en SharePointløsning onPrem med ganske tøff branding laget ved Composed Looks. Plutselig fikk vi problemer med dato-velgeren i skjemaer, opprettelse av nyheter og annet innhold er brukerne selv skal sette en dato. Problemet var at de små pilene som lar deg bla frem og tilbake mellom månedene plutselig var borte. Denne lille pop-up boksen med oversikt over den aktuelle måneden er faktisk en egen iframe; og derfor når jeg den ikke med CSS fra min custom CSS-fil i masterpage gallery. For å nå denne lille boksen ser jeg ingen annen mulighet enn å ty til jQuery – for det fungerer!

Les mer fra dette innlegget

SharePoint Online with WebDav and SSO

This post explains how to get a smart link which persists authentication, scroll down to the wrap-up if you’re just looking for a quick solution.

We recently had an interesting situation with a customer. They are using SharePoint Online (or to be more precise, Office365) which is federated with their own domain and using their own domain name for the SharePoint sites. They have Single Sign On working by using a portal for authentication and redirection to the Microsoft Online Services with smart links ( http://community.office365.com/en-us/w/sso/using-smart-links-or-idp-initiated-authentication-with-office-365.aspx ).

So what’s the twist?
The thing about the users in this company is that they like to open document libraries in Windows Explorer, using the «Open in explorer» button in the SharePoint library and then dragging the URL to the left-hand shortcut tab in Windows Explorer (folder names blurred on purpose):WebDavShortCut

This function works pretty good now, unlike a couple of years ago which many of you may remember (WebDav has been a source of frustration for many sysadmins over the years), but it has one major drawback:
When the security token issued for the SharePoint Online site expires, you will no longer be able to open the document library in Windows Explorer. In fact you’ll get an error message which can be caused by several different root causes, and might send you off on a wild goose chase, trying to find out what’s wrong with the Internet Explorer settings, why the ADFS-server isn’t accepting your credentials, and others (see the following blog ). The reason for this is the Forms Based authentication used by SharePoint Online, and Windows Explorer does not have a function to authenticate automatically with forms based authentication. This means that you’ll have to re-authenticate against that SharePoint root site to be able to browse the WebDav folder again.

NOTE! The security token accepted for a SharePoint site is bound to the site’s domain URL (eg: example.sharepoint.com/site1 and example.sharepoint.com/site2 uses the same security token, but example-my.sharepoint.com does not use the same token as example.sharepoint.com). This means that you’ll have to open the correct root site to get a valid token.

So how do we communicate this to end users? The answer is you don’t, and the solution is easier than you might think. When a user tries to access their company’s SharePoint Online site they may enter https://example.sharepoint.com, which will give them the following log on screen (sorry for the Norwegian version):

That’s why we use smart links, because they allow us to send the domain information so we get redirected to our ADFS (presumably) server and authenticated, without having to type our username:


The issue with this is that the security token issued will not be persistent (Remember me), which means that the WebDav folder will still not be accessible, even though you’re logged in to SharePoint again. So what I did was start up Fiddler, and I checked the web requests sent from Internet Explorer when I logged in the «hard way» with persistent authentication (Remember me). What I found was that the Microsoft Online portal redirected me to our ADFS-server with an insane URL (whitespace inserted to make the blog post readable):
https://sts.example.com/adfs/ls/?cbcxt=&popupui=&vv=&username=user%40example.com&mkt=&lc=1044&wfresh=&wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline&wctx=wa%3Dwsignin1%252E0%26rpsnv%3D3%26ct %3D1967435096%26rver%3D6%252E1%252E5474 %252E0%26wp%3DMBI%26wreply%3Dhttps%253A %252F%252Fexample%252Esharepoint%252Ecom %26lc%3D1044%26id%3D5878324%26%26bk%3D14327786597%26LoginOptions%3D1

Now, this might look like a hash or some obscure meta-information at first, but what you can get from this is that the portal redirects you to your ADFS-server, with the original request as a reference (which is used by the ADFS server to redirect you back to Microsoft online with a reference to the SharePoint server you’re trying to reach, which makes the Microsoft Online portal redirect you to SharePoint Online. Like a merry-go-round of authentication madness). The interesting part is the last bit, which says LoginOptions%3D1, where %3D is code for the equals (=) sign, and 1 is a value (duh). So I ran the request again with the Remember me box unchecked, and to nobody’s surprise this gave me the exact same result, except with LoginOptions%3D3 at the end.

Huzzah! We have a 380 character string we can use as for reathentication……
Not quite. To make this simpler without using a webserver and a vanity URL (in which case I recommend using this insanely long URL to reduce the redirect madness with one hop. As long as single-sign-on is working with your ADFS server you can use ‘domain.com’ instead of ‘user%40example.com’ to prevent confusion), just take the last part of the URL and add it to your smart link:

Now, just add that URL as a favorite in Internet Explorer, in a log-on script (remember to specify IE as the browser), set it as the home page, or however you want to do it and users will be able to easily re-authenticate and continue to browse their WebDav directories.

On a side note, should we allow our users to keep traversing folders like it’s 1999? Why not use the functionality SharePoint gives you instead, and demand that your system owners and/or Microsoft Partner optimize search and browsing experience instead of letting users make mistakes by dragging/moving folders all over the place using Windows Explorer? The easy answer is ‘Use search!’, but in reality you have to find out if users are ready to change the way they work, and this ‘quick fix’ will make things much better for a low cost until you decide to move things forward. Manually browsing filesystems can be useful, but more often than not what you’re doing is looking for files you don’t really know where are, so why not use the functionality you’ve already payed for?


The wrap up
To get single-sign-on with SharePoint Online by using a single URL to do the job, simply enter your company’s details in the following URL (replace the orange text) and use that to make it easy for users to log in and stay authenticated (for 8 hours or until the browser cache and cookies are cleared, whichever comes first):


Written by

Marius Agur Pedersen
Super Potato at Skill AS


Server-based SharePoint integration error: List does not support this operation


The newly released server-based integration between Dynamics CRM and SharePoint allows for a quicker and easier setup of document management in CRM. Previously, a SharePoint solution file (listcomponent.wsp) had to be installed on the SharePoint server in order for the two systems to communicate with each other. Now, all you need is an administrator account on both tenants, a copy-paste and a few clicks. This setup process is covered here http://technet.microsoft.com/en-us/library/dn531154.aspx under “Enable server-based SharePoint integration”.

The issue

On a Dynamics CRM Online tenant that had been connected to a SharePoint 2013 Online tenant via the List Component for some time, the server-based integration was enabled because it offers a visual improvement compared to the existing integration. Upon navigating to an Account to view the new, fresh look of the SharePoint iframe, we were met with the following error message in place of the document library:


In English language packs, this error translates into «Error. List does not support this operation». Not the most vague error message Dynamics CRM has produced, but it ranks quite high on the list. As this setup is irreversible, it had to be fixed in order for the integration to work.

After trying any and all combinations of absolute and relative URLs in the SharePoint Sites options, checking and re-checking that the path to the document library on SharePoint and the path that CRM refers to matched perfectly and playing around with display names in CRM, Dynamics CRM MVP Rhett Clinton came through with a solution on the Dynamics Community site. Strangely enough, the issue was related to the display name of the SharePoint site that contained the Account folders. The actual URL of the site matched the one referenced from CRM; «https://x.sharepoint.com/sales/customers/account/». Behind the scenes, however, the SharePoint site display name was «AccountDocuments» while the display name of the entity in CRM is «Account».


Because of this slight mismatch the SharePoint iframe would not compile the list of files in the library, effectively breaking the integration between Dynamics CRM and SharePoint.



Although this was not required for the List Component-based integration, the server-based integration requires a perfect match between the display names of the Account entity in CRM and the site containing the Account libraries on SharePoint. This would also be the case for any other entities for which document management has been set up. It would also be the case for any other language packs on CRM, as the issue is based on the display name of the entity.

Note: Custom security roles need to be configured in order for users to see the Documents button. See http://crmandcoffee.wordpress.com/2014/06/07/crm-2013-leo-lost-documents-button-after-enabling-server-based-sharepoint-integration/ for more information.


Insufficient Privileges Dynamics CRM 2013

Introduction (summary at the bottom)

As we all know, Microsoft CRM is the best CRM system (direct quote: Amund Breda 2013), and to be the best CRM system it has to implement cool, new features with regular intervals. One of the coolest new features added in the last year is the Business Process Flow, a new kind of process entity which allows users to create new objects in a flow based interface which guides the user through the process by implementing phases and steps. This is an example on how Microsoft listens to its community and give us what we want.

The downside to being such a massive, brilliant application is that they have to think about the consequences of the different implementations. Not only are the components dependent on each other, they also need to analyze performance and usability impact for everything they want to implement. In addition, they need to write material for users, customizers and administrators to let us know how they recommend using their solution, and how we can utilize the customization and extension options.

So what happens when Microsoft’s intentions change between versions? That’s when we experience confusing errors like this.


We have a Microsoft Dynamics CRM organization which was upgraded from Dynamics CRM 2011 to Dynamics CRM 2013. After the upgrade some users complain about an error which occur seemingly at random, where they get an error message in the web page saying «Insufficient Privileges» when they try to open different objects in CRM. This happened on contacts, accounts, leads and other objects, but not necessarily for all objects of a specific type. What I found was that all users who experienced this problem belonged to the same business unit, and the users who didn’t experience the problem in that business unit all had roles like «system customizer» and «sales manager». The users who experienced the issue all only had custom or customized security roles. The next step was that I checked which built-in security roles the users had, which was a customized and imported version of the «salesperson» security role. The reason for the import was that all customization was done in a test/development environment, and then imported into the production environment (nothing new about this). So I exported this security role along with a normal salesperson-security role from another business unit to compare the security settings.

What I found was that the built-in, non-customized salesperson security role had read permissions to «process configuration», but the customized security role did not. I performed a test where I would log in with a sales manager user and create a new object using a Business Process Flow, and before finishing I would save and close the object. Then I logged in with a user that had the customized roles, and try to open the object. As expected this caused the issue with insufficient privileges. So I logged on with a system administrator and gave the customized «salesperson» security role read permissions to «process configuration», and created a new object like before using a business process flow. Then I logged back in with the user who experienced the issue, and lo and behold, the record opened like it should. So I wrote a quick change request and implemented the fix, and we told the users to let us know if they experienced the issue again, which have yet to happen.


When a Microsoft Dynamics CRM 2011 organization is upgraded to Microsoft Dynamics CRM 2013 the built-in security roles automatically have access to read the process configuration. This is needed for a user to be able to use business process flows, as the BPF is implemented by Microsoft as a process entity. To make sure your users don’t run into this issue you’ll need to either use a built-in security role that has read permissions to the process configuration, or create a custom security role specifically for this purpose.



Bli med Skill på GOBI 2014!


Skill gir deg 20% rabatt til GOBI2014!Gjør deg klar for Norges største BI konferanse: Gurus of Business Intelligence (GOBI). Du får høre masse om det raskest økende området innen BI, Visual Analytics, med demoer, foredrag og til og med en data visualization challenge fra scenen.

GOBI arrangeres for andre gang mandag 2. juni i Oslo Spektrum.

Spar ytterligere kr 1000,- innen 30. April

Skill er stolt medarrangør og vi har forhandlet frem en god partnerrabatt som vi ønsker å dele med deg!

Kjøp din billett via http://gurusofbi.no/register_gobi, og benytt vår partnerrabatt: SKILL14. Da får du 20% avslag på gjeldende pris. Husk også at EarlyBird  billetter selges  tom. 30. april, og da sparer du ytterligere kr 1000,-

Opplev GOBI sammen med oss – vi tror du får stort utbytte av å delta!

Sharepoint 2013 Branding – Where to start


Composed Look er best practise for tematisering av SharePoint 2013. En Composed Look er satt sammen av en masterpage, en .spcolor-fil, en .spfont-fil, og et bakgrunnsbilde. Legger du til en .preview-fil med samme navn som masterpage og setter opp logo i løsningen har du en brandet SharePointløsning uten å røre ved originale SharePointfiler som gir høy verdi for kunden. I denne bloggartikkelen viser jeg deg hvordan du gjør det.. Les mer fra dette innlegget

Standardfonter i Sharepoint 2013

Som standard kommer Sharepoint 2013 med 8 ulike fontsett. De kan du velge mellom når du setter sammen en Composed Look (N: Sammensatt utseende). Det er ingenting som indikerer hvilket fontsett som finnes i de syv ulike .spfont filene, så her har du en liten oversikt: Les mer fra dette innlegget


Få nye innlegg levert til din innboks.