2020.3.1 Moving server: Please enter a valid master key

We’re moving from one server to a newer one.

I’ve upgraded to 2020.3.1 (on an unrelated note, it either dropped some of my bindings or it’s forcing a redirect to the configured domain, instead of accepting connections on any domain as long as the port matched).

After that I’ve moved the database to a new SQL Server and then installed a fresh 2020.3.1 instance on a new Windows server. When I copy the master key straight from the Octopus Manager to the installer, I get the following error: “Please enter a valid master key for the existing database”.

I’ve triple-checked it by now. It’s valid.

Hi Govert,

Thank you for contacting Octopus Support. I’m sorry you are having trouble with this.

If you haven’t already you might try using the Export Data feature in Octopus Manager on the old server, create a “blank” instance of 2020.3.1 on the new server, then use Import Data from Octopus Manager.

If that doesn’t work or if that is no longer an option, you can try renaming your OctopusServer.config file (located in C:\Octopus by default) to OctopusServer.old or something, then try the installation again.

Let me know if you have any luck with either of those options. If not, we can dive deeper. :slight_smile:

Regards,
Donny

Hi Donny,

I’m not sure I explained the problem correctly, I haven’t finished the installer because I’m blocked at the Master Key entry, so the OctopusServer.config is not yet created.

I also don’t think I can use the Export Data feature because I need to retain everything and if I uncerstand correctly releases and deployments are not retained when using the Export Data feature?

Regards,
Govert

Hi Govert,

Thanks for getting back to me.

Quick question, did you upgrade your Octopus instance to 2020.3.1 prior to exporting the SQL db? If not, on the new server, you’ll need to install whatever version you were previously on, complete the setup, then upgrade to 2020.3.1.

Let me know what you think.

Regards,
Donny

I did perform the upgrade before transferring the db.
A record in the OctopusServerInstallationHistory table confirms so too.

Hi Govert,

Thanks for getting back to me. I was afraid you were going to say that.

I’m going to spin up a test environment and try to reproduce this issue in 2020.3.1. In the meantime, if you have the ability to go back, you could try upgrading to 2020.2.16 on the original server, complete the migration, then upgrade to 2020.3.1.

If you end up trying that route, let me know if you have any luck. Otherwise, I’ll check back in once I test.

Regards,
Donny

Hi Donny,

Thanks for the efforts. Due to some scheduling issues we won’t be able to attempt the migration again until in two weeks, if something else falls through maybe sooner.
So I think it’d be best to await your results first.

If I can help in any way in the meantime, please let me know. If you end up needing a copy of the database I may be able to provide that too.

Regards,
Govert

Hi Govert,

Thank you for getting back to me.

I appreciate the (potential) offer for a copy of the db. I’ll let you know if it looks like your db will be necessary to reproduce.

I’ll check back in once I’m done tinkering with the test environment.

Regards,
Donny

Hi Govert,

I appreciate your patience so far.

I was able to successfully replicate your issue. Unfortunately, I have not found a workaround yet. I’ll need to get with my engineering team and figure out next steps as this looks like a possible bug.

Once I hear back from them, I’ll let you know.

Regards,
Donny

Hi Donny,

Thank you for the update and the efforts thus far. I’m glad you were able to reproduce the issue on your end.

I’ll patiently await new updates. Best of luck!

Regards,
Govert

Hi Govert,

Thank you for getting back to me.

Our engineering team has identified this as a bug and are fast tracking a fix.

I’ll update you as I get more information. :slight_smile:

Regards,
Donny

Hi Govert,

I just wanted to update you that we have a github issue raised here for this bug if you want to monitor progress:

In the meantime, let me know if you have any questions.

Regards,
Donny

Hi Donny,

Thanks for the update, I will monitor the GitHub issue.

Regards,
Govert

1 Like

Hi Donny,

What is your estimated time to resolution? We’re kind of blocked from migrating at the moment so we’re currently paying for a server we aren’t using.

Best regards,
Govert

Hi Govert,

Thanks for reach out. I’m sorry that you are currently blocked.

It looks like the patch for this issue has been written and merged to master. Octopus Server 2020.3.3 should be released in the next few days with the patch applied.

Let me know if I can assist with anything else.

Regards,
Donny

Hi Donny,

That’s fantastic, thank you very much!

Regards,
Govert

1 Like

Hi Govert,

I wanted to share an update and provide you with an option that should unblock you.

Due to the holiday in Australia, it looks like we won’t see the final release of 2020.3.3 until (likely) next week. However, I was able to snag a release candidate that should unblock you.

I cannot stress this enough that this is NOT a final release. There could be minor issues and you absolutely need to backup your database prior to touching this release candidate. You may download the RC for 2020.3.3 here:
https://octopus-testing.s3.amazonaws.com/server/Octopus.2020.3.3-x64.msi

If it is possible, I would highly recommend continuing to wait until the official 2020.3.3 release. As I mentioned previously, it should be available next week. However, our releases must pass all of our testing first, which means getting pushed out if an issue crops up.

If you do choose to use this release candidate, please be sure to install the official release once it is available.

I look forward to hearing back from you.

Regards,
Donny

Hi Donny,

Thank you very much, I truly appreciate the extra effort.
I will discuss internally what our best course of action is but in principle I agree with you, I prefer to install a blessed, well-tested release. I’ll see if we can adjust our schedule to delay the migration.

Should we need to try the release candidate, do I need to update the server we’re migrating away from? Or can I only update the destination server?

Thanks again for keeping me informed and providing an alternative.

Regards,
Govert

Hi Govert,

Thank you for getting back to me.

I would normally say that you should be on the same version on both sides. But, in this case, you should be fine keeping 2020.3.2 on the old server as I don’t recall there being any major SQL db changes in 2020.3.3. If there is a conflict, the install will tell you and won’t continue, so you don’t have to worry about that.

In my opinion, it isn’t worth the risk installing a 2020.3.3 RC on your current Octopus Server. You would have to restore from a db back up and reinstall Octopus to go back to 2020.3.2 if the 2020.3.3 RC isn’t work as intended.

Let me know if you decide to give it a try on the new machine. Otherwise, I’ll keep my ear to the ground regarding an official release.

Regards,
Donny