Friday, December 23, 2016

Some time ago I wrote post Get Sharepoint current datetime in javascript for Sharepoint Online, where described the way how to get current server datetime in javascript and how it works (or to be more precise almost current date time – see below for explanation). Briefly we use _spPageContextInfo.clientServerTimeDelta standard variable which is returned from server in the following form:

And remember that it will be almost current server date time – difference will be in the time between moments when javascript interprets line with initialization of _spPageContextInfo.clientServerTimeDelta variable (see above) and line where you calculate currentServerDateTime.

Friday, December 16, 2016

Recently on several Sharepoint Online sites which belong to different tenants we encountered with similar problem with slowness. Slowness didn’t appear immediately, i.e. from beginning sites worked fast. But after some time response time grew to 6-14 seconds, which made sites almost unusable. First of all we checked SPRequestDuration response header in browser developer tools which shows server response time (see Diagnosing performance issues with SharePoint Online). It showed that slowness is not caused by client side custom components but instead comes from server side because SPRequestDuration had value from 6000 to 14000 milliseconds. All sub sites used OTB seattle.master master page without customizations. After deeper investigation we found that the problem is caused by structural navigation used for left navigation (for top navigation managed metadata navigation was used). I.e. with time number of sub sites in hierarchy grew up and it made structural left navigation work much slower.

We opened ticket in MS for that, but as workaround for this issue you may change left navigation from structural to managed metadata. After we did it on all sub sites (as in Sharepoint single term set with navigation terms can be used on single site, we set managed metadata left navigation on the root site and then inherited left navigation from the parent sites on all sub sites. This approach also has own problems, because in OTB master page only 2 levels of hierarchy are shown. Better approach will is to create own navigation term set for each sub site, but there you also need to think how to keep navigation terms synced with site structure), server response time was reduced to 1 second. In one of the future posts I will describe how you may keep in sync sites structure and managed metadata navigation terms hierarchy.

Wednesday, December 7, 2016

Recently I faced with strange problem: when tried to use Microsoft Graph client library in ASP.Net web forms web application (tried to run it in Azure web site) code hang and Request timeout exception was thrown after request processing time reached timeout value. E.g. if we will use example which I showed in one of the previous posts (see Work with Azure AD via Microsoft Graph API):

thread hang on line 16 when we perform actual call to graph API for retrieving groups:

1: var groups = await graph.Groups.Request().GetAsync();

However the same code worked well in console application even if we would remove async/await from enumGroups method and would call client library synchronously. In ASP.Net web forms it is little bit more tricky. In order to make it work you need to make all methods up in the call stack asynchronous including page itself (see Using Asynchronous Methods in ASP.NET 4.5). I.e. in .aspx file add Async=”true” attribute to the Page directive:

1:<%@ Page Async="true" ...

After that rewrite page method which calls Graph client library in async way:

1:protectedvoid Page_Load(object sender, EventArgs e)

2: {

3: RegisterAsyncTask(new PageAsyncTask(Page_LoadAsync));

4: }

5:

6:private async Task Page_LoadAsync()

7: {

8: await enumGroups();

9: }

(if you have other methods in call stack between Page_LoadAsync and enumGroups you need to make them async as well). After that call to Microsoft Graph client library shouldn’t stuck anymore and should work as expected. There is also similar issue with ASP.Net MVC web applications: Application hang when executing AuthenticationContext.AcquireTokenAsync. Solution is also similar: you have to change MVC actions from sync to async. Exactly this article pointed me to the right direction for ASP.Net web forms, so big thanks to the author.

Saturday, December 3, 2016

Some time ago we faced with strange problem: on one of Sharepoint 2013 sites some users were not shown in their groups’ membership page (Site settings > Users and groups: http://example.com/_layouts/15/people.aspx?MembershipGroupId=groupId). Such users were able to login to Sharepoint and had all necessary permissions, but they didn’t appear on this page. Also need to notice that this site was migrated from SP2007. When I checked groups of the missing user via PowerShell:

1: $u = Get-SPUser -Id "loginName" -Web http://example.com

2: $u.Groups

they were properly returned. Also it worked as expected when I checked it in opposite way: check members of the group:

1: $web = Get-SPWeb http://example.com

2: $g = $web.SiteGroups["Foo"]

3: $g.Users

User was shown there as well. And when I checked permissions via the following useful script which shows both permissions granted explicitly to the user and permissions granted via groups:

About Me

I've created this blog for sharing my technical experience in software engineering. Most of posts will be dedicated to Sharepoint. But I will write also about another areas of software development for .Net platform. Hope it will be useful and will help you in your work.