David Wang

Question:

Answer:

This is an often asked question and point of confusion. I will clarify the terms from an IIS perspective.

What's in a Name?

The generic terms "web application", "virtual directory", "virtual server", and "web site" are inconsistently defined between servers/applications/platforms, so you have to understand the term's meaning in each server/application/platform and translate appropriately. In fact, even Microsoft products do not standardize on a common meaning for those terms, and due to historical legacy of each product, they will likely never change, converge, nor standardize. Sigh.

For example, a Sharepoint "Virtual Server" is the same as an IIS "Web Site" and not to be confused with Microsoft's "Virtual Server" virtualization platform, which hosts virtual machines - who themselves can end up hosting Sharepoint Virtual Servers aka IIS Web Sites. Confused yet? Good. :-)

IIS's terminology does not include the term "Virtual Server". When most people talk about "Virtual Server" they are often thinking of an IIS Web Site, or something that answers HTTP requests to host their logical website, which consists of a single application codebase.

Web Site

An IIS Web Site is a mapping between a <IP:Port:Hostname> Binding triplet and a "root" Web Application (defined shortly) that responds to "/". The Web Site is how IIS figures out whether it should handle any given HTTP request and if so, with what configuration. Since this determination directly affects how a HTTP request is handled, all Binding definitions MUST be unique on a IIS machine. You do not want two Web Sites potentially fighting over the same request, right? Now, the Binding triplet is different than the "Friendly Name", which is an optional string meant for User's identification benefit. It can be "Default Web Site" or anything else, and since it is optional and not used for request handling determination, it can be duplicate or not defined.

For example, suppose you have the following Web Sites with the following Binding triplets. This is what each means:

1. :80: - across all IPs of all NICs, handle port 80 traffic, regardless of Host header
2. 12.34.56.78:443 - only requests to IP 12.34.56.67 on port 443
3. :80:Domain2.com - across all IPs of all NICs, handle port 80 traffic for requests with Host header of Domain2.com

With this configuration, when IIS receives any request, it knows from TCP/IP which IP:Port the request is meant for, and if the data is unencrypted, it can decipher the Host: header, and with these three pieces of information, it can determine if it matches any Web Site's Binding definition (or none) and route/handle accordingly. If it matches nothing, a "400 Bad Request" response is returned.

SSL Host Header (sidetrack)

At this point, I will briefly digress on another topic, SSL Host Headers.

Technically, there is no such thing as SSL Host Header. From the perspective of the SSL Specification, host headers do not exist because they are defined in the HTTP specification and not TCP where SSL operates.

When IIS receives any request, it only knows the IP:Port that request is destined for. In order to determine the Host header of a request, IIS must decipher the request's payload data. And to do that for an SSL request, IIS has to first decrypt the payload data by using a Server Certificate to complete the SSL handshake with the Client. However, IIS needs to know the Host header in order to know which Binding, and hence which Server Certificate, to use to decrypt the payload data and decipher the Host header. This is clearly a Catch-22.

So, how does IIS implement "SSL Host Headers"? It breaks the Catch-22 by requiring all sites using SSL Host Headers for a given Binding must be configured to use the same Server Certificate. That way, when IIS gets a IP:Port of a request, it can unambiguously use that now-synchronized Server Certificate to first decrypt the Host: header, and THEN decide which Web Site matches the IP:Port:Host Binding and route the request to it.

Web Application

A Web Application is a mapping between a name in the virtual namespace (i.e. the URLs "/", "/App", or "/cgi-bin") and its runtime properties. These runtime properties tell IIS how to execute a request which belongs in the virtual namespace. Common runtime properties include:

• Whether user's application code is to be executed "In Process", "Out of Process", or "Pooled" [for IIS 4/5/5.1/6 in IIS5 Compatibility Mode] or specific Application Pood ID [for IIS6 in Worker Process Isolation Mode and IIS7]
• Process Identity used to execute program code
• Monitoring/Recycling Metrics
• etc...

By default, whenever you create a Web Site and define the Binding (and optionally the Friendly Name), IIS also creates a "root" Web Application for "/" and asks you for a Virtual Directory mapping (defined shortly). This is because people commonly create a Web Site to host a Web Application which consists of files located at same physical directory, so defining all three features make sense... but the three concepts are definitely different.

Virtual Directory

A Virtual Directory is a mapping between a name in the virtual namespace (i.e. the URLs "/", "/App", or "/cgi-bin") and a corresponding physical name (i.e. the Filesystem name "C:\inetpub\wwwroot\App"). It allows IIS to calculate a physical resource name for any given virtual name and provide it to the handler of the request.

For example, suppose "/" maps to the physical name "C:\inetpub\wwwroot". A request for "/default.asp" refers to the physical name "C:\inetpub\wwwroot\default.asp".

The astute reader should realize that the mapping provided by a Virtual Directory is merely a "recommendation" by IIS to the request's handler - the actual handler of a request can do whatever mapping it wants with the virtual and physical names provided.

In the case of /default.asp, IIS first goes through this process to figure out the handler. Suppose it ends up being ASP.DLL - it will honor the physical name C:\inetpub\wwwroot\default.asp and execute the script contained within it to generate a response.

However, the handler or its script code can choose to implement its own name mapping scheme to process a given request. For example, some people write ASP pages like "redir.asp" which return different responses based on template HTML stored within a SQL database depending on the querystring. i.e. /redir.asp?id=1 will load up some template HTML in SQL and generate a HTML response. Clearly, Virtual Directory is only a hint/recommendation provided by IIS to the request handler, which can do whatever it wants with the information.

Conclusion

Given the above information, the answers to your questions are straight forward.

A plain Virtual Directory provides a virtual/physical name mapping and MUST inherit and use the runtime settings defined at its nearest parent to execute code contained within it.

A Virtual Directory that is also a Web Application has the option to inherit from its nearest parent AND customize runtime settings to execute code contained within it.

Clearly, if you do not customize runtime settings, then it is not necessary to create a Web Application. And if you create a Web Application and customize runtime settings, then behavior of code execution may be different than a plain Virtual Directory (assuming that the inherited settings by the Virtual Directory do not match the customized settings of the Web Application).

As for differences between a "root" Web Application and a nested Web Application within another Web Application or Virtual Directory. IIS does not treat them differently since Web Applications are just runtime settings. However, application platforms running on top of IIS may choose to interpret the "application root" of an Web Application differently and behave accordingly. For example, ASP.Net uses "Web Application" to delimit the boundaries of its applications, so if you nest a Web Application within another, you end up with two different ASP.Net Web Applications.

//David

Question:

Answer:

Technically, preConditions only apply on a per-GlobalModule, per-Module, per-Handler, or per-ISAPI Filter basis. This is because globalModules, modules, handlers, and ISAPI Filters have to be explicitly configured within IIS to function. ISAPI Extensions simply need to be dropped into a web-accessible folder and then "allowed to execute" via Executable execution permission and IsapiCgiRestriction. There is no per-ISAPI Extension configuration to stick preConditions.

However, as I will illustrate shortly, it is STILL possible to apply preConditions on a per-ISAPI Extension basis in a fairly clean and clear manner.

Some people would propose that it would be nice to stick preCondition onto IsapiCgiRestriction since it is a sort of per-ISAPI Extension configuration, but IsapiCgiRestriction is really a security configuration which we hardly want to preCondition. Besides, what happens if notListedIsapisAllowed="true" and we still want to preCondition an ISAPI Extension - now we have to add a bogus entry for preCondition? Anyways, this is getting complicated very quickly, a sure sign that the proposed design has some fundamental logical flaw.

Common Misconceptions about Bitness and preConditions 

Now, before I get into how to setup per-ISAPI Extension preCondition, I want to clarify some of the misconceptions in your question about Bitness and preCondition. Using preCondition="bitness64" does NOT:

1. Explicitly load an ISAPI Extension as x64 module
2. Make an ISAPI work no matter what the application pool is configured for
3. Allow "both x64 and x86" of ANYTHING

A preCondition is a simple filtering mechanism on the affected IIS configuration. What preCondition="bitness64" means is that the affected configuration is ONLY applicable in a 64bit Application Pool. A 64bit Application Pool will only see globalModule, module, handler, and isapiFilter with either bitness64 or no bitness preCondition. It will not see any globalModule, module, handler, and isapiFilter configuration with the bitness32 preCondition.

Thus, a preCondition does NOT cause an ISAPI to be explicitly loaded as any bitness. LoadLibrary() will just load the resolved DLL name into the process's address space, and if the bitness do not match, fail. Likewise, it cannot make the ISAPI work no matter what, because if the bitness does not match, it fails. Finally, Windows does not allow both 32bit and 64bit code to co-exist in the same process, and IIS does not allow an Application Pool to be both 32bit and 64bit.

What is a correct way to use the bitness preConditions? Check out the various pre-defined "-64" handlers when ASP.Net Feature support is installed. For example, the svc-ISAPI-2.0 and svc-ISAPI-2.0-64 handlers. Notice that the bitness32 preCondition applies to a 32bit ISAPI, and bitness64 preCondition applies to a separate 64bit ISAPI. This dual configuration allows the same feature to work with both 32bit and 64bit Application Pools with no additional configurations changes in-between. Remember how you had to run aspnet_regiis.exe from the correct Framework bitness directory every time you changed Application Pool bitness with .Net Framework 2.0 on IIS6 in 64bit Windows, or else you would see 503 Service Unavailable failure? No longer necessary with preConditions on IIS7 and things just work!

PreConditioning an ISAPI Extension DLL

As I mentioned earlier, per-ISAPI Extension preCondition can be accomplished by leveraging preCondition support of handlers. The following configuration shows how to request an ISAPI Extension name "MyISAPI.dll" and have it work no matter the bitness of the Application Pool. It requires a 32bit version and 64bit version of the same DLL, named MyISAPI32.dll and MyISAPI64.dll, respectively.

<handlers>
  ...
  <add name="MyISAPI-64" path="MyISAPI.dll" verb="*" modules="IsapiModule" scriptProcessor="C:\inetpub\wwwroot\bin\MyISAPI64.dll" resourceType="File" requireAccess="Execute" preCondition="bitness64" />
  <add name="MyISAPI-32" path="MyISAPI.dll" verb="*" modules="IsapiModule" scriptProcessor="C:\inetpub\wwwroot\bin\MyISAPI32.dll" resourceType="File" requireAccess="Execute" preCondition="bitness32" />
  ...
</handlers>

Looking at the key configuration details:

• Having two handlers, one with bitness32 preCondition on the 32bit MyISAPI32.dll, the other with bitness64 preCondition on the 64bit MyISAPI64.dll, assures that only one of these handlers with the correct bitness apply to any given Application Pool
• path="MyISAPI.dll" means that end consumers only request /MyISAPI.dll while the dynamic 32/64bit wiring happens underneath the covers via the bitness preCondition
• requireAccess="Execute" makes Execute permissions necessary to execute an ISAPI Extension DLL in a given URL namespace

The combination of preConditions, path-remapping, and requireAccess gives the illusion of a single named ISAPI DLL which transparently works with similar requirements as ISAPI Extension regardless of Application Pool bitness. Yes, don't forget to set IsapiCgiRestriction on both MyISAPI64.dll and MyISAPI32.dll as well as enable "Execute" permission on your virtual directory... :-)

Cheers.

//David

Question:

Answer:

Source and Read permissions control different behaviors.

Read permission controls whether the IIS Static File Handler allows the requested resource to be retrieved (i.e. read) as the response. This action is subject to all behaviors of the IIS Static File Handler, including the MIME Type check.

Source permission, when WebDAV functionality is present (i.e. installed/enabled), controls what happens when the request has the Translate: header. The logic looks like:

If Translate:f AND "Source" is enabled Then
    // Handle with Static File Handler
Else
    // Continue processing normally
End If

Thus, the interesting combination for "Source" happens when:

Question:

Answer:

The answer really depends on the filter events that the ISAPI Filter subscribes to.

Unfortunately, no built-in IIS UI or tool displays this information since it is rarely of interest to the user.

However, you can use my tool from here to view the events that an ISAPI Filter subscribes for. To the astute reader - this filter status information is only available AFTER IIS successfully loads an ISAPI Filter (i.e. IIS successfully LoadLibrary(), GetProcAddress() the Filter DLL's GetFilterVersion() exported function, executes it for registered events, and the function returns TRUE to IIS), and depending on IIS version/mode and the type of ISAPI Filter, IIS ends up loading an ISAPI Filter at different times. The history and rationale behind the differences is an entire blog entry all to itself, but the following table is a sufficient summary for now:

It's all about Timing

Now, you may wonder WHY knowing the subscribed filter events affect the answer. As in life and most things in our four dimensional world, it's all about timing, and this situation is no exception.

ISAPI Filter triggers on various events fired by IIS throughout a request's processing, while Managed Modules trigger after only one of those events (and in IIS7 in Integrated Pipeline Mode, Managed Modules trigger on ALMOST all of the events). Thus, if you want the Managed Module to run before the ISAPI Filter, the ISAPI Filter's subscribed events must be limited to those that happen AFTER the Module triggers.

Since Modules trigger pretty late in the request processing, right before response generation and logging, and ISAPI Filters typically trigger early in the request process, to perform either custom authentication, URL rewriting, etc, it is highly likely that what you want to do is impossible on any IIS version - without knowing the exact filter events involved, I cannot be definitive.

The following is a condensed outline of how ISAPI Filter and Managed Modules triggering are ordered:

• On IIS4, IIS5, IIS5.1, and IIS6, Managed Modules trigger between the SF_NOTIFY_AUTH_COMPLETE and SF_NOTIFY_SEND_RESPONSE filter events.
• On IIS7 in Classic Pipeline Mode, things behave as in IIS6.
• On IIS7 in Integrated Pipeline Mode, Managed Modules trigger in-line with all ISAPI Filter events in all Pipeline Modes (Classic and Integrated) because ISAPI Filters are actually just DLLs loaded by the "ISAPI Filter" Module, which acts as a shim to trigger appropriate ISAPI Filter events for the corresponding Module events of the Integrated Pipeline. For example, the "ISAPI Filter Module" subscribes for the OnPreBeginRequest event, which when triggered by IIS will cause it to fire the SF_NOTIFY_PREPROC_HEADERS filter event to all applicable ISAPI Filters for that URL scope.

Conclusion

In general, if your ISAPI filter does NOT subscribe to events earlier than SF_NOTIFY_SEND_RESPONSE, it would be possible for a Managed Module to execute before the ISAPI filter triggers.

You should notice some direct correlations between the Module events of the IIS7 Integrated Pipeline and a merging of the ISAPI Filter events and classic ASP.Net HttpModule events. This is intentional - that is what we meant with the name "Integrated" Pipeline! :-)

The astute reader should note that Managed Modules on IIS7 do not have access to the OnPreBeginRequest module event. Since that event is used by the "ISAPI Filter" Module to trigger the SF_NOTIFY_PREPROC_HEADERS event, this means that even in Integrated Pipeline mode, where Managed Modules trigger in-line with any other module such as the "ISAPI Filter" Module shim, a Managed Module will NOT be able to execute before an ISAPI Filter that subscribes to the SF_NOTIFY_PREPROC_HEADERS event.

Yes, there is a huge story behind why OnPreBeginRequest even exists and why Managed Modules do not have access to that event (and other such global notification events). The blurbs on MSDN simply does not do it justice...

But at long last, here is the long-winded response to it all.

Cheers!

//David

Question:

Answer:

Third party code will not be able to directly impersonate and have IIS use that user token. IIS will:

• Strip off the impersonation token after ISAPI Extension returns control to it
• Ignore and re-apply IIS's desired impersonation token if ISAPI Filter changed it

Thus, the only way for you to impersonate users with IIS is to change IIS's desired impersonation token. The following are the methods, in no particular order, that ISAPI can change IIS's desired impersonation token and hence control impersonated user. The method you choose depends on your authentication protocol's requirements.

• ISAPI Filter - SF_NOTIFY_PREPROC_HEADERS event - change the "Authorization" request header value to be: Basic [base64 encoding of username:password] . Requires Basic Authentication enabled in IIS.
• ISAPI Filter - SF_NOTIFY_AUTHENTICATION event - change pszUser and pszPassword fields on HTTP_FILTER_AUTHENT. Remember to SET your values into the provided buffers (and change the cbUserBuff/cbPasswordBuf values) because those are the actual buffers IIS will use. Requires Anonymous or Basic Authentication enabled in IIS.
• ISAPI Extension - HSE_REQ_EXEC_URL configured as Wildcard Application Mapping - change hImpersonationToken field on HSE_EXEC_URL_USER_INFO to be the actual NT User Token used by IIS for request impersonation. Requires Anonymous Authentication enabled in IIS.

//David

Question:

Answer:

What you want to do is not achievable via the UI. You have to configure the .config file directly.

This looks like a bug in the UI because the "accessPolicy" and "requireAccess" attributes are not aligned.

Here's what the UI is attempting to do:

• accessPolicy corresponds to the old "Execute Permissions" set of checkboxes
• requireAccess is brand new in IIS7. After we opened up the handler definition in IIS7, it became necessary to add requireAccess so that one could express the concept of "this handler requires script access permissions to execute" so that one could then use accessPolicy to control whether "scripts" can run or not.

Before IIS7, the logical tie between handlers and requireAccess was hardcoded into IIS into statements like:

• StaticFileHandler requires Read Permission
• All Other Handlers require Script Permission
• EXE and DLL require Execute Permission

Starting from IIS7, it is completely wide open. The astute reader should realize that it is possible in IIS7 to do something goofy like set ISAPI Handler to require "no" permissions (instead of Execute) and allow the ISAPI Handler to be executed by IIS Core all the time. However, the actual execution of an ISAPI DLL by the ISAPI Handler is still subject to ISAPI CGI Restriction. This is another example of defense in depth!

What the UI tries to display via the "State" view is: "if you allow only scripts, only these handlers are active". Of course, it is missing the "Write" permission as a filter. Even though the handler require access dialog just added "Write". Thus, when you selected "Write" request restriction for the handler, it makes it impossible for the UI to display as enabled because it does not have "Write" permission as a filter.

I would chalk this up as a bug introduced when WebDAV was added for Windows Server 2008 because that's the main module that needs it. However, if you think about what I just said, this is really easy to work around. Remember, IIS7 does not know what "Execute" permission is (or else the goofy ISAPI Handler configuration would not be possible), so IIS7 does not know what "Write" permission is, either.

Internally, the handler execution logic in IIS7 Core is:

1. accessPolicy contains "Text1, Text2, Text3".
2. handler's requireAccess contains "Text3".
3. requireAccess text is found inside of accessPolicy text. Allow handler execution.

//David

Question:

Answer:

I think the choice of development platform should depend on the features you want to provide and the platforms you plan to support. Personal preference and upgrade schedule should not decide the development platform unless you also want them to decide your potential user/customer base.

Personally, I believe you should develop on Vista, and here is why.

First, IIS7 is finally the release where the development experience on the client OS matches the corresponding server OS. No more hassling over XP Pro and Windows Server 2003 differences in everything related to IIS, from security ACLs, security models, Application isolation between high/medium/low and Application Pools, Web Service Restrictions on CGI and ISAPI, configuration changes, TCP Connection limitations, etc... you get the picture. The same IIS7 server core is on Vista and Windows Server 2008, with the same security model, application isolation, configuration files, etc. Unity at last.

Now, for some more technical reasons. IIS7 has two "Pipeline modes", classic and integrated, that offer completely different behavior/abilities for certain events (authentication being one of them):

• Classic mode is supposed to mirror ASP.Net behavior on IIS5x/6.0. With some minor tweaks while reconciling IIS and ASP.Net behavior.
• Integrated mode is completely new and represents true managed code extensibility of IIS for the future that mostly matches the native code extensibility of IIS.

I must warn that Classic mode will NEVER match Integrated mode in terms of features and functionality - it exists only for legacy, compatibility reasons. Thus, by definition, the two modes are different.

So, yes, it should be relatively painless to author a Custom Authentication HttpModule in ASP.Net on IIS 5.1 and run it in Classic mode on IIS7. However, that module will likely fail when you switch to Integrated mode, especially for Authentication since it is one of those events whose ordering changes (intentionally, for the better) between Classic and Integrated mode.

In fact, the way you configure that module will be different in IIS7 between the two modes:

• In Integrated mode, your simply add a new <module> using the type of your custom auth assembly in <modules>, and optionally add a preCondition to determine if the module should only run on requests involving managed code (i.e. only .aspx, .asmx, etc pages) or all requests (i.e. .html, .xml, .css, .asp, .php, pages).
  
  This is exactly what people tried (in vain) to do with ASP.Net 2.0 on IIS6 but could not, and certainly not with the elegance and compactness of preConditions.
  
  Instead, what one needs to do is the following set of kludges...
• In Classic mode, you need configuration that emulates what it took on IIS6 to get similar (but not identical) behavior. This means:
  1. *-scriptmap to aspnet_isapi.dll -- this is now a *-<handler> to isapi.dll with aspnet_isapi.dll as the scriptProcessor
  2. <httpHandler> for * which derives from DefaultHttpHandler and tweaks some special settings on the HttpContext to cause it to call the HSE_REQ_EXEC_URL ISAPI ServerSupportFunction underneath the covers
  3. Order the remaining <httpHandlers> correctly relative to #2 to get reasonable behavior

The astute reader will remind you that I just rushed through a WHOLE lot of details there, which many people have dedicated countless number of hours of pain/frustration/anguish and countless fragments of articles describing how to get an ASP.Net 2.0 Custom Authentication Module to [not] work on IIS 6. And what I just described does not even apply or work on the IIS 5.1 on XP Pro 32bit scenario you just described, unless you intend to only implement Custom Authentication module for ASP.Net pages and static files.

Now, we could have made it easier on the users (but much harder on us) in implementation, but we chose the clean implementation you currently see PRECISELY because it starkly shows how much more elegent Integrated mode is in comparison to classic mode at resolving the issue of managed code extensibility of IIS.

I hope this helps frame the discussion for your future development .

//David

Question:

Answer:

Yes, you can modify that code to get this information, but if you just want a list of virtual directories on a server, you don't need to write any script code to do it. At the end of this blog entry is one way, using a simple batch file, to get this information using ADSUTIL.VBS, a built-in script. Just make sure to provide the right filepath for CMD_ADSUTIL. And of course, the user running the script must have administrator privileges to enumerate the IIS metabase on all required servers.

This batch file accepts one optional input parameter.

• If you provide no parameter, it will enumerate all vdirs and their respective physical paths of the local computer
• If you provide a computer name, it will enumerate all vdirs of that computer
• If you provide a filepath, it will treat each line of the file as a computer name and enumerate all its vdirs

Since I often see this feature requested, I decided to show one simple way to turn a script which takes a server name as input into one that loops through a list of server names stored in a text file, one server name on each line. This should hopefully be illustrative enough of the powerful combination of both VBScript/JScript and Batch script.

Sample usage:

C:\>enumvdirs -?
enumvdirs [servername | file-list]

Where:
    servername is the name of the server to query. DAVIDWANG by default
    file-list is filepath to text file containing list of servers, one per line

C:\>enumvdirs DAVIDWANG
DAVIDWANG/W3SVC/1/ROOT = "c:\inetpub\wwwroot"
DAVIDWANG/W3SVC/1/ROOT/IISHelp = "c:\windows\help\iishelp"
DAVIDWANG/W3SVC/1/ROOT/Printers = "C:\WINDOWS\web\printers"
DAVIDWANG/W3SVC/1/ROOT/Scripts = "C:\Inetpub\Scripts"

C:\>ECHO %COMPUTERNAME% > ListOfServers.txt

C:\>TYPE ListOfServers.txt
DAVIDWANG

C:\>enumvdirs ListOfServers.txt
DAVIDWANG/W3SVC/1/ROOT = "c:\inetpub\wwwroot"
DAVIDWANG/W3SVC/1/ROOT/IISHelp = "c:\windows\help\iishelp"
DAVIDWANG/W3SVC/1/ROOT/Printers = "C:\WINDOWS\web\printers"
DAVIDWANG/W3SVC/1/ROOT/Scripts = "C:\Inetpub\Scripts"

Enjoy.

@IF NOT DEFINED _ECHO ECHO OFF
SETLOCAL
SET CMD_ADSUTIL=CSCRIPT.EXE //Nologo %SYSTEMDRIVE%\Inetpub\Adminscripts\ADSUTIL.VBS
SET PROPERTY_TO_FIND=Path

SET SERVERS="%1"
IF ?%1? EQU ?? SET SERVERS="%COMPUTERNAME%"
IF EXIST %SERVERS% SET SERVERS=%SERVERS:~1,-1%

SET NEED_HELP=%SERVERS:?=%
IF /I "%NEED_HELP%" NEQ "%SERVERS%" GOTO :Help

FOR /F %%A IN ( %SERVERS% ) DO (
    FOR /F "usebackq skip=1 tokens=*" %%I IN ( `%CMD_ADSUTIL% FIND %PROPERTY_TO_FIND% -s:%%A` ) DO (
        FOR /F "usebackq tokens=3,*" %%J IN ( `%CMD_ADSUTIL% GET %%I/%PROPERTY_TO_FIND% -s:%%A` ) DO (
            ECHO %%A/%%I = %%K
        )
    )
)

ENDLOCAL
GOTO :EOF



:Help
ECHO %0 [servername ^| file-list]
ECHO.
ECHO Where:
ECHO     servername is the name of the server to query. %COMPUTERNAME% by default
ECHO     file-list is filepath to text file containing list of servers, one per line

GOTO :EOF

//David

Question

Answer

You can use the ADSUTIL.VBS tool to do this from the commandline (or steal the code from it for your own custom script).

The properties that you are interested in are all documented on MSDN at Metabase Properties.

The following is an example of how to create a new Application Pool called "MyAppPool" and configure it to use a custom Application Pool identity of domain\username with a password of pass. You can find all the property syntax and valid values in the MSDN. Remember, if you want to use the space character as a parameter, you have to put it in double-quotes since the commandline processor uses space as parameter delimiter.

CSCRIPT %SYSTEMDRIVE%\Inetpub\AdminScripts\ADSUTIL.VBS CREATE w3svc/AppPools/MyAppPool IIsApplicationPool
CSCRIPT %SYSTEMDRIVE%\Inetpub\AdminScripts\ADSUTIL.VBS SET w3svc/AppPools/MyAppPool/WamUserName "domain\username"
CSCRIPT %SYSTEMDRIVE%\Inetpub\AdminScripts\ADSUTIL.VBS SET w3svc/AppPools/MyAppPool/WamUserPass "pass"
CSCRIPT %SYSTEMDRIVE%\Inetpub\AdminScripts\ADSUTIL.VBS SET w3svc/AppPools/MyAppPool/AppPoolIdentityType 3

//David

After a long and very much needed hiatus, I have regained control of this blog and returned to blogging. For the curious reader, you can read about some of the happenings here. But, I am not one for dwelling on the past (except to learn and improve upon); I look forward to the future.

And speaking of the future... technology-wise, my day-to-day interests have moved up the application stack to Exchange, specifically the Calendaring, OOF, and Free/Busy components. Basically, whenever you use Outlook or OWA to schedule a meeting, look up an attendee's Free/Busy information, or toggle your own OOF on Exchange 2007 onward, you are looking at functionality that I am responsible for within Exchange... and that is just the beginning. So, I will certainly be offering tidbits and answering questions about that aspect of Exchange as well as others as I encounter them.

Of course, I will continue to write and answer questions about IIS and ISAPI since they remain woefully under-documented. Not much changes with ISAPI after IIS6 since it exists for compatibility. As for IIS7 and beyond... I was involved in a lot of the design discussions/reviews and co-inventor of the extensibility API introduced in IIS7, so I think I have a good idea how things SHOULD work at the core. ;-) Besides, most of the work on IIS7 and beyond should come in the form of additional modules/handler on top of the core extensibility API, so questions about them are really specific to those modules and not IIS...

Cheers!

//David

P.S. Yes, I am still working on answering the backlog of existing comments, and I have just re-enabled anonymous comments...

Question:

Answer:

Actually, the problem you observe comes from your ISAPI Extension DLL. It is actually sending an invalid HTTP response without an entity body, and the APIs correctly complain. Let me explain.

Problem Restated

My understanding of your facts:

1. You have an ActiveX DLL using WinInet which successfully POSTs to an ISAPI Extension
2. You have a Windows Service which fails to POST to the exact same ISAPI Extension using either WinHttp or .NET Client

Based on that information, I hypothesize either:

1. The ISAPI Extension or other Server Side ISAPI Filter is doing something wrong, but WinInet ignores or covers it up while WinHttp/.NET Client correctly fail
2. The ISAPI Extension or other Server Side ISAPI Filter is doing something wrong, but IIS/ISAPI/Windows Networking stack does a special hack for WinInet but not others like WinHttp or .NET Client

Personally, I am more inclined to believe that the former is happening. The latter is simply way too convoluted, difficult, and fragile. I am not a Conspiracy Theorist - I believe in straight-forward explanations for computer issues. :-)

Problem Confirmed

In this case, I am certain that #1 applies for several reasons:

1. The simplified ISAPI Extension does not send a proper HTTP Response
2. "WinInet accepts the response" does NOT mean "it is a proper HTTP response"

In other words, the ISAPI Extension is doing something bad, but WinInet (and IE, which uses WinInet) tries very hard to succeed and hence overlooks such errors.

<rant>

Yes, it gives a great user experience to see IE render all sorts of improper HTTP responses and HTML pages, but it also gives false user confidence in the correctness of such HTTP/HTML.

But, I do not think the problem is solely with Microsoft/IE but rather shared with the authors of such bad HTTP and HTML. Computer users expect things to magically "work", so someone has to make the broken things be "less broken" and "work". This expectation results in a viscious cycle:

If IE refused to render the broken HTTP/HTML but some other browser did, then users think that IE is broken instead of blaming the incorrect web page. Since IE renders more broken HTTP/HTML, web page developers have less motivation to author correctly... and IE will be punished for refusing to render that future broken web page.

How whacky is that!?! Of course, Users have no idea that this is going on - they only see rendered pages and think everything is alright - when in fact the browser and web developers are slowly diverging from published specifications, increasing their maintenance costs, and causing headaches on the development side of things. And all because we are trying to shield the End User...

This downside is what hits you right now. In this case, you see a response from the ISAPI Extension when browsed with Internet Explorer or WinInet, so you probably think the ISAPI is perfectly simple and correct. Hence, you think that Microsoft has a bug somewhere that either causes WinHttp or .NET Client to not work with the ISAPI, or that there is some devious hack somewhere to favor WinInet. Bad Microsoft.

But in reality, it is the ISAPI Extension that is broken, and you were fooled by the tainted validations with Internet Explorer and WinInet.

</rant>

Troubleshoot with Trusted Tools

This is why I only use the following basic but trusted tools to debug HTTP Client/Server issues... because they have no alternative agenda to mislead anyone:

• WFetch to make raw requests and observe raw responses
• Network Monitor to tap the network and observe raw requests and responses
• Native Code Debuggers to observe programmatic state inside a process

I simply do not trust debugging/troubleshooting with anything else. If I have to use something like IE/FireFox, I always treat its answer with a heavy grain of salt and not as Gospel.

Resolution

If you change the ISAPI code to send the following response, then I believe it should work for WinHttp and .NET Client as well as WinInet:

char szPage[] = "HTTP/1.1 200 OK\r\n"
                "Content-Type: text/html\r\n"
                "Content-Length: 16\r\n"
                "\r\n"
                "We're good to go";

Basically, your ISAPI only sent back "We're good to go" as an HTTP response, and that is improperly formatted. The fix makes the ISAPI send back a proper HTTP response, so the client APIs like WinHttp or .NET Client should just work.

Conclusion

Powerful APIs, like ISAPI Extension and ISAPI Filter, directly control the data stream to/from IIS. Thus, they can either positively augment IIS behavior or negatively manipulate IIS to misbehave.

In particular, they differ from programming environments like ASP, ASP.Net, or PHP, which removes some of the power to protect the user from generating common HTTP mistakes. One just has to be aware of the guard-rails and training wheels.

Like many things, it is just a tradeoff that one needs to be aware of; nothing right or wrong.

//David

Annually, the IIS team gathers at Emily's house on the shores of lake Sammamish to enjoy a day of fun under under the sun. We call it "water day", and it has been a team tradition for at least as long as I have been on the IIS team.

Its organization, activities, and participants constantly alter, but one thing remains constant - a large number of the IIS team take off on a work day to go have fun on the lake, and a sub group hangs around at the end to really chat/gripe about things on their mind, management excluded. It allows parts of the team who otherwise would not gather/socialize with each other a chance to do so, and it gives people a creative outlet to vent/relax. We try to not talk about work, but inevitably, issues/differences do get informally ironed out, and that is a cool side-effect.

I remember water day starting out as a bunch of core developers who decided to coordinate a common ditch-work-day to go drink and play on the lake (water ski, wake board, swim, etc), and few key test process and automation folks with close working relationship with those developers who tagged along. It quickly got management sanction, organization, and catering, and it grew into the current, annual event.

Yeah, it is symbolic of how many things come about on the IIS team - do it, and they will come. A small number of people decides to do something, the result gathers concensus from others, and management later comes along to rationalize/formalize what was intuitively done.

In contrast to prior years, the team catered everything. Brian, Rich, and Keith manned the grill and churned out BBQ ribs, chicken, burgers, hot dogs, and ears of corn. Chips/salsa, fresh veggie platter, fresh fruit platter, chocolate chip cookies, brownies, and ice cream were also present... along with two kegs of beer. Emily took interested people out for a ride on her boat. I took photos/movies of the event throughout the entire water day. Yeah, we had everything covered. :-)

For the first half of the afternoon, the weather was overcast, and people staggered in from work between 12-2pm to eat. Some people went out for a ride on the jet skis and hopped off the water trampoline; others just ate and watched from shore. Fortunately, the sun broke through later in the afternoon, and that was when the fun began. Chris challenged Andrew to a team drinking game - team of people each sequentially drink an equal amount of beer and then attempt to flip their plastic cup to stand on its opposite end, and first team to have all its members complete the drink-and-flip task wins the round... and we played to the best of 7 rounds to win a game, and best two out of three games.

Let's just say that this kept a large part of the IIS team entertained, and we were glad that the managers were no longer around. ;-) Jan made a strong showing for the women on the IIS team by consistently performing the drink-and-flip in a short amount of time, and there were several photo-finish moments, including one where Edmund beat Wade by a matter of milliseconds. In the end, Andrew's team soundly beat Chris's team... but Andrew got really, really wasted. But it was all in good fun. We all had a great time.

Most people left by 8pm, but Jan, Edmund, Andrew, Emily, and I hung around to watch the sunset and chat/gripe about the drama in our lives both work and personal. I swear... while it is nice to impersonally plan and negotiate a task completion schedule, it is very satisfying to just reach a mutual state of understanding and simply operate as friends instead of coworkers. Things just get done better when we do things as "favors" for friends and our team morale stays higher as well. Yes, I know it does not scale past a certain point, but the IIS team is not yet past that point... despite what team management tries to organize. We just try to pull together and get things done, fast.

Ahh... it was such a nice, enjoyable day..

//David

Lately, I have not been making frequent blog posts. There are good reasons, of course... and I will get to disclosing them in the near future.

Recently, I have been spending a lot of time house-hunting. Yeah, I have decided that it is about time for me to move from my condo into a stand-alone house. I have a lot of furniture and electronics purchases all queued up behind buying a house, and it is about time I release that bottleneck.

And I have been amazed at the tools available at my fingertips to make this search. I remember just three years ago how painful it was for me to locate appropriately priced condos in the areas that I wanted. I needed an agent to help locate and sort things out.

Well, with websites like http://www.johnlscott.com and http://www.windermere.com, I can finally do most of the hunting on my own and engage a buyer's agent to help with the details and close the deal. I can easily enter in my criteria, like price range, location, features, rooms, etc... and scrolling/zooming around a map to narrow down the location... and the web app shows me the properties that match my criteria. How nifty is that!

I am especially impressed with the John L Scott site because it is so intuitively functional. I start out by punching in a price range and simply start scrolling, panning, and zooming into the area I want to focus on, and eventually I end up with a list of property matches with hyperlinks to lots of relevant information. And it works smoothly and quickly... so I have to say "score one for Microsoft technologies like ASP.Net, AJAX, and Virtual Earth"! Meanwhile, the Windermere site, which is based on ColdFusion and a MapQuest-like map called PropertyPoint... simply pales in comparison. Search criteria behavior is quirky at best, search/navigation is archaic in comparison to new standards like Virtual Earth and Google Maps, and usefulness of pricing information is not that high.

In contrast, from the John L Scott site, I have quick access to information like:

• Recent sale prices in the area, so I can guage price/sq.ft ratio and relative desire
• Historical public information on any property from metrokc.gov so that I have an idea of the price/profit range to help me determine position and approach for price negotiation
• I can also passively keep tabs on listings in the area, price changes... all of which help me easily assess property worth before I even invest the time into physically touring the place to determine if I like it or not

Yeah... it is very different from my first home purchase experience where I spent days of time visiting dozens of homes before finding one I loved, had no clue on the basis of price negotiation, and then later rationalized the economics and details. That was a weird feeling for me because I never felt in control and my selection criteria was so emotional.

Well... this time, I finally have the tools to apply an analytical approach of quantifying and qualifying what I am looking for and how important each criteria is... and then narrowing down amongst those choices. It leaves the emotions out until the end, which I think is the way it should be. After all, real-estate purchase is financial in nature for most people, not emotional (don't know about you, but I don't buy houses because I am "bored" or for "fun")... :-)

Next step - how to make the financing work from an investment perspective...

//David

Ok, maybe this is something you business/marketing types understand intrinsically... but it is something that I do not understand, so please bear with me. Why do people complain about getting something for free that used to require money? I thought people like getting something for nothing.

For example, Microsoft recently announced that Virtual PC 2004 will be available free of charge. I expected users to be happy to get yet more quality software for free... but I did not expect the firestorm of complaint from users on newsgroups that fall along this line of logic:

Gosh, I feel like a used dummy for paying Microsoft $X for Virtual PC 2004 Y months ago. Either

• Microsoft is stealing money from me
• I am simply lining Microsoft's profits without even an acknowledgement

These users either want:

• Microsoft to give compensation, either in the form of money-back or money voucher, for people who purchased Virtual PC 2004 in the last Y months
• To pirate other Microsoft software to "get back" at Microsoft because it extorted money on eventually free software and who knows, it may be released for free in the future.

I simply do not understand the rationale for this line of logic. Software is not your possession; you purchase a license to give yourself the right to use that software.

If I purchase a possession and the seller later decides to give the item away for free, then sure I will be bummed because it means I cannot later resell that possession. I am cheated from being able to resell that possession because the sellar has deflated the market price for that item. However, regardless of price, I still get my utility and value from using the item - it functions the same whether it is priced at something or nothing.

If I merely purchase the RIGHT to use an item and the seller later decides to give the item away for free, then how can I be cheated? Since I never owned the item, I am not cheated from being able to resell the item because I could not sell the rights to it in the first place. However, I still get my utility and value from using the item regardless of price.

So, I do not think there is any stealing going on. Instead, I think there is a natural sense of Buyer's Remorse. Why one thinks that s/he is magically entitled to compensation for feeling remorseful... I do not know.

I mean... no one pointed a gun at you or otherwise extorted you to purchase an item Y months ago for $X. You willingly purchased the item because you believed its utility is worth at least $X at that time. Just because its price is now free does not diminish its utility - you are not investing in something you don't own; the binary files didn't change; the software doesn't phone home and alter behavior, did it? And since you did not own it in the first place... what's changed?

Are you upset that Joe Schmoe now gets the software for free while you had to pay for it? But what about those Y months when you had utility of the tool but Joe did not; was the price not worth it? But if it was not worth it, then why did you purchase it in the first place? Oh, you thought that Y was going to be a long period of time to amortize the initial cost... but who gives assurance of that assumption?

I sense the same analogy in computer hardware. It seems like every year the hard drives double in capacity at the same price point. Do I complain to the hard drive manufacturers that I am simply lining their profits this year and that they are stealing money from me because next year they will charge me half the price for the same item? Or that they should just give me the discounted price now or give me cash back/voucher towards the future purchase of a hard drive? Or that I should steal an identically sized hard drive every year because it halves in price?

Nope... I take comfort in the fact that when I purchase a hard drive, I do so at a reasonable price point at that time, and the utility of having that drive for a year is worth any depreciation in price. Looking back and feeling remorseful is only going to be upsetting because most things tend to get cheaper/faster/better as time goes on. I just accept it and move on.

So... can anyone explain to me why Buyer's Remorse deserves compensation, or that Microsoft is somehow stealing by giving away software for free? Because as far as I see, Microsoft is far from stealing - it is simply not making money it can otherwise make. Maybe there are subtle points that I do not understand; feel free to kindly enlighten me. :-)

//David

Back in this blog entry, I mused about the nice Audio over RDP feature. It is pretty sweet to have secure, remote access to one's audio collection.

Well, I recently started playing with RDP over the new TS Gateway on Vista Server, and I have to say that it just keeps getting better.

In the past, I would VPN from home into Microsoft, open RDP from my laptop at home into my work machine at Microsoft, then stream audio from the work machine through my laptop at home. Life was good.

With TS Gateway, I no longer need to VPN. I now directly open RDP from my laptop at home into my work machine at Microsoft and stream audio. Life is great.

While you may think "big deal... you are still tunneling and get no substantially new features", it is important to me for one reason:

I no longer need to run as local Administrator on any of my systems.

As I mentioned in this blog entry - I run as normal, unprivileged User to do everything; I turn on the Windows Firewall to block all but a few select ports; I do not bother with personal Security Products because they simply intrude on my computing freedom... because, umm... the idea of a computer software "chaperone" scares me. Remember HAL 9000?

Dave... what's wrong? What are you doing? Please don't do that...

Argh! :-P

Anyways, the one and only reason that I still use my local Administrator account is to VPN from home into Microsoft, and once I have VPN, I immediately RDP from my laptop to my machine at work using my non-priviledged account. I imagine that most everyone else in the world running Windows do something similar and run with Administrative priviliges with far greater amount of time.

Well, the TS Gateway works perfectly for me:

• I still RDP from my laptop at home to my machine at work
• I no longer need to VPN
• I no longer need to use my local Administrator accounts anywhere

To boot, RDP already allows me to copy files between the Host and Remote computers. So I do not need to VPN anymore to do these common operations.

Yes, I know you *nix-heads are shaking your heads and saying "welcome to modern computing; *nix has had SSH tunneling and X11 port-forwarding for decades now" - but humor me for the moment. :-) How easy is it to work with and forward smart card so that you can double hop?

To me, the TS Gateway feature, like IIS7, make Vista Server compelling.

//David