Category: Forefront Identity Manager

Email troubleshooting in SharePoint 2013

SharePoint and Exchange is a great ever combination of making a productive environment these days you may have heard from Microsoft. Indeed, the combination offers you full collaboration features and unblocks numerous of choke points in communication. However, the integration between SharePoint and Exchange is not as easy as installing Exchange, configuring out-going setting and performing full synchronization. This sounds like a very normal case all of us know, but not really a list to make things become complete.

Recently I have seen several misunderstandings about email address in SharePoint 2013 from my clients and colleagues. Most of them let User Profile Synchronization do its job and were in trouble as to why email addresses in SharePoint didn’t get updated. As a result, end users didn’t get email notification from SharePoint making a big problem in business operation. On several issues about email address, this article is going to clarify a few things. It will also provide some tips to troubleshooting common email-related cases in SharePoint 2013.

Note: this article is not going to target to business user, instead to people who work with SharePoint as an administrator or a developer.

Where do you see email address in SharePoint?

Email address of a user object in User information list is the very first place for the answer. This email address is used for email process. If an email is outdated, the owner will not receive any notification SharePoint via your email server. I would say it’s an actual working email in SharePoint. To see it, browse this URL http://<your_sitecollection>/_layouts/userdisp.aspx

If you are using Social features provided by User Profile Service application, you will be redirected to your personal site.

From PowerShell, use the following command line to check the email address:

Make sure the LoginName value is form of claim (i:0#.w|)

If you like to do something like a DBA, query the UserInfo table of the content database where your site collection is stored within. Below is the sample T-SQL code snippet

The second place you’ve got to see the email address is user profile service application. Just open it and navigate to Manage User Profiles page.

How does email get updated to the User Information List?

As said earlier, the email address you see in User Information List is used by SharePoint for notification. Hence, understanding how it is synchronized or updated to the list is very important and will support your troubleshooting.

In all of basis, SharePoint has User Profile Synchronization service responsible for mapping data from an identity provider to each user profile in SharePoint relatively. The mapping depends on how you set in Manage User Properties page. By default, Work email property is mapped to proxyAddress attribute in Active Directory.

Described by Microsoft, a proxy address is the address by which a Microsoft Exchange Server recipient object is recognized in a foreign messaging system. Proxy addresses are required not just for users, but for all recipient objects, such as contacts, distribution groups, and public folders. Another description from Microsoft Exchange team is that proxyAddress is the main attribute where email address information is kept. Because proxyAddress can contain multiple values, I suppose they are as follows:

  • (primary address)
  • smtp: (secondary address)

The description does tell us that if SharePoint synchronizes proxyAddress, there will be multiple values in Work email property.

When an email is synchronized or updated to a user profile, there are two timer jobs that are responsible for email synchronization to the user information list.

  • User Profile to SharePoint Full Synchronization: synchronizes user information from the user profile application to SharePoint users and synchronizes site membership from SharePoint to the user profile application.
  • User Profile to SharePoint Quick Synchronization: synchronizes user information from the user profile application to SharePoint users recently added to a site.

The flow above gives you an overview of how proxyAddress is synched to user profile and is updated to the UserInfo table of a content database.

How to edit the mapping of email property

Keeping proxyAddress by default mapped to Work email property is not recommended. First, if you do not have Microsoft Exchange, proxyAddress property would be always empty. Secondly, if proxyAddress has multiple values, User Profile Synchronization doesn’t understand multi-value format while the property type is E-mail. Therefore, we need to map the email property to the mail attribute in Active Directory.

This way facilitates email management because you can edit to troubleshoot anytime you want without the need of rights on Exchange server.  It’s also to let SharePoint understand that mail attribute only contains a single value.

From SharePoint User Profile Service Application page, click Manage User Properties. Locate to Work email property and click Edit (from a small arrow beside).

Scroll down to Property Mapping for Synchronization setting, click Remove

Under Add New Mapping setting, select synchronization connection under Source Data Connection. Under Attribute, select mail. Under Direction, select Import.

Click Add. Make sure you see the new mapping of mail attribute in Property Mapping for Synchronization setting. Click OK to complete then verify the mapping before full synchronization.

Perform full synchronization and open Forefront Identity Manager (C:\Program Files\Microsoft Office Servers\15.0\Synchronization Service\UIShell\miisclient.exe) to monitor and test the result.


In almost cases when an end user doesn’t receive an email notification while his colleague is, folks often leave a look at the User Information List where that end user resides. They also seem to be in trouble with User Profile Service application and Exchange server.

If you have ever encountered such a case, make sure the email address in the user information list has been newly updated. Otherwise, SharePoint will send the request of old email address to email server. If the email address is old, check the email address of the affected end user in User Profile Service Application. If the user profile has the new email address updated, chances are User Profile to SharePoint Full Synchronization and User Profile to SharePoint Quick Synchronization timer jobs haven’t worked correctly. In this case, you need to check Last run time value and history of each timer job. You would need to clear configuration cache to update the configuration database and make things come back normally.

In case the email in the user profile is still not correct, open Forefront Identity Manager to see synchronization history, status and error if any. Also make sure User Profile Synchronization service is started and isn’t affected by any automatic SharePoint backup script using server-side object model.

Until you verify the email address in both locations (user profile service application and user information list) are updated correctly, you can begin testing SMTP status. There is a PowerShell script to do that:

If the output is true, your SMTP is working well with SharePoint. Otherwise there is a problem between the SMTP server and your SharePoint.


If you need a quick way to update the email address for an affected end user, use the following PowerShell command line:


Email in SharePoint looks pretty complicated as it presents in several different locations and requires a complete process to make email notification in SharePoint work. To troubleshoot, you need to be familiar with User Profile Service application, a little more with Forefront Identity Manager and some skills for timer job troubleshooting. Or all of these things can be out of you list if you feel confident of making a custom job that can directly reach to Active Directory via LDAP syntax then update directly to user information list utilizing SPUser class. That’s your choice.

You may need to read Synchronizing User Account in Active Directory to SharePoint

Some notes on Office 365 synchronization error

One of my customers I have recently deployed Active Directory synchronization and single sign-on on Office 365 urgently called me he got message from the Microsoft Office 365 team that Windows Azure Active Directory did not register a synchronization attempt from the Directory Sync tool in the last 24 hours. I shortly suspected that the synchronization server might be down or its Internet connection got disconnected but this didn’t really make sense because a delta synchronization occurs every three hours.


“Service not available” displaying on FIM Portal

I suddenly today ran into one of the most common errors around the Forefront Identity Manager (FIM) world when opening FIM administration portal site hosted in one of my customers I have been supporting. I got redirected to the URL in conjunction with the error message “Service not available. Please contact your help desk or system administrator”.


Some notes on using QuickStart to synchronize AD user profiles to FIM profile database

One of the most important tasks before implementing Identity Management solution based on Microsoft Forefront Identity Manager 2010 R2 in a real-world business context is to synchronize user profiles from Active Directory repository or external directory systems to FIM profile database. I’m not going to go along with User Profile Synchronization service in SharePoint 2010 so you guys please do not confuse, even there is actually a SharePoint farm in my environment.

Let me show you a little bit about my FIM logical topology which is drawn by Visio 2013 Preview.

I have only one FIM server which hosts all FIM components and System Center Service Manager (SCSM) 2010 SP1. In my environment, there is a SharePoint farm which has two Web-front end servers and one application server. All databases whether FIM database or SharePoint databases are stored in one database server as you see in the figure. The SharePoint application server hosts its own FIM Service and FIM Synchronization. In other words, FIM Synchronization on the FIM server is different from SharePoint application server’s. Some of you may be worrying about a duplication of FIM synchronizations and how each can independently work with corresponding application. When you need to synchronize user profiles from Active Directory to whether SharePoint profile database or FIM profile database, you must create a management agent for Active Directory Domain Services. If you have 10 applications, each of which require its own management agent before synchronization so you will have 10 independent management agents. Hence, two synchronization services in the same environment do not matter. This is just a small note to know when you have both FIM and SharePoint joined to the same domain.

There are two ways to perform a synchronization.

  • Creating a management agent for Active Directory Domain Service
  • Using the QuickStart tool to quickly synchronize user profiles.

With the first way, you can open Synchronization Service program which can be found here: “C:\Program FilesMicrosoft \Forefront Identity Manager\2010\Synchronization Service\UIShell\miisclient.exe“, and then create a new management agent for ADDS by clicking Create in the Actions panel. I actually don’t want to go in more detail with this manual way. You can get started with the second way. However, if you need to configure more specific, such as attribute selection, object filter or so on, the first way is worth considering.

Using the QuickStart tool which is a PowerShell module provided by Microsoft helps you reduce time of a synchronization. QuickStart automatically verifies, creates a new management agent as well as synchronize user profiles stored in a selected Organization Unit to FIM profile database. Before using QuickStart, the following notes you should have to consider:

PowerShell 2.0 must be installed on the server which hosts FIM synchronization service. Windows Server 2008 R2 already has PowerShell 2.0.

During the creation of the management agent, FIM requires an Active Directory credential of that management agent. This account must have DirSync permission on the domain. However, this requirement is likely ambiguous for those who are not familiar with Active Directory, especially do not know how to assign DirSync permission. I have tried to find out how to assign DirSync permission but there is nothing but its appearance mostly on Office 365 directory synchronization topics. I have found a helpful discussion on why DirSync requires Enterprise Admin privilege here . In a nutshell, make sure the AD management agent account is a member of Enterprise Admin group in Active Directory.

Make sure FIM Synchronization service is already started before executing QuickStart. You can check via Microsoft Management Console Services.

Open %Program Files\Microsoft Identity Manager\2010\Synchronization Service\Tools and then extract to C:\WindowsSystem32\WindowsPowerShell\v1.0\Modules.

Open PowerShell or PowerShell Integrated Scripting Environment (ISE) and then type Import-Module QuickStart. If you see an error strong name validation error, add the following keys in the Registry.

  • [HKEY_LOCAL_MACHINE]Software\Microsoft\StrongName\Verification*,31bf3856ad364e35] and
  • [HKEY_LOCAL_MACHINE]Software\Wow64\32Node\Microsoft\StrongName\Verification*,31bf3856ad364e35]

These keys are recommended by Microsoft. Next, enter the following command line:

Make sure every parameter is valid. If you don’t know exactly domain name forest, let’s use the VBScripts shared by Jonh Savill in this post:
You will get the following message if you have had already at least a management agent.

Invoke-QuickStart : Quick Start cannot proceed because the Synchronization service has already been configured with management agents. Remove all agents before trying again

One of the most important parameters in the command line is ForefrontIdentityMangerSeviceBaseAddress. If FIM service and FIM Synchronization service are installed on the same server, enter http://localhost:5725. If it is installed on another server (e.g. its name is App1), you have to enter http://app1:5725. Make sure your firewall allows TCP port 5725. When I entered FIM service base address wrongly, I got the error at the step Enabling declarative provisioning in Forefront Identity Manager: The HTTP request is unauthorized with client authentication scheme ‘Anonymous’. The authentication header received from the server was ‘NTLM’.

After the automation is completed like the below image. (Note: I was using PowerShell ISE)

You can check via FIM portal (https:/sharepoint.soldier.lab/IdentityManagement)


Some of the things found in this article may be helpful for those who are new to Forefront Identity Manager. Whether deploying anything using FIM 2010 R2, you first must synchronize user profile from Active Directory or external directory repositories. Those user profiles are stored in FIM profile database which you specified during FIM installation. My purpose of this article is to note some points to help you facilitate synchronization before diving into FIM 2010 R2. In the future, I will write a series of best practices Self-Service Password Rest deployment in SharePoint environment.

The following references I have used:

© 2018 The Soldier of Fortune.