none
Synchronisieren von AD Element "Contact" möglich? RRS feed

  • Frage

  • Hallo,

    gibt es eine Möglichkeit ebenfalls Kontakte aus dem Active Directory neben Benutzern über die Dienstanwendung "User Profile Service Application" in den SharePoint zu synchronisieren?

    Oder irgendeine andere Art ohne Third-Party Tools?

    Ziel ist einfach nur die Synchronisierung von Kontakten aus dem AD ins SP.

    Vielen Dank

    Dienstag, 7. Juli 2015 08:45

Antworten

  • Hi,
    für diese Aufgabenstellung würde ich einen externen Inhaltstyp programmieren, der für die Anzeige des Telefonbuches und die Suche darin genutzt werden kann. Der externe Inhaltstyp holt sich per Programmcode die Daten aus dem AD, sowohl User als auch Contact. Damit wären die Angaben immer aktuell und die bisherige Pflegetechnologie im AD kann beibehalten werden. Falls das Auslesen der Datzen aus dem AD zu langsam ist, könnte man ein Caching reinprogrammieren, welches mit einer vorgegebenen Verzögerungszeit (z.B. 1 Tag oder 1 h) immer aktuell ist.

    Alternativ wäre auch das regelmäßige Füllen einer Liste per Programm oder PowerShell  aus dem AD möglich. Die Liste ist dann das Telefonbuch. Die Regelmäßigkeit kann durch den Task Manager (bei PowerShell) oder über einen zu programmierenden Timer Job organisiert werden.


    --
    Viele Grüsse
    Peter Fleischer (MVP, Partner)
    Meine Homepage mit Tipps und Tricks


    Donnerstag, 9. Juli 2015 08:39
  • Hi,
    es gibt doch bestimmt einen Grund, warum Kontakte alternativ anstelle Domänen-Nutzer angelegt wurden. Vermutlich sind das Sicherheitsgründe. Das zu ändern, sollte gut überlegt werden.

    Nutzerprofilsynchronisation hat mit der Authentifizierung nichts zu tun. Die Authentifizierung kann z.B. gegen das AD oder auch über FBA organisiert werden. Wenn Du für eine Zone FBA nutzen willst, geht das gegen LDAP-Users oder mit einer eigenen Nutzerdatenbank. Diese Datenbank ist dann aber auch unabhängig von den Kontakten im AD. Du kannst natürlich auch mit einem MembershipProvider gegen die Kontakte prüfen, wobei offen bleibt, wie Kennworte und weitere Angaben verwaltet werden. Der Aufwand zur Programmierung eigener MembershipProvider und RoleProvider ist recht hoch und nicht trivial.

    Möglich ist die Nutzung einer SQL Datenbank mit Nutzern außerhalb des AD. Für diese Nutzer können auch Profile im SharePoint verwaltet werden, die dann auch bei der Personensuche gefunden werden. In diesem Fall ist aber noch zu klären, wie die Kontakte in die SQL Datenbank kommen und wie die weiteren Angaben, wie Kennwort eingepflegt werden.


    --
    Viele Grüsse
    Peter Fleischer (MVP, Partner)
    Meine Homepage mit Tipps und Tricks

    Donnerstag, 9. Juli 2015 05:51

Alle Antworten

  • Hi,
    wie soll den synchronisiert werden? Ein Kontakt ist kein Nutzer. Daraus kann kein Nutzerprofil mit Anmeldekennung usw. erzeugt werden.

    Wenn klar ist, wie Du aus einem Kontakt ein Nutzerprofil erstellen willst, kannst Du auch einen PowerShell Script erstellen, den Du dann regelmäßig (z.B. über den Task Manager) abarbeiten lässt.


    --
    Viele Grüsse
    Peter Fleischer (MVP, Partner)
    Meine Homepage mit Tipps und Tricks

    Dienstag, 7. Juli 2015 19:10
  • Okay, dann habe ich bereits einen Fehler im Ansatz gemacht.

    Ziel ist es die Daten aus den Kontakten im AD über die SharePoint Personensuche auslesen zu können.
    Gibt es hierzu eine empfohlene Vorgehensweise o.ä.?

    Eine Möglichkeit wäre sicherlich für jeden vorhandenen Kontakt im AD einen User anzulegen, jedoch wäre dies mMn etwas zu übertrieben, da lediglich die hinter dem User stehenden Daten für ein "Telefonbuch" benötigt werden.

    Wir haben einen SharePoint mit der Authentifizierungsmethode NTLM und aktiver Userprofileservice Application, die Nutzer aus dem AD in den SharePoint synchronisiert.
    Kann ich parallel dazu FBA aktivieren und User einer SQL Datenbank zusätzlich in den SharePoint migrieren?

    Mittwoch, 8. Juli 2015 12:46
  • Hi,
    es gibt doch bestimmt einen Grund, warum Kontakte alternativ anstelle Domänen-Nutzer angelegt wurden. Vermutlich sind das Sicherheitsgründe. Das zu ändern, sollte gut überlegt werden.

    Nutzerprofilsynchronisation hat mit der Authentifizierung nichts zu tun. Die Authentifizierung kann z.B. gegen das AD oder auch über FBA organisiert werden. Wenn Du für eine Zone FBA nutzen willst, geht das gegen LDAP-Users oder mit einer eigenen Nutzerdatenbank. Diese Datenbank ist dann aber auch unabhängig von den Kontakten im AD. Du kannst natürlich auch mit einem MembershipProvider gegen die Kontakte prüfen, wobei offen bleibt, wie Kennworte und weitere Angaben verwaltet werden. Der Aufwand zur Programmierung eigener MembershipProvider und RoleProvider ist recht hoch und nicht trivial.

    Möglich ist die Nutzung einer SQL Datenbank mit Nutzern außerhalb des AD. Für diese Nutzer können auch Profile im SharePoint verwaltet werden, die dann auch bei der Personensuche gefunden werden. In diesem Fall ist aber noch zu klären, wie die Kontakte in die SQL Datenbank kommen und wie die weiteren Angaben, wie Kennwort eingepflegt werden.


    --
    Viele Grüsse
    Peter Fleischer (MVP, Partner)
    Meine Homepage mit Tipps und Tricks

    Donnerstag, 9. Juli 2015 05:51
  • Mit dem einpflegen der Kontakte in eine SQL DB hast du sicherlich recht, da die Kontakte nicht direkt in den SharePoint synchronisiert werden können bleibt nichts anderes übrig.
    Oder ist dir hier eine bessere Variante bekannt?

    Donnerstag, 9. Juli 2015 07:32
  • Hi,
    was verstehst Du unter "besserer Variante". Kontakte im AD haben keine ausreichende Information für eine Anmeldung. Warum bei Euch Kontakte genutzt werden und woher die unzureichende Information genommen werden soll, kann ich ohne Kenntnis Eurer Entscheidungen zur Infrastruktur nicht sagen.

    --
    Viele Grüsse
    Peter Fleischer (MVP, Partner)
    Meine Homepage mit Tipps und Tricks

    Donnerstag, 9. Juli 2015 07:53
  • Es gibt Mitarbeiter die ohne PC arbeiten und somit keinen Login benötigen.
    Jedoch wurden eben diese bisher als Kontakt im AD gepflegt, als Grundlage für Telefonbücher etc.

    Mit der Einführung von SP2013 und einem neuen Intranet soll das Telefonbuch nun auch im SharePoint liegen. Also müssten die Mitarbeiter, die nur als Kontakte vorliegen irgendwie in den SharePoint.

    Donnerstag, 9. Juli 2015 08:07
  • Hi,
    für diese Aufgabenstellung würde ich einen externen Inhaltstyp programmieren, der für die Anzeige des Telefonbuches und die Suche darin genutzt werden kann. Der externe Inhaltstyp holt sich per Programmcode die Daten aus dem AD, sowohl User als auch Contact. Damit wären die Angaben immer aktuell und die bisherige Pflegetechnologie im AD kann beibehalten werden. Falls das Auslesen der Datzen aus dem AD zu langsam ist, könnte man ein Caching reinprogrammieren, welches mit einer vorgegebenen Verzögerungszeit (z.B. 1 Tag oder 1 h) immer aktuell ist.

    Alternativ wäre auch das regelmäßige Füllen einer Liste per Programm oder PowerShell  aus dem AD möglich. Die Liste ist dann das Telefonbuch. Die Regelmäßigkeit kann durch den Task Manager (bei PowerShell) oder über einen zu programmierenden Timer Job organisiert werden.


    --
    Viele Grüsse
    Peter Fleischer (MVP, Partner)
    Meine Homepage mit Tipps und Tricks


    Donnerstag, 9. Juli 2015 08:39