Here are some additional features we’re thinking of – what do you think? How woudl you rate the importance of these features below?
We'd love to hear your thoughts.
What do you think of these features? Please let us know...
Also - did we miss anything? Please write to us on this community page, or directly to email@example.com
The OnPlus Team
I like a lot of the top 10. Kaseya is the RMM tool we use. One truly key feature I believe should be in the top 10 is the ability to turn off monitoring on a given device/IP and/or us creating exclusion lists. OnPlus and my RMM are running into each other.
Sent from my iPhone through Exchange
Thanks for your reply!
When you say that OnPlus and the RMM are running into each other - what type of behavior are you witnessing?
It sounds to me like we'd need to turn off monitoring on a device only when an RMM is present and known to OnPlus. This woudl be part of our integration with these tools. Would you agree?
BTW, you can turn off all monitors for given devices dynamically through their device windows, and manage notification rules through the Notifications menu. This might prevent some of the collision you were referencing earlier.
Yes it would be nice if the RMM and OnPlus were aware of each other’s devices and could dynamically, or manually, turn off monitoring. When I say they’re running into each other, I’m referring to the fact that OnPlus, for example, is trying to monitor servers/desktops already monitored by my RMM tool, Kaseya in my case.
I’m am aware that I can turn off all monitors on a given device however, and I did open another thread about this previously, even if I turn off all credentials on a given server device, OnPlus continues to try to connect to the server and I continue to see failed auth messages in the security logs. My only option was to turn off failed auth, which wasn’t really an option anyway. That is why it would really be necessary to have the ability to manually turn off monitoring or manage an exclusion list of IPs for a given client. There’s always the possibility that they only have us monitoring/managing a select number of devices and not everything that can be monitored/managed.
In regards to RMM integration: GFI Max is the one we use and integration would be great!
We also use Autotask but I have been unable to get the OnPlus integration to work with Autotask. It won't look up any clients, regardless of spelling, punctuation, etc. I just haven't had time to ask about this yet...
Thank you Chris for your input.
We're aware of this issue with Autotask and are working with them to resolve this quickly.
Sent from Cisco Technical Support iPhone App
My top Feature List:
1. Add most popular Cisco products as supported templates such as
- 3750 switches
- 3560 Switches
- 28XX routers
- 29XX Routers
2. Create the ability for a default SNMP RO and RW string to be input before discovery. That way it can find out much more information on the first pass.
3. How do I add more CCO ID's to the portal?
4. Bandwidth reporting ( All reporting available to be co-branded or purely white labeled)
I am sure i can come up with more but this is it for now.
We continue to add more Cisco devices and the routers and switches you mention are definitely in the works.
As far as Bandwidth Reporting, have you checked out the NTOP Packet Monitoring under the "Apps" tab of any customer? You can read more about it
We are working on co-branded reports and you should be seeing this feature very soon.
My votes would go to (in order of importance):
1. Discover different subnets - if you instruct OnPlus which subnet to find - we'll find it for you.
--> This one is fairly big for me. I would have thought that in the area between customers who don't see any value in a managed network service and those for who the OnPlus service is a bit basic, you're going to have a lot of customer sites with 2-10 VLANs, each almost always with its own subnet.
2. Telnet / SSH to local devices – this feature will enable your to create, through OnPlus a Telnet or SSH tunnel directly into the device you’d like to manage.
--> Again a big one for any network-centric service provider - CLI access is a must and having the tool to handle NAT devices between the provider and the device would be great. If the interface is going to be browser based though, I'd suggest finding something that's quick/responsive and which lets you cut and paste. Better still would be an installable browser plugin or Java applet that could fire up Putty natively on a technician's workstation and proxy the connection. This is what PacketTrap do allthough their interface is not web-based so it's a bit different. Ability to set the TCP port to use on a global/customer/device basis would be handy too.
3. Day-0 Device Configuration Library – in OnPlus, you’ll be able to store day-0 configurations for devices that you commonly deploy. So, following an installation at a customer site, the initial firmware (already supported) and configuration could be downloaded with only a few clicks of a button, with no local copies to be made.
--> not a massive one for me but I can definitely see us using this if it were available.
On the topic of remote connection with SSH or Telnet, that is certainly already possible using the "Generic Tunnel" feature of the Connect tab. You do have to enter the port you want to connect to (22 for ssh, 23 for telnet). This system builds the tunnel and provides a hostname and port that you feed to the client software of your choice. This is covered in the Onplus User Guide in section 8 in the vicinity of p146.
Item 3 in the original request is actually asking about trying to simplify the process by automatically launching the client application with the correct connection configuration. Obviously that's a little tough to cover well for multiple operating systems, windowing systems, and terminal clients, so before delving into that, we're trying to figure out the demand over and above what is already supported.
What we have today gets you there, but you have to use cut/paste so it is a little ugly.
Also, I should point out that the traffic from your client application to the portal endpoint is "raw". Not an issue for ssh, but it does mean that telnet traffic is exposed, including any passwords typed. From the portal endpoint through to the ON100 the traffic is encrypted, and then it is exposed again for the last leg from the ON100 to the device.