Removing devices from Inventory

[netguyz08]

I setup the TBA on my office network first, and then took it to a client's site and deployed it. However, all of my office network devices show up in the Topology and Inventory.

I tried a complete firmware reset on the TBA, thinking that might wipe it, but the info still shows up under the Customer's Profile in the TBP.

What can I do to wipe the missing devices?

[afullfor]

To reset the topology when there has been a major change, like moving from one site to another, go to Topology and click on the "Options" button.  It has a gear icon.  Click on the "Reset All" button and confirm.  This removes the history of known devices and all manually added detail, and rebuilds the topology from the the most recently discovered information.

We have a feature requested to better support this kind of staging operation.  At the moment doing the "Reset All" before you go on site doesn't help because there is no new discovery information so the topology will just get rebuilt from the previous view.  So for this process we will probably add something that also clears the last discovery, reseting the topology ready for the when the device is moved on-site and announces itself again.

[netguyz08]

Perfect that did it. Luckily I only setup some descriptions and monitoring on 4 of the devices so it was easy. It would be nice to select the item in the Inventory section and simply remove it from the list. Like check a box along each item to remove in Inventory, and then select a Remove Device button.

[Michael Holloway]

Great feedback, thanks.  From the inventory screen today you can double-click on a single device icon to edit that device and then from it's Actions drop-down menu you can choose to remove the device, if it's removable. Devices are only removable if they are not currently present on the network (presence of that device's MAC address on the network).  Before allowing a device to be deleted, we also check to make sure that we don't leave any other devices orphaned and disconnected from the network topology.

If we did add a remove checkbox for each device in the inventory screen, which could definitely make bulk deletes easier (especially when sorting by device State) what would you expect to happen to another device if you removed it's topological parent?  Should we re-parent the child device(s) to the 'root' device, or would you instead expect to be blocked from removing any device that is a parent of another device, until any children had been re-parented in the topology view? 

Do you see yourself needing to do many bulk deletes rather than the 'Reset All' option?  Would this be used for staging and configuring monitors on manually added devices (not actually present on the staging network), and then removing only the devices that the TBA might have also discovered while connected to the staging network?  Trying to get a picture of the ideal scenario for where you folks would use this feature.

-mike

[netguyz08]

Good questions, because I was mostly thinking I had the device on one network and now on another. I would like to keep settings I made on new devices, yet wipe the old devices out.

If I deployed Thunderbolt to a client, I would see where I shouldn't have to do a bunch of bulk deletes. I could see where it would make sense if there were network changes being made, or a bunch of remote guys had their devices on the network and then left and I wanted to remove them, but made some monitoring changes to other devices that I wouldn't want to have to re-add.

The Reset All makese me have to rename devices, add monitoring options again, etc. All those custom settings are lost if I want to wipe out orphaned devices, so I can see where it would be handy to just remove some of them and leave the other devices alone, in their current state.

As for re-parenting them, just add orphaned devices to the root device as a default.

[Brian Bergin]

My question is why stage the TBA?  We pre-config'd the WAPs and ESWs but didn't bother with the TBA since all you have to do is plug it in, let it boot and enter the site ID and pwd, there's really nothing else to configure other than to wait for the TBA to download the current settings and firmware(s).  I would recommend that it be recommended that the TBAs not be staged as there just isn't a lot of config'ing to do (you can even do it remotely if you ship the TBA to a customer, they plug it in and you VPN to their LAN and enter the credentials).  Just my 2 ¢...

[davebainum]

Hi all,

I am also curious to know if there's a benefit to "Staging" the TBA's in advance.  We had just plugged them in at the sites themselves on their various installation dates, and for the most part, they'd just auto-discover the devices from there.  The most tricky part so far has been occasional issues with the switches concerning ARP and/or DHCP when tied into other switches, however I don't believe it's a Thunderbolt issue as much as just ensuring that the Cisco switches are properly configured...

Regards,

-- Dave Bainum (dbainum@ritetech.net),  PMP*
tinyurl.com/plf8wz>
RiteTech LLC / www.ritetech.net / +1 (703) 561-0607
Creators of the www.RPConnect.net suite of applications

[afullfor]

I think the main benefit of staging would be to get the device preloaded with the latest firmware and get the credentials in place.  It also means you would have more confidence that the hardware is functioning ahead of a truck-roll.  This seems enough justification for us to better support pre-staging.

Another approach we've used in earlier projects was to have tools on the Portal to download the latest firmware to a USB key and also download a file holding the basic settings for the TBA, including the Thunderbolt Server ID, customer ID, and when we do support static addressing, the IP address, network, gateway, DNS, NTP server, etc.

The idea is that you would arrive on site with (or ship) the TBA and this pre-configured USB key.  The device is then plugged in, it freshens its firmware from the USB key, and then goes online with the site-specific information.

This moves most of the effort for an installation to the VAR office instead of the customer site, though the total effort is probably increased because of the handling necessary to build individual USB keys.  On the other hand, the effort at the site is very small with no need to even browse to the TBA to get it going.

Do it sound like this would fit with your business styles?

Would you have security concerns with the TBA being shipped with the access credentials?