/build/static/layout/Breadcrumb_cap_w.png

My Experience Upgrading K2000 RSAs to 7.0.357

I've been doing software upgrades since the 1980s and my cardinal rule is to wait a while for someone else to find the bugs before upgrading my production system.  I broke that rule last week and upgraded my K2000 to the latest version.  The SDA upgrade from 6.1.251 to 7.0.357 went fine.  Unfortunately, when I started upgrading my RSAs that were all on 6.1.251, many of them failed.  After reboot, they refused web connections and would not allow konfig login at the console.  My typical experience with Quest support when RSAs are bricked is for them to tell me to recreate the RSAs.  Ten of the 18 RSAs I'd started did upgrade successfully.  I wasn't looking forward to recreating those 8 bricked RSAs and still had another 12 that needed upgrading.  I opened a ticket with Quest and crossed my fingers.  Thankfully, a Quest support person got in a WebEx session with me and eventually figured out they all failed at the same point in the upgrade.  He was able to login as root and restart the upgrades on all bricked systems.  They all completed successfully!  Whew!!!  They're still investigating why some are failing.  I've had four more fail today but Quest support got them all restarted successfully.  Moral of the story...  You might want to wait to upgrade to 7.0 (like I should have) but don't fret if the RSA upgrade fails - Quest support has a lot of experience fixing my systems.


2 Comments   [ + ] Show comments
  • I bet they are all Hyper-V based... be careful with:

    https://support.quest.com/kace-systems-deployment-appliance/kb/195580/

    -and

    https://support.quest.com/kace-systems-deployment-appliance/kb/153445/

    This only applies to Hyper-V.

    Also Do you remember if you triggered the update via the SDA console?

    Or you went to the RSA's console and use the Offline installer?

    Maybe the payload wasn't properly transferred to the RSAs? - Channeler 4 years ago
  • They are all Hyper-V and they are all configured properly. I triggered the updates via the SDA console. - LHYardi 4 years ago

Answers (1)

Posted by: cserrins 4 years ago
Red Belt
0

Just as a note, we stronly feel we have corrected this issue, and it has to do with upgrading over previous versions; the further back you started, the more likely you were to experience the issue.  We have issued a new kbin to both the support portal and our warehouse.  This issue should no longer affect any of our users.

We apologize for the inconvenience.


Comments:
  • Thanks, Corey, for the info. I stumbled upon another issue earlier this week while building a new RSA using the v7 package. All of my 30 existing RSAs were built pre-v7. Most of those locations are Class B networks. Our typical config is:

    Device IP: 10.x.9.x
    Subnet Mask: 255.255.0.0
    Default GW: 10.x.0.254

    Trying to save these settings while building the RSA tells me the gateway is out of the deployment range. It's not... Quest support is reviewing. This issue did not exist in systems prior to v7. - LHYardi 4 years ago
    • Is this in konfig/konfig? If so, can you do a basic configuration there, and then try changing it to what you want in the UI once it is setup? This will help us determine where the issue may reside. - cserrins 4 years ago
      • I tried that first - making the GW 10.x.9.254 (as if it was a Class C) so I could save it. Still barks at me when I try to enter the correct GW in the UI. - LHYardi 4 years ago
      • @LHYardi Can you make sure you box has an internet connection and then enable your tether and let us know when active so we can take a look. Only outbound port 22 needs to be opened. - cserrins 4 years ago
      • Tether enabled. I had to set the device IP to 10.63.0.21 (so I could access it from my location) but the correct IP should be 10.63.9.21 - LHYardi 4 years ago
      • This is happening for us as well.
        Is there any news on a fix for this yet? - jbishop 4 years ago
      • They fixed my issue via tether. I don't see any updates on the downloads page yet. Might want to enter a support ticket for them to help. - LHYardi 4 years ago
      • An updated version of the .kbin was posted long ago, it did not require a version change. However, if you applied the older kbin and you update your RSAs via the SDA, then you may still run into this issue. Download the posted kbin again and manually apply the update to the RSAs. If you have RSAs already in a failed state, contact support to get them fixed. You could also ask the support person who fixes the RSA if he could put the updated RSA package on the SDA so that you could apply the update via the SDA instead of manually on the RSAs. Hope this makes sense! - cserrins 4 years ago
      • Upgrading an existing RSA may be fixed - I don't have any more to test. The second issue I identified with default gateway 'outside deployment subnet' persists if you download the current vk2000 hyperv 500GB zip. - LHYardi 4 years ago
      • Yes, that issue still exists in 7.0. You have been the only to report it, so we filed the defect and have it resolved in 7.1. - cserrins 4 years ago

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ