AC_Martin_J

You can run the following script on a domain controller to see all enabled users using Powershell in Pulseway: get-aduser -filter * -properties samaccountname, enabled, givenname, surname | where {$_.enabled -eq $true} | select -property samaccountname, givenname, surname | sort-object -property samaccountname The output will be all users in AD where the enabled-attribute is set to true (ie all active users), and they will be presented in alphabetical order sorted by their username.

Remember to not only enable workstations to generate notifications, but also enable the account/s to receive them as well. Have a look under Account -> Notifications and make sure that they are enabled there too.

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!

Thanks for your reply! I can't find any misconfiguration regarding the group policies. This is a behavior that'll happen on our workstations from time to time. I can always remote control the clients, but the issue is that I sometimes have to wait one minute because the notification isn't shown (I know this because I'm talking to the end user via phone simultaneously). Have a look at the following pictures to see how I've configured it all:

This functionality is not available in the Pulseway Remote Control software at the moment. As a pulseway user, I can't determine whether I want this functionality or not. Because I can see the benefits but I also see them as security concerns at the same time (if the account were to be compromised).

I appreciate you sharing the script, but please note that the password is stored unencrypted and visible to others in both the script itself (if you edit the code) and in the registry. You might want to consider using the Autologin-tool from Mark over at Windows SysInternals instead. It's a great tool to add autologin to kiosk-computers and such, while keeping the credentials safe since they will be encrypted. https://docs.microsoft.com/en-us/sysinternals/downloads/autologon To turn it back off, you simply run the tool again and disable the autologin feature. In other situations, there's also a Cmdlet to gather credentials and store the password as a secure string which is handy. You can try the following to test it out: #Running this first line will open a prompt for you to enter username and password and store it in $Credentials $Credentials = Get-Credential #Running the second line will output the UserName that was entered previously, and in a readable formt $Credentials.UserName #Running the third line will output the Password as a secure-string (non readable) $Credentials.Password #You can then use the stored information when running the Invoke Cmdlet for example (ie running a scriptblock on another computer), or when connecting to Office 365. #Furthermore it's possible to convert the secure-string into an unreadable text format so you can save it in plain text but without the risk of having it compromised. #Running the fourth line will convert the password from a SecureString and store it in $Password $Password = $Credentials.Password | ConvertFrom-SecureString #You can then compare the output of $Credentials.Password and $Password by running them separately. The first one will show the SecureString-data, and the second will show the same information but in plain text while it can also be exported/saved for future use, unlike a securestring. #Running the fifth line will export the password in an unreadable plaintext-format and save it as a file, so you can import this at a later point in time (ideal when running scripts with the task scheduler where the script needs credentials in order to proceed). Set-Content "C:\temp\MyPasswordData.txt" $Password #Running the sixth line will import the password and convert it back to a securestring so you can use it in your scripts. $ImportedPassword = Get-Content "C:\temp\MyPasswordData.txt" | ConvertTo-SecureString Hope this helps!

@Greg Candido It's possible to run Pulseway with User Impersonation, and by doing so you should be able to access network resources because it's essentially running as a user instead of system. I did the following in our setup: Create an account for the Pulseway service in active directory. Give the new account share permissions and file permissions on the directory where the MSI-file resides. Open Pulseway Manager on one of the clients. Open Settings -> Runtime and check the "Enable Powershell User Impersonation". Enter the credentials created in the first step above, including the domain. Apply the settings and exit the Pulseway Manager. Open registry editor on the same client and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\MMSOFT Design\PC Monitor Copy the data of each of the following keys for later use: PowerShellUserImpersonation PowerShellUserImpersonationDomain PowerShellUserImpersonationPassword PowerShellUserImpersonationPasswordCtrl PowerShellUserImpersonationUsername Open the group policy manager on a domain controller and create a new group policy object. Expand Computer Configuration -> Preferences -> Windows Settings > Registry and create the following keys: PowerShellUserImpersonation Action: Update Hive: HKEY_LOCAL_MACHINE Key path: SOFTWARE\MMSOFT Design\PC Monitor Value name: PowerShellUserImpersonation Value type: REG_SZ Value data: 1 PowerShellUserImpersonationDomain Action: Update Hive: HKEY_LOCAL_MACHINE Key path: SOFTWARE\MMSOFT Design\PC Monitor Value name: PowerShellUserImpersonationDomain Value type: REG_SZ Value data: %the domain name copied from previous steps% PowerShellUserImpersonationPassword Action: Update Hive: HKEY_LOCAL_MACHINE Key path: SOFTWARE\MMSOFT Design\PC Monitor Value name: PowerShellUserImpersonationPassword Value type: REG_SZ Value data: %the password data copied from previous steps% PowerShellUserImpersonationPasswordCtrl Action: Update Hive: HKEY_LOCAL_MACHINE Key path: SOFTWARE\MMSOFT Design\PC Monitor Value name: PowerShellUserImpersonationPasswordCtrl Value type: REG_SZ Value data: %the password ctrl data copied from previous steps% PowerShellUserImpersonationUsername Action: Update Hive: HKEY_LOCAL_MACHINE Key path: SOFTWARE\MMSOFT Design\PC Monitor Value name: PowerShellUserImpersonationUsername Value type: REG_SZ Value data: %the username data copied from previous steps% Link the newly created GPO to an OU with one or more test-clients and verify that the user impersonation is working, and then enable it on all the clients in the domain where you want to enable the functionality.

I'm currently running Pulseway OnPrem (7.0.0 build 120 release 283), and I'm using Pulseway Remote Control (6.6.3). The issue I have experienced is that the remote control notification doesn't always show up on the client when I attempt to remote control a session. We have 150+ computers in our environment and sometimes it works fine, and sometimes it doesn't, and the different behavior can even occur on the same machine from time to time. Pulseway is configured to automatically allow the remote session if no one accept (or deny) the request within a minute, and I have noticed that even if the notification doesn't show up, the connection will still be established when the timer runs out. To make things clearer, here are two different scenarios. (Scenario 2 is the incorrect behavior) Scenario 1: Select computer -> Select active session -> Client notification "do you allow x to remote control" -> User press Allow -> Remote session established Scenario 2: Select computer -> Select active session -> Client notification not shown -> 1 minute timeout -> Remote session established Are you guys aware of this? Has anyone else experienced the same behavior?

@Chris Nah, that's not at all what I'm after, but thanks.. I want to use the Pulseway message feature ad-hoc, for example when a critical system goes down and I need to immediately notify all my users that I'm aware and that we are working on a solution.

I might have misunderstood the whole thing here, but if you want to move a client between Organization, sites or groups as Chris mentioned, then the client needs to have Pulseway agent 6.0 or later, which is where this functionality was first introduced.. I've had a couple of devices myself that I couldn't move because of this, but it went fine after booting them up and allowing pulseway to update to a newer version.

Hi all! I'm frequently using the "Send Message" feature that Pulseway provide, and it's usually when I need to quickly distribute information to our employees. I've found that you can send messages to a specific client, or a specific group (both of which are great). But it would be even better if we can select multiple groups to send the message to as a third option. It's not a big deal to copy the message and go into each group and send the message from there, but it's more of a convenience thing. Please consider it at least! // Martin

Yep, this is great! I suppose some information can be extracted from a report, but having the information stored on each system in the GUI would improve the daily workflow.

Hey guys! I have a couple of things that would greatly improve my own workflow and also improving the remote desktop client in general, so I decided to collect them all in one thread. Please share your thoughts. 1. Adding sections for tags, notes and last logged on user in the Remote Desktop Client GUI. This is illustrated in the uploaded picture within this thread. 2. Transfer files. Both ways would be great, but at least being able to transfer from host to client at first. 3. Portable remote sessions. What I mean by this is to have a link that a user can go to (for example https://pulseway.yourdomain.com/help), and then download a portable version of Pulseway Remote. The user would then let me know of a PIN-code that can be entered within my Remote Desktop Client to remote control his/her desktop. 4. We are currently able to toggle the ask for confirmation-behavior, and I have configured a 1 minute timeout before it is automatically allowed. However, my suggestion is that the timeout won't apply when the "Login"-session is the only session available. // Martin

I didn't like this either, but I created a GPO to remove the shortcuts instead.. It seems to be working well.

Hey guys! I think Pulseway would be even better if the alerts would clear themselves when resolved.. For example, a server with available windows updates will reboot during our custom maintenance window but the alert will stay until I manually clear it in either the webGUI or the Dashboard app. Those kind of alerts along with cpu spikes, short memory outtage etc are more like "white noise" in the monitoring for me and I'd like to focus on alerts where a proper action is needed in order to resolve. To build further on this idea an even better improvement would be to tie alerts to scripts, so if Alert X is triggered, script Y will run and Alert X will be cleared. Let me know what you think! // Martin

At least I think it's exciting that the new version is being rolled out =). Looking forward to this (apart from the issue mentioned in this thread).. Any news when the update may get distributed to us who doesn't use SaaS?

Hi Paul! I thought I'd ask in this thread, rather than creating a new one.. Is it possible to set which email a support request should be sent to? I'm asking because I would like to receive all support requests on a dedicated email address for that specific purpose (while the notifications are sent to another dedicated address). But it seems like the support request will be sent to the email address of the account which is connected to the Pulseway Manager on that specific client. A working solution could be if those emails are sent to an address based on what is specified in the "Company email"-section at the "Support Info Details"-tab.

Looking forward to the next release of Pulseway then Sharing scripts, group policies etc are also settings that I'd like to be shared between accounts.

+1, this is a great idea!

Thanks Paul! That sounds promising.. Please let us know when the REST API has been adjusted accordingly, so we can test it.

No problem! I'm glad it was useful for you. My installations through Pulseway have gone smoothly, so I don't know about the failures you've gotten. In my case, it became more manageable to trigger the installation via script, rather than via Pulseway. Especially since clients imported with other pulseway-users aren't shown in the webGUI (for those, you have to login to the specific account and install from there, and that method isn't going to cut it). I wish that we find a way to register the integration between Webroot and Pulseway after running the script, it will save us some more time and make the deployment easier. There are some registry entries at HKLM:\Software\MMSOFT Design\PC Monitor\Addons\2 that seems related to Webroot. I saw the key code written there, in plain text. It was under the subkey "LicenseHash" on a couple of our workstations, and they were installed via the Pulseway WebGUI if I'm not mistaken.. However, the sideloading-operation leaves the same subkey blank. There is also a second subkey, called "InstallationId" that I'm curious about. The "LicenseHash" could be easily populated with the correct key code, but I'm more worried about the "InstallationId", as it contains a long hash value generated from somewhere, somehow. I'm hoping that the Pulseway-developers can contribute with some useful information here.. =)

Hey.. I've been moving clients between groups with the script below, and it might be useful to some of you.. If you need to do it in a bigger batch, then maybe you can create a scope and attach the script to a task that has the scope connected to it. Also, tags could be used to further narrow down the targeted clients. #Replace 'NewGroupNameHere' with whatever group name you would like to use. #Example, $NewGroup = 'Servers' $PreviousGroup = Get-ItemProperty -Path "HKLM:\Software\MMSOFT Design\PC Monitor\" -Name GroupName $NewGroup = 'NewGroupNameHere' Write-Host 'The Pulseway group is currently set to:' $PreviousGroup.GroupName Write-Host 'The Pulseway group will be set to:' $NewGroup Set-ItemProperty -Path "HKLM:\Software\MMSOFT Design\PC Monitor\" -Name GroupName -Value $NewGroup Write-Host 'Verifying...' $Verification = Get-ItemProperty -Path "HKLM:\Software\MMSOFT Design\PC Monitor\" -Name GroupName Write-Host 'The Pulseway group was successfully changed to' $Verification.GroupName

Hey guys! I've been testing the Webroot trial recently and it has been working fine, but I found something where there is room for improvement.. The Webroot installation can be done through Pulseway already, and everything that's needed is basically the Key Code assigning the client to the corresponding Webroot dashboard. This method works fine, but my idea is to automate as many of these tasks as possible, hence Powershell come in to play. Webroot have published a document with other deployment methods, such as GPO or MSI, and I'm mostly interested in the latter. So I created a script for the installation task, which is working fine in itself. But I also found out that the client is shown as "Not installed" in Pulseway afterwards. I spoke with support representatives from Pulseway about this, and a workaround is to use the "Install"-button in Pulseway to create the connection. They told me that the software won't be reinstalled by doing this, but simply associate the agent with Pulseway.. It got me thinking.. There should be a way to trigger this "Install"-function elsewhere, and a smooth solution would be if it could be triggered from the same script as the installation. Maybe something is written in the registry (client side), that we could use? Does anyone else have a solution on how to perform such a task? Webroot deployment documentation (Command line options and other install methods) Here is the script that I've got so far, feel free to use it, if you find it useful! #Replace "KEYCODEHERE" at the arguments-variable with the Key Code shown in your own Webroot Dashboard. #Example: 'GUILIC=XXXX-XXXX-XXXX-XXXX-XXXX CMDLINE=SME,quiet /qn /l*v install.log' $tempdir = get-item -Path "$Env:SystemDrive\Temp" -ErrorAction SilentlyContinue if ($tempdir -eq $null) { New-Item -ItemType "Directory" -Path "$Env:SystemDrive\Temp" Write-Host 'Creating Temp-Dir.' } $Downloadurl = 'http://anywhere.webrootcloudav.com/zerol/wsasme.msi' Write-Host 'Downloading executable to local storage.' $Executable = "$Env:SystemDrive\Temp\wsasme.msi" $Arguments = 'GUILIC=KEYCODEHERE CMDLINE=SME,quiet /qn /l*v install.log' $wc = New-Object System.Net.WebClient $wc.DownloadFile($Downloadurl, $Executable) Start-Process $Executable -ArgumentList $Arguments -Wait Write-Host 'Installing' Remove-Item -Path $Executable Write-Host 'Cleaning up locally stored data.' Start-Sleep -s 30 $program = 'Webroot' Write-Host 'Verifying installation...' $32bit = ((Get-ChildItem "HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall") | Where-Object { $_.GetValue( "DisplayName" ) -like "*$program*" } ).Length -gt 0; $64bit = ((Get-ChildItem "HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall") | Where-Object { $_.GetValue( "DisplayName" ) -like "*$program*" } ).Length -gt 0; if ($32bit -eq $True -or $64bit -eq $True) { Write-Host "$program has been successfully installed." } // Martin Johansson