https://mujportal/mujweb/_catalogs/users/detail.aspx   (nebo jednodušší pohled /simple.aspx)

Na tento list se účet uživatele dostane ihned po přiřazení odpovídajících práv a od té chvíle může být jeho jméno zobrazováno v systémových sloupcích „Created by“, „Modified by“ nebo na koncích stránek v systémových řádcích jako je „Created at … by …“ nebo „Last modified at … by …“, viz obrázek:

Každý záznam osahuje více či méně viditelné atributy jako je jméno, oddělení, fotografie nebo oblíbené „About me“, které však není možné prostřednictvím GUI jakkoliv měnit. Každý uživatel dostane své ID, které je poté dosazováno do linků systémových sloupců a konců stránek tak, aby systém věděl čí profil má zobrazit, pokud někdo na dané jméno klikne a ID je v rámci jedné kolekce jedinečné. (Ano, pokud jich Váš portál má víc, bude ID pokaždé úplně jiné).

O přesměrování na správný uživatelský profil se stará stránka /userdisp.aspx a příslušný atribut. Kdyby náš výše zmíněný „System Account“ dostal číslo 1, vypadal by odkaz takto:

https://mujportal/mujweb/_layouts/userdisp.aspx?ID=1

O existenci UIL nepotřebujete vedět nic, dokud nemáte problém. Pokud synchonizujete uživatelské profily pomocí „User Profile Service“ a měníte povahu uživatelských účtů, může se stát, že se nastavené změny v UIL neprojeví (např. při migraci uživatele mezi doménami, při změně příjmení, při změně domény a ještě navíc i příjmení…). Občas je dokonce profilová stránka uživatele správná, ale data, která uživatel měnil, jsou vázaná stále na starý účet a po kliknutí  na něj se otevře jen stránka s chybou místo fotografie s popiskem. Proč? UIL se odkazuje na špatné ID, protože k němu se žádná informace o změně nedostala. Pokud  založíte úplně novou kolekci webů a požádáte „problémového“ uživatele o nahrání jakéhokoliv souboru, tak  zjistíte, že účet a jméno jsou správné. Jak takové nekonzistence odstranit?

Zatím jsem nenašla postup, který by fungoval na 100% a sama takové „problémové“ uživatele pořád mám, jenže ti vznikli migrací. Možná Vám pomohou následující čtyři tipy:

Poslední možnost trochu rozvedu. Pokud máte podezření, že synchronizace nepracuje tak jak má, otevřete konzoli a spusťte následující příkaz:

stsadm -o sync -listolddatabases X  (kde velké X znamená počet celých dní, nejlépe 0)

Pokud se po zadání tohoto příkazu objeví databáze se starým datem poslední synchrnonizace, můžete její í záznam smazat následujícím příkazem:

stsadm -o sync -deleteolddatabases X (kde velké X znamená počet celých dní, nejlépe 0).

… ona se opět zařadí do pravidelných aktualizací. Příkaz nemaže data, jen neaktuální záznam držený v „config“ databázi.

Pro úplnost dodávám, že uživatelé kterým odebereme právo zápisu, v UIL zůstanou, ale neaktualizují se. Uživatelé, kteří jsou přiřazeni k souboru nebo knihovně, ale kteří nikdy neotevřeli portál, mají záznam v UIL, ale už nemusí mít nutně profilovou stránku. Když tu není nic, co by UIL řeklo že došlo ke změně a účet změní jméno nebo doménu, může být po přihlášení považován za úplně nový objekt (s novým ID).