/build/static/layout/Breadcrumb_cap_w.png
07/30/2019 279 views

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

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?
  • They are all Hyper-V and they are all configured properly. I triggered the updates via the SDA console.

All Answers

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.

Answered 09/09/2019 by: cserrins
Red Belt

  • 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.
    • 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.
      • 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 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.
      • 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