Configuration: 2 Physical Servers. 1. Server 2008 R2, Domain Controller named DnsDcServer. 2. Server 2008 with Hyper V running named BaseServer. 2.a. Virtual Server - Web Server 2008 R2 named WebServer, IIS installed. 2.b. Virtual Server - Server 2008 R2, named DbServer, SQL 2008 installed. Situation: Migrating existing application software from Server 2003 to Server 2008. Software Architecture: User Applications (.Exe's) <-> DCOM Application Components (.Exe's) <-> Database Applications (.Exe's) All applications and components work if operated on a single machine, namely DbServer. The database apps are started first. Then the user applications are manually started and they correctly launch the DCOM components locally and all modules communicate and execute as expected. Problem: 1. When the same user applications and components are installed on WebServer, the components get launched locally. In Component Services the components are configured to launch on DbServer. 2. When configuring the components, the location tab has the "Run application on this computer" unchecked and greyed out on WebServer and DbServer. I am not sure what Microsoft has changed within Server 2008 domain security that would cause this different behaviour. If I knew how to setup the security on 2008 so it behaved like 2003, probably it solve these two related issues. Also, is there a starter GPO that can be installed that converts Server 2008 to behave like Server 2003? You help will be much appreciated, Roger.

To investigate the source of: 2. When configuring the components, the location tab has the "Run application on this computer" unchecked and greyed out... I created another virtual server WS2008R2 full install, named it AppServer, and did NOT join the domain. I did not create any roles or install features, so its right out of the box. Then to register the app components, first I installed the VcRedist_x86.exe for 2005 and 2008. Then registered the app components with the /RegServer switch. In Component Services (DcomCnfg) for each component's properties on the Location tab the "Run application on this computer" is unchecked and greyed out! What is causing this behaviour? This is as near a virgin copy of Windows Server 2008 R2 as you can get!

To reproduce this DComCnfg error: 1.a. Use Visual Studio, Add new project, select Visual C++, select ATL Project, name it Component32. 1.b. In the ATL Project Wizard, select Application Settings, select Executable (EXE), select Allow merging of proxy/stub code, click Finish. 1.c. Build the project as is. The output will be Component32.exe. 2.a. Use Hyper-V and create a Virtual Windows Server 2008 R2. 2.b. Install VcRedist_x86.exe for 2008 so your new server will have the C++ runtime libraries. 2.c. Copy your simple ATL component to your new server: C:\Components\Component32.exe. 2.d. Register the simple component: C:\Components\Component32.exe /RegServer 3.a. Open Component Services, Computers, My Computer, DCOM Config, right click Component32, select properties. 3.b. Select the Location tab and there you have the error. "Run aplication on this computer" is grey. The ability for the administrator to specify where software will run is essential for anyone writing a Subscriber/Publisher application with connection points. This erroneous behavior of Server 2008 does not permit remote access or launching of a publisher on a server by a subscribing client. Has anyone been able to make this work with Server 2008 R2? It works just fine with Server 2003.

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: http://msdn.microsoft.com/en-us/library/ms678426(VS.85).aspx "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

On both Systems Win7 x64 and Win2k8R2 x64 the mmc comexp.msc /32 switch is not working! Any other suggestions?

On both Systems Win7 x64 and Win2k8R2 x64 the mmc comexp.msc /32 switch is not working! Any other suggestions? Is describing the correct solution for any service: http://social.technet.microsoft.com/Forums/en-US/winservergen/thread/239741f3-1ce7-476b-88b0-860d5e1724d2