Working on a script to append registry key values however I'm running into a problem when trying to create a variable from the current key value. What is the proper syntax that the procedure is looking for?
I'm just guessing that it would be something like HKLM\"path"\ /"key" just like in a command shell but I couldn't find anything in the Kaseya documentation.
Sorry if this is a dumb question.
The getRegistryValue() step takes this format:
For clarity, registry "keys" are the folders on the left pane in Regedit. The "values" are the files on the right and we are getting the data within those.
Here is the Kaseya help file for this step and others like it: help.kaseya.com/.../index.asp
Awesome thank for the help.
Second question. Can I edit values in HKEY_CURRENT_USER? Scrip seems to work for HKLM but not HKCU.
That is where things get tricky. By default, the agent runs in the context of LOCAL SYSTEM. When you make changes to HKEY_CURRENT_USER, you are actually modifying the SYSTEM profile. There are ways to work with HKCU, but you will have to be creative. For example, you could run an impersonateUser() step first and then an executeShellCommand() step with the option to run as User. The shell command might be something like "reg query HKCU\Key /v Value>>C:\regTemp.txt" (output to a file so we can get its content in a variable for appending)
This old chestnut again
Another alternative is to look at using the HKEY_USERS (HKU), more complicated but it works great.
Thanks for the tips guys. Will see what I can get going tomorrow!
Not sure what the issue is that you are experiencing, but the various registry related agent procedure steps:
getVariable("Registry Value", "HKEY_CURRENT_USER\....
do in fact support reading/writing to HKEY_CURRENT_USER without special workarounds...
The Kaseya Agent is in fact user aware and as long as KaUsrTsk.exe is running within the context of the logged on user, you should NOT need to jump through hoops using executeShellCommand() steps with the "Execute as User" Run As option enabled and so forth.
KaUsrTsk.exe is a process installed when the Kaseya Agent is installed, and should be loaded via the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run registry hive when a user logs onto Windows and Explorer loads. There should be a REG_SZ under the above key called KASH<customerId><agentInstallGuid> where <customerId> is your Kaseya Customer Id (the first 6 characters of your Kaseya License Code) and <agentInstallGuid> is a unique installation Guid specific to your Kaseya Server Install. The value of this REG_SZ will be the path to "C:\Program Files\...KaUsrTsk.exe" or where ever your Kaseya Agent install path is if you branded the install path in your Agent Deployment Package install configuration.
This KaUsrTsk.exe runs as the logged on user when Explorer loads (if there is a user logged onto the machine) even though AgentMon.exe (the Kaseya Agent Windows Service) is running as Local System.
When the Agent Procedure makes calls to HKEY_CURRENT_USER, it will have KaUsrTsk.exe make those calls automatically as long as there is a user logged on and KaUsrTsk.exe is loaded in memory and is running as the currently logged on user. If KaUsrTsk.exe is not running for some reason then the registry calls will be made by AgentMon.exe which is running as Local System.
Therefore, I would check if KaUsrTsk.exe is in fact running on the machine when the user is logged on. You can do this locally on the machine by pulling up Task Manager and looking for KaUsrTsk.exe, or in the Kaseya VSA by looking at the the Kaseya Agent status icon which should look like one of these icons:
You are also advised when writing scripts like this to check with an IF isUserLoggedIn() step to ensure that a user is actually logged on. This IF isUserLoggedIn() check will return True if KaUsrTsk.exe is running on the machine as the logged on user, or False if KaUsrTsk.exe is not running.
Now there is a special case where KaUsrTsk.exe will not be running, and that is when the user is logged on via a Terminal Server/RDP (or Citrix) session rather than being logged onto the machine at the console.
I have included an agent procedure that you can import, which tests the various registry related agent procedure steps for you to use as a reference. It creates a registry key called HKEY_CURRENT_USER\KaseyaAgent-HKCUTest with a number of registry values (two REG_SZs and a REG_DWORD) and then reads the values back, displays the read values back to the screen so the logged on user can see them, and also copies xcopy,exe back from the agents c:\windows\system32 path to the Kaseya Servers Agent specific Get File path (see the Agent Procedures->Get File function to verify the xcopy.exe is copied back to the server for the agent you test on). I would install an agent on your own machine, and then run this test agent procedure on your own machine.
Kaseya Professional Services
Aye, but counting on users being logged in sucks. The methods above work regardless of user status.
A real slick way to go about HKCU settings for all users is to hit all the profiles present in HKEY_USERS (people currently logged in) and then load all the NTUSER.DAT files for profiles which are not logged in with 'reg load'. I would love to see Kaseya implement a step for this! It would be super powerful when you consider managing Group Policy settings via the registry.
More discussion on this topic: community.kaseya.com/.../82117.aspx