Desktop - My Computer + Drivec (C:) + Drived (D:) - Drivee (E:) - InetPub - wwwroot - <b>web00000</b> <-- Physical dir for the web site; Wc.dll, COM server and base HTML web pages here + Images <-- images for web pages here + Scripts <-- Scripts dir WC Help says to place from wConnect + Template <-- *.wc template files - Temp - wc - My_Web_Site <-- temp dir for the application The web00000, Images, Scripts and Template dirs all have the following NTFS permissions: Administrators Full Control Everyone RX IUSR_machinename RX Domain Super User Full Control SYSTEM Full Control The temp Dirs Temp and My_Web_Site have the following NTFS permissions: Everyone RWXD IUSR_machinename RWX Domain Super User Full ControlSome of these settings seem pretty loose but I wanted to get the thing running then tighten up security.
Console Root - Internet Information Server - *MachineName + Default Web Site ... - <b>My_Web_Site</b> <-- Wc.dll, COM server and base HTML web pages here + Images <-- images for web pages here + Scripts <-- Scripts dir WC Help says to place from wConnect + Template <-- *.wc template files <b>My_Web_Site Properties:</b> <i>Web Site</i> Site has a Host Header Name containing periods ( see caveat at end ) registered in a DNS Server <i>Home Directory</i> Application Settings: Permissions set to Execute There is no Isolation Mode in the version of this dialog but the "Run in separate memory space" is <i><b>not</i></b> checked <i>Directory Security</i> Basic Auth is checked with the Domain Name set to the Domain we are in ( I have tried with and w/o the Domain Name set ) NTCR is checked Anonymous Authentication - I have tried with this both unchecked and checked with the IUSR_machinename account entered as the User Name Images, Scripts and Template sub-directories all have Basic Auth and NTCR checkedCaveat: The Host Header Name for the web site has periods in it which, according to MS can result in an automatic challenge from IIS because it "sees" the periods and interprets the address as an Internet address even tho it is actually an Intranet address. The MS workaround is to include the name in the list of Intranet sites in IE Security. After this entry, IIS no longer challenged to access the web pages. Whether this is affecting firing the dll, I don't know.