On a fresh install of Windows Server 2008 R2 with IIS 7, it creates a default website in C:\inetpub\wwwroot. I'm sure there's lots of subjective opinion on where good places to store website files are, but I'm wondering if I were to create a second website, in addition to the default website, where would the IIS developers have intended I put it?
I'm thinking C:\inetpub\mysecondsite, but I can't say for sure.
You can really put your new web site's files wherever you want on the server. Most people tend to make subfolders for each individual site under the wwwroot. I usually delete the Default Web Site and start from scratch.
For example:
C:\inetpub\wwwroot\myfirstsite
C:\inetpub\wwwroot\mysecondsite
Related
I can't found nothing recent on the web about if deleting Default Web Site in IIS is a good practice, i'm using IIS v10 and as in wwwroot i have each website inside it's own folder in IIS i've just created a website for each of them..
So i'm just not using the Default Web Site and i was wondering if will it cause any problem if i will delete it (for now i've just disabled it but seeing it in the list is a bit triggering), about deleting or keeping the Default Web Site i just found an article from 2001 so i would know something more recent about it.
Yes, you can safely delete the Default Web Site in IIS Manager, even though delete the files under the wwwroot. And it should be a good practice to do that to avoid some unexpected web accesses or attack.
And the Default Web Site in IIS Manager, even though the files under the wwwroot, is used for the first validation of IIS installation.
More, the Default Web Site will take the default port 80 if not disabled/deleted.
So, please go ahead to delete it.
Recently we moved our server from testing to production.
We had an issue with caching some referenced scripts so we needed to edit site.master and put some artificial query parameters on our referenced scripts.
From what I thought you wouldn't need to restart IIS simply modifying a .master page, but the other day I tried uploading a handful .master pages because we eliminated some code on them, and the site went down until we restarted IIS.
Any insight to the way IIS and MASTER pages work would be stellar.
Thank You for your help.
Generally speaking you wouldn't necessarily need to restart your website for a change in your master page. However, if you modify the code-behind you need to compile the site, because Sitefinity is a Web Application Project, not a Web Site Project. This means the full site is compiled to a DLL, so any changes in the code require a new compile to be run and pushed to your site.
In addition, Sitefinity makes use of caching to improve performance, so you might need to restart the site to clear the cache for any changes to things like master pages or user control (ascx) files as well.
I hope this is helpful!
I'm looking for a way to (hopefully) create a text file which lists all the settings in IIS for..
Virtual Directories
Web sites
Which framework is used on a certain website/directory
directory of hosted files
etc.
Basically I want to do some investigation on some of our servers to figure out where certain projects are located, without digging through right clicking and looking for the directory name manually, etc, for every domain we host.
The reasoning is that I often need to find access to files/projects I haven't worked on before, but historically, we don't have a strong naming scheme, so you can't just look where something "logically" would be - so, generating a list would be very helpful.
Something like this would be awesome, but I'm looking for any tips at all
Domainname1.com
framework: ASP.NET 1.1
directory: c:\inetpub\wwwroot\domainname1.com
Applications hosted at this domain:
etc, etc.
Plain text, XLS, XML.. anything other than right clicking through the whole list!
Thanks!
The IIS metabase is a configuration file that contains most of the settings of IIS, including what websites/application pools are running on the server. It's located by default at:
%windir%/system32/inetsrv/metabase.xml
You can potentially use that as a starting point and write a custom parser, or an XSLT transformation to get the report you want, but it's probably not going to be a trivial task.
We've installed Windows Search Server Express on one of our servers, which apparently runs on top of sharepoint.
Sharepoint was installed on port 80, where our "normal" intranet runs. When I disable the intranet and run the sharepoint site, everything works as intended. The intranet is linked in many places it would be a pain to move it, so I'm trying to move sharepoint to another "place" (hoping this is less of a pain), either a different port or as a virtual directory under the main site.
First, when I make any of these changes, it fails to get access to the intranet root. Not sure what it is looking for there, but ok, I give "Network service" (the acocunt the "Sharepoint 80" application pool is running under) access to the intranet root. This gets me one step further, I am stumped:
When I move the Sharepoint website to another port, it complains that it can't find default.aspx (there is none, but also it doesn't need it when running on port 80)
When I move it to a sub folder of the existing site, and try to open the global.asax in the browser, ti tells me that this extension is prohibited, even though the "Application configuration" is - as far as I understand - identical to that of the Sharepoint site, and allows GET, HEAD, POST, DEBUG for .asax.
Any suggestions?
Sharepoint sites should be able to run on any port- if you go into Sharepoint Central Admin and create or delete web applications without a problem.
Is it your intention to run heterogenously with Sharepoint and your regular site both on Port 80? I know that you can create a web application on 80 and then not have a root site collection ( Sharepoint applications consist of a Web Application that runs on a certain port and any number of Site Collections within that, each of which has it's own directory path and can contain lists, libraries, other Site Collections and so on ) just creating one on a different path, but I don't know for sure how that would work alongside an existing web site on the same port- it may not play nice. Again, you can create and delete site collections from the Sharepoint Central Admin page, which is linked from your Administrative Tools list on your server.I would try this first, as if it works it's an easy solution.
Is Windows Search Server Express related to Sharepoint's own search facilities? If it is you may find that it expects to run using some of the Shared Service Provider facilities, which even Sharepoint doesn't expect to be running on the same port as the sites it's providing services for.
An even better way would be to create another alias (cname) in your DNS for your server, just set a different host header for each web site.
for example, in DNS your machine might be named 'intranet'. Create an alias for that machine named 'sharepoint'
In IIS, create a new website for sharepoint, and set the host header for that site to 'sharepoint.domain.com', where domain.com is your domain.
Do the same for the intranet website, but set the host header to 'intranet.domain.com'
That way, your users don't have to use another port in the URL.
Thank you! I found the option in the sharepoint administration website.
I add this response to detail the steps I have taken - maybe they are useful for someone else.
In the sharepoint administration website (running flawlessly on another port), I chose "create or extend web applications", then "extend existing web application".
There, from the the drop down "Web application", "change web application" opens a popup with the web applications available. Search server was installed as "Sharepoint 80", so I selected that.
Then I selected "Create new IIS website", with a new name and a new port. All the other options looked fine to me as default.
Clicking OK, this creates a new web site in IIS, which was configured correctly. it doesn't work via the IP address of the server (http://192.x.x.x:8080), only using the server name - but that's ok with me :)
I still had to make some adjustments with the access rights, but the full crawl is running and I can find a few documents already. Yay!
This is much easier when you first backup your site and then create a new site from the central admin with a new port number and then restore the backup to it(overwrite)
Is it best practice to not use C:\Inetpub\wwwroot\wss\ for SharePoint? My concern is that the configuration wizard seems to look for this C: path and it may be too complicated to not use the default path(s),
What would be the reason for using an alternate location?
You should not be changing anything in the sharepoint IIS sites through IIS Manager, except through the sharepoint Central Admin site. There are dependencies in the sharepoint configuration that are not just stored in IIS, especially around the users that are applied for app pools etc. This website does most of the things you need to do (i.e. host headers etc)
So best practice is to create a folder in the C:\Inetpub\wwwroot\wss\ that is easy to map to the web application and then leave the folder as is.
Although it is hard to find stuff in the Central Admin site, the Infrastructure Update for SharePoint helps.
Having failed miserably in the past merely trying to change machine names on a VM after Sharepoint was installed, it is hard to imagine a goal more likely to frustrate than this idea!
The only arguments I've heard for not running IIS websites out of the Inetpub directory is that it's a commonly known location for evildoers to look at when attacking a system, but if security is your concern you're far past screwing the pooch if an attacker has file system access.
We've always let the configuration wizard pick that location for us. There's a lot of aspects of the underlying configuration that rely on that location and it's never seemed worthwhile to explore changing the home directory.