Execview usability- run as service, local console

[John_Scott_2]

I am trying to get Execview 3.2 running for a single site with one BE v9.1 server and two BE v8.5 servers, using ECM v3.1. It has run stably during the first few days of my test setup, but has several quirks. I'm hoping you can advise about workarounds for those quirks.

1) EIS appears to run TomCat as an application, so that it is only available during the first user session after the EIS service is started. If I log off the first session after a restart, the only ways to revive TomCat are to log on with a user that has privileges to restart services, and restart the EIS service, or to restart the EIS server and log on with any user (even one with restricted privileges).

Is there any workaround that will allow me to run the Execview server like a service, that is, without it being affected by who is logged on or whether anyone is currently logged on?

Would the rest of EIS work with it if I installed TomCat as a service?

This feature strikes me as a peculiar lapse, for a product whose main purpose is to allow me run my backup server without a high-privilege user logged in. In its current implementation, EV merely shifts that burden to a different server.

2) One way I'd like to use Execview is to be able to check my servers from home, where my bandwidth is limited. Is there a way to install the Console application on my laptop, so that it doesn't have to copy the .CAB over every time I open the execview.html page?

3) Finally, a feature request for the next version. If the user profile can be smart enough to remember which columns I want to see in the job list, why can't it remember which way I want the listing sorted?

John Scott

[John_Scott_2]

Bump.

C'mon, Veritas staff... In contrast to the kvetchers elsewhere, I'm trying to approach this positively. The EV product appears usable so far in my evaluation. I'm just looking for a way to get software that is designed to be able to run like a service (TomCat), to actually do so in this application. Help me out here.

Alternately, hey superusers! Can the folks who are using EV successfully confirm the limitations I'm seeing, or share any usability workarounds they've found?

[Ken_Putnam]

The last ExecView version worth anything at all was v2.6, but BackupExec v9 and higher only support ExecView v3.0 and above.

I've stopped using ExecView, and use a RemoteControl application (PCAnywhere) to connect to the Media Server (suitably locked down, of course), and run the AdminConsole through that

[John_Scott_2]

Ken, thank you for that reply. That was the sense I got from browsing the posts about ExecView. I used to use EV several years ago with v7.?, but dropped it once it got complicated.

So far, in the two weeks I've had it up, it is working (although requiring an awkward environment to do so). I just thought I might find some brave soul who was using it successfully, or provoke Vertitas/Symantec into making a public case for why it ought to be seriously reconsidered by folks like you who have been burned.

[John_Scott_2]

I am finally ready to agree that Execview is not worth trying to run. After the first few weeks when it worked (but I wasn't touching the EIS server), I tried to run some other software on the EIS server.

The whole thing unraveled. Communication with the ECM agents started failing. The remedy in KB doc 242519 and the lack of remedy in doc 268156 provide no help. I've seen the doc 252867 error, but I'm not going to reinstall Java just now. Reinstalling the ECM on the server didn't help. Reinstalling the EIS didn't help.

I'm finally ready to join the "Execview is a fragile toy, not a usable product" chorus.

[shweta_rege]

Hello,

Could you please update us on the issue

******************************************************************
*****************************************************************

Note : If we do not receive your reply within two business days, this post would be marked ‘assumed answered’ and would be moved to ‘answered questions’ pool.


Thanks.