Octopus Deploy Version: 3.2.13
Target Web Servers: Windows Server 2008 R2/IIS 7.5/.net 4.5.2 installed on it/WMI 4.0
PowerShell information below:
PSVersion 4.0
WSManStackVersion 3.0
SerializationVersion 1.1.0.1
CLRVersion 4.0.30319.42000
BuildVersion 6.3.9600.16406
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0}
PSRemotingProtocolVersion 2.2
I’m having an issue with a PowerShell script that we pulled from the community library which I have attached. We’re using this step template on other IIS Applications that we create on our servers without issue. This specific one we’re creating has a wcf service that is using the protocolMapping node in its web.config. This specific application is working locally on my windows 7 machine with IIS7.5. So the problem isn’t in my web.config.
I’ve checked our machine.config file for the 4.0 framework and it’s defined in that file. I do notice when the WebAdministration module identifies the version of the CLR it’s v2.0.50727. We just upgraded our servers Windows Management Framework to 4.0 hoping to address this issue. I’m not familiar enough with PowerShell and using the WebAdministration module for IIS to know what it’s doing under the hood before using Set-WebConfigurationProperty to set these values but it appears it wouldn’t be using the 4.0 machine.config file before setting the authentication settings.
Thanks for reaching out. What .NET CLR version is the App pool of your app running? could you double check that its running under 4.0 and not under 2.0? Send a screenshot if possible.
Yes you can see in my server tasks file that the step before the creation/update of the IIS Application is the creation/update of the IIS Application Pool in which I’m setting the pool to v4.0.
09:28:00 Info | GAC Version Location
09:28:00 Info | — ------- --------
09:28:00 Info | True v2.0.50727 C:\Windows\assembly\GAC_MSIL\Microsoft.Web.Administrat…
09:28:01 Info | Application Pool ‘MyTestApp’ already exists, reconfiguring.
09:28:01 Info | Setting: AutoStart = True
09:28:01 Info | Setting: Enable32BitAppOnWin64 = False
09:28:01 Info | Setting: IdentityType = 3
09:28:01 Info | Setting: UserName = UserAccount
09:28:01 Info | Setting: Password = [Omitted For Security]
09:28:01 Info | Setting: ManagedRuntimeVersion = v4.0
09:28:01 Info | Setting: ManagedPipelineMode = Integrated
I’m taking the issue over for Dalmiro. The issue is interesting as I think the error message may be misleading. I have a few questions which hopefully can help us isolate and resolve the issue.
Is this a new server? Do you have other apps/projects deployed to it using the same step template? Do you have other WCF services running on it?
Is it possible to manually deploy the service to the web server? I suspect the issue is an environmental issue with an Windows Server/IIS dependency rather than an issue with your web.config or the powershell script. If you manually deploy it, this should help isolate the issue.
This is not a new server. I do have other projects using this step template but they are not a WCF service and they work. I do have other WCF services running on the web server without issue.
I have manually deployed the service to the server and it is working. The web.config is fine because it runs on my local IIS.
Thanks for the reply. I think that eliminates my initial suspicion if the service runs fine by deploying manually. I did some further investigation and I found the following answer on StackOverflow. It sounds very likely because the service runs fine but the powershell script is failing.
That’s what I thought originally when I saw the error. I then had our Systems Management people update the Windows Management Framework on the servers to 4.0 to up the PowerShell version to 4.0. I’ve verified the machine.config for 4.0 does have the protocolMapping node declared in it. The error is still occurring when running the step.
Do you think the issue is that the Microsoft.Web.Administration assembly being used is the one from the GAC and is v2.0.50727. Hence it using the machine.config from the .net 2.0 framework version?
Thanks for following up and I’m sorry for the delay. I’m a bit stumped on this issue but I’ve been investigating further.
I think you might be on to something with the version of the web administration DLL. Can you tell me what IIS Web management tools features are installed on the server? I’ve found some resources online indicating that the IIS Management Console, IIS Management Scripts and Tools and IIS Management Service features are required.
Do you have an example of the script being deploy successfully on another server? Not necessarily for this project. Just to compare the script output/DLL version. i.e. Does it have the same version?
Unfortunately, this is a difficult issue that will take some troubleshooting. Hopefully we’re not far off.
I verified with our Systems Management person that those are indeed all installed. This specific template works on another server but the difference is that web.config does not have the protocolMapping node in it. It does show the same Microsoft.Web.Administration assembly being used is the one from the GAC and is v2.0.50727.
Thanks for the reply. I’m sorry for the delay but I don’t have a concrete solution. I believe the core issue is the version mismatch of the web administration module/dll but the powershell version, CLR version etc are all correct so it doesn’t make sense. i.e. It’s executing as Powershell v4 and the .NET Framework v4 but it’s trying to use a .NET v2 module/dll.
Can you try running the step template powershell script, or a subset of it, to exercise the command failing on the server? I’d like to see if it will run independent of Octopus or if it still fails which would point to an environmental issue on the specific server.
I asked other members of our team about this issue and similar issues have been resolved by upgrading to Powershell 3 or greater (which you’ve already done) or installing .NET Framework 3.5.1. It might be worth trying to install .NET Framework 3.5.1 even though it shouldn’t matter.