By default MOSS imports data from a Master Connection first, which is typically Active Directory but could be another LDAP source. Once a successful master connection import completes, it is possible to import additional data from one or more BDC data sources, also known as supplemental data sources. This is very common, since many organizations keep the bulk of the interesting employee information in HR systems outside of Active Directory. Often these HR systems more accurate and up-to-date than Active Directory, and are therefore considered the official system of record for personnel data. Refer to Importing User Profiles on MSDN for additional information on profile importing.
A relationship between the Master Connection data and the entity methods in the BDC application definition must be established. This is done with an Identifier field. The Identifier is populated by the Master Connection, and then used as the foreign key when executing the BDC methods. In this picture, AccountName is the foreign key; however, most commonly this is a numeric value like PersonnelNumber.
The first step in creating the BDC import connection is to create the BDC application definition. This contains the LOB description, the LOB entities, and methods. This post will not go into the details of the application definition; other than to point out it must have both Enumerator and Specific Finder methods for each entity which will be imported into the user profiles. The application definition should be tested using the out-of-the-box Business Data Catalog web parts on a test page. This will verify the correctness of the Finder and Specific Finder entity methods.
So what if you get this far, but BDC data is not being imported into the user profiles? Given that you application definition is correct as proven by using the BDC web parts, these are the things to investigate.
- The incorrect configuration of the identifier field is a major cause for the BDC import to fail. The identifier field coming from the master connection (AD or LDAP) is null, incorrectly mapped to a profile property, or malformed. Make sure the property mapping is correct. Visually look at some user profiles to make sure the property is populated with the expected values.
- Make sure the identifier is being populated from AD into the profile. Display the profile property definition (Central Administration > Shared Services Administration: SSP Name > User Profile and Properties > View Profile Properties > User Profile Property). Note the value in the Number of profiles using this property box. This should equal the number of profiles (assuming all profiles should have valid values).
- If Number of profiles using this property is zero, check the Property Import Mapping farther down on the same page. The Data source field to map should be checked. This picture is an INCORRECT mapping, which is causing the attribute import to fail.
Even if the mapping is correct, there could be a type casting problem; for example, the AD attribute is a string containing non-numeric characters which is mapped to a numeric profile property type. Use an AD tool like ADSIEDIT (in the Server 2003 Support Tools folder) to inspect the source attribute in AD to be sure it is non-null and conforms to the expected data type.
The identifier field in the profile has a data type incompatible with the application definition. I found it safest to define the profile property as a string. The BDC seems to be smart enough to map a string to any database type. - The enumerator method is not returning the correct identifier values or is otherwise failing. Execute the IDEnumerator method in Visual Studio or SQL Management Studio to make sure there are no SQL Syntax errors, and that the correct identifier values are being returned.
- In Central Administration > Operations > Diagnostic Logging set the diagnostic logging to Verbose for BDC and User Profile categories, perform an import, and then cull through the ULS logs for any error or warning messages. Note: the ULS logs could become very large, so be sure there is sufficient logging disk space. If there are SQL syntax problems, data type conversion issues, etc, these will be logged. Look in the import logs for the users with exceptions, and then search the ULS logs for those user names to see what BDC messages are associated with that user's profile. Filter the logs by time and content source (DL_IMPORT) to see just the BDC import related portion of the logs.
- Check the BDC import time on the User Profiles and Properties page. For 127,000 profiles, my customer is seeing the AD importing taking 2 hours and the BDC import taking 5 to 6 hours (for 4 different connections). If you see only 2 or 3 minutes for the BDC import, the connections are not being called or otherwise failing.
Beyond these investigative steps, there is not much else you can do to debug BDC import problems. If these steps fail to find a root cause, consider opening a support case with Premier Support, who can get the product team involved if necessary.