One of the search features introduced with SharePoint 2010 was the concept of search refiners and this really gave power to the users to filter and work with search results. This capability was surfaced as the Refiner Panel in the search results pages and was driven by metadata values assigned to the content. The benefit of this was that users can work with large results sets and narrow down the search results based on meaningful business criteria.
Some good quick tips from SharePoint community site
I was recently asked to take a look a SharePoint 2010 UAT server that was showing some very odd search behaviour. The rest of SharePoint was working fine but search results were only bringing back web pages, no other content was appearing in the search results.
We tried the normal trouble shooting steps such as clearing the config cache and resetting the search indexes but nothing seemed to help, we checked the crawl, event and ULS logs but nothing seemed to point to an problem.
We finally resorted to creating a new search application and adding to the default group. After running a full crawl we had a full set of results back as expected, the only step left was to move the existing crawl rules from the old search application to the new one.
After moving the crawl rules across from the original search application to the the new one the same result issues appeared, so it was obvious that one of the 10+ crawl rules in operation was causing the issue, we removed the rules one at time and reran a full crawl each time to check the results, we finally found the offending rule (below) with a URL exclusion of ‘http://*/forms’ , this seemed to have the effect of stopping the crawler component going into the hidden forms folder and crawling content via that route.
Recently I had the need to backup all the solutions deployed to a test system before a code refresh, to achieve this I used the simple piece of PowerShell below.
$dirName = "C:\Solutions"
foreach ($solution in Get-SPSolution)
$filename = $Solution.SolutionFile.Name
To run the PowerShell script simply create the folder c:\Solutions, or set another location in the script and run with Farm credentials or equivalent.
Happy SharePointing !
I was recently involved with helping a client expand a 2010 farm by adding 2 more servers to an existing environment.
It should have have been a straight forward task to install the SP2010 binaries, Service Pack etc and join the new servers to the existing farm.
Checking the documentation for the existing farm I could that the following build was in use
SharePoint 2010 RTM & SP1 & Feb 2012 CU & June 2012 CU & Brazil Portuguese Language Pack & Language Pack SP1 & Office Web Apps.
I gathered all the media together and settled down for a day of watching the blue bar.
After all the installs I planned to run the Configuration Wizard up to the PassPhrase step to ensure the servers were ready to be joined at a later point.
Running the Configuration Wizard on one of the ‘New’ servers I was able to connect to the Configuration database but the Configuration Wizard was stopping at the Patch screen reporting a patch mismatch between the current farm servers and the new server.
The Patch status was reporting that the June 2012 CU was not installed on any of the other servers, even thought it clearly was !.
After much head scratching and chatting to colleagues I was at bit of a loss as to what the issue could be, I was thinking about running a PsConfig b2b on one the ‘live’ servers, but decided to keep looking around and finally found a discrepancy in Control Panel –> Programs –> View Installed Updates, comparing the new server with one of the current servers I noticed a difference in the installed updates for the Language Pack, the ‘new’ server was showing 13 updates for the Language Pack compared to existing servers that were only showing 1
After another chat with one of my colleagues we established that in the current live environment the Language Pack had been installed after the June 2012 CU, where as when i built the ‘New’ servers I had installed the Language Pack before the CU, and as the CU’s are multilingual a number of extra Hotfixes had been installed.
The solution in this case was simply remove and reapply the Language Pack over the CU, now the new servers could be added to the current farm.
When you have been working with SharePoint for a while, you get a feeling for when an issue is with SharePoint and when its not, and you can generally tell which it is within a few minutes.
So when we started getting reports of users unable to edit documents or save edits back to SharePoint, I immediately though it’s just a single user or a faulty workstation, but when we started getting more and more reports I did begin to wonder it it was a SharePoint issue after all.
The symptoms seemed to be, a user could open a document from SharePoint, edit it and save the edits, but the all subsequent documents would open in [Read-Only] mode, without the normal “Edit Document” message bar appearing in the office client application.
To get back to normal functionality the user would have to close all browser sessions and relaunch, no amount of changing browser or office settings would return office to normal working.
Further investigations showed that almost all the workstations were running Windows 7 and Office 2010, but all had Lync 2013 installed, finally we we tried running an Office 2010 client repair from Windows Control Panel and bingo, normal document editing was resumed.
So once again not a true SharePoint issue, but as the presentation layer SharePoint normally gets the blame.
Happy SharePointingFollow @NeilKing41
Getting the AD update feature working in SharePoint 2010 / 2013 can be a challenge as you need to ensure the the permissions you set on the synchronization account are exactly correct as per the following TechNet article.
Even following these to the letter you can still come across problems as I recently discovered.
I was asked to take a look at client system where the AD update for the telephone number was failing, checking in SharePoint I could see that attribute was set to ‘Export’
but the Telephone number for a ‘Test User’ was not being set, checking in the FIM client tool we could see a permissions error for the object update.
Rechecking the permissions that the AD sync account has showed that the update permission had been removed from the AD object and AD Inheritance had been removed.
After some serious investigation by a colleague ( Big Respect to Chris V ), we discovered an AD feature called “Protected Groups” whereby if you are a member of a specific AD group such as Administrators, Account Operators, Server Operators etc the following could happen.
As soon as we tested the AD feature for a ‘normal’ user it worked as exactly as expected , so a nice little ‘feature’ to watch out for that is not documented from the SharePoint side.
Happy SharePointingFollow @NeilKing41
Recently I was asked to take a look at SPD workflow on development system that was not sending emails.
Normally this works fine as it uses the standard emailing features of the SharePoint Platform, as long as the outgoing email settings are configured.
In this instance the outgoing email settings were correct for the environment in question, so a quick test I created an alert on a list, normally this would send an email straight away saying that an alert has been created but no email arrived.
If you have access to the server console the first test is to make sure you can ping your SMTP relay server, this will be the server you have referenced in your outgoing SMTP server configured in Central Administration.
If you can ping the server try using TelNet to connect on Port 25, if telnet times out and fails to connect then you probably have a firewall issue.
In this instance we were getting:
Which was an indication that the development server was not allowed to relay email via the SMTP server, as soon as we had the development server added to the allowed SMTP relay list we could connect via TelNet and send alerts and emails from SharePoint and development continued.
So always check the simple things 1st !
Consider the following situation, you have a column in a list or library with a name such as “Workflow” , someone come along and creates a workflow called “Workflow” and associates it with your list, in isolation that is no problem. However you do now have 2 columns in your list / library view called “workflow” one is your column and the other is the status of your workflow.
In your list description you still only have one column called “Workflow”
But your end users are saying that when they are creating views there are 2 columns called “Workflow” and don’t know which to choose.
The most simple thing to do would be rename the Workflow, the only effect this should have is to change the name of your status column (personally I have not seen other side effects of doing this)
So in SPD we change the Workflow name, hit Save then Publish and nothing happens !, so we do it again and nothing happens, no changes in SharePoint, so we change the Workflow name then hit Rename then hit Save & Publish and finally it works, how odd !
Microsoft Security Bulletin MS13-024 – Critical
Vulnerabilities in SharePoint Could Allow Elevation of Privilege (2780176)
Published: Tuesday, March 12, 2013
This security update resolves four privately reported vulnerabilities in Microsoft SharePoint and Microsoft SharePoint Foundation. The most severe vulnerabilities could allow elevation of privilege if a user clicks a specially crafted URL that takes the user to a targeted SharePoint site.
This security update is rated Critical for all supported editions of Microsoft SharePoint Server 2010 and rated Important for all supported editions of Microsoft SharePoint Foundation 2010. For more information, see the subsection, Affected and Non-Affected Software, in this section.
The security update addresses the vulnerabilities correcting the way that Microsoft SharePoint Server validates URLs and user input. For more information about the vulnerabilities, see the Frequently Asked Questions (FAQ) subsection for the specific vulnerability entry under the next section, Vulnerability Information.