Microsoft Land

Archive for the ‘Sharepoint 2010’ Category

Inteded to: I am writing this article assuming that the reader is already aware of Claims based authentication, Trusted Identity Providers, ADFS and PowerShell.

Scenario: We are planning to Migrate a SharePoint site from NTLM to Claims based authentication using a Trusted Identity Provider (ADFS). So once the Migration is complete we are going to disable NTLM for the site so that the Users get’s authenticated using ADFS. The Trusted Identity Token Issuer for ADFS is configured with the Claims mapping using the Email Address of the users.

Problem: We have users their roles configured in the current site and we want to migrate those users and roles to Claims and remove the old NTLM users from the Site.

Resolution: Before we get into script let’s see what SPWeb.MigrateUsers (http://technet.microsoft.com/en-us/library/gg251985.aspx) does, and why it will not work in this case, for example

If we have a user CORP\DTOM in the Site once we say $objWeb.MigrateUsers($true) this user will be converted to Claims based user using the OOB Active Directory claims Provider (to see the list of Providers In PowerShell use the Command Get-SPClaimProvider. Get-SPTrustedIdentityTokenIssuer for the list of Trusted Identity Providers). So the converted ID will be i:0#.w|CORP\DTOM. Notice the “w” in the ID which indicates that it’s still being identified as a Active Directory user.  Because claims is enabled on the website MigrateUsers converted the LoginID to Claims based LoginID. It actually has to be converted to i:<<some number>>#.t|<<providername>>|<<ClaimsMappingValue>> for example i:05#.t|myadfstrustedprovider|dtom@corp.com

Below is the Powershell script to do the same, migrate the user permissions and remove the old user from the site before we turn off NTLM on the site.

$dn = New-Object System.DirectoryServices.DirectoryEntry (“LDAP://LDAPSERVER”,”LoginUsername”,”LoginPassword“)
$web = Get-SPWeb “https://mywebapplication
$Users = @()
foreach ($user in $web.AllUsers)
{
$users += $user
}
foreach ($user in $Users)
{
$user2Find = $user.userlogin
if ($user2Find.ToUpper().Contains(CORP\’))
{
$ds = new-object System.DirectoryServices.DirectorySearcher($dn)
$rnull = $ds.filter = “(sAMAccountName=” + $user2Find.ToUpper().Replace(CORP\’,”) + “)”
$rnull= $ds.SearchScope = “subtree”
$rnull= $ds.PropertiesToLoad.Add(“mail”)
$rnull= $ds.PropertiesToLoad.Add(“displayname”)
$theUser = $ds.FindOne()
if ($theUser -ne $null)
{
$email = $theUser.Properties["mail"]
$name = $theUser.Properties["displayname"]
$claim = New-SPClaimsPrincipal -Identity $email -TrustedIdentityTokenIssuer “myadfstrustedprovider”
foreach ($group in $user.Groups)
{
if (!($group.ID -eq $null))
{
$web.Groups[$group].Users.Add($claim.ToEncodedString(),$email,$name,”Migrated user for ADFS authentication”)
}
}
$web.AllUsers.Remove($user.userlogin)
}
else
{
Write-Host “Not Found”  $user2Find
}
}
else
{
Write-Host “Not CORP User”
}
}

We are working a Self Service SharePoint Site Creation Web Part which allows users to create a site by filling in a Form with the information about the content database / site collection / managed path / list of administrators etc., and upon approval perform the logic to create the Web with the information given by the user.

SPPersisted Object could not be updated because the current user is not a Farm Administrator.

I know that the creation process is running under an account which is a farm administrator. After detailed look at the event logs (Detailed level Verbose enabled), found that we can resolve this with a simple Power Shell script.

[System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint”) > $null
[System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint.Administration”) > $null
$contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$contentService.RemoteAdministratorAccessDenied = $false
$contentService.Update()

If you have a webpart on the Page which has a customized XSL for changing the user interface and getting the below error

Error while executing web part: Microsoft.SharePoint.WebPartPages.WebPartPageUserException: Personalization has been disabled for this zone.     at Microsoft.SharePoint.WebPartPages.SPWebPartManager.ThrowIfCantModifyZone(String zoneID, Boolean throwIfLocked)     at Microsoft.SharePoint.WebPartPages.SPWebPartManager.ProcessZoneId(WebPart webPart, Boolean throwIfLocked)     at Microsoft.SharePoint.WebPartPages.SPWebPartManager.SaveChangesInternal(SPLayoutProperties layoutProperties, Boolean skipRightsCheck, Boolean skipSafeAgainstScriptCheck)     at Microsoft.SharePoint.WebPartPages.BaseXsltListWebPart.get_CustomizedXsl()     at Microsoft.SharePoint.WebPartPages.BaseXsltListWebPart.LoadXslCompiledTransform(WSSXmlUrlResolver someXmlResolver)     at Microsoft.SharePoint.WebPartPages.DataFormWebPart.GetXslCompiledTransform()     at Microsoft.SharePoint.WebPartPages.DataFormWebPart.PrepareAndPerformTransform(Boolean bDeferExecuteTransform)

and if the error is NOT being thrown for Owners of the site,

1. Delete / Add the user account again to the site.

2. Make sure the user has Manage Lists permission level.

Though i am not quite clear how it solves the issue, it worked for me.

If SharePoint Search is throwing the below error while crawling the site collection

SharePoint Search can’t crawl SharePoint site – Error HRESULT E_FAIL has been returned from a call to a COM component

Possible issue could be with the Impersonation settings in the web.config

Edit the web.config of the web application, and make sure that the identity impersonation is set to “true”.

<identity impersonate=”true” />

$sourceWebUrl = $args[0]

$destWebUrl = $args[1]

$path = “c:\Sriram\Contents\”

$lists = @(“ideastream”, “Clients”)

foreach($list in $lists)

{

Write-Host (“Exporting ” + $sourceWebUrl + “/lists/” + $list)

export-spweb $sourceWebUrl -ItemUrl (“/lists/” + $list) -IncludeUserSecurity -IncludeVersions All -path ($path + $list + “.cmp”) -nologfile -force

“Exporting complete.”

Write-Host (“Importing ” + $destWebUrl + “/lists/” + $list)

import-spweb $destWebUrl -IncludeUserSecurity -path ($path + $list + “.cmp”) -nologfile

“Importing Complete”

}

$doclibs = @(“sitecollectionimages”)

foreach($doclib in $doclibs)

{

Write-Host (“Exporting ” + $sourceWebUrl + “/” + $doclib)

export-spweb $sourceWebUrl -ItemUrl (“/” + $doclib) -IncludeUserSecurity -IncludeVersions All -path ($path + $doclib + “.cmp”) -nologfile -force

“Exporting complete.”

Write-Host (“Importing ” + $destWebUrl + “/” + $doclib)

import-spweb $destWebUrl -IncludeUserSecurity -path ($path + $doclib + “.cmp”) -nologfile

“Importing Complete”

}

$site = new-object Microsoft.SharePoint.SPSite(“site url”);

$query = new-object Microsoft.SharePoint.SPRecycleBinQuery;

$query.ItemState = “FirstStageRecycleBin”;

$query.ItemState = “SecondStageRecycleBin”;

$query.RowLimit = 100;

$itemcoll = $site.GetRecycleBinItems($query);

foreach ($item in $itemcoll)

{

$id = $item.ID;

write-host -nonewline “Deleting FS: ” $item.Title ” … “;

$itemcoll.Delete($id);

write-host “Done”;

}

$query.ItemState = “SecondStageRecycleBin”;

$query.RowLimit = 100;

$itemcoll = $site.GetRecycleBinItems($query);

foreach ($item in $itemcoll)

{

$id = $item.ID;

write-host -nonewline “Deleting SS: ” $item.Title ” … “;

$itemcoll.Delete($id);

write-host “Done”;

}

I am sure many Server Administrators / HR department will be initially worried about exposing the user profile information from Active Directory to SharePoint (when we especially say we are going to replicate / synchronize) and ask to do required configuration at the Active Directory end.

This is becuase of the reason that updating the user profile information in SharePoint could overwrite the updates in Active Directory which leads to a scenario where HR / Active Directory Server administrators will loose control over it.

SharePoint / User Profile Service is capable of handling both Uni-Directional and Bi-Directional Replication of the user profiles between Active Directory and SharePoint.

When we configure the user profile service initially all the Mapped User Profile Properties are by default configured as “Import” (Uni-Directory).  This makes that only the changes in Active Directory will be replicated into the SharePoint user profile store.  Any changes done by the users / administrators at the SharePoint end will get overridden by AD changes when the Sync service runs.  We can make the changes update back to Active Directory by Editing the user profile properties and configuring the Mapping as “Export” between the SharePoint User Profile Property and Active Directory Mapped Property.

This ability will also help us in creating custom properties in active directory for user profiles which can be managed through SharePoint, thus those properties can be consumed in other systems for various business functions.  Remember the size limit of each user profile property (7500 bytes and 3600 for double byte types) when exporting them back to Active Directory.

First of all Happy New Year to everyone.

I am actually trouble shooting one of the SharePoint 2010 newly setup Service Farm which is causing issues during Replicating the user profile from Active directory.

When i looked at the Error Log and details it shows me

Replication access was denied error code with an error code 8453

When i look at the event log on the service to see what the problem is i found a error message which took me to the next step.  Refer to the link to continue to that error message and resolution.

First of all Happy New Year to everyone.

I am actually trouble shooting one of the SharePoint 2010 newly setup Service Farm which is causing issues during Replicating the user profile from Active directory.

This is the error that i found in the Event Viewer that is related to the User Profile Synchronization Service.

The management agent “” failed on run Profile “DS_DELTAIMPORT” because of connectivity issues. View the management agent run history for details

Refer this link to debug the issue from management agent.

First of all Happy New Year to everyone.

I am actually trouble shooting one of the SharePoint 2010 newly setup Service Farm which is causing issues during Replicating the user profile from Active directory.

Background

When you configure the User Profile service successfully, there are two services related to Forefront Identity manager that will automatically be started on the server on which User Profile Service is Configured.  You don’t need to start them manually (actually you should not), and they will be configured automatically when you configure the User Profile Service.  They are

Forefront Identity Manager (User Profile Service in SharePoint Service Applications) and Forefront Identity Manager Synchronization Service (User Profile Synchronization Service in SharePoint Service Applications).  The Synchronization Service is the key one which does the Sync between the Active Directory and SharePoint while User Profile Service is the one which managed the show from SharePoint standpoint.

The Physical path of the Sync Service is C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\Bin\miisclient.exe.

Issue

So, to debug the issue when i launch it to see what the actual error is (it shows a great detailed level of logging on what it is doing)

Unable to connect to the Synchronization Service.

Some possible reasons are: 1) The service is not started. 2) Your account is not a member of a required security group.

I double checked that the User profile administrative account is in the required secuirty groups on that Server from which the Sync Service is running.  And the service is running properly.  So the next issue is issue with the Active Directory.

Refer to the link on how to resolve that issue at Active Directory end.


My Tweets

Follow

Get every new post delivered to your Inbox.

Join 120 other followers