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!

Hi @bdoadmin,
You may change the system in Pulseway remotely by using the Pulseway Dashboard or using the Powershell command from the Pulseway WebApp -> Systems -> Systems ->select the required system -> PowerShell terminal and run the following command:
Set-ItemProperty -Path "HKLM:\Software\MMSOFT Design\PC Monitor\" -Name ComputerName -Value "New_Name_for_the_system"
Let us know how it goes.

The latest update for the All Systems page is packed with new features focused on productivity and user experience.   Multi-tab support for Systems With the new support for tabs you can easily switch back and forth different views and effortlessly multitask between systems.   Create shortcuts for your Favorite actions You can now pin your most used modules and create shortcuts to further enhance your productivity.   Updated Search Experience & General User Interface Continuing our efforts to deliver a simple and intuitive user interface, we have redesigned our search experience and modernized the overall look and feel of the All Systems page.

Further user interface improvements to four additional pages:
Patch Management Policies Page Antivirus Policies Page Antivirus History Page Account Overview Page

Hi James,
A system is considered as offline when you receive the offline notification. For the Professional product that is about 10 minutes after the agent stops communicating with the Pulseway Cloud Servers and for the Enterprise product this interval can be customized.
-Paul

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'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.

Going to bring this thread back to the top.  If anyone else feels that having the ability to input at run time a variable they declared as a custom field in their scripts, please upvote.  This is probably one of the single biggest improvements I want to see with Pulseway.  Custom variables should be able to be set to prompt at run for input.  We should also be able to set Customer level variables that are static and can be called in a given script.  
Here is the link to the feature request.  I did search and didn't find someone else asking about this, but I may have missed it. Either way, doesn't seem high on the list of votes so getting more attention to it would be great. 
https://pulseway.featureupvote.com/suggestions/189283/more-robust-input-and-site-variables

Thanks. This is a great idea, we'll consider it for a future release. It's annoying that you have to create tags, a scope and a task only when you need something real quick. We'll see how we can improve this.
-Paul

Here's a remote wipe script you can use: https://github.com/paulcsiki/pulseway-scripts/blob/main/remote-wipe/report-bitlocker-status.ps1
-Paul

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!

@Gregory Candido That's correct. It will apply to ALL patch policies you have in place.  You can create rules for new ones as well yes.
However, you can also do the registry entries as mentioned previously.  They will prevent auto updates to anything past what you set.  Obviously, this may need to change as Windows 10 continues to release updates, but we will have to wait and see if they alter version numbers so that Windows 11 is different from Windows 10 in that regards.  
For now, you can script these reg entries or deploy via GPO if you have an AD environment. 
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate.
Create or update the Dword TargetReleaseVersion to 1.
Create or update the Dword TargetReleaseVersionInfo to 21H1.
 

I've taken 2 steps to this.
1.  Create a Global Rule in Pulseway that says if Name or Description contains 21H2, don't install.  21H2 is used by Windows 11.  
2. Set registry entries to tell Windows 10 to not update Feature version past 21H1 for now.  This can also be done via GPO in a domain environment. 
 
 
BUT - I don't think this stops end users from clicking upgrade if they get a prompt or choose to be curious themselves.  I've also sent out communications to my customers explaining that they should not be pressing update to any Windows 11 prompts if they happen to see any lol. 

Would this be correct?  I would assume if they come 22H2 in the future we would need to create a global rule for that as well.
Since this is a global rule this means it will apply to all my tenant's machines?
 
Greg

Hi there! 
 
I often find myself running scripts on our machines in a way that demands follow up/verification, so I thought it would be a good thing to be able to add scripts to a queue in Pulseway to have them run at a later point in time when a system becomes available online. Currently I tend to keep a document with all the machines listed, so I can mark them one by one in order to know which ones are done, and which ones remain. This is kinda tedious because our machines (especially laptops) tend to be offline for longer periods of time, and I have to follow up on a daily basis until the script ran successfully on all of them. 
 
I know about automation tasks in Pulseway and the possibility to schedule scripts to run daily, weekly etc. But they will continue to run on all computers for as long as the task is enabled. I've tried to cope with this by building scripts that won't reapply the software and/or settings if existing data is found. It seems to work, although it's not an optimal solution since the scripts will run tens or hundreds of times on our systems when they only really need to be ran once. 
 
So, what am I suggesting?
The possibility to run one or multiple scripts (either directly or via an automation task depending on what the Pulseway devs prefer) With an option to run once. With an option to include offline systems (the script/s will be queued for when they come back online) With an option to send success/failure-reports to the administrator With an option to retry once, twice or three times whenever a script is unsuccessful. (in my case this is useful because Powershell Impersonation doesn't work in home environments when VPN is disabled, so a second attempt may succeed.) A section in Pulseway WebGUI where an administrator can see the deployment progress and success/failure-ratio.  
One of many scenarios: I have a script that will install a scheduled task with some predefined values, and upgrade an MSI-installation to a newer version. I want to make sure that all our computers run the script with a successful output.
 
Please let me know if you find this suggestion useful! 

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.

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

A number of folks have requested the ability to manage bitlocker with Pulseway, so I thought I would share how I am doing this with Powershell scripts and Pulseway's custom fields feature. 
First, you will need to create a custom fields in Pulseway (Automation Tab --> Custom Fields). This fields should be a text variable that has the system context. I personally have 3, BitlockerKey, Protection Status (On/Off), and BitLockerVolumeStatus. BitlockerKey is probably the one most people will care about. . 

After Configuring the Custom fields, you will then need to create your PowerShell script. Notice you have inputs and outputs. You will want to click New for output. Name it what you wish, ensure it is a text variable type, and then turn on "set Custom Field Value"

Now we toggle the flag for it being a windows powershell script. You should see in the top that it has created a comment #outputs with your defined output variable assigned the default value you gave it. 
Now we have our script: Update as of 4/18/2021, script now tracks 3 custom fields and will account for if a drive is encrypted but protection is off and no protectors have been added yet.
# Outputs $ProtectionStatus = "na" $recoveryKey = "na" $VolumeStatus = "na" #region functions function Start-BitlockerEnable { Enable-BitLocker -MountPoint c: -EncryptionMethod XtsAes128 -UsedSpaceOnly -TpmProtector $today = Get-Date $scheduledtime = $today.Date.AddHours(23) [int]$SecondsToMidnight = ($scheduledtime - $today).TotalSeconds shutdown /r /t $SecondsToMidnight msg.exe * "Bitlocker Encryption has been enabled. A reboot is needed before the encryption will apply and has been scheduled for $scheduledtime local time. You can reboot before this if you prefer." #start-sleep 90 #msg.exe * "This Computer will reboot in 30 seconds to bitlocker Encryption" #start-sleep 30 #Restart-computer -force } #endregion functions #region execution $BitLockerStatus = Get-BitLockerVolume -MountPoint c: if ((Get-Tpm).tpmpresent -eq $true) { #If Volume is in the process of encrypting or decrypting the Volume status will not say fully. Don't make changes when it changes if (($BitLockerStatus.ProtectionStatus -match 'off') -and ($bitlockerstatus.VolumeStatus -notmatch 'progress')) { #NoBitlocker is enabled so run it. if ($BitLockerStatus.VolumeStatus -eq 'FullyDecrypted') { $recoverykey = $BitLockerStatus.KeyProtector | Select-Object -ExpandProperty recoverypassword if(!($recoveryKey)){ Add-BitLockerKeyProtector -MountPoint c: -RecoveryPasswordProtector } $newStatus = Get-BitLockerVolume -MountPoint c: $recoverykey = $newStatus.KeyProtector | Select-Object -ExpandProperty recoverypassword Start-Process -FilePath "$env:PWY_HOME\CLI.exe" -ArgumentList ("setVariable recoverykey ""$recoverykey""") -Wait if ($newStatus.KeyProtector -match 'Recovery') { Start-BitlockerEnable } } #Bitlocker must be Partially enabled where drive is fully encrypted, but protection is off and no protectors exist. #Typically this is using xtsAES128 so you may wish to disable-bitlocker, then re-enable it with your protectors and prefered encryption level. else{ Disable-BitLocker -MountPoint 'c:' $decryptInProgress = $true While($decryptInProgress -eq $true){ $decryptstatus = Get-BitLockerVolume -MountPoint 'c:' if($decryptstatus.VolumeStatus -match 'progress'){ Start-Sleep 2 } else{ $decryptInProgress = $false } } Add-BitLockerKeyProtector -MountPoint c: -RecoveryPasswordProtector $newStatus = Get-BitLockerVolume -MountPoint c: $recoverykey = $newStatus.KeyProtector | Select-Object -ExpandProperty recoverypassword Start-Process -FilePath "$env:PWY_HOME\CLI.exe" -ArgumentList ("setVariable recoverykey ""$recoverykey""") -Wait if ($newStatus.KeyProtector -match 'Recovery') { Start-BitlockerEnable } } } #BitLocker should already be enabled so log keys, volume status etc. else { $recoverykey = $BitLockerStatus.KeyProtector | Select-Object -ExpandProperty recoverypassword $ProtectionStatus = $BitLockerStatus.ProtectionStatus $VolumeStatus = $BitLockerStatus.VolumeStatus Start-Process -FilePath "$env:PWY_HOME\CLI.exe" -ArgumentList ("setVariable recoverykey ""$recoverykey""") -Wait Start-Process -FilePath "$env:PWY_HOME\CLI.exe" -ArgumentList ("setVariable ProtectionStatus ""$ProtectionStatus""") -Wait Start-Process -FilePath "$env:PWY_HOME\CLI.exe" -ArgumentList ("setVariable VolumeStatus ""$VolumeStatus""") -Wait } } else { $recoverykey = 'NoTpm' Start-Process -FilePath "$env:PWY_HOME\CLI.exe" -ArgumentList ("setVariable recoveryKey ""$recoveryKey""") -Wait } #endregion execution You can modify the above script as you wish. I personally have gone with a bit of a cautious approach where it will not skip the hardware check which will reboot the pc, but for me I prefer this approach to having it encrypt the drive without checking tpm is all good which could then result in the drive being encrypted and locking out the end user. 
 
At the end of all this, you now should be able to Both Enable bitlocker encryption as well as pull your recovery keys from pulseway like so :