Workflow does not automatically start when emailing a SharePoint Group

I recently created a simple workflow for an SP2010 site using SharePoint Designer 2010 which emailed a SharePoint Group when any document was uploaded to a specific document library. I found that for certain users the workflow would not start and nothing was logged in the workflow history list.

It seems that if the user uploading the document cannot see the membership of a SharePoint group they cannot resolve the email addresses of users within that group. The way around this is to edit the SharePoint group settings and set the "View Membership" setting to "Everyone" for the SharePoint group being emailed in the workflow. You can do this by going to Site Settings > People and Groups > Groups from the left hand navigation bar and editing the group in question.
 

 
This was also the case in MOSS 2007 and the problem and solution are described here: http://blogs.msdn.com/b/spdsupport/archive/2008/06/16/how-to-fix-sharepoint-designer-created-workflow-that-periodically-stops-and-does-not-send-emails.aspx

Query Server Not Responding

I Recently installed the "republished" October Cumulative Updates for SharePoint 2010. I then discovered that Search was not working. Crawl was going on forever and I was getting the message "Query Server not responding" therefore no propogation was happening . All my Search components were installed on a single server at this point. The Crawl component was also reporting a "Recovering" status. I added a new Query component and deleted the original one but this did not fix the problem.

I then remembered that I had seen something similar in SharePoint 2007 where updating the farm with a cumulative update would cause the Adobe PDF iFilter settings to be lost from the registry which in turn would break search. I have blogged this previously  http://mrvsharepoint.blogspot.com/2009/03/moss-february-2009-cumulative-updates.html

It seems that this is still the case with SharePoint 2010 and certain Cumulative updates. I went back and added the PDF iFilter  settings back into the registry (http://support.microsoft.com/kb/2293357), rebooted the server, did a full crawl and it all worked again.

FIM Service Stops after Import and User Profile Synch Connection Disappears

I opened a support call  with Microsoft recently where miiserver.exe would fault after an incremental import every night which would cause the FIM services to stop. This would result in the User Profile Synch connection disappearing. Restarting the FIM services would fix the problem but obviously this wasn't ideal.

A description of the issue is as follows:

At 1am every night the Incremental User Profile Import runs. Following this the FIM Service enters a "Stopped" state. Inspection of the System Log indicates:

EVENT ID: 1000

Faulting application name: miiserver.exe, version: 4.0.2450.11, time stamp: 0x4c3e8067 Faulting module name: KERNELBASE.dll, version: 6.1.7600.16385, time stamp: 0x4a5bdfe0 Exception code: 0xe053534f Fault offset: 0x000000000000aa7d Faulting process id: 0x%9 Faulting application start time: 0x%10 Faulting application path: %11 Faulting module path: %12 Report Id: %13

The fix as suggested by Microsoft was as follows:

  

“Please add the following line (highlighted) to the miisserver.exe.config (C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\Bin) and see if it helps….restart the FIM services (through services.msc) and re-run incremental sync." 

 <?xml version="1.0" encoding="UTF-16"?>

<configuration>

        <configSections>

                                <section name="resourceManagementClient"

type="Microsoft.ResourceManagement.WebServices.Client.ResourceManagementClientSection, Microsoft.ResourceManagement"/>

        </configSections>

                <startup>

                                <requiredRuntime version="v2.0.50727"></requiredRuntime>

                                <supportedRuntime version="v2.0.50727"></supportedRuntime>

                </startup>

  <runtime>

    <disableStackOverflowProbing enabled="true"/>

    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

      <dependentAssembly>

        <assemblyIdentity name="Microsoft.MetadirectoryServicesEx" publicKeyToken="31bf3856ad364e35" />

        <bindingRedirect oldVersion="3.3.0.0" newVersion="4.0.0.0" />

      </dependentAssembly>

    </assemblyBinding>

  </runtime>

</configuration>

 An explanation for the line that resolves the problem can be found here at http://msdn.microsoft.com/en-us/library/ms149581.aspx and is due to the stack size.

Event ID 3 ForeFront Identity Manager Error

After applying the August 2010 Cumulative Update for SharePoint 2010, I started to see the following error in Application Event Logs around every 30 seconds. They occurred on the server that was running the FIM Services:

EVENT ID 3

Provider: ForeFront Identity Manager

Microsoft.ResourceManagement.Service: Microsoft.ResourceManagement.Workflow.Hosting.WorkflowManagerException: Forefront Identity Management Service does not support workflows of type 'Microsoft.ResourceManagement.Workflow.Activities.SequentialWorkflow, Microsoft.ResourceManagement, Version=4.0.2450.9, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. at Microsoft.ResourceManagement.Workflow.Hosting.HostActivator.ActivateHost(ResourceManagementWorkflowDefinition workflowDefinition) at Microsoft.ResourceManagement.Workflow.Hosting.WorkflowManager.StartWorkflowInstance(Guid workflowInstanceIdentifier, KeyValuePair`2[] additionalParameters

After a call to Microsoft I was told that they are "aware of the issue" and a hotfix and associated KB article will be released very soon. The product group stated that these "errors are benign".

Verdict: Harmless but annoying

People Search Results adds a :80 Suffix to results on an External Facing Site

Had an issue where doing a People Search by connecting to my external facing SharePoint site via ISA Server 2006 on say https://extranet.domain.com was returning People search results suffixed with a ":80" so for example People Search results done externally for a particular person would return something like:

https://mysite.domain.com:80/person.aspx?guid=08AE56E0-EA14 etc which does not resolve externally

Internally everything is fine so browsing to http://intranet and performing a People Search returns the correct URL for a person as http://mysite/person.aspx?guid=08AE56 etc which is correct

AAM Settings are:

Intranet Web Application

Default Zone: http://intranet

Extranet Zone: https://extranet.domain.com

MySite Web Application

Default Zone: http://mysite

Extranet Zone: https://mysite.domain.com

This could be caused by using the same web application for both port 80 and 443 access and tests showed that this was not caused by ISA 2006 but I managed to resolve this on the external side by adding a Link Translation mapping in my ISA Server Extranet publishing rule that maps https://mysite.domain.com:80 to https://mysite.domain.com

This works fine but in environments where ISA is not used it may be prudent to extend the Web App so that you have a dedicated SSL web application which may solve the issue (haven't tested this but a colleague has this scenario and doesn't have the problem.

Alternatively, I also found the following article which resolves the issue by editing the People Search Core Results Web Part and the Search High Confidence Results Web Part.

http://blogs.technet.com/victorbutuza/archive/2008/10/20/how-to-remove-something-the-port-from-the-url-as-returned-in-the-search-results-searchresults-aspx.aspx

NLB IP Address does not appear in IIS on Windows 2008

Had an interesting issue as follows - I configured Windows Network Load Balancing (NLB) on my 2 SharePoint 2007 Web Front End Servers on Windows Server 2008 SP2 64Bit and then proceeded to assign IP addresses to my Main Portal Web Application and the MySite Web Application (both web apps are on port 80 so using IP addresses to distinguish them apart rather than host headers). The weird thing is that unlike Windows 2003 NLB in Windows 2008 your load balanced Virtual IP does not appear in the list of IP addresses you can bind to the web application. Looking around on various forums it seems that this is some kind of a bug on Server 2008. A workaround for now which I used is to manually type in the Load balanced IP address in IIS when selecting from a list of IP addresses to bind to the web application.

As you can see in the example below the 172.16.0.50 is my load balanced address but does not appear in the list of IP Addresses in the drop down list so I have typed it in manually and this works:

Access Denied messages when performing an Index Crawl and Event 2436 Warnings

Had an issue recently where I could not Crawl a SharePoint site after setting off a full crawl of my default content source and was receiving the following message "Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content."

I was also getting Warnings with Event ID 2436 stating that Access was Denied.

I discovered that this was down to the Loopback problem described in KB896861 http://support.microsoft.com/kb/896861 and was caused by the site URL not having the NetBIOS name of my SharePoint server, e.g. my server was called MOSS01 but I was trying to crawl my site collection at http://portal.domain.com

I followed the instructions for "Method 1" in the article which are as follows:

To specify the host names that are mapped to the loopback address and can connect to Web sites on your computer, follow these steps:

1. Click Start, click Run, type regedit, and then click OK.
2. In Registry Editor, locate and then click the following registry key:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
3. Right-click MSV1_0, point to New, and then click Multi-String Value.
4. Type BackConnectionHostNames, and then press ENTER.
5. Right-click BackConnectionHostNames, and then click Modify.
6. In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
7. Quit Registry Editor, and then restart the IISAdmin service.

I started another full crawl after an IISRESET but still received the same errors. I eventually resolved it by resetting all crawled content from the SSP Administration pages as follows:

SSP > Search Administration > Reset all crawled content

This allowed me to perform a full crawl without any errors.