I just needed to copy the Default Website Property settings everytime a new test server is to be set up. It is tedious to compare and do that manually everytime and there is a chance of mistakes.
I know we can use the Web Deployment Tool to sync websites between a local and remote IIS server. But all I need is copying the iis settings and not the websites in it.
If I use the Web Deployment Tool it copies even my website files which are on the Default Web Site (No Virtual Directory).
I see you've tagged your question with IIS5. I've used the metabase import export tool before with some success, although it is targetted for IIS6 so I don't know if it would work for you. Perhaps worth looking at though:
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/637e4ec0-d9ef-4115-935b-47087870e01a.mspx?mfr=true
Related
Specific to Web Apps hosted on Microsoft Azure, is there a way to prevent the mydomain.azurewebsites.net URL from being indexed by search engines? I'm planning to use a web app as a staging website, and don't want it to accidentally get indexed.
I know I could add a robots.txt file to the project with everything set to no-index, but I don't want to ever accidentally publish it to the production site (or alternatively, forget to publish it to the staging website).
Is there a setting in Azure that will prevent the ".azurewebsites.net" domain from being indexed? Or if the robots.txt file is the only way, how do you keep it organized so that the right robots.txt file is published to staging and production, using ASP.NET Core.
Another option is to enable Authentication against your Azure Active Directory from the Authentication/Authorization tab in your App Service's settings for development and staging environments.
This way users will be forced to login to access those apps.
Documentation: https://learn.microsoft.com/en-us/azure/app-service/app-service-authentication-overview
https://learn.microsoft.com/en-us/azure/app-service/app-service-mobile-how-to-configure-active-directory-authentication
You can publish robots.txt to your staging server once. This can be done via FTP or via your SCM site. Once you publish this file, web publish will not remove additional files on the server (including your robots.txt file) unless you select "Remove additional files at destination" in your web publish settings.
So the robots.txt file will hang around forever on your staging server unless you remove it. Then you do not need to include robots.txt in your project or solution, and not risk accidentally publishing it to your production environment.
Restrict access based on hostname and request IP
Unless you need your staging slot to be accessible to a wide range of dynamic IPs, you could consider using the URL Rewrite module and adding rule[s] to your web app config to disallow traffic except for a few known IPs, but make those rules conditional on the HOST header matching the staging host (mydomain.azurewebsites.net), so they can never apply on the production hostname.
The details in the question here show a similar type of setup.
my friend have a site whole written in aspx (i dont know much about it).
we are trying to switch his web-hoster. we opened a new account (in a web-host site that supports everything we need) and moved all the files AS IS to the new web hoster.
now we get a:
Directory Listing Denied
This Virtual Directory does not allow contents to be listed.
what where we doing wrong? is there anything we need to concider besides putting the files in the new web-hoster...?
thanks.
Try http://yourwebsite.com/yourwebpage.aspx if this works then your deployment is correct. Now what you want is set the default page to "yourwebpage.aspx" as already commented by Brandon. Different host service provide different ways to do this. First let us know if http://yourwebsite.com/yourwebpage.aspx works. Also provide your host service provider name will look into their documentation and tell how to setup default page
It sounds like the website could have been running a url rewrite module which would require the server to pass all requests via asp.net using wildmapping.
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/5c5ae5e0-f4f9-44b0-a743-f4c3a5ff68ec.mspx?mfr=true
There are different ways this is handled depending on the version of IIS you are using. There is also limitations on this depending on your hosting environment.
A couple of questions that might help identity the issue
Was the previous hosting environment shared or dedicated/virtual
Was the previous hosting environment Windows 2003/IIS 6 or windows 2008/IIS 7
Is the new hosting environment shared or dedicated/virtual
Is the new hosting environment Windows 2003/IIS 6 or windows 2008/IIS 7
Before and application can run, you need to specify that the folder is an asp.net application. There should be a way to do this through your control panel, if not contact the vendor
What is the difference between publishing a website to {localdrive}\inetpub\wwwroot and anywhere else on the web server e.g. C:\Website.
I have noticed that I am always left with a directory and a website in the IIS console if I publish to {localdrive}\inetpub\wwwroot.
After reading articles on MSDN, I am still unclear of the difference. I realise that there is probably a simpe answer to this, but I cannot find it.
The web path / is already mapped to c:\inetpub\wwwroot, so /abc is mapped to c:\inetpub\wwwroot\abc automatically.
When you publish to c:\website, you need to set up a virtual path manually.
Nothing too much as your website path in IIS can point to any directory. However, that being said always double check your directory permissions and security settings. In addition, I guess if a hacker did compromised your webserver... the default c:\inetpub\wwwroot is well known.
And just for good measure in case you are having issues - check out the Aspnet_regiis.exe tool on MSDN as it usually solves a lot of issues for folks.
{localdrive}\inetpub\wwwroot is usually used for the default web site that comes with IIS.
Additional Microsoft products use the same directory and take advantage of the virtual directories that exist in the default site.
If this is your personal web site, or a web site you created from scratch, you can publish anywhere you want.
Before you publish, you need to make sure IIS knows where the directory will be, and you need to assign the correct permissions for that folder.
The default website in IIS is mapped to C:\inetpub\wwwroot by default, so publishing to wwwroot makes it easy to add applications as virtual directories.
However, you can publish wherever you like, and either point a virtual directory or new website at your publication location. You simply need to make sure user the App Pool is running as (usually IUSR under IIS7, IUSR_MachineName under previous versions) has read/execute permissions on the folder you are publishing to.
Although they say Virtual Directory created by default for your website in wwwroot and you don't have to configure it again. Many times I found we still have to go there and click on Remove and then click on Create button again :)
Thus it is almost no problem if you create your website outside wwwroot, only difference outside you have to give full path of VD and inside you have to click Remove and then Create button
The problem I had was different from all of the above. I was trying to publish in "C:\inetpub\wwwroot" and the publish failed every time. Than i changed the publish folder to another and it worked. When I launched visual studio as administrator I could copy to C:\inetpub\wwwroot also without problems
I am trying to get a grasp on how to handle updates to a live, functioning ASP.NET (2.0 or greater) Application while there are users on the site.
For example, suppose SO is an ASP.NET Web Application project. The project code compiles down to the single .DLL in the BIN folder. Now, there are constantly users on SO, so what would happen to users' actions/sessions if you would use the Visual Studio .NET "Publish" feature (or just FTP everything again manually) while they are using the site?
Would creating an ASP.NET Web Site, instead, alleviate any problems that may or may not exist with the scenario above? I am beginning to develop a web site as a user-driven Web Application, and I want to make sure that my inexperience with this would not potentially annoy the [potentially] many users that I [want to] have 24/7.
EDIT: Sorry, I should have put this in a more exact context. Assume that this site is being hosted by a web hosting service with monthly fees. I won't be managing the server itself, just what the web host allows as a user of their services.
I create two Web sites in IIS. One is the production Web site, and the other is a static Web site with an HttpHandler that sends all requests to a single static "We're updating" HTML page served with an HTTP 503 Service Unavailable. Typically the update Web site is turned off. When it's time to update, we stop the production Web site, start the update Web site, and now we can fiddle with the production Web site all we want without worrying about DLLs being locked or worker processes needing to be spun down.
I started doing this because
App_Offline.htm really does not work well in Web Gardens, which we use.
App_Offline.htm serves its page as 404, which is bad if you're down for a meaningful period of time.
We can start the upgraded production Web site with modified settings (only listening on localhost), where we can do a last-minute acceptance/verification that everything is working before we flip the switch, turning off the update Web site and re-enabling the production Web site.
Things this does not solve include
Any maintenance that requires a restart of the server--you still have downtime where no page is served.
Any maintenance that diddles with the .NET runtime, like upgrading to the latest service pack.
Other approaches I've seen include
Having two servers. Send all load balancing requests to one server, upgrade the other one; then rinse and repeat. Most of us don't have this luxury.
Creating multiple bin directories, like bin-1.0.0.0 and bin-1.1.0.0 and telling ASP.NET which bin directory to use in the web.config file. (One advantage of this is that reverting to a previous binary is just editing a config file. A disadvantage is that it's harder to revert resources that don't end up in your binaries, like templates and images and such.) I don't remember how this actually worked--I think the application did some late assembly loading in its Global.asax based on its own web.config section (since you touched the web.config, the app had restarted, so it was okay).
If you find a better way, let me know!
Changing to the asp.net web site model won't have any effect, as the recycle will also happen, some of changes that trigger it for sure: web.config, global.asax, app_code.
After the recycle, user will still be logged in because asp.net will just validate the syntax. That is given you use a fixed machine key, otherwise it will change on each recycle. This is something you want to do anyway as other stuff can break if the key change across requests i.e. viewstate validation, embedded resources (decryption of the url fails).
If you can put the session out of process, like in sql server, you will avoid loosing the session. If you can't, your code will have to consider that. There are plenty of scenarios where you can avoid using session, and others were you can wrap it and re-retrieve the info if the session was cleaned. This should leave you with a handful specific cases that you know can give trouble to the users, so for those you do some of the suggestions others have already made.
One solution could be to deploy your application into a load balanced environment (web farm).
When deploying a new version you would use the load balancer to redirect requests to the server you are not deploying to.
App_offline.htm is great solution for this I think.
in SO we see application currently unavailable page when a deployment begins.
I am not sure how SO handles it.. But we usually put a holding page. So what ever the user has done (adding question or answering questions) does not get updated. As soon as he updates something he will see a holding page asking him to try after sometime.
And if I am the user I usually press the back button to make sure what I entered is saved in the browser history so that I can post later.
Some site use use are in clustered environment so I take one server offline and inform the load balancer that she will not be available and once I make sure that the new version is working fine I make it live.. I do the same thing for the next server.
Do we have any other option?
It is not a technical solution, but set up a scheduled maintenance window. You can annoucement in advance giving your user base fair warning that there is a possiblity that the application will not be available during that time frame.
I'm going mad trying to get an ASP.NET application running on IIS7 (Server2008).
I have one web site set up in IIS7 which works fine. I'm trying to create another one now but I only get 404s for all .aspx files. The Handling Mappers are all different from the working site's.
Is there any way I can duplicate the working site's settings so I don't have to go through 50 mappings manually.
Or is there a better way to get the correct settings?
removed dead ImageShack links
IIS7's default configurations are held in c:\windows\system32\inetsrv\config\applicationHost.config
Any changes you make on a per site/application basis are stored in the web.config for that site/application.
You should be able to simply copy the files onto the second server.
If you are merely trying to re-install the default ASP.NET mappings, the best way to do that is use
aspnet_regiis.exe
which is in the %windir%\Microsoft.NET\Framework\v___ folders (depends on which version you're trying to set -- looks like 3.5?)
Use the documentation at http://msdn.microsoft.com/en-us/library/k6h9cz8h.aspx to see whether you want to use the -i, -r, or -s option.
For IIS 5 (and 6?), Microsoft had a free download called MetaEdit. It was used for just this - backing up and restoring an IIS configuration from machine to machine. Check MS's web site to see if there is an updated version for IIS 7.