Its common to find vulnerabilities in file upload functionality, allowing a malicious file upload, thereby allowing code execution. This is more interesting under IIS 6.0 because of the recently published exploit for Windows Token Kidnapping vulnerability. Under IIS 6.0 every website runs under a particular Application Pool, and the default application pool runs as 'Network Service'. It is this pool(running as network service) which will allow a privilege escalation vulnerability as per the token kidnapping issue.
It may at times be possible to use a vulnerable file upload functionality to upload the shell file(shell.asp or shell.aspx) into a different website running under a different application pool(e.g. weak permissions etc). This will mostly be the case with shared hosting. Thus if you find a vulnerable file upload under IIS 6.0 and it does not run as network service, it may be worth finding out other websites hosted on this server and trying to execute your shell under these 'Application Pool' and if you are lucky you will get one website running under default application pool(network service). I found that both asp and aspx shells under IIS 6 run as the same user which is same as the one assigned for that Application Pool.
Under IIS 5 (and IIS 6.0 running under IIS 5.0 isolation mode) asp runs under iwam_machinename user, whereas asp .net(aspx) run under aspnet user. Thus you cannot use the token kidnapping issue under these conditions.
Other than the vulnerable file upload functionalities, the same attack vector can also be used if the web server has webdav enabled and allows PUT method.