Octopus Offline Deployment failed with Powershell ParseException (missing the terminator: ".)

Hello. We use Octopus 3.1.3.

We create the Offline deployment package (Offline Package Drop Deployment target).

The result package was copied to machine with Powershell v2.

After the start executing Offline PS script we received parsing exception:
`PS D:\19.1.682.1> & '.\Production Application Box.Application.Deployments-1455.ps1’
The string starting:
At D:\19.1.682.1\Production Application Box.Application.Deployments-1455.ps1:23 char:324

  • & “Calamari\Calamari.exe” run-script -script “Scripts\Start Application Service.ps1” -variables "Variables

\Production Application Box.Application.Start Application Service.variables.json" -sensitiveVariables="Variables
Production Application Box.Application.Start Application Service.variables.secret <<<< " $PasswordArg
is missing the terminator: ".
At D:\19.1.682.1\Production Application Box.Application.Deployments-1455.ps1:25 char:3

  • #} <<<<
    • CategoryInfo : ParserError: ( $PasswordArg…ASTEXITCODE
      #}:String) [], ParseException
    • FullyQualifiedErrorId : TerminatorExpectedAtEndOfString`

The error string from the PS file is:

If ($Result -eq 0) { & "Calamari\Calamari.exe" run-script -script "Scripts\Start Application Service.ps1" -variables "Variables\Application Box.Application.Start Application Service.variables.json" -sensitiveVariables="Variables\Application Box.Application.Start Application Service.variables.secret" $PasswordArg $Result = $LASTEXITCODE }

"-sensitiveVariables=" looks suspicious. Why do we need equal sign…

Could you please check this potential defect?

Also there is next line in this file:
$PasswordArg="-sensitiveVariablesPassword="""+ $Password + ""

Why do we need to add empty string in the end? May be it’s necessary to add some symbol here?

Also could you please suggest some workaround until the fix of the issue will be published? According ot the first look i could be replacing “-sensitiveVariables=” to "-sensitiveVariables " (change the equal sign to space), but this should be checked.

Thank you.

Hi Octopus folks,
Were you guys able to reproduce/investigate this issue? Right now we’re modifying the generated scripts manually each time we are doing deployments. Since we’ve actively dev’ing them we’re doing that quite often.


Thanks for reaching out. I wasn’t able to reproduce this error when running a simple deployment with sensitive variables. I’m gonna pass this ticket to our Dev team so they can take a look at it during their daytime (they are located in Australia). We’ll update this ticket as soon as we find something.




Dalmiro, thank you for the response.

I checked offline script on the Win 10 with PowerShell v5 - the parcing is correct.

It looks like the issue is actual for powershell v2, not v5. (v3 and v4 were not checked).

Igor - Thanks for that update! That narrows down the troubleshooting a lot :slight_smile:

We’ll update this ticket as soon as we have something.


Has there been any updates on this?

I am getting the same error when trying to run an offline deployment just now. The server has PowerShell 2 installed.

NOTE: This was using Octopus 3.1.2.



Ok, looks like I might have found the issue…

If you look at the attached screenshot, you will see that the resulting $PasswordArg variable does not contain the trailing ".

This was done by simply executing the commands that are being used as part of the deployment script.

Hope this helps!


Digging into this a little further, there looks like there are a couple other things not quite right as well…

In the *.ps1 file, there is a section, similar to this:


The = after the parameter name is not required. It should simply be a space. After correcting this, I was able to get the *.ps1 to run correctly, however, then it immediately fails with the error:

Unable to parse sensitive-variables as valid JSON

Can you please provide some assistance on how to move forward with this.

In a previous deployment, using Octopus 3.0.x, I didn’t have these issues.



I have just upgraded Octopus to 3.1.4, hoping that this might help, but I am getting the same problem :frowning:


How can I tell what version of Calamari is contained within the deployment package? How does File Version 510.0.0.0 map to the Octopus Version number?

The reason that I ask is that I have just debugged the source code for Calamari from here:

And the decrypting of my sensitive file worked exactly as I expected it would, so not sure why the packaged Calamari that was created as part of my deployment isn’t working.

Any ideas?


I am happy to say that I have now been able to get a successful deployment, using the packaged deployment from Octopus 3.1.4. I have attached a redacted deployment ps1 file of the original generated one, and the modified version that works. The only thing that had to be removed was the = sign on each of the calls to calamari.exe.

However, I am slightly confused as to what is going on here, as I didn’t have to remove the = from the line which is setting the $PasswordArg variable, and also, as it currently stands, the $PasswordArg variable contains -sensitiveVariablesPassword="Password NOTE the lack of " at the end.

In all honesty, I have no idea how/why this is actually working, but at least it is. Can we get this included in a new release of Octopus so that I don’t have to manually edit the files before doing the deployment?


Redacted.Deployments-287.ps1.modified (2 KB)

Redacted.Deployments-287.ps1.original (2 KB)


I’ve created a github issue so our devs can check this out https://github.com/OctopusDeploy/Issues/issues/2065

Thanks for all the info provided. I’m sure It’ll come in handy.


I had exactly the same problem on a Windows 2008 R2 server with Powershell V2 - I corrected the scripts as described above (which was a great help = thanks!) and it solved my problem. I hope this issue gets resolved soon as it is not ideal to have to edit the script every time a new release is applied.

Hi guys,
A fix for this should go out in the next release 3.2.2 in the coming few days. Looks like this was a niche environmental case that we just weren’t testing for.
There were a few security updates in 3.1 to ensure that sensitive variables were more securely encrypted which is why this problem didn’t exist in 3.0.
Keep an eye out for the new release and give us a yell if you notice any other problems pop up.

That is great news, thank you Robert. Is there somewhere I can subscribe to notifications about new releases? Thanks!

Great :slight_smile:

Thank you for a good news, Robert!

Hi Igor,
We provide information about minor release updates regularly in our blog which you can subscribe to via our RSS Feed. As for the incremental builds, your Octopus Deploy server should itself be aware of available updates and there should be a small bullhorn icon in the top right hand corner of the menu that lets you know of new builds as soon they are released. These releases are built such that you can just install over the top of the old one and get going with your deployments.
Let us know if you encounter any problems with the upgrade process and we’d be more than happy to help.

Hello Robert,

Yes, I have seen the bullhorn icon within the Octopus Deploy dashboard, however, since our deployments are automated from TeamCity, I am not in that dashboard as much as I am in the TeamCity build status page. Is there nowhere else to get notifications about patch releases of Octopus?


For more up-to-date information there’s probably not much better place than the download or release page itself. :slight_smile:

Ok, thanks for getting back to me. I would have liked to have seen this available somewhere that I wouldn’t have to manually check for it, but I can live with that. Thanks!