Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
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
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
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
Hi,
We have tried the below one i think by the helpdesk, this doesn't help and this issue keeps coming up.
Need to understand why this comes up?
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
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
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
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.