SharePoint 2019
PeoplePicker qui ne trouve personne dans l’annuaire
Bonjour,
Suite à une migration entre SharePoint 2013 > 2016 > 2019, et passant de Kerberos à Claims, j’ai observé un comportement étrange sur les PeoplePickers (sélecteur de personnes dans SharePoint, associé à une métadonnée de type Personne ou Groupe). En effet, ces derniers ne résolvaient plus les noms !
Dans l’usage classique, lorsque l’on commence à taper le nom d’un collaborateur dans une métadonnée de type Personne, une requête est lancée en direction de l’annuaire (ou des annuaires) afin de récupérer les identités des personnes dont le nom ou le prénom contient les lettres recherchées. Au retour de la requête, les propositions concordantes sont affichées à l’utilisateur qui pourra choisi celle qui l’intéresse.
Lors de cette migration, les PeoplePickers ne résolvaient plus rien, ne proposaient plus rien. Cependant la validation des noms en entrant l’adresse e-mail (UPN) suivi de Ctrl + K validait bien le champ. Etrange !
J’ai tout d’abord pensé à un problème sur la requête ou autour, plus précisément à un port bloqué par le firewall. Non dans mon cas ce n’était pas ca.
Dans les Logs ULS, j’avais peu d’éléments mais quelques erreurs remontaient toutefois, du type :
- Exception from site settings manager. Using default value. Key: ‘EveryoneClaimEnabled’, Default: ‘True’
- Error in resolving user. User: ‘Michel’, ResolverInformation: ‘SPActiveDirectoryPrincipalResolver, DomainName: ‘tatooine.local’, DomainIsForest: ‘True’, DomainLoginName: ”, CustomSearchQuery: ”, CustomSearchFilter: ”, Timeout: ’00:00:30′, IncludeDistributionList: ‘True”, Exception: ‘System.Runtime.InteropServices.COMException (0x8007203A): The server is not operational. at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail) at System.DirectoryServices.DirectoryEntry.Bind() at System.DirectoryServices.DirectoryEntry.get_AdsObject() at System.DirectoryServices.DirectorySearcher.FindAll(Boolean findMoreThanOne) at Microsoft.SharePoint.WebControls.PeopleEditor.SearchFromGC(SPActiveDirectoryDomain domain, String strFilter, String[] rgstrProp, Int32 nTimeout, Int32 nSizeLimit, SPUserCollection spUsers, ArrayList& rgResults) at Microsoft.SharePoint.Utilities.SPUserUtility.SearchAgainstAD(String input, Boolean useUpnInResolve, SPActiveDirectoryDomain domainController, SPPrincipalType scopes, SPUserCollection usersContainer, Int32 maxCount, String customQuery, String customFilter, TimeSpan searchTimeout, Boolean& reachMaxCount) at Microsoft.SharePoint.Utilities.SPActiveDirectoryPrincipalResolver.SearchPrincipals(String input, SPPrincipalType scopes, SPPrincipalSource sources, SPUserCollection usersContainer, Int32 maxCount, Boolean& reachMaxCount) at Microsoft.SharePoint.Utilities.SPUtility.SearchPrincipalFromResolvers(List1 resolvers, String input, SPPrincipalType scopes, SPPrincipalSource sources, SPUserCollection usersContainer, Int32 maxCount, Boolean& reachMaxCount, Dictionary2 usersDict)’, ExceptionStackTrace: ‘ at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail) at System.DirectoryServices.DirectoryEntry.Bind() at System.DirectoryServices.DirectoryEntry.get_AdsObject() at System.DirectoryServices.DirectorySearcher.FindAll(Boolean findMoreThanOne) at Microsoft.SharePoint.WebControls.PeopleEditor.SearchFromGC(SPActiveDirectoryDomain dom… 0094b8a0-2951-e0fc-8428-cb70dfc9d300
Je vous passe les recherches infructueuses, les tests, le parcours de centaines de lignes de logs etc. Alors la solution à mon problème… C’est quoi ?
En fait, il m’a fallu modifier un paramètre dans la WebApplication, accessible en PowerShell pour aller implémenter un objet forçant la recherche sur l’annuaire (sa forêt en l’occurence), et qui finalement est relativement simple :
$wa = Get-SPWebApplication | ? { $_.displayname -eq "Intranet" }
$SearchAD = $wa.PeoplePickerSettings.SearchActiveDirectoryDomains
$domain = New-Object Microsoft.SharePoint.Administration.sppeoplepickersearchactivedirectorydomain
$domain.DomainName = "tatooine.local"
$domain.IsForest = $true
$SearchAD.Add($domain)
$wa.Update()
Et c’est tout, enfin pensez à faire un petit IISReset /noforce sur tous les frontaux Web.
NB : Pensez à vérifier :
- le nom du domain, on parle du haut de la forêt et le paramètre IsForest vous permettra de rechercher partout ($true = partout ; $false = sur le niveau supérieur seulement)
- Le nom de votre WebApp, j’ai mis Intranet ici, à vous d’adapter dans votre contexte
A bientôt !
Sources :
CountDictionary() : Fonction JavaScript non supportée dans SP2016 et SP2019
Bonjour,
Suite à la migration d’un de mes clients de SharePoint 2013 vers SharePoint 2019 (en passant par SP2016 évidemment), je me suis aperçu qu’une fonction bien pratique n’était plus disponible ! Il s’agit de la fonction CountDictionary() qui permettait d’énumérer et compter les éléments dans un dictionnaire.
Vous l’aurez probablement utilisée dans des CustomAction placées dans le ruban de SharePoint par exemple, afin de vérifier qu’un élément au moins était sélectionné dans un affichage (vue liste / bibliothèque de document par exemple).
Heureusement il est possible de corriger le problème en modifiant son fichier source JavaScript et en ajoutant la fonction directement :
function CountDictionary(b) {
var a = 0, c;
for (c in b)
a++;
return a
}
Il est probable que d’autres fonctions aient été “oubliées” sur la longue route de SharePoint et ses migrations… mais pour l’instant je ne suis tombé sur aucun de ces cas 🙂
A bientôt ! (en tout cas je l’espère… depuis le temps que je n’avais pas publié !)
Florent Cazenave 