mylifeinaminute.com

While implementing a new SharePoint 2010 farm, I ran into a number of issues while attempting to get the user profile synchronization to run correctly. I did discover that some additional configuration was needed around the profile synchronization account as I was dealing with a multi-domain forest and the domain NetBios name did not match the FQDN.

Even after verifying that my configuration was correct (as far as SharePoint was concerned), I was still running into issues with the Extensible Connectivity agent (part of FIM) associated with my User Profile Service Application. It would consistently fail, throwing 6801 and 6803 errors in the event log.

Error 6801

The extensible extension returned an unsupported error.

The stack trace is:

“System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.UriFormatException: Invalid URI: A port was expected because of there is a colon (‘:’) present but the port could not be parsed.

at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)

at System.Web.HttpRequest.get_Url()

at Microsoft.SharePoint.Administration.SPAlternateUrl.get_ContextUri()

at Microsoft.SharePoint.WebControls.SPControl.SPSiteFromContextNoCache()

at Microsoft.SharePoint.WebControls.SPControl.SPWebEnsureSPControl(HttpContext context)

at Microsoft.SharePoint.SPContext.get_Current()

at Microsoft.Office.Server.UserProfiles.ProfileManagerInstance.GetApplicationProxy()

at Microsoft.Office.Server.UserProfiles.ProfileImportExportService.GetPartitionIds()

— End of inner exception stack trace —

at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)

at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)

at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)

at Microsoft.Office.Server.WebServiceDirectProxy.WebMethodInfo.Invoke(Object webServiceInstance, Object[] args)

at Microsoft.Office.Server.WebServiceDirectProxy.Invoke(String methodName, Object[] args)

at Microsoft.Office.Server.UserProfiles.ManagementAgent.ProfileImportExportDirect.GetPartitionIds()

at Microsoft.Office.Server.UserProfiles.ManagementAgent.ProfileImportExportExtension.Microsoft.MetadirectoryServices.IMAExtensibleFileImport.GenerateImportFile(String fileName, String connectTo, String user, String password, ConfigParameterCollection configParameters, Boolean fFullImport, TypeDescriptionCollection types, String& customData)

Forefront Identity Manager 4.0.2450.5″

The extensible extension returned an unsupported error. The stack trace is:  ”System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.UriFormatException: Invalid URI: A port was expected because of there is a colon (‘:’) present but the port could not be parsed.   at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)   at System.Web.HttpRequest.get_Url()   at Microsoft.SharePoint.Administration.SPAlternateUrl.get_ContextUri()   at Microsoft.SharePoint.WebControls.SPControl.SPSiteFromContextNoCache()   at Microsoft.SharePoint.WebControls.SPControl.SPWebEnsureSPControl(HttpContext context)   at Microsoft.SharePoint.SPContext.get_Current()   at Microsoft.Office.Server.UserProfiles.ProfileManagerInstance.GetApplicationProxy()   at Microsoft.Office.Server.UserProfiles.ProfileImportExportService.GetPartitionIds()   — End of inner exception stack trace —   at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)   at Microsoft.Office.Server.WebServiceDirectProxy.WebMethodInfo.Invoke(Object webServiceInstance, Object[] args)   at Microsoft.Office.Server.WebServiceDirectProxy.Invoke(String methodName, Object[] args)   at Microsoft.Office.Server.UserProfiles.ManagementAgent.ProfileImportExportDirect.GetPartitionIds()   at Microsoft.Office.Server.UserProfiles.ManagementAgent.ProfileImportExportExtension.Microsoft.MetadirectoryServices.IMAExtensibleFileImport.GenerateImportFile(String fileName, String connectTo, String user, String password, ConfigParameterCollection configParameters, Boolean fFullImport, TypeDescriptionCollection types, String& customData)Forefront Identity Manager 4.0.2450.5″

Error 6803

The management agent “MOSS-8e630c0a-434f-4af2-b8fe-a020bd3ef255″ failed on run profile “MOSS_FULLIMPORT_e6294a6e-3dcb-4ac5-86e2-24eddfeaa0e9″ because the server encountered errors.

Opening miisclient (%programfiles%\Microsoft Office Server\14.0\Synchronization Service\UIShell\miisclient.exe) revealed that my Extensible Connectivity agent was failing with a status of stopped-extension-dll-exception (which was confirmed by was visible in the event log).

A bad URI request was being formed somewhere along the way. FIM was expecting a URI formatted with a colon (“:”), which none of my alternate access mappings provided. (Question for the SharePoint product team – Who still runs their applications on non-standard ports?)

Thankfully, the FIM Synchronization Service can be configured manually to tidy these errors up.

1. Browse to %programfiles%\Microsoft Office Server\14.0\Synchronization Service\UIShell
2. Launch miisclient.exe
3. Click the ‘Management Agents’ button in the toolbar to switch to the “Management Agents” pane
4. Right click on the Management Agent with the “Extensible Connectivity” type called MOSS-{guid} and select “Properties”
5. Click on the “Configure Connection Information” property pane
6. At the bottom of the dialog, there should be a “Connection information” section which includes a “Connect To:” text box
7. Change the hostname of the URI in this text box to direct://{HOST}:{PORT}…
8. Click OK, and close the Synchronization Service Manager (miisclient)
9. Start a full import and everything should now work.

Reference

• Rational Guide to implementing SharePoint Server 2010 User Profile Synchronization
• SharePoint 2010 – Provisioning User Profile Synchronization

From MSDN:

Designing and developing rich, robust Microsoft® SharePoint® applications can be challenging. The following releases are designed to help solution developers and architects make the right decisions and follow proven practices when building applications for SharePoint. Each release contains guidance documentation, source code for reference implementations, reusable library code, and Quick Starts.

Definitely worth exploring further if you looking to see how others are building on top of the product stack and what the SharePoint MVPs view as essential for developing robust applications.

Reference

• SharePoint Guidance on MSDN

Restoring site collections with stsadm is normally a straightforward affair, requiring little to no manual intervention to get things back up and running. That is of course, unless you are restoring sites based on the Publishing Site template.

I recently wanted to take an existing site collection, make a copy of it in the same web application under a newly created managed path and have it reside in a new content database. The backup went smooth, utilizing stsadm -o backup. The creation of the new managed path went off without a hitch. The creation of a new content database and the restoration of the site collection into that database also occurred with no issues.

Browsing the site however told a different story. I was immediately greeted with a standard error page stating “File Not Found”. Browsing to other pages within the site (eg. “/_layouts/settings.aspx“) yielded the same result. After turning on the callstack/debugging and disabling the custom error page, I was greeted with the following:

The problem? Each publishing page points to an incorrect page layout after the restoration. One would think that the restore via stsadm would recognize this and fix it, but it does not.

The fix? The stsadm extensions published by Gary Lapointe. The package built by Gary offers a command call gl-fixpublishingpagespagelayouturl. Verbose? Yes. Does it work? Absolutely.

After running the command and executing an iisreset, the site was once again able to be browsed and appears to be intact.

Reference

• SharePoint Automation: Fix Publising Pages Page Layout URL
• File not found errors when restoring a site collection
• stsadm backup Operation
• stsadm restore Operation

SharePoint 2007 always required some level of scripting in it’s installation to allow for greater control of the installation process (i.e. creating database names without GUIDs). SharePoint 2010 is not any different in that scripting is still required to gain the finer control over installation. What has changed is that now PowerShell can be used in place of psconfig/stsadm. With that in mind, let’s begin.

1. Install the SharePoint binaries on each server in your farm. Select “Complete” as the installation type. This will allow you to create a farm as opposed to a single server installation.After the install has completed, you will asked if you would like to complete the “SharePoint Products Configuration Wizard”. Do not run the wizard at this time.
2. On the server which you wish to provision Central Administration:
   1. Open the  ”SharePoint 2010 Management Shell” (right-click and select “Run as administrator”). The shell will load with a message that the local farm is not accessible. This is expected as we have only installed the binaries.
   2. Run the following command to create the initial configuration/content database for the farm.

      New-SPConfigurationDatabase –DatabaseName “SharePoint2010_Config” –DatabaseServer “SharePoint2010SQL” –AdministrationContentDatabaseName “SharePoint2010_Content_Admin” –Passphrase (ConvertTo-SecureString “Pass@word1” –AsPlaintext –Force) –FarmCredentials (Get-Credential)
      

   3. After the initial creation of the farm, close and reload the “SharePoint 2010 Management Shell”. You should no longer receive any error messages.
   4. Install the help files.

      Install-SPHelpCollection -All
      

   5. Secure the resources used by the server (files and registry).

      Initialize-SPResourceSecurity
      

   6. Install and provision the farm services.

      Install-SPService
      

   7. Install the features on the server.

      Install-SPFeature –AllExistingFeatures
      

   8. Provision Central Administration.

      New-SPCentralAdministration -Port 1234  -WindowsAuthProvider "NTLM"
      

   9. Install the application content.

      Install-SPApplicationContent
      

   10. Optional: Disable the loopback check. If this is a development install, outright disabling the check should be fine. For production environments, the loopback check should be left in place and BackConnectionHostNames should be used in its place. See KB 896861.

       New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name "DisableLoopbackCheck"  -value "1" -PropertyType dword
       

3. On each additional server that you wish to converge in the farm:
   1. Open the  ”SharePoint 2010 Management Shell” (right-click and select “Run as administrator”). The shell will load with a message that the local farm is not accessible. This is expected as we have only installed the binaries.
   2. Connect the server to the farm with the following command:

      Connect-SPConfigurationDatabase -DatabaseName "SharePoint2010_Config" -DatabaseServer "SharePoint2010SQL" -Passphrase (ConvertTo-SecureString "Pass@word1" -AsPlaintext -Force)
      

   3. Install the help files.

      Install-SPHelpCollection -All
      

   4. Secure the resources used by the server (files and registry).

      Initialize-SPResourceSecurity
      

   5. Install and provision the farm services.

      Install-SPService
      

   6. Install the features on the server.

      Install-SPFeature –AllExistingFeatures
      

   7. Install the application content.

      Install-SPApplicationContent
      

   8. Optional: Disable the loopback check. If this is a development install, outright disabling the check should be fine. For production environments, the loopback check should be left in place and BackConnectionHostNames should be used in its place. See KB 896861.

      New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name "DisableLoopbackCheck"  -value "1" -PropertyType dword
      

Reference

• Eric Kraus’ SharePoint/.NET Blog – SharePoint 2010 Provisioning A New Farm with Powershell
• You receive error 401.1 when you browse a Web site that uses Integrated Authentication and is hosted on IIS 5.1 or a later version
• SharePoint Automation: SharePoint 2010 PSConfig and Powershell