This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Remote Administration Requirements - Your feedback requested

We’re in planning for our next release and we’d like to
explore how we can more fully address your remote administration requirements.   We’ve interviewed/surveyed quite a few customers
and have formulated some ideas on how we might approach this effort.   However, before we get too far along….we’d
like to reach out to our user community again to ensure we’re accounting for
all use-cases:

1. In what situations do you require
remote access to Cirrus functions in your environment (the more detail the
better)?  What functions do you typically perform remotely?  When is remote desktop *not* a
viable option for you?
 
2. In the situations described above, is a web browser interface
a must have OR could you meet your requirements with a remote-able Cirrus Win32
client installed on your machine?
 
3. What is the minimum set of Cirrus functions that would
have to be exposed in a remote Cirrus console for it to have value in your
organization?
















 
If you’re amenable to having a follow-up call to discuss in more detail,
please let me know in your post.
  • Chris,


    Speaking for myself, it's not so much the administration of Cirrus that's a problem (TS is OK for that), it's user access. The idea of a Cirrus client is really not very appealing. While it would be nice to have an efficient, fully functional web interface to administer the app (ACD devices, users, etc), given a choice between the two, I would prefer to see a web-enabled interface for end users to view, compare, and edit configs, as well as running and viewing reports, etc. Naturally, if all functions of Cirrus can be performed via a web interface, that would be even better.


    While we're spewing our wishes, the best case scenario would be to have the ability to fully integrate Cirrus and Orion, which may be accomplished by the aforementioned web-enablement. Betcha haven't heard that one before... :)

  • Thanks for the response vhcato...this is good feedback! 
     

    Are others in the same boat as vhcato or do you have a differing requirements?

  • Chris,
     
    I agree completely with Vic’s comments above.

    With Orion, we have a very strong desire for a web interface that covers the parts only currently available via an RDP session (i.e. add/remove device).

    Cirrus is a different proposition, in that general user access to the product is much more limited (at least within our site).

    Web based reporting for end users is much more the required need from my perspective.

    We already have set up a custom  web report portal just for this reason – although we have issues with the options available for report exports when scheduling  the reports from with Cirrus (i.e. no options for report attachments, no support for mhtml, alternative formats, no filename variable support  etc ).

    The web based reporting should also extend to the policy reports (both rules and compliance reports).
     
    Regarding Orion/Cirrus integration, even a reconciliation function would be a step forward.

    We have created a custom column in Orion to indicate if an Orion device should be included in Cirrus, and run DTS jobs to perform this reconciliation report – however this type of function should be available within the product.
     
    Regards,

    Dave.

  • I agree with the posts above. I would like to see a web interface for management rather than a Win32 client. Being able to add/remove nodes (and edit their properties when adding) and viewing reports via a web interface would be a good place to start as long as the rest of the management features follow.

    As a side note, I would also like to see (better) integration between Cirrus and Orion.

  •  For us, a web browser interface is a must have. It's really the only complaint I have about Cirrus. I've heard from enough people who have told me "if it was a web interface, I'd use it" to think that it's really the direction Cirrus needs to go.

     

  • Chris


    As Vic said, we would like to be able to give other users access to run reports, run basic switch commands, compare configs and at the moment TS works but if you only run it in admin mode you have a maximum of two session at any one time and I tend to leave my session open most of the day so it leaves 1 free session for anyone else so making it web frontend would resolve this issue and it would be far easier for anyone to access and now that the security has been vastly improved it makes it a true multi user environment.


    Also integration between Orion and Cirrus would be great as it would make the two products indispensable and make our lives a lot easier with configs and switch commands and it would get my manager off my back always moaning :-)that he can't do everything through a web frontend.


    Jon

  • Jon, we just have a view in Orion with one giant green icon for management to see. That's aaaaaall they need to know... :)

  • Thanks everyone for the great feedback thus far!   Please keep it coming!

  • Don't want to beat a dead horse, but I also agree with Vic; fully functional web GUI as well as integration with Orion.  Also, the ability to force rediscover individual nodes without enabling node monitoring would be very useful.  I just wanted to include myself to the list.  I am also to provide more feedback through a follow-up call if necessary.  With our conversion from CiscoWorks to Cirrus last August, we are now a full SolarWinds shop, running multiple instances of Orion, Cirrus, and Engineers Toolset.  I appreciate the developers at SolarWinds taking the time to hear customers ideas on how to further their great product line.


     


    Thanks

  • It would be great to have the find address feature be built into the web interface so our non network engineering team members can track down an ip, hostname or mac address to rank 0 interface / port.