In this walkthrough you will learn how to create Web-Sites, Web Applications, Virtual Directories and Application Pools.

Introduction

The IIS PowerShell namespace consists of items like Web-Sites, Apps, Virtual Directories and Application Pools. Creating new namespace items and managing them is very easy using the built-in PowerShell cmdlets.

Creating Web-Sites

 If you are familiar with PowerShell you know that the New-Item cmdlet is used to create new items in the various PowerShell namespaces. The command "New-Item c:\TestDirectory" creates a new filesystem directory for example (most people use the "MD" or "MKDIR" alias for New-Item however). New-Item is also used to create new Web-Sites within the IIS 7.0 PowerShell namespace.

Parameters

Specifying the name of the directory is the only argument needed when you create a new file system directory. Unfortunately this is not enough when you create a Web-Site. Additional parameters like the file system path and network bindings are needed to create a Web-Site. Here is the command to create a new Web-Site followed by a dir command:

PS IIS:\Sites> New-Item iis:\Sites\TestSite -bindings @{protocol="http";bindingInformation=":80:TestSite"} -physicalPath c:\test

PS IIS:\Sites> dir

Name             ID   State      Physical Path                  Bindings
----             --   -----      -------------                  --------
Default Web Site 1    Started    f:\inetpub\wwwroot             http *:80:
TestSite         2    Started    c:\test                        http :80:TestSite 

Using the -physicalPath argument is pretty straightforward. But you might ask yourself why the -bindings argument looks so complex.

The construct used is a hashtable (go here to learn more about PowerShell hash tables). Within the hash table key=value pairs indicate the settings that reflect the attributes within the IIS site bindings section:

<bindings>
        <binding protocol="http" bindingInformation=":80:TestSite" />
</bindings>

Now here is the reason why we use a hash table: IIS configuration is completely extensible (see  here for more details) with additional sections and attributes. You can imagine that somebody extending the <binding> element with additional attributes. Key value pairs within a hash table provide the flexibility to incorporate these new attributes without having to completely rewrite the IIS PowerShell Snap-in.

Granted, the syntax is a bit complex. We are thinking about wrapping some typical tasks like creating sites with additional functions or scripts in a later Tech Preview.

Deleting Sites

Here is how you delete the site you just created.

PS IIS:\ >Remove-Item IIS:\Sites\TestSite

Creating Web Applications

Creating Web Applications is easier than creating sites. Here we go: 

PS IIS:\> New-Item 'IIS:\Sites\Default Web Site\DemoApp' -physicalPath c:\test -type Application

 

Name                     ApplicationPool          EnabledProtocols         PhysicalPath
----                     ---------------          ----------------         ------------
DemoApp                  DefaultAppPool           http                     c:\test

The only parameter you have to specify is the type (-type) because underneath a Web-Site you might want to create an Applications or a Virtual Directories. By specifying the -type parameter you tell the IIS Snap-in to create an application.

To delete the application you can also use Remove-Item.  

Creating Virtual Directories

To create a Virtual Directory you also use the New-Item cmdlet. Let's create a Virtual Directory underneath the 'Default Web Site' but and a second one underneath the Web Application we created in the previous step.

PS IIS:\> New-Item 'IIS:\Sites\Default Web Site\DemoVirtualDir1' -type VirtualDirectory -physicalPath c:\test\virtualDirectory1

Name                                              PhysicalPath
----                                              ------------
DemoVirtualDir1                                   c:\test\virtualDirectory1


PS IIS:\> New-Item 'IIS:\Sites\Default Web Site\DemoApp\DemoVirtualDir2' -type VirtualDirectory -physicalPath c:\test\virtualDirectory2

Name                                              PhysicalPath
----                                              ------------
DemoVirtualDir2                                   c:\test\virtualDirectory2

Creating Application Pools

But it gets even simpler. Creating a new AppPool only requires the name to be specified.

PS IIS:\> new-item AppPools\DemoAppPool

Name                     State
----                     -----
DemoAppPool              {}

Simple, wasn't it? Now let's put this together to an end-to-end scenario.

Putting it all Together

In the following end-to-end scenario we will execute the following step:

  1. Create a set of new file system directories for the sites, web applications and virtual directories we will create a little later.
  2. Copy some very simple web content into the newly created directories.
  3. Create new Application Pool
  4. Create a new site, a new application and two new virtual directories and assign them to newly created Application Pool.
  5. Request the web content via the web browser.

Step 1: Create New Directories

 We use the New-Item cmdlet to create four new file system directories. Execute the following commands (use 'md' instead of New-Item if you don't want to specify the -type parameter):

New-Item C:\DemoSite -type Directory

New-Item C:\DemoSite\DemoApp -type Directory

New-Item C:\DemoSite\DemoVirtualDir1 -type Directory

New-Item C:\DemoSite\DemoVirtualDir2 -type Directory

Step 2: Copy Content

Now let's write some simple html content to these directories:

Set-Content C:\DemoSite\Default.htm "DemoSite Default Page"

Set-Content C:\DemoSite\DemoApp\Default.htm "DemoSite\DemoApp Default Page"

Set-Content C:\DemoSite\DemoVirtualDir1\Default.htm "DemoSite\DemoVirtualDir1 Default Page"

Set-Content C:\DemoSite\DemoVirtualDir2\Default.htm "DemoSite\DemoApp\DemoVirtualDir2 Default Page"

Step 3: Create New Application Pool

Create the new Application Pool 'DemoAppPool' for the new site if you deleted the one we created in the previous sample.  

New-Item IIS:\AppPools\DemoAppPool

Step 4: Create New Sites, Web Applications and Virtual Directories and Assign to Application Pool

Here comes the beef. We create DemoSite, DemoApp and two Virtual Directories - DemoVirtualDir1 is directly underneath DemoSite and DemoVirtualDir2 is underneath DemoApp. We are assigning DemoSite and DemoApp to DemoAppPool created in the previous step. DemoSite is assigned to port 8080 to not conflict with the 'Default Web Site'

New-Item IIS:\Sites\DemoSite -physicalPath C:\DemoSite -bindings @{protocol="http";bindingInformation=":8080:"}

Set-ItemProperty IIS:\Sites\DemoSite -name applicationPool -value DemoAppPool

New-Item IIS:\Sites\DemoSite\DemoApp -physicalPath C:\DemoSite\DemoApp -type Application

Set-ItemProperty IIS:\sites\DemoSite\DemoApp -name applicationPool -value DemoAppPool

New-Item IIS:\Sites\DemoSite\DemoVirtualDir1 -physicalPath C:\DemoSite\DemoVirtualDir1 -type VirtualDirectory

New-Item IIS:\Sites\DemoSite\DemoApp\DemoVirtualDir2 -physicalPath C:\DemoSite\DemoVirtualDir2 -type VirtualDirectory

Voila. All that's left is to request the web content.

Step 5: Request the Web Content

You can of course open the browser and enter http://localhost:8080/ and all the other URLs. But its a PowerShell walkthrough and we'll use PowerShell to do it by using the .NET WebClient classes:

$webclient = New-Object Net.WebClient

$webclient.DownloadString("http://localhost:8080/");

$webclient.DownloadString("http://localhost:8080/DemoApp");

$webclient.DownloadString("http://localhost:8080/DemoVirtualDir1");

$webclient.DownloadString("http://localhost:8080/DemoApp/DemoVirtualDir2");

If you feeling adventurous you can also use Internet Explorer object itself:

$ie = new-object -com InternetExplorer.Application

$ie.Visible = $true

$ie.Navigate("http://localhost:8080/");

Summary

In this walkthrough you learned how to create Web-Sites, Web Applications, Virtual Directories and Application Pools with PowerShell. Additional PowerShell features were used to build a functional end-to-end scenario.

Related Content


Every time I create an IIS website, I do some steps, which I consider as best practice for creating any IIS website for better performance, maintainability, and scalability. Here' re the things I do:

Create a separate application pool for each web application

I always create separate app pool for each web app because I can select different schedule for app pool recycle. Some heavy traffic websites have long recycle schedule where low traffic websites have short recycle schedule to save memory. Moreover, I can choose different number of processes served by the app pool. Applications that are made for web garden mode can benefit from multiple process where applications that use in-process session, in memory cache needs to have single process serving the app pool. Hosting all my application under the DefaultAppPool does not give me the flexibility to control these per site.

The more app pool you create, the more ASP.NET threads you make available to your application. Each w3wp.exe has it's own thread pool. So, if some application is congesting particular w3wp.exe process, other applications can run happily on their separate w3wp.exe instance, running under separate app pool. Each app pool hosts its own w3wp.exe instance.

So, my rule of thumb: Always create new app pool for new web applications and name the app pool based on the site's domain name or some internal name that makes sense. For example, if you are creating a new website alzabir.com, name the app pool alzabir.com to easily identify it.

Another best practice: Disable the DefaultAppPool so that you don't mistakenly keep adding sites to DefaultAppPool.

image

First you create a new application pool. Then you create a new Website or Virtual Directory, go to Properties -> Home Directory tab -> Select the new app pool.

image

Customize Website properties for performance, scalability and maintainability

First you map the right host headers to your website. In order to do this, go to WebSite tab and click on "Advanced" button. Add mapping for both domain.com and www.domain.com. Most of the time, people forget to map the domain.com. Thus many visitors skip typing the www prefix and get no page served.

image

Next turn on some log entries:

image

These are very handy for analysis. If you want to measure your bandwidth consumption for specific sites, you need the Bytes Sent. If you want to measure the execution time of different pages and find out the slow running pages, you need Time Taken. If you want to measure unique and returning visitors, you need the Cookie. If you need to know who is sending you most traffic - search engines or some websites, you need the Referer. Once these entries are turned on, you can use variety of Log Analysis tools to do the analysis. For example, open source AWStats.

But if you are using Google Analytics or something else, you should have these turned off, especially the Cookie and Referer because they take quite some space on the log. If you are using ASP.NET Forms Authentication, the gigantic cookie coming with every request will produce gigabytes of logs per week if you have a medium traffic website.

image

This is kinda no brainer. I add Default.aspx as the default content page so that, when visitors hit the site without any .aspx page name, e.g. alzabir.com, they get the default.aspx served.

image 

Things I do here:

  • Turn on Content Expiration. This makes static files remain in browser cache for 30 days and browser serves the files from its own cache instead of hitting the server. As a result, when your users revisit, they don't download all the static files like images, javascripts, css files again and again. This one setting significantly improves your site's performance.
  • Remove the X-Powered-By: ASP.NET header. You really don't need it unless you want to attach Visual Studio Remote Debugger to your IIS. Otherwise, it's just sending 21 bytes on every response.
  • Add "From" header and set the server name. I do this on each webserver and specify different names on each box. It's handy to see from which servers requests are being served. When you are trying to troubleshoot load balancing issues, it comes handy to see if a particular server is sending requests.

image

I set the 404 handler to some ASPX so that I can show some custom error message. There's a 404.aspx which shows some nice friendly message and suggests some other pages that user can visit. However, another reason to use this custom mapping is to serve extensionless URL from IIS. Read this blog post for details.

image

Make sure to set ASP.NET 2.0 for your ASP.NET 2.0, 3.0 and 3.5 websites.

Finally, you must, I repeat you "MUST" turn on IIS 6.0 gzip compression. This turns on the Volkswagen V8 engine that is built into IIS to make your site screaming fast.


출처 : http://weblogs.asp.net/omarzabir/archive/2008/10/04/best-practices-for-creating-websites-in-iis-6-0.aspx

+ Recent posts