Upload files to libraries using SharePoint services

We can use copy.asmx SharePoint web service to upload files when we can’t use SharePoint object model.
It’s very simple. you need to do something like below.

   1: const string webUrl = "http://sp13:8080/sites/hr/";

   2: const string sourceUrl = @"C:\Copy\emp.doc";

   3: string[] destinationUrl = { @"http://sp13:8080/sites/hr/Documents/emp.doc";

   4: CopyService.CopyResult[] resultArray;

   5: byte[] fileContents;

   6:  

   7:  var copyService = new CopyService.Copy

   8:   {

   9:     Url = webUrl + "/_vti_bin/copy.asmx",

  10:     Credentials = System.Net.CredentialCache.DefaultCredentials

  11:   };

  12:  

  13:  

  14:  var filedInfo = new CopyService.FieldInformation

  15:   {

  16:     DisplayName = "Title",

  17:     Type = CopyService.FieldType.Text,

  18:     Value = "Test"

  19:   };

  20:  

  21: //add values to fields in the library using fieldInfoArray array

  22: CopyService.FieldInformation[] filedInfoArray = { filedInfo };

  23:  

  24: //upload file using a file stream

  25: using (var stream = new FileStream(sourceUrl, FileMode.Open, FileAccess.Read))

  26:  {

  27:    fileContents = new Byte[stream.Length];

  28:    var read = stream.Read(fileContents, 0, Convert.ToInt32(stream.Length));

  29:    stream.Close();

  30:   }

  31:  

  32: var copyResult = copyService.CopyIntoItems(sourceUrl, destinationUrl, filedInfoArray, fileContents, out resultArray);

Disable offline synchronization for all libraries with specific template

Recently we got a requirement to disable offline synchronization for all Picture Libraries in a web application. Reason for the exclusion was that, those libraries contain large amount of pictures which take long time to download to the client.
We use following PowerShell script to disable offline synchronization for all Picture Libraries currently exist in the web application

   1: Start-SPAssignment -global

   2: $webs = Get-SPWebApplication "http://sp13" | Get-SPSite -Limit All | Get-SPWeb -Limit All | Foreach-Object { 

   3: Foreach ($list in $_.Lists | Where-Object { $_.BaseTemplate -eq "PictureLibrary"}){

   4:  $list.ExcludeFromOfflineClient=1; 

   5:  $list.Update()

   6:  }

   7: }

   8: Stop-SPAssignment –global

As a result, the synchronization process skips Picture Libraries

Configure SharePoint People Picker to include One-way trusted domains

If you have multiple one-way trusted domains in your SharePoint environment, you should explicitly configure people picker control. Otherwise users from those domains will not be searched.
To configure the people picker you need to follow these steps.

Configure encryption key
You need to type below command in each WFE servers

STSADM.exe -o setapppassword -password "key"

Configure people picker
Then you need to execute below command with privileged user for each domain. This command will configure people picker per web application and zone.

STSADM.exe -o setproperty -pn peoplepicker-searchadforests -pv "forest:sp.local;domain:apac.contoso.com,apac\user,*****;domain:emeia.contoso.com,emeia\user,*****" -url https://www.sp13

That’s all !. Now you can  search for users in one-way trusted domains in your people picker

Convert claims based login name in SharePoint

In SharePoint 2010 and 2013 we can have classic mode authentication as well as claims based authentication. In a classic mode scenario, if we get LoginName for a SPUser object it would result something like “Domain\LoginName”

But if the web application is configured with claims based authentication it will provide us something like “i:0#.w|Domain\LoginName”.

Let’s say we don’t need the prefix (e.g: i:0#.w ) and require only the valid login name portion (in this case Domain\LoginName). How do we get it ? Will something like below work ?

   1: var user = @"i:0#.w|dev\john";

   2: var encodedUser = user.Split('|')[1];

OK. it will work, but for this scenario only.

This is because that claims based environment is highly scalable where you can plug so many authentication providers. If you plug another authentication provider instead of windows authentication you may get different forms of encoded strings. Let’s assume you have federated authentication using email as login you would get something like below for LoginName

   1: i:05.t|Azure|myemail@gmail.com

You can see that string operations (e.g:split) we’ve used in above code will not work for this scenario. Furthermore there are so many other claim representations as well for other providers. You can get a complete list by referring this post from Wictor Wilen’s blog.

What is the recommended way to decode claims encoded string. We can get the help from “SPClaimProviderManager” class. Following code will decode claims string.

   1: private string GetLoggingName(string name)

   2: {

   3:     var manager = SPClaimProviderManager.Local;

   4:     if (manager != null){

   5:         return SPClaimProviderManager.IsEncodedClaim(name) ? manager.DecodeClaim(name).Value : name;

   6:     }

   7:     return name;

   8: }

It’s better to avoid string operations to decode/encode claims as we don’t know what providers will be plugged or unplugged in our claims environment future.