Finally.... After installing windows 7 - 32 bit and seeing that DcomCnfg worked led me to believe that the problem was 64 bit related. So I googled DcomCnfg 64 bit and found:
Kepware Server是32位的，所以要在32位程序下配置应用服务。
在控制台运行mmc comexp.msc /32即可。
"Dcomcnfg.exe and 64-bit Applications
On x64 operating systems from Windows XP to Windows Server 2008, the 64-bit version of DCOMCNFG.EXE does not correctly configure 32-bit DCOM applications for remote activation. This behavior causes components that are meant to be activated remotely instead being activated locally. This behavior does not occur in Windows 7 and Windows Server 2008 R2 and higher versions.The workaround is to use the 32-bit version of DCOMCNFG. Run the 32-bit version of mmc.exe and load the 32-bit version of the Component Services snap-in by using the following command line.
C:\WINDOWS\SysWOW64>mmc comexp.msc /32
The 32-bit version of Component Services correctly registers 32-bit DCOM applications for remote activation."
My suspicions were confirmed, although the article incorrectly has the sub-title: "Dcomcnfg.exe and 64-bit Applications"
The 64 bit version of DCOMCNFG does NOT work! The 32 bit version of DCOMCNFG does work.
I immediately tested this on Windows 7 - 64 bit: Start -> Run -> mmc comexp.msc /32
Then going to my 32 bit ATL exe component under DCOM Config -> properties -> location tab. All check boxes were available, none were grey. Furthermore the previously greyed unchecked "Run application on this computer" was now checked and available! Imagine that, previously shown unchecked and not editable, now shown correctly using the 32 bit version of DcomCnfg!
It is disappointing that the article says "This behavior does not occur in Windows 7 and Windows Server 2008 R2 and higher versions." Hello? Does anybody test this stuff? Clearly this statement in the article is false.
Anyway.... the solution to bad DcomCnfg behavior under 64 - bit Windows OS's is to use the 32 bit version of DcomCnfg.
Start -> Run -> mmc comexp.msc /32