Hey @Adam.Archibald,
If you can get them to temporarily disable it just so you can test that one deployment that would be beneficial. Mainly because we have had customers in the past whitelist Octopus folders but once they have temporarily disabled AV the deployment started working, which then highlighted a folder they needed to whitelist so disabling it is the only way to fully rule out AV in situations such as this. Though I do fully appreciate there are security implications to be considered when doing so.
Do you know how we can up the logging from verbose to see more detail
If you mean the deployment logs we do have a page in our documentation here which does go through changing the log levels for Octopus Server and tentacle but that does not include deployment logs so there is no way to change a deployment log from its current logging level of Verbose.
You could try setting the tentacle log to a higher log level and see what that outputs if anything but usually the tentacle log doesnt show deployment processes it just shows service and connection level outputs.
You could also try checking out the AV logs on that machine or in event viewer to see if there are any indications that AV is scanning a file from Octopus.
Do you know if we can adjust through config the Temp Directory to somewhere else (we have in the past seen issues with the C Users Directory of the service running
Unfortunately, the temp directory is dictated by the OS so Octopus has no control over where that lives, it will use the service account that Octopus is running under and use that temp directory to store temp files in before they are transferred to the Octopus Work directory.
We do have a document on the folders you need to whitelist in Octopus but that does use the default drives so you would need to change those as appropriate for your instance. So that may help but if you have on access scanning on it will still scan the .nupkg before it gets put in a work folder so that would need to be turned off anyway in favour of on demand scanning.
This does seem environmental on that one machine from the way you have described it so it is doubtful it is a network issue or a change in network such as a DC change. The fact your other tentacles are working (assuming they are on the same subnet with the same external security policies in place) does point me to that one specific machine.
Hopefully we can get this sorted for you but if you send over that whitelist page to your AV team and ensure all of those folders have been whitelisted and see if they can temporarily disable AV on that one machine that will officially rule out AV and we can focus on some other things.
In the meantime, what are the RAM and CPU usage of the machine like at the time of the deployment, are they near max capacity or do they look ok?
Kind Regards,
Clare
