Can someone tell me why this script works locally from the server but not from Pulseway. I've tested running the script both with impersonation enabled and disabled. Both tests were done on server 2012 R2. One with default Powershell version and one with 5.1. This script runs perfectly fine from the server itself just not through pulseway. I have several scripts that give the same type of error. I'd appreciate any help so I can figure this out. It seems like Pulseway doesn't like certain characters?
ForEach ($COMPUTER in (Get-ADComputer -Filter '*' | Select -ExpandProperty Name))
$key = “SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\Results\Install”
$keytype = [Microsoft.Win32.RegistryHive]::LocalMachine
$RemoteBase = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey($keytype,$Server)
$regKey = $RemoteBase.OpenSubKey($key)
$KeyValue = $regkey.GetValue(”LastSuccessTime”)
$System = (Get-Date -Format "yyyy-MM-dd hh:mm:ss")
if ($KeyValue -lt $System)
Write-Host " "
Write-Host $computer "Last time updates were installed was: " $KeyValue
This is what it looks like when ran from the server without involving pulseway
We've noticed that some of the ticket titles from the RMM system to PSA are way too long, please check the attachment. Other events like backup failures/successes are fine but CPU and Memory usage tickets are massive. Would you be able to look into a way to create less obtrusive ticket titles from RMM?
We've also noticed that the RMM priority doesn't necessarily map to a PSA priority. Is there a way to do this or is this something to come out in the future?
Per PCI 3.2, TLS 1.0 will soon be required to be disabled. We tested this out on a few of our servers with Pulseway and after doing so the Pulseway Agent on the server stop reporting into the Pulseway Console. When trying to verify the account on the Pulseway Manager 5.1 we got the following error:
An error occurred while receiving the HTTP response to https://ws15.pulseway.com/Server.svc. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to theservice shutting down). See server logs for more details.
The only way to fix it was to re-enable the TLS 1.0 Client Protocol here:
I checked Pulseway's SSL Cert on Qualys SSL and it said it accepted TLS 1.0 to 1.2 but it must be something in the Agent code that limits it to TLS 1.0.
Not sure if this should be a Bug or Feature request but just wanted to make the team aware of the issue.
I've been trying to automate as many of my maintenance tasks as possible with Pulseway, but I've noticed that the scheduled start time does not correspond with the actual start time. It's not consistent though, so it doesn't appear to be a time zone issue. Here's some examples:
Sample: Cleanup Temporary Files
Weekly on Thursday starting on 29 December 2016 at 20:00
16 February 2017 21:39 Took 8 seconds Result: Successful 15 February 2017 20:00 Took 15 seconds Result: Successful 8 February 2017 20:00 Took 15 seconds Result: Successful 1 February 2017 20:00 Took 22 seconds Result: Successful 25 January 2017 20:00 Took 1 minute and 42 seconds Result: Successful 18 January 2017 20:00 Took 18 seconds Result: Successful 12 January 2017 22:06 Took 1 minute and 3 seconds Result: Successful 11 January 2017 20:00 Took 20 seconds Result: Successful 4 January 2017 23:56 Took 10 seconds Result: Successful Other tasks have the same issue with scheduling. While basic maintenance scripts like time syncs, temp file cleanup are not time sensitive, Other tasks are. I have my complete weekly patch and update sequence saved as scheduled tasks, and I can't use it because the scripts are not guaranteed to run during my maintenance window. Any ideas?