Tentacle new-certificate throwing UnauthorisedAccessException


I’m trying to install Octopus Tentacle as part of an automated process to stand up a new virtual machine in Windows Azure. As part of this process, after the machine has come online, I’m using the Invoke-Command cmdlet to run through the process of downloading & installing Octopus:

invoke-webrequest -outfile Octopus.Tentacle.msi -uri $TentacleDownload
msiexec /i Octopus.Tentacle.msi /quiet
tentacle configure --appdir="C:\Octopus\Applications" --port=$TentaclePort --trust=$ServerThumbprint
tentacle new-certificate
tentacle install
tentacle register-with --server=$ServerUrl --publicHostname=$TentacleFQDN --environment=$ServerEnvironment --apikey=$AdminApiKey

Unfortunately, the tentacle new-certificate command throws an exception:

Generating and installing a new cetificate...
System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
   at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
   at Octopus.Shared.Security.CertificateGenerator.Generate(String fullName, Boolean exportable) in c:\w\e6923628be6eaf72\source\Octopus.Shared\Security\CertificateGenerator.cs:line 25
   at Octopus.Tentacle.Commands.NewCertificateCommand.Execute() in c:\w\e6923628be6eaf72\source\Octopus.Tentacle\Commands\NewCertificateCommand.cs:line 31
   at Octopus.Shared.Startup.CommandProcessor.Process(String[] args) in c:\w\e6923628be6eaf72\source\Octopus.Shared\Startup\CommandProcessor.cs:line 40

Because this is part of an automated deployment, nobody has ever logged into the machine manually via Remote Desktop. However, if I do Remote Desktop and issue the same commands (obviously as the same user I’m using in Invoke-Command), then the command works. Furthermore, running the command via Invoke-Command works fine from then on too.

Having to manually log into each machine we deploy isn’t really an option, so I was wondering if anybody can shed any light on what’s going on here, or give me some other hints on how to go about automating the deployment of Octopus Tentacle on Azure VMs.



Hi Richard,

Could you check this StackOverflow thread to see if any of the solutions there work for you?


Hi Paul,

Thanks for getting back to me.

I had read that before and unfortunately it seems to be a suggestion for solving it in a Ruby solution, I’m looking for something that is pure Powershell, or for some other way of doing whatever this mixin is doing. Trouble is, I don’t know what it’s doing! :slight_smile:


Did anyone solve this… I am having the same issue trying to remotely install and configure the tentacle on an azure vm

Hi E,

Attempting to understand and emulate what the suggested Ruby package does is too time consuming for me at the moment, so currently I’m stuck with having a separate script that is run by manually logging into each web server after it’s deployed :frowning:


Thanks for following up. Ultimately the problem is in the tentacle code. There is a way to create and load certificates without requiring the profile to be loaded. I do this in my app.

I will keep working thru this and see what woke around I can come up with. I have tried a number of variations already but the they are not working in the remote powershell console the way I expect. I am currently using chocolatey to install the msi so I will first attempt to see if the chocolatey running loads the exe with a profile.

Sent from my iPhone

Hi all,

Thanks for the updates. I’ll try and reproduce this and find a workaround that we can include in our documentation. When loading certificates we shouldn’t require the profile anymore, but when generating them I think we still do. I’ll look into Eric’s suggestion that we may be able to generate the certificates without needing a profile too (Eric, I don’t suppose you have sample code to share?)

If you have time, could either of you please share the exact steps you’re using to do this with Azure? I take it you are provisioning a VM, waiting for it to report as being “ready”, and then running Invoke-Command against the public IP address of the VM?


FYI, I’ve created an issue here to track this:


Hey Paul,

I was incorrect, I load existing certs without the profile, but I do not created them in my app. We created them out of proc, so I am not sure if this can be done without the profile loaded, I assume it would use the same cert store that is used the way we load them.