In my previous post Retrieve User Profile information and display all properties in simple webpart I provided a web part showing all user profile properties and values of a user account.
Today I needed the out-of-the-box (OOB) list of all profile properties. Below the full list of all properties.
[Update: link to TechNet article Default user profile properties (SharePoint Server 2010) and Default user profile property mappings (SharePoint Server 2010)]
| Displayname | Name | Value |
| Section: Basic Information | ||
| Id | UserProfile_GUID | |
| SID | SID | |
| Active Directory Id | ADGuid | |
| Account name | AccountName | |
| First name | FirstName | |
| Phonetic First Name | SPS-PhoneticFirstName | |
| Last name | LastName | |
| Phonetic Last Name | SPS-PhoneticLastName | |
| Name | PreferredName | |
| Phonetic Display Name | SPS-PhoneticDisplayName | |
| Work phone | WorkPhone | |
| Department | Department | |
| Title | Title | |
| Job Title | SPS-JobTitle | |
| Manager | Manager | |
| About me | AboutMe | |
| Personal site | PersonalSpace | |
| Picture | PictureURL | |
| User name | UserName | |
| Quick links | QuickLinks | |
| Web site | WebSite | |
| Public site redirect | PublicSiteRedirect | |
| Data source | SPS-DataSource | |
| MemberOf | SPS-MemberOf | |
| Dotted-line Manager | SPS-Dotted-line | |
| Peers | SPS-Peers | |
| Ask Me About | SPS-Responsibility | |
| SIP Address | SPS-SipAddress | |
| My Site Upgrade | SPS-MySiteUpgrade | |
| Don’t Suggest List | SPS-DontSuggestList | |
| Proxy addresses | SPS-ProxyAddresses | |
| Hire date | SPS-HireDate | |
| Display Order | SPS-DisplayOrder | |
| Claim User Identifier | SPS-ClaimID | |
| Claim Provider Identifier | SPS-ClaimProviderID | |
| Claim Provider Type | SPS-ClaimProviderType | |
| Last Colleague Added | SPS-LastColleagueAdded | |
| Outlook Web Access URL | SPS-OWAUrl | |
| Saved Account Name | SPS-SavedAccountName | |
| Saved SID | SPS-SavedSID | |
| Resource Forest SID | SPS-ResourceSID | |
| Resource Forest Account Name | SPS-ResourceAccountName | |
| Object Exists | SPS-ObjectExists | |
| Master Account Name | SPS-MasterAccountName | |
| Distinguished Name | SPS-DistinguishedName | |
| Source Object Distinguished Name | SPS-SourceObjectDN | |
| Last Keyword Added | SPS-LastKeywordAdded | |
| Section: Contact Information | ||
| Work e-mail | WorkEmail | |
| Mobile phone | CellPhone | |
| Fax | Fax | |
| Home phone | HomePhone | |
| Office | Office | |
| Office Location | SPS-Location | |
| Time Zone | SPS-TimeZone | |
| Assistant | Assistant | |
| Section: Details | ||
| Past projects | SPS-PastProjects | |
| Skills | SPS-Skills | |
| Schools | SPS-School | |
| Birthday | SPS-Birthday | |
| Status Message | SPS-StatusNotes | |
| Section: Delegation | ||
| Section: Newsfeed Settings | ||
| Interests | SPS-Interests | |
| Email Notifications | SPS-EmailOptin | |
| Section: Custom Properties | ||
Bram de Jager - Architect, Speaker, Author 
Do you know why there is a Ttitle and a Job title Fields ? I am trying to learn there intended usage.
Dear dlgross, when looking into both profile properties it seems they serve the same purpose. Both are a string (single value) property. The Job Title (SPS-JobTitle) is mapped to the AD title attribute, but is not shown anywhere in the user interface. The Title (Title) field is not mapped to the AD, but it is shown in the Edit Details page and shows the updates in the Newsfeed. The interesting part is when running synchronization both properties get provisioned with the same value from the AD title attribute. The actual value in the Job Title (SPS-JobTitle) property is an metadata field and adds the value to the Keywords (folksonomy) termset.
So how is Title populated, is it a build in function that just takes data from SPS-JobTitle and populate Title? and is it a build in function, that you cannot change?
Title is automatically populated via the default mapping, see http://technet.microsoft.com/en-us/library/hh147510.aspx
how to get user address or Street address
Bram, really, how to get he street, for example?
The fields shown in this example are the out of the box fields provided by SharePoint. If you prefer additional fields you need to map them first before you can access those. Mapping can be done from different sources. The most common is Active Directory.
So, depending where you store your Street data, you need to map it first. Only then you can access it.
Hmm, ok.
Not sure how the mapping should be done.