Search results matching tag 'Other'

Setup IIS on Server Core – Windows Server 2008 R2

Anonymous — Fri, 27 Feb 2009 01:20:24 GMT

With the addition of .NET Framework to Server Core in Windows Server 2008 R2 the Server Core installation option became even more appealing for those who want to use a very low footprint server for hosting their applications. Availability of .NET framework provides the following great benefits:

ASP.NET support – you can now use Server Core to host your ASP.NET applications.
IIS Remote Management – Server Core does not provide any user interface other than command line. But if you prefer to use IIS Manager UI to administer IIS, you can now use IIS Remote Manager to connect to IIS on Server Core and perform all the management tasks from within familiar UI of IIS Manager.
PowerShell – Windows Server 2008 R2 includes IIS PowerShell snapin, which is also available on Server Core.

This post describes how to setup and configure IIS on Server Core in Windows Server 2008 R2. Specifically the following tasks are described:

Using oclist and ocsetup commands
Basic Installation of IIS
Installing ASP.NET
Installing PowerShell and IIS snap-in
Enabling IIS Remote Management

Using oclist and ocsetup commands

oclist command can be used to list the available and installed roles and services on the server. The output of the command looks similar to below:

It is important to understand how oclist renders component dependencies. For example, in the above screenshot the oclist output shows that IIS-FTPExtensibility is dependent on IIS-FTPSvc, so in order to install IIS-FTPExtensibility it is first necessary to install IIS-FTPSvc.

ocsetup command can be used to install and uninstall individual roles and services.

Basic Installation of IIS

To perform basic and default installation of IIS on Server Core run the following command:

start /w ocsetup IIS-WebServerRole

After the command has run you can run oclist | more and check which IIS components have been installed.

Installing ASP.NET

To install ASP.NET on Server Core run the following commands in exact same order as listed below:

start /w ocsetup WAS-NetFxEnvironment
start /w ocsetup IIS-ISAPIExtensions
start /w ocsetup IIS-ISAPIFilter
start /w ocsetup IIS-NetFxExtensibility
start /w ocsetup IIS-ASPNET

Installing PowerShell and IIS snap-in

First, install the PowerShell by running the command as below:

start /w ocsetup MicrosoftWindowsPowerShell

Next, launch the PowerShell by running this command:

\windows\system32\WindowsPowerShell\v1.0\powershell.exe

After running this command you should see a PowerShell prompt. Type the following to import IIS snapin:

import-module WebAdministration

After that you can get the list of available IIS cmdlets by typing

get-command –pssnapin WebAdministration

Refer to the article Managing IIS with IIS 7.0 PowerShell Snap-in for more information.

Enabling IIS Remote Management

First install the IIS management service by executing this command:

start /w ocsetup IIS-ManagementService

Then enable remote management by running this command:

reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebManagement\Server ^
/v EnableRemoteManagement /t REG_DWORD /d 1

And finally start the management service:

net start wmsvc

Now you can connect to the IIS on the Server Core from a remote machine by using IIS Remote Manager.

Acknowledgement: thanks to Saad Ladki and Thomas Deml from IIS team for explaining to me all these steps.

Dynamic IP Restrictions for IIS 7.0 - Beta

Anonymous — Tue, 17 Feb 2009 02:34:00 GMT

Today IIS team has released the Dynamic IP Restrictions Extension for IIS 7.0 - Beta. The Dynamic IP Restrictions Extension provides IT Professionals and Hosters a configurable module that helps mitigate or block Denial of Service Attacks or cracking of passwords through Brute-force by temporarily blocking Internet Protocol (IP) addresses of HTTP clients who follow a pattern that could be conducive to one of such attacks. This module can be configured such that the analysis and blocking could be done at the Web Server or the Web Site level.

Install the Dynamic IP Restrictions Beta Today!

Microsoft Dynamic IP Restrictions for IIS 7.0 - Beta (x86)

Microsoft Dynamic IP Restrictions for IIS 7.0 - Beta (x64)

If IIS already has IPv4 Address and IP restrictions module enabled then Dynamic IP Restrictions installer will need to un-install the existing module in order to continue the setup process. Note that the existing IPv4 configuration will be preserved while old module is removed and new module is installed

Features

The Dynamic IP Restrictions includes these key features:

Blocking of IP addresses based on number of concurrent requests - If HTTP client makes many concurrent requests then that client’s IP address gets temporarily blocked.
Blocking of IP addresses based on number of requests over a period of time - If HTTP client makes many requests over short period of time then that client’s IP address gets temporarily blocked.
Various deny actions - it is possible to specify what response to return to an HTTP client whose IP address is blocked. The module can return status codes 403 and 404 or just drop the HTTP connection and do not return any response.
Logging of dynamically denied requests - all denied requests can be logged into a W3C formatted log file.
Displaying currently blocked IP addresses - a list of currently blocked IP addresses can be obtained by using IIS Manager or by using IIS RSCA API’s.
IPv6 - the module fully supports IPv6 addresses.

In additions to these features, the Dynamic IP Restrictions for IIS 7.0 provides the same functionality that exists in IIS 7.0 built-in IPv4 and Domain Restrictions. Because of that the Dynamic IP Restrictions is provided as a replacement for IPv4 and Domain Restrictions.

More information

Module walkthrough: http://learn.iis.net/page.aspx/548/using-dynamic-ip-restrictions/

Support forum: http://forums.iis.net/1043.aspx

ASP.NET postbacks and URL rewriting

Anonymous — Thu, 23 Oct 2008 05:04:11 GMT

ASP.NET Web Forms extensively use postback mechanism in order to maintain the state of the server-side controls on the web page. This makes it somewhat tricky to perform URL rewriting for ASP.NET pages. When a server side form control is added to the web page, ASP.NET will render the response with HTML <form> tag that contains an action attribute pointing back to the page where the form control is. This means that if URL rewriting was used for that page, the action attribute will point back to the rewritten URL, not to the URL that was requested from the browser. This will cause the browser to show rewritten URL any time a postback occurs.

Let me demonstrate this on an example. Assume you have a very simple web form in a file called default.aspx. When you request http://localhost/default.aspx in a browser and then view the HTML source for the response, you will see that the response contains the <form> element, which looks similar to this:

<form name=”form1″ method=”post” action=”Default.aspx” id=”form1″>

The action attribute contains the URL where the form data will be posted to when you click on the button in the web page.

Now, let’s create a very simple rewrite rule that rewrites URL from http://localhost/homepage to http://localhost/default.aspx.

<rewrite>
  <rules>
    <rule name="MyRule" patternSyntax="Wildcard">
      <match url="homepage" />
      <action type="Rewrite" url="default.aspx" />
    </rule>
  </rules>
</rewrite>

When you request http://localhost/homepage in a browser, the URL will be rewritten in accordance to the above rule and the page will be shown correctly in the browser:

However, when you click on the Submit button, the browser’s address bar will display http://localhost/default.aspx, thus exposing the internal URL, that you wanted to hide by using URL rewriting:

A few workarounds to fix this behavior existed in previous versions of ASP.NET. For example, you could sub-class the form control, or use Control Adapter as explained here. However, these workarounds were not very easy to implement. Luckily, the ASP.NET in .NET Framework 3.5 SP1 provides a very simple way to fix that. Now you can use the property of the HtmlForm class called Action to set the postback URL to the one that was requested by browser before any rewriting happened. You can obtain that URL from a server variable set by URL rewriting component. For example ISAPI_Rewrite saves it in a server variable called HTTP_X_REWRITE_URL. URL Rewrite Module for IIS 7.0 saves it in HTTP_X_ORIGINAL_URL. So, to fix the postback URL for your web form when you use URL Rewrite Module, you would need to add the following code to the page:

protected void Page_Load(object sender, EventArgs e)
{
    if ( !String.IsNullOrEmpty(Request.ServerVariables["HTTP_X_ORIGINAL_URL"]) )
    {
        form1.Action = Request.ServerVariables["HTTP_X_ORIGINAL_URL"];
    }
}

After this change, if you reload the web page at http://localhost/homepage and then click on submit button you will see that the browser’s address bar still displays the correct URL:

If you view the HTML for the response you will see that the <form> tag now contains the correct action URL:

<form name=”form1″ method=”post” action=”/homepage” id=”form1″>

When you use ASP.NET master pages you could add the Page_Load method to the master page and that would take care of postback action URL for all the pages in your web application. Note thought that in order to be able to use the HtmlForm.Action property you have to upgrade to .NET Framework 3.5 SP1.

Wildcard script mapping and IIS 7 integrated pipeline

Anonymous — Wed, 01 Oct 2008 03:30:18 GMT

The big benefit of IIS 7 integrated request processing pipeline is the fact that all the nice and useful ASP.NET features can be used for any type of content on your web site; not just for ASP.NET-specific content. For example, ASP.NET SQL-based membership can be used to protect static files and folders. Also, ASP.NET extensibility API’s, such as IHttpHandler and IHttpModule can be used to add custom modules and handlers that would be executed even for non-ASP.NET content.

IIS 6 did not have this level of integration. ASP.NET was plugged into IIS 6 as an ISAPI extension and by default was configured to handle ONLY requests mapped to that extension - for example any request that ended with “.aspx” would be be processed by ASP.NET extension. This obviously was a big limitation for customers who wanted to be able to use ASP.NET features for all other contend on web site. The most common way to workaround that was to use “Wildcard script mapping”. This post explains how an application that used wildcard script mapping in IIS 6 can be migrated over to IIS 7.

Assume you had configured ASP.NET in IIS 6 to handle all requests by using wildcard script mapping. For example you had an ASP.NET module for URL rewriting and you wanted this module to handle extension-less URLs.

This wildcard script map configuration is typically done within IIS 6 manager by opening the properties dialog for either web server or web site and selecting Home Directory tab, then clicking on Configuration button and then clicking on the Insert button for “Wildcard application maps”:

Now, as you move your application to IIS 7, you want to configure it to achieve the same behavior of ASP.NET. There are two options on how this can be done: using Classic pipeline mode or using Integrated pipeline mode.

Wildcard script mapping in IIS 7 classic pipeline mode

With classic pipeline mode the ASP.NET is plugged into the IIS request processing pipeline as an ISAPI extension - exactly the same way as it was in IIS 6. In fact, if you open %WINDIR%\system32\inetsrv\config\applicationHost.config file and locate the <handlers> section inside of it you can see how IIS is configured to map ASP.NET specific requests to the aspnet_isapi.dll:

<handlers accessPolicy="Read, Script">
  ...
  <add name="PageHandlerFactory-ISAPI-2.0"
       path="*.aspx" verb="GET,HEAD,POST,DEBUG"
       modules="IsapiModule"
       scriptProcessor="%windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"
       preCondition="classicMode,runtimeVersionv2.0,bitness32" responseBufferLimit="0" />
  ...
</handlers>

Notice the preCondition attribute for the handler mapping. Among other things this attribute is set to classicMode, which ensures that this handler mapping only takes effect when the application pool is configured to run in classic mode.

Now if you want to configure wildcard mapping for the ASP.NET running in classic mode, you can add one more handler mapping to the <handlers> section just before the handler mapping for static files:

<handlers accessPolicy="Read, Script">
  ...
  <add name="ASP.NET-ISAPI-2.0-Wildcard"
     path="*" verb="GET,HEAD,POST,DEBUG"
     modules="IsapiModule"
     scriptProcessor="%windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"
     preCondition="classicMode,runtimeVersionv2.0,bitness32" responseBufferLimit="0" />
  <add name="StaticFile"
     path="*" verb="*"
     modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule"
     resourceType="Either" requireAccess="Read" />
</handlers>

The relative order of the wildcard handler mapping is important: if you define this handler mapping after the “StaticFile” handler mapping then “StaticFile” will handle all the requests and no requests will ever come to ASP.NET wildcard handler.

As you may already know the ASP.NET wildcard handler mapping in IIS 7 is subject to the same performance limitations as existed in IIS 6. The problem with this kind of handler mapping is that ALL requests are processed by it, including requests for static files. The ASP.NET static file handler is not as powerful as native IIS static file handler. Plus static files served by ASP.NET will not be cached by IIS in kernel mode. Because of these performance limitations it is recommended that you use IIS 7 integrated pipeline to achieve the same functionality as with wildcard mappings in IIS 6.

IIS 7 integrated pipeline instead of wildcard script mapping

With integrated pipeline, the ASP.NET functionality is fully integrated into the main request processing in IIS, which means that all ASP.NET features are now available for any type of requests. This effectively eliminates the need for the wildcard handler mapping. Now you can use your existing ASP.NET modules and have them applied to all requests.

For example let’s say you had a URL rewriting module written in ASP.NET. On IIS 6 this module was registered inside of the <system.web> section in web.config file as below:

<system.Web>
  <httpModules>
    ...
    <add name="MyUrlRewrite"
         type="SomeNamespace.MyModules.UrlRewrite, SomeNamespace.MyModules" />
    ...
  </httpModules>
</system.Web>

Since on IIS 6 this module was only executed for requests to managed content, it only worked for URLs that had .aspx extension, such as http://example.com/archive/2008/08/26/post-title.aspx. If you wanted it to handle extension-less URLs you had to configure wildcard script mapping for ASP.NET. With IIS 7 integrated pipeline you do not have to do that anymore. In order to make this module apply to extension-less URLs you need to register it within the <system.webServer> section inside of web.config file as below:

<system.webServer>
  <modules >
    ...
    <add name="MyUrlRewrite"
         type="SomeNamespace.MyModules.UrlRewrite, SomeNamespace.MyModules"
         preCondition="" />
    ...
  </modules>
<system.webServer>

Make sure that you leave the preCondition attribute empty here as it would enforce that the module will be executed for all requests, not just for requests for ASP.NET specific content.

Registering your managed modules this way does not have such dramatic performance impact as when using wildcard script mappings. Even though the module is invoked for all requests to web application, all the existing handler mappings are still in effect, which means that the static files are still served by the native IIS static file handler. Another benefit of registering your module this way is that now it can be applied to requests for PHP, ASP or any other dynamic pages. You would not be able to do that if you used wildcard script mappings.

One last thing to mention here is that you can also use the attribute on the <modules> section called runAllManagedModulesForAllRequests.

<system.webServer>
  <modules runAllManagedModulesForAllRequests="True" >
    ...
    <add name="MyUrlRewrite"
         type="SomeNamespace.MyModules.UrlRewrite, SomeNamespace.MyModules"
         preCondition="ManagedHandler" />
    ...
  </modules>
<system.webServer>

This attributes forces IIS to ignore the preCondition=”managedHandler” attribute, hence all managed modules will be invoked for all requests to web application.

Introduction

Anonymous — Fri, 11 Jul 2008 05:29:11 GMT

My name is Ruslan Yakushev. I am a program manager on IIS team, working on some of the very interesting projects that are being developed in the team right now. I have joined the team about a year ago, and was thinking about starting a blog for a while now. The primary work responsibilities kept me busy, so I have been postponing blog idea for a while. Every time I needed to make an announcement or an update on IIS community site, I asked some of my colleagues on the team to blog my content. Finally, I figured that I should probably start my own blog, so I could have all the freedom of publishing my own content any time I want.

Being a technical program manager on the team, I like to use (in other words - “dogfood”) the products that team develops. Hence I decided to self-host my own blog by using latest version of IIS. Also, I have been working with FastCGI and PHP for a while now, and became quite familiar with many popular PHP applications. As a result I chose to run my blog by using latest version of WordPress, which is a very nice and easy to use blog engine application. Finally, I am using my favorite feature of IIS 7.0 - URL rewriter - to enable “pretty permalinks” on my blog.

I plan to use this blog to publish information related to FastCGI, PHP, URL rewriter and IIS in general. I hope you’ll find this content useful.

Leaving Microsoft ...

mvolo — Wed, 14 May 2008 23:29:00 GMT

After almost 5 years at the company, I am both sad and excited to say that I’ll be leaving the IIS team and Microsoft at the end of this week.

I’ve spent the past 4 years living and breathing IIS 7.0, from its inception, to the Vista release, and the final debut in Windows Server 2008. During most of this time, I was heads down in designing and driving the development of the product, with little opportunity to see the impact it will have in the outside world.

Now that IIS 7.0 is ready, I feel it’s the right time to shift perspectives, and focus on leveraging it to make that impact. The more I learn about the problems customers solve in the wild, the more I realize how much work there still is to truly “unleash the potential” of the web server (thankfully, this is exactly what we wanted to enable through the end-to-end extensibility architecture of IIS 7.0). So, I will be leaving to help customers make the most of IIS 7.0, and start a few projects around web server performance, shared hosting and scalable web farms.

Looking back, I can say that my experience at Microsoft has been truly amazing. I got to ship two amazing products, ASP.NET 2.0, and IIS 7.0. I got to do what I love to do – design and build platform technology. Here are some of things I’ve owned:

1. ASP.NET 2.0 core infrastructure: designing and driving literally hundreds of features and improvements for the ASP.NET 2.0 runtime, and platform features like security, session state, caching, health monitoring, tracing, etc. Back then I was on the free nights/weekends work plan :).

2. Driving ASP.NET 2.0 security, and delaying the security push by 2 weeks to personally threat model 3/4ths of the product.

3. Designing and driving the IIS 7.0 core web server engine, extensibility layer, and core features

4. IIS 7.0’s output cache

5. The never-ending story of making the ASP.NET Integrated pipeline happen

6. FastCGI and PHP integration

7. Being the trinity (dev, pm, and test) for AppCmd

8. Bitrate throttling

9. Happiest moment: standing ovation at the TechEd 2005 demo of showing a completely stripped-down IIS 7.0 web server.

10. Most embarrassing moment: “HTTP service failed to start” during my first demo at the breakout PDC session on IIS 7.0 (when the BITS service randomly decided to corrupt its SSL binding, after a dozen of successful test runs the night before)

Between my core areas, side projects, and random work, I got to do pretty much everything else in the process: work on the IIS 7.0 config system, write code, do performance testing, drive product-wide compatibility analysis, write the IIS 7.0 Resource Kit book, present at TechEd and PDC, blog, and write articles.

Even more importantly, I got to work with some of the most talented people I have ever met, from whom I learned a great deal and without whom IIS 7.0 would not have been possible.

So, I definitely feel like I am not leaving empty-handed. I will really miss the team and the people, and will be keeping in touch. I look forward to using all the new great out of band features that the team is building to help make the IIS 7.0 platform the best web server in the world. Also, you can count on me continuing to blog about using and extending IIS 7.0.

I’ll be posting more info on www.mvolo.com next week. In the meantime, if you need help on an IIS 7.0 project, let me know.

Sincerely,

Mike (mvolo) Volodarsky

IIS 7.0 is finished: a trip down memory lane

mvolo — Fri, 29 Feb 2008 03:35:00 GMT

After 5 years in development, IIS 7.0 is finished!

Personally, it is hard to believe that it is over. I remember joining the IIS 7.0 team over 4 years ago, when the project was in its infancy, to drive the design of the web server engine. I remember getting in the room with all of the senior IIS 7.0 developers, with a spec of how the web server pipeline was going to work … feeling like I was about to be eaten alive :)

More reflections at http://mvolo.com/blogs/serverside/archive/2008/02/28/IIS-7.0-ships_3A00_-a-trip-down-memory-lane.aspx.

Mvolo.com is back!

mvolo — Mon, 24 Sep 2007 04:01:00 GMT

After several weeks of move-related outages, mvolo.com is back online at its new home at MaximumASP.

The server ran Windows Server 2008 beta 3 for 5+ months in my friend's garage without a single reboot, while the only access I had to it was through the blog's publishing interface. The new specs are orders of magnitude better than what I had before, so I am pretty excited to see the improvements in responsiveness.

Temporary mvolo.com outages

mvolo — Fri, 14 Sep 2007 01:45:00 GMT

You may have noticed mvolo.com being unavailable at certain points over the past two days. I am in the process of moving the server across the country, and that combined with certain other toubles with the internet setup is contributing to spotty availability.

Next week the server will find its new permanent home so it will start being available 24/7 once again.

In the meantime, sorry for the inconvinience. Do check back soon as there are A LOT of exciting news and new stuff coming your way next week.

Thanks,

Mike

A look at the IIS7 web server in MSDN magazine

mvolo — Thu, 15 Feb 2007 02:54:00 GMT

The march edition of MSDN magazine is live, containing my article about the IIS7 web server in Windows Vista. The article is an overview of the many features and architectural changes in IIS7, that hopefully will point people towards the specific things that they want to learn more about and try.

Read more on http://mvolo.com/blogs/serverside/archive/2007/02/14/A-look-at-the-IIS7-web-server-in-MSDN-magazine.aspx.