You are viewing limited content. For full access, please sign in.

Question

Question

Search in Web Client Never Returns Results

asked on August 29, 2017

For one user, search in the web client almost never actually returns search results.  The users sees the "Searching ..." dialog, and the search will run forever.  Other users can execute the search using identical criteria from both the web client and desktop client with acceptable performance.

We've tested both wired and wireless network connections.  We've tested other laptops docked on the docking station and connected off the dock to the same access point inside the user's office.  We've tried other users logged into the web client from the problem user's windows profile.  We've tried Chrome, Firefox, and Internet Explorer.  We've had that user try other workstations.  All tests return search results in a reasonable amount of time.

We have not tried the desktop client on the user's workstation.  I'm forcing the migration to the web client, and I'm reluctant to let this user be exempt from the migration.

It seems to be something unique to this user on this particular workstation.  We could load a new workstation for this person, but that starts a whole chain of workstation reloads that I'd rather avoid.

Any suggestions on where to turn next in finding the cause?

LF 10.1

MS SQL server

Hosted on-prem on stand alone server (not VM)

Windows 7 OS on problem workstation

Current versions of all three web browsers as of last week

 

Thanks in advance for any advice.

 

Brian Van Vleet

0 0

Replies

replied on August 29, 2017

When one user gets different results in search than other users the reason is almost always that their access rights in the repository are different. 

In this case, my first thought is that the other users with no search problems have access to a much smaller number of documents and folders than the user who has their searches taking forever. While the other user's searches might be going through 20% of the documents in the repository, that one user might be searching all 100% of the documents in the repository.

0 0
replied on September 11, 2017

Glen,

I've been using myself as a base line, and I have access to the entire repository.  I get search results in a matter of seconds.

I had wondered if this user was a member of multiple groups that had conflicting security to portions of the repository, but that is not the case.

The problem started when the user was issued a new workstation and was simultaneously move to the web client from the desktop client.   Prior to that, there were no complaints.

Any other suggestions for me?

Brian

0 0
replied on September 12, 2017

I have no idea, unless you've got a really old version of the web client. Install the software client and see if there's a difference. 

0 0
replied on November 1, 2017

After installing the client, the user reports acceptable performance.  It seems isolated to just the web client for a specific user on a specific machine.

 

Brian

0 0
replied on August 29, 2017

Check the "console" tab of the browser dev tools (aka F12), there might be an error that is silently causing the search to fail.

0 0
replied on September 11, 2017

Robert,

The attached shows the results from this users workstation.  We get similar results from all the other users we've tested on the various workstations.  Even if these warning message are indicating a problem, they don't seem to be highlighting why this one user's experience is different from everyone else or why is suddenly started with a new workstation and the change to the web client.

Any other suggestions?

Brian

LF console 1 - Copy.PNG
0 0
replied on September 14, 2017

Ok, that verifies it isn't failing due to a silent error. Next I would try clearing the user's trustee attributes via the administration console. When you clear the attributes, you will be prompted to save them as an XML document that can be used to restore them. After clearing the attributes, have the user sign in and try the search again.

1 0
You are not allowed to follow up in this post.

Sign in to reply to this post.