The SysAdmin Network

No more hiding in the server room

DCOM, or Distributed Component Object Model, is a technology in Windows allowing remote communication between programs. WMI, in particular, uses it to communicate. A lot of business oriented server applications use it, as well, to communicate between layers. If you've ever spent any time with DCOM you probably have come to understand just how fragile it can be. When it works, it's like magic, but when it doesn't it can be a serious hair pulling experience.

One of the more fragile bits of DCOM is its security. There are are four different areas of DCOM each with their own ACLs (Access Control Lists) and a problem in any one of the four can lead to hard to track down problems. To make matters worse, many applications that use DCOM will alter the security settings, potentially breaking DCOM access for other programs on the same computer. Sometimes it's necessary to just reset DCOM security to its default state, just as it was when Windows was installed.

Last week I found a quick way to do this, but it does require editing the registry so the standard warnings and "do not try this at home" apply. However, if you're stuck fixing a problem down in the guts of DCOM security, editing the registry is the least of your worries.

You can view the DCOM ACLs by running dcomcnfg.exe and navigating to Component Services > Computers > My Computer > Right-click > Properties > COM Security tab.


The ACLs are stored in the registry under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole, in the following binary values:

  • DefaultAccessPermission
  • DefaultLaunchPermission
  • MachineAccessRestriction
  • MachineLaunchRestriction

To reset them, all you need to do is to delete these values. If DCOM doesn't find any ACLs here, then it will use its defaults. Any changes you make will then re-create the values. Of course, you'll want to back them up before you delete them, or you could just rename them to be safe.

Views: 220

Tags: dcom, reset, security

Robert Chipperfield Comment by Robert Chipperfield on February 11, 2010 at 1:34am
"when it doesn't it can be a serious hair pulling experience" - Amen to that!

Another useful tip is that a lot of DCOM launch or activatoin failures get logged to the event log (component name DCOM) with something that almost approaches a helpful error message! Working out how to fix it can be a little trickier, but at least it's a hint as to what's going wrong.

And by the way - if anyone's ever wondered what the mysterious "dllhost.exe" process is, that's what's known as a "COM Surrogate". Basically it lets you move part of an application out into its own process without having to recompile it.

It's handy if you've got legacy code that can't co-exist with modern code, but you can't change it - for example, if you have a library that needs to run in 32-bit mode, but you'd like the rest of your application to run 64-bit.

Comment

You need to be a member of The SysAdmin Network to add comments!

Join The SysAdmin Network

© 2012   Created by Elizabeth Ayer and Michael Francis.   Powered by .

Badges  |  Report an Issue  |  Terms of Service