nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Remote Administration Requirements - Your feedback requested

chris.lapoint

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.

Find more posts tagged with

cirrus

Accepted answers

All comments

vhcato

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

chris.lapoint

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

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

savell

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.

SamuelB

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.

IPv6Freely

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.

jonchill

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

vhcato

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

chris.lapoint

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

jodros

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

jamesbernhard

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.

FormerMember

1. We have numerous engineer's working every shift from around the country picking up change tickets all the time. Much like Orion, the RDP restriction of 2 users doesn't help. You can use Citrix to get around this though web interfaces are much less taxing on the host server.
2. The web interface is desirable but not critical - a secure win32 client would be sufficient.
3. The remote client win32 should have all the functionality of the local interface. The web client could have report generation, config view/compare, node 'show' commands (like the Cisco interface) all via SSL.

Wants:
1. Web Admin - for all the functionality of the local client.
2. Ability for the user logged into Cirrus (either local, web or win32 client) to use those credentials as pass-thru to the nodes being changed/managed (like from a command push). Our nodes are all logged into via ACS with back end AD authentication, and it doesn't really help to see 'cirrus-admin-server' as the user in either 'syslog' or 'last log on' to know who really made X change when trying to correlate change management.

chris.lapoint

Thanks everyone for keeping the feedback going. Just to make sure we're on the same page, can everyone clarify what remote administration means to you?

For example, is it:

a) The ability to have a multiple remote Cirrus consoles that use the same database AND leverage a central server to execute all config mgmt (upload/download), inventory, and job requests.

b) The ability to have multiple remote Cirrus consoles that use the same database, but NO central server that proxies the requests to the network . All config mgmt (upload/download), inventory, job requests would be locally executed from each remote console.

I believe (a) is the option we're all talking about given access control restrictions, but I want to make sure nothing has been lost in translation.

Thanks,

-Chris

FormerMember

My preference is A along with the remote users that are executing those jobs/config changes, etc, having their login credentials authenticated through a TACACs/Radius/AD server to log into Cirrus, and then all jobs performed from that session uses those credentials as pass-thru to the nodes. Scheduled jobs would have a separate login (the same way it is currently).

SamuelB

a) The ability to have a multiple remote Cirrus consoles that use the same database AND leverage a central server to execute all config mgmt (upload/download), inventory, and job requests.
OR
b) The ability to have multiple remote Cirrus consoles that use the same database, but NO central server that proxies the requests to the network . All config mgmt (upload/download), inventory, job requests would be locally executed from each remote console.

Definitely "a".

amm_orion

I definitely like the idea of Option A.. That way we can keep the RDP access to the server at a minimum.

savell

Option A.

Security requirements (i.e. firewall rules and access lists) would preclude us from implementing Option B.

Dave.

tbaggins

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?

I work for a medical software company. We use IPSEC VPN's to remote clinic to facilitate a connection to our host server for the remote clients. We also use these tunnels for support of the application. To manage the configs and roll out upgrades, changes, etc to the 300+ Juniper NS5GT's and almost 400 Cisco 1100 series AP's we chose Cirrus. I would like to hand off some of the responsibility to our Implementations and support teams, but I am not willing to give them access to the server itself where Cirrus runs as I also have ORION and the Solarwinds Eng. Toolset on there. We are running a limited version of Windows 2k3 anyway. Right now I can only get 3 users on there via RDP at a time. If the support and implementations teams (total of 20 people tops) had a client they could use to access Cirrus all my problems would be resolved. Again, I DO NOT want to give these guys RDP access to the Solarwinds server. Just the app running on it. I have already created multiple pages they can view over http in Orion.

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?

Web or Client is fine with me.

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?

Config view / Config Download / and executing a command script

I'm open to a follow-up call at any time. My number is 205-298-6874

Sincere thanks for your help.

chris.lapoint

tbaggins, thanks for the post. I'll contact you separately to setup a time for a follow-up call.

rcahill

Our environment would be best suited with a web interface to the cirrus application. When admins or pc support tech are off-site to remote locations they generally do not have access to a desktop with gui access to Cirrus for reference.

We have multiple admins that can and should be accessing Cirrus from various locations. Being restricted to the 2 user RDP limit of Windows server reduces their willingness to quickly update / add / remove devices and run reports from our server.

Since this server utilizes multiple web-enabled applications a web-enable Cirrus application should be able to use another port address or url path.

Request for the new version.
Please add in Orion's Report writer functionality. Cirrus needs some assiatance there.

chris.lapoint

rcahill, thanks for the feedback. I think you'll be happy where we're headed with v5 and the new web interface. The new website will provide the ability to be configured on a different port than your other web applications. Reporting improvements are definitely on our roadmap.

ecornwell

I was wondering if there was any update on this. We're getting ready to roll NCM out and so far, I've been the only one using it but as it gets more visibility the other support personnel are going to need to access it. We have it installed on the same server as NPM and EOC and our server group isn't real keen on the idea of giving out that much RDP access.

chris.lapoint

v5 has been released and adds a new website with reporting capabilities. We're working on adding upload, download, and execute script to the website in v5.1 which is coming soon. If you're interested in being part of a web preview demo of 5.1 I'm doing next week, please send me a PM.