After I restart my Server 2019 I get the following error trying to go to a west wind route:

Unknown application error

Retrieving the COM class factory for component with CLSID {D155EF20-D7B1-416A-A0ED-E29F4172C7F0} failed due to the following error: 8000401a The server process could not be started because the configured identity is incorrect. Check the username and password. (Exception from HRESULT: 0x8000401A).

If I log onto the server via RDP, then log into the west wind administration page and then click "Load Servers" then things start working. The West Wind Control Panel also pops up on my desktop.

Under Security I have the following:

Admin Account ANY

Authenticated User ANOVYS\jeff.roberts

Auth Mode NTLM

Server Account SYSTEM

So I think this is probably because it is trying to run as me but can't until I log in. Do I need to just change this user, and if so, how do I do that?

I got this working by following instructions here to run 32 Bit Version of DCOMCnfg:

https://webconnection.west-wind.com/docs/_4kg0z4g3p.htm

I am wondering if I skipped a step, or if this is standard to need to make these changes when deploying on a server that I don't plan on staying logged into?

DCOMCnfg configuration is manual, so if you change accounts you have to do this yourself.

If IIS Application Pool Identity is not configured (through Web Connection configuration or manually) you'll run under ApplicationPoolIdentity which has zero rights and likely can't run the Web Connection COM server at all.

Web Connection's auto configuration by default doesn't register COM server configuration and uses the default pass through security in IIS. This means IIS is set up to use the Application Pool identity - whatever account your Application Pool is set up to run under, which is what I would strongly recommend if at all possible rather than messing with DCOMCnfg. IOW, rather than changing the identity of the COM server, change the Identity of the IIS application which is then inherited by the FoxPro server. This is much easier in terms of configuration and is also the most configuration that you actually want to have for an 'application' where both IIS and your FoxPro server running under the same credentials.

If you must register DCOM for your FoxPro server, the yourApp_ServerConfig.prg file has the following at the end commented out:

*** COM Server Registration
IF IsAdmin() AND FILE("wcdemo.exe")
   RUN /n4 "wcdemo.exe" /regserver

   *** Optionally set DCOM permission - only set if needed
   *** requires that DComLaunchPermissions.exe is available
   * DCOMLaunchPermissions("Testproject2.Testproject2Server","INTERACTIVE")
   * DCOMLaunchPermissions("Testproject2.Testproject2Server","SYSTEM")
   * DCOMLaunchPermissions("Testproject2.Testproject2Server","username","password")
ENDIF

+++ Rick ---

All -

Unknown application error
Retrieving the COM class factory for component with CLSID {D155EF20-D7B1-416A-A0ED-E29F4172C7F0} failed due to the following error: 8000401a The server process could not be started because the configured identity is incorrect. Check the username and password. (Exception from HRESULT: 0x8000401A).

For anybody finding this message thread when searching for "8000401A" or any of the rest of the error message, there is also another resolution for a different use case. My issue didn't involve running DCOMCnfg at all.

I set up a new project on my default (#1) IIS website, using a new virtual, and used that to develop a small personal utility site. Once I got it mostly complete, I obtained a new domain name and created a new website in IIS. I manually configured the new website, making the various changes for the application pool and other settings required to allow IIS to work with the Web Connection framework. I tested my new domain name and the page popped right up with no problems.

However over the next several days, I found that trying to access the site, I'd get the message above. Like the original poster of this thread, I could log into the WC administrative page and click on Load One Server and everything worked again. However after a period of time where it would not get any hits, the COM server would unload itself, and then I'd get the same error message as before. It wouldn't start up on its own, but had to be manually started up from the admin page.

I strongly suspected it was due to moving the app from one website to a new one, and looking around, I found within the (myapp).ini file, under the [ServerConfig] section, entries for IISPath and Virtual..

IISPath=IIS://localhost/w3svc/1/root
Virtual=(myVirtual)

I changed the '1' in the IISPath to the appropriate IIS new website ID #, and cleared out the Virtual entry (since my new site ran from the root). Then I rebuilt the project and ran..

DO (myApp) with "CONFIG"

..and now everything works fine - the COM server automatically starts up when the site is hit, even after unloading due to inactivity, without me having to log in and manually start it up.

I'm not sure, but I believe this may be due to the exe being \regserver-ed with the appropriate configuration settings (now 'attached' to the right website or something) when (myApp)_ServerConfig.prg runs with the "CONFIG" parameter.

-Mike McDonald

Yeah but the issue likely is DCOM configuration after all. You just didn't set it manually.

Your server was configured for Interactive use which requires a logon. When you ran the config, the server was re-registered and the INTERACTIVE DCOMCnfg mapping was likely removed and now the server runs invisibly under whatever the Application Pool's identity is (LOCALSYSTEM by default).

The scenario you describe is a classic case of the INTERACTIVE user which only works with a logon and the only way to set that on the COM server is via DCOMCnfg.

+++ Rick ---