Add device via 'Wizard' bug - When will it be considered/solved?

Just now, Stuart Weenig said:

IMO, MSPs should not be using the wizard. Use expert mode or a scripted netscan to sync from a cmdb. The wizard is not meant for that level of scalability. It goes through troubleshooting connectivity to every device, etc. If you do add one device at a time, use expert mode, which actually allows you to set properties on the device, add it into groups, etc. as its added.

I'm probably missing some use case out there, so i'm curious how you're using it.

As an MSP we use netscan & expert mode all the time. That's not in question, however, we've a lot of persons using LM & sometimes 'Wizard' is used to add 1 device or so instead of 'Expert'.
This is a bug & should be fixed... Regardless if we're an MSP or no, it doesn't make sense to populate the properties of a certain device on the root group... I'm also missing the use case for this logic, are you aware of it?

This is just my opinion though. We rarely use the Wizard (myself, I don't use it all), however, I can't control our users.
We already brought this to everyone attention, however, if someone forgets, the issue is still there & might impact something.

Therefore & to prevent human error this should be considered & fixed on LM end.

This actually answers an issue I've been having to correct in our portal. We are also an MSP and monitor client gear. However, we also monitor all of our internal devices via LM as well. We have all our internal roles and permissions separated out to only allow users to see their respective folder structure. However, we needed to be able to allow some users to create dynamic groups, which means we have to give them manage access to the root of the portal. Which, I understand but it would be nice if users could create dynamic folders and it was aware of their permissions and would filter out what they don't have permission to see. Regardless, the users that do have root folder access must be using the wizard and applying properties while doing so, then causing these properties on the root of our folder. I have to delete esx users, api users, snmp community strings, etc pretty consistently. In several instances this has caused us issues with service accounts getting locked out when a property got inherited incorrectly.  Some sort of check in the wizard would be helpful. Perhaps if you do have a check box that asks to save the credentials allow the user to specify the folder level to save them? 

Hello, my name is Ryan Albert Donovan, Senior Product Managers here at LM. If either of you have some time this week I'd love to have a brief call to better understand the issue or see it recreated. Both myself and my developers haven't been able to reproduce in-house. If not a screen cap of the issue would suffice. Let me know if this work four either of you.

Ryan

On 5/5/2021 at 7:14 AM, Ryan Albert Donovan said:

Hello, my name is @Ryan Albert Donovan, Senior Product Managers here at LM. If either of you have some time this week I'd love to have a brief call to better understand the issue or see it recreated. Both myself and my developers haven't been able to reproduce in-house. If not a screen cap of the issue would suffice. Let me know if this work four either of you.

 

Ryan

Also feel free to also reach out to me about this. I've brought up this issue several times over the past 4 years including several tickets: tickets 76322, 88632, 108961, FEED-2277.

Enterprise customer here and I agree this needs fixing.

IMO, MSPs should not be using the wizard. Use expert mode or a scripted netscan to sync from a cmdb. The wizard is not meant for that level of scalability. It goes through troubleshooting connectivity to every device, etc. If you do add one device at a time, use expert mode, which actually allows you to set properties on the device, add it into groups, etc. as its added.

I'm probably missing some use case out there, so i'm curious how you're using it.

1 minute ago, Vitor Santos said:

it doesn't make sense to populate the properties of a certain device on the root group... I'm also missing the use case for this logic, are you aware of it?

The thinking behind this is for enterprise customers, not MSP. If you are an enterprise and you're adding one device, more than likely you'll be adding other devices. Storing the creds at the root level makes sense on an enterprise level, especially if you are depending on the Wizard to help you with your deployment.

I agree that it should be fixed. Perhaps just a checkbox in the wizard that says, "Save these credentials for future use" that defaults to unchecked.

Just now, Stuart Weenig said:

The thinking behind this is for enterprise customers, not MSP. If you are an enterprise and you're adding one device, more than likely you'll be adding other devices. Storing the creds at the root level makes sense on an enterprise level, especially if you are depending on the Wizard to help you with your deployment.

I agree that it should be fixed. Perhaps just a checkbox in the wizard that says, "Save these credentials for future use" that defaults to unchecked.

Well yeah, I could argue that as an enterprise user that could cause issues as well but, you got my point ?
I agree if this doesn't get solved, then have an alternative solution. Exactly like you stated would suffice (at least it would give us the option to choose what happens).

14 hours ago, asims@cspire.com said:

This actually answers an issue I've been having to correct in our portal. We are also an MSP and monitor client gear. However, we also monitor all of our internal devices via LM as well. We have all our internal roles and permissions separated out to only allow users to see their respective folder structure. However, we needed to be able to allow some users to create dynamic groups, which means we have to give them manage access to the root of the portal. Which, I understand but it would be nice if users could create dynamic folders and it was aware of their permissions and would filter out what they don't have permission to see. Regardless, the users that do have root folder access must be using the wizard and applying properties while doing so, then causing these properties on the root of our folder. I have to delete esx users, api users, snmp community strings, etc pretty consistently. In several instances this has caused us issues with service accounts getting locked out when a property got inherited incorrectly.  Some sort of check in the wizard would be helpful. Perhaps if you do have a check box that asks to save the credentials allow the user to specify the folder level to save them? 

 

Exactly! That would solve the issue.

20 minutes ago, Ryan Albert Donovan said:

Hello, my name is Ryan Albert Donovan, Senior Product Managers here at LM. If either of you have some time this week I'd love to have a brief call to better understand the issue or see it recreated. Both myself and my developers haven't been able to reproduce in-house. If not a screen cap of the issue would suffice. Let me know if this work four either of you.

 

Ryan

I'll reply to your email (will include our CSM as well for his awareness). Thanks!