• State Suggested Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 31 subscribers
  • Views 9916 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Upgrade to 6.1.2.115 lost core console access

douglas.murphy
over 6 years ago

After upgrading 3 cores to 6.1.2.115, two had no problems, but the third responds with "Error occurred during request execution Go to Home Page - Contact Support" when attempting to open Core Console GUI. Ran "Repair" twice, and re-booted, without success. Performing a "Get-ActiveJobs -all" in Powershell returns "Unable to connect to host localhost:8006. The server is either offline or unreachable." Tried with 3 different browsers, same results. All Services show as running.

  • 0 over 6 years ago

    Additional. Event log shows "The Core service on <servername> was not shut down cleanly. The system is running checks to ensure the data integrity." No other messages in any Event Log.

  • 0 over 6 years ago
    not that it helps you, but you're not alone. Have you asked support why it crashed?
  • 0 over 6 years ago
    also, did the service appear to still be running according to services?
  • 0 over 6 years ago
    Yes, see last sentence of description. Technically, it didn't actually crash, and support didn't have an answer, except to pass it on to the devs, who never responded. Btw, don't try to get support on a weekend. No one is around, apparently, and has to be paged. You also, even if you work there, cannot contact the devs on weekends. "Enterprise" software. The support tech, as I said, did not have a clue, but did give me a tutorial on how to read the app recovery logs, which helped. Once I saw the reason (that 127.0.0.1:8006 could not be accessed), I went to the IIS logs and found that the default web site had not been started, and was not staking in a starter state. Starting that, an "iisreset", and a re-boot took care of it and I was able to administer the Core. The Core services had always been running, and luckily I had been smart enough to pause all the protections or the repositories probably would have been hosed. Nothing trying connect to 8006 was working due to IIS owning it, and locking it up. This is probably the most tentative and finicky software I've ever seen. We have a big time investment in RR, but their change to Quest has made the investment questionable. We'll be looking at another solution this month. It's the beginning of our fiscal year, so we may have to do some budget adjustments, but this software is bullshit
  • 0 over 6 years ago
    Yeah, I noted that you had an entry in the event log stating that it had crashed. We had that and had two entries in the application log related to ASP.NET/.NET crashing at the same time. Didn't think about checking IIS to see if the site was running, perhaps i'll do that next time.

    Agreed, went through a whole heap of pain until 5.4.3 came out, then actually relaxed for quite a while as it worked. Just now have some customers starting to look at server 2016 so have needed to upgrade. Not liking the confidence crash so far
  • 0 over 6 years ago

    Hi douglas.murphy:
    Sorry for the issues you have experienced. I have forwarded your post to our management for investigation. By all generally accepted metrics, our support team is one of the best in the business. Your experience as you described it will analyzed and addressed.


    On the technical side, there is no connection between IIS and Rapid Recovery. Rapid Recovery uses its own proprietary web browser. To be complete, IIS is used only on DL appliances to show the Appliance Tab (and even this is going away). BTW -- if you have a DL appliance you need to run the latest RUU update before updating Rapid Recovery.


    However, your error message "127.0.0.1:8006" indicates a possible listener issue which in turn relates to Windows.  Listening should be on 0.0.0.0:8006. To check if indeed it is the case open an elevated command prompt and run:


    C: \> netstat -nab | findstr 8006
    If the reply is  
    TCP    127.0.0.1:8006             0.0.0.0:0              LISTENING
    It means that you are facing the issue I mentioned above.


    Use RegEdit to navigate to
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\ListenOnlyList
    which is a Regmultisz value.
    If the value is 127.0.0.1, replace it with 0.0.0.0. This MUST be the only value in the list.
    If the ListenOnlyList value doesn't exist, it means that the default one (0.0.0.0) is applied (and more troubleshooting is needed).


    Once the value is changed, you need to restart the HTTP service. Since it has multiple dependencies, you can do it from PowerShell as shown below:


    PS C:\> restart-service HTTP -passthru -force

    Hope that this helps.
    Please let us know how it works for you.

  • 0 over 6 years ago
    Hello Douglas.Murphy,
    I'm trying to investigate the support issue that you are describing however, I'm having difficulty researching this without a Support Request to reference. If you would be so kind to provide the SR number, I can look further into the case and then determine the best course going forward to advance on this issue.

    Thank you.
  • 0 over 6 years ago
    Hello,

    I am having the same issue in that I have lost console access by both the web and powershell.

    However, when I run netstat I see:
    TCP 0.0.0.0:8006 0.0.0.0:0 LISTENING

    Any other thoughts?

    Thanks and regards,
    Mike