Modifying Windows registry in a Bamboo task?

[Paul Smith]

I have a Bamboo remote agent running on a Windows 10 server.  One of the plans I want to create is for testing an ODBC driver.  In order to install the driver so it can be tested I need to modify the Windows registry HKLM (HKEY_LOCAL_MACHINE) section to add information about the driver DLL.

When I do this (from a cmd.exe inline Script task) it succeeds with no errors and if I run reg query in my Bamboo task script, both before and after I run the client, I can see all the settings just as I want them.  However starting the ODBC client fails saying no driver is registered.

Then when I log into the Windows system and look at the registry, none of my HKLM settings exist (I purposefully didn't remove them again).  Also, if I'm logged into the Windows system and I run the exact same test from a cmd.exe it works great with no errors: it finds the driver and the tests succeed.  And the HKLM settings still exist after the test concludes of course.

Is there some magical thing that the Bamboo agent does that fakes out the Windows registry so that reg add / reg query / etc. commands pretend to succeed while not actually  modifying the registry at all?  That's the only way I can explain the behavior I'm seeing.  But, I can't seem to find any info about anything like this in the documentation.

[Paul Smith · Accepted solution]

A co-worker of mine found the answer (thanks Eusebio!)

The problem was that on these systems the Bamboo agent was started using a 32bit version of the Java JRE.  This caused 32bit mode version of regedit to be run.  When this happens and you update an entry in the HKLM\Software section of the registry, it will "magically" update that entry in the HKLM\Software\WOW6432Node section instead, behind your back.  So as long as you're running the 32bit versions of software it looks like everything is set right.  But when you run 64bit software like drivers etc. and it looks in the real HKLM\Software section, those changes are not found.

Once we ensured that the Bamboo agents were started with a 64bit Java JRE everything started working as expected.

[Eduardo Alvarenga]

Hello @Paul Smith

Can you confirm if the user that is running the Bambo remote agent has enough privileges to edit the registry? Can you share the command/script you are running through cmd.exe?

Regards,

Eduardo Alvarenga
Atlassian Support APAC

[Paul Smith]

Well, the user account running the agent definitely can "run as administrator" (this is a dedicated bamboo agent host and there's only one user account on it, and I log in as that account and I can "run as administrator").

I don't know if the bamboo agent itself is running with elevated privileges or not.  I thought it was, since when I run commands that modify the registry I get no errors and a query run in the task shows it's there.  But since other parts of the system can't see it and it doesn't appear visible outside the task script I'm no longer sure.

Unfortunately I'm not very knowledgeable about Windows: I really only do UNIX systems like Linux and MacOS.

The commands I'm running are things like:

reg add "HKLM\Software\ODBC\ODBCINST.INI\ODBC Drivers" /v "Test ODBC Driver" /t REG_SZ /d "Installed" /f
The operation completed successfully.

Then in the task script right after the above command I can run:

reg query "HKLM\Software\ODBC\ODBCINST.INI\ODBC Drivers"

and it prints the driver name I just added.

But then when I RDP to the server and run the same query, it shows nothing.  And, my ODBC driver (which is trying to look up this driver name) fails saying no such driver exists.

But, when I run these exact same commands via RDP from a cmd.exe with administrator privileges it works fine and the ODBC driver is found.

[Eduardo Alvarenga]

Hello @Paul Smith

I'm not sure about your Windows setup, you mentioned you run the commands with "Administrator privileges" but you don't mention your Bamboo user that runs the agent has such privileges. Though it can run the command "as an Administrator", you still will need to enforce the run of reg as an Administrator to make it work. Be careful with escaping the quote characters:

runas /user:Administrator "reg add \"HKLM\Software\ODBC\ODBCINST.INI\ODBC Drivers\" /v \"Test ODBC Driver\" /t REG_SZ /d \"Installed\" /f"

You will also need to enable the "Administrator" user (or equivalent account) and disable UAC to make it work.

Eduardo Alvarenga
Atlassian Support APAC

[Paul Smith]

Hi @Eduardo Alvarenga  I tried to be clear about the environment but I guess I failed.  There is only one account on the system.  That account is allowed to start programs with administrator privileges.  That account runs the bamboo agent.  I don't know if the bamboo agent process (java) was started with administrator privileges or not.  I'm sorry but I'm not a Windows person so I don't know how to figure out these things.

I tried the runas command you suggested.  There are two problems: first, it asks for a password so it can't be used in a script (however I think I read somewhere there's a way to cache the password so maybe that's possible).  Second, no matter what password I enter it says "5: Access is denied."  This makes me think I don't know the needed password (I tried the account password for example).  If I start a cmd.exe terminal "Run as Administrator", I can do that and the reg command works.

It would be good to find a way to make this work but that's not actually the main thing I have a question about.

The main thing I want to know is, why do these registry commands all succeed when I run them from within my Bamboo task, but they don't actually seem to affect the real registry on the system?

That is the part that really confused me: the `reg add` commands work, the `reg query` commands see the changes, but the changes aren't actually there in the registry.  Once the task ends, all those changes are gone.  And even while the task is running other parts of the system (like the ODBC framework) can't see these changes.

If the commands failed, I would know that privileges were wrong.  But they don't fail, so I spent a lot of time trying to figure out what was wrong.  So I'd like to understand how this happens.

[Eduardo Alvarenga]

Hello @Paul Smith,

I understand your system has only "one" account, but Windows has many built-in users that can't be removed. When you state your Bamboo user can run commands "with administrator privileges" it is not the same as running a command "as an administrator". You need to tell Windows that the command needs higher privileges, and for that you use runas.

You can overcome the password requirement by running the command manually and using the "/savecred" option once. It will save the credentials. You can also use psexec from Windows Sysinternals to specify a password on the command line.

There are also other creative ways to create an "administrator" link, including using Powershell tricks. You will need to Google that around to find the solution that best suits you.

If you are receiving a "Permission Denied" upon running as an administrator, it may be because the Administrator account is locked/disabled. Please review that as I have advised in my previous message.

It is also important to remind you that Bamboo on Windows may run as a Service (if enabled). When running as a service, Bamboo will run as the "Local Service" user account by default and not the "Bamboo" user account. If that's your case you will have to review that user privileges and validate the "reg" interaction from that account. You can modify the service to run as the "Bamboo" user by following this KB:

• Running Bamboo as a Windows service as the local user 

About why "reg" commands work when within a task in Bamboo, I'm really clueless on that, you will need to reach out to your Windows team and ask them if that behaviour is expected or not as this is something that can't be solved by Bamboo itself.

Eduardo Alvarenga
Atlassian Support APAC