I have a VFP COM Server running under WC successfully on a development server in the Intranet. When the application was moved to the production server, IIS issues a challenge when an attempt is made to fire the COM server, whether from a web page link or if I type in a URL to a test method in the server.

Web directories are configured for NTCR and Basic Auth. The challenge is not issued when accessing the web pages themselves, just when attempting to fire the COM server. The COM server is set up to run under the Interactive User ( a Domain Super User so ought to have enough rights ) in DCOMCNFG and, interestingly, this is the UserID and password IIS is expecting in the challenge. As noted, this all runs successfully on the dev server. I tried to set up the production server web site like the dev server but 100% similarity was not attainable since the prod server basic set up was done by another individual. I have checked every IIS/NTFS/DCOMCNFG security setting I know of several times.

Dev/Prod Server differences:
1) Application is running in a virtual directory under the Default Web Site on the dev server, but in it's own web site ( separate from Default Web Site ) on the prod server.

2) The individual who set up the prod server removed the IUSR_machinename account ( haven't the faintest idea why!! ) and set up another account intended to be used for anonymous access. I have this account included in Access/Launch permissions for the COM server in DCOMCNFG. But I am using NTCR and Basic Auth since everyone who hits the site should be logged on to the NT Domain here ( and I can programmatically determine who they are for backend processing ) so I would guess(??) that this is a mute point?!

3) The prod server administrator set up the web site with a Host Header Name which is recorded in a DNS Server in the Domain. This HH Name contains dots (.) like an Internet address and, according to MS, this can result in a challenge when hitting the web site pages. The MS workaround is to record (gag) the Site in the list of Intranet sites in IE and after doing this, no challenge was issued by IIS when accessing the web pages themselves. Whether this is affecting the challenge on COM Server access, I don't know.

Besides these basic differences I have looked at all the settings 20 times and can find nothing, that I know of, that would cause this challenge so I've run out of things to look for. I would appreciate any thoughts that would shed some light or prick my thoughts for something I could have missed here.

Thanks,
Bill