David Wang

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

Ok, I know that I just purchased an IBM X41 Tablet last fall, but I am in the market for a new laptop again.

No, nothing wrong with my computers... I am just going to be giving the X41 to my younger sister so that she can use it during Law School the next few years. I wager she needs it more than I do, and I still have my older Dell laptop, PC, and Mac Mini, so I have no shortage of computers. Yes, I am a nice older brother.

Why am I giving her the X41 instead of the other machines? Because the X41 is new and still has its 3-year warranty. There is no way that I am giving my sister a machine out of warranty because if anything goes wrong, I will get the phone call... and we all know what long-distance computer troubleshooting can be like... ;-)

All it means is that I must re-evaluate the ultraportable landscape again.

Unfortunately, it seems that Dell's design philosophy for its Latitude Ultraportables no longer match what I am looking for. I do not want a widescreen LCD on the business-class Latitude; if I wanted widescreen LCDs for movies, I would choose the consumer-class Inspirons. PC Card slot and SD memory slot are necessary now, for my smart card reader and digital camera memory. And packing it all into a real ultraportable package (2.5-4lb, 1" thick) is important. Sigh... I do like Dell machines, especially their a la carte software setup, but their hardware design seems to go in a direction that no longer match what I want.

Toshiba appears to still go with the R200, which while sleek and more business-minded, it is also demanding a price premium for last year's hardware (Pentium M instead of Solo/Duo, 4200rpm HDD). I may enjoy the fashion, but not at the cost of basic functionality. I am willing to trade-off some hardware functionality for a fashionable ultraportable form factor (like the fastest CPUs, discrete graphics, or 1600x1200 LCD panels), but not for last year's functionality. Gotta have standards, you know. ;-)

Apple, HP/Compaq, and Gateway are pretty much out of the picture because I have never seen a system from them that simultaneously satisify the price, functionality, reliability, and customizability ratio. I am always amazed at how Apple manages to pawn last year's hardware at premium prices and still get away with it - gotta love their marketing and spin-machine...

So, I guess that leaves me with IBM (oops, Lenovo) for the this purchase. I am debating between the X60S and the T60P... because on the one hand, you have the classic ultraportable X60S with all the usual features and this year's hardware refresh (Duo, 7200rpm HDD) while still retaining the standard XGA resolution, PC Card/SD Memory, and now 3 USB 2.0 ports... and on the other, you have the classic power-machine T60P with all the top-end Vista-ready hardware (Duo, 7200 HDD, discrete graphics) while sporting a 1600x1200 LCD. I don't know... 1600x1200 is a really attractive resolution, especially for me to PPTP into my work machines. I have been really spoiled by my dual 1600x1200 and 1200x1600 monitor layout - having screen real-estate really helps my work efficiency.

Hmm... I guess I will just have to toss a coin... :-)

//David

IIS7 core extensibility model supports both native and managed code as first-class citizens. So, I feel it is time for a little refresher on managed/native code interop... starting with the more popular route of how to wrap native code API for use within managed code. I am using the newer syntax introduced with .Net Framework 2.0 instead of the older, kludgy syntax.

Now, I am going to ignore the reciprocal route of calling managed code from native code for a couple of reasons:

• It is just boiler plate COM Interop within native code after generating and registering the CCW (COM Callable Wrapper) of the managed class.
• Why don't you just write a managed code module/handler in IIS7 to directly use that managed API?

The example illustrates how to use Managed Code to:

• Pass a .NET String into Managed C++
• Manipulate a .NET String in Managed C++
• Return a .NET String from Managed C++
• Pass in arbitrary number of args into Managed C++

Remember to use a Class Library Project for Sample.h and Sample.cpp to create a Managed C++ Wrapper around native code API, and you can use the resulting Managed Assembly from Sample.cs managed code.

Enjoy,

//David

Sample.h

#pragma once
#include <windows.h>
#include "SomeNativeAPI.h"

using namespace System;
using namespace System::Runtime::InteropServices;

namespace Sample
{
    public ref class ManagedClass
    {
    public:
        ManagedClass( String^ name );
        ~ManagedClass();
        !ManagedClass();
        String^ DebugPrint( String^ format, ...array<String^>^ args );
    private:
        SomeNativeType* m_pType;
    };
}

Sample.cpp

#include "Sample.h"

Sample::ManagedClass::ManagedClass( String^ name )
{
    //
    // Convert .NET String into LPSTR for 
    // Native code API to use in constructor
    //
    IntPtr szName;
    szName = Marshal::StringToHGlobalAnsi( name );
    m_pType = new SomeNativeType( szName );
    Marshal::FreeHGlobal( szName );
}
Sample::ManagedClass::~ManagedClass()
{
    this->!ManagedClass();
}
Sample::ManagedClass::!ManagedClass()
{
    delete m_pType;
}
String^ Sample::ManagedClass::DebugPrint( String^ format, ...array<String^>^ args )
{
    //
    // Use Managed Code to format variable arguments as .NET String,
    // convert the .NET String into Unicode String, and pass
    // it to Native API
    //
    String^ formattedString = System::String::Format( format, args );
    IntPtr  wszFormattedString;

    wszFormattedString = Marshal::StringToHGlobalUni( formattedString );
    m_pType->SomeFunctionUnicode( wszFormattedString );
    Marshal::FreeHGlobal( wszFormattedString );

    return formattedString;
}

Sample.cs

namespace Sample
{
    class Program
    {
        static void Main( string[] args )
        {
            Sample.ManagedClass cls = new Sample.ManagedClass( "Name?" );
            System.Console.WriteLine( cls.DebugPrint( "0:{0},1:{1}", "N", "V" ) );
        }
    }
}

Yes... software can have bugs, even if you test it. :-)

Question:

Answer:

Yup, your issue is with relative path resolution of URIs by browsers, and it is caused by a bug in your CGI. Yes, I know you say that you have successfully tested the CGI on a number of platforms, but at the end of the day, your customer demonstrated a flaw within your CGI despite your testing, so you simply have to accept and fix it.

To allow your customers to install your CGI wherever they want, I suggest that you fix your CGI to use the Server Variable (or CGI environment variable) SCRIPT_NAME to generate the correct URI for ACTION. SCRIPT_NAME resolves back to the URL that invoked the CGI, wherever the user installed it. So, for a first run URL of http://mysite.com/cgi-bin/prog.cgi , SCRIPT_NAME returns /cgi-bin/prog.cgi... which should correctly resolve as ACTION for your subsequent PostBack.

If you just use "prog.cgi" as ACTION, you are assuming that the BROWSER resolves /cgi-bin as the base directory of the request and makes the PostBack to /cgi-bin/prog.cgi. If the browser does not resolve /cgi-bin as the base directory, the PostBack likely results in a 404. You can verify this with the server log file corresponding to the failed PostBack that results in a 404.

//David

Question:

Answer:

ISAPI Filter can access the entire request sent by the Browser, which includes the information you named (URL and Host [i.e. "domain name"]). However, it may not be in the form you expect because:

1. The web browser does not necessarily send the exact typed text to the web server
2. GetHeader("url") does not retrieve what is typed into the web browser

The following is an abridged version of the BNF definition of a HTTP Request:

       HTTP-message   = Request | Response     ; HTTP/1.1 messages

        Request       = Request-Line              ; Section 5.1
                        *(( general-header        ; Section 4.5
                         | request-header         ; Section 5.3
                         | entity-header ) CRLF)  ; Section 7.1
                        CRLF
                        [ message-body ]          ; Section 4.3

       Request-Line   = Method SP Request-URI SP HTTP-Version CRLF

       Request-URI    = "*" | absoluteURI | abs_path | authority

       request-header = ...
                      | Host                     ; Section 14.23

Given your example URL of http://www.mysite.com/test , the web browser can send a couple of different valid requests. I color code what retrieves what:

Example 1:

GET http://www.mysite.com/test HTTP/1.1\r\n
\r\n

Example 2:

GET /test HTTP/1.1\r\n
Host: www.mysite.com\r\n
\r\n

In particular, GetHeader("url") only retrieves the Request-URI (colored in red) and GetHeader("host:") only retrieves the Host header (colored in green). In other words, GetHeader() does not retrieving the "logical URL" typed into the web browser; it retrieves specific parts of the request as identified by BNF.

Since you want to know the logical "domain" and "URL" of the request, you will have to retrieve the data via ISAPI and parse it yourself according to HTTP specifications. I suggest you read the HTTP 1.1 RFC for all of the proper details since ISAPI just gives you access to the data - you have to make logical sense of it yourself.

Now, as to your question about using ISAPI Filter to "change the domain name"... an ISAPI Filter can only change the domain name as it appears in the Host: header. It cannot alter IIS request processing nor server variables based on the website.

This means that if the original request came in for domain "original.com", it will be processed by the metadata associated with the "original.com" website. Even if the ISAPI Filter uses SetHeader() changes the Host: header to "new.com" or sets the URL to http://www.new.com/test, the SERVER_NAME and request is still processed by "original.com" - you only see the Host header change in the ALL_RAW and HTTP_HOST server variables.

In other words, it is not possible to transparently and easily change/re-route requests between different websites... unless you use a SF_NOTIFY_READ_RAW_DATA filter. But, you really do not want to do that for many reasons - on IIS6, you lose Worker Process Isolation Mode, and you also have to know HTTP backwards and forwards to write it correctly for all possible cases without crashing.

//David