Update 12/8/19: Found that deletions are processed differently for a partitioned user profile service app. See the ** amendment in the “ADI Step 2” section below.
In SharePoint 2016, you have two options. Like SharePoint 2013, you can use Active Directory Import (aka: “AD Import”, “ADI”). You also have the option of using an “External Identity Manager”. In most cases, this will be Microsoft Identity Manager 2016 (aka: MIM), which is the successor to Forefront Identity Manager (FIM).
Active Directory Import (aka: ADI)
ADI Step 1: Determine if the profile is already marked for deletion.
Run this SQL query against the Profile database:
If your target profiles are in the results, that means they are already marked for deletion. All you should need to do is run the My Site Cleanup Job. See step 4 below.
Note: Managed profiles marked for deletion should also show in Central Admin | Your UPA | Manage User Profiles | Profiles Missing from Import.
Note: By default, SharePoint only runs Incremental imports on a schedule. In order to run a Full import on a schedule, you’ll have to create a Windows Scheduled Task and kick it off with PowerShell like this:
** The exception to this rule is if you directly delete AD users from a synched OU (one that is selected for import). In that case, the deletion of the profile is processed automatically during the next import. You’d see entries like this in the ULS log during the import (if your logging is Verbose):
11/19/2019 14:05:47.48 OWSTIMER.EXE (0x1F34) 0x1098 SharePoint Portal Server User Profiles aei5q Verbose QueueItemChange: Incoming delete for item <GUID=c5b7cfb9-d98d-437a-acc5-da1bc6453a4c>;<SID=S-1-5-21-1700552430-3460358242-3531541990-1701>;CN=User1\0ADEL:c5b7cfb9-d98d-437a-acc5-da1bc6453a4c,CN=Deleted Objects,DC=contoso,DC=com of type 0. 2377199f-f0a8-e088-a10e-e2e15e2daf5a
11/19/2019 14:05:47.51 OWSTIMER.EXE (0x1F34) 0x1098 SharePoint Portal Server User Profiles c8hz Verbose ProfileImportExportService.UpdateWithProfileChangeData: Begin Delete CN=User1\0ADEL:c5b7cfb9-d98d-437a-acc5-da1bc6453a4c,CN=Deleted Objects,DC=contoso,DC=com 9c570013-54d5-4ab2-8097-8f90d6985a0b
11/19/2019 14:05:47.54 OWSTIMER.EXE (0x1F34) 0x1098 SharePoint Portal Server User Profiles c8i0 Verbose ProfileImportExportService.UpdateWithProfileChangeData: End Delete CN=User1\0ADEL:c5b7cfb9-d98d-437a-acc5-da1bc6453a4c,CN=Deleted Objects,DC=contoso,DC=com 9c570013-54d5-4ab2-8097-8f90d6985a0b
However, this is only true if your User Profile Service Application is the regular non-partitioned variety. If you have a partitioned UPA, these profile deletions for deleted AD users do not occur automatically. In that case, you need to deal with them just like other “out of scope” profiles. You can check if your UPA is partitioned or not using this PowerShell:
If the target profiles are managed profiles, not marked for deletion, and you have run a Full Import, then you need to look into why AD Import is not marking them for deletion.
Document your connection filter and selected OUs / containers and check your target profiles against them. If you’re using a complex LDAP filter on your import connection, you should consider using an LDAP tool like LDP.exe or LDAP Browser to test the LDAP filter and make sure it includes and excludes the users you think it should.
ADI Step 4: My Site Cleanup Job
While “Set-SPProfileServiceApplication $upa -PurgeNonImportedObjects $true” marks out-of-scope profiles for deletion, it doesn’t actually delete anything. That’s left to the My Site Cleanup Job.
Check Central Administration | Monitoring | Timer Jobs | Review Job Definitions | My Site Cleanup Job. Make sure it’s set to run at least once per day.
Important: In SharePoint 2016, there were some major changes made to how the My Site Cleanup Job works. Instead of immediately deleting profiles that are marked for deletion, it schedules the profiles to be deleted after 30 days. The 30-day setting is hard-coded. There is no way to change it. Also, if your build is pre-August 2017 CU (16.0.4573.1002), this functionality does not work at all, even after 30 days. You’ll need to upgrade. See this post for details: https://blogs.msdn.microsoft.com/spses/2017/05/22/sharepoint-2016-mysitecleanup-job-functionality-changes/
If for some reason you can’t wait 30 days to get rid of these profiles, then you’ll have to delete them via PowerShell script. My colleague Adam has a nice option for doing that here: https://adamsorenson.com/deleting-user-profiles-using-powershell/
I’ve also added my own take on a profile deletion script, which is slightly more automated as you don’t have to prepare the input file. Instead, it just deletes all profiles that are bDeleted = 1 in the upa.userprofile_Full table of the Profile database:
# Author: Joroar, et al.
# This PowerShell script is provided “as-is” with no warranties expressed or implied. Use at your own risk.
# Please back up your UPA databases before running this.
# This script will access the UPA associated to the web application given and delete all the user profiles that are marked for deletion
# It will delete all the user profiles that have the BDeleted flag set to 1
# It also makes a web request to log usage data about how often this script is used
# Only one value that needs to be updated below, the $webapp variable. You can also adjust the log location in $logPath if you like
# If there is more than one UPA in the farm, it will prompt you to choose the correct one.
# If you’d like to test a “dry run” first without removing any profiles, just comment out the “$pm.RemoveUserProfile($id)” line
# Update the web application with one that is associated with the target UPA
$webapp = “http://teams.contoso.com”
$logPath = “c:\temp\”
# Declaring and creating the log files. Each time the script is executed, a new file will be created with the current time in the filename.
If the target profiles are managed profiles and not marked for deletion, then you need to look into why the Sync is not marking them for deletion.
Document your Sync connection filters and selected OUs / containers and check your target profiles against them.
Take a look at the MIM Client (miiscleint.exe) on your MIM server. Detailing exactly what to look for in the MIM client is beyond the scope of this blog post, but generally speaking, if you have entire Sync steps that are failing, that’s likely the problem.
MIM Sync Step 3: Run a Full Sync.
If you’ve made recent changes to your Sync connection filters or AD container selection, it takes a Full Sync to apply those changes to all profiles. Also, an Incremental Sync only gets one shot at updating a profile. If something went wrong during the Incremental that ran right after the user fell out-of-scope (deleted from AD, etc), that change is missed. If the user object in AD does not change again, the Incremental will not attempt to pull that user in again. Therefore, a failure during a single run of the Sync could cause the profile to never be processed. For this reason, we recommend that you run a Full Sync on some type of recurring schedule. The interval is up to you, but something between once a week and once a month should work.
MIM Sync Step 4: My Site Cleanup Job
This step is exactly the same as the “ADI Step 4: My Site Cleanup Job” section above. See that.