Fixed issues in Sync Engine
Issue 1
An
ExpectedRulesEntry (ERE) object is associated to a child synchronization rule of a
Metaverse object. If the ERE object has a
Remove action, deprovisioning of the object is also being triggered. Then, the behavior causes the deletion of the
Metaverse object.
Issue 2
Fixes an access violation when a custom extension calls a COM+ object.
Issue 3
An earlier hotfix introduced a special Extensible Connectivity Management Agent (ECMA) mode to keep unconfirmed exports in escrow instead of awaiting confirmation. An issue with that hotfix causes delta sync to add new items that are not merged with an escrowed export into a pending export. After you install the hotfix that is mentioned in this article, if the ECMAAlwaysExportUnconfirmed registry entry is set to 1, the escrowed and pending changes are merged.
Issue 4
Fixes an SQL query construction issue that occurs during an import. This issue affects a DB2 database that uses a non-Unicode character set.
Issue 5
Fixes many "Export not reimported" errors that might occur because of errors in SQL.
Issue 6
Improves the performance of all Sync Engine operations.
Note This change involves an extensive upgrade to the sync database. This upgrade can take lots of time, depending on your hardware. A progress bar is displayed during the database upgrade.
Issue 7
A password reset that uses the ADMAEnforcePasswordPolicy registry setting fails when the user is in the Administrator group but is not an administrator.
Feature 1
Adds an option to have FIM 2010 export the current time on the server to the
HTTPPasswordChangeDate field during the password set operation. The time stamp is stored as a
TimeDate data type.
To enable this behavior, set the following registry subkey to a nonzero DWORD Value:
SYSTEM\CurrentControlSet\Services\FIMSynchronizationService\Parameters\NotesMAExportPwdTimestamp
Feature 2
The FIM 2010 Active Directory Management Agent (AD MA) does not honor the preferred domain controller list when passwords are exported. This is an issue for customers who require password changes to flow to a specific set of domain controllers. This hotfix rollup package changes the AD MA to use the preferred domain controller list first. If the preferred domain controller list does not exist, the domain controller locator service will identify a domain controller for password export operations. Additionally, you can still force password operations to use the primary domain controller by setting the following registry subkey:
Subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\FIMSynchronizationService\Parameters\PerMAInstance\<MA_name>
Value:
ADMAUsePDCForPasswordOperations (REG_DWORD, 1 = True, 0 = False)
This hotfix rollup package also updates the AD MA so that a trust relationship with the configured Active Directory forest is not required to export passwords to that forest.
Feature 3
Adds the ability to filter objects before they are imported into the AD MA connector space.
Fixed issues in Sets and Query
Issue 1
Fixes an issue that would sometimes cause incorrect Set calculations. This resulted in lots of set corrections. Also revised the Sets Correction job so that it does not change special sets that are maintained by another system maintenance job.
Issue 2
Revised the FIM "Query and Sets" features to correctly treat percent signs, underscores, and opening brackets as literals instead of as SQL wildcard characters.
The approved character sets for strings that are used in FIM attribute values are defined in the attribute and binding schema in the FIM service. The syntax for representing an XPath filter is documented on MSDN in the following "FIM XPath Filter Dialect" article:
Some customers may have included characters that SQL defines as query wildcard characters, such as the percent character, in FIM searches and Set filters. In this case, the customers intended FIM to treat the characters as SQL wildcard characters. This is not a documented or supported feature of the product. In some cases, customers may be able to achieve the intended functionality by removing the wildcard and by using a “contains” query/filter instead.
Existing Set resources that have filters that contain SQL wildcard characters may not continue to function as the filters functioned before this hotfix was applied. Also, a filter that contains wildcard characters and that continued to function as expected after the hotfix was applied may function differently if the administrator later updates the filter definition.
Customers who used characters that SQL defined as query wildcard characters must check and revise their Set filters either before or after they upgrade to this hotfix. Customers should consider the impact of Set membership changes on Set transition MPRs. And, customers may want to temporarily disable MPRs or update workflow definitions while they change their Set filters to avoid unintentionally triggering provisioning or deprovisioning operations during Set definition maintenance.
Fixed issues in Certificate Management
Issue 1
Enables the random number generator in the server key generation function.
Issue 2
Improves the performance when enrolling a smartcard that has not previously been used with FIM Certificate Management (CM).
Fixed issues in FIM Management Agent (MA)
Issue 1
Fixes an issue in which the FIM synchronization service configuration for synchronization rules and codeless provisioning was not correctly written to the FIM Service database.
Fixed issues in FIM Service
Issue 1
Fixes an issue with SQL Server deadlocks that might occur during periods of high concurrency of requests or approvals.
Issue 2
Fixes an issue in which unexpected data in the FIM Service database could result in the FIM MA causing the Synchronization service to fail during import, and a stopped-server error occurred.
Issue 3
Fixes an issue when you add or remove a value for a multivalued string attribute. If the request was subject to authorization such as request reevaluation, the request would fail after approval.
Issue 4
Some
ExpectedRuleEntry objects and
DetectedRuleEntry objects in FIM 2010 can become "orphaned" over time. When a
DetectedRuleEntry object is not referenced in the DetectedRulesList of any object in the system, that object is determined to be orphaned. Similarly, when an
ExpectedRuleEntry object is not referenced in the ExpectedRulesList of any object in the system, that object is also determined to be orphaned.
These orphaned objects have no functional impact on FIM. However, over time, these orphaned objects can cause a decrease in performance for both FIM operations and Sync operations that are related to FIM, such as import or export by using the FIM MA.
A pruning stored procedure, [debug].[DeleteOrphanedRulesByType], was added to the [debug] namespace of the FimService database. This stored procedure must be run separately for the
DetectedRuleEntry object and the
ExpectedRuleEntry object. The stored procedure also has a "reportOnly" mode, and this mode can be used to determine the presence and number of orphaned
DetectedRuleEntry and
ExpectedRuleEntry objects in the system.
The
@ruleType parameter expects one of the following well-known values:
- N'Detected' for DetectedRuleEntry objects
- N'Expected' for ExpectedRuleEntry objects
To determine the number of orphaned objects in the system, run the stored procedure in "reportOnly" mode as follows.
DECLARE
@deletedRulesFound BIT;
EXEC [debug].[DeleteOrphanedRulesByType] @ruleType=N'CHANGE_ME', @reportOnly=1, @deletedRulesFound=@deletedRulesFound OUTPUT;
To loop through and actually delete orphaned objects in the system, run the stored procedure as follows. @deletionLimit=1000 instructs the procedure to stop when it has deleted 1,000 objects. If there are more than 1,000 orphaned objects in the system, either run the procedure multiple times (recommended) or increase the deletionLimit value.
DECLARE
@deletedRulesFound BIT,
@startDateTime DATETIME,
@endDateTime DATETIME;
SELECT @deletedRulesFound = -1;
WHILE @deletedRulesFound <> 0
BEGIN
SELECT @startDateTime = CURRENT_TIMESTAMP;
EXEC [debug].[DeleteOrphanedRulesByType] @ruleType=N'CHANGE_ME', @deletionLimit=1000, @reportOnly=0, @deletedRulesFound=@deletedRulesFound OUTPUT;
SELECT @endDateTime = CURRENT_TIMESTAMP;
SELECT @startDateTime AS [StartTime], @endDateTime AS [EndTime], @deletedRulesFound AS [WereDeletedRulesFound];
END