Due to the differences in the management of Rooms between Exchange 2003 and Exchange 2010, a custom mapping is required for Rooms from an Exchange 2003 source to appear as a Room object in a target Exchange 2010 environment. The following fields must appear in the target Room objects for them to display as Rooms.
Attribute | Value |
---|---|
MSExchResourceDisplay | Room |
MSExchResourceMetaData | Resource Type: Room |
MSExchResourceSearchProperties | Room |
MSExchResourceDisplayType | 7 |
MSExchResourceRecipientTypeDetails | 16 |
The Room must be a mailbox –enabled object in the source AD and cannot be a Public Folder Binary Tree does not recommend manually editing any attributes from the target directory. All updates should be from the authoritative source directory or via custom mapping There must be an identifying attribute in the source object that is used to distinguish these objects as Exchange 2003 Rooms. For this example, we have set the extension Attribute1 to “btroom”. |
To customize the mapping so that Exchange 2003 rooms appear as rooms in Exchange 2010:
View | Field Name | Field Value |
---|---|---|
Person | msExchResourceDisplay | CASE WHEN P.msExchResourceDisplay IS NOT NULL THEN P.msExchResourceDisplay ELSE (CASE P.Extension1 WHEN 'btroom' THEN 'Room' ELSE NULL END) END |
Person | msExchResourceMetaData | CASE WHEN P.msExchResourceMetaData IS NOT NULL THEN P.msExchResourceMetaData ELSE (CASE P.Extension1 WHEN 'btroom' THEN 'ResourceType:Room' ELSE NULL END) END |
Person | msExchResourceSearchProperties | CASE WHEN P.msExchResourceSearchProperties IS NOT NULL THEN P.msExchResourceSearchProperties ELSE (CASE P.Extension1 WHEN 'btroom' THEN 'Room' ELSE NULL END) END |
Person | msExchRecipientDisplayType | CASE WHEN P.msExchRecipientDisplayType IS NOT NULL THEN P.msExchRecipientDisplayType ELSE (CASE P.Extension1 WHEN 'btroom' THEN '7' ELSE NULL END) END |
Person | msExchRecipientTypeDetails | CASE WHEN P.msExchRecipientTypeDetails IS NOT NULL THEN P.msExchRecipientTypeDetails ELSE (CASE P.Extension1 WHEN 'btroom' THEN '16' ELSE NULL END) END |
Expand the Organization Configuration folder, select Mailbox, and then select All Rooms.
Right click on All Rooms and then select Apply.
Click Next and then Finish to reapply the address list.
By default, the adminDescription attribute is stamped on objects on the Target that are created or updated by Directory Sync Pro for Active Directory with "Created by Dirsync" or "Updated by Dirsync" to define which objects can be safely deleted from the Target. An app setting is available in the config file to allow you to define a different attribute/field for this purpose.
To use an attribute other than adminDescription or $BTAction, define a new DirSyncAttribute setting in the <appSettings> section of the config file. For example, the below setting will use adminDisplayName instead of adminDescription:
Warning: This must be configured before the initial sync.
<appSettings>
<add key="DirSyncAttribute" value="adminDisplayName"/>
</appSettings>
A configuration option to allow you to set msExchRecipientDisplayType and msExchRecipientTypeDetails Exchange attributes based on the value of a configurable attribute is available. This option is only applied to target objects not created by Directory Sync Pro for Active Directory.
The configuration option must defined in the <appSettings> section of the config file, as shown below. “Value=” should be contain the attribute to be used. (proxyAddresses shown below). If the value of the target attribute is null, msExchRecipientDisplayType and msExchRecipientTypeDetails will be populated. See the list below for the values that will be populated.
<appSettings>
<add key="RecipientType_MailEnabledAttribute" value="proxyAddresses"/>
</appSettings>
Mail Enabled Users in the source:
- msExchRecipientDisplayType = 6
- msExchRecipientTypeDetails = 128
Room Mailbox in the source:
- msExchRecipientDisplayType = 7
- msExchRecipientTypeDetails = 16
Resource Mailbox in the source:
- msExchRecipientDisplayType = 8
- msExchRecipientTypeDetails = 32
Shared Mailbox in the source:
- msExchRecipientDisplayType = 0
- msExchRecipientTypeDetails = 4
A setting that allows objects with connected O365 remote mailboxes to be treated as mailbox-enabled objects is available. To enable this feature, add the RemoteMailboxAsMailboxEnabled option to the <appSettings> section of the BinaryTree.DirSync.Exchange.exe.config file as displayed below.
<appSettings>
<add key="RemoteMailboxAsMailboxEnabled" value="True"/>
</appSettings>
If this setting is set to any value other than True or if omitted from the file, objects with remote mailboxes will be treated as non-mailbox-enabled. If set to True, objects with remote mailboxes will be treated as mailbox-enabled.
A configuration option in the appSettings section of the config file to specify a timeout for password sync is available. In large environments, it may take longer than the default 300 second timeout to complete the password sync process and may need to be lengthened.
This setting should be added to the BinaryTree.DirSync.Exchange.exe.config file.
<appSettings>
<add key="PasswordSyncTimeoutSeconds" value="300"/>
</appSettings>
Set the value to configure the timeout to a specific number of seconds. If this setting is omitted, or set to an invalid value, the timeout will be set to 300 seconds (5 minutes). To disable the timeout functionality, set to -1 (or any negative value).
A configuration option can be used in the appSettings section of the config file to disable the caching of group members.
This setting should be added to the BinaryTree.DirSync.Exchange.exe.config file.
<appSettings>
<add key="OptimizeGroupSyncMemoryUsage" value="true"/>
</appSettings>
Valid values are true and false. If this setting is omitted, or set to an invalid value, the value defaults to false. If set to false, group members will be cached during push and pull. If set to true, group members will not be cached during push and pull.
A configuration option can be used in the appSettings section of the config file to disable the initialization of the sync report. If disabled, a sync report will still be recorded, but it will not be initialized between syncs. The result will be that an object will show data from the last time it was processed by Directory Sync Pro for Active Directory, rather than just the most recent time it was processed. In other words, if an object is inserted during a sync, it will show in the sync report as Inserted. Assuming a second sync does not touch this object, then if the sync report is initialized, a second sync will show this object as No Change, but if the sync report is not initialized, the object will still show as Inserted.
This setting should be added to the BinaryTree.DirSync.Exchange.exe.config file.
<appSettings>
<add key="DisableSyncReportInitialization" value="true"/>
</appSettings>
Valid values are true and false. If this setting is omitted, or set to an invalid value, the value defaults to false. If set to false, the sync report will be initialized. If set to true, the sync report will not be initialized.
During pull processing, Directory Sync Pro for Active Directory will sync multiple Active Directory user and group objects simultaneously into the target AD. The maximum number of users and groups synced simultaneously can be changed using the ThreadCount setting in the config file. If this configuration option is not specified, the ThreadCount will be set to the same number of logical processor cores of the server on which Directory Sync Pro for Active Directory is running.
The configuration option is not included by default. To add, modify the BinaryTree.DirSync.Exchange.exe.config file located at C:\Program Files\Binary Tree\DirSync and add a new key to the <appSettings> section as follows:
<appSettings>
<add key="ThreadCount" value="4"/>
</appSettings>
This option should never be set to a number greater than the number of processor cores on the server. However, you may need to specify a lower number if other applications also running on the server require a specific number of cores set aside for processing. Best practice is to leave the setting at the default value and lower it only if additional processing power is needed for other applications on the server.
Multiple passes will be needed to make sure all data is synchronized to the target when multi-threading is used. An example scenario is:
- User B is the Manager of User A.
- User A is synchronized first.
- Then, User B is synchronized.
- Another sync is needed for User B to be the Manager on User A.
A configuration option can be used in the appSettings section of the config file to ensure passwords are copied even if a prior sync failed.
This setting should be added to the BinaryTree.DirSync.Exchange.exe.config file.
<appSettings>
<add key="RepushAllPasswords" value="true"/>
</appSettings>
Valid values are true and false. If set to true, Directory Sync Pro for Active Directory will process passwords for all users during the push. Any users with changed passwords will be processed on the pull. Using this option will increase the sync time, but ensure that all passwords are made current. If set to false or the setting is omitted, this option is disabled.
A configuration option can be added to control how many objects are selected when the user selects all (Ctrl+A):
<appSettings>
<add key="SelectAllLimit" value="1000"/>
</appSettings>
If this configuration option is omitted, the default value is 1000. Setting this option to a high number may cause performance issues when selecting and marking objects.
Selecting objects to mark as Ready to Sync can be done from the Objects tab within the Sync Report, which contains all object types.
A configuration option can be used in the appSettings section of the config file to control how many objects are selected when the user selects all (Ctrl+A):
This setting should be added to the BinaryTree.DirSync.Exchange.exe.config file.
<appSettings>
<add key="SelectAllLimit" value="1000"/>
</appSettings>
If this configuration option is omitted, the default value is 1000. Setting this to a high number may cause performance issues when selecting and marking objects.
This option does not apply to Windows Server Migration profiles.
A configuration option can be added to change the attribute used for the linking functionality.
This setting should be added to the BinaryTree.DirSync.Exchange.exe.config file.
<appSettings>
<add key="LinkedIDAttribute" value="adminDisplayName"/>
</appSettings>
If this configuration option is omitted, adminDisplayName is used.
A configuration option can be added to change the delay length prior to running the post sync PowerShell script. By default, the delay is 300 seconds (5 minutes).
This setting should be added to the BinaryTree.DirSync.Exchange.exe.config file.
<appSettings>
<add key="PostScriptDelaySeconds" value="300"/>
</appSettings>
Active Directory provides a powerful way of retrieving data through the use LDAP filters. Directory Synchronization exposes three filters during the creation of a synchronization profile: User OU Filter, Group OU Filter, and Device OU Filter whose defaults are:
- Users: (&(!(adminDescription=Created By DirSync))(|(objectClass=Person)(objectClass=room))(!(objectClass=computer)))
- Groups: (&(!(adminDescription=Created By DirSync))(objectClass=Group))
- Devices: (&(!(adminDescription=Created By DirSync))(objectClass=computer)(!(primaryGroupID=516)))
These filters are per organizational unit and apply to sub-OUs when the Sync Sub-OUs option is selected.
Modifying these filters requires a basic understanding of the attributes, their value representations, and their data types. LDAP filters support any number of options including filtering by date ranges, wildcards, and the use of bitmasks as in the userAccountControl property.
The use of the objectClass and objectCategory properties can greatly reduce the number of records retrieved resulting in improved performance. You may use other attributes to further restrict your results.
The following are common examples of queries and their LDAP query syntax.
- Selecting users that are part of the ‘Accounting’ department:
- (&(objectClass=User)(objectCategory=Person)(department=Accounting))
- Selecting mailbox-enabled users:
- (&(objectClass=User)(objectCategory=Person)(homeMDB=*))
- Selecting mail-enabled users and contacts:
- (|(&(objectClass=User)(objectCategory=Person)(!homeMDB=*))(objectClass=Contact))
- Selecting users created after January 1, 2011:
- (&(objectClass=User)(objectCategory=Person)(whenCreated>=20110101000000.0Z))
- Selecting distribution lists:
- (&(objectClass=Group)(groupType=2))
Binary Tree recommends that you use the Active Directory Users and Computers management console to test your filters to prevent Directory Synchronization from failing due to an invalid filter.
Active Directory provides a powerful way of retrieving data through the use LDAP filters. Directory Synchronization exposes two filters during the creation of a synchronization profile: User OU Filter and Group OU Filter whose defaults are:
- Users: (&(!(adminDescription=Created By DirSync))(|(objectClass=Person)(objectClass=room))(!(objectClass=computer)))
- Groups: (&(!(adminDescription=Created By DirSync))(objectClass=Group))
These filters are per organizational unit and apply to sub-OUs when the Sync Sub-OUs option is selected.
Modifying these filters requires a basic understanding of the attributes, their value representations, and their data types. LDAP filters support any number of options including filtering by date ranges, wildcards, and the use of bitmasks as in the userAccountControl property.
The use of the objectClass and objectCategory properties can greatly reduce the number of records retrieved resulting in improved performance. You may use other attributes to further restrict your results.
- Selecting users that are part of the ‘Accounting’ department:
- (&(objectClass=User)(objectCategory=Person)(department=Accounting))
- Selecting mailbox-enabled users:
- (&(objectClass=User)(objectCategory=Person)(homeMDB=*))
- Selecting mail-enabled users and contacts:
- (|(&(objectClass=User)(objectCategory=Person)(!homeMDB=*))(objectClass=Contact))
- Selecting users created after January 1, 2011:
- (&(objectClass=User)(objectCategory=Person)(whenCreated>=20110101000000.0Z))
- Selecting distribution lists:
- (&(objectClass=Group)(groupType=2))
The following are common examples of queries and their LDAP query syntax.
Binary Tree recommends that you use the Active Directory Users and Computers management console to test your filters to prevent Directory Synchronization from failing due to an invalid filter.
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. 利用規約 プライバシー Cookie Preference Center