Double AD profiles in User Profile Service?

This is directly related to working with Claims.

The user profile service imports AD accounts and sets the 'identifier' of the object to be the sAMAAccountName (This is the AD property which looks like sampledomain\johndoe).

When a claims web app accesses the User Profile service, such as for example MySites, if configured to use Claims, it looks for the User Profile service by it's own identifier, which is the token in a format like this:  i:0#.f|ldapmember|johndoe

The object will not be found, and MySites will generate the user profile and set the url to the personal site (yet another property in User Profiles), and this is how you end up with two records that refer to the same person, such as below:

The first one is the one generated by the User Profile Service, with properties such as First name, Last Name and other properties you have mapped to be imported from AD, while the other profile is the one generated by MySites, and only has the token and the URL set to the personal site.

The solution is to map the two identifiers to each-other so that when a claims-based app queries the User Profile service, it finds the profile by token.

The first property, Claim User Identifier, refers to the token and the mapped AD property called sAMAAccountName refers to the format domain\user.

Once mapped, any user profile action will follow this rule. For already existing duplicate accounts, the duplicate token one needs to be deleted for clean-up.

The new MySite generations should look like this:

This solution assumes that when you set up the UPS AD connection, you configure it as well as Claims:

Migrating CSV data into SharePoint lists

A common migration scenario of data into SharePoint involves CSV files to be imported via Datasheet view into SharePoint lists.

However there are some limitations such as multi-lookup values, where data should be provided in the following format: "5;#technology;#3science;#". The same format has to be provided for columns of type 'People or Groups', such as "67;#John Doe;#123;#Anne Jackson;#". As a result, you cannot use DataSheet view and you have to upload the CSV programmatically.

This post focuses on reading the CSV file programmatically. You have two options:

• if you use Powershell, you can use the PS command import-csv and then access the data like this:
  
  import-csv c:\folder\file.csv
  foreach($line in $excelFile){$title = $line.name 
  
• if you use C# you can read the CSV file via a OLEDB driver you need to install locally, to permit your 64-bit code (you have to run on 64 bit to be able to execute SharePoint API calls for the actual lookup of values and list item creation).
  
  You can find the driver here Microsoft Access Database Engine 2010 Redistributable.
  This driver is simply a replacement for JET OLEDB to be run on server applications. JET is only running on 32 bits.
  
  

  string connectionString = @"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=c:\folder_name\;Extended Properties='text;HDR=Yes;FMT=Delimited'";

  
  
  string excelSheetName = "file.csv";
  
  
  OleDbConnection myConnection = new OleDbConnection(connectionString);
  myConnection.Open();
  OleDbCommand myCommand = new OleDbCommand("Select * from " + excelSheetName + ";", myConnection);
  OleDbDataAdapter adapter = new OleDbDataAdapter(myCommand);
  adapter.Fill(ds);
  
  
  myConnection.Close();
  
  

How to use SharePoint's OOB error page to show a friendly error message

In many cases, such as a feature activation, it is best to not overwrite the out-of-the-box error page with a custom one, but have the page show a custom message such that users know where the custom code you wrote, failed.

Envision the following scenario: you have an OOB site collection and on custom feature activation, you try to:

• bind custom fields deployed by the feature to a metadata term store
• add these custom fields to content types
• create subsites programmatically
• set permissions programmatically, etc.

Wrap each action in it's own try-catch statement and inside the catch call your custom Error Handler  method that writes to the ULS logs.

In addition to writing to the ULS logs, have your method also do a forced Response.Redirect to the OOB error page, with "ErrorText" in the QueryString object:

  //write to log first, then:

   string idcurr = CorrelationId.GetCurrentCorrelationToken().ToString();

   errorMessage = HttpUtility.UrlEncode(errorMessage);

   HttpContext.Current.Response.Redirect("/_layouts/error.aspx?ErrorText="+ errorMessage + "&ErrorCorrelationId=" + idcurr);

The ErrorCorrelationId QueryString parameter will ensure that the ID you see on the error page matches what you see in the ULS logs.

But the actual Error Handling, if custom, will generate it's own ID when writing to the logs.

It is necessary for these two to match, basically for the code to associate the custom Error message generated with the ID shown on the page.

The only way to grab the latest CorrelationID generated is to grab it via this class, and I am referencing this blog where I found the solution to the issue:

http://www.wictorwilen.se/Post/Working-with-SharePoint-2010-Correlation-ID-in-PowerShell-and-code.aspx

public class CorrelationId

    {

        [DllImport("advapi32.dll")]

        public static extern uint EventActivityIdControl(uint controlCode, ref  Guid activityId);

        public const uint EVENT_ACTIVITY_CTRL_GET_ID = 1;

        public static Guid GetCurrentCorrelationToken()

        {

            Guid g = Guid.Empty;

            EventActivityIdControl(EVENT_ACTIVITY_CTRL_GET_ID, ref  g);

            return g;

        }

    }