Office 365 Profilfoto

Genau wie On-Premises gibt es auch in der Cloud die Möglichkeit, dass Anwender ein Bild mit ihrem Konto verbinden. Auch hier ist interessant zu wissen, wer so etwas wie aktualisieren kann und wie der Client darüber informiert wird. Beachten Sie dazu auch die Seiten ADPhoto, Lync Photo und Export-ExchangeUserPhoto.

Bilder im Client

Bei der Betrachtung der Bilder gibt es mehrere Faktoren:

  • Wo werden die Bilder real gespeichert ?
    Das ist eigentlich das Exchange Postfach aber was macht jemand ohne Postfach?
  • Wo kann ein Benutzer oder Admin neue Bilder einstellen?
    Administratoren und Benutzer können Bilder teils selbst aktualisieren
    • SharePoint: My Site
    • Outlook Client
    • Outlook Online
    • Skype for Business Client (springt zu OWA)
    • Yammer
    • Admin: Set-MGUserPhoto (Graph PowerShell)
    • Admin: AADConnect (wenn AD Thumbnail Bilder synchronisiert werden)
  • Wo wird das Bild sichtbar?
    Das sind sehr viele Stellen. Gefunden habe ich bislang:
    • SharePoint: My Site
    • SharePoint: People Search Result
    • SharePoint: People Search Result Contact Hover
    • SharePoint: Newsfeed
    • SharePoint: People Picker Field (configured to show the profile image)
    • Outlook Online: Contact Card
    • Outlook Online: Thumbnail on Existing Email
    • Outlook Online: Thumbnail on Draft Email
    • OutlookClient
    • Office365 Portalwebseite
    • Lync Client
    • Yammer

Wir müssen also etwas beleuchten, wie all diese Clients und Speicher zusammenhängen. Insbesondere wenn Anwender nur Teil-Lizenzen haben und daher einige Speicher nicht erreichbar sind.

Welche Foto ist maßgeblich?

Allerdings gibt es auch in Office 365 ein Mischmasch an Speicherorten, wie wir das schon aus der On-Premises Umgebung kennen. Denn auch gibt es einmal das Bild im Exchange Postfach aber auch das "Thumbnail-Photo", welches über ADSync aus dem lokalen Active Directory repliziert wird. das kann dann zu unterschiedlichen Bildern führen. Hier sehen Sie mein Bild in Delve, welches auch mein Profilfoto aus Exchange ist und parallel auch in Teams, SharePoint etc. genutzt wird.

Ich kann aber auch über das AzureAD ein anderes Bild sehen.

Zu allem Überfluss sehen sie in OneNote aber nun gar kein Bild.

Da kommen natürlich fragen auf

Speicherorte

Wie schon On-Premises gibt es auch in Office 365 und bei Hybrid-Umgebungen auch lokal verschiedene Speicherorte:

Datentopf Größe und Einsatzzweck Zugriffe

Lokales Active Directory: ThumbnailPhoto

<100KB, Ideal für kleine Bilder mit 48x48 oder 96x96 Pixel

AADConnect:READ
Set-MGUserPhoto:WRITE

Azure Active Directory: ThumbnailPhoto

<100KB, Ideal für kleine Bilder mit 48x48 oder 96x96 Pixel

AADConnect: WRITE
Set-MGUserPhoto:WRITE

Exchange Mailbox

max. 500kByte, Bilder bis 648x648 Pixel

Set-MGUserPhoto:WRITE
User: HTTPUpload

SharePoint User Library

Speichert drei Größen
Klein:48 x 48
Mittel: 72 x 72
Groß: 200x200

User: HTTPUpload
Sync von Exchange Postfach

Skype for Business Addressbook

Generiert Bild aus AD

User: ReadOnly

Sowohl Exchange als auch Skype for Business generieren ein "Offline Adressbuch" basierend auf den Daten aus dem Active Directory und ggfls. von Bildern. Dies sind aber immer "ReadOnly"-Kopien und vom Benutzer nicht direkt änderbar. Nach meinen Erfahrungen nutzt Skype for Business dazu das Active Directory bzw. AzureAD. Allerdings könne Outlook als auch Skype for Business angewiesen werden, die Bilder direkt von Exchange per HTTP zu laden.

Replikation

Wenn nun in mehreren Datentöpfen die gleiche oder ähnliche Information liegt, dann ist ein Abgleich eine nützliche Funktion, die von den Produkten auch bereitgestellt werden.

Mittlerweile hat Microsoft auf Information about profile picture synchronization in Microsoft 365 (https://support.microsoft.com/en-us/office/information-about-profile-picture-synchronization-in-microsoft-365-20594d76-d054-4af4-a660-401133e3d48a) eine Beschreibung mit Schwerpunkt SharePoint Online bereit gestellt.

 Folgende Replikationen habe ich bislang ermittelt:

  1. AADConnect
    Per Default synchronisiert AADConnect den Inhalt von "ThumbnailPhoto" aus dem lokalen AD in das Azure Active Directory. Allerdings passiert das wohl nur einmal und spätere Updated werden wohl nicht weiter repliziert.
  2. Exchange holt sich ThumbnailPhoto aus dem AzureAD
    Das macht Exchange aber nur, wenn das Bild <10KB ist.
  3. SharePoint Online holt Exchange Daten
    SharePoint macht das wohl alle 24 oder 72 Stunden. Schneller geht es, wenn der Client über die SharePoint Seite sein Profil anschaut. Dann stößt dies wohl direkt einen Abgleich mit Exchange Online an.
  4. Update mit Set-MGUserPhoto
    Dieses Exchange Commandlet ist für Administratoren das primäre Werkzeug um die Bilder eines Benutzer in Exchange zu aktualisieren.
  5. Update durch Anwender
    Auch Benutzer können das Bild aktualisieren. Skype for Business und Outlook verweisen den Anwender auf die Exchange OWA, um ein eigenes Bild bereit zu stellen. Überall in Office 365 findet sich am Profilfoto die Funktion eben diese Daten auch zu ändern. Es gibt auch den direkten Link auf https://portal.office.com/Userphoto
    Auch über die Office Apps kann das Bild geändert werden. Es kann bis zu 48 Stunden dauern
    https://support.microsoft.com/en-us/office/change-your-profile-photo-555376e0-1fca-49ba-8434-307a0525c767
  6. Exchange 2016 Update
    Mit Exchange 2016 habe ich gesehen, dass ein Hochladen des Fotos per OWA nach einigen Minuten zu einem Update von "Thumbnailphoto" im AD führt. Anscheinend gibt es in Exchange 2016 einen Backgroundprozess, der dies durchführt: Hier sehen Sie einen Trace mit GET-ADChanges. Sie sehen noch die Reste der Aktivierung und dann die Anmeldung (per OWA) mit dem Update des CountryCode und LastLogonTimestamp. Ca. 2 Minuten später ändert sich dann das "Thumbnailphoto". Kurz darauf schreibt ADSync noch ein paar Felder.

    In die Gegenrichtung gibt es keine Replikation, d.h. wer ein Bild in Office 365 aktualisiert bekommt kein aktuelles Thumbnailphoto im lokalen AD

The thumbnailPhoto attribute is synced only one time between Azure AD and Exchange Online. Any later changes to the attribute from the On-Premises environment are not synced to the Exchange Online mailbox.
Quelle: https://support.microsoft.com/en-us/help/3062745/User-photos-aren-t-synced-from-the-On-Premises-environment-to-exchange

“SharePoint Online receives profile information from the Office 365 directory service during regularly scheduled one-way synchronization—which should occur at least every 24 hours” https://support.office.com/en-us/article/Manage-SharePoint-Online-User-profiles-from-the-SharePoint-admin-center-494bec9c-6654-41f0-920f-f7f937ea9723

If the User has updated his/her profile image within the last 72 hours, SharePoint will not show the update until the 72 hours has passed. The reasoning behind the 72 hour delay (according to O365 support) is the extra processing power required to create the 3 sizes of profile images in SharePoint. If a User makes multiple changes in Outlook Online with a 72 hour period, only the first and last will get pushed to SharePoint.
Quelle: https://threewill.com/User-photo-sync-behavior-in-office-365/

Profilfoto in Exchange Online

Sie wissen zwar nun, wie Exchange Online und AADConnect und SharePoint Online zusammen hängen aber sie haben sicher auch mitgenommen, dass das Foto in lokalen AD-Feld "ThumbnailPhoto" aufgrund der Größe und der Einschränkungen bei der Replikation nicht als Lösung angesehen werden kann. In Office 365 ist in Verbindung mit Exchange Online das Profilfoto im Exchange Postfach die Schlüsselkomponente.

Wenn Sie es nun nicht dem Anwender überlassen wollen, sein Bild zu aktualisieren, dann sollten Sie als Administrator die per Provisioning übernehmen. Dabei sind natürlich auch die Datenschutzrichtlinien ihres Unternehmens zu beachten. Insbesondere das Recht des Mitarbeiters am eigenen Bild als auch die Rechte am Bild selbst (z.B. Fotograf). Hier sollten Sie sehr früh mit der Personalabteilung Kontakt aufnehmen, die vielleicht heute schon für jeden Mitarbeiter ein Foto für den Werksausweiß und zur Identifizierung erfasst. Wenn dieses Foto auch den Firmenstandards entspricht und der Mitarbeiter bei der Aufnahme schon sein Einverständnis oder Ablehnung, geben kann, dann steht einem geordneten zentralen Import nichts im Wege.

Hinweis: Das Commandlet "Set-UserPhoto" wird im Jahr 2024 aussortiert. Nutzen Sie stattdessen Set-MGUserPhoto"
MC678855 ExchangePowerShell: retirement of tenant admin cmdlets to Get, Set, and Remove UserPhotos
Deprecation of Exchange Online PowerShell UserPhoto cmdlets
https://techcommunity.microsoft.com/t5/exchange-team-blog/deprecation-of-exchange-online-powershell-userphoto-cmdlets/ba-p/3955744
https://office365itpros.com/2023/10/09/user-photo-cmdlets/

Hier ein Code-Schnipsel, der die Bilder in einem Verzeichnis über die Exchange PowerShell importiert.

$fotolist = (get-childitem  "c:\bilder" -filter "*.jpg")
foreach ($foto in $fotolist) {
   write-host "Importing " $foto.name
   Set-UserPhoto `
      -Identity ($foto.basename + "@netatwork.de") `
      -PictureData ([System.IO.File]::ReadAllBytes($foto.fullname)) `
      -Confirm:$False
}

Profilfoto mit Exchange On-Premises

Wenn Anwender in Office 365 unterwegs sind, dann bedeutet dies nicht automatisch, dass auch ihr Postfach in der Cloud liegt. Das Postfach kann ja durchaus On-Premises liegen und damit für den Cloud-Benutzer erreichbar sein. Das bedeutet aber nicht, dass auch andere Benutzer in der Cloud das Bild im lokalen Postfach auslesen können. Der Exchange Server veröffentlich das Bild zwar per URL aber nicht für anonyme Anfragen.

Aber Office 365 weiß natürlich, dass der Benutzer ein lokales Postfach hat und versucht darauf zuzugreifen. Wenn daher die Auflösung des Postfachs per Autodiscover möglich ist, können Dienste auch das Bild eines lokalen Postfachs finden. Hier sind aber zwei Zugänge zu unterscheiden.

  • Der Client holt sich selbst das Bild
    Wenn ein Client sich das Bild direkt vom Exchange Server selbst holt, dann muss ich der Anwender an dem Exchange Server natürlich ausweisen. Solange es sich hierbei um ein Domänenmitglied handelt, ist das nicht wirklich ein Problem. Der Client bekommt da Bild.
  • Ein Server holt sich das Bild im Auftrag des Clients oder als Prozess
    Anders sieht es aus, wenn der Anwender z.B. über eine Webseite in Office 365 zugreift oder ein Serverprozess wie SharePoint, Exchange OAB, sich Bilder in seine eigene Datenbank überträgt. Dann greift der "Computer" auf das Postfach zu. Hier muss die entsprechende Authentifizierung auch über die Grenzen hinweg möglich sein.

Mit der Einrichtung des Exchange Hybrid Mode werden vom Hybrid Konfiguration Assistent die erforderlichen Einstellungen vorgenommen, damit ein Service in der Cloud auch auf die Bilder in lokalen Postfächern zugreifen kann.

Profilfoto im Postfach

Das Profilfoto im Postfach können Sie sogar mit EWSEditor oder MFCMAPI sehen.

User photos are stored in the user's Active Directory account and in the root directory of the user's Exchange mailbox
Quelle: https://docs.microsoft.com/en-us/powershell/module/exchange/get-userphoto

Im Ordner "Non_IPM_Root" des Postfachs gibt es ein Element mit der ´Nachrichtenklasse "IPM.UserPhoto" und den verschiedenen Properties:

Hier ist gut zu erkennen, dass Exchange die Bilder in den entsprechenden Auflösungen ablegt.

Profilfoto ohne Exchange Postfach

Ein Sonderfall ist ein Benutzer, der kein Exchange Postfach hat und daher der Exchange Speicher als "Master" ausfällt. Wenn ich in diesem besonderen Fall als Anwender mein Profil-Foto ändere, dann lande ich nicht auf Exchange sondern direkt in der SharePont

Diesen Fall können Sie einfach provozieren, indem Sie einen Benutzer die Exchange Lizenz entziehen. Jeder Zugriff landet dann auf der SharePoint URL in der Form.

https://%tenantname%-my.sharepoint.com//_layouts/15/editprofile.aspx?UserSettingsProvider=xxxxx

Eine Synchronisation mit dem AzureAD Attribut "ThumbnailPhoto" ist hier wohl nicht vorgesehen. In diesem Fall können Sie aber auch die Bilder zentral verwalten. Die Profilbilder in SharePoint liegen in einer eigenen Dokumentlibrary.

Ein Office 365 Benutzer ohne Exchange Postfach ist aber auch anderweitig limitiert. So kann Skype for Business das kleine Bild zwar anzeigen aber der Link zu Bearbeitung funktioniert nicht.

Auch ein Update über die URL https://portal.office.com/Userphoto funktioniert nicht ohne ein Exchange Postfach.

AADConnect und Thumbnail Photo

AzureAD Connect kann die Bilder aus dem lokalen Active Directory in den Office 365 Tenant replizieren. Ein Blick in den "Synchronization Rule Editor" zeigt, wo das Feld verwendet wird:

In der Transformation Rule für "User Common" wird das Feld 1:1 in das Metaverse übertragen:

Ausgehend Richtung AzureAD ist zu sehen, dass das Feld schon aufgrund mehrerer Regeln wieder exportiert wird:

Auch dort wird das Feld wieder 1:1 in das AzureAD geschrieben. Wenn ich die Konfiguration hier aber richtig interpretiere, dann ist das Feld "ThumbnailPhoto" der lokalen On-Premises Instanz immer führend und wird auch immer in AzureAD aktualisiert. Es wird aber nie zurück geschrieben. Änderungen im Office 365 Tenant kommen daher nie im lokalen Active Directory an.

Wer Bilder in beiden Welten pflegt, sollte überlegen, wie hier vielleicht ein Provisioning hilft, damit ein Anwender nur eine Seite pflegen muss und davon abgeleitet dann die andere Seite möglichst automatisiert aktualisiert wird. Mit Exchange kann ein privilegierter Benutzer im gleichen Tenant das Bild ja recht einfach per URL beziehen.

https://outlook.office.com/ews/Exchange.asmx/s/GetUserPhoto?email=<User EMAIL>&size=HR96x96

Ein Administrator kann das dann per PowerShell machen. Leider liefern weder "Get-MSOLUser" noch "Get-AzureADUser" ein Feld mit dem ThumbnailPhoto. So bleibt nur die PowerShell.

$PictureData = (Get-UserPhoto -Identity demo4).PictureData
[System.IO.File]::WriteAllBytes("C:\temp\demo4.jpg", $PictureData)

Es sollte also möglich sein diese Bilder immer mal wieder aus Office 365 zu extrahieren und lokal weiter zu verwenden.

Foto für Guest Benutzer

Neben den normalen "Cloud Only" Benutzern und die per ADSync verwalteten Anwender gibt es natürlich noch Gäste, die in jedem Tenant manuell oder dynamisch angelegt werden. Gäste sind Platzhalter für Identitäten, die in anderen Tenants oder Umgebungen existieren aber Zugriff auf Informationen in ihrem Tenant haben. Dies kann ein Zugriff per Teams, OneDrive, SharePoint o.ä., sein. Normalerweise ist für Office 365 nur die Mailadresse, die zugleich als Anmeldename dient, relevant. Andere Stammdaten wie z.B. die Telefonnummern oder eben auch Bilder werden bei der Anlage normalerweise nicht ergänzt. Wenn Sie aber die Bilder haben oder externe Personen mit einem nützlichen Symbolbild versehen wollen, dann können Sie auch bei Gästen ein Bild hinterlegen

Das ganze geht mit dem AzureAD-PowerShell-Befehl Set-AzureADUserThumbnailPhoto relativ einfach. Sie benötigen aber die ObjectID des Users, die sie sich vorher mit Get-AzureADUser besorgen können.

$user = Get-AzureADUser user1@uclabor.de
Set-AzureADUserThumbnailPhoto `
  -ObjectId $user.objectid `
   -FilePath C:\temp\foto.jpg

Wer auch hier die Bilder z.B.: mit einem UPN als Name gespeichert hat, kann natürlich eine Schleife über die Dateien in einem Verzeichnis machen und Bilder massenhaft importieren.

Hinweis: Dieser manuelle Schritt ist nur für Objekte sinnvoll, die nicht durch ADSync verwaltet werden, da hier der Inhalte von Thumbnailphoto des lokale Active Directory bei der nächten lokalen Änderung oder einem FullSync in die Cloud geschrieben wird.

Bilder in Delve

Ein Portal für Anwender ist Delve, indem alle letzten Änderungen und Dokumente zu sehen sind. Hier gibt es auch einen Weg das Profilbild zu ändern. Bei der Analyse der URLs ist mir aber aufgefallen, dass es quasi keinen Exchange Zugriff gibt, der ein Bild zu Exchange Online hoch lädt. Es werden nur einmal die OOF-Einstellungen geladen. Alles andere erfolgt über die SharePoint-Seiten:

Das führt zu den Probleme, dass ein Bild in Delve zwar von SharePoint kommt aber im Office 365 Portal nicht sichtbar ist

Ich kann das Bild weder in OWA (da kein Exchange Postfach) noch mit Delve ändern.

Einzig über die SharePoint "My-Site" kann ich das Bild ändern. Die Daten landen und bleiben dann aber in SharePoint.

Profilbilder in Skype for Business Online

Wenn ich meinen Skype for Business Client starte, dann sehe ich den Abruf auf Exchange um ein Bild zu erhalten. Dieser Benutzer hat wohl noch kein Bild

Genauso sehe ich das auch in der GUI aber ich kann es ändern.

Der Link verweist auf die URL

https://outlook.office365.com/owa/?path=/options/myaccount/action/photo

Wenn ich ein Bild über OWA hochgeladen habe, dann ist auch der Post-Request zu sehen:

POST /owa/service.svc?action=UploadPhoto&EP=1&ID=-61&AC=1 HTTP/1.1

Der Skype Client holt sich das Bild auch direkt wieder aus Exchange

In einem Fiddler-Trace kann ich gut sehen, dass mein Skype Client mein eigenes Bild in Zeile 1 sowohl mit 648x648 Pixeln aber auch in Zeile 3 mit 96x96 lädt. Sie sehen aber auch, dass alle Zugriffe "authentifiziert" erfolgen.

In Zeile 2 sehen Sie den Zugriff auf ein nicht existentes Postfach. Der SfB Client fragt den Exchange Server des angemeldeten Benutzers und nicht den fremden Exchange Server. Andere Mitarbeiter in der Umgebung werden in Zeile 4/5 mit der einfachen Auflösung mi 96x96 Pixel angezeigt.

Notify in Skype

Ich habe per Webbrowser beim Bild geändert und daneben direkt den Skype for Business Client samt Konfigurationsdialog offen gehabt. Interessant war hier, dass eine Änderung des Profilfotos auf dem Skype Client quasi innerhalb von Sekunden aktualisiert wurde. Da musste ich ja schon direkt in das UCCPILOG schauen. Hier finde ich einen "NOTIFY". Ich habe das Paket gekürzt, da der Payload die gleiche Information für unterschiedliche "Container" wiederholt. 

06/18/2018|11:54:23.444 4BAC:106C INFO  :: NOTIFY sip:13.100.11.253:16008;transport=tls;
   ms-opaque=b799556092;ms-received-cid=41D2E00;grid SIP/2.0
ms-User-logon-data: RemoteUser
Via: SIP/2.0/TLS 13.100.10.147:443;branch=xxx.xxx;branched=FALSE;ms-internal-info="xxx"
Authentication-Info: TLS-DSK qop="auth", opaque="xx", srand="xx", snum="23", rspauth="xxx", 
   targetname="DM10A23FES05.Infra.lync.com", realm="SIP Communications Service", version=4
Max-Forwards: 69
Via: SIP/2.0/TLS 13.100.10.152:37224;branch=xxx.xxx;branched=FALSE;ms-received-port=37224;ms-received-cid=4128A00
To: <sip:demo4@uclabor.de>;tag=xx;epid=xx
Content-Length: 7291
From: <sip:demo4@uclabor.de>;tag=xx
Call-ID: xx
CSeq: 4 NOTIFY
ms-telemetry-id: xxxxxx-xxxx-xxxx-xxx-xxxxxx
Require: eventlist
Content-Type: application/vnd-microsoft-roaming-self+xml
Event: vnd-microsoft-roaming-self
subscription-state: active;expires=31358
Supported: ms-dialog-route-set-update
<roamingData xmlns="http://schemas.microsoft.com/2006/09/sip/roaming-self" 
   xmlns:cat="http://schemas.microsoft.com/2006/09/sip/categories">
<categories xmlns="http://schemas.microsoft.com/2006/09/sip/categories" uri="sip:demo4@uclabor.de">
<category name="contactCard" instance="0" publishTime="2018-05-14T07:19:44.460" 
   container="100" version="8" expireType="static">
<contactCard xmlns="http://schemas.microsoft.com/2006/09/sip/contactcard" >
<identity >
<name ><displayName >Net at Work Webcast</displayName></name>
<email >demo4@uclabor.de</email></identity></contactCard>
</category>
<category name="contactCard" instance="4" publishTime="2018-06-07T12:51:29.040" 
   container="100" version="151" expireType="static">
  <contactCard xmlns="http://schemas.microsoft.com/2006/09/sip/contactcard" isUCEnabled="false">
    <url type="voicemail">sip:demo4@uclabor.de;opaque=app:voicemail;local-resource-path=voicememo</url>
  </contactCard>
</category>
<category name="contactCard" instance="6" publishTime="2018-06-18T09:54:22.983" container="100" version="6" expireType="static">
  <contactCard xmlns="http://schemas.microsoft.com/2006/09/sip/contactcard">
    <delimiter xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes"></delimiter>
    <delimiter xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes"></delimiter>
    <displayADPhoto>true</displayADPhoto>
    <photo type="exchange" updated="2018-06-18T09:54:22Z">
    <uri>&lt;ewsUrl&gt;https://outlook.office365.com/EWS/Exchange.asmx/WSSecurity&lt;
            /ewsUrl&gt;&lt;primarySMTP&gt;demo4@uclabor.de&lt;/primarySMTP&gt;</uri>
    <hash>&quot;0F43E3A7&quot;</hash></photo>
  </contactCard>
</category>
...

Das Paket ist vom "06/18/2018|11:54:23.444 4BAC:106C" und meldet, dass das Foto am "updated="2018-06-18T09:54:22Z"" aktualisiert wurde.

Der Client quittiert den Notify.

06/18/2018|11:54:23.458 4BAC:106C INFO  :: Sending Packet - 52.112.64.87:443 (From Local Address: 10.255.254.210:54607) 895 bytes:
06/18/2018|11:54:23.458 4BAC:106C INFO  :: SIP/2.0 200 OK
Via: SIP/2.0/TLS 13.100.10.147:443;branch=xxx.xxx;branched=FALSE;ms-internal-info="xxx"
Via: SIP/2.0/TLS 13.100.10.152:37224;branch=xxx.xxx;branched=FALSE;ms-received-port=37224;ms-received-cid=4128A00
From: <sip:demo4@uclabor.de>;tag=9C350080
To: <sip:demo4@uclabor.de>;tag=e6cc7a307c;epid=b6c76ccc34
Call-ID: 88c90d52db3f43b0952752f0ccbee873
CSeq: 4 NOTIFY User-Agent: UCCAPI/16.0.10228.20021 OC/16.0.10228.20021 (Skype for Business)
Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="DA29C5C9", 
   targetname="DM10A23FES05.Infra.lync.com", crand="6e048d2e", cnum="23", response="xxx"
Content-Length: 0

06/18/2018|11:54:23.458 4BAC:106C INFO  :: End of Sending Packet - 52.112.64.87:443 (From Local Address: 10.255.254.210:54607) 895 bytes

Das neue Bild wird aber nicht per SIP übertragen. Mit Fiddler kann ich dann sehen, welche URL der Client kurz nach dem Notify nachlädt.

Bild mit https://portal.office.com/Userphoto

ÜÜber diese direkte URL kann ein Anwender sehr einfach ebenfalls sein Bild ändern. Er muss dazu also nicht erst in OWA oder SharePoint unterwegs sein.

Das Bild wird nach dem "Zuschnitt" einfach als "Form POST" hochgeladen.

In dem Beispiel konnte ich das Bild aber nicht hochladen. Der Benutzer hatte kein Exchange Postfach. Ein Benutzer mit einem Exchange Online Postfach kann hingegen über diesen Weg sein Bild aktualisieren.

Zentrales Provisioning und Benutzer blockieren

Wenn Sie eine strenge Firmenrichtlinie haben, dann kann es durchaus erforderlich sein, dem Benutzer die direkte Pflege des eigenen Fotos zu verhindern. Einige meiner Kunden haben hier einen Prozess etabliert, das die Bilder ein bestimmtes Niveau haben und vor allem auch der Datenschutz gewährleistet wird. Jeder Mensch hat nämlich ein Recht an seinem Foto und muss der Veröffentlichung aktiv zustimmen. Wenn Sie als Administrator sich also mal eben alle Bilder per "Set-UserPhoto" bereitstellen, begibt sich auf dünnes Eis.

Für die Definition des Prozesses gibt es allerdings keine Blaupause. Einige Firmen fotografieren die Mitarbeiter für die Ausstellung von Ausweisen und können dann hier gleich die Erlaubnis mit einholen und die Qualität sichern. Andere Firmen ermöglichen es den Anwendern selbst die Bilder hochzuladen. Wenn Sie aber zentral die Bilder bereitstellen, dann kommt schnell die Forderung auf, dass der Benutzer nicht selbst das Bilder an ihrem Prozess vorbei ändern kann.

  • Abschalten in OWA
    Die meisten Änderungen werden über Exchange durchgeführt, so dass Sie hier per OWA-Policies dies deaktivieren können.
Get-OwaMailboxPolicy | Set-OwaMailboxPolicy -SetPhotoEnabled $false

Es könnten natürlich immer noch Hintertüren offen sein, z.B. kann der Anwender per LDAP/ADSI natürlich seine ThumbnailPhoto-Attribute ändern und per EWS/MAPI sicher auch die Bilder in Exchange an OWA vorbei ändern. Auch der direkte Zugriff auf die folgende URL ist noch nicht durch die OWAPolicy blickiert

https://outlook.office.com/mail/changephoto

Aber dann hat der Anwender selbst die Änderung durchgeführt. Für eine Firma könnte es dennoch erforderlich sein, die aktuelle Bilder als Snapshot immer mal wieder zu exportieren und mit einem Soll-Stand zu vergleichen.

Zwischenstand

Ich wollte eigentlich nur einen kleinen Artikel für die Profil-Fotos in Office 365 schreiben. Dazu habe ich zuerst einige Quellen zusammen getragen und dann ein paar Tests gemacht. Soweit war auch noch alles "einfach". Dann kam aber die Herausforderung eines Projekt, bei dem die Anwender zwar Skype for Business Online benutzen sollen aber noch nicht mit Exchange Online arbeiten sollen. Das Postfach in der Cloud darf erst im Zuge der Migration von einem alten lokalen Mailsystem freigegeben werden.

Dieser Anwendungsfall ist ein Office 365 aber entweder sehr selten oder wurde noch nicht eskaliert. Ohne Exchange Postfach ist die Nutzbarkeit des Profilfotos doch sehr eingeschränkt bis gar nicht möglich. Da bleibt nur zu hoffen,. dass dieser Sonderfall nur sehr kurz anhält oder sich niemand beschwert. Ich habe bis zum Schluss einen Benutzer "Demo4" gehabt, bei dem ich alle drei Konfigurationen nebeneinander vorliegen habe.

  • Bild 1 in Sharepoint, welches ich sehen und ändern kann
    Ich ändere und sehe das Bild aus dem SharePoint MySite-Bereich
  • Bild2 in Delve und Skype for Business, welches ich aber wohl nicht mehr ändern kann
    Ich weiß nicht wo Skype for Business dieses Bild letztlich bezieht. Ich tippe auf das Skype OAB. Auch Delve zeigt dieses Bild an
  • "Kein" Bild im Office 365 Portal
    Die anderen Office 365 Webseiten zeigen nur das graue Buchstaben-Logo an

Ich werde mal einige Stunden warten, ob sich der Zustand dann bessert. Einige Dinge brauchen wohl etwas länger. Auf der sicheren Seite sind sie wohl nur mit einem Exchange Online Postfach. Sie können dennoch natürlich die Bilder der Anwender auch im SharePoint Profil hinterlegen. Denken Sie aber dran, dass es keine Replikation von SharePoint zu Exchange gibt. Sobald der Anwender später ein Exchange Postfach bekommt und dort das Bild ändert, wird es auch in SharePoint neu gesetzt.

Weitere Links