Following Part I, I did some more tests. It was a similar format to last time, but I though it worth looking at the results, and I also spoke to Microsoft Support about this latency question. Continue reading
I’ve had to look into Search latency in Office 365 for one of our customers. This is the time taken between a document being uploaded into Office 365 and it being available in Search. The results are interesting, though do raise a few more questions. Continue reading
The customer I was with last week, like many others, wanted their search results to appear in a table form – like a List View, in fact.
Now, I’ve written the XSL to do this for various solutions over the years, but they had found a CodePlex project for this – SharePoint 2010 Search Results in Tabular Format. This project has a feature I’d not managed to write, or had seen working before – column titles that were sortable and filterable:
That’s pretty neat. And it’s all XSL. You can, if you edit the XSL and the Columns you get back from search, show, sort, and filter other columns of data.
One observation I would make is that this XSL does not format Hit Highlighting – that is, matches aren’t shown as strong, and the summary doesn’t contain any ellipsises [ ... ] characters. However, you could easily add these from the ‘standard’ XSL to get hit highlighting working again.
So, related to my previous post, we had problems initially deleting the Search Service Application. The Search Content Application’s Database had become ‘Suspect’. I’ve had this happen a few times before (I’m not sure why – I ain’t a DB Admin) and I have a little script that I run that seems to fix this, mostly.
EXEC sp_resetstatus 'PROBLEM_DB_NAME'
ALTER DATABASE PROBLEM_DB_NAME SET EMERGENCY
ALTER DATABASE PROBLEM_DB_NAME SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CheckDB ('PROBLEM_DB_NAME', REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE PROBLEM_DB_NAME SET MULTI_USER
No, I’m not entirely sure of the logic of how it works, and I’m pretty sure I can here DB Admins across the world screaming, but for my dev systems that I can afford to trash, it seems adequate.
Anyway, on this occasion it didn’t work, so I decided to simply delete the Search Service Application. I tried this through the UI – but it just seemed to hang. I tried again – and it seemed to hang. It wasn’t going away. I tried PowerShell – which took me a while as I’m still a fan of STSADM – and that didn’t work.
In the end I found the solution – on Donal Conlon’s blog - use STSADM -o deleteconfigurationobject
Yes, there’s a certain irony in that.
Last week I was working on a customer’s Dev system and when we tried to set up search we received the error:
“The search service is not able to connect to the machine that hosts the administration component”
Interesting. And annoying. I tried removing and recreating the search application service – and we got the same error. Weirdly, it had been working previously. Continue reading
I had two of my colleagues come to me with the same complaint – that the Basic Search Center site template in SharePoint 2010 doesn’t have any navigation to get ‘back’ to the rest of the site collection:
I pointed out to them that there are good reasons to consider having the Search Center separated from the rest of your content. I’d even suggest a separate Site Collection if using the Enterprise Search Center. (This uses the publishing features, and you might not want them turned on in your existing site collection).
However, my colleagues didn’t need all that, and really did just want a simple search center in the same site collection as their content. For example, a departmental site collection needed its own search center and search experience. But they’d really like users to be able to navigate back to the rest of the site collection.
So, I set forth to fix this dire state of affairs for them. Continue reading
I’d a really, really weird problem with a customer yesterday. We’d set up their SharePoint search. Indexing seemed to be working correctly, and when I logged in as an administrator, I was getting search results correctly. However, logged in as a normal – though very highly privileged – user my search results were missing! This was some thing of a surprise. It felt like security trimming, but the user was a Site Collection admin, and had Full Control throughout the entire main content web application. Also, we were indexing content off the network file share, and we knew he could access both the SharePoint Content.
However, when he ran a search, he didn’t get any search results. That sucked. I tried another user account – and had the same problem.
Eventually, I looked in the logs and found the following message:
AuthzInitializeContextFromSid failed with ERROR_ACCESS_DENIED. This error indicates that the account under which this process is executing may not have read access to the tokenGroupsGlobalAndUniversal attribute on the querying user’s Active Directory object. Query results which require non-Claims Windows authorization will not be returned to this querying user.
I think I might have come across a problem with using the BDC to index entity data in legacy systems. I’m sure I can’t be the first person to have hit this problem, but I can’t find a solution. Thus, I thought I’d blog it so other folks might be aware of it, and to open the problem up to suggestions.
I’m not sure I can describe the system I’m actually working on, so I’m going to use a slightly contrived example… Continue reading
One of the most popular blog post on my site is, curiously, about the lack of wildcard searching in SharePoint out of the box. This, as it happens, is a bit of a simplification, and I’d like to be a bit clearer – even if it is more complicated.
- Out of the box SharePoint does not have a way of searching for “App*” and getting all results such as “Apple”, “Application”, and so on. This is the wildcard search I was on about before.
- You can do a wildcard search on a particular metadata property. “Title:App*” would return items with a title that contained “Apple”, “Application”, and so on. The down side is, you have to know the property you want to search on, and you have to know its name, which isn’t always easy or viable for users.
- SharePoint Search service does actually support wildcard searching – just there is no way of using it with the out of the box controls. Essenially, it’s a problem of the user interface. The search service supports 3 different ways of querying it. This is why Corey Roth wrote his wildcard search webpart (on codeplex), and I’m sure there are others. He explains why he wrote it here, and what you give up by using Full Text SQL queries.
So, in short, if you’re able to do some custom development (or use Corey’s web part), and if you’re willing to trade off some other areas of functionality, you can get wildcard searching – but it’s not just out-of-the-box.
All of this is explained in ‘Inside the Index and Search Engines: Microsoft Office SharePoint Server’ by Tisseghem and Fastrup. I highly recommend it for developers working with Search.
So, I’m continuing my efforts at finding a way to handling Contextual Searching.
To describe the issue again, SharePoint allows you to search ‘This List’ or ‘This Site’. Unfortunately, these searches always show the ‘OSSSearchResults.aspx’ results page, which is built into SharePoint, can’t be modified, and this means that you can’t use your normal ‘Search Center’ experience, which is usually modified and optimized for your users.
This is a shame, so I’ve been looking at ways of overcoming this problem. Continue reading