I have a powershell script to output the remote desktop license server to a text file on the c drive. This script works with I run it locally at the system. However, when I run it through a kaseya script the output file is always blank(empty). Any idea's???
Im running Kasyea 6.5. I have attempted to call my ps1 file from a bat file and just run it as a powershell script. Once again when I run the script locally it works correctly. I have added pauses in the kaseya procedure to allow some time for the script to run with no changes.
Have you tried executePowershellCommand as user?
You shouldn't need to add pauses.
Try running the script manually as the SYSTEM account and see if it works.
You can do this with psexec from pstools by running 'psexec -s cmd.exe', then attempting to launch your powershell commands.
Yes i have tried executePowershellCommand as user.
I just tried your suggestion. My script runs correctly locally but again not from a kaseya script. Here is my script files:
Powershell.exe -ImportSystemModules - executionpolicy remotesigned -File C:\*******.ps1
dir SpecifiedLicenseServers > c:\text.txt
We are wanting to run these scripts on server 2008 through kaseya agent procedures. My latest procedure that does not produce the complete output is:
writeFile(******.bat, c:\*********.bat, All Operating Systems, Halt on fail)
writeFile(******.ps1, c:\*********.ps1, All Operating Systems, Halt on fail)
impersonateUser(domainadmin account creditials)
executeFile(C:\*********.ps1, Execute as user and wait, All Operating Systems, Halt on fail)
This should produce a text file of 1k not 0k on our systems. I have also tried calling my ps1 using executePowershell command. When these files are ran locally they produce a text file with information in it. When ran through Kasyea procedures they produce a 0k text file(empty).
First, just using just "executeFile" won't work to just call your PS1 file. You're also missing your ImportSystemModules switch there.
If your script works when using the system account you don't need to use impersonate user / run as user.
This seems odd though - set-location seems to be looking for what appears to be a network share called rds, which won't be accessible if you were actually executing your powershell command as a SYSTEM account, which will otherwise not be able to access a network share.
Oops!! sorry executeFile is for the bat not the ps1. The -ImportSystemModules switch is called in the bat file.
What about my question about the set-location rds and system account?
Ben, RDS: is not a mapped drive, or UNC path, but rather the powershell "Drive" for the Remote Desktop Services Provider"
Jamesb... From what I can see it seems to somehow not like actually importing the system modules that contain the powershell drive... I'm not sure why. I ran some tests myself, though I simplified your overall script down to a simple one liner in powershell..
powershell -ImportSystemModules -command Write-Output (gci rds:\rdsconfiguration\licensingsettings\SpecifiedLicenseServers).Name
I can run that just fine in the interactive shell, but not from Kaseya... In a kaseya script the return gives me an error specifically indicating that it can't find the RDS: drive, so Ben was on the right track overall with the drive path..
Aha, and it appears to be with the environment setup...
I changed the onliner to :
powershell -command import-module remotedesktopservices; Write-Output (gci rds:\rdsconfiguration\licensingsettings\SpecifiedLicenseServers).Name
which again works from the normal interactive command prompt, but trying to run it as a command in Kaseya it gets an error stating that it couldn't find the module. So somehow, even impersonating the user, it doesn't appear that Kaseya actually loads the paths for the powershell environment.
I've successfully been able to run Jonathan's code via Kaseya in a ps1 file.
Import-Module RemoteDesktopServices$Name = (gci RDS:\RDSConfiguration\LicensingSettings\SpecifiedLicenseServers).Name
$Name | Out-File C:\kworking\test.txt
Simply write the file down to the agent, execute as 64bit user and write result to procedure log. You can always grab the text file as well if that's what you are after. If you are trying to write directly to the root of C:\ that might be where your issue lies.
Johnathan and Neal,
Thank you. This works perfectly!!!!