Skip to main content
Announcements
Global Transformation Awards! Applications are now open. Submit Entry
cancel
Showing results for 
Search instead for 
Did you mean: 
kashyapdhar
Contributor III
Contributor III

QVDEPLOY: Trust Relationship Issue

Hi Forum Members,

I would like to seek your guidance in resolving the below issue which keeps popping up randomly. We get the below issue on QVDEPLOY application which leads to downtime and none of us can use the application till it gets resolved

 

  The trust relationship between this workstation and the primary domain failed.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.SystemException: The trust relationship between this workstation and the primary domain failed.


Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

 

 

 

Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.36480

 

Current Workaround:

Raise a Infra helpdesk ticket and ask them to restart the server. This resolves the issue. But this is not an ideal solution and we are trying to understand what is going on either in "application" or "application server" which is causing this

 

Any suggestion to resolve this will help a long way. Appreciate you taking some time out and guiding in right direction

Labels (1)
2 Solutions

Accepted Solutions
kashyapdhar
Contributor III
Contributor III
Author

Hi Marcus,

Many thanks, we did check the authentication channel and it is secure channel. We did join-rejoin the server and still get the same error.

We did note that while a certain AD groups which we had created long back to provide access to business users for running QV tasks from qvdeploy page, have become redundant and not applicable anymore on our AD. Do we need to manually remove such AD groups from the qvdeploy permissions tables in database? will these cause issues of sync and trust relationship?

 

Note: We have now removed such entries from our qvdeploy permissions table in the database, but still get the trust relationship error

Appreciate your support

 

Regards,

KD

View solution in original post

marcus_sommer

My assumption goes more in the direction that certain authentication-queries didn't get a proper result within their defined time-frame - means it runs in a timeout. Like above mentioned if it's worked in general all logics and settings are "fine" and the cause is a temporary overload anywhere in your environment. Therefore my suggestion to look within the various log-files to detect the appropriate pattern.

- Marcus

View solution in original post

5 Replies
kashyapdhar
Contributor III
Contributor III
Author

Hi,

We have tried the below one i think by the helpdesk, this doesn't help and this issue keeps coming up.

https://community.qlik.com/t5/QlikView-Management/Error-Exception-System-SystemException-The-trust-r...

 

Need to understand why this comes up?

marcus_sommer

I assume that any essential authentication failed and caused then this error. If it's in general worked and only randomly failed it's quite likely that there is any overload directly on your server and/or your network and/or your active directory. Therefore I suggest to take a look on all relevant/available log-files and/or to enable them respectively to increase their level of detail.

- Marcus

kashyapdhar
Contributor III
Contributor III
Author

Hi Marcus,

Many thanks, we did check the authentication channel and it is secure channel. We did join-rejoin the server and still get the same error.

We did note that while a certain AD groups which we had created long back to provide access to business users for running QV tasks from qvdeploy page, have become redundant and not applicable anymore on our AD. Do we need to manually remove such AD groups from the qvdeploy permissions tables in database? will these cause issues of sync and trust relationship?

 

Note: We have now removed such entries from our qvdeploy permissions table in the database, but still get the trust relationship error

Appreciate your support

 

Regards,

KD

marcus_sommer

My assumption goes more in the direction that certain authentication-queries didn't get a proper result within their defined time-frame - means it runs in a timeout. Like above mentioned if it's worked in general all logics and settings are "fine" and the cause is a temporary overload anywhere in your environment. Therefore my suggestion to look within the various log-files to detect the appropriate pattern.

- Marcus

kashyapdhar
Contributor III
Contributor III
Author

Hi @marcus_sommer 

This is insightful. Actually we went back and checked this yesterday afternoon and into evening and found that the issue was with AD groups.

Actually we have a mechanism where we can control the access to refreshing a report from UI.qvw for specific users through an AD group configured. Few of the old AD groups had expired and were not valid. QVDEPLOY was trying to verify those AD groups and somehow issue was being caused. Once we removed the AD groups from QVDEPLOY and checked, this worked absolutely fine. 

The engineering team helped us get the info on all inactive or invalid AD groups and we removed them all to avoid this issue happening again. This activity may be a periodic activity for admins now

 

We are on SQL server 2008 🙂

 

Many thanks for taking time out and guiding in right direction. Adding my comments here to help others who might encounter this issue

 

Below steps were performed:

Initially server reboot - this usually has been our first step to get rid of the issue and it usually works (we have a different standalone qvdeploy server)

If the above fails, we do un-join/join the server back using support from infra teams

if this also fails we get the information checked with AD infra team & wintel engineering team

post following instructions on what needs to be done from QV admin side, changes were made as stated above and it helped resolve the issue.