A couple of days ago, the .exe running our Intranet suddenly became unable to access any UNC shares, either files or printers, on itself or any other machine. It's a Windows 2012r2 server, and it's been running fine for almost a year.

From the server's command line, there is no problem. It's just the .exe running under IIS that has this problem.

The .exe can use a local file: e.g.

use e:\datatables\datafile.dbf

use \\lcoalhost\datatables\datafile.dbf

Trying to copy a print job from a local text file also fails. e.g.

copy file textfile.txt to \\printserver\print

Shelling out to DOS from within the VFP .exe also fails, e.g.
! copy textfile.txt /b \\printserver\printer

If we change the share permissions to allow 'everyone', then the .exe can access files on the share. But that's not a good workaround.

The identically configured backup server doesn't have this problem. We can't find any differences between the two machines.

(Perhaps unwisely) we run the .exe using the domain administrator account identity. So it shouldn't be a permissions issue.

We did find some 10020 errors in the event log, and tried this to no avail.
http://www.itexperience.net/2008/12/30/event-id-10020-the-machine-wide-default-launch-and-activation-security-descriptor-is-invalid/

It's almost like IIS is shielding our .exe from accessing shares.

Has anyone run into something like this?

.. Geoff

I suspect your permissions aren't what you think they are - you should probably dump out what actual account your EXE is running when you're trying to access the resources. Make sure there isn't some issue with permissions getting switched (like with Impersonation which you shouldn't be using anyway)...

Also keep in mind that when running under IIS you may not have access to profile data (unless you turn it on in the ApplicationPool) so if there's some sort of look up or other dependency based on profile (HKCU reg keys and local user folders like AppData/Documents) required that won't work.

+++ Rick ---

use e:\datatables\datafile.dbf

use \\lcoalhost\datatables\datafile.dbf

copy file textfile.txt to \\printserver\print

The DComcnfg identity is Domain\Administrator.

So... turns out that somehow web.config in our application directory got changed from
<add key="MessagingMechanism" value="Com" />
<add key="MessagingMechanism" value="File" />

Changing this line back fixed the issue.

Thanks for pointing us in the right direction.

.. Geoff

use e:\datatables\datafile.dbf

use \\lcoalhost\datatables\datafile.dbf

copy file textfile.txt to \\printserver\print

This is one more readson why I recommend to NOT use DCOM impersonation for your COM servers, but rather rely on the security environment from the Web server using the Application Pool Identity. Besides being much easier to administer (there are no policy issues as there can be DCOM) it provides a consistent execution environment for the entire Web application. In this context I'd consider both the IIS application and the Web COnnection application a single environment and this provides the same security context.

When you do both COM and File based will run in the same execution evnironment because both the COM server and File Server will be launched from the same execution context of IIS's Application pool.

So do yourself a favor and use AppPool Identity and reset the DCOM impersonation back to the default of the Launching User to remove one more potentially troubling configuration step.

+++ Rick ---

use e:\datatables\datafile.dbf

use \\lcoalhost\datatables\datafile.dbf

copy file textfile.txt to \\printserver\print

I must have accidentally clicked the "Switch" link on the Web Connection Module Status Page, switching the system from Com to File, resulting in our permission issues.

Could you please update two pages in the documentation? We were using them for troubleshooting, but didn't know then what we know now.

1) Windows 8, 7, Vista, 2008 and 2012 Configuration
"Once you've created the Application Pool select it in the list and click on Advanced Settings. In the property sheet that appears set the Identity for the Application Pool to LocalSystem."

2) Manual COM Server Configuration
"We recommend application pools running under the SYSTEM account or a custom configured account to allow access to specific resources."

I see your current recommendations in "Startup Error Handling and Detecting Server COM Load Errors", but I never made it to that page.

Cheers
.. Geoff

use e:\datatables\datafile.dbf

use \\lcoalhost\datatables\datafile.dbf

copy file textfile.txt to \\printserver\print

+++ Rick ---

use e:\datatables\datafile.dbf

use \\lcoalhost\datatables\datafile.dbf

copy file textfile.txt to \\printserver\print

In the help page "Startup Error Handling and Detecting Server COM Load Errors", you say:

"The easiest way to ensure COM servers can be launched with the appropriate rights is to set up IIS the Application Pool Impersonation to the appropriate account that has rights to access your local file system, data files, network etc. and don't touch the DCOM configuration at all. That way DCOM can just inherit the impersonation and nothing else needs to be configured. If you've already configured DCOM Impersonation you can switch it back by setting the Impersonation to The Launching User."

In the two help topics, "Windows 8, 7, Vista, 2008 and 2012 Configuration" and "Manual COM Server Configuration", you suggest that the Application Pool run under the local system account.

Our server was set up so that the Application Pool ran under the local system account, and the DCOM identity was an account that could access the local files and network shares. When I accidentally clicked the link on the ISAPI config page that switched from COM mode to File mode, our line-of-business application suddenly could not access network shares, and we didn't know why. It was because the identity changed from the named account to System, and System can't access network shares on other computers.

As this was not an intentional change, it took a few days for us to figure out what happened.

Following the advice in "Startup Error Handling and Detecting Server COM Load Errors" would solve that problem, because Com and File modes both run with the Application Pool's identity.

What I'm suggesting is that you change the two help topics from suggesting that the Application Pool runs under the local system account to "an account with appropriate rights to your local system, data files and network shares".

.. Geoff

use e:\datatables\datafile.dbf

use \\lcoalhost\datatables\datafile.dbf

copy file textfile.txt to \\printserver\print