Granting the Replicating Directory Changes Permission

At a lot of my customers I run into the job of granting and documenting having granted the access right "Replicating Directory Changes" for the Active Directory Management Agent service account.

The necessary permissions are documented nicely by Microsoft in http://support.microsoft.com/kb/303972/en-us; however, I like scripting because it's repeatable and you're sure that its gets done the right way each time - and also, you can delegate the task of granting the permission to someone else, i.e. the customers directory administrator.

I know that most of this stuff is old news, but I just wanted to share the script that I use at my customers to grant the permission; hopefully this can be useful to others as well.

The syntax for running the script (from a PowerShell prompt as an account holding he appropriate permissions) is something like this if you wanted to grant the permission to the user called SVC-FIM-ADMA -

.\Grant-ReplicatingDirectoryChanges.ps1 -Account SVC-FIM-ADMA

Usually, though, I tend to recommend my customers to create a new domain security group and grant the permission to that group instead. And then just add the MA account that needs the permission to that group. Seems like a more sustainable approach, allowing you to delegating the permissions to another account without having to run the script again. If you want to use this approach, the script will work as well - just give the group name as a parameter instead of a username.
Enjoy and here’s the script (remember to save it as a .ps1 file)

# Grants necessary permissions for AD MA Service Account for
# FIM 2010 or ILM 2007 according to directions in
# http://support.microsoft.com/kb/303972/en-us article
#
# Please note that this script has only been tested on Windows Server 2008 R2
param (
 $Account
)

# get domain environment information
$RootDse = [ADSI] "LDAP://RootDSE"
$DefaultNamingContext = $RootDse.defaultNamingContext
$Domain = [ADSI] "LDAP://$DefaultNamingContext"
$DomainNetBIOSName = $Domain.Name.ToString().ToUpper()
$DomainFQDN = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()

# translate to SID (I like this due to it's uniqueness characterictics
$UserPrincipal = New-Object Security.Principal.NTAccount("$DomainNetBIOSName", "$Account")
$SID = $UserPrincipal.Translate([System.Security.Principal.SecurityIdentifier]).Value

DSACLS "$DefaultNamingContext" /G "$($SID):CA;Replicating Directory Changes";

The Granfeldt PowerShell Management Agent

UPDATE: September 11, 2012 - Find new version here http://blog.goverco.com/p/powershell-management-agent.html

I'm pleased to announce that my PowerShell Management Agent has been released and is available upon request.

The Granfeldt PowerShell Management Agent is a diverse Management Agent (MA) that can be used for many different purposes. Basically, any task that can be done in PowerShell can be triggered through this MA, making it very flexible and a regular hybrid MA.

The MA is built using the Extensible Management Agent (ExMA) framework provided as part of the Forefront Identity Manager 2010 (FIM 2010) product. Upon request, a version can be made available Microsoft Identity Lifecycle Manager 2007 (ILM 2007).

The Management runs as an export-only Management Agent that allows for a PowerShell script to be run for each object that is provisioned to the Connector Space (CS) of the Management Agent. The name of the PowerShell script to be run must follow each object when it is provisioned in the attribute named ScriptFullPath. The script will run on add, modify and delete of objects in the CS.

By using traditional provisioning code or Synchronization Rules in FIM, you can provision new instances of objects for which to run scripts.

The following shows an example of a CS object being passed to the script –

Id: 464286ED-5F81-4A82-8172-EA1549AC0901
ScriptFullPath: C:\Scripts\Manage-HomeDirs.ps1
uid: User1
displayName: Test User1
homeFolderRoot: \\fs001\HomeFolders

When this object is exported to the script, the actual PowerShell script command line will be –

C:\Scripts\Manage-HomeDirs.ps1 –DN 464286ED-5F81-4A82-8172-EA1549AC0901 –Id 464286ED-5F81-4A82-8172-EA1549AC0901 –ObjectClass person –ModificationType Add –ChangedAttributes uid, displayName, homeFolderRoot –uid User1 –displayName “Test User1” –homeFolderRoot \\fs001\HomeFolder

If you'd like to receive a version of the code for testing purposes, please drop me an mail on soren@granfeldt.dk; please let me know if you are using ILM 2007 or FIM 2010, so that I can get the correct version to you.

The MA is also available for purchase; please contact me for price and details.

Debug information in Management Agents and Workflows

When I write custom workflows or XMA's for ILM 2007 and FIM 2010, I like to include a lot of logging to enable customers to debug if something happens - and of course for debugging when I'm testing the code.

I usually use System.Diagnostics.Debug.WriteLine to write to the attached debugger, i.e. Mark Russinovich's DbgView or similar. The nice thing about System.Diagnostics.Debug.WriteLine is that the code will be ignored once you compile a Release build. However, recently a customer of mine would like to have this debug information stay in and be processed even in the Release build.

So how do you go about this without rewriting the logging code entirely?

Tadada, System.Diagnostics.Trace.WriteLine to the rescue. Using Trace.WriteLine instead of Debug.WriteLine make sure that the code is processed no matter the build type.

Features of a Home Directory Management Agent?

I'm currently working on a Management Agent for provisioning and deprovisioning home directories (and other directories) for users in ILM / FIM environments. I do a lot of Proof of Concepts and a typical scenario is home folder handling. Therefore I'm working on building a generic homefolder MA that rocks and is highly customizable. Some basic features currently are -

1. Create and apply ACLS for user
2. Move / rename based on, i.e. sAMAccountName
3. Deletion / removal

I'd very much like some additional feature that you see customers may need in the real world. I'll make the MA generally available for testing / PoC's when I'm done.