Unable to add client node in Rapid recovery core dashboard

Hello All,

I'm facing one issue I'm unable to add one client server in core dashboard.Its giving following error:-

Value cannot be null. Parameter name:Source

Can anyone please help me out.Support team is telling to upgrade the Core version form 6.2 to 6.3

Agent version is 6.2

Agent OS:-windows 2012 R2 Standard

Core version:-6.2

Core OS:-windows server 2012 Standard

Error log:-

WARN  2019-11-21T08:13:10 [20] - Replay.Agent.Management.Authentication.AgentPairingClientCertificateAuthenticator ()

Request client certificate thumbprint 'C355AEFC0649A62C83326737770F64F8DE428EFD' does not match previously paired client certificate thumbprint ''

Please suggest

Parents
  • The push to upgrade is fairly common with support. They wont even bother to troubleshoot till you spend a bunch of time and effort to upgrade everything to the most recent version even though they know it wont help. Its a terrible practice and not how a enterprise level software works

     This is a fairly common problem with RR and they have multiple TN on how to fix this (see below) Moving forward, make sure you always visit Quest.com, click Support, Knowledge Base and do a few keyword search's. The search function is not great so make sure you do several variations of keywords

    https://support.quest.com/rapid-recovery/kb/155417/how-to-pair-an-agent-to-its-original-recovery-points-after-the-agent-had-been-reinstalled-

    https://support.quest.com/rapid-recovery/kb/189965/adding-an-agent-to-protection-fails-with-error-occured-pairing-to-agent-error-message-

  • Thank you for your suggestion, Emte. I agree with your direction in terms of troubleshooting.

    However, I do see an important point in suggesting an upgrade at this time. I believe its relevant since version 6.2 support will not be available Jan 9, 2020, which is pretty much around the corner. Sujoy can certainly troubleshoot based on the KB articles provided, if he chooses to, but an upgrade will do at least 2 things: Ensure his support, and be relevant in refreshing/repairing the agent installation. I would consider it part of the troubleshooting process to be complete at this point.

  • Here... I forgot to provide the support life cycle link with pertinent information....

    https://support.quest.com/rapid-recovery/lifecycle

  • Good afternoon Jose. I see what you are saying but you have to see things from our perspective also. The guy opened a case to solve his problem, so solving the problem AND telling him that support ends in X days would have been fine. But that does not appear to be what happened here. A simple fix has been withheld and the demand to upgrade is the only option given (I assume, I cant see his case)

    It feels like some of the people in Support don't understand the challenges of some (not all) enterprise IT depts. Installing patches and reboots are sometimes difficult to accomplish due to change control, never mind huge core upgrades that span multiple server/sites. It feels like some people in RR support may have experience with consumer level software and use the same operating procedures that are fine with consumer level but don't work in some enterprise shops.

    We could add in here how quickly RR versions become unsupported, it causes a lot of issues for sites. 6.2 was moved to limited support in way less than 1 year and EOL before 2 if I remember correctly (I could be mistaken)

    I have been in his shoes. I have had critical cases where the RR support person has told me the ONLY option is to upgrade even though he could not provide any evidence that it would fix my issue (I was fairly certain it would not) I argued with him for awhile about how hard it is to get upgrades done in certain environments but they did not care. So several days later when we finally got approval, we upgrade and of course the issue remained. So now the backups have failed for days but only then would the tech even look at our logs to start troubleshooting.

    This does not appear to a standard policy. Some RR cases (techs) will demand an upgrade prior to any troubleshooting while others will work almost any issue regardless of version. 

    Sorry this turned into a much longer reply than I intended but I always want to share my reasons for strenuously objecting to any stance that requires an upgrade be done prior to troubleshooting.

Reply
  • Good afternoon Jose. I see what you are saying but you have to see things from our perspective also. The guy opened a case to solve his problem, so solving the problem AND telling him that support ends in X days would have been fine. But that does not appear to be what happened here. A simple fix has been withheld and the demand to upgrade is the only option given (I assume, I cant see his case)

    It feels like some of the people in Support don't understand the challenges of some (not all) enterprise IT depts. Installing patches and reboots are sometimes difficult to accomplish due to change control, never mind huge core upgrades that span multiple server/sites. It feels like some people in RR support may have experience with consumer level software and use the same operating procedures that are fine with consumer level but don't work in some enterprise shops.

    We could add in here how quickly RR versions become unsupported, it causes a lot of issues for sites. 6.2 was moved to limited support in way less than 1 year and EOL before 2 if I remember correctly (I could be mistaken)

    I have been in his shoes. I have had critical cases where the RR support person has told me the ONLY option is to upgrade even though he could not provide any evidence that it would fix my issue (I was fairly certain it would not) I argued with him for awhile about how hard it is to get upgrades done in certain environments but they did not care. So several days later when we finally got approval, we upgrade and of course the issue remained. So now the backups have failed for days but only then would the tech even look at our logs to start troubleshooting.

    This does not appear to a standard policy. Some RR cases (techs) will demand an upgrade prior to any troubleshooting while others will work almost any issue regardless of version. 

    Sorry this turned into a much longer reply than I intended but I always want to share my reasons for strenuously objecting to any stance that requires an upgrade be done prior to troubleshooting.

Children
  • Thanks for your explanation, which is very much in the spirit and purpose of the forum.
    I have been on both sides of the equation, and I understand.

    In my experience as part of the support team, we always address the need for a "not-able-to-upgrade" scenario. From Sugoy's post, it is difficult to tell whether he conveyed that specific need, and as well, whether he was provided alternative options by support. Perhaps Sugoy can give us details of his service request. We would definitely make sure all possibilities are covered.

    Again, thanks for your explanation. It is one of our goals to understand everyone's specific situations so we can better assist.