Stubborn error- Logical Disk Manager service won't connect

varelg

While routinely preparing for 270 on my lab, I tried to connect to Disk Management to the other PC that I have in my local workgroup. The book says it's as easy as right-click on My Computer -> Manage -> Actions -> Connect to another computer -> and you choose the computer whose disks you need to manage. In the book it's nice and dandy but when I tried it myself, I ran into a stubborn error message that just won't go away no matter what of suggested solutions is applied.
Both my and the "remote" machine (that are in the same subnet) ping themselves fine. Both have set up exceptions in their firewalls for RPC, dmremote and File and Printer Sharing. Services that are needed are started (Logical Disk Manager, RPC, Plug&Play, COM+ Event System, COM+ System application, Volume Shadow Copy and System Even Notification), and necessary permissions on DCOM are set for Everyone and Anonymous to Remote.
At the machine from which I initiate the remote call I edited HKEY_CURRENT_USER\Software\Microsoft\Windows\Policies\Explorer where I created the DWORD value NoManageMyComputerVerb and set it to 0, as a kind of hail- Mary shot from the heap at the problem.
Microsoft suggested solutions had been tried and failed. Enthusiasts on forums either have this same question unanswered or answered by copy- paste already failed solution.
Is this some kind of a boogie man question that is damned to not be answered?
The exact message is "You do not have access rights to Logical Disk Manager on <remote computer name> with "unable to connect to Logical Disk Manager service" in the background. This message I get on both local and the computer to which I try to connect.
Both machines are using XP Professional SP 3.
Miffed.

Claymoore

Try starting the Logical Disk Manager Administrative Service on the target PC before launching the Disk Management snap-in. Disk Manager would start the service if it were launched locally, but may not be able to across the wire. The Virtual Disk service works the same way in Server 2003 and later OS versions.

Logical Disk Manager Administrative Service (System Services for the Windows Server 2003 Family and Windows XP Operating Systems)

varelg

I did as you suggested Claymore, to no avail. Services that are listed on which Logical Disk Manager Administrative Services depends are already started on the target machine.

MrAgent

So what I would do is make sure you are using the same account/password on both machines. I had to do something similar to let my Windows 7 workstation access my Windows 2008 hyper v server. I had to create the same account on both machines to allow access, and they both had to be in same workgroup.

varelg

Both are in the same workgroup and I tried the suggestion with the same account name and password on both machines. No avail. What's more, not only does Disk Manager refuse to give it up, other items in the Management window are refused access to remote machine, with a message like "Access denied" or "Error 5: access denied".

MrAgent

Have you seen this kb?

You cannot use the Computer Management feature on a Windows XP SP2-based computer to access Logical Disk Manager on a Windows Server 2003-based computer

varelg

Yes, ports required in that article are open and DCOM adjusted for permissions for remote logging as was required in that article. This didn't work.
After you suggested to create similar accounts on both machines I brought down firewalls but that didn't work either.
Some of the more dated posts on this subjects that I found while researching referred to SP2 breaking things up on remote disk management, but since SP2 initial release that has been documented and fixed. Safe Mode was also mentioned, but if I have to put my computer in safe mode just for the sake of remotely managing disks, then that's not an option.

varelg

Finally cracked it open. This article on further ironing security options on DCOM services on both machines helped. Things started working after the MMC service's security properties were set as described in the article.
Now that it's done, I will further recreate previous conditions and see why the heck it worked the way it did.
Adding to frustration, several dated posts I found on the net in blogs and forums with exactly my scenario were unanswered, and the resource that had the most answers according to google, was offline today.
I doubt something like this will be on the test however. It involved clicking through a lot of menus and can't simply be recreated in an exam sim.

varelg

Essentially, remote management of your workgroup computers via Computer Management console doesn't just work and you have to enable it by:
- poking holes in the firewalls of both remote and your machine for services dmadmin and dmremote (found as executables in C:\Windows\system32) and for RPC (port 135)
- setting up COM Security properties to allow remote machines access to COM on the host (Start -> Run -> dcomcnfg -> Component Services -> Computers -> My Computer right- click and choose "properties" and at COM Security tab allow remote access to appropriate groups).
- identical user accounts with identical passwords on both machines. This is an absolute must. They have to be created from scratch and not just renamed and password changed.
Although prep book says that simple click will connect you with Computer Management console of the remote machine in your workgroup, someone in some Service Pack/Automatic Update package broke things up without documenting it. Not entirely unknown practice that has been seen in some community projects, ahem ahem.
Off I go to play some more with Solaris...

KenC

Hi,
realise this is an old thread, but I came across it and got curious about it.

My question is: Is this solely a workgroup issue?

I have a domain scenario and I was able to connect to another PC (and vice versa). I had to follow the kb article posted by MrAgent to connect from my XP machine to my W2K3 server, but after that I was able to complete the task. Connection to XP machine from server worked fine once allowed through firewall.

I did not have to use the same username and password as suggested, so that's why I'm asking is it a workgroup issue.

Thanks, Kenneth.