It would be helpful to limit what users can access certain Automation policies created by a company. Example: user A can see and run automation scripts 1, 2, and 3... But User B can see and run automation scripts 3, 4, and 5. Our old platform Kaseya had folder structure for procedures and access was given at the folder level. Currently if a user has access to run an automation policy or script they can see all scripts ...more »
i would like to see under scheduled tasks, being able to filter by date created.
Is there a possibility to read content of xml documents? I am on the point, that I can download a xml document from a netgear temperature sensor, but I can not find an option to read and process the xml document.
any ideas into this?
The ability to call Custom Details into variables during automation policies would be very helpful when you are tying to filter options
When creating an automation policy, I need a way to include the customer ID and the Site and the machine id in N-central (not necessarily the net bios name) in an email that is being sent out. If i could pull this information into a variable that would be great. An email that only contains the computer name is not very useful with you have thousands of computers.
When we create a new automation policy that requires password input there is no way to hard-code that password.
The field requires an input parameter and that parameter has to be a password.
Ever time you run the policy ADHOC it prompts for password.
Would like to have a way to hard-code so there is no prompt for the password.
It would be nice to be able to use booleans in an automation policy with the added effect of allowing certain input parameters to only show when certain boxes are checked. This would allow for more complex and user friendly Automation Policies without the need to give the user to many options when they are running specific Automation Policies. To give a small example, I have a disk cleanup script that has multiple sections ...more »
We have scripts that reference the agent and probe installers at e.g. "https://ncentral.example.com/download/188.8.131.527/winnt/N-central/WindowsProbeSetup.exe". Whenever we update N-Central or port a script to our test environment running the beta version, we have to manually adjust the link in the script to point to the current version. Providing a link without a version component would make our job a lot easier.
currently you can run an automation policy within another automation policy, we'd like the ability to do that with all of the scheduled tasks (script, push third party software, file transfer). AND we'd like to make sure that if if an AMP calls for one of these to be run, it wait until they are completed before continuing on with the rest of the items in the AMP.
currently it looks for 64 bit folder structures which can be present on 32 bit machines when users accidentally or unknowingly try to install 64 bit versions of software. It would be better if it used the same method of checking that the Asset tab in device details looks this information up (i'm assuming a WMI call)
we would like the ability to run scripts, automation policies, file transfers, and push third party software on custom device classes. since the Operating System information is still in asset info and in the settings tabs we feel it is fairly unreasonable that these devices are not available to target (for example we have a custom device class CSI Probe that are windows devices but which are not available on the targets ...more »