Scott, we haven't needed to set any rights on the VFP mtdll itself to call it from ASP. The virtual directory where the ASP script runs (that calls the vfp mtdll) has script/executables Execute permissions. The only time we need to add IUSR and IWAM for security is for Write access on the VFP data. This is on Win2k Server SP2. Make sure you have the latest SP since there are issues with SP1 and no service pack.

I can send you ActiveVFP 1.5 which does all of this for you with the WebAppBuilder. ActiveVFP 2 will be coming out soon and will be a big improvement, especially in the areas of debugging and deployment

You probably already tried IISRESET. Also, when you rename a VFP mtdll, you need to make sure the Type Library name is consistent with the new name - take a look at the project information box under Servers...
>I have a VFP7 DLL COM server running in my ASP pages with no trouble (IIS 5). I recompiled that same app as a different DLL name and it will not run out of ASP pages. I get the infamous
>
>HTTP 500 - Internal server error
>Internet Explorer
>
>ProgIds are "esiwebdl.app" and "esiwebdltest.app". The "test" DLL is the one that fails. VFP7 runs both just fine from command window when I instantiated them with same Progids.
>
>The two DLLs are in the same folder on the server, and have the same rights (IUSR_svrname and SYSTEM users have Read and Execute). They do exactly the same thing. I had a problem getting the first one to work in ASP, but I don't remember what I did. Now, the second one won't instantiate but first one still does.
>
>Data access is not an issue because I created a couple of more small "Hello World" type DLLs, registered them on the server in the same folder, and they won't run either.
>
>I try creating both in the same ASP page to rule out rights issues where the page is stored.
>
>I know DCOMCFNG will change access and launch rights for EXE servers, so I tried setting global rights there but it didn't make a difference.
>
>It almost seems like there is a rights issue inside IIS that is set down at the file level for each DLL. Is this the case???
>
>2:45am and I'm out of ideas...