David Wang : IIS 7.0 (beta)

HOWTO: Install and Run PHP on IIS7, Part 2

Anonymous — Thu, 22 Jun 2006 06:39:00 GMT

A couple of months ago, I wrote a quick and dirty entry on how to install PHP on IIS7. The main purpose of that entry was to explain the details of what was going on as well as cookie-cutter instructions of one way to successfully install PHP on IIS7.

Well, the responses that I have received from that blog entry made me realize that I need to provide something a little more shrink-wapped which does a few more things other than just run the bare minimum... because I was seeing way too many broken custom modifications coming from mistaken assumptions about PHP or IIS7.

Here it is, V2. Just copy/paste the following into a .bat file, right-click run it as elevated Administrator on Vista, and follow the prompted instructions. You should have PHP extracted into a directory of your choice before-hand (I favor and default to %SYSTEMDRIVE%\Inetpub\PHP for many aforementioned reasons; in my examples, I chose "C:\Program Files\P H P" to show it working with long pathnames).

The batch script:

Works with PHP installed wherever, including pathnames with spaces. Just tell it where you installed PHP (sans double quotes and trailing backslash)
Gives choice of whether to use the CGI or ISAPI version of PHP. You do have to give the correct binary name (php5isapi.dll or php-cgi.exe, assuming PHP5), but there are checks for that
Gives warnings and errors if the directory/file does not exist, mismatched binary types, and additional steps you need to do to have a minimally functioning PHP

Now, I am no PHP expert, so I can only give instructions for how to get PHP configured and running on IIS7. Questions about all other PHP-related features (like PHP extensions, integration with mySQL, etc) and how to get them working really belong on a PHP support forum.

Sample Execution Results:

Setting up PHP5 installed at "C:\Program Files\P H P", ISAPI version. Notice the defaults and verification of provided inputs.

David.Wang's Sample PHP/IIS7 Configurator
Version: June 2006

------------------------------ Summary ------------------------------
PHP Binaries Dir : C:\Inetpub\PHP
PHP Binary Type  : ISAPI
PHP Binary Name  : php5isapi.dll
---------------------------------------------------------------------

Validating inputs...

ERROR: PHP Binary "C:\Inetpub\PHP\php5isapi.dll" does not exist!
Please first completely extract PHP to "C:\Inetpub\PHP"

Remember to tweak PHP.INI for security and functionality per php.net
Finished input validation.

Press 1 to EDIT choices, or ENTER to start IIS modifications:1

Press ENTER to accept [C:\Inetpub\PHP], or provide new value (folder path)
PHP Binaries Dir:C:\Program Files\P H P
Press ENTER to accept [ISAPI], or provide new value (CGI or ISAPI)
PHP Binary Type:
Press ENTER to accept [php5isapi.dll], or provide new value (filename)
PHP Binary Name:

David.Wang's Sample PHP/IIS7 Configurator
Version: June 2006

------------------------------ Summary ------------------------------
PHP Binaries Dir : C:\Program Files\P H P
PHP Binary Type  : ISAPI
PHP Binary Name  : php5isapi.dll
---------------------------------------------------------------------

Validating inputs...

Remember to tweak PHP.INI for security and functionality per php.net
Finished input validation.

Press 1 to EDIT choices, or ENTER to start IIS modifications:

Starting IIS7 Configuration...

Copying "C:\Program Files\P H P\PHP.INI-Recommended" to PHP.INI...
Setting PHP Handler...
CONFIG object "system.webServer/handlers" changed
Adding and Enabling PHP in ISAPI/CGI Restriction List...
CONFIG object "system.webServer/security/isapiCgiRestriction" changed

Finished IIS7 Configuration.

Test installation using PHP file content of:  <?php phpinfo();?>

Setting up PHP5 installed at "C:\Program Files\P H P", CGI version. Notice the defaults and reminders as you change to CGI.

David.Wang's Sample PHP/IIS7 Configurator
Version: June 2006

------------------------------ Summary ------------------------------
PHP Binaries Dir : C:\Inetpub\PHP
PHP Binary Type  : ISAPI
PHP Binary Name  : php5isapi.dll
---------------------------------------------------------------------

Validating inputs...

ERROR: PHP Binary "C:\Inetpub\PHP\php5isapi.dll" does not exist!
Please first completely extract PHP to "C:\Inetpub\PHP"

Remember to tweak PHP.INI for security and functionality per php.net
Finished input validation.

Press 1 to EDIT choices, or ENTER to start IIS modifications:1

Press ENTER to accept [C:\Inetpub\PHP], or provide new value (folder path)
PHP Binaries Dir:C:\Program Files\P H P
Press ENTER to accept [ISAPI], or provide new value (CGI or ISAPI)
PHP Binary Type:cgi
Press ENTER to accept [php5isapi.dll], or provide new value (filename)
PHP Binary Name:php-cgi.exe

David.Wang's Sample PHP/IIS7 Configurator
Version: June 2006

------------------------------ Summary ------------------------------
PHP Binaries Dir : C:\Program Files\P H P
PHP Binary Type  : cgi
PHP Binary Name  : php-cgi.exe
---------------------------------------------------------------------

Validating inputs...

ERROR: PHP CGI requires modifying cgi.force_redirect to 0 in "C:\Program Files\P H P\PHP.INI"

Remember to tweak PHP.INI for security and functionality per php.net
Finished input validation.

Press 1 to EDIT choices, or ENTER to start IIS modifications:

Starting IIS7 Configuration...

Copying "C:\Program Files\P H P\PHP.INI-Recommended" to PHP.INI...
Setting PHP Handler...
CONFIG object "system.webServer/handlers" changed
Adding and Enabling PHP in ISAPI/CGI Restriction List...
CONFIG object "system.webServer/security/isapiCgiRestriction" changed

Finished IIS7 Configuration.

Test installation using PHP file content of:  <?php phpinfo();?>

Enjoy.

//David

@IF ?%_ECHO%?==?? ECHO OFF

SETLOCAL
SET DIR_PHP_FROM=%SYSTEMDRIVE%\Inetpub\PHP
SET PHP_TYPE=ISAPI
SET PHP_MODULE=IsapiModule
SET PHP_BINARY=php5isapi.dll

:Menu
ECHO.
ECHO David.Wang's Sample PHP/IIS7 Configurator
ECHO Version: June 2006
ECHO.
ECHO ------------------------------ Summary ------------------------------
ECHO PHP Binaries Dir : %DIR_PHP_FROM%
ECHO PHP Binary Type  : %PHP_TYPE%
ECHO PHP Binary Name  : %PHP_BINARY%
ECHO ---------------------------------------------------------------------

REM
REM Do some basic validations
REM
ECHO.
ECHO Validating inputs...
IF /I ?%PHP_TYPE%? NEQ ?CGI? IF /I ?%PHP_TYPE%? NEQ ?ISAPI? ECHO.&ECHO ERROR: Binary Type MUST be either CGI or ISAPI
FOR %%I IN ( %PHP_BINARY% ) DO (
    IF /I ?%PHP_TYPE%? EQU ?CGI? IF /I ?%%~xI? NEQ ?.exe? ECHO.&ECHO WARNING: Binary Type %PHP_TYPE% requires a CGI EXE binary
    IF /I ?%PHP_TYPE%? EQU ?ISAPI? IF /I ?%%~xI? NEQ ?.dll? ECHO.&ECHO WARNING: Binary Type %PHP_TYPE% requires an ISAPI DLL binary
)
IF NOT EXIST "%DIR_PHP_FROM%\%PHP_BINARY%" (
    ECHO.
    ECHO ERROR: PHP Binary "%DIR_PHP_FROM%\%PHP_BINARY%" does not exist!
    ECHO Please first completely extract PHP to "%DIR_PHP_FROM%"
)
IF /I ?%PHP_TYPE%? EQU ?CGI? SET PHP_MODULE=CgiModule
IF /I ?%PHP_TYPE%? EQU ?CGI? ECHO.&ECHO ERROR: PHP CGI requires modifying cgi.force_redirect to 0 in "%DIR_PHP_FROM%\PHP.INI"
IF /I ?%PHP_BINARY%? NEQ ?php5isapi.dll? IF /I ?%PHP_BINARY%? NEQ ?php-cgi.exe? ECHO.&ECHO WARNING: Unrecognized PHP binary %PHP_BINARY%
ECHO.
ECHO Remember to tweak PHP.INI for security and functionality per php.net
ECHO Finished input validation.
ECHO.

SET GO=
SET /P GO=Press 1 to EDIT choices, or ENTER to start IIS modifications:
IF ?%GO%? EQU ?? GOTO :Start

ECHO.
ECHO Press ENTER to accept [%DIR_PHP_FROM%], or provide new value (folder path)
SET /P DIR_PHP_FROM=PHP Binaries Dir:
ECHO Press ENTER to accept [%PHP_TYPE%], or provide new value (CGI or ISAPI)
SET /P PHP_TYPE=PHP Binary Type:
ECHO Press ENTER to accept [%PHP_BINARY%], or provide new value (filename)
SET /P PHP_BINARY=PHP Binary Name:

GOTO :Menu

:Start
REM
REM Start Configuration
REM
IF NOT EXIST "%DIR_PHP_FROM%\%PHP_BINARY%" (
    ECHO.
    ECHO ERROR: PHP Binary "%DIR_PHP_FROM%\%PHP_BINARY%" does not exist!
    ECHO Please first completely extract PHP to "%DIR_PHP_FROM%"
    GOTO :EOF
)

ECHO.
ECHO Starting IIS7 Configuration...
ECHO.
ECHO Copying "%DIR_PHP_FROM%\PHP.INI-Recommended" to PHP.INI...
COPY /Y "%DIR_PHP_FROM%\PHP.INI-Recommended" "%DIR_PHP_FROM%\PHP.INI" >NUL

PUSHD %SYSTEMROOT%\System32\inetsrv

ECHO Setting PHP Handler...
APPCMD SET CONFIG -section:handlers "-+[name='PHP-%PHP_TYPE%',path='*.php',verb='GET,HEAD,POST',modules='%PHP_MODULE%',scriptProcessor='%DIR_PHP_FROM%\%PHP_BINARY%',resourceType='File']"

ECHO Adding and Enabling PHP in ISAPI/CGI Restriction List...
APPCMD SET CONFIG -section:isapiCgiRestriction "-+[path='%DIR_PHP_FROM%\%PHP_BINARY%',allowed='true',groupId='PHP',description='PHP']"

POPD

ECHO.
ECHO Finished IIS7 Configuration.
ECHO.
ECHO Test installation using PHP file content of:  ^<?php phpinfo();?^>

ENDLOCAL

Thoughts on Debugging IIS7

Anonymous — Fri, 16 Jun 2006 13:45:00 GMT

Hmm... it seems that ever since I made the blog entry about how to install PHP on IIS7, I seem to have become the default tech-support for PHP/IIS7 issues. That'll teach me to ever post beta guidance again - I just get more "help, I've fallen and I can't get up" questions, especially the sort when the user ignores the directions or thinks that their "modifications" to my instructions are just as good. Sigh... ;-)

I mean, is it too much to expect that if you want to modify the configuration files by hand or commandline that you should have write access to the configuration files? The IIS7 UI automatically asks you for privilege elevation, but when you go on the commandline you are obviously on your own. Or that if I give instructions for configuring the PHP ISAPI handler to run using the ISAPI Module that you merely change the handler to run the PHP CGI EXE handler with the ISAPI Module (and not the CGI Module)?

However, this also makes me realize that if you think IIS6 is confusing and difficult to troubleshoot, IIS7 is even more open-ended and hence harder to troubleshoot. You really have to know how IIS7 operates and what you are configuring (and why) when you make IIS7 configuration changes... because one wrong step and the server will stop working, by-design due to its open extensibility.

For example, when it comes to requests not resulting in the proper response, my first question is "what handler generated the response - static file handler or arbitrary dynamic file handler" - because that determines the expected response behavior. However, it is clearly not how users think - users think of it as a file to download, HTML page with a CSS stylesheet, or ASP.Net web application not working. Unfortunately, given how configurable (and misconfigurable) IIS7 can be, using the user's view of the issue will not be sufficient to troubleshoot, and we cannot make it any better/easier - there are so many things to misconfigure!

All it means is that if you customize beyond the default set of supported IIS7 configurations, you will pretty much be on your own. We try our best to make many module combinations work, but it will always be possible to configure IIS7 modules into a non-functional state.

For example:

If you [accidentally] mangle the ordering of the StaticFileModule, DirectoryListingModule, and DefaultDocumentModule modules, IIS7 will either refuse to serve default documents (regardless of how you enabled/configured it), refuse to do 301 courtesy-redirect, or refuse to show a directory listing. If you just stare at the IIS7 configuration, you will tear your hair out trying to figure it out... and FREB or ETW tracing won't really help, either. You literally have to know how to order the modules to end up with expected IIS behavior, and requiring that knowledge is by-design. Similar dependencies exist for authentication and caching...
If you want to configure a "wildcard application mapping", you have to chant the magic incantation of a perfect handler configuration. I'll leave the exercise to the reader to come up with the spell. :-)
If you configure a handler AFTER the catch-all StaticFileHandler, it will NOT apply to any requests. If you just stare at the IIS7 configuration wondering why it is not running - it is there in the configuration section - you will go crazy unless you know how the handler section works.
If you configure an ISAPI DLL as a globalModule, reference a non-existing managed type as a module, or remove a referenced module from loading... good luck on the spotting the error! ;-)

In short, if you run IIS7 in non-default fashion, it will require either perfect instructions or the user has to really understand IIS7 processing and behavior. Maybe there is a way to lower the requirements of running/using IIS7, but I have not come up with any. What are your thoughts?

//David

HOWTO: Useful ASP page to retrieve Request and send Response Headers

Anonymous — Sun, 14 May 2006 10:30:00 GMT

I am finishing up on the series of ASP pages that show how to:

Send Responses of arbitrary Status Code
Send Responses with arbitrary types of Entity Body
Send Responses with arbitrary Headers (this entry)
Query Request Headers (this entry)

You know, the common programmatic stuff one wants to do on the web server to enable dynamic applications.

Yes, there is a good reason why I am going through this exercise with 10-year old ASP technology, and it has nothing to do with boredom. ;-) Hehe, it is always nice to have good debugging code on the server...

Where I am going with this is that later on, I am going to illustrate how IIS7 extensibility truly integrates native and managed modules. Yes, they ALL can finally modify and share the same request and response headers AS WELL AS Server Variables.

For years, you all have been asking for a way to modify AUTH_USER, AUTH_TYPE, REMOTE_ADDR, REMOTE_USER (and more) IIS Server Variables, and I have always told you it was essentially read-only and cannot be done without altering request processing behavior. Well, now you can change them at-will, and I will provide the module that shows you how.

FYI: For the astute reader and detail-freak - this is similar to the sort of code used to test IIS7...

Now remember, with power comes responsibility. Since any module can change the state of the IIS7 request pipeline, when you have custom modules configured, one can NO LONGER trust its state nor make any expectations of IIS behavior. This will make IIS7 harder to debug because you MUST know what every custom module is doing at all times in the request pipeline. FREB cannot help in general, and ETW Tracing is pretty noisy.

In other words, when it comes to debugging IIS7, it is CRITICAL to share:

What Global Modules are installed, especially non-default ones not shipped by Microsoft
What Modules are enabled to execute in URL namespace that runs your application, especially non-default managed code modules not shipped by Microsoft
What Handlers are configured for the applicable URL namespace that runs your application

I ask for similar things on IIS6 - what ISAPI Filters are installed and what Application Scriptmaps are applicable for your application. Just wider in scope.

But, enough about the upcoming stuff. Here's a little flashback...

/Headers.asp - just echos back the request headers sent by the client
/Headers.asp?action=set&headername=Foo&headervalue=bar - set response header of Foo with value bar. You need a raw client like WFetch to be able to see these results since web browsers ignore custom headers

Enjoy.

//David

<%
DIM headerAction, headerName, headerValue

headerAction = UCASE( Request.QueryString( "action" ) )
headerName = Request.QueryString( "headername" )
headerValue = Request.QueryString( "headervalue" )

IF headerAction = "SET" THEN
    Response.AddHeader headerName, headerValue
    Response.Write "<H2>Sent Response Headers:</H2>" & VbCrLf & _
                   "<PRE>" & VbCrLf & _
                   headerName & ": " & headerValue & VbCrLf & _
                   "</PRE>"
ELSE
    Response.Write "<H2>Received Request Headers:</H2>" & VbCrLf & _
                   "<PRE>" & VbCrLf & _
                   Request.ServerVariables( "ALL_RAW" ) & _
                   "</PRE>"
END IF
%>

Thoughts on Delegating IIS Configuration and Administration

Anonymous — Wed, 10 May 2006 09:56:00 GMT

Question

I am running IIS 6.0 on Windows 2003 Server. our web developers needed to create or edit websites, for security reasons I cannot simply give them admin rights or the password to the admin account.

I have created an account for them to logon remotely to the webserver, however, they do not have the proper rights to use the IIS management console. Is there a way to provide users without admin rights the ability to use IIS to create, edit and manage websites from a remote desktop connection?

Any help would be appreciated.

Best Regards

One Answer:

You must be a member of the Local administrators group to administer IIS 6 and below.

IIS 7 (when released) will remove such restrictions.

My Answer:

IIS6 does not come with such delegated administration capabilities, but various Control Panel Applets supplement that market.

Also... IIS7 does not exactly remove such restrictions. ;-)

On IIS7 Configuration

The security model of IIS7 configuration derives from NTFS ACLs on the distributed .config configuration files as well as Allow/Deny/Inherit logic of the configuration properties within the distributed .config hierarchy. I know I know, it sounds more complicated than it actually works. Without getting hung up on the details, here is how I rationalize it:

NTFS ACLs control whether a user can modify the .config files and hence potentially configure IIS behavior by adding/changing configuration properties.
Allow/Deny/Inherit logic within the IIS configuration subsystem determines whether the parent's or child's setting of any given configuration property within the distributed .config hierarchy "wins" and takes effect.
IIS server core (and its modules) merely read from the IIS configuration subsystem to get a merged view of the distributed configuration and then perform specified actions.
applicationHost.config is the root of the IIS configuration hierarchy.

All the pieces have to align for distributed administration to work properly. For example, you may have NTFS ACLs to write configuration values into a web.config file, but if the web.config file is not considered part of the .config hierarchy or whose property configuration was not delegated to that part of the hierarchy, the IIS configuration subsystem simply ignores your changes and IIS server core never sees nor acts on it (well, right now it just fails fast, so IIS7 is finicky about broken configuration, but you get the idea). Likewise, if you have no NTFS ACLs to change web.config files, you have no way to configure IIS even if the configuration properties are all delegated.

Thus, IIS7 restricts non-administrators from performing the following tasks via NTFS ACLs on the applicationHost.config file. This list merely illustrates our logical design and not necessarily exhaustive nor complete.

Create/Manage Application Pools
Create Websites and associate IP:Port:Host Bindings
Create Applications and associate Application Pools
Add Global Modules

Non-administrators can change any other IIS configuration as long as it is delegated to their portion of the .config hierarchy, and they have NTFS ACLs to modify web.config files.

Security, Security, Security...

Security is the reason why non-administrators cannot perform those tasks by default. Why? Well... non-administrators can easily elevate privileges via those tasks, which sorta destroys the purpose of delegating privileges...

If non-administrator can manage Application Pools, then they can elevate privileges by simply changing the Application Pool running their code into LocalSystem.
If non-administrator can Create/Manage Websites, then they can control what Application Pool runs their Application in the Website and hence can run code in Application Pools of elevated privileges.
If non-administrator can manage Global Modules, then they control the code that loads in all Application Pools and can possibly run code in Application Pools of elevated privileges.

You control all of this by controlling who can associate websites, applications and global modules, and application pools... which means that you simply cannot maintain security AND give non-administrators the ability to Create and Edit websites AND publish code into it. And no, we are not going to build hierarchies of inheritance simply to support the ability to only change Application Pool identity at one level but not another. Just too complicated a feature - you need to re-think your developer sandbox.

Conclusion

I understand that your desires are logical and reasonable, but logical/reasonable != secure. I hope I have explained why your requirements are actually contrary to your security desires.

Prior to IIS7, IIS did not have a configuration subsystem which allowed rich definition and delegation, so IIS control panel applets all run with Administrator/LocalSystem privileges and provide a proprietary/individual delegation view.

IIS7 comes with a rich and delegation friendly configuration subsystem that should be customizable to fit many requirements without needing control panel applets. Of course, IIS7 is totally extensible, from the server core to its configuration and administration via the UI, Commandline, and Scripting, so you can always implement your own logic on top of our primitives. You have the choice.

//David

Sitting in with the WiX "team"

Anonymous — Wed, 19 Apr 2006 09:50:00 GMT

I had a chance to sit in with the WiX "team" on their weekly Tuesday night "meeting" where the majority of the heavy-lifting of WiX development happens. For those of you who think that Microsoft cannot "get stuff done" ... you should see how WiX works.

Now, I knew Rob already, but tonight was the first time I put a name to a face for the other Microsoft contributors to WiX - in particular, Derek, Scott, and Justin. And of course, I will likely show up more in the future as I get more engaged in the following problem space...

For some time now, I have been an avid user of WiX, and I learned a lot about how MSI works through using WiX and getting answers from people like Rob and Carol. Of course, I also enjoy giving back by weigning in on questions regarding the IIS CustomAction support in WiX. And inevitably, everyone always asks this question - why doesn't someone on the IIS team own the IIS CustomAction support for MSI?

Well, I am taking that next logical step... getting CustomAction support for configuring IIS7 into WiX. I am getting my source enlistment right now and have some starter tasks to get my feet wet with, so I am looking forward to that. :-)

Now, I will only say that some of the most "interesting" discussions and things come up on these Tuesday night "meetings". Want to know about them? You will just have to come and see for yourself. ;-)

//David

IIS7. Product or Platform

Anonymous — Fri, 14 Apr 2006 09:34:00 GMT

IIS has always had an identity crisis. Is it a platform for hosting and building web applications, or is it a web server product?

Well, for the first time in IIS product history (that I am aware of, anyways...), IIS is treated more like a product with a competitive purpose instead of just being the ho-hum infrastructure that everything runs on and everyone depends on, yet no one maintains nor invests in.

Why do I say this?

Well, for one thing, we are actually planning on doing integration with Visual Studio to provide proper wizards and code project templates to allow developers to easily and correctly write modules to extend IIS funnctionality. This includes native code (ISAPI, Global Modules, and Handlers) as well as managed code (Managed Modules and Handlers). Hopefully, this preemptive action avoids debacles like the MFC ISAPI Template as well as establish IIS as a legitimate target for developers to enrich web server functionality.

Wait, it gets better. Not only will you get Visual Studio integration to easily start a project and code templates to help write the extensibilities modules, we will also provide WiX templates to allow you to quickly compile your extensibility modules and configuration into a MSI package and then deploy it to other machines.

Oh, and another random thought... maybe I will join an Open Source project on Source Forge to provide a MSI CustomAction to configure IIS7 for use with WiX. I think lots of people would benefit from that. I have been consulting with Rob and several other WiX contributors on the existing CustomAction for IIS for a while now... ;-)

These are clearly NOT things that a pure-platform play would consider...

Want more visible evidence of IIS acting more like a product? How about putting the crosshairs on Apache? Those of you who attended TechEd 2005 in Orlando probably saw the Penguin in crosshairs T-shirt...

Dare I say it... ONE of the reasons why Apache has a 70% (hmm... it is well under 70% now and progressively dropping every month, according to Netcraft... interesting... no comment ;-) ) market share in host names is due to lack of competition. Microsoft simply has not focused on producing a web server product but rather a platform to support all its other server products.

With IIS6, Microsoft has a web server squarely able to compete (we still have to make up for years of Apache module investments, but there are only a few big ticket items there and most users should be satisfied - like URL Rewriter, Request Forwarder, Virtual Websites, and CustomAuth. It is an embarassingly small lead if you think about it. You see, it is not that we cannot do it; it is that we were never directed / mandated to do it.

Well, all I can say is that it will be interesting to see how this competitive landscape shapes up in the next couple of years as IIS6 gears up and IIS7 gets released.

//David

IIS7. Team Photo

Anonymous — Sat, 08 Apr 2006 10:59:00 GMT

For those of you who enjoy photos and putting faces to names... here is one of the entire IIS7 PM, Development, and Test team.

Fortunately, the weather Thursday afternoon was pretty agreeable, so the picture came out well.

Random Factoids:

For the curious - I am the one in the white mock turtleneck just right of picture center, behind the kneeling Sergei.
This photo is taken with Bill's Nikon digicam (Bill is in grey/green rolled up long sleeved shirt and jeans on the very left)
Yes, the IIS team is representative of the skewed male:female ratio at Microsoft
Eric is holding up a picture of Jaro, who is away on vacation
We wear a lot of jeans

In a future blog entry, I will post an annotated photo with short bio so that you can better put names with faces and IIS7 features.

//David

HTTP.SYS, IIS, and the 100 continue

Anonymous — Wed, 05 Apr 2006 10:20:00 GMT

Question:

Hi David,

"My Company" is a leading middleware provider for mobile multiplayer games. Cutsomer like Disney, THQ etc.

The backend is built on .NET. We went live in the US with W2K3/IIS6 which is great.

But we have a major IIS6 issue. The handsets connect through HTTP/POST and sometimes the Server answers with "100 continue" and this leads to crashes on certain phones.

In IIS5 we wrote an ISAPI filter - which works well.

Question:

1) Is IIS6 sending the "100 continue". We assume yes ... (due to file must exist)

2) Will an ISAPI Extension be able to fullfill this?

I would really apprciate your help.

thanks,

Answer:

Actually, I would frame it differently - this is probably NOT a "major IIS6 issue".

Clients which advertise to be HTTP/1.1 compliant and then crash on "100 continue" are the real problem (they are not following public specifications), and servers that allow such broken clients are also a part of the problem.

Technically, these phones should just keep crashing until the consumer gets sick of it and switches to another phone that works correctly. This is the way to get the phone manufacturers to write/use properly implemented networking protocol stacks - when their customers hit their pocketbooks. As middleware, it should not differ if the consumer uses one phone or another to run your games... as long as the consumer has *A* phone that runs your games.

On the other hand, if the server keeps hacking to work around client-side bugs, the phone manufacturers never get wind of their problems and have ZERO incentive to fix their phones, leading to accumulation of server-side hacks over time that increase server maintenance costs for you.

Thus, it is in your best interest to notify and get phone manufacturers to fix their buggy software.

I understand that business pressures can force you to compromise and otherwise work-around such issues in the spirit of "making things work", but I just want to remind you of the implications of your actions on your long-term interests.

</soapbox>

On Windows Server 2003, it is a cooperation between IIS6 in user mode and HTTP.SYS in kernel mode that drives HTTP request/response serving. Logically speaking:

HTTP.SYS picks up data off the network, parses it into HTTP requests, identifies which Application Pool it belongs, and places it into its queue.
IIS6 user mode worker process picks up requests from the queue of its Application Pool, processes each by running either a user-supplied ISAPI/CGI or the built-in IIS Static File Handler, and hands the response back to HTTP.SYS to send over the wire.

A "100 continue", like a "400 Bad Request" or a Kernel Response Cache Hit, is special in that HTTP.SYS transparently handles it in kernel mode without notifying user mode of anything. In addition, ISAPI Extensions cannot interact with any response output - they can only generate response output, not see results of response output. Thus, an ISAPI Extension will never be able to interact with requests that generate "100 continue" nor "100 continue" responses themselves to suppress them.

On IIS6, the only way to inject user mode processing into these transparent request handlings of HTTP.SYS is to run in IIS5 Compatibility Mode and use an ReadRawData/SendRawData ISAPI Filter. ReadRawData forces HTTP.SYS to hand the raw data off the network into user mode for filtering PRIOR to parsing that user mode output into HTTP requests to place into queues.

Of course, this method completely defeats the purpose of running IIS6 with Application Pools and process isolation (a single failure in this filtering user mode process halts the entire server)... but such is the server-side compromise when the client is buggy...

FYI: This approach will not work on Vista Server/IIS7. HTTP.SYS will no longer hand raw data off the network into user mode for filtering prior to parsing, so it will be impossible for user mode code to know that a request which triggers the automatic "100 continue" happened.

//David

HOWTO: Install and run PHP on IIS7

Anonymous — Tue, 04 Apr 2006 12:56:00 GMT

Question:

Hi all,

I have trouble to configure PHP 5 (CGI mode) in IIS 7 on Vista 5308...

What I did:
- Download and unpack PHP
- set user permission to PHP folder AND script folder (IIS_IUSRS and Internet Guest Account)
- in IIS Manager: Added pages in Default documents
- Added in "ISAPI and GCI Restrictions": Allowed PHP group ID PHP path c:\php\php-cgi.exe
- Added in "Global Modules" PHP as integratedmode path c:\php\php-cgi.exe
- Added in "Handler" PHP to map *.php,*.php3 type:File path c:\php\php-cgi.exe all verb handler:cgimodule
- Added in "module": PHP code:c:\php\php-cgi.exe module:native entry:local

Answer:

Unfortunately, at this point in the beta cycle, IIS7 configuration failures are still cryptic, so you basically need to really know what you are configuring. However, most things are conceptually the same as prior IIS versions - just maybe named/organized or configured differently.

For many reasons, I do not use the UI nor give instructions for the UI (except if explicitly talking about a UI-behavior), so all my instructions directly manipulate the necessary .config files with the right values to generate the desired behavior.

The UI is still under development and can change from build to build, including introduce bugs. A UI bug should not prevent you from using server features.
The server behavior (and hence configuration) rarely changes. The UI surrounding it may change in response to concepts/feedback, so UI-based instructions can be out-of-date, especially during beta.
I want to illustrate how to configure and use IIS, not how to use the UI to generate the necessary configuration.

In your case, you basically chose to configure all possible locations, but that is not all correct and thus IIS7 will mysteriously fail. In particular, configuring PHP as a "Global Module" or "Module" is incorrect.

Instructions

This is all you should do (and why):

Install PHP into %SYSTEMDRIVE%\Inetpub\PHP (I want to easily inherit any IIS7-related ACLs)
Download and unpack PHP into %SYSTEMDRIVE%\Inetpub\PHP (For this example, I chose the latest currently available build, PHP 5.1.2 ZIP package, from http://www.php.net/downloads.php )
Use the recommended PHP.INI-Recommended INI file inside the PHP directory (or whatever PHP configuration you need)
Configure a Handler for *.php using %SYSTEMDRIVE%\Inetpub\PHP\PHP5ISAPI.DLL or %SYSTEMDRIVE%\Inetpub\PHP\PHP-CGI.EXE (I prefer the ISAPI version on IIS) and order the Handler AHEAD of the StaticFile Handler
Configure an ISAPI and CGI Restrictions entry to enable the added Handler for PHP

This is all you need to do. Conceptually, it is not any different than prior IIS versions, like IIS6, and the necessary data is pretty much the same. The only difference is that you are configuring a Handler instead of an Application Mapping. This is because we have reconciled the IIS Application Mapping with the ASP.Net httpHandlers (as well as many other things, such as ISAPI Filters and httpModules) to form the new IIS7 Integrated Pipeline. The new unified section is called "handlers".

The Details

The astute Reader should note that it is important to place the PHP Handler ahead of the StaticFile Handler. Why?

Unlike the IIS Application Mapping list, which is unordered, the Handlers list is ordered. This means:

For Application Mappings prior to IIS7, we chose to have arbitrary behavior of wildcard application mappings always run first to handle a request, and if unhandled, then the first Application mapping with a matching extension is executed).
For Handlers in IIS7, we chose to have first-match (of extension/verb) wins. This gives user complete control over Handler resolution order; no arbitrary ordering imposed by IIS core.

In other words, you can configure IIS7 Handlers to act like pre-IIS7 Application Mappings by doing the following (conceptual). Note that IIS6 hardcodes the ordering of WildcardApplicationMappings and StaticFileModule to be first and last, respectively... while IIS7 allows you to order the Handlers however you want:

Of course, with power comes responsibility. With such a flexible system, it means that the StaticFile Handler, which maps to all extensions and all verbs, must be configured last so that it is the Handler of last resort after all other Handlers fail to match. This means that any added handlers must be ahead of the "wildcard" handlers since otherwise the wildcard handler will get picked first.

Instructions (Automation)

Ok, suppose the Instructions weren't clear enough. Here is the commandline version of the above instructions. :-)

MKDIR %SYSTEMDRIVE%\Inetpub\PHP
ECHO Extract PHP files from ZIP archive into %SYSTEMDRIVE%\Inetpub\PHP
COPY /Y %SYSTEMDRIVE%\Inetpub\PHP\PHP.INI-Recommended %SYSTEMDRIVE%\Inetpub\PHP\PHP.INI
PUSHD %SYSTEMROOT%\System32\inetsrv
APPCMD SET CONFIG -section:handlers -+[name='PHP',path='*.php',verb='GET,HEAD,POST',modules='IsapiModule',scriptProcessor='%SYSTEMDRIVE%\Inetpub\PHP\php5isapi.dll',resourceType='File']
APPCMD SET CONFIG -section:isapiCgiRestriction -+[path='%SYSTEMDRIVE%\Inetpub\PHP\php5isapi.dll',allowed='true',groupId='PHP',description='PHP5']
POPD

Yes, I am using the new APPCMD commandline tool for manipulating IIS7 configuration to make scriptable changes. You can view it as the IIS7 uber-replacement for adsutil.vbs and all of the IIS6 commandline tools. Bear with the cryptic syntax for the moment - it is really quite handy once you get past the syntax (especially the syntax for collection manipulation - I can spend a blog entry just talking about it alone ;-) ).

Conclusion

The above instructions are all the IIS-specific steps necessary to get PHP to work on IIS7. I was able to run a PHP page containing <?php phpinfo();?> after making just those changes on top of a default IIS7 installation. If you still have problems, it is most likely coming from PHP itself.

For example, php-cgi.exe does not seem to work because its CGI output is missing the Status: field as required by CGI 1.1 specification.

[Modified 4-4-2006] php-cgi.exe does work on IIS7. You need to modify PHP.INI to have the line:

cgi.force_redirect = 0

If you do not do this modification, PHP-CGI.EXE outputs a security warning response without proper response headers, which causes IIS to return a 502 Bad Gateway. Strangely, running PHP-CGI.EXE from the commandline does not generate this error - I guess using NPH CGI is the only way to debug PHP, because running it from the commandline is not 100% indicative of web-server Runtime behavior.

[Modified 6-14-2006] Removed the following lines of batch script to work-around of APPCMD manipulation of StaticFile module since the bug got fixed.

APPCMD SET CONFIG -section:handlers --[name='StaticFile',path='*',verb='*']
APPCMD SET CONFIG -section:handlers -+[name='StaticFile',path='*',verb='*',modules='StaticFileModule,DefaultDocumentModule,DirectoryListingModule',resourceType='Either',requireAccess='Read']

[Modified 6-24-2006] Linked to newer instructions here.

//David

IIS7. Availability

Anonymous — Fri, 24 Mar 2006 13:30:00 GMT

Question:

Mr. Wang,

I have not been able to find a concrete answer for this anywhere:

I'm looking to start working with IIS 7.0 and especially Windows Activation Service. Is there a way to do this without a Longhorn Server build? Are there implementations of IIS 7.0 beta or WAS that work on previous server releases (Win 2K3, etc.)? I don't think this is the case, but it seems like you'd be a good person to give a definitive on that.

And if I'm right about needing Longhorn Server builds, do you know when there will be a public (MSDN) beta available?

Thanks a lot for your help.

Answer:

The latest that I have heard - IIS 7 will only be available with Windows Vista, all SKUs. Yes, including Home and Professional SKUs.

Yes, we heard your requirements about having the same server on Professional and Server SKUs so that your developers can accurately target the server with their workstations. Believe me, we tried several times to get IIS6 into XP Professional, but we were shot down every time by Windows management for various random reasons, none relating to your usage requirements (apparently, customer satisfaction is not the top criteria for Windows release management, but hey, what do I know...).

Our only solace is that XP Professional x64 Edition DOES have IIS6... and WOW64 32bit compatibility mode is there... so if you are thinking ahead and buying x64 machines... your best bet is to install XP Professional x64 so that your developers can natively target IIS6. Add Visual Studio x64 Edition (Express SKUs are free, including x64) and Virtual Server 2005 R2 x64 Edition ($99), and you have one cheap but powerful development platform able to target and test against all Windows Server platforms including IIS6, as well as stay abreast of Windows Vista and IIS7 developments. What more do you need?

Now, those of you at TechEd 2005 Orlando may recall seeing in the Product Pavillion a Virtual Machine of IIS7 pre-Vista Beta 1 binaries running on Windows Server 2003 SP1, but sorry, that is a pre-release demo I had to create for TechEd, and it no longer exists. Many things have subsequently developed and changed to the point that it will impossible to install, let alone run IIS7 downlevel. And we have no plans to ship IIS7 downlevel, either (for certain, there is no testing of IIS7 downlevel). Read what you will from these statements...

As for availability of the next public Windows Vista beta - I really have no more information about it than you can legally obtain. I am in the product team, so I do not care about those nebulous things called "milestone dates". I just care about what features get into what product as a ship vehicle. :-)

All I know is that Vista Beta 2 will be when you first see IIS7 in a broadly available Windows beta. I have heard of various people getting interim beta builds as a part of CTP and any deeper engagements, etc, but that is Windows-specific. I have also heard rumblings of an IIS-specific program to provide access to interim IIS7 beta builds to solicit user testing and feedback - but I have not seen anything concrete materializing. You want to ping Brett Hill and Chris Adams about this... but you can be sure that I will certainly blog about this iff/when I know it to be real.

//David

On IIS Team Blogging, Part 2

Anonymous — Mon, 20 Mar 2006 09:58:00 GMT

Back in this blog entry, I mused about how nice it would be to have more bloggers from the IIS product team. One thing is for certain - the IIS team traditionally has never dialed up the volume when it comes to evangelizing what we are doing and its importance as the foundation of the entire Microsoft web platform. We tend to be treated like a cog that has to keep turning and no one notices it until it stops turning. :-P Yes, I know that Atlas is sexy and so is ASP.Net, but they go no where without some basic support from IIS and Windows.

Anyways, I got wind of some new IIS Bloggers coming... people who actually have review commitments to blog. Some have queried me quite a bit about how to approach blogging, so of course I gave them the summary of what I have concluded. I told them:

Have a target audience in mind and write to it. Like a TV channel, do not try to appeal to everyone because you end up appealing to no one.
Have a "point" and stick to it. Like a TV show, people naturally gravitate towards the type of material they like. Your audience will gather, so do not change your point to chase after the audience. You have a target audience in mind, remember?
Blog often. If the content is not fresh or active, neither is your audience. This is not MSDN.

Of course, lately I have been pushing at the boundaries of the second "point" quite a bit by trying a variety of blog topics (like the Office Move, Lumiere, Blog Upgrade)... which bring in more of the human factors but still remain within myself and audience. As I see it, this is just an extension of an original goal... disseminating information about IIS as well as the people/process/circumstances around building IIS can be interesting. Hey, it certainly lightens things up a bit more for me. :-) You can tell me whether you want more or less of that, of course.

Hopefully in the near future, these new IIS bloggers will start and tell me about it so that I can link them in... and give them a good greeting. :-) Hehe... I'll just put them on the spot by giving names, job role, and short personal blurb:

Bill Staples, product unit manager for IIS. He's charged with shipping IIS7, amongst other things.
Dave Cox, test lead. He owns IIS7 Configuration, Stress, and Administration (excluding UI). He also has a lot of context on WebDAV and IIS6/UNC having owned those areas in IIS6.
Oscar Omar Garza Santos, program manager. He owns IIS7 Configuration, Administration, and other loose ends. He can explain.

Unfortunately, I still cannot get a IIS developer to start a blog. They have quite the story to tell if they would only write it all down. I have some candidates in mind, but I won't bug them now; they are already crazy with developing features and fixing bugs.

//David

IIS7. PreConditions and the Integrated Pipeline

Anonymous — Sun, 19 Mar 2006 09:55:00 GMT

One of the cooler but definitely unsung feature of the IIS7 Server Core is PreConditions. So, that's what I am going to talk about... yup, I am exploring the little, non-obvious details that is IIS7.

What is a PreCondition

The basic idea of PreConditions is for a piece of code to run very early-on in request processing, quickly calculate "answers" to some "questions", and allow IIS to conditionalize subsequent request processing based on those answers. Ideally, the user expresses conditions via configuration and not programmatic manipulation, allowing the user to make powerful changes to server behavior without writing code.

PreCondition calculation happens very early on in request processing, after the user-mode worker process picks up the request from an HTTP.SYS Request Queue but before real request processing begins. Real request processing includes things like:

Calculating the effective URL (remember, ISAPI Filters listening to SF_NOTIFY_PREPROC_HEADERS to change effective URL, as can PreBeginRequest Modules)
Loading relevant metadata based on the URL (such as what modules are enabled and what handlers are available for the request)
And finally driving the request pipeline, notifying modules of events, and responding to module actions and return values

But what is a PreCondition, Really?

So... you have an inkling of an idea about this "PreCondition" thing and hear that it allows the user to make powerful changes to server behavior, but the same can be said of pulling out the Server's power cord... ;-) so what distinguishes between the two? Enough on the motivations and high-level architectural discussions and get to the concrete details and examples, you say? Alright, here's the details (of course, dated and subject to RTM change)...

IIS7 Server Core allows preConditions to be defined on the following entities:

globalModules
modules
handlers
isapiFilters

IIS7 Server Core allows the following groups of values for preConditions:

Process Bitness: bitness32, bitness64
Managed Extensibility Style: integratedMode, ISAPIMode
.NET Framework Version: runtimeVersionv1.1, runtimeVersionv2.0
Managed Code Execution: managedHandler

For example, if you assign the bitness32 preCondition to a globalModule (see this blog entry on why it is only native code), IIS will load that DLL only if the worker process is in WOW64 (32bit emulation) mode on a 64bit OS. Similarly, you can assign the managedHandler preCondition to a module to make it applicable only for "managed code" requests like .ASPX pages and NOT apply for "non-managed" requests like .GIF.

In all cases, there is exactly ONE server configuration file and list to manage, but it expresses a rich set of configurations and server behavior.

Why preConditions?

Ok, I probably lost everybody by now or you are wondering "why does this preCondition thing exist?" ;-) ... so let me just explain what they are good for and you can judge for yourself.

Process Bitness

A major problem with IIS6, 64bit Windows, and WOW64 is that exactly one configuration is used by IIS to load DLLs used for both native 64bit as well as WOW64 32bit modes, while 64bit Windows requires DLLs to match the bitness of the process they load in.

Thus, if you configure ISAPI Filters or ISAPI Extensions (through [Wildcard] Application Mappings) and the bitness of the DLL does not match the bitness of the worker process (which only works if your file is located in a directory with WOW64 FileSystem Redirection enabled [basically just the Windows System32 folder]), you will see problems when you toggle IIS6 to launch worker process from 32bit to 64bit mode or vice versa.

For examples of the complexities and user confusion, see the following blog entries:

The bitness32 and bitness64 preConditions neatly solve this problem by allowing one configuration to express via preCondition: "these DLLs are 32bit, and those DLLs are 64bit, so only load the 32bit DLLs for a 32bit worker process in WOW64 and 64bit DLLs for a 64bit worker process." Of course, the user is still responsible for defining the preCondition to take advantage of it, but IIS7 comes with many of them pre-defined so examples of proper usage should be easy to find.

Managed Extensibility Style

The deep, high-fidelity, highly-functional, yet highly-performant integration of managed code into core server extensibility illustrates one of the major advances in IIS7 - you can fully extend IIS7 with managed code in Integrated Mode*, while ISAPI Mode represents the partial integration possible with IIS6 and ASP.Net 2.0.

However, we are aware that not everyone nor every ASP.Net application is ready to make this jump, so we have the integratedMode and ISAPIMode preConditions to allow:

Application Pool to specify whether it is running managed code applications in Integrated Mode or ISAPI Mode
Handlers to specify whether it should run for requests in Integrated Mode or ISAPI Mode

The integratedMode and ISAPIMode preConditions allow you to control your migration of ASP.Net applications from ISAPI Mode to Integrated Mode and do so in a partial fashion within exactly one configuration section... so you CAN have your cake and eat it, too.

* Almost true. You cannot have managed global modules, but you are not missing out on much.

.NET Framework Version

By now, we should all know about the .NET Framework versioning problem. See this blog entry for a refresher.

Since we cannot run .Net Framework 1.1 and .Net Framework 2.0, yet for compatibility reasons their respective handlers are configured in the unified <handlers> section, how do we:

Maintain one single <handlers> section as the place to configure all request handlers
Conditionally load different managed handlers based on framework version
Tie it all to different Application Pools (necessary for process isolation to support .Net Framework versioning)

Yup, you guessed it - the runtimeVersionv1.1 and runtimeVersionv2.0 preConditions.

Managed Code Execution

While IIS7 offers great programmability and extensibility by managed code, there are always situations that require pure native code speed. How do you make sure that requests that do not involve managed code for processing stay "native", yet simultaneously allow requests that leverage managed code features?

That is the problem that the managedHandler preCondition solves. It basically identifies "this module uses managed code, so if the request is not already serviced by managed code, do not use the module".

For example, even though IIS7 comes predefined with managed modules performing ASP.Net Forms Authentication, by default they have the managedHandler preCondition and only apply to managed resources and not static resources like .GIF.

This allows a single unified <modules> list to give pure native performance for .GIF files while simultaneously allowing Forms Authentication to be enabled for other managed resources. And all you need to do to have managed modules apply to all requests is to simply remove the managedHandler preCondition for that module.

Prior to IIS7, you had to shotgun a wildcard application mapping for ASPNET_ISAPI.DLL to do this. You no longer want to do this on IIS7 - just run in Integrated Mode and add/remove managedHandler your way to include/exclude managed code from IIS request processing.

Conclusion

Whew. Thanks for making it this far. I think I probably lost just about everyone with this topic. :-)

But, even if this entry was just blah blah blah IIS7 blah blah blah preConditions blah blah blah, just remember that:

preCondition is a cool "man behind the curtains" technology that make a lot of things work automatically and elegantly.

IIS7... It's Everywhere You Want to Be.

//David

Have you seen a WebEngine.dll crash with ASP.Net 2.0? Read This...

Anonymous — Thu, 16 Mar 2006 14:55:00 GMT

Lately, I have received quite a few comments concerning a crash in WebEngine.dll when you recycle an application pool running ASP.Net 2.0.

The sheer number of independent users reporting this makes be believe that it is real. If it was individual users, I would think user hallucination (strangely, many users are very good at doing this... ;-) ), but when it comes with numbers and stack traces, I believe it and not mass hysteria.

However, I have yet to reproduce it myself given the provided instructions. One user said that merely making a request to an ASP.Net 2.0 page and then manual recycling the application pool should trigger the event... but that did not happen for me. Some have said that Sharepoint is involved; others see it without Sharepoint; I could not get either to work. The variations go on and on.

My Ask...

At the moment, I am a little short on bandwidth to figure out exactly what sequence results in the crash, so I am asking for some help in coming up with a reliable sequence of instructions that allow anyone to reproduce this crash. Be as detailed as possible. Start from when the OS is installed if you can - the more details of installation steps and in particular any non-default configuration changes (such as joining a domain, installing an application, running anti-virus, running login/configuration scripts, etc), the better. You want reliable, reproducible instructions because that allows a bug to be filed to the right developer to get it fixed.

What does this have to do with IIS7?

Now, the astute reader is probably wondering what ASP.Net 2.0 on IIS6 has anything to do with IIS7, so first let me give a little history of WebEngine.dll...

WebEngine.dll is a native code DLL which ships with ASP.Net 2.0 but also provides the managed code extensibility in IIS7. How it works is basically this:

When used by ASP.Net 2.0/IIS6, Application Mappings of aspnet_isapi.dll funnel requests to ASP.Net, and aspnet_isapi.dll is simply a thin shim that calls into WebEngine.dll to create the AppDomains and drives the ASP.Net request pipeline.
When used by IIS7, WebEngine.dll is loaded directly as a global module (native code only - see this blog entry for details) to create AppDomains, and it hooks directly into the IIS7 Integrated request Pipeline to provide managed code extensibility as the IIS7 request pipeline is driven.

Since IIS7 is in Windows Vista, and it comes with .Net Framework 2.0, it means that we had to get a foothold for our IIS7-related managed code extensibility and ship it with .Net Framework 2.0 ... which is why you see WebEngine.dll with ASP.Net 2.0 on IIS6 NOW instead of when IIS7 ships with Vista.

Of course, WebEngine.dll is not supposed to crash... and since its primary purpose is for IIS7, I am very interested in determining the cause because it may be an IIS7/Vista issue as well. The association of WebEngine.dll with an yet-to-ship product under active development (IIS7) instead of an already-shipped product under sustained engineering (ASP.Net 2.0) is what will make fixes in it happen faster.

So, if you are seeing crashes in WebEngine.dll with ASP.Net 2.0 NOW, I want to know about it. And if you can provide clear, reliable instructions for reproducing the crash, I thank you ahead of time for improving the quality of ASP.Net 2.0 and IIS7. And you should also thank yourself for getting a pesky issue fixed!

//David

IIS7. Installation instructions for Vista Beta 2

Anonymous — Thu, 16 Mar 2006 09:53:00 GMT

Since IIS7 is not enabled nor installed by default on Vista (just like IIS6 is not enabled nor installed by default on Windows Server 2003 and Windows XP 64bit), and the various UI/Wizard/ControlPanel-mechanisms for managing components in Vista are not exactly ready for prime time (all are completely rewritten for Vista), I thought I should share the mechanism that the IIS team uses to install/develop/test IIS7.

BTW, this is the only mechanism that I can assure you that works because we run it every day and assure it works as we merge our code changes on towards the WinMain branch which produces the beta/product builds that you get.

start /w pkgmgr /l:log.etw /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect;IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility;IIS-ASP;IIS-CGI;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;IIS-ODBCLogging;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication;IIS-IISCertificateMappingAuthentication;IIS-URLAuthorization;IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-WebServerManagementTools;IIS-ManagementConsole;IIS-ManagementScriptingTools;IIS-ManagementService;IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;IIS-LegacyScripts;IIS-LegacySnapIn;IIS-FTPPublishingService;IIS-FTPServer;IIS-FTPManagement;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI

Yes, I know it is long. It installs all IIS7 components.

You can pick a smaller set, but then I cannot assure you that it works nor that uninstall/upgrade works. In fact, let me just say that you should not try upgrades nor partial uninstallations. It does not work reliably (yet), and we know that already.

This command should work for Vista builds greater than 5266, though I recommend builds 5308 or later of Beta 2. We changed the names of several IIS Components in between those times for consistency purposes - this command represents the latest agreed-upon names.

//David

Office Move 2006, Part 2

Anonymous — Wed, 22 Feb 2006 04:30:00 GMT

I finally got around to setting up and re-arranging my office after the completion of the Office Move. Like Wade, I spend the extra time and effort to disassemble all wires of my computers prior to moving and reassemble them myself after the move. My main reasons for doing this?

I want to be responsible for how my machines are wired. One of the worst feelings is to have a kernel debugger misconfigured following a move and waste time figuring out what happened in the middle of a debugging session
I re-optimize my wiring depending on the location of the power/networking jacks as well as machine placement. Usually, I decide on a machine layout after seeing them in the new office, so I will likely undo any existing wiring efforts done by the movers... might as well do it myself

In other words, I am just picky when it comes to my machines and how they are arranged. :-)

Well, this time I remembered to take pictures of my new office after I finished wiring everything up.

As you can see, I do not like clutter and highly value clean, contiguous space, so I basically stashed all my computers into one corner of the office so that I can have an entire wall of just whiteboards.

And another nice thing with this particular office's layout is that I can stash my old move boxes (which accumulate every time I move offices) into a recessed area so that I do not need to unpack them. Out of sight, out of mind. :-)

Yes, there is a little stuffed radioactive-green frog lounging across the top of my LCDs.

//David