to have tight control over what the service can do vs the local system account which is tantamount to having full local administrator rights.

to connect to SQL Server using Windows Authentication and.The previous installation of Octopus Deploy used a local Windows system account, but for the new installation, we want to use a domain account This three server set-up does not truly represent a real-world environment (for example, the SQL Server would not normally reside on the domain controller), but is enough to emulate the core elements of the environment that I will be using in the real world. A Windows 2012 server that will be a target server for deploying web sites to via an Octopus Deploy Tentacle.A Windows 2016 server that doubles up as the TeamCity and Octopus Deploy server.A Windows 2016 server that is the Active Directory Domain Controller and hosts a SQL Server 2017 database server.In my test lab I have the following set up as Hyper-V virtual machines: This makes taking snapshots/checkpoints to rollback to if things go wrong during installation a bit more complicated. It also means that we effectively only get one shot at getting things right.įor these reasons, I created a small test lab at home to practice all the steps required so that I could create an installation step-by-step ‘run-book’ to do the real installation with as few hiccups as possible.

The (virtual) server we will be installing on is hosted in a managed environment (with no self-service facilities). The upgrade path from these (very old) versions to the latest versions is complicated and therefore we have set up a new server to host the latest versions. I am currently working with a team that has old versions of TeamCity and Octopus Deploy and want to move to the latest versions. This post is primarily for my future self to document how to deal with the problems I had installing Octopus Deploy using a domain account as the service account.

Ocropus windows installer