Unable to configure Server 2020.1.10

reliability
support
unknown
(Hlogsdon) #1

I’m trying to setup an instance of self-hosted Octopus to be used by my development team to become familiar with it’s use. I’ve followed the deployment instructions starting at https://octopus.com/docs/installation . I’m installing it on a Windows 2012 R2 server.

Initial installation was uneventful, but upon running Octopus.Manager.Server.exe and entering all the configuration information, I end up getting a generic .NET Core startup error as the manager app attempts to run the configuration script.

Error: A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'C:\Program Files\dotnet'.
Error: The previous command returned a non-zero exit code of: -2147450749
Error: The command that failed was: "C:\Program Files\Octopus Deploy\Octopus\Octopus.Server.exe" create-instance --instance "OctopusServer" --config "D:\Octopus\OctopusServer.config" --serverNodeName "MYSERVERNAME"
Error: A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'C:\Program Files\dotnet'.
Error: The previous command returned a non-zero exit code of: -2147450749
Error: The command that failed was: "C:\Program Files\Octopus Deploy\Octopus\Octopus.Server.exe" delete-instance --instance "OctopusServer"

As a developer, I’ve run into this issue before when compiling and running my applications, and my notes state that I’ve had to add some configuration to my deployment and recompile/republish my binaries. This is not something I’m able to do with Octopus, for obvious reasons. Additionally, nearly every search result in researching this issue also talk about the issue from the development point of view, not the end-user.

I’ve attempted to manually configure the server by running the configuration “script” via the Command Prompt and PowerShell which both result in the same error. When attempting to run Octopus.Server.exe via the dotnet command executable results in a nearly identical error:

PS C:\Program Files\Octopus Deploy\Octopus> dotnet exec .\Octopus.Server.exe create-instance --instance "OctopusServer" --config "D:\Octopus\OctopusServer.config" --serverNodeName "MYSERVERNAME"
A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'C:\Program Files\Octopus Deploy\Octopus\'.
Failed to run as a self-contained app. If this should be a framework-dependent app, specify the appropriate framework in C:\Program Files\Octopus Deploy\Octopus\Octopus.Server.runtimeconfig.json.

This second error is even more confounding as the Octopus.Server.runtimeconfig.json file exists in that location and the two framework entries there do in fact exist as installed runtimes in C:\Program Files\dotnet despite the installation instructions stating that the app should run as a self-contained app.

Does anyone know what’s going on here?

(Dane Falvo) #3

Hi Hlogsdon,

I’m sorry you’ve run into this issue and my apologies for the delay in getting back to you.

You’re right, it definitely seems like an issue that might be seen in a development environment as opposed to an error you would see during a standard installation. To answer your question directly, I’m not entirely sure what’s going on, but I’m ready to work with you to help get to the bottom of this.

I’ve recreated the environment here, and I’ve managed to reproduce this error:
dotnet : A fatal error was encountered. The library ‘hostpolicy.dll’ required to execute the application was not found in ‘C:\Program Files\dotnet\shared\Microsoft.NETCore.App\3.1.3’.

I achieved this by simply renaming the hostpolicy.dll file. This leads me to believe there is a dotnet installation issue that needs to be rectified.

So let’s start off by gathering some details.

Can you please run the following commands for me and please send me back the results?

  • dotnet --info *
  • dotnet --list-sdks *
  • dotnet --list-runtimes *

If you are running into errors, with any of the above commands - It’s a good sign you may need to reinstall or repair your dotnet installation as the first objective. If you decide to try re-installation, unless necessary to deviate, I would always recommend keeping the same architecture type (x64 / x86) across your dotnet installations, Octopus Deploy and System.

Looking forward to hearing back from you so we can keep diving into this a bit more.

Dane

(Trey Thomas) #4

@dane.falvo

I am also running into this exact issue on Windows Server 2016.

I previously had 2019.13.7, and was upgrading to 2020.1.17.

At first, when Octopus Manager tried to run for the first time after the installation was complete, I got the larger error that @hlogsdon posted first.

I then downloaded and installed .NET Core, and now only get the message below:

Error: A fatal error was encountered. The library ‘hostpolicy.dll’ required to execute the application was not found in ‘C:\Program Files\dotnet’.
Error: The previous command returned a non-zero exit code of: -2147450749
Error: The command that failed was: “C:\Program Files\Octopus Deploy\Octopus\Octopus.Server.exe” service --instance “OctopusServer” --start

After reading the requirements page, you all are bundling .NET core with Octopus, so nothing should be required to be installed, right?

This file is on my system, located at:
C:\Program Files\dotnet\shared\Microsoft.NETCore.App\3.1.4

Below is my output from what you asked from @hlogsdon

PS C:\Users\Administrator> dotnet --info *
.NET Core SDK (reflecting any global.json):
Version: 3.1.300
Commit: b2475c1295

Runtime Environment:
OS Name: Windows
OS Version: 10.0.14393
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\3.1.300\

Host (useful for support):
Version: 3.1.4
Commit: 0c2e69caa6

.NET Core SDKs installed:
3.1.300 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download

PS C:\Users\Administrator> dotnet --list-sdks *
3.1.300 [C:\Program Files\dotnet\sdk]

PS C:\Users\Administrator> dotnet --list-runtimes *
Microsoft.AspNetCore.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

(Dane Falvo) #6

Hi Trey,

Thanks for reaching out. I have attempted to reproduce this issue a number of ways with no luck. I am still investigating possible permissions issues as the culprit but have no solid leads as yet. I have a couple of theories that I will keep investigating.

We have managed to replicate the hostpolicy error by changing the permissions on certain folders and on the file itself. This is the basis for some of my theories.

Can I ask a couple of questions regarding your installation.

  1. Does the hostpolicy.dll files exist within “C:\Program Files\Octopus Deploy\Octopus”?

  2. When configuring the 2020 upgrade via Octopus Manager did you install the instance to run as Local System Account or a Custom Domain Account?

  3. What permissions does that account (the local system account or the Custom Domain Account) have on the folder “C:\Program Files\dotnet”?

  4. What permissions does that account have on the folder “C:\Program Files\Octopus Deploy\Octopus”

I’ll raise this ticket during our team triage early next week to get some more opinions, but if you can get back to me with the answers to the above questions, that would be great!

Thank you,

Kind Regards,

Dane.

(Trey Thomas) #7

@dane.falvo,

I had removed 2020 and went back to 2019.13.7 as I was needing to get something going.

I had sometime today to try this again.

So with 2019.13.7 already installed, and the service stopped, I ran the following installer:
Octopus.2020.1.17-x64.msi

I’m not sure about hostpolicy.dll and if it was there before on the first try. I’m thinking I didn’t search the entire C:, as the error message had a link to download the .NET. So I downloaded and installed it, and then checked for that file in the C:\Program Files\dotnet folder. I don’t think I ever checked C:\Program Files\Octopus.

To answer the following questions:

  1. I’m unsure on the first try, but on this second try, yes, the hostpolicy.dll file is there in C:\Program Files\Octopus Deploy\Octopus. When looking at the Details of this file, it has a file date of 2/28/2020 8:06PM sitting at 577KB. File Version 3.100.320.12801
  2. Local System Account. This is a Windows 2016 VM running in a non-domain/Active Directory setup. Just a standalone Windows Server installation.
  3. Logged into the host, and installed with Administrator. Administrator has Full Access on C:\Program Files\dotnet
  4. Same as #3

Also, this time the installation was successful :smiley:.

I thought possibly the issue was the version of SQL server being ran, which is SQL Server Express 13. From reading some other posts on here, I had a feeling it might work just fine, you guys just weren’t testing against older builds of SQL server, so therefore no more support. Is that a correct assumption?

This Octopus installation has been around since Octopus 3.15.x, so 2017. And has been upgraded from 3.x to 4.x, to 2018.x, to 2019.x, and now 2020.x.

I have logs going back to last week if you’d like to see them. I looked through them, but couldn’t see much when it came to upgrade tasks.

-Trey

(Dane Falvo) #8

Trey,

That’s great news that it’s all back up and running.

We do have a lot of integrations to test against and although we may have tested against SQL Server Express 13 at some point, it may have been on an absolutely clean install. When you put upgrades into the mix, there is almost an unlimited number of possibilities and an unlimited number of things that may go wrong over time. We do our best to minimise these but sometimes you get an odd case like yours.

Thank you for offering up your log files. At this point in time, these details are probably not necessary.

I am glad that you are back on track.

Happy deploying!