I'm running in COM with the dotNet connector. I have now seen several times where the loaded servers will stop excepting hits and shut down. Before I can get them to restart, I have to Remote Desktop onto the server and then try hitting the site again. This seems to unplug what is getting in the way from allowing the hits to go through.

Any idea where to look for additional clues?

Problem being by the time I login with Remote Desktop the problem is solved.

What do you have in your dll log (wc.wc?wwMaint~wcDLLErrorLog)?

I don't seem to have access to the log files from within the Web Connection Server Maintenance page. I get the message "Authentication Required" dialog box although I have already signed into the machine.

As far as opening the authentication, I was having a prior problem that was related to URL Rewrite. I think that was solved by allowing traffic to the .WC file extension. But to confirm this was not causing this current problem, I disabled the rewrite rules and the re-tested. The problem remains so that is not the issue now in my opinion.

I was able to get the following error message while in the Web Connection Server Maintenance page at a point in time when the servers were not responding to auto load. I have no idea what this means...

Any suggestions would be very welcome... in the mean time I will run in File Mode.

which user account does your IIS application pool run under (cercled green below)?

There appear to be three pools, two which I assume Web Connect installed and one when I created my application. They are all set to "LocalSystem" and from a brief review thay all apear to be set the same.

Here is a screen shot of my Mapped Handlers followed by a screen shot of my Application Pools. Everything looks correct to me...

Thanks for your help...

which app pool used by the offending app?

you could try a dedicated account

CFM as I understand your question....

The script mapping is to the filetype .cfmx which points to the CFM pool.

What is your security for the application pool set to?

You should be running under SYstem or some other Admin account that has the rights you need and NOT interactive. If you run Interactive an active desktop logon has to be happening on the console of the server. Running a non-System account will run invisible.

IIS will shut down app pools after 20 minutes of idle time by default (you can change that in the App Pool administration in IIS) and if you're running Interactive and there's no console active servers will not launch.

Based on the screen shots you have here, I'd say the problem is the DCOM identity. You should not be using DCOM identity and use Launching User identity of the host (IIS AppPool - or SYSTEM in your case). You probably have your server set up to Interactive or some other account that's not available. So - fix the DCOM configuration by removing any impersonation and revert to Launching User.

+++ Rick ---

OK... not sure I've done this all correctly or for that matter fully understood your directions. I captured the screens that I understood you to be referring to and show them all below.

First my IIS application pool, these screen shots suggest everything is OK with the Identity = LocalSystem

Now onto the DCOM, I'm omitting tabs 1,2 and 4 and showing tab 3 "Security" which I had to drill down into before exposing the data. No changes were made here because I'm assuming these settings are correct.

Then onto the final tab "Identity". Here I discovered the interactive user you referred to and changed it to launching user.

Do you see any other issues before allow the system to run in COM?

Thanks for your comments, very helpful as alway! And BTW being able to attach screen shots is really cool! Huge improvement in the message board.

Ok so all of my users when home for the day which gives me the chance to see if this change helped or not...

Wow - it is running now without any UI. I guess I misread Rick's post!

So based on my settings where do I see the statement "Running a non-System account will run invisible." show up?

For the past two hours I've been messaging around with how the DCOM Security options and the Identity options interact.

On the Launch and Activation Permission tab, I found three Users/Groups were defined, System, Administrator and Interactive. So based on Rick's note, I deleted the Interactive account and restarted DECOM. This caused the servers to unload so from my browser I re-hit my application and it responded. But no change, with Identity set to "The launching user" the WebConnection cosole is invisable. The server is running fine but I do't see any UI.

In this case, I'm wondering who is launching the application? Under Security, Launch and Activation the only remaining accounts are administrator and system.

If I switch back to the interactive user, the Web Connection console becomes visable on the first hit. This is a good thing but I'm not sure if my original problem is solved as a result of removing the Interactive user account from the Launch and Activation tab.

On a side note... it seems strange to me that my servers ever stop. I have a Web Monitor hitting the application every ten minutes. when the console is visable, I can see the hits to the server and after creating a custom page TestPage just for the monitor, I know it is getting hit in the log. Oh, the Idle Time-out is set to 20 minutes... hence my questioning why the server is able to unload in the first place.

FWIW, even if it may seem weird after having run under file mode for a while, having no server console visible in COM mode is OK on the long run.

That's what you want. The console should be invisible. It can only be visible in Interactive mode (which you can set in the AppPool Identity) but it's a bad idea because it requires a login. You don't want that. You can look at information the console displays on the admin page - most likely the log. Or if you really need it for some sort of debugging scenario - fire up a file based instance(s) and switch to file mode.

The proper way to run a server is:

• Set IIS APplication to SYSTEM (or other account that you know has all the rights you need)
• Set DCOM Identity to Launching User (or more accurately leave it alone - this is the default)

This makes your FoxPro server run under SYSTEM (or whatever you used on the AppPool). There will be no visible Web Connection console.

The advantage of all this is:

• You don't have to be logged on - Much more secure and easier to manage.
• You only configure security on the Application Pool
• The same security applies to IIS and your Fox application - predictable!

You can dial down the security as needeed just make sure you have rights to read/write your data, the Web folder (for admin settings) and you can load a COM server.

+++ Rick ---

First of all, the new Gravatar.com photo of you hiding behind your laptop (covered with decals no less) makes me laugh... Really silly!

Removing the INTERACTIVE account from DCOM Launch and Activaion Permissions (see below) seems to have solved the problem of having the machine freeze up.

In response to your last message, it all makes good sense and I will follow your directions as soon as I can figure out why I can't look at the Log's. At this point whenever, I click to open any of the log links from the Web Connection Server Maintenance page, I get an authenticate dialog popup. Strange since I can login to the Module Administration page with my current administrator user and password account.

What is more surprizing to me is the log pages all use the same script maps as the maintenance page... where do the maintenance pages reside on the drive, maybe SYSTEM does not have rights (is this even possible)?

Below is a screen shot of the error page I see after attempting to login to any of the Log pages.

Authentication problems have nothing to do with the Impersonation of the server or Fox server identity. Those are configuration issues on the Web site - Authentication and potentially ACL setting on files if Windows Authentication is enabled.

Make sure you enable authentication in your server (AdminAccount in web.config) and make sure the username(s) you use match exactly. You can use ANY if not sure.

Additionally, if you're logging on from the server please note that Windows Auth logins by default don't work because Windows disables that on Server OSs.

More info on the local logon issue here:

• Why is Windows Authentication not working Locally but working Remotely?

+++ Rick ---

Where are the log routines and their files?

did you enable Windows and basic authentication?

Yea, problem solved... thanks!

In my Web.Config file the Admin user was incorrect. After switching back to ANY, it started working correctly.