However Alex’s script uses Excel which I don’t have installed in my lab and don’t really want. So I’ve taken his source lists and his concept and written a little powershell script to do much the same thing.

You can download it from here.

PreReqs

Custom sync rules do involve .NET coding, so you’re going to need Visual Studio installed on the Sync server. My example code in is VB.NET so you’ll need the Visual Basic libraries installed to use them.

And it’s only a minusculey tiny bit of code, okay?

I will assume you’ve already managed to create your AD and FIM management agents, and that you have already sucessfully imported or joined the group members – ie the users and contacts.

The “member” attribute is relational, meaning it effectively points to other objects that it also knows about. To maintain the referential relationship from AD through to the FIM Portal you must satisfy the following requirements:

• The groups and their member objects must exist within the connector space of the same AD MA. You can’t import groups from one MA and users from another – you have to have the groups and users together.
• The groups and their members must be joined to their metaverse counterparts, either through Join or Projection rules.
• The groups and their members must be exported through the same FIM MA to the FIM Portal (though AFAIK you can only have one FIM MA anyway).

Step 1: Importing the AD Groups into the Metaverse

First make sure that the OU(s) containing the groups are within the scope of your MA.
Next check the “group” object type.Note I also have my potential group member object types selected, and within the scope of the MA – see the comment above about maintaining references in the prereqs section above.
And make sure the following attributes are selected: displayName, domain, groupType, member, sAMAccountName, (and for Distrubution Lists) mail, mailNickname.
Create a Projection Rule. This will project AD groups as new group objects in the Metaverse. Note the following points: You should also create a Join Rule so that already-projected groups may be rejoined automatically if they happen to become disconnected, If you want some groups to be ignored then the simplest way is with a Connector Filter. Otherwise you can use a coded Projection Rule, but I won’t be going into that here.
Next create Direct import flow rules for the following attributes:  displayName → displayName sAMAccountName → accountName member → member mail → mail mailNickname → mailNickname
At this point you can actually save the MA and go ahead and run an Import-Sync. What you should see is some group objects projected into the Metaverse.If you’ve already mapped the group object type in the FIM MA you should see objects created there too, but don’t try to export them yet, we need to add a few more attributes.
Now go back into your AD MA and add the following Advanced import flow rules:  Constant: your NETBIOS domain name → domain Constant: “Owner Approval” → membershipAddWorkflow Constant: “false” → membershipLocked groupType → Rules Extension: “import_scope” → scope groupType → Rules Extension: “import_type” → type
When you try and save the MA now you should get this error: “Rules Extension validation error: Please specify a valid rules extension name.”When you click OK you will be taken to the place where you can specify the name of the dll where those two advanced rules (import_scope and import_type) are to be found. In fact we haven’t written the dll yet, but that’s ok, just accept the default name.
Now it is time to create the extension project.Select your MA and click Create Extension Project. You want to create a project of type “Rules Extension”.Check the default name – it should be the same as already set in the MA in the previous step (if it somehow isn’t don’t worry, you can always change the dll referenced in the MA later). The only thing you might want to change is the folder where the project will be created. When you’re ready, click OK and the new project will be created and opened in Visual Studio for you (assuming you installed Visual Studio on the server).
Now fill in the MapAttributesForImport section of the project as shown here.Once you’ve done that you can compile the code. The dll shoud be put straight into the correct folder for you (normally C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Extensions).	Public Sub MapAttributesForImport(ByVal FlowRuleName As String, ByVal csentry As CSEntry, ByVal mventry As MVEntry) Implements IMASynchronization.MapAttributesForImport Select Case FlowRuleName Case "import_type" Select Case csentry("groupType").IntegerValue Case 2, 4, 8 mventry("type").Value = "Distribution" Case Else mventry("type").Value = "Security" End Select Case "import_scope" Select Case csentry("groupType").IntegerValue Case 2, -2147483646 mventry("scope").Value = "Global" Case 4, -2147483644 mventry("scope").Value = "DomainLocal" Case Else mventry("scope").Value = "Universal" End Select Case Else Throw New EntryPointNotImplementedException() End Select End Sub
Now you should be able to Sync the AD MA and check how the group objects look in the Metaverse.

Step 2: Exporting the Groups from the Metaverse to the FIM Portal

There are a couple of Portal MPRs that must be enabled to allow the Sync Service to create groups in the Portal.
If you haven’t already done so, select the group object type in your FIM MA.
And add the mapping to the Metaverse group type.
Now all you should need to do is add simple export flow rules for these attributes: accountName, displayName, domain, scope, type, membershipAddWorkflow, membershipLocked, member, (and for Distribution groups) mail, mailNickname .
Run another Sync on the AD MA and now you should be able to see the group objects in the FIM connector space, ready to export.
After running an Export from the FIM MA the groups should be in the Portal, and you can start to manage them there.Note there is an error being reported about selecting a manger. If you do happen to have the group manager field populated in AD then by all means go ahead and import it from AD through to the Portal. Otherwise you will have to chose a manager directly in the Portal.

Troubleshooting FIM MA export errors

The FIM MA can give you some rather cryptic looking failed-creation-via-web-services messages, but usually if you read them properly you can work out the problem.

1. Missing Required Attribute

Here I have forgotten to populate the “Domain” attribute

2. Incorrect Attribute Value

Some attributes in the Portal Schema have validation strings listing which values are allowed. Here I’ve tried to export a type of “Distribution List” instead of “Distribution”, and that has been blocked.

Fault Details: <RepresentationFailures xmlns="http://schemas.microsoft.com/2006/11/ResourceManagement" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><AttributeRepresentationFailure><AttributeType>Type</AttributeType>
<AttributeValue>Distribution List</AttributeValue><FailureMessage>The specified attribute value does not satisfy the regular expression.</FailureMessage><AttributeFailureCode>ValueViolatesRegularExpression</AttributeFailureCode></AttributeRepresentationFailure></RepresentationFailures>


3. Permissions failure

Your MPRs need to allow the Built-In Synchronization account to create Group objects in the Portal. In this rather long-winded messages there are a few immediate giveaways.

Exception: ManagementPolicyRule
Stack Trace: Microsoft.ResourceManagement.WebServices.Exceptions.PermissionDeniedException: ManagementPolicyRule —> System.Data.SqlClient.SqlException: Reraised Error 50000, Level 16, State 1, Procedure DoEvaluateRequestInner, Line 462, Message: Permission denied.
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
at System.Data.SqlClient.SqlDataReader.ConsumeMetaData()
at System.Data.SqlClient.SqlDataReader.get_MetaData()
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
at System.Data.SqlClient.SqlCommand.ExecuteReader()
at Microsoft.ResourceManagement.Data.DataAccess.DoRequestCreation(RequestType request, Guid cause, Guid requestMarker, Boolean doEvaluation, Int16 serviceId, Int16 servicePartitionId)
— End of inner exception stack trace —
at Microsoft.ResourceManagement.WebServices.RequestDispatcher.CreateRequest(CreateRequestDispatchParameter dispatchParameter)
at Microsoft.ResourceManagement.WebServices.RequestDispatcher.CreateRequest(UniqueIdentifier requestor, UniqueIdentifier targetIdentifier, OperationType operation, String businessJustification, List`1 requestParameters, CultureInfo locale, Boolean isChildRequest, Guid cause, Boolean doEvaluation, Nullable`1 serviceId, Nullable`1 servicePartitionId)
at Microsoft.ResourceManagement.WebServices.RequestDispatcher.CreateRequest(UniqueIdentifier requestor, UniqueIdentifier targetIdentifier, OperationType operation, String businessJustification, List`1 requestParameters, CultureInfo locale, Boolean isChildRequest, Guid cause, Boolean doEvaluation)
at Microsoft.ResourceManagement.WebServices.ResourceManagementService.Create(Message request)ManagementPolicyRule

Stack Trace: at Microsoft.ResourceManagement.WebServices.ResourceFactoryClient.Create(Message request)
at Microsoft.ResourceManagement.WebServices.ResourceFactoryClient.Create(Create createBody)
at Microsoft.ResourceManagement.WebServices.Client.ResourceTemplate.CreateResource()

Inner Exception: Policy prohibits the request from completing.

Some users were unable to access DFS via the domain name:  The error was

"\\mydomain.com\dfs is not accessible. You might not have permission to use this network resource"

However there was clearly no permissions issue. The users could access the DFS shares just fine via “\\dcname\dfs”.

Once I tried to net view the namespace the problem became clear:

net view \\mydomain.com

DFS   Disk   [Offline Share]
NETLOGON  Disk  Logon server share
SYSVOL  Disk  Logon server share

Windows 7 had become completely convinced that the entire DFS was “Offline” and that appeared to be that.

Instead of trying to figure out why this had happened I decided to disable Offline Files. This was the next problem – I went through the Control Panel and found the message “Offline Files is currently enabled” below a greyed out “Disable offline files” button.

In the GPO, “Allow or Disallow the use of Offline Files” was set to “Disabled”. According to the blurb: “If you disable this setting, Offline Files is disabled and users cannot enable it.”

However this was patently not the case. The setting was Disabled but Offline Files was enabled on the client. (I ran the Resultant Set of Policy tool on the client to confirm it really was inheriting the GPO setting – it was.) As far as I can tell, all this setting does is disable the ability to change the state of Offline Files – without actually disabling Offline Files!

Finally I had to set the GPO option to “Not configured”. After that I could disable Offline Files on the client and, finally, DFS is accessible!

But the last irritation is that I had to unconfigure this setting in the global GPO. There is no way to override an “Enabled” or “Disabled” with a “Not Configured” at a sub-OU level.

Update

There was a bug in the original script where I had forgotten to populate mailNickname. I have now done so, adding a “c-” to the front of it as a completely optional convention to avoid conflicts.

Update 2

Several people have commented below about needing to enable the contacts in Exchange after creation. I have used the modifcations posted by Mark in the comments to make a new version that I hope will work better with 2007 and 2010, though I have only tested it with 2010. Both versions are linked below, and please keep adding your comments and modifications.

The Script

Now I have two versions the scripts have been moved off to seperate pages. Follow the links below.

Other people’s versions

Modified for Distribution Lists: http://www.wapshere.com/missmiis/galsync-v2/galsync-ps1-for-distribution-lists

But we don’t need to be that fancy. If all you want is to create a regular Windows-type home folder, at the same time as you create the AD user account, then here’s a way to do with an XMA.

Overview

To summarise the approach:

1. Create the user account in AD,
   • Flow the SID back into the metaverse – proof the account exists,
2. Create the home folder using an XMA,
   • Flow the path back into the metaverse,
3. Flow the path out to the user’s homeDirectory attribute through the AD MA.

Metaverse Schema

Add the following two attributes to the “person” type (or whatever you are using for your user objects):

• userSid (Binary)
• homeDirectory (String)

Create the XMA

Create an Extensible MA and call it “HomeFolders”. (Note: I don’t use spaces in my MA names so I have no scripting hassles.)

Configure Connection Information

Choose “Import and Export” and “Call based”.

Connected data source extension: “HomeFolders_CSExtension.dll”  (we will create the extension later)

Connection information: If you want to use this you will have to work out how to use the logon details in your CSExtension code to force the Import and Export steps to use this account instead of the ILM service account. I’m no great programmer, and to this day I’ve always managed to get away with giving the ILM service account the permissions I need. In this case it needs permission to create home folders and set ACLs.

Configure Additional Parameters

None

Select Template Input File

I created a text file called homefolders.txt and saved it to the MaData folder. In the file I have the following line:

path,folder,server,owner

Select the file and choose “Delimited” as the file type.

It is useful to keep this template file. Later, if you need to change the schema, you can modify this file and use it in the Refresh Schema operation.

Delimited Text Format

Tick “Use first row for header names”.

Select “Comma” as the delimiter.

Configure Attributes

Set Anchor: path

I also click Advanced and change the Fixed object type to “folder”.

Define Object Types

Leave on the default – only path is required.

Connector Filter

None. Use this if there are certain folder names you want to exclude.

Join and Projection Rules

If you’re lucky the folder names will match the sAMAccoutNames and you can join on that. You could also flow homeDirectory back from the AD MA and join on the path.

Try very hard to avoid manual joins in such an MA as you have no real way to flow an identifier back out to the folder itself (something you should always do if manual joins have been used – you should always be able to clear and re-import a connector space). If you have to go the manual join way then consider using a SQL table alongside this MA, as in this post, to keep track of folder owners.

Attribute Flow

One inbound flow only:

path --> homeDirectory

Configure Deprovisioning

“Make them disconnectors”

You can delete home folders with an XMA – you just need to add the appropriate code in your CSExtension to deal with modificationType = delete. But for this example I’m just creating the folder.

Configure Extensions

Click Finish to create the MA.

Write the CSExtension

With the new MA selected, click on Create Extension Project. In Project type choose “Connected Data Source Extension” and then enter as the name “HomeFolders_CSExtension”. Make sure your Project Location is correct and then click OK.

GenerateImportFile

The first step is to write the Import step. This should go out and find all the existing home folders and then populate a csv file along the lines of the template you created above. The actual import into the connector space then occurs from the csv file.

Note that my GetOwner function is a fudge – I actually just return the first domain account that I find with rights to the folder. This is acceptable to me because I am not going to use this MA to modify existing rights. All I really care about is checking that the user was correctly assigned to a newly created home folder. Typically the user will be the only domain account with explicit (as opposed to inherited) rights to the folder, so this should work fine.

  Dim Servers As String() = {"server1", "server2", "server3"}

    Public Sub GenerateImportFile(ByVal filename As String, ByVal connectTo As String, ByVal user As String, ByVal password As String, ByVal configParameters As ConfigParameterCollection, ByVal fullImport As Boolean, ByVal types As TypeDescriptionCollection, ByRef customData As String) Implements IMAExtensibleFileImport.GenerateImportFile
        Dim server As String
        Dim path As String
        Dim folders As System.Collections.IEnumerator
        Dim fw As StreamWriter

        Try
            'Open the output file specified in the run profile
            fw = New System.IO.StreamWriter(filename, False)
            fw.WriteLine("path,folder,server,owner")
        Catch ex As Exception
            Throw New UnauthorizedAccessException("Unable to open file: " & filename)
        End Try

        For Each server In Servers
            folders = Directory.GetDirectories("\\" & server & "\homedir").GetEnumerator
            While folders.MoveNext
                path = folders.Current.ToString
                'For each folder, write an entry into the import file
                fw.WriteLine(path & "," _
                            & path.Split("\".ToCharArray)(4) & "," _
                            & path.Split("\".ToCharArray)(2) & "," _
                            & GetOwner(path))
            End While
        Next
        fw.Close()
    End Sub

   Function GetOwner(ByVal path As String) As String
        ' This function does not get the actual owner of the folder,
        ' rather it returns the first domain trustee account.
        ' This is not very precise but the purpose is just to check the ACL
        ' for new folders so it will do.
        Dim AccessRules As AuthorizationRuleCollection
        Dim AuthRule As AuthorizationRule = Nothing
        Dim Owner As String = ""
        Dim Fs As FileSecurity

        Try
            Fs = New FileSecurity(path, AccessControlSections.Access)
            AccessRules = Fs.GetAccessRules(True, False, Type.GetType("System.Security.Principal.NTAccount"))
            If Not AccessRules Is Nothing Then
                For Each AuthRule In AccessRules
                    If AuthRule.IdentityReference.ToString.IndexOf("MYDOMAIN\") = 0 Then
                        Owner = AuthRule.IdentityReference.ToString
                        Exit For
                    End If
                Next
            End If
        Catch ex As Exception
        End Try

        If AuthRule Is Nothing Or _
           Owner = "" Or _
           Owner.IndexOf("MYDOMAIN\") < 0 Then
            Return ""
        Else
            Return Owner
        End If

    End Function

Once this code is in place you should be able to run an Import step on your MA. You will need to specify an import file name – just something like “import.csv” is fine. Once your code is working you will be able to see the file created in the MaData\HomeFolders directory, and populated with information about the folders it has found.

ExportEntry

I’m going to include the code for the ExportEntry sub here, but we won’t have anything to export until we modify our MVExtension provisioning code to create new folder objects. More on that below.

    Public Sub ExportEntry(ByVal modificationType As ModificationType, ByVal changedAttributes As String(), ByVal csentry As CSEntry) Implements IMAExtensibleCallExport.ExportEntry

        If modificationType = Microsoft.MetadirectoryServices.ModificationType.Add Then
            Directory.CreateDirectory(csentry("path").StringValue)

            If Directory.Exists(csentry("path").StringValue) Then
                Try
                    ' Get current ACL from the folder
                    Dim security As DirectorySecurity = Directory.GetAccessControl(csentry("path").StringValue)

                    ' Create a new rule granting owner full access
                    Dim rule As New FileSystemAccessRule(New NTAccount(csentry("owner").StringValue.ToLower), FileSystemRights.FullControl, AccessControlType.Allow)

                    ' Add the rule to the existing rules
                    security.AddAccessRule(rule)

                    ' Persist the changes
                    Directory.SetAccessControl(csentry("path").StringValue, security)

                Catch ex As Exception
                    ' If the ACL failed the delete the folder so the operation can be retried later.
                    Directory.Delete(csentry("path").StringValue)
                    Throw New EntryExportException("Failed to set ACL on " & csentry("path").StringValue _
                              & " - deleting folder. " & vbCrLf & ex.Message)
                End Try

            End If
        End If

    End Sub

Provisioning

Now we want to create the home folder.

As I indicated at the top of this post, you need some kind of proof that the user account was created before you create the home folder. The reason is permissions – you can’t grant permissions to a user that doesn’t exist yet. Technically you could provision your user and home folder objects at the same time, so long as you made sure the AD MA was exported first, but fundamentally I don’t like this. Even though it means running a series of export/import-syncs in a row, I much prefer to wait for the user account before I provision the home folder.

And the way I do this is by checking the Sid. I flow the userSid back into the Metaverse from the AD MA and use this as a test in my provisioning logic for home folders.

  Sub HomeFolder_Provisioning(ByVal mventry As MVEntry)
        Dim HFMA As ConnectedMA = mventry.ConnectedMAs("HomeFolders")
        Dim path As String = ""
        Dim server As String = ""

        '' Generate the path based on location
        If mventry("location").IsPresent Then
            Select Case mventry("location").StringValue.ToLower
                Case "london"
                    server = "server1"
                Case "zürich"
                    location = "server 2"
                Case Else
                    server = "server3"
            End Select
            path = "\\" & server & "\homedir\" & mventry("uid").StringValue
        End If

        '' Should the folder exist? AD account must be provisioned first.
        '' Note: Folders are NOT deleted. ShouldExist = FALSE just prevents creation.
        If mventry("Sid_AD").IsPresent Then
            ShouldExist = True
        Else
            ShouldExist = False
        End If

        '' Check if the folder already exists
        Select Case HFMA.Connectors.Count
            Case 0
                DoesExist = False
            Case 1
                DoesExist = True
            Case Else
                Throw New UnexpectedDataException("The metaverse person object with employeeID =" _
                 & mventry("employeeID").StringValue & " has more than one connector in MA " & HFMA.Name)
        End Select

        '' Take action based on values of ShouldExist and DoesExist
        If ShouldExist And DoesExist Then
            'Do nothing

        ElseIf ShouldExist And Not DoesExist Then
            'Create folder object in CS
            Dim csentry As CSEntry = HFMA.Connectors.StartNewConnector("folder")
            csentry("path").Value = path
            csentry("server").Value = server
            csentry("folder").Value = mventry("uid").StringValue
            csentry("owner").Value = "MYDOMAIN\" & mventry("uid").StringValue
            csentry.CommitNewConnector()

        ElseIf Not ShouldExist And DoesExist Then
            'Do nothing

        Else 'Should not exist and does not exist
            'Do nothing
        End If

    End Sub

All going well, you should now be able to Sync your AD MA, and any AD accounts that are missing a home folder should have one provisioned.

Start testing your exports by restricting the Export step to only process one object at a time.

Update User homeDirectory

The final step is to flow the path out to the homeDirectory attribute on the user, using the AD MA.

homeDirectory --> homeDirectory

If you want to map a particulay drive letter at the same time then flow a constant to homeDrive, eg.,

"H:" --> homeDrive

Doing more

You can do more. As I mentioned above you could modify your ExportEntry sub to process a delete, and then delete the home folder – though you would want to tread very carefully. There are bound to be far more interesting things you can do with the permissions, or with sharing the folder – but I’ll leave that for you to work out. Unless I have to do something like that myself – and then I will no doubt write it up here.

Hmm. So what if you need to? Well a customer is insisting that it must be done, so I’ve had to do some investigations.

Note that this article is based on lab work – I will post again after the actual rename, assuming I can’t swing Option 1 below.

Option 1: Try to talk people out of it

It’s not just Exchange that will be affected. If you have a CA Server you will have to reinstall it with the new name, and then recreate all your certs.  Your DNS zone structure will have to be recreated. And of course every computer attached to the network will need to be rebooted – probably more than once. You will have to track down every script, service and network device that has the domain name hardcoded somewhere… Basically, it’s not going to be simple, you may well have to reinstall some services from scratch, and you could have niggly problems going on for weeks.

But if that doesn’t work…

Option 2: Migrate to a new forest

This is where you create a new forest with the new name, install a new Exchange 2007 server into it, and then use tools like ADMT, Gpolmig and Move-Mailbox to shift everything over. This approach has several factors in its favour:

• The new forest will be completely free of the old name,
• Migrations are well understood and there’s plenty of documentation out there,
• The old domain and, importantly, the old Exchange server are untouched and available for rollback,
• With an inter-forest trust, it should be possible to move services over in stages.

Of course you’re going to need some new hardware, in particular that new Exchange server. Which would be rather annoying if you’d only recently installed the “old” one.

Option 3: Uninstall Exchange 2007 , Rename the domain, Reinstall Exchange and Restore the mailboxes

Now you can use rendom.exe to rename a Windows 2003 domain once you have uninstalled the Exchange 2007 server. There is no need to do anything special with AD or its schema – just get rid of that Exchange 2007 server and you’re ready to go.

It’s all a bit scary though. To uninstall Exchange 2007 you must first run the disable-mailbox cmdlet against all users – this effectively removes all Exchange-related information from the user objects, including quotas and delegations. You then have to remove your Mail and Public Folder databases. Yikes!

After the rename it is simple enough to reinstall Exchange 2007 (no need to forestprep as the schema changes are still there) and create new mailboxes for all the users…

But here’s where it all went pear-shaped in my test environment. It is not possible to restore an Exchange database over the top of an existing one, you have to go via a Recovery Storage Group,  BUT the restore utility would not restore to my new mailboxes because the mailbox GUIDs did not match! Of course – I’d created new mailboxes.

It is supposed to be possible to restore a mailbox to a folder inside a different mailbox – but my tests on this were not exactly promising – basically, I could not get it to work at all.

So we have a scary, risky uninstall of Exchange 2007, with a messay, potentially unworkable restore procedure. Not great.

Option 3.1: Use PSTs instead of RSGs

So the other idea is to export all the mailboxes to PST using export-PST before uninstalling Exchange 2007. Afterwards you should be able to import into the new mailboxes using import-PST.

But I haven’t actually tested this, because the whole uninstall-Exchange-from-production-environment thing has just got me too worried, and I have no intention of doing it for real.

Option 4: Like 3, but restore the entire Exchange Server

I haven’t tested this one because I don’t see how it would work. A crashed server can be rebuilt using the /RecoverServer switch – however all the information must still exist in AD. If you have actually uninstalled Exchange (essential prereq for renaming the domain) then the info is gone from AD and this switch won’t help.

The same goes for trying to restore the entire server image from backup. Exchange is too emeshed into AD, and if you’ve gone through the uninstall, you can’t fool it by just popping the server back up.

Option 5: Install Exchange 2003

Now I thought this was a pretty neat idea. You install an Exchange 2003 server, migrate everything to it (including the Public Folders), and then proceed as above with the uninstall-rename-reinstall activities. You could probably actually keep mail live through most of it, nothing gets deleted, and you could use a temporary server (assuming you had enough disk space).

But again it all fell through for me. Turns out you can’t install Exchange 2003 into a domain that’s only had Exchange 2007. The forestprep step fails, and then the installation fails because forestprep wasn’t done.

I know it is possible to run Exchange 2003 and 2007 in the one domain – but 2003 has to be there first. It may be possible to install an Exchange 2003 server into a domain that had Exchange 2003 before, but I haven’t had a chance to test that one out – and as it’s not relevant to my current problem, I won’t be pursuing this option any longer.

Conclusion

Failing Option1, I’ll be going for Option 2.

If you do need to do this, all I can say is: test, test, test, plan, plan, plan.

The one domain-wide right you do need to grant is Replicate Directory Changes – and you can read all about how to set that here. If you don’t set this permission you will see a stopped-connectivity error, and event 6050 in the application log.

If you haven’t changed the default rights for the Authenticated Users group then you should not need to add any extra permissions at the Domain level. This group will give the ILM account sufficient rights to map out the directory OU tree and read the schema.

So then it just remains to give the service account rights to the OUs that it will be interested in:

• Create/Delete specific object types as required,
• Read/Write All Properties,
• Reset Password (if using password sync).

Note that I’ve suggested read and write to all properties even though, theoretically, you could go through picking out just the particular attributes ILM can change. Personally I would strenuously resist this approach as it would be a right nuisance every time an extra attribute was added to a flow rule. Point out that the attribute selection can also be restricted from the ILM side so, while it may have access to unneeded attributes, it is completely impossible for it to modify values it can’t even see.

Group population is not the simplest thing to automate, however it is often a time-consuming manual task, and something high up on the priority list for an ILM project. Here are a few points which may help you on your way.

Members are Reference DN values

Groups are populated with links to the member objects, not a text list of names. To manage group memberships in ILM all involved objects must be present in ILM.

So, to put this plainly, if you’re trying to manage a particular group in AD then ILM must know about all its members. It is not possibly to partially manage a group.

You can only populate member and not memberOf

You can’t write to the “memberOf” attribute on user objects. It is something called a “backlinked” attribute, and AD is in charge of maintaining it.

You can, however, write to the “member” attribute of group objects, and this is the way you have to do it.

So it is not possible to manage group memberships by only considering the person (or user or contact) object – you need to manage the group objects as well.

You can’t modify reference DN attributes in extension code

ILM won’t let you write advanced flow rules for reference DN attributes – all you can do is flow them direct from one connector space, via the metaverse, to another.

(Actually I’ve never quite understood why this is, but there you go, we have to live with it.)

To emphasise the point: you must generate your membership lists outside of ILM, and then sync them directly through ILM.

When Dynamic Groups are not enough

Dynamic groups are those ones you want to change based on members’ attributes. Perhaps the group should contain everyone in a particular department, or a building, or with the same manager.

Exchange 2003 brought us dynamic groups – but only for distribution lists, and not security. Pathetic.

Besides, you’re most likely going to need some manually populated groups as well – not everything can be worked out from attribute values. You may also want some groups where most of the members are dynamic, and a couple which are static.

If you’re using SunOne LDAP you can do all this natively… but with AD the membership of all security groups are static, and you need something else to help automate things.

Generate the members in SQL

Here’s how you might generate the membership lists in SQL:

1. Generate dynamic group memberships in a view by directly querying the mms_metaverse table (sample queries to follow in another post).
2. Maintain another table for manually added group memberships (perhaps with a web front-end to manage them; groups can appear in both tables).
3. Concatenate the table and view together.
4. Import using the multivalue function of the SQL MA.

For more explanation on how to configure the tables to import group memberships see this post.

Use Delta tables

You may quickly find that full imports from multivalued tables are too slow – for this reason it is essential that you use delta imports, ie., only import changes.

The basic method is as follows:

1. Snapshot your import table/view;
2. Do a Full import;
3. Next time, take a new snapshot and compare it to the last one to make a Delta Table;
4. Do a Delta Import;
5. Once the Delta Import has completed successfully, clear out the Delta Table;
6. Repeat steps 3-5 ad nauseum.

There is (naturally) a fair bit more to it when you start bringing multivalued attributes into the mix. I’ve written a few posts on the subject in the past, and the best place to start is with this one.

In Summary

I once set up a system that had 6,000 groups and 40,000 users. The group memberships changed continuously – particularly the self-subscriber ones that were updated through the user portal. For efficiency, I separated the multivalued and single valued attributes into seperate MAs, and the multivalued Full Import still took about 5 hours. But by running regular delta imports (every 15 minutes) the list of changes each time was short, and the imports took only a matter of moments.

So while group population and synchronisation with ILM is fiddly, and does use a number of advanced techniques, it is certainly possible to achieve a result that is both effective and efficient.

Starting on the Configure Directory Partitions page, select your preferred directory Patition, Domain Controllers (optional) and Containers (OUs). Just let ILM see what it has to – there is no need to waste diskspace and time on importing OUs it has no business with.

Next we come to the Object Types. Again here you can be selective, but make sure you keep container and organizationalUnit as ILM will need them when constructing DNs.

Similarly on the Attributes page select the bare minimum, remembering that you can always add more later on. The basics for a user object are cn, firstName, sn, displayName, sAMAccountName (this is actually optional – AD will fill in a random one, but it will be ugly and I prefer to supply my own), userAccountControl, userPwd.

I prefer to be selective about which objects and attributes ILM can see for a couple of reasons – one is to reduce the scope for accidents, and the other is to reduce the size of the blame target. Call me paranoid if you will, but I have disproved a charge of “ILM did it” in the past by simply pointing out that the attributes in question weren’t even selected!

The final point I will mention is about the Enable Exchange 2007 provisioning option that has appeared, in ILM 2007, on the Extensions page. I understand this has something to do with Exchange 2007 no longer using the Recipient Update Service – a rather annoyingly opaque process in 2000/2003, but something we ILM’ers were relying on to get mailboxes created. There’s a proper explanation on this technet page.

I actually ended up writing the script twice.

1. First I used DNs as the search criteria, which makes the script quite simple, and also means it will work with any object type. You can see that script here.
2. Then, after seeing that the source spreadsheet contained usernames rather than DNs, I modified the script to use the CN instead. The restriction is that now the script only works with user objects (though there’s actually no reason why you couldn’t make a column for the object type in the spreadsheet as well). That script is here.

It needs to be noted that these scripts should only be used for updating single-valued attributes. I have included no back-out – so if you have the wrong data in your spreadsheet I accept no responsibility for you putting rubbish in your AD.

You also need to make sure your spreadsheet is tidy, with even column lengths, and no blank row in the middle (the script stops at the first blank cell).

For the CN script your spreadsheet should look something like this: