Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Challenge when firing COM Server
Message
General information
Forum:
Visual FoxPro
Category:
Internet applications
Miscellaneous
Thread ID:
00516505
Message ID:
00516967
Views:
9
>Is it the .dll link that causes this or the COM server permissions? I think it's the DLL permissions, cause you wouldn't get an auth box in the browser if the server failed due to access rights.
>
>That leaves you with the issue of incorrect directory permissions. Check and make sure that the IUSR_ account has execute rights whereever wc.dll lives and script rights in whatever directory you try to access any script map pages. Also make sure you got your application isolation mode in IIS set to Low - if you use the default Medium the account you need to mark will be IWAM_ instead of IUSR_. Sometimes permissions can get wacky on NT/2000 so remove those accounts and add 'em back in.
>
>Make sure basic auth/ntcr are enabled ofr all the directories in question. The DLL path as well as the virtuals you're running out of (if different).
>
>+++ Rick ---

Rick,
I have looked carefully at all theses items and tried various settings but still get this challenge. Sorry to be a bother but please bear with me and let me completely describe the settings since everything looks "ok" but something must be missing:

The IUSR_machinename account had been removed by the person who set up the machine so I added it back in. Accepted defaults except checked "User cannot change password" and "Password never expires". It defaulted to the Domain User group.

NTFS Settings

The physical directory tree appears as:
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 Control
Some of these settings seem pretty loose but I wanted to get the thing running then tighten up security.

IIS Settings

The IIS Console directory tree appears as:
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 checked
Caveat: 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.

I'm sorry for so much detail here Rick, but after trying everything I know plus all you have indicated, I'm out of ideas. I keep coming back to thinking there must be something different about how this server is configured but I don't know what it could be.

Thanks,
Bill
William A. Caton III
Software Engineer
MAXIMUS
Atlanta, Ga.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform