I'm pulling a list of employees from SharePoint into a web part. I did the following:

  1. mapped the Hire Date user profile property to the createTimeStamp AD property
  2. created a managed property in the Search Service Application and mapped it to the People:SPS-HireDate(Date and Time) crawled property
  3. used PowerShell to set FullTextQueriable to true for Hire Date
  4. ran a full profile sync and a full crawl

Then in my web part, I used FullTextSqlQuery with the following query text:

SELECT PreferredName, Department, WorkEmail, HireDate FROM SCOPE() WHERE \"scope\" = 'People'

PreferredName, Department, and WorkEmail all return data, but HireDate does not. Why am I not getting any data for HireDate?

Update: There is data in the createTimeStamp attribute in AD that is supposed to be imported into Hire Date. For some reason, the Hire Date property is not used in any user profiles, even though I've marked it required. I tried querying the user profile via PowerShell, and it returns values for other attributes, but not HireDate. It seems like the createTimeStamp data is not getting imported into SharePoint during the user profile sync, for some reason.

  • Have you added it into central admin as a property and done a full crawl?
    – Hugh Wood
    Commented Nov 14, 2012 at 16:52
  • Yes (I mention that in steps 2 and 4 in my post).
    – LFurness
    Commented Nov 14, 2012 at 16:55
  • Was checking if it was a full crawl you see not an incremental. Does the property have example data in central admin?
    – Hugh Wood
    Commented Nov 14, 2012 at 16:56
  • No, the crawled property does not have any sample documents. Is that abnormal?
    – LFurness
    Commented Nov 14, 2012 at 17:00
  • It basically means it isn't picking up the data in the crawl, check that the field you have mapped is correct. Check that it is set to "Include values of this property in search Index"
    – Hugh Wood
    Commented Nov 14, 2012 at 17:04

1 Answer 1


It turns out that createTimeStamp was not syncing any information to SharePoint. I switched to using the whenHired attribute instead. That worked perfectly.

The problem may have been due to using Windows 2008 for the SharePoint server and Windows 2003 for the AD server.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.