We have a few applications installed within a single "Web App" on Azure. We've configured each one as an Application (Configure>Virtual Applications and Directories and checkbox checked).
I've noticed that whenever we update a dll in one of the applications all of them get restarted. Any way to prevent this from happening other than creating a separate "Web App" for each application?
We need all of these apps to live under a single domain but remain independent.
I think it is because I have the main site under "/" and other applications nested in it. This was done to map the site to the root.
We have it defined this way: Site - "/" - mapped to site\wwwroot Application - /account mapped to site\account Pretty much the way it is set in this article. The physical folders are adjacent and the virtual folders are nested so one would expect that they would not affect each other.
We could not find a way to work around this issue. Eventually, we've resorted to azure slot swapping which provides zero downtime: https://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/
Related
This post needs help from experienced iis administrators, but must be explained in details for EXTREME newbies.
What I am doing:
I have two computers, both running Windows 10. One is a desktop and one is a laptop.
iis is enabled on both computers. Each computer can access the iis web server from the other and pull up a page from the other - using the ip address.
There is no DNS or host files being used (this is by ip address only), nor do I want to use any sort of naming.
Both computers are running an identical website, and the website files are in a different directory than the default. The structure is like this:
C:\inetpub\ROOT\myWebsite\myIndex.html
web.config
Changes I've made - now a few problems.
On both computers I have deleted the DefaultAppPool and the default website that comes installed with iis. This has not stopped the website from completely working, so adding that back seems unlikely to fix my problem.
I have deleted my application pool and website from iis (never deleting the actual files from the file system) several times, and added it several times. Each time I do this, my site comes back, but with the same problem I am having.
I have deleted all of the default documents, and the only default document listed in iis is myIndex.html.
myIndex.html initially displays a graphic image (using the standard tag), and this image comes up. Sort of. See explanation below.
The problem I am having
Before I started this project, I had iis working on the desktop with the default site and app pool and simply added some of my own files with really simple text content and some pics. I had replaced the default iis splash image with my own image, and all that worked with no problem.
the image that comes up is a link to another page that has a list of links to other stuff in my website. It all works no problem there.
Now, with the setup I have now, on the desktop I was originally using (in the paragraph above) if I pull up my website locally, myIndex.html loads in the browser and my image comes up, and everything works fine.
The same is true on the laptop, when I access the site locally.
However, if I attempt to access the desktop site (using its ip address) from the laptop, it pulls up the old splash image from the default site I deleted.( I left those files there even though I deleted the site from within iis). All those files are in the default location C:\inetpub\wwwroot.
If I move those files to another directory, thus leaving C:\inetpub\wwwroot completely empty, then when I access the site on the desktop (via the ip address) from the laptop, my new site comes up without a problem.
While it seems I may have solved my problem by moving the file from the previous project, doing that does not teach me how iis is actually working, and why files from a website that no longer exists in iis are still being accessed from remote computers.
So, please teach me something about the internal workings of iis, and how it chooses to access the different application pools and websites.
Again, please word your answers for complete newbies, because I know a little but not enough to get real technical.
I have been reading posts on stackexchange.com and other sites; links to microsoft docs etc. That's not helping as those docs are expecting too much prerequisite knowledge, and speaking in terms that are not really explaining things in a way I can understand.
You have described several different problems. I will try to address each of them (contrary to S/O recommendations).
First, when you make changes, and they don't seem to show up, it is usually because of caching. IIS always wants to cache files/configs. So does your web browser. So, to force an accurate test, you need to dump your browser cache and cycle IIS (to make sure it drops its cache and loads new files and configs). Start there.
Second, IIS is designed for settings inheritance. Which means, each app and each folder will inherit settings and permissions from the parent, unless you override them. Overriding them can be done by files and/or IIS configs (application vs folder). The IIS configs are the stronger of the two.
Also, the IIS config for "default files" might have come into-play for your test. If you didn't set up MyIndex.html as the top-most default file, then IIS would look for other files first. In fact, if you don't have MyIndex.html in the list of default files, IIS would have to depend on your app to choose that as a default page (MVC routing, etc).
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
Till date, I was thinking that we always create/host web-site in IIS.
But I was going through powershell tutorial today which says it is different to create web-site and a web application.
This is the tutorial link (check different section on creating web site and application) -
http://learn.iis.net/page.aspx/433/powershell-snap-in-creating-web-sites-web-applications-virtual-directories-and-application-pools/
Can please guide what is the difference between the two.
Any example will be really helpful.
Thank you!
A web site in IIS is the top level under Sites. The default one that is normally automatically created for you when installing IIS is named "Default Web Site".
This is the "root" that runs on port 80.
Under that, you can create virtual directories, which is basically sub-levels under the root web site, or you can create separate web applications that lives as separate applications under the root level.
A web application must live under a web site.
It is possible to create other web sites that can either be set up to run on other ports (i.e. 81), or to be named with a different host name which enables multiple sites to run on same port number. If named with a different host name, this name must be registered in a DNS server somewere to point to the IP address for your server. A workaround is also to to add it as an entry in the hosts file on the client computer that should access it.
This is example on how it looks in IIS Manager:
I have a script I use when creating a website and AppPool in IIS 7+, .net4, Integrated pipeline and thought you might find it useful.
Use it as so:
CreateSite.ps1 [WebsiteName] [AppPoolName] [Port] [Path]
If you are reinstalling the site, you will need to Stop it first. That is done as so:
StopSite.ps1 [WebsiteName] [AppPoolName]
you can grab the scripts from my gist
Update I have added/extended the scripts and put them in their own Github repository
Here is my CreateWebsite PowerShell script: http://www.zerrouki.com/create-website/
In short, I have three servers in a web farm, one of which is configured as a State Server. Two of the servers (including the State Server) are correctly sharing session state, but the other server is holding it's own session still.
Here's what I've done:
I have modified the web.config.comments file on all three servers so that they have the same machineKey entry.
On the State Server, I have changed the AllowRemoteConnections registry entry to 1. I then set the ASP.Net State Service to start automatically and switched it on.
The web site is configured on all three servers and the root site shares the same Identifer in IIS. Each configuration is identical. The website itself is contained on a network share, so the same web.config file is used on all three servers. I changed the sessionState entry in the web.config to point to Web3.
So Web2 and Web3 are able to set/modify/destroy the same session, but Web1 is still running with it's own.
I'm at a loss here after hours of Googling, so any help is greatly appreciated.
This application is configured a few subdirectories into the root site. Is there a separate AppID at this level? If so, how can I find it?
Thanks,
Aaron
http://support.microsoft.com/kb/325056
To maintain session state across different Web servers in the Web farm, the application path of the Web site (for example, \LM\W3SVC\2) in the Microsoft Internet Information Services (IIS) metabase must be the same for all of the Web servers in the Web farm. The case also needs to be the same because the application path is case-sensitive.
On one Web server, the instance ID of the Web site where the ASP.NET application is hosted may be 2 (where the application path is \LM\W3SVC\2). On another Web server, the instance ID of the Web site may be 3 (where the application path is \LM\W3SVC\3). Therefore, the application paths between Web servers in the Web farm are different. For additional information about how to check the application path of the Web site, click the following article number to view the article in the Microsoft Knowledge Base:
240225 Description of Adsutil and MetaEdit Used to Modify the Metabase
This is not really answering your question, but in my experience the ASP.NET session state service is not something you should scale to more than one server. It doesn't perform very well (especially under load) and is difficult to configure. I found that a distributed cache such as memcached is much simpler and faster for this purpose.
Have a look at this project.
matthewk's answer actually turned out to be almost the correct one. Over a year later I've returned to this and found the answer. Though probably correct, I felt that if the answer above had been more specific I would have solved this!
I searched through the MetaBase.xml file (C:\WINDOWS\system32\inetsrv) for the web application. After a game of spot the difference I noticed that there was a slight difference in the following line:
<IIsWebVirtualDir Location ="/LM/W3SVC/103071637/root"
AccessFlags="AccessRead | AccessScript"
AppFriendlyName="Default Application"
AppIsolated="2"
AppRoot="/LM/W3SVC/103071637/Root"
...
Specifically, the AppRoot (not the Location) on Server 1 had a Proper-Case "Root" whereas Server's 2 and 3 had "ROOT" all in caps. I updated Server 1 to match and restarted IIS and it works a treat.
ie.
AppRoot="/LM/W3SVC/103071637/Root"
AppRoot="/LM/W3SVC/103071637/ROOT"
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.