10

We have come across an issue on IIS 7.5 where we have a simple deploy system which consists of the following:

Create a zip-file of new webroot, consisting of three folders:

Api
Site
Manager

This is unzipped into a new folder (let's say we call it "SITE_REV1"), and contains a script which invokes the following (one for each webroot):

C:\Windows\system32\inetsrv\appcmd set vdir "www.site.com/" -physicalPath:"SITE_REV1\Site"

This usually work, in 9/10 times. In some cases, the webroot seems to be updated correctly (if I inspect basic settings in IIS Manager, the path looks correct), but the running site in question is actually pointed to the old location. The only way we have managed to "fix it", is by running an IIS-reset. It isn't enough to recycle the application pool in question.

Sometimes it seems to even necessary be to make a reboot, but I'm not 100% sure that is accurate (it hasn't always been myself that was fixing the problem).

I rewrote the script using Powershell and the Web-Administration module, hoping that there was a glitch in appcmd, but the same issue occurs.

Set-ItemProperty "IIS:\Sites\www.site.com" -Name physicalPath -Value "SITE_REV1\Site"

Has anyone experienced something like this? Do anyone have a clue on what's going on, and what I can try and do to prevent this issue? Doing an IIS reset is not really a good option for us, because that would affect all sites on the server every time we try and deploy changes on a single site.

EDIT: We have identified that a start/stop of the site (NOT the application pool) in IIS Manager resolves the errorneous physical path, but if I stop the site using appcmd, change physical path, and then start it, I still suffer from the same issues. I'm at a blank...

jishi
  • 858
  • 1
  • 11
  • 25
  • 1
    For those times when it doesn't work, is it possible that the requests were existing ones being served by the old app pool via [overlapping rotation](http://technet.microsoft.com/en-us/library/cc735206%28v=ws.10%29.aspx)? Not sure of the uptime requirements of your site, but you could try disabling overlapping rotation and including an app pool recycle command in your deployment script. – explunit Apr 04 '13 at 13:47
  • No, all subsequent requests is served from the old webroot, even an application recycle will reload the application from the old root. An IIS reset is the only way we have managed to restore it. It's like the applicationHost.config is updated (since IIS manager shows the correct path), but the IIS server itself works from the previous configuration... – jishi Apr 04 '13 at 13:49
  • I can not find a mention of it in applicationHost.config, so I assume it's the default "false"? – jishi Apr 04 '13 at 13:59
  • OK, was thinking if disallowOverlappingRotation = true, then old app pool might not be shutting down due to a long-running thread or something. Which is why IIS Reset would be required to fully clear it. Interesting question -- will be curious to see what answers show up. – explunit Apr 04 '13 at 14:01
  • Bear in mind an app pool recycle isn't the same as stop/start. Have you tried this method? Bear in mind, this will kill all current connections and make the site unavailable (error 500) until the app pool is restarted. – John Homer Apr 11 '13 at 14:35
  • Will give that a try, thanks for the suggestion. However, a manual recycle (opposed to a recycle based on file modifications) will spawn a new process (new pid), are you saying that even a manual recycle isn't the same as a stop/start? – jishi Apr 11 '13 at 14:37
  • I have to agree with explunit. The default value of disallowOverlappingRotation = false can be problematic for many web sites, and the resulting issues are not always obvious that this is the cause. It is equivalent to a 'web garden' (multiple worker processes). It is particularly bad if there is high resource usage, as it can temporarily double the amount of memory required. Overlapped Recycle is not necessary when there are multiple web servers hosting the site. – Greg Askew Apr 14 '13 at 13:56
  • Hi @jishi, Did you find any solutions to this? I am experiencing the same behaviour – Daniel Conde Marin Dec 11 '17 at 21:44
  • @Daniel Conde hi, this was a long time ago, but I think the conclusion was that restarting the site (not the app pool) made iis use the new web root correctly. I think in the end we ended up stopping the site, changing web root then starting it again programmatically for simplicity. The app pool then recycles automatically because of the identified change in source files (I think) – jishi Dec 13 '17 at 04:13

2 Answers2

0

Does changing the physical path from IIS Manager work correctly and immediately?

You might want to try the following command. Differently syntax, should have the same result but maybe it works slightly different internally causing IIS to pick up the changes (better):

C:\Windows\System32\inetsrv\appcmd.exe set app "www.site.com/" -[path='/'].physicalPath:"SITE_REV1\Site"

Marco Miltenburg
  • 1,121
  • 8
  • 9
  • AFAIK we have never had any problem when we change it manually in IIS manager, only programatically. – jishi Apr 14 '13 at 10:31
0

An app pool recycle should be sufficient per site basis. These are independent processes. Too often articles and processes promote using iisreset. Is stopping / starting the app pool for the one site an option? Is this a single server solution and are you trying to minimze downtime for the site? There is an option to Disable recycling on configuration changes. Then you can manually recycle. When the problem happens, what is listed in the applicationHost.config?

Steve Schofield
  • 429
  • 2
  • 4
  • I'm not 100% sure, but since IIS Manager list the new path, I assume that applicationHost.config is up to date. However, when the process recycles, it doesn't seem to use the newly configured values. Since this only happens occasionally it's hard to troubleshoot it in a timely manner. – jishi Apr 14 '13 at 10:30