Changing pool name fails running the container about aspnet-docker HOT 20 CLOSED

@pan-wang Any idea what's going on here?

from aspnet-docker.

this is by design. We decided user should only use default apppool (default apppol should always exist). ServiceMonitor will update environment variable for default apppool. Renaming default apppool will cause appcmd failure. @MichaelLogutov is there any special reason that you want to rename/delete default apppool?

from aspnet-docker.

Mostly for consistency with our scripts. Not big deal - it's just stange that Service Monitor needed a "magic string" technique to work properly.

from aspnet-docker.

@pan-wang I am testing a website with sub-applications that are meant to run on separate app pools. I am getting the following error on run:

app_1 | ERROR ( message:Cannot find requested collection element. )
app_1 | Applied configuration changes to section "system.applicationHost/applicationPools" for "MACHINE/WEBROOT/APPHOST" at configuration commit path "MACHINE/WEBROOT/APPHOST"
Gracefully stopping...

Dockerfile looks like this:

FROM microsoft/aspnet:4.7
SHELL ["powershell"]
RUN Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters' -Name ServerPriorityTimeLimit -Value 0 -Type DWord
COPY ./web /sites/website
COPY ./app /sites/app
RUN Import-Module ServerManager; Add-WindowsFeature Web-Scripting-Tools; \
Import-Module WebAdministration; \
New-Item -Path "IIS:\AppPools" -Name "website" -Type AppPool -Force; \
Set-ItemProperty -Path "IIS:\AppPools\website" -name "managedRuntimeVersion" -value "v4.0" -Force; \
Set-ItemProperty -Path "IIS:\AppPools\website" -name "startMode" -value "AlwaysRunning" -Force; \
New-Item -Path "IIS:\AppPools" -Name "app" -Type AppPool -Force; \
Set-ItemProperty -Path "IIS:\AppPools\app" -name "managedRuntimeVersion" -value "v4.0" -Force; \
Set-ItemProperty -Path "IIS:\AppPools\app" -name "startMode" -value "AlwaysRunning" -Force; \
New-Website -Name 'website' -PhysicalPath 'C:\sites\website' -Port 80 -ApplicationPool website -Force; \
New-WebApplication -Name 'app' -Site 'website1' -PhysicalPath 'C:\sites\app -ApplicationPool app -Force; \
EXPOSE 80

Info:

Kernel Version: 10.0 15063 (15063.0.amd64fre.rs2_release.170317-1834) Operating System: Windows 10 Pro OSType: windows
Server Version: 17.09.0-ce

So, is this expected behavior as per your comment, "this is by design. We decided user should only use default apppool"??

By design, IIS allows multiple app pools. Why is there a decision here not to allow if this is indeed the case? Understood that these apps might all be separate services ideally. But these are legacy apps and this is a development env that I am trying to create.

Any suggestions on how I should proceed?

Thanks.

Justin

from aspnet-docker.

No. What I said is that the default behavior for IIS container image is that the image has a default website and default application pool. User can just map the application to the wwwroot folder and the default scenario will work automatically without configuring/changing docker file.
For advanced scenarios (e.g., multiple sites, different application pools, sub applications), they are fully supported. User needs to config IIS via docker file himself/herself.
For your case, something missed from your configuration. I did not see where the "website1" was defined. You may either create it (you need to set binding as apppool) or switch to use default web site.

from aspnet-docker.

@pan-wang thank you for clarifying. That makes a lot more sense now.

There was a typo in the sample dockerfile that I shared. I am fairly confident the actual one I am using is set-up properly to achive the desired set-up yet I continue to get the error:

ERROR ( message:Cannot find requested collection element. )

Is there a way to investigate the error message in further detail from within the container?

Here is the actual dockerfile I am using. if you care to give any feedback I would be grateful:

FROM microsoft/aspnet:4.7

ADD ./sites.tar.gz /

SHELL ["powershell"]

RUN Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters' -Name ServerPriorityTimeLimit -Value 0 -Type DWord

COPY ./web /sites/AreaDevelopment
COPY ./Admin /sites/Admin

RUN Import-Module ServerManager; Add-WindowsFeature Web-Scripting-Tools; \
Import-Module WebAdministration; \
New-Item -Path "IIS:\AppPools" -Name "AreaDevelopment" -Type AppPool -Force; \
Set-ItemProperty -Path "IIS:\AppPools\AreaDevelopment" -name "managedRuntimeVersion" -value "v4.0" -Force; \
Set-ItemProperty -Path "IIS:\AppPools\AreaDevelopment" -name "startMode" -value "AlwaysRunning" -Force; \
New-Item -Path "IIS:\AppPools" -Name "Admin" -Type AppPool -Force; \
Set-ItemProperty -Path "IIS:\AppPools\Admin" -name "managedRuntimeVersion" -value "v4.0" -Force; \
Set-ItemProperty -Path "IIS:\AppPools\Admin" -name "startMode" -value "AlwaysRunning" -Force; \
Remove-Website -Name 'Default Web Site'; \
New-Website -Name 'AreaDevelopment' -PhysicalPath 'C:\sites\AreaDevelopment' -Port 80 -ApplicationPool AreaDevelopment -Force; \
New-WebApplication -Name 'Admin' -Site 'AreaDevelopment' -PhysicalPath 'C:\sites\Admin' -ApplicationPool Admin -Force; \
Start-Website -Name 'AreaDevelopment';
EXPOSE 80

from aspnet-docker.

from aspnet-docker.

Thanks @pan-wang

The good news is that I discovered when running "docker-compose up" with "-d" flag the error output is suppressed and the container is initialized and reachable as expected. I suspect the container was always reachable but I was just being thrown off by the error output in non detached mode.

The bad news is that the error is still there so while it is not killing things it is certainly not desirable.

There is another issue I am having and it may be related to underlying cause of the error message so I will mention it. The asp.net website I have set up in the container cannot serve static content from its directory. I am banging my head against the wall on this and have tried setting full ACL privileges for NETWORK SERVICE, IUSR and IIS_IUSRS (confirmed successfully) for the directories associated with the website. It also appears that the right windows features are enabled by default out of the box (results of Get-WindowsFeature also attached). Have you heard of this happening?

applicationhosts.zip

from aspnet-docker.

ERROR ( message:Cannot find requested collection element. ) , This error message is an known issue and ignorable. It was generated when servicemonitor.exe tried to delete non-exist configuration element.

Not sure about "cannot serve static content from its directory". Could you please share more details about it and the error code/page from client?

@mcy94w could you please take a look it?

from aspnet-docker.

@justinshea
If would be very helpful if you can share your image with us through dockerhub.

from aspnet-docker.

@pan-wang @mcy94w
i'll look into sharing the image. I am new to docker and this my company's domain so it might take a minute to get approval and figure out how to do it :)

Meanwhile I am putting together further details about the static content server issues to share here.

At this point I would be surprised if it is an issue with the image. Seems more likely to be a configuration detail concerning ACLs, AppPool Identity, and anonymous authentication (even though I feel like I'm pretty far down the worm hole at this point.)

from aspnet-docker.

There are not too many details on response to client. When requesting a static file it is a simple text response:

The page cannot be displayed because an internal server error has occurred.

Header:
HTTP/1.1 500 Internal Server Error Content-Type: text/html Server: Microsoft-IIS/10.0 Date: Tue, 07 Nov 2017 00:09:37 GMT Content-Length: 75

In the IIS logs:

2017-11-06 23:23:50 172.26.59.53 GET /Front-end/styles/css/main.css - 80 - 172.26.48.1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/63.0.3239.30+Safari/537.36 http://172.26.59.53/ 500 19 183 31

There are a variety of reasons for this error:
https://support.microsoft.com/en-us/help/942055/-http-error-500-19-error-when-you-open-an-iis-7-0-webpage

Looks like the culprit could be a missing dll, ACL permissions or malformed config file.

I would be surprised if is a malformed web.config file on app level (attached) as dynamic requests are presently working and this is the same file used in other development environments successfully.

I have been pulling my hair out testing and configuring ACL rules and I have hit a wall. Based on available documentation - so far as I can tell because the documentation is convoluted - the ACL rules should not be the problem.

Based on this combination of settings the AppPool should automatically be added to the IIS_IUSRS group when created and started:

Get-ItemProperty IIS:\AppPools\AreaDevelopment | select -ExpandProperty processModel
identityType : ApplicationPoolIdentity
loadUserProfile : True
Get-ItemProperty IIS:\AppPools\AreaDevelopment | select -ExpandProperty processModel | select -ExpandProperty Attributes
Name: manualGroupMembership
Value: False

Here you can see the ACL rights properly assigned to one of the representative static files:

Get-Acl c:\sites\AreaDevelopment\Front-end\styles\css\main.css | Format-List
Access : BUILTIN\IIS_IUSRS Allow ReadAndExecute, Synchronize

(some details from command are removed above for brevity)

I am not sure how to find further error details other then the generated IIS logs. I tried trace.axd (enabled in web.config) and I got the same 500 error. There is no output in FailedReqLogFiles. Might there be other logs generated that could help elsewhere?

As you can see in the ApplicationHosts.config file I previously provided it would appear all modules and handlers for static serving are set-up properly. There should be no conflicts on app level web.config to negate that.

I appreciate your help troubleshooting this.

applicationhostsv2.zip

from aspnet-docker.

@pan-wang @mcy94w
What are your docker hub user names?

from aspnet-docker.

@justinshea you have to create you own dockerhub account and push the image. After you push the image, we can pull on our side.

from aspnet-docker.

@justinshea my account is mcy94w

from aspnet-docker.

Thanks. @mcy94w
I've added added you as a collaborator to justinmshea/areadev

from aspnet-docker.

Hi. My new theory is that this is a web.config issue. My app was recently converted from 3.5 manually. There may be some artifacts in the app level web.config that are causing the error? All other environments I have tested the 4. configuration in have had 3.5 enabled as well but this image does not (understandably). So, presently, I am looking into cleaning up the web.config 👍 or adding 3.5 to the image 👎 in hopes that will solve the issues. Any thoughts, ideas etc. would be humbly accepted and appreciated. I will keep circling back until I can prove it is or is not an actual issue.

from aspnet-docker.

Any feedback is appreciated. I've tried troubleshooting web.config file and numerous variations on ACLs with no success.

from aspnet-docker.

Hi @mcy94w
Still no success here. Have you been able to look at the image? I've been through hundreds of permutations at this point and I'm about ready to throw in the towel. I believe there is a problem when serving static files from a directory other then "c:/inetpub/wwwroot". Or perhaps, the problem is related to using new apppool profiles other then default. Bottom line, I do believe the problem extends past just configuration....

from aspnet-docker.

@mcy94w
Problem solved. this was not a aspnet:4.7 build issue but a clash with the applicationhost.config file as a result of migrating to a newer version of IIS then my previous environment. I wish IIS gave me more info other then 500.19 but I also should have identified the underlying issue a lot sooner and shouldn't have gummed up the works here...
Thanks

from aspnet-docker.