[I'm posting this to record what I actually found out after hours of painful trial-and-error.]
I have a website that I need to be "always running" (because in this case it has a Hangfire job that's responsible for kicking off a scheduled task every 5 minutes), and by default, websites are only started up when the first request is received.
So, how can I ensure that the website is started automatically? And, how can I configure this via the TFS release management tool?
[This answer isn't specific to Hangfire, but see the Hangfire documentation's discussion of this issue for details of how it affects Hangfire, but note that the recommended work-around is somewhat involved, and much more complex than the solution below. See also a separate and quite comprehensive discussion on the Hangfire support forum that gives several alternative solutions.]
In IIS, each website is associated with an Application Pool (App Pool). You can configure your App Pool to start automatically via IIS Manager by changing the "Start Mode" to AlwaysRunning in "Advanced Settings" for the App Pool:
However, starting the App Pool doesn't start the website (or websites) associated with it. The website does not get loaded until the first request is received.
In IIS8 (or IIS7.5 with an extension), a new setting was added that allows us to work around this. You can ensure that the website gets sent a request as soon as the App Pool starts by setting "Preload Enabled" to True in "Advanced Settings" for the website:
The combination of these settings ensure that the website will automatically start up when IIS starts, and immediately after the App Pool is recycled, etc.
But, how can you get those settings applied automatically as part of a TFS release pipeline, rather than having to remember to set them manually?
In your release definition, you presumably have an "IIS Web App Management" task, which sets up the App Pool and the website. In the configuration panel for this step, there should be an "Advanced" box with an "Additional AppCmd.exe Commands" entry field. You can use AppCmd to apply the settings described above.
AppCmd has the most confusing command-line syntax I've yet seen outside of code-golf competitions, but here's the incantation that worked for me:
set config /section:applicationPools -[name='myAppPoolName'].startMode:AlwaysRunning
set app "mySiteName/" /preloadEnabled:true
Note that if you have configuration variables defined for your App Pool name and website name, then you can use those rather than hard-coding the name, such as:
set config /section:applicationPools -[name='$(appPoolName)'].startMode:AlwaysRunning
I hope this helps somebody... Thanks for listening :-)
Related
An extension called AppStateTracker is causing issues on my Azure web app, what extension is this?
what is it, and why are we only seeing it on one services. What differs that service from the rest of our services. I see it in the Activity Log when I check the JSON for the "Update website extensions"
AppStateTracker is an update which enables config level tracking for your web app from Application Change Analysis blade and simply collects data from the environment. So frequent changes to your application will create frequent updates but will have no adverse effects on your application.
AppStateTracker is a dormant extension, it gets activated when Azure makes PUT calls to the application. It would wake up your process if its not always on, however in terms of actual impact on the application - there is nothing invasive that can affect anything. It only scans environment variables and settings and never attaches or does anything with running process nor modify anything. It is part of Change Analysis which is a completely independent product.
If you want to see less of these updates, you can choose to disable file and configuration change tracking on web app following the instructions below:
https://learn.microsoft.com/en-us/azure/azure-monitor/app/change-analysis#application-change-analysis-in-the-diagnose-and-solve-problems-tool.
I 've found out that Azure websites (trial version) doesn't autostart my node sever process (it starts only when I load the url in the web browser); and that when there are no requests in a while, the process is killed.
I mean, when I git push my server, I would like it to start running immediately and continuously.
I read (here, for example) that this might have to do with the way iisnode manages azure websites, and that I can't do anything to change it. Is this the actual way Azure websites work? Is there any way I can deal with this?
Thanks in advance,
Bruno.
You've find the answer. There is no other answer.
The process termination because of inactivity comes from IIS - there is Idle Timeout setting. Which to my knowledge is not configurable in Azure Web Sites (at least not Free tier). Check out also this SO question and its answer to get better understanding on why you can't change this timeout on the FREE and STANDARD tiers.
And here is an interesting workaround to avoid this idle timeout. Actually if you use technique, you will also have kind-of "auto start", in terms that when your scheduler hits your site after a new deployment, it will "boot up".
This can get a little complicated, but if you don't want to use their 5-min ping service, you can keep these always on by doing the following:
Create an app setting on your website configuration tab within the portal:
WEBSITE_PRIVATE_EXTENSIONS and give it a value of 1
Create a text file named applicationhost.xdt and populate it with:
<?xml version="1.0"?><configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"><system.applicationHost><applicationPools><add name="DefaultAppPool" managedRuntimeVersion="v4.5" startMode="AlwaysRunning"><processModel identityType="ApplicationPoolIdentity" /></add></applicationPools></system.applicationHost></configuration>
ftp into your website and create a folder on the root directory called Site Extensions. (there should now be 3 folders in your root: LogFiles, site, & SiteExtensions)
Create another folder within 'Site Extensions', named ASPLimits
Upload the applicationhost.xdt into the ASPLimits folder
Restart your website using the portal
I noticed that when you RDP to a Web Role instance on Windows Azure to make an iisreset, the World Wide Web Publishing Service shuts down, and the only way to get your role up and running again is either by restarting the aforementioned service or re-roll/restart your instance.
For reasons unknown to me, Windows Azure default the start mode of World Wide Web Publishing Service to Manual, why an iisreset sort a leave your Web Role unavailable to the WWW.
I found a solution to this - IMO - odd behavior, and answered it to the original question of this post.
However, is there an alternative to iisreset on Windows Azure - maybe programmatically where I can pinpoint the exact instance? Because that is another issue; now I have to use RDP to each instance .. it would be nice if it was possible to do a pinpoint each instance.
Think about it; i have a CNAME to www.awesome-azure.com; this is hosted by 3 instances in round-robin, and I want to reset/monitor/diagnose/heartbeat each one through a REST API (ir similiar), and not like now - through RDP.
Can this be achieved.
EDIT
Tried to make it more clear what the challenge is as well as the goal to achieve.
EDIT 2
Provided a solution to the iisreset challenge; updated the question to pinpoint instances over the Internet if possible.
Well, I still don't know why Microsoft Azure decides to set World Wide Web Publishing Service to start mode Manual, but I found a way to change it.
To the second part of the original question I still hoping for an answer, but until then, please find my solution for the first part to fix the (IMO) iisreset problem with Startup Task:
In your startup.cmd (or what ever you have named it) which I have placed in a startup folder in the root of my application, include this line of text:
powershell -ExecutionPolicy Unrestricted .\startup\w3svc.ps1
In the same folder, create a PowerShell file named w3svc.ps1 with the following content:
Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\W3SVC -Name Start -Value 2
Voila; your IIS now works as expected - World Wide Web Publishing Service is now set to start mode Automatically.
Note: for the above to work, you need to have your osFamily property set to 2 in you ServiceConfiguration.cscfg file.
You can handle the RoleEnvironment.Changing event in WebRole.cs and set the Cancel property on the event arguments object to true. Then you just need to make a change to the configuration settings and Azure will restart all your instances in an orderly fashion.
I don't know why iisreset isn't working. As to your second question, you can use the Service Management API to reboot or reimage an instance. That might do what you want. You could also, of course, write your own code to do whatever you want. (You could have code in your web role that polls a blob called <instance ID>.txt and does an iisreset any time the blob changes.)
I am trying to deploy a PHP application to azure web cgi role. I set my web.config and web.roleconfig correctly, I believe. Since when I remote to the machine, I set the fast cgi handler in IIS manually to the same value. It works. However, it doesn't work after the package is deployed, even if the value is the same! I have to manually reset it to the same value! Sounds weird?
So I am thinking to write a piece of code in role start event to reset the mapping. Does anybody knows how to do it in C#?
Thanks
KAO!
Setting up the handler mapping has two phases:
1. setup web.config
2. create application
I only did first one. By clicking the OK on the popup window on UI will set the second. So if I want to deploy to Azure on a side website (which mean the website is not linked with the web role), I have to do the second setup myself, by either manually or runing a command line: %windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI /+[fullPath='XXXX\php-cgi.exe']
So I figured out that by adding the ResetWebServer="FALSE" attribute to the solution manifest prevents SharePoint from recycling any app pools.
However, when upgrading a solution that originally did not specify ResetWebServer="FALSE" or when retracting a solution that does specify ResetWebServer="FALSE", the application pools are still being recycled. Is there a way to prevent any auto-recycling of app pools?
This does not seem possible given the document on MSDN (see below), note that I included Deploying a Solution over Upgrading a solution as underneath it is effectively doing a file replacement. I believe the restart/recycling is necessary as a result of how IIS functions. An option to explore if you wanted to manage when this occurs is to ensure that all deployments are done via timer jobs and execute when their impact will be minimized.
Deploying a solution
Initially, manifest and feature manifests are parsed to find assembly and _layouts files, which are copied to the appropriate locations. All other files contained within a feature directory are copied to the feature directory. After solution files are copied to the target computers, a configuration reset is scheduled for all front-end Web servers; the reset then deploys the files and restarts Microsoft Internet Information Services (IIS).
Retracting a solution
On each front-end Web server, the following occurs:
Microsoft Internet Information Services (IIS) is disabled.
Files are removed from the system.
IIS is re-enabled and Windows SharePoint Services is reloaded when
a user browses to a page.
You might also take a look at the "-local" switch. Didn't try it yet but it seemed that it allowed deployment server per server when you are in a load balanced situation.
Might be a good lead.