1. Please take a little time for this simple survey! Thank you for participating!
    Dismiss Notice

fpmapping.dll -- where does it load?

Discussion in 'Plesk for Windows - 8.x and Older' started by secretagentman, May 20, 2004.

  1. secretagentman

    secretagentman Guest

    0
     
    Strangely, on a CLEAN install of Plesk 6.5.2 on a VIRGIN Microsoft Windows 2000 Server, the fpmapping.dll ISAPI filter is not loaded.

    Would someone please look at their IIS Control Panel and look to see where fpmapping.dll loads?

    I'm going to assume that fpmapping.dll loads under the web site that has your virtually hosted IP address of your Plesk server (the "Physical Hosting" IP address).

    Would someone take a look under the ISAPI Filter tab and tell me if they have mapping.dll and the fpse dll loaded. And also the order or the dlls and if fpmapping.dll is loaded?

    The forum member's assistance is much appreciated.

    Let's pray that the forums stay even when this new Microsoft Marketing person has been hired. I fear that this person's first task is to remove any 'negative' or possibly 'negative' talk/help/etc about Plesk -- including the tearing down of this forum. --> That is another THREAD --> DON'T DISCUSS THAT HERE.
     
  2. secretagentman

    secretagentman Guest

    0
     
    News from support.

    Seems the Control Panel "FP Webadmin" button does not work in 6.5.2. "This will be fixed in next Plesk version."

    Vodka shots for all.
     
  3. secretagentman

    secretagentman Guest

    0
     
    The actual problem for this thread is:

    "FP Webadmin" button in the Control Panel does not go to the correct web page.

    It incorrectly goes to:

    http://www.domain.tld/_vti_bin/_vti_adm/fpadmdll.dll?page=webadmin.htm

    This actually will require the server's admininstrator's username and password to get into the interface.

    The Control Panel "FP Webadmin" button is sending you to the wrong subweb.

    It should resolve to:

    http://www.domain.tld/domain.tld_non_ssl/_vti_bin/_vti_adm/fpadmdll.dll?page=webadmin.htm

    Then your end user can use their FrontPage username and password to use Microsoft's FrontPage web-based administration page.

    "This will be fixed in next Plesk version."

    Vodka shots for all.
     
  4. MattR@

    MattR@ Guest

    0
     
    I've just tested this out on our 6.5.2 box and the button works fine, able to recalculate the web, and all other functions I tried worked fine. I was able to login using the domain frontpage username and password. Does this happen on all of your domains?
     
  5. secretagentman

    secretagentman Guest

    0
     
    Yes, it does happen with all of the domains.

    Strangely, why would Plesk's technical support state that it is a known error that will be corrected in the next release?

    Left hand please meet right hand.
     
  6. secretagentman

    secretagentman Guest

    0
     
    MattR,

    Since you're reading this thread, would you mind looking at your ISAPI filters for your base Physcially Hosted web site in IIS and report back on your loaded ISAPI filters?

    That would be much appreciated.
     
  7. MattR@

    MattR@ Guest

    0
     
    I'm surprised Plesk would have said that, maybe you hit someone on a bad day, shouldn't have happened. Nonetheless, the loaded filters are:
    mapping.dll
    fpexedll.dll

    Let me know if there's anything else I can do that might be of help.

    Cheers,
    Matt
     
  8. secretagentman

    secretagentman Guest

    0
     
    Yes, mapping.dll and fpexedll.dll are the exact same dlls I have loaded. So the "FP Webadmin" bug is very odd. Especially if it is true that you and anyone else running Windows 2000 Server with Plesk 6.5.2 and having all patches installed do not have the "FP Webadmin" bug.

    "Shouldn't have happened" .. are you saying that you have insider knowledge of the Plesk technical support team?
     
  9. MattR@

    MattR@ Guest

    0
     
    I can't speak for anyone else's machines, just that it works on ours, we've certainly run across many other bugs, the _non_ssl Server.MapPath() being the most serious forcing us to setup sites manually in IIS to support ASP.Net applications.

    When I said it shouldn't have happened, I just mean if Plesk were my company anyone on the front line replying to tickets stating that this is a known issue and will be fixed in the next version, if it isn't, wouldn't be working long. Maybe it is a bug specific to Windows 2000, etc. but they should be making these things clear or at least putting a knowledgebase of some sort online, or better yet designate a knowledgable employee to resolve problems in here so potential customers aren't coming in here browsing threads about customers dumping the product because it doesn't work.
     
Loading...