Microsoft Land

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”
}
}

Issue: Using Oracle VirtualBox to host a VM of any operating system. Trying to configure network connection between the Host and Guest operating system using Bridged Adapter (which basically let’s the communication happen between the Host and Guest two way). The drop down list is empty after selecting Bridged Adapter. You will be able to ping the Host from guest using NAT but you will not be able to ping the Guest from the Host Machine.

Resolution: Make sure you have the latest Version of the Oracle VirtualBox installed with Extentions.  If required upgrade the S/W. Make sure you don’t have Virtual PC installed on your machine, which is the key.

Virtual PC provides a network service named “Virtual PC Network Filter Driver”, and similarly Oracle VirtualBox provides a network service named “VirtualBox Bridged Networking Driver”.

So if you have Virtual PC installed and if the network service is already associated to the network Adapters that are available on your Host operating system, we cannot associte the Network Service Driver provided by Virtual Box because of which when we select the Bridged Adapter in VirtualBox Manager network configuration the list will be Empty.

To resolve the issue (assuming your Host operating system on which Oracle VirtualBox is installed is Windows 7)

Open Control Panel -> Network and Sharing Center -> Change Adapter Settings.  You will see the list of Adapters that are installed on your Host machine.  Double click on the Network Adapter that you want to use to Bridge the connection between the Host and the Guest and click on Properties. If you see “Virtual PC Network Filter Driver” in the list of items that the connection is using, select that and Uninstall it.

After the uninstallation click on Install and select “Service” you should be able to find “VirtualBox Bridged Networking Driver” from Oracle.  Select and Install the Service.  Now in Oracle VirtualBox Manager if you go to the Network Adapter configuration of the VM and select Bridged Adapter you should be able to select the Network Adapter which you have just reconfigured to Bridge the connection between the Host and Guest.

If we are using FetchXML as the method to query the data to generate the Report in Dynamics CRM (either using OOB report or Custom Reports), we could often see the below error while generating the report.

Microsoft.Crm.CrmException: An unexpected error occurred.
System.ServiceModel.Security.SecurityNegotiationException: A call to SSPI failed, see inner exception.
System.Security.Authentication.AuthenticationException: A call to SSPI failed, see inner exception.
System.ComponentModel.Win32Exception: The target principal name is incorrect

This is caused because, the FetchXML query needs to be able to resolve to a HTTP SPN in order to fully communicate between the server. In a scenario where the Microsoft Dynamics CRM application pool is being run by a domain account the query will be looking for a HTTP SPN that does not exist by default.

Simple step to resolve with an example of the server configuration that I have worked with.

CRM Nodes: CRMDEV1.corp.domain, CRMDEV2.corp.domain

CRM Load Balancing URL: http://crmserver.corp.domain

SSRS Node: http://SQLSRV.corp.domain/RSCRMDEV/

CRM App Pool Account: CORP\CRMAppPool

Below configuration needs to be done on the Report Server.

Under the Registry HKLM\SOFTWARE\Microsoft\MSCRM,

add a String “SandboxClientSpn.CRMDEV1.corp.domain”, value “HTTP/CRMFetch(CRMDEVSERVER)”

add a string “SandboxClientSpn.CRMDEV2.corp.domain”, value “HTTP/CRMFetch(CRMDEVSERVER)”

Open command prompt and add a SPN for the Application Pool Account.

SetSpn -a HTTP://CRMFetch(CRMDEVSERVER) CORP\CRMAppPool

Above is a simple workaround to get the issue resolved immediately.

Other way of doing it is to, Configure the SPN’s for CRM Nodes (with and without Fully Qualified Domain Names) along with the AD CRM Server (with and without Fully Qualified Domain names) + Changing the CRM authentication to let useAppPoolCredentials to “true” in web.config.  This approach has some additional steps too based on the IIS version and authentication Model (Keberos / Kernel Mode Authentication) etc.,

Hope this helps.

Steps to Modify the Report Server URL for an Organization in Dynamics CRM 2011. This assumes that the report server is already installed and Configured.

1. Open CRM Dynamics Deployment Manager,

2. Select the Organization

3. Right Click and Disable the Organization.

4. Right Click again and Click on “Edit Organization”

5. Modify the URL of the SQL Server Reporting Services URL and respond to the Wizard.

6. Enable the Organization.

http://msdn.microsoft.com/en-us/library/dd979290.aspx

Above is the link from MSDN which provides an detailed explanation on the configuration of Dynamics CRM 2011 SSRS Connector installation and configuration.

Unfortunately this doesn’t provide detailed explanation on Scenario’s where there are named SSRS instances configured (may be I have missed below points anywhere mentioned in the MSDN documentation). So just thought to share this information.  It would have helped me if the below two points are included in the documentation highlighted in the first page itself.

1. One installation of Dynamics CRM SSRS Connector supports only one Instance of SSRS configuration.

2. Plan your Dynamics CRM Deployment architecture and SQL Server / SSRS Deployment Architecture considering the above point.

Reason being, We started setting up the Dynamics CRM DEV and QA instances and we ended up installing DEV on “CRMDEV” and QA on “CRMQA”. We created two named instances in a single SQL Server Box “SQLSRV” with the names “SQLDYNDEV” and “SQLDYNQA”.  We also ended up creating two instances of Reporting Services on the same Server “RSDYNDEV” and “RSDYNQA”.  So the mistake was not considering / overlooking the above mentioned point #1.

When we started installing SSRS Data Connector, we understood that we can only configure SSRS Connector for one named instance. Mistake again was – We thought to use one instance for both “CRMDEV” and “CRMQA” and ignored the SSRS instance “RSDYNQA”.  So we ended up configuring “RSDYNDEV” as the SSRS Instance for both DEV and QA.

We had few issues with the Configuration of SPN’s which we have resolved.  See this Blog Article for that information. Reports are working fine in DEV and not working in QA. They are getting deployed to the Organization folder that get’s created in the Report Server.  But when we try to Run the report it only works for DEV and not for QA.

Reason being, Reports that are deployed are always trying to access the “SQLDYNDEV” instance that is Created for “CRMDEV”.  So when the report is run “from CRMQA” it will try to find the Organization that is created in QA which actually doesn’t exist in SQLDYNDEV. So they are getting failed.  SSRS Connector records the  SQL Server Connection information and Report Server Instance name in the Registry. Looks like it uses this Registry information to query the data always. Below is the Registry location.

HKLM\SOFTWARE\Microsoft\MSCRM

So, for immediate fix we had to reconfigure (Repair the installation of SSRS Connector) to point the installation to “SQLDYNQA”. Later or we have resigned the Physical Architecture and moved over the databases and Configured the Dynamics installation again.

Hope this helps for better planning.

We have a custom workflow process that we tried to Deploy to Dynamics CRM 2011 (Rollup 8).  Below is the error that we received during the deployment of the process using a Managed solution.

This process cannot be created, updated, or activated because it was created outside the Microsoft Dynamics CRM web application.  your organization does not allow this type of process

By default XAML workflows are enabled in Dynamics CRM, so before deploying the workflow we should enable them. Below is the Power Shell script that needs to be executed on the CRM Server to enable XAML workflows.

Add-PSSnapin Microsoft.Crm.PowerShell
$setting = get-crmsetting customcodesettings
$setting.AllowDeclarativeWorkflows=”True”
set-crmsetting $setting

http://msdn.microsoft.com/en-us/library/8da8c71e-84af-441e-b99b-0b59399f10f6#enable_disable

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()

My Tweets

Follow

Get every new post delivered to your Inbox.

Join 121 other followers