Fred_BD

I know this is a little bit of an older post but there aren't many others along the same topic. You will need to set up scripts to remotely wipe and lock a system down. I have created a special agent group for stolen computers where the next time they go online, the public IP address and SSID gets recorded and the (I believe to be) irreversible process of reinstalling Windows OS starts. The only caveat to this is that the stolen computer has to go online, which is typically not the case in my experience. No, the remote wipes and locks aren't a 1-button solution. They're Powershell scripts that take 7 clicks in total to initiate if you're looking to run it manually. I'm OK with that considering the impact those have on the end system. The stolen computer group is all automated, however, which should fulfill those types of requirements.

@Jamie Taylor Sorry to pile on here but we're also looking for this feature. If we aren't eligible to have it enabled for us, can anyone think of a workaround to get roughly the same results? I am thinking of a daily task that runs a simple script (ping 127.0.0.1?) which will fail for a system that can't respond back and will report as such, but that feels messy and may bring in false positives. It also would only occur at a particular time during the day, which would exclude any computers operating outside of when the task runs. I guess I can have multiple tasks running at different times during the day, but then I'm compiling that data and... it would just be easier if this were a built-in feature, I'm concluding!

Try using the Pulseway installer MSI file. When you run it, you have the options of repairing or removing Pulseway. If removing outright doesn't work, trying repairing and it might bring the entry back into the Add/Remove Programs window. I have purposely hidden Pulseway away from that window on our employee computers to avoid any "misclicks" that would uninstall Pulseway and that's the method I've been able to consistently use to uninstall it.

I believe there was a mistake in the guide which I think applies to you. In the guide, where it says: You actually don't want the Output name to be anything other than what matches the variable(s) in the script. For this guide, you would want to name the Output either ProtectionStatus, recoveryKey, or VolumeStatus. You'll notice after you create the Output, its name is a variable at the top of your script. I simply removed the already mentioned (same-named) variable from the top of Carl T's original script. The alternative to all of this is you can change the script's variable names to match your Output name but that's extra effort. I should note that the names of custom fields can be whatever you'd like, those don't have to match anything.

I'm also learning about custom fields and I think it finally clicked for me. I want to share this to help anyone else struggling with this. I used this guide to set up custom fields and to find out how to connect them to a script. While this guide in itself may not apply exactly with what you're looking to accomplish, use it as a template as it lays a good foundation on the process. Simply put, you create the custom fields in Automation > Custom Fields. Then create (or edit) your script (Automation > Scripts) and add in those custom fields as Outputs. It's important to note that the name of the Output needs to match whatever variable name (in the script) that you want to extract the information from - this is something I will later correct in the comments on the other thread as it was written incorrectly in the guide. So, running through the script I'm presenting as the example - the script checks on the BitLocker status/keys and then puts that data into the script's variables, which passes that info to the Outputted custom fields, which will then save those in the custom fields under Systems > Systems > (individual system name) > Custom Fields. --- Edit: One more quick note on a discovery which I haven't seen documented anywhere - You don't have to manually assign custom fields to any systems (at least with the custom fields with the "System" context). Once you run a script that has a custom field as an output, it will automatically assign that custom field to the system under Systems > Systems > (individual system name) > Custom Fields. Hopefully that saves someone some time.

Just ran into this case, myself. Any updates on this or at least some sort of closure so it's not left open-ended if it's still in the works?

I think this is supposed to be a String rather than DWORD. We don't have an AD environment but I'm still able to use automation within Pulseway to make all of this happen. Thanks @Mark G38for the help!

Thanks Jamie, that makes sense then. We'll try this one out once we're prepared for the trial.

I really appreciate this Carl T. Tremendously helpful and I can't wait to try it out. Does anyone know why I'm not finding the ability to create custom fields under the Automation tab? I'm running the free license for 2 users (to try this out long term before we purchase this and push it company-wide) so I'm wondering if that's the reason. We're not quite ready for the timed trial, but if this is something to add to the list of things to do during the trial (along with remote access) then that's fine, I'm just looking for confirmation on that. I'm looking at both the browser version of Pulseway as well as the Android version and I'm just not seeing it.