Thursday, December 20, 2007

How to Overcome Windows Protected Groups Permissions Problems


Windows Active Directory protects certain built-in groups from ACL modifications. The purpose of this is to prevent these groups, and their members, from becoming inaccessible by applying restrictive permissions to them. For example, an administrator my accidentally (or maliciously) assign Deny All permissions to the Domain Admins group. Doing so will prevent the Domain Admins group members from managing the domain.

To fix this condition, the AdminSDHolder process reapplies default ACL permissions to all protected groups. This background occurs roughly once per hour. A side affect of this is that it removes the permissions inheritance attribute from all AD objects that are members of these protect groups. Membership is transitive, meaning that a user may be a member of a group that is a member of a protected group and will be affected by this process. A common side effect of this behavior is that affected users cannot change properties of their user object in AD or reset their own passwords using ADUC.

As a resolution you can modify the ACL permissions on the AdminSDHolder container in the System container of the domain. The ACL permissions applied to the AdminSDHolder container act as the "template" that is applied to all Windows Protected Groups.

The protected groups in Windows 2000 are:

  • Enterprise Administrators
  • Schema Administrators
  • Domain Administrators
  • Administrators

The protected groups in Windows Server 2003 and in Windows 2000 after you apply KB327825 or Service Pack 4 are:

  • Administrators
  • Account Operators
  • Server Operators
  • Print Operators
  • Backup Operators
  • Domain Administrators
  • Schema Administrators
  • Enterprise Administrators
  • Cert Publishers

In addition, the following users are also considered protected:

  • Administrator
  • Krbtgt
The following steps explain how to modify the permissions on this container to allow members of these groups to modify their own attributes and reset their passwords using ADUC.
  • Run Active Directory Users and Computers (ADUC) with Domain Admin rights

  • View advanced features by selecting Advanced Features from the View menu

  • Select the System container in the selected domain

  • Right-click the AdminSDHolder container and select Properties

  • Click the Security tab and the Advanced button

  • Under Permission Entries select SELF and click Edit

  • Assign SELF Full Control permissions. Click OK.

  • Click OK to close the Advanced Security Settings for AdminSDHolder window

  • Click OK to close the AdminSDHolder Properties window

The new settings will propagate to all members of the Windows Protected Groups the next time the AdminSDHolder background process runs (about an hour).

Monday, December 17, 2007

Wednesday, December 12, 2007

How to Tell Which Users Have an ActiveSync Partnership

It's always good to know who is using the technology we support. I have a customer who needed to know which users were utilizing Windows Mobile devices to access their Exchange servers.

Here's a one-liner PowerShell command that reports which users have ActiveSync partnerships configured in Exchange 2007:
Get-CASMailbox WHERE {$_.HasActiveSyncDevicePartnership} SELECT identity
In Exchange 2003, it's not quite that simple. The ActiveSync partnership is stored in a hidden folder within the user's Exchange mailbox. This folder can be exposed using mfcmapi (the Microsoft Exchange Server MAPI Editor).

Mailboxes do not have the hidden Microsoft-Server-ActiveSync folder by default. Once an ActiveSync partnership has been configured from the user's Windows Mobile device, the following folder structure is created under the Root Container:


Note that PocketPC may show as SmartPhone, depending on the device used.

While mfcmapi can view the Root Container structure for an individual maibox, this is not feasible for a multi-user enterprise. I contacted Microsoft PSS for a solution, but they said there was no way to do this programmatically. Fortunately, I found this excellent VBscript written by Glen Scales that does exactly what I was looking for.

Here's an example of the output that the script produces:


Viola! Just what the doctor ordered!

Tuesday, December 4, 2007

How to Forcibly Remove MOM Agents

I'm currently involved with a large System Center Operations Manager (SCOM) 2007 deployment. The client is moving from MOM 2000 to SCOM 2007.

In the course of deployment we're successfully removing the MOM agent via the MOM management console, but for some reason the agent software and OnePoint service remain on the servers. This causes various WMI and other errors on the newly unmanaged servers.
To fix this, I wrote a batch file that will forcibly remove the OnePoint service and all Microsoft Operations Manager 2000 software from the target server.

The usage is: KILLMOM [TargetComputer]
@echo off
if "%1"=="" goto Syntax
echo.
echo WARNING! This command forcibly removes the MOM agent from the target server.
echo.
echo Press CTRL-C to quit or
pause
echo.
sc \\%1 stop onepoint
ping 127.0.0.1 -n 40 > nul
sc %1 stop snmp
ping 127.0.0.1 -n 20 > nul
sc \\%1 delete onepoint
rd "\\%1\c$\Program Files\Microsoft Operations Manager 2000" /s /q
sc \\%1 start snmp
echo The MOM agent has been removed successfully.
goto End
:Syntax
echo Usage: KillMOM [servername]
echo.
:End

I keep this batch file on the MOM DAS and run it from there. You must be an administrator on the target computer to successfully uninstall the MOM agent.