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

Question

Question

9.0.2 and 9.0.1 Laserfiche Client throwing errors connecting to 9.1 repository

asked on February 3, 2014

After upgrading our 9.0 Rio environment to 9.1 our 9.0.2 and 9.0.1 clients were getting the error below. The following products were upgraded to 9.1: Laserfiche Server, Workflow, Forms, WebAccess, LFTSC, AuditTrail. I didn't think there were compatibility issues between 9.0.x clients and a 9.1 repository. I upgraded the clients to 9.1 and the error is not longer occuring. Also, 9.0.3 clients were able to connect without errors as well. Is this a know compatibility issue or did something possibly go wrong in my 9.1 upgrade?

 

Error Code: 6000
Error Message: Unable to cast COM object of type 'System.__ComObject' to interface type 'Laserfiche.Workflow.BusinessProcess.Security.ISecurityGroupProvider'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{599F6755-708F-424E-9E58-D580A8C2AD7F}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)). [6000:0x80004002] (No such interface supported)

------------ Technical Details: ------------

LF.exe (9.0.2.728):
    Call Stack: (Current)
        CLFToc::InitializeConnection
        CLoginView::LoginHandler
    Additional Details:
        Exception: 0x80004002 [6000] (Unable to cast COM object of type 'System.__ComObject' to interface type 'Laserfiche.Workflow.BusinessProcess.Security.ISecurityGroupProvider'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{599F6755-708F-424E-9E58-D580A8C2AD7F}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).) (CLFToc::InitializeConnection at lfToc.cpp:610)
    Call History:
              CAttachedRepository::GetProfileValue
          GetOptionString ([Settings]SnapshotAvailableTimeout)
          GetOptionString ([Settings]ShowOpenEDocDlg)
           CAttachedRepository::GetProfileValue
          GetOptionString ([Settings]RemovedMenuItems)
           CAttachedRepository::GetProfileValue
          GetOptionString ([Settings]FavoriteBusinessProcesses)
           CAttachedRepository::GetProfileValue

LFError.jpg
LFError.jpg (231.11 KB)
1 0

Answers

APPROVED ANSWER
replied on February 4, 2014

The issue is that the 9.0 Client contained a multi-threading/timing issue that rarely occurred, if at all, when connected to a 9.0 Server. However, due to changes in the 9.1 Server, it made this 9.0 Client bug more likely to occur unfortunately. This issue has been fixed in the 9.1 Client though.

 

With the complexity of the code, it would not be a good idea to try and fix this server side by catching the 9.0 Client usage scenario. The reason is that it may add more instability to the server and it may not even fully address the issue.

 

The proposed workarounds are as follows:

1. Upgrade to the 9.1 Client, at least for users who use the "Business Processes" feature.

2. If upgrading isn't an option and users do not use business processes, then create the attribute [Settings]EnableBusinessProcesses and set its value to No.

2 0
SELECTED ANSWER
replied on February 3, 2014

This is actually a known issue. It's been fixed for 9.1.0.

2 0

Replies

replied on May 6, 2014

Having run into this issue, and turning an hour upgrade into a six hour process, I think the installation package needs to flash a warning of this problem.

 

Reason is, Laserfiche has NEVER had an issue with backward compatibility between server and client versions. It's the last thing we ever expected to see, and we figured we had broken something else.

 

Here the most important thing is that the 9.0.2 client will not work with the 9.1.1 server, so you need to be prepared to update the server and the clients all in the same time frame.  

1 0
replied on February 3, 2014

There should be no compatibility issues between a 9.1 server and 9.0.x clients. Can you please open a support case through your re-seller so we can better investigate this issue.

0 0
replied on February 3, 2014

Thank you for the reply Mike. I have sent the information to my VAR.

0 0
SELECTED ANSWER
replied on February 3, 2014

This is actually a known issue. It's been fixed for 9.1.0.

2 0
replied on February 3, 2014

To expand on what Miruna indicated, the aspect of this that has been fixed in 9.1.0 is on the Client. That is, if you upgrade to Server 9.1 and then also upgrade the Clients to 9.1, this will be resolved. We're currently investigating being able to fix the Server issue so that this doesn't come up in the first place.

0 0
APPROVED ANSWER
replied on February 4, 2014

The issue is that the 9.0 Client contained a multi-threading/timing issue that rarely occurred, if at all, when connected to a 9.0 Server. However, due to changes in the 9.1 Server, it made this 9.0 Client bug more likely to occur unfortunately. This issue has been fixed in the 9.1 Client though.

 

With the complexity of the code, it would not be a good idea to try and fix this server side by catching the 9.0 Client usage scenario. The reason is that it may add more instability to the server and it may not even fully address the issue.

 

The proposed workarounds are as follows:

1. Upgrade to the 9.1 Client, at least for users who use the "Business Processes" feature.

2. If upgrading isn't an option and users do not use business processes, then create the attribute [Settings]EnableBusinessProcesses and set its value to No.

2 0
replied on March 7, 2014

My client needs to upgrade to 9.1.1 in order to get the resolution for another problem but is currently not in  a position to upgrade all of his users. Should I recomment to upgrade his server to 9.1.1 and apply  workaround 2 ? Is this 100% safe ?

 

0 0
replied on March 7, 2014 Show version history

Michel, what version are you upgrading from? Are you using the business processes functionality?

0 0
replied on March 7, 2014

Hi Justin,

 

He is upgrading from version 9.0.2.681. He is not using the business processes functionality.

 

Regards,

0 0
replied on March 7, 2014

That should be fine then. The only issue would be that this would disable BPs, so if you were using them it wouldn't be a good workaround.

0 0
replied on October 31, 2014

Hi Guys

We are busy testing our upgrade to Server 9.2 and are experiencing the same issue when connecting from a Client version 9.0.2. Does it mean we have to upgrade the client installs to 9.2 as well?  We have 250 Users that would need to be upgraded as 90% of our users actually make use of the Business Process mechanism. Based on the post it would seems that the problems was meant to have been fixed in 9.1.1 and thus the assumption is that it would have been fixed in 9.2 as well.  

0 0
replied on October 31, 2014

Correct. Fixes from one version would carry over into newer versions. This issue shouldn't occur when using the 9.2 Server and Client.

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

Sign in to reply to this post.