WinXP Component Services

PsyOps

Pixelated
On an AD with a WinXP (SP3) machine. I'm trying to change peprmissions for DCOM. When launching dcomcnfg.exe I expand 'Component Services' then click on "Computers'. When I click on 'Computers' Component Services crashes. When I remove the machine from the domain this does not happen. It appears to be a setting in the Group Policy.

Any ideas?
 

Lamini

Member
if it works fine off the domain, then its a domain policy. logon as an admin on the machine while on the domain and check rsop. Theres registry settings as well, but if it's gonna be written over once your on the domain its kinda pointless to fiddle with it.
 

TurboK9

New Member
do you have domain admin privilidges?

If you can change it through gpedit, try finding it with ADSIedit. :shrug:
 

PsyOps

Pixelated
do you have domain admin privilidges?

If you can change it through gpedit, try finding it with ADSIedit. :shrug:

I have admin privileges but the problem will be in the group policy defined on the AD, not the local machine. I'm just not sure which setting within the group policy affects this.
 

PsyOps

Pixelated
if it works fine off the domain, then its a domain policy. logon as an admin on the machine while on the domain and check rsop. Theres registry settings as well, but if it's gonna be written over once your on the domain its kinda pointless to fiddle with it.

What is the path to rsop within the GP?
 

TurboK9

New Member
I have admin privileges but the problem will be in the group policy defined on the AD, not the local machine. I'm just not sure which setting within the group policy affects this.

First check and make sure DCOM Launch Service is enabled.

If not, enable it. If you can't, or it 're-disables' this is what the POL is controlling.

Check -> Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options - DCOM entries.
 

PsyOps

Pixelated
First check and make sure DCOM Launch Service is enabled.

If not, enable it. If you can't, or it 're-disables' this is what the POL is controlling.

Check -> Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options - DCOM entries.

In group policy (gpedit) the two DCOM options are defined. I added in the the user levels I need. When I view these in the rsop.msc they are grayed out.

Try to remember I have to make these changes on my AD Group Management Objects, not on the local machine.
 

TurboK9

New Member
In group policy (gpedit) the two DCOM options are defined. I added in the the user levels I need. When I view these in the rsop.msc they are grayed out.

Try to remember I have to make these changes on my AD Group Management Objects, not on the local machine.

Right. I was thinking go through ADSIedit and root around to the DCOM entries.

The tree should be similar.

By chance was there a DC recently added or removed forcefully? If so re-setting the op master etc may help. I've had pretty nasty DCOM issues after loosing a DC and having to force removal from the AD. Just saying. :shrug:
 

PsyOps

Pixelated
Right. I was thinking go through ADSIedit and root around to the DCOM entries.

The tree should be similar.

By chance was there a DC recently added or removed forcefully? If so re-setting the op master etc may help. I've had pretty nasty DCOM issues after loosing a DC and having to force removal from the AD. Just saying. :shrug:

But you have to run ADSIedit on the local machine right?

We recently (within the past 6 months) installed a DC. The GPs to each workstation and server are forced from the DC. Any previous local settings are no longer used unless removing the machine from the domain and logging in locally.

The problem we are having is we are trying to do Retina scans and apparently some permissions need to be set on DCOM that allow the scans to work. Here are the instruction we were given to set this:

Type this in a command window while logged in as an administrator:

c:> dcomcnfg.exe

1. Click Component Services
2. Click Computers
3. Right-click My Computer
4. Properties
5. Click on the Default Properties tab
6. Check "Enable Distributed COM on this computer"
7. Default Authentication Level: Connect
8. Default Impersonation Level: Identify

When doing step 2, dcomcnfg crashes; it completely disappears from the screen. It works if we remove the machine from the domain and log in locally. So I am assuming it is a group policy setting being pushed out from Active Directory.
 
Last edited:

TurboK9

New Member
But you have to run ADSIedit on the local machine right?

We recently (within the past 6 months) installed a DC. The GPs to each workstation and server are forced from the DC. Any previous local settings are no longer used unless removing the machine from the domain and logging in locally.

The problem we are having is we are trying to do Retina scans and apparently some permissions need to be set on DCOM that allow the scans to work. Here are the instruction we were given to set this:



When doing step 2, dcomcnfg crashes; it completely disappears from the screen. It works if we remove the machine from the domain and log in locally. So I am assuming it is a group policy setting being pushed out from Active Directory.

OK :confused:

Are you not allowed to log on locally to a DC in your AD forest? If it is a GPOL in the AD, then yes, you'll have to run ADSIedit locally on any DC in your forest... there is no longer PDCs and BDCs, just DCs, so any DC priviledged server should do it. If it's indeed a GPOL issue, there really isn't any way to resolve it without editing the AD either through ADSI or gpedit.msc.
 
Last edited:

PsyOps

Pixelated
OK :confused:

Are you not allowed to log on locally to a DC in your AD forest? If it is a GPOL in the AD, then yes, you'll have to run ADSIedit locally on any DC in your forest... there is no longer PDCs and BDCs, just DCs, so any DC priviledged server should do it. If it's indeed a GPOL issue, there really isn't any way to resolve it without editing the AD either through ADSI or gpedit.msc.

It's pretty obvious I'm showing my AD deficiencies. :blush: I’m pretty new at it. I have admin rights to the DC.

If I launch ADSI or gpedit from the DC locally, wont any changes I make there only be local to that server? Or will it propagate to all machines on the domain? It’s my understanding that you affect GP changes to your machines on the domain by using the Group Policy Management tool.
 

TurboK9

New Member
It's pretty obvious I'm showing my AD deficiencies. :blush: I’m pretty new at it. I have admin rights to the DC.

If I launch ADSI or gpedit from the DC locally, wont any changes I make there only be local to that server? Or will it propagate to all machines on the domain? It’s my understanding that you affect GP changes to your machines on the domain by using the Group Policy Management tool.

It depends on the changes you make, whether you make them in the local policy or the AD. Modifying the AD objects for DCOM should release them for the entire AD. Unless you specify a machine or group, you'll cover the entire forest. Be careful there, there are cases where security may be an issue if you free up DCOM security settings for machines that don't require it.

I'd create a group for each machine that will use the retinal scanners, and change the policy for DCOM for the group.

Going in through GPEDIT should do it (from the DC), I wouldn't mess in ADSI edit if you are new to AD. You screw up a GC entry and you screw your AD.
 
E

EmptyTimCup

Guest
It's pretty obvious I'm showing my AD deficiencies. :blush: I’m pretty new at it. I have admin rights to the DC.

If I launch ADSI or gpedit from the DC locally, wont any changes I make there only be local to that server? Or will it propagate to all machines on the domain? It’s my understanding that you affect GP changes to your machines on the domain by using the Group Policy Management tool.

IIRC ...

you can set what level the Group Policy applies .... with in the Organizational Unit ....

Domain, Local Computer, Local Users .... etc
 
E

EmptyTimCup

Guest
Last edited by a moderator:

PsyOps

Pixelated
this looks like a good starter introduction ...


Microsoft GPMC Group Policy Management Console. Windows Server 2003

Download GPMC

Group Policy Management Console (Windows)

down the left side are different units in the Forest or domain if you only have one ... in here you can make specific policies for your Admin group, maybe you sales forces gets some more leeway because they work outside of the office ... and you lock down average user tighter ...

http://www.petri.co.il/images/gpmc.gif

Sorry I wasn't more clear on this. I know how to access GPMC, and configure it, and it's already configured with our different policies and groups. The part I don't know is where to find the setting for the problem mentioned in my OP.
 
E

EmptyTimCup

Guest
Any ideas?

not sure why it crashes ...

Security-Related Policy Settings

Using Group Policy to Manage Computer-Wide DCOM Access Restrictions

To manage the computer-wide ACLs in an enterprise, you can use the following Group Policy settings in Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options:

*

DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax. You can use this setting to grant access to all the computers to particular users for DCOM application in the enterprise through Group Policy.
*

DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax. You can use this setting to grant launch or activation permissions to all the computers to particular users for DCOM application in the enterprise through Group Policy.



does this help ?
 

PsyOps

Pixelated
not sure why it crashes ...

Security-Related Policy Settings





does this help ?

These were the first settings I messed with. I've tried setting the ACLs for a wide variety of admin-level settings and now have it set to 'Everyone' with full privileges.

I can run dcomcnfg.exe. It just crashes when trying to open the 'computers' directory. This seems to be a persmission issue, but I speculate it's something more related to a registry setting because it is a problem within dcomcnfg.

Thanks for the help.
 
Last edited:

TurboK9

New Member
Wow you still cranking on this?

Here is what I would do...

First three 'spare' machines you can use to create a little test network.

Machine one, install your server OS.

Machine two, server OS.

Machine 3, whatever OS your user is running (XP, 7, etc)

Now, Connect M1 to the network and join the domain, allow the AD and GC to propogate to it. Disconnect, using NTDSUtil, forcefully assign all AD roles to it. DO NOT REATTACH TO ACTUAL NETWORK AT THIS POINT!!

Set up M2 with it's own 'faux' domain.

Network M1 and M3 and try to recreate the problem.


Network M2 and M3 and try to recreate.

If the problem recurs when join M1 but not M2, then you know you have a GPOL or AD specific issue. If it doesn't recur on either, than you have an issue specifically relating to your network itself. You may have packet restrictions etc on your routers (I'm assuming there is no firewall between the user PC and server).
 

PsyOps

Pixelated
Wow you still cranking on this?

Here is what I would do...

First three 'spare' machines you can use to create a little test network.

Machine one, install your server OS.

Machine two, server OS.

Machine 3, whatever OS your user is running (XP, 7, etc)

Now, Connect M1 to the network and join the domain, allow the AD and GC to propogate to it. Disconnect, using NTDSUtil, forcefully assign all AD roles to it. DO NOT REATTACH TO ACTUAL NETWORK AT THIS POINT!!

Set up M2 with it's own 'faux' domain.

Network M1 and M3 and try to recreate the problem.


Network M2 and M3 and try to recreate.

If the problem recurs when join M1 but not M2, then you know you have a GPOL or AD specific issue. If it doesn't recur on either, than you have an issue specifically relating to your network itself. You may have packet restrictions etc on your routers (I'm assuming there is no firewall between the user PC and server).

Not working this issue so much anymore. It's not causing any real operational problems. We need to set the DCOM permissions for the computers directory in order to run Retina Scans. We have a group coming in to scan us and claim their Retina can't see our workstations. I happen to think it's a problem with their Retina setup since our Retina works fine. But the who issue of dcomcnfg crashing is more of an annoyance that I would like to find the answer to.

In my OP I mentioned that when I remove any machine from the domain the problem doesn't occur. This tells me it's an AD/GP issue. Between the DC and client there are only switches with no restrictions. No firewall.
 
Last edited:
Top