Friday, 16 March 2012
I created a new search centre on a new site collection as a test and it worked ok so it meant that people search on the farm was working but there was obviously something peculiar about the migrated site collection. The solution in the end was to edit the People Core Result Web Part on the search results page and expand the “Display properties” and make sure “Use Location Visualization” is checked.
I eventually found the answer here:
Monday, 7 February 2011
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
Tuesday, 7 December 2010
Thursday, 11 November 2010
Friday, 1 October 2010
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
Thursday, 30 July 2009
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
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.
Monday, 27 July 2009
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: