When creating an Octopus AWS Account (https://octopus.com/docs/infrastructure/deployment-targets/aws) you currently need to enter an AWS Access Key and Secret Key. This means the corresponding AWS Access Key needs to be periodically rotated, creating some management overhead and potential security vulnerabilities. Rather than an AWS Access Key and Secret Key, if we were able to enter an AWS IAM Role that is assumed whenever that Octopus AWS Account is used, then we would no longer need to manage AWS Access Keys.

In the background, Octopus Deploy would need to set it up so that the AWS IAM Role is assumed and temporary credentials (https://docs.aws.amazon.com/IAM/latest/UserGuide/idcredentialstemp_use-resources.html) are created whenever the corresponding Octopus AWS Account is used by a deploy process.

As for the credentials that are used to assume the AWS IAM Role, I would expect that the AWS service role for EC2 instances running the Octopus Deploy server / workers is used by default to assume the AWS IAM Role. And if Octopus is not running on EC2 instances, maybe as part of the creation of the Octopus AWS Account, when specifying the AWS IAM Role to assume, you could specify another Octopus AWS Account to use to assume that role. That way you could maintain a single AWS IAM User and Access Key, and then that user would be used to assume the AWS IAM Roles.

As an example, you could setup the Octopus Deploy server / workers EC2 role (or an IAM user) policy as follows:
Name: octopus-deploy-server
https://gist.github.com/burck1/5469acbff31b71fa69ef8d91c4426e50

Then when creating the AWS IAM Role that will be assumed as part of the deployment you would:
1. Setup the Trust Relationship as:
Name: octopus-deploy-my-project-deployer
https://gist.github.com/burck1/5469acbff31b71fa69ef8d91c4426e50
2. Setup the AWS IAM Role policy to have access to whatever AWS resources needed.

Note: This feature would also allow cross-account access as AWS IAM Roles can be assumed within other accounts.

It would be great if the Octopus dashboard, which displays the current releases of each application in each environment, contained links to the applications in the specific environments. E.g. if the box displaying details of the most recent deployment of Application X to Environment Y also contained a link to that app in that environment

We presently maintain this info outside of Octopus, in Wiki pages etc, but it’s a pain to maintain.
It would be great if this was directly available in Octopus, because the matrix of applications to environments is already there. Forcing users to access the links via Octopus would also have the advantage of making sure they know the version they are accessing too (we do display the version numbers in our apps also, but you know what I mean).

Was thinking if “Application URL” was a property of a deployment, and there was some means of setting that property as part of the deployment process steps (say via a step type), then the dashboard could check if the URL for deployments had been set, and if so display a link. Also has the benefit that if the URL needs to change with a given release, that can be controlled like other changes

I think a lot of customers would find this a useful feature… there is nothing special about our situation, maybe just that we have a lot of environments and a lot of apps, making the problem more important to solve

It would be useful if we could set variables in a variable set to a Project Group scope.

The use case for this is that we have a shared variable set that sets a product ID.

We could then scope this by product group.

eg

Variable Set Products
Product Id - ATeam Scoped to Project Group A
Product Id - BTeam Scoped to Project Group B

Project Group A
- Proj A1
- Proj A2

Project Group B
- Proj B1
- Proj B2

Currently we have to override the ProductID in every project in Project Group B which sometimes gets overlooked, scoping by Project Group would remove the need to do this.

OST file is one of the database files used by Microsoft Outlook. Its main purpose is to serve as an enabler for working offline even when the connection to Exchange is not live. In such scenarios, the changes you make are later synced to the Exchange Server when the connection is back live.

If there are any errors or corruption issues in the OST file, the information stored within it comes under risk. This is mainly due to the fact that OST files, unlike PST files, cannot be opened independently of the Outlook profile that created them.

So in all such scenarios, what we need is a tool that can Convert OST file to PST. The resultant PST file can then be easily imported into any version of Outlook and its contents viewed. To accomplish this, you will need an tool that can easily extract all the information from within your OST file including mails, calendar, tasks, journals, contacts etc and flawlessly convert it to Outlook PST file.

EdbMails OST to PST Converter tool with its simple to use user interface can accomplish this for you. Along with support for most versions of Exchange and Outlook, it also supports 64 bit windows operating systems. What’s more novel about the OST to PST tool is that it allows direct OST migration to Office 365 as well as Live Exchange Server.

EdbMails preserves the folder structure intact and also lets you view all the contents of the OST file within the application. There are extensive filtering options by date, subject, attachments etc that you can apply to the mails before export to PST file

Add variables to Runbooks, so that adding new variables to the project for a specific Runbook don't cause the snapshots of other Runbooks to be old.

For example, we have a Runbook that exports data from a database to a CSV and emails it. We have variables for the from and to dates and the email addresses to send to. The from/to dates are prompted variables, so you can do an adhoc run. If no dates are provided, it will default to the last week of data.

These variables only have meaning for this Runbook, so it would be nice to define them for the Runbook.

I find that the most common task performed on tenants is modification of tenant variables. However, I feel that the UI does not support this task very well.

I find that once I click through on the tenant, my next step is to click on the project in which I wish to set variables for which does not result in the expected action (it takes you to the project instead).

My recommendation is that the tenant variables becomes the landing page for tenants and the project administration for the tenant could become a secondary page (or perhaps it could even be combined into the variables page).

With standard octopus deployment there is a "deploy a release" step which can be used to run other projects from a parent project.

It would be usefult o have a similar "run a runbook" step to be able to build up run books from smaller steps into bigger processes.

Our use case is swithcing to DR, there are numerous steps such as stopping various services, starting other services, stopping replication etc. But, each of these steps is also useful in itself so we have steps effectively duplicated, once in the invoke dr runbook and once in a runbook all by their lonesome. But, the data and process is identical across them all.