Question

OS – Windows 2008 server R2 X 2 (firewall disabled on both machines)

I wish to take advantage of GlassFish 3.1.2 Windows DCOM feature to setup communication between GlassFish DAS and a remote node. I’ve successfully followed Byron Nevins instructions on using GlassFish 3.1.2 DCOM Configuration Utility

However I’m having an issue validating DCOM following the instructions in GlassFish 3.1.2 Guide – 2 Enabling Centralized Administration of GlassFish Server Instances

When I run command validate-dcom –passwordfile C:/Sun/AppServer/password.txt -v 192.168.0.80 I get the following output:

asadmin> validate-dcom --passwordfile C:/Sun/AppServer/password.txt -v 192.168.0.80
remote failure:
Successfully verified that the host, 192.168.0.80, is not the local machine as required.
Successfully resolved host name to: /192.168.0.80
Successfully connected to DCOM Port at port 135 on host 192.168.0.80.
Successfully connected to NetBIOS Session Service at port 139 on host 192.168.0.80.
Successfully connected to Windows Shares at port 445 on host 192.168.0.80.
The remote file, C: doesn't exist on 192.168.0.80 : Logon failure: unknown user name or bad password.

Password file, password.txt, contains a single entry:

AS_ADMIN_WINDOWSPASSWORD=my-windows-password

I have double-checked I can successfully login with my windows password on the remote machine 192.168.0.80. I’ve also tried this test with two Windows XP professional machines and get the same error.

Also performed this operation by creating a New Node in Admin Console, got the same error:

Cannot figure what is going wrong or what I may be missing

Thanks in advance

Answer 1

I have had similar issues while setting up the new production env. at work last friday, and could not find any useful information on the interwebs, except people encountering the same issue, some with comments as fresh as the day I was looking it up.

So after a rather excessive amount of painful, in-depth debugging, I was able to figure out a few things:

1. You must explicitly specifiy the local windows user you create for the purpose of running glassfish in both the add-node dialog, and the validate-dcom subcommand (option -w), else it will either default to ‘admin’ or the user the DAS is running as.

2. There is a bug in validate-dcom that causes it to ignore whatever you specify as the test directory. No matter what you do it will always use C:\, and result in “access-denied”.

3. The documentation omits another registry key that must be given access to in order for WMI to work

Regarding the first issue, you will most likely encounter it if your nodes are not part of a domain or you are using a local account. Windows NT6+ has a new default security policy that prevents local users from elevating privileges over the network, which causes that test to fail, necessarily, seeing how writing to the root of a system drive not something one can do without elevation.

I previously blogged about it for someone to stumble upon it if needed:
http://www.raptorized.com/2008/08/19/access-administrative-shares-on-server-2008vista/

The gist of it is that you have to navigate to the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

and create a new DWORD named LocalAccountTokenFilterPolicy with a value of 1.

There is no need to reboot, the first, broken test should pass. However you will then see an error about being unable to connect to WMI, and it will fail again.

To remedy this, you must also take ownership and grant your local service account user full control over the following registry key, in addition to the other ones described in the HA Administration Guide:

HKEY_CLASSES_ROOT\CLSID\{76A64158-CB41-11D1-8B02-00600806D9B6}

Afterwards, validate-dcom should report success and you will be able to add it as a node, and create instances on it.

I hope this helps, because the seeming lack of activity from Oracle on that issue was infuriating.

I am also less than pleased by the hackish, ugly, insecure nature of the DCOM support in Glassfish 3 🙁