Unable to execute batch file after offline package deployment

knilsen · 26 November 2015 07:53

Hi,

We have setup deployment to an offline package drop for one of our environments. After the drop has been performed, and the files have been copied to the server, we have a step in the deployment process that runs the following Powershell script to execute the batch file for offline deployment:

$offlinePackageDrop = "<path_to_drop>"

$environment = $OctopusParameters['Octopus.Environment.Name']
$project = $OctopusParameters['Octopus.Project.Name']
$release = $OctopusParameters['Octopus.Release.Number']

$deploymentId = $OctopusParameters['Octopus.Deployment.Id']
$machineName = $OctopusParameters['Octopus.Machine.Name']

Write-Host "Path to batch file: $offlinePackageDrop\$environment\$project\$release\$machineName.$project.$deploymentId.cmd"
$deploymentScriptPath = "$offlinePackageDrop\$environment\$project\$release\$machineName.$project.$deploymentId.cmd"

Start-Process "cmd.exe" "/c $deploymentScriptPath"

However, the script does not seem to be executed and the only output I get when executing that step in the deployment process is:
Executing script on <server_name>
Appending run-script step to batch file

Do you have any idea what might cause this? Appreciate any help and input I can get.

Thank you and best regards,
/K

Michael_Noonan · 27 November 2015 07:12

Hi!

Thanks for getting in touch. Script Steps should run during the deployment of an Offline Drop Package just like they do when you’re using normal targets, like Machines. The only things that don’t work as normal are:

You can’t pass Output Variables from one step to another - that is coordinated by the Octopus Server usually
You can’t publish Artifacts - again, requires access to the Octopus Server

I would like to investigate this further, but what would really help is the raw deployment logs from your offline drop deployment, and any other details you think are relevant, like Octopus Version, a screenshot of the Deployment Process including any scoping of steps/variables.

Hope that helps!
Mike

knilsen · 27 November 2015 07:37

Hi Mike,

Please find attached the raw deployment log, as well as screenshots of the deployment process and variables. We are running version 3.1.0 of the Octopus server.

My understanding was that when using an offline package drop we would have to explicitly execute the deployment when performing an offline package drop by running the batch file, which is being copied – see the bottom of the following page on your wiki: http://docs.octopusdeploy.com/display/OD/Offline+Package+Drop.

Is the assumption above incorrect? Should I have execute all the deployment steps as usual after the drop has been made?

Thanks,
/K

knilsen · 27 November 2015 07:42

Please also find attached the raw log from a previous deployment where I executed all the steps as usual. The variables used are the same as those attached previously, and the deployment process is the same, except for the step “Execute Offline Deployment”, which did not exist. Also, steps 4 through 9 would have been run for S-test as well.

Thanks,
/K

knilsen · 27 November 2015 12:42

Some more info regarding the offline deployment target:

Applications directory: C:\Octopus\Applications
Octopus working directory: C:\Octopus

The contents of the .nupkg file is never deployed/extracted to the applications directory.

knilsen · 27 November 2015 12:56

Re-uploaded the raw log from a previous deployment where I executed all the steps as usual (see comment made on Nov 27, 2015 @ 08:42 AM).

ServerTasks-2141.log.txt (6 KB)

Michael_Noonan · 1 December 2015 01:36

Hi!

Thanks for sending that through. I’ve tried to reproduce the behaviour you’re seeing but my offline deployment worked as I expected and my custom scripts were executed. I’ve read over your scenario a couple more times, and I think I’ve misunderstood, and my response was probably misleading.

When you deploy to an Offline Package Drop target, Octopus will bundle up everything you need to manually execute the deployment on the target server - and that’s where Octopus stops. You need to take the folder that Octopus produces, and then manually execute the batch file on the target machine.

This feature was built to suit situations where Tentacle cannot be used to execute deployments, but instead a person needs to RDP in to the server and execute the deployment, perhaps from a USB drive, or a file share location.

Does that sound about right?
Mike

knilsen · 1 December 2015 07:10

Hi Mike,

Now we are on the same page . I might have been a bit unclear in trying to describe my problem, though.

Then I have one final question: With regards to “You need to take the folder that Octopus produces, and then manually execute the batch file on the target machine.”; Would it not be possible to perform this as a scripted step in the deployment process, i.e. add a step to run a Powershell script that executes the batch file? Of course, this requires the user we run the Octopus service as to have access to a file share on the target machine, as well as any other directories that the deployment might be using, correct?

Thanks,
/K

Michael_Noonan · 1 December 2015 07:25

Hi!

From what you’re describing it seems like you’re using the Offline Package Drop target when you don’t need to. Could you describe what your deployment actually does on the target machine? Perhaps there’s another way to achieve what you want.

Typically deploying an application with Octopus doesn’t just deploy files onto the target machine’s disk, but also modifies registry, creates web sites in IIS, or installs windows services etc - all of which are difficult to do remotely. That’s why we built Tentacle in the first place, so you could have a secure/trusted agent running on the target machine for Octopus to delegate all this kind of work to, without the need to set up PowerShell remoting or another remoting technology.

Offline Package Drops were created to help customers where there is absolutely no way to get a Tentacle installed on the target machine - think about an ISV using Octopus for lots of customers, but need a way to deal with Government customers who won’t install Tentacle, or cannot allow external network access. In this case the ISV can provide installation media to the Government customers which they can manually install on their target machines.

Hope that helps!
Mike

knilsen · 2 December 2015 07:56

Hi,

That might be. Thank you for explaining the usage of the offline package drops.
With regards to what our deployment actually does on the target; here are the steps that are being performed:

  Extract the content of the NuGet package to a given directory

```
  Perform a Web.config transform
```

  Uninstall the previous version of our application on the target machine using a Powershell script, which calls “msiexec” with some uninstall parameters

  Install the new version of our application, which is a part of the NuGet package in step 1. This is also done by using a Powershell script , which calls “msiexec” with some installation parameters

  Copy the transformed Web.config file to the application installation directory

Our deployment server resides in a network A and our system test environment target reside in a network B. When the team deployed the application manually, they would do the following:

  Establish a VPN connection from a given machine in network A to the target machine in network B

  Copy all necessary files from a given machine in network A to a file share on the target machine

  Manually perform all the deployment steps described above on the target machine

I do not think that we could install a Tentacle on the target machine and set it to listening mode. The reason is that it would require opening a port on the target machine for communicating with the Octopus server (or any other machine in network A for that matter). If we were to accomplish that we would need to get approval for opening up for communication on a given port through one or more firewalls, and unfortunately I doubt that we will get approval for that.

Am I correct in assuming that using an offline package drop for the scenario above is our only option?

Thanks,
/K

Michael_Noonan · 3 December 2015 02:41

Hi!

Thanks for the extra details.

Have you considered setting up a Polling Tentacle? This would enable machine(s) in Network B to poll the Octopus Server in Network A for deployment tasks. In this case Network B just needs to be able to make outbound requests to Network A, which might be easier for you to manage. (We generally recommend Listening Tentacles for performance reasons, but built Polling Tentacles to enable this kind of scenario where Listening simply isn’t possible).

A Polling Tentacle can do everything a Listening Tentacle can do, and would do all of the deployment process you described without any manual steps.

If you cannot use Tentacle on your target machines in any way, the only option remaining to you is to use Offline Drops. In this case I’d see the process as:

Deploy the Release to the Offline Drop target - preferably a common file share between all end-user machines
RDP to the end-user machine and execute the deployment from the common file share location manually.

I think fighting for Tentacles is worthwhile because your deployments can be automated completely. Just in case it helps, here is the documentation on the secure communication protocol between Tentacle and Octopus: http://docs.octopusdeploy.com/display/OD/Octopus+-+Tentacle+communication

Hope that helps!
Mike

knilsen · 4 December 2015 06:06

Hi,

We have looked into the possibility of using a polling tentacle as well, although it all boils down to the fact that – for now – no TCP requests are allowed to/from either network. Thus, for the time being I think we’ll have to use offline deployments as a temporary solution until we are able to convince our network guys that using tentacles for deployment is the way to go. I’ll keep on fighting ;-).

Thanks a lot for all your help and input, Mike!

/K

Michael_Noonan · 4 December 2015 06:08

Hi!

Best of luck heading towards tentacles. When it comes down to it, we also have a whitepaper from a security audit as the result of penetration testing - just in case it helps.

I’m glad I’ve been able to help you out to this point. Don’t hesitate to get in touch in the future about anything.

Happy Deployments!
Mike

knilsen · 4 December 2015 11:05

That could help. I would appreciate if you could send me the whitepaper, or point me to it.

Thank you and best regards,
/K

Michael_Noonan · 6 December 2015 23:15

Hi!

The whitepaper is in draft right now - I could send you a copy, otherwise you can get back in contact when you need it and hopefully we’ll have the final version.

Hope that helps!
Mike

knilsen · 7 December 2015 06:40

Hi Mike,

No worries. I’ll get back in touch when I need it.

Thanks,
/K