Profiles don’t get imported from AD
I ran into this while attempting to import the profiles and playing with my managed properties in the SSP.
Here’s what I did and noticed:
Having defined my BDC as a People Details Repository the initial purpose of the test was to completely replace all the user details in the search results with the results coming from BDC, because , as in life, the user details like address or office or job role might change and it is more likely that the updates will occur first in the BDC not always in AD.
Starting with the above assumption, I considered the AD properties static and left the default user properties mapping as they are ( eg. Office will be imported from AD) and , since I wanted to replace only the results, I modified the metadata mappings in the search configuration page to map to my BDC values and removed the People metadata from being indexed.
Uncheck “Include values for this property in the search index” in Metadata property definition.
For a list of default values you can check the full comprehensive list at Anne Stenberg’s blog.
https://blogs.technet.com/anneste/archive/tags/crawled+properties/default.aspx
I ran a full profile import and tested the search
After modifying the WorkPhone metadata HighConfidenceDisplay2, mapped by default to People:WorkPhone(Text) and removed the property from index I ran a full crawl and expected to see the results coming from BDC. To my surprise , no work phone was returned. I checked the BDC database to see if the phone was present. I checked the ActiveDirectory. Workphone ( and alternates) checked out fine. Furthermore, the field in the user properties ( which should have been imported from AD) was empty.
I re-mapped the metadata property to it’s original value and ran a full profile import and a full crawl.The property magically appeared.
Hmmm.I wondered if the behavior is reproducible with other metadata and I modified the Office managed property which, again should get imported from AD.
By default, the People:Office(Text) metadata property mapping is mapped to the following categories:
OfficeNumber, HighConfidenceDisplay2,4,7.
I replaced all the mappings with mapping to my BDC.Office value and unchecked the “Include values for this property in the search index” checkbox.
The result after a full crawl and a full profile import : Office Field was no longer populated with Active Directory value, nor with the BDC value.
Hmmm!
Taking the test further to see if this happens for all the profile properties, I replaced all the metadata mappings with values from my BDC. The biggest surprise of all came when I modified People:AccountName(Text) ( mapped to HighConfidenceMatching and AccountName) because after a full crawl, the next profile import skipped the accounts altogether. The profiles did not get imported AT ALL .
After doing some research, I found out the next post which pretty much explains the behavior.
The point is, since the profile import is basically a crawl, if we remove the People:xxxxxx() metadata from the index, the filter will discard all these values therefore, discarding the properties imported from Active Directory. If the property discarded is AccountName, naturally the profile will not get imported at all since we cannot have NULL AccountNames.
The solution was to add back the properties to their original mappings, along with the bdc mappings and run a full crawl on the Local Office Sharepoint SitesContent Source.
And the conclusion is : Do Not Remove People:AccountName(Text) from Index and do not change it's mapping. For that matter, do not remove the People:xxxx (text) from being indexed or you might run into very peculiar behaviors.
Hope it helps.