What You Need to Know About SharePoint Server 2016 Installation and Upgrade

You may also like...

3 Responses

  1. JCrowe says:

    Hi, I’ve got the SharePoint 2016 IT Preview stood up in Azure with:

    Windows Server 2012 R2 Domain Controller serving as the ADDS
    Windows Server 2012 R2 serving MSSQL 2016
    Windows Server 2012 R2 serving the SharePoint 2016 IT Preview bits

    It appears from your article and other being published (including Microsoft) – FIM client is no longer used to synchronize between Active Directory and SharePoint. The default process is Active Directory Import.

    After testing with AD user accounts it seems the same known issues are still present in SP 2016 Active Directory Import that were present in SP 2013. Primarily the import works however, if an account is later marked “disabled” or deleted from AD SharePoint 2016 is not marking the record for delete.

    The LDAP “Filter out disabled users ” does not work against records previously imported. It does work if they are marked when the record is created in AD.


    Any thoughts on this issue?

  2. Zubair Alexander says:


    Everything that you have mentioned in your comment is correct. I ran several tests in SP2016 (on-premises) to see if the issue in SP2013 that you’ve mentioned still exists in SP2016. Unfortunately, the problem has not been fixed in SP2016. Once you import an AD user into SharePoint, there is no automated way to clean the deleted users. Even if you delete the user account in AD and then manually run the timer job called “My Site Cleanup job” in SharePoint, the user will still remain in SharePoint. It’s like Jason in the movie Friday the 13th, you can’t kill him no matter what you do.

    If the user is disabled, the synchronization process will not import it into SharePoint, which is great. However, like you said, if the user is disabled after the account was imported in SharePoint, the user profile won’t be cleaned and the account will remain in SharePoint. So far, the only workaround I have seen from Microsoft is to use PurgeNonImportedObjects command, which is going to delete all the objects that are NOT being imported. This is not really a “workaround” because as Microsoft points out, this will delete all of the following:
    1. Users that were created manually.
    2. Users that are not imported because of a change in OU selection, Disabled Account, Filtered, etc.
    3. Users that were automatically created by browsing to MySite host.

    Frankly, a better workaround is to manually delete the user under Manage User Profiles. Obviously, this won’t really help when you have a large number of users because the process is not automated. If the accounts are disabled and still exist in SharePoint, you could rename these accounts in AD (e.g. use an underscore at the beginning of each disabled account), then run the synchronization, go to Manage User Profiles, search for underscore, select all, then delete them.

    Another workaround you may want to try is to add the following at the end of the Site Collection URL: _catalogs/users/simple.aspx or _catalogs/users/detail.aspx. For example, http://intranet.contoso.com/_catalogs/users/simple.aspx. This will get you the hidden User List Information for the users that visited the Site Collection. You can then select all the users that were deleted in AD and then clean them from this list. You need to repeat this step for each Site Collection that the users browsed. I realize these are not solutions to a known issue in SharePoint 2013/2016, I am just trying to come up with some possible workarounds for you :-).

    I will look into this further and post an update on my blog if I have a better workaround, or a fix from Microsoft.

  3. JCrowe says:

    Additional discovery:

    Issue – The account is never deleted automatically from SharePoint Profile Store even if disabled in Active Directory or deleted in Active Directory.

    1. User logs into SharePoint and creates a MySite (Waffle Icon > Sites). This kicks of the One Drive and creates a site

    2. Delete the user account from AD and run import

    3. Manage User Profiles > Find Profile (domain name) > View “Profiles Missing from Import”

    4. Deleted Profiles will be populated and can manually deleted

    5. While this will remove the profile from having the profile store it does not remove the user name from any sites/resources they previously had access to.

    6. If the user never creates a MySite they are never deleted from the Profile Store

    7. If the user account is later disabled in Active Directory the user profile remains in the Profile Store

    Scenario 1:
    A. User in AD is imported to SP2016 using Active Directory Import
    B. User logs into SharePoint and creates a “MySite”
    C. User is deleted from AD
    D. User can be removed from profile store using the “Profiles Missing from Import”
    E. User account name is left in the SharePoint Security Group (Owners, Members, Vistors) and must be deleted manually

    Scenario 2:
    A. User in AD is imported to SP2016 using Active Directory Import
    B. User logs into SharePoint and DOES NOT create a “MySite”
    C. User is deleted from AD
    D. User profile remains in the Profile Store
    E. User account name is left in the SharePoint Security Group (Owners, Members, Visitors) and must be deleted manually

    I suppose a method would be to pragmatically create the users MySite and manage deletes via the “Profiles Missing from Import” option. Even a large organization should be manageable.

    Your thoughts?

    Thank you,

Leave a Reply

Your email address will not be published. Required fields are marked *

two × three =