People Directory with CSWP

Today I started to work on a mock-up of a People Directory which is not utilizing anything else, but a Content Search Web Part due to the easy customization Display Templates and the powerful features it offers. It already has som good templates like Large picture for example, that will be all I need + Department and Job Title (which will be managed properties, linked to a term set).

Even though this Web Part is heavily promoted and is supposed to enhance/replace the good old CQWP, it doesn't work right away as you'd expect (at least in SharePoint Online).

Let's imagine you create a blank page and you add the Web Part.

You then configure your query - it'll be very simple "@*onmicrosoft.com" so that I can get all the people from my demo tenant

As you can see, the query is tested and it simply works. Then you save your Web Part and get this:

Some people suggested that this Web Part is not available in SharePoint Online Plan 1 and they've been in touch with Microsoft Support .... which I have to use in production... but I couldn't find an official source stating that. I think that's old information, I think the web part was not even available in SharePoint Online in the beginning. I know it's definitely not available on-premise if you don't have the Enterprise version.

I've also tested this on my demo tenant which is on SharePoint Online Plan 2... and I got the same results. Turns out pretty simple, I just had to enable the Cross Site Publishing feature on the site collection and the web part works.

+ a little bit of CSS = a sample of my desired outcome:

The next thing is to find out which properties we want displayed in these boxes, if they're custom ones they should be mapped to a managed property first before we can stick them in here.


But that will be another blog post :)

Issues when requesting the Search Results page with no query in SharePoint 2010

After some vacation time in July I'm back to share some of the experiences with SharePoint, this time from the backlog I have for posting here. Although SharePoint 2010 mainstream support will expire soon (Oct 13, 2015) there are still a number of customers using it.

For one of our clients, we've had to design a custom big shiny button that leads to their Search Center (read: Results page) but without the need for users to type in any query before hitting the button. Something similar to this, in the middle of a Publishing page where we've removed the default Search Box webpart on the client's request.

That's a quick and easy thing, if we don't count the numerous design iterations that we've done of course. Once implemented in the test environment though, we have faced some issues.

Whenever you try to search for a keyword, nothing happens. Your Search Query box is reset to empty. So you try again... and again. This was a very intermittent behavior, after some time... it will eventually work. It was also working always for admin accounts. The ULS logs would show:

System.Runtime.InteropServices.COMException: The security validation for this page is invalid. Click Back in your Web browser, refresh the page, and try your operation again.    at Microsoft.SharePoint.Library.SPRequestInternalClass.ValidateFormDigest(String bstrUrl, String bstrListName)     at Microsoft.SharePoint.Library.SPRequest.ValidateFormDigest(String bstrUrl, String bstrListName) 7ee02ec8-2297-4816-b3c8-b31f0150d81d

Initially one would think to disable the Web Page Security Validation on the web application... which is totally not a good idea and brings more issues when trying to save site as templates, etc.

After a lot of digging, I've found no way of fixing this, so we've changed the behaviour of the Search button to not go to the results page directly with no query, but instead require the user to input a query before that. 

Now that works fine and everyone's happy. Not sure if this is by design, but out of the box Search Webparts would require you to type your query before you can go to the results, so it might be.

Cross-Farm Service Application Publishing

To start the process of cross farm service application publishing in SharePoint 2013, first look at the post about establishing STS trust between farms. You also need to have the farm IDs of the farms that are going to consume the service applications in hand.







So, let's assume the STS trust is established, now the steps to publish and then consume the services are:









1. On the source farm, go to Central Admin -> Application Management -> Manage service applications, select the one you want to publish (in this example Search) and click Publish from the top ribbon.














You could also achieve this with PowerShell:







Publish-SPServiceApplication -Identity <ServiceApplicationGUID>



If you do not know the GUID of the service application, you can use the following Windows PowerShell 3.0 cmdlet to list all service applications in the farm, together with their GUIDS:
Get-SPServiceApplication



2. Select the "Publish this Service Application to other farms" option. I recommend using https connection. 









Take a note of the Published URL and save it.






3. Grant permissions to the consuming farms on the source service application by using the consuming farm IDs. 





4. Now, go to the consuming farm(s) Central Admin -> Application Management -> Manage service applicatoins and click Connect. Now insert the address that you've saved in Step 2. The server hostname in the example screenshot is removed on purpose.






5. Now choose the service application that will be provided as a choice to you. In our example - Search Service.



Leave the option “Add this service application’s proxy to the farm’s default proxy list” ticked and click OK.








6. On the next screen, you can choose a name of the service application. Finally you'll get a confirmation that you've connected successfully.


If you're consuming remote Managed Metadata Service, there is an additional setting to be set that will prevent errors when trying to update some of the user profile properties through MySites:













Select this one as well (not related to the issue above), but needed if you want to map custom user profile properties to term sets:

Continuous Crawl Intervals

So this new feature in SharePoint 2013 sounds good, right? Ever wondered is it really continuous and how fresh really are your search results when using it? Here's the answer in maybe my shortest blog post:

1. $ssa = Get-SPEnterpriseSearchServiceApplication  
2. $ssa.GetProperty("ContinuousCrawlInterval")  

The default interval is 15 minutes. You can easily change that to anything else, say 20 in this example:

1. $ssa = Get-SPEnterpriseSearchServiceApplication  
2. $ssa.SetProperty("ContinuousCrawlInterval",20)  

SharePoint 2013: Search Service not working due to lost permissions

I was delivering a training session in our London office 2 weeks ago, while I was interrupted for an urgent issue for a client that could not wait as this was their live system and the current support provided had no success in resolving it. Briefly - Search not working. SharePoint 2013. I jumped in and there were some actions already tried by the support provider, but mostly restarting the Search Services on all servers. That didn't help. The client production configuration is (the issue did not occur on any of their dev/test environments):

• 1 WFE running the Query Processing Component 
• 2 Application servers running all other Search components
• 1 SQL server (dedicated and only one instance on it)
• All databases and service applicatoins provisioned through PowerShell (AutoSPInstaller)

The user experience looks like this on any query, executed from anywhere (and that just happened to occur out of the blue):

The Search Service Administration page in Central Admin was showing "All Errors".

The event logs on the APP servers were all flooded with EventID 1357 containing this:

A database error occurred. Source: .Net SqlClient Data Provider Code: 229 occurred 0 time(s) Description:  Error ordinal: 1 Message: The EXECUTE permission was denied on the object 'proc_MSS_GetStatusChangeRequest', database 'Search_Service_Application_DB', schema 'dbo'., Class: 14, Number: 229, State: 5    at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
   at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
   at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
   at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite, SqlDataReader ds)
   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout, Task& task, Boolean asyncWrite)
   at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(TaskCompletionSource`1 completion, String methodName, Boolean sendToPipe, Int32 timeout, Boolean asyncWrite)
   at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
   at Microsoft.Office.Server.Data.SqlSession.ExecuteNonQuery(SqlCommand command)
   at Microsoft.Office.Server.Search.ManagedSqlSession.ExecuteNonQuery()

.... and a lot more errors related to Search as a consequence of this.

That's SP2013 + SP1 + only 2 security updates released in May this year.  No updates applied after that and everything was working as a charm for 6 months after we've built it. I was given info that there were some network issues experienced just prior to that issue, but I did not have enough data to correlate both.

I've seen the same behavior a couple of months ago when a SQL box was rebooted manually without any actions on the SharePoint farm like stopping services or IIS at all. Then the Search stopped working even when SQL was operational. The reason was lost service account permissions for the Search service account. The same thing happened now for some (unknown yet) reason - the Search service account losts its permission - SPSearchDBAdmin for the Search Service Application database.

I know that's not the best solution, but the only one I could think of in the limited amount of time available to fix this production system - add the permission to the account manually in SQL Server Management Studio. Go to your Search Service Application database (the one referenced above in the application error from the event log, then go to Security -> Users and select the account you use for running your Search Service Application pool, it is also shown in the event log under the error.

In my case that's a dev system on which I've reproduced the issue for the purpose of this post:

On the Membership section, verify the SPSearchDBAdmin role is selected for the account, if it's not (like it was in our case), add it and that should fix your problem. Might need to restart the Search Service again on all the servers running it - we had to do that in our case to get the Admin Component up and running in addition to the Query Processing Component which started working properly immediately after the database permissions were restored.

We still do not know the root cause of that as the environment was handed over long time ago, initially thought that Search in 2013 is very sensitive to connectivity to the SQL Server as I've seen the issue with lost permissoins twice, and the first time was a reboot of SQL definitely causing it. Then I stopped the SQL server on my dev environment for a while to see if that will happen and it didn't, it must  be something else then. And yes, we do use SQL aliases, but we only had one SQL server in that production environment. Hopefully that helps you solve such critical issues quickly.