Namenswechsel

Nein, ich bin nicht mit Lync verheiratet aber eine Heirat ist bei einem Anwender oft auch Anlass, seinen Namen zu ändern. Und das hat durchaus Auswirklungen, wenn sich z.B. der Nachname ändert und das Konto des Anwenders dann auch im Computersystem angepasst werden muss. Diese Seite beschreibt die Auswirkungen auf Lync.

Siehe auch SIPDomainRename und Office 365:UPN / Anmeldename

Das AD-Objekt, UPN und SamAccountName und ACLs

Es liegt natürlich nahe, dass der Benutzer im Active Directory "korrigiert" wird. Hier kommen mehrere Felder in Betracht:

  • DisplayName, sn (Surname)
    Dieser Felder sind recht einfach direkt über die MMC für Active Directory Benutzer und Computer oder andere Tools zu ändern. Die Änderung ist als unkritisch anzusehen.
  • DN/RDN
    Der Name des LDAP-Objekts ist bei einigen Firmen ebenfalls mit dem Nachnamen verbunden. Der Name kann durch einen "Rename" ebenfalls geändert werden und sollte in der Regel keine Auswirkungen haben. Eine Ausnahme hier ist aber Lync 2013, wie ich weiter unten beschreibe.
  • SamAccountName
    Wenn der alte "Windows Anmeldename" auch mit dem Nachnamen verbunden ist, dann können Sie den Namen natürlich auch ändern. Allerdings ist das nicht mehr zwingend so ungefährlich, da dieser Name z.B. vom Anwender eventuell eingegeben wird (Domäne\SamAccountName). Zudem wird der Name gerne auch in Skripten verwenden, z.B. zur Verbindung von Laufwerken, insbesondere des Homelaufwerk. Auch gibt es gerne mal Programme, die dieses Feld für eigene Zwecke nutzen. Es kann also sein, dass der umbenannte Benutzer für die ein oder andere Software ein "neuer" Benutzer ist. Denken Sie z.B. an Gruppenrichtlinien zur Verwaltung von Gruppenmitgliedschaften, die teilweise nicht aus SIDs sondern auf dem String aufbauen.
  • UPN
    Der UserPrincipalName ist oft mit der Mailadresse und SIP-Adresse identisch und kann in dem Zuge mit geändert werden. Auch hier gelten im wesentlichen die Probleme des SamAccountName. Der Anwender muss den Namen ggfls. dann geändert eingeben.

Die SID des Benutzer ändert sich dabei aber ebenso wenig wie die ObjectGUID oder die Mitgliedschaft in Gruppen, welche von verschiedenen Programmen ebenfalls genutzt wird. Dies ist besonders wichtig im Hinblick auf ACLs, die sich an der SID orientieren. Auch der umbenannte Benutzer hat damit weiterhin die gleichen Berechtigungen wie vor der Umbenennung.

Provisioning, etc.

Nicht immer die die "Umbenennung" direkt im AD der richtige Weg. Je größer eine Firma ist, desto eher werden die Benutzer eben nicht mehr von Hand verwaltet, sondern über eine eigene Software gepflegt oder sogar direkt aus den Personalstammdaten abgeleitet. Dann ist es natürlich in der Hand dieser Software, den "Rename" richtig zu machen. Werden die Daten quasi über einen DirSync-Prozess abgebildet, dann muss dieser zumindest in der Quelle den "Rename" erkennen, damit auch im Ziel das nun nicht mehr passende Objekt weiter gefunden wird. Es wäre sehr ungeschickt, wenn der Displayname hier quasi der "Matchcode" wäre. In der Regel wird hier aber z.B. einer Personalnummer genutzt, die in einem freien AD-Feld mit abgelegt wird oder ein eindeutiger Identifier aus dem AD wird in die Quelle oder das Metaverse zurück übertragen.

Der große Vorteil einer Provisioning-Lösung ist allerdings, dass Sie eben nicht nur mal schnell die Felder "sn" und "Displayname" ändert, sondern auch alle anderen erforderlichen Änderungen durchführen kann, die ich im folgenden beschreibe. Auch wenn Sie kein DirSync oder Provisioning bislang wissentlich eingesetzt haben, so gibt es in vielen Firmen dennoch solche Mechanismen, die sie nicht übersehen dürfen. Viele davon können mit einem "Rename" umgehen, z.B. repliziert Lync die Anwender in seinen SQL-Server oder Office 365 nutz einen DirSync um die Identitäten in der Cloud mit zu pflegen.

Es kann aber durchaus auch andere Produkte geben, die die AD-Daten nicht direkt verwenden, sondern eine Kopie  in einem eigenen Datenbestand halten. Hier sollten sie schon neugierig sein, ob die Software z.B. einen Änderung des UPN oder DN/RDN korrekt verarbeitet und nicht den nicht mehr auffindbaren Benutzer löscht und ein neues Benutzerobjekt dafür anlegt.

Rename und Office 365

Wer Office 365 mit einer On-Prem-Umgebung per DirSync verbunden hat, muss die Änderungen nur On-Premises durchführen. Auch wenn beim ersten "Matchen" der UPN eine wichtige Rolle spielt, werden alle späteren Änderungen über einen Object-Identifier (eine Art GUID) durchgeführt. Es ist also unkritisch, wenn Sie Systemfelder wie den SAMAccountName, die Mailadresse oder den UPN ändern. Die anderen Felder wie Vorname, Nachname, Displayname sind ebenso unkritisch. Die Änderungen werden einfach auch in der Cloud nachgezogen.

Allerdings gelten dann auch hier die Einschränkungen bezüglich der Applikationen Exchange und Lync wie bisher. Bei Lync sollten Sie noch beachten:

When a User's Office 365 sign-in address (also known as the User Principal Name, UPN, or User ID) is changed, the Lync Online SIP address für the User is automatically synchronized. Previously, when a User's Office 365 sign-in address was changed, the IT administrator had to Update the User's SIP address separately to match the new Office 365 sign-in address. Otherwise, the two values would be mismatched. A mismatch between a User ID and the User's SIP address may cause confusion für the Lync Online User during sign in.
Quelle: 2537764 Considerations für Lync Online when you change an Office 365 sign-in address

Das "Verhalten" der Cloud ist nicht mit der Funktion einer selbst betriebenen Lync-Umgebung identisch. On-Prem können Sie den UPN und die SIP-Adresse natürlich getrennt verwalten. Bei Office 365 wird die SIP-Adresse an den UPN angeglichen. Sie können das recht schnell nachprüfen:

Get-CsonlineUser `
| Select Alias, DisplayName, SipAddress, WindowsEmailAddress

Das kann dann natürlich auch mal zu Problemen führen, Wenn Sie On-Prem die SIP-Adresse auf einen Wert ändert, der in der Cloud schon einem anderen Konto zugewiesen wurde.

If the Office 365 organization is using Directory Synchronization and has or previously had a Office Communications Server 2007 R2, Lync Server 2010, or Lync Server 2013 deployment On-Premises, the SIP Address can be Updated independently by populating the msRTCSIP-PrimaryUserAddress value in Active Directory. Review the following Knowledge Base article to make sure that the values in Office 365 aren't in conflict with On-Premises values: 2430520 Error in the Office 365 portal: "Value of msRTCSIP-PrimaryUserAddress or the SIP address in the ProxyAddresses field in your local Active Directory is not unique"
Quelle: 2537764 Considerations für Lync Online when you change an Office 365 sign-in address

Exchange und Mailadresse

Exchange war wohl eines der ersten Produkte, die das Active Directory sehr intensiv genutzt haben und noch nutzen. Auch heute basiert das Mailrouting nur auf den AD-Objekten die von den Exchange Servern direkt per LDAP ausgelesen werden. Exchange optimiert natürlich Anfragen, indem Antworten in einem Cache vorgehalten werden aber es findet keine Replikation in einen anderen Datentopf statt. Das stimmt nicht ganz, denn für die Anwender erstellt Exchange schon noch ein "Offline Adressbuch".

Eine Änderung des Namens führt fast zwangsläufig auch zu einer Änderung der Mailadresse. Damit sind bei Exchange drei Felder interessant:

  • Alias
    Dieser Eintrag wird gerne aus dem CN oder dem SamAccountName des Objekte gebildet. Wenn sich diese Quelle ändert, dann kann man auch den Alias mit ändern.
  • Mail
    Die primäre Mailadresse eines AD-Benutzers wird von Exchange nicht wirklich benötigt,. für die Zustellung der Mails wird ausschließlich das Feld "ProxyAddresses" heran gezogen und für den Versand davon die groß geschriebene SMTP-Adresse. Die Adresse ist aber dennoch wichtig, da z.B. Lync daraus die EWS-Domäne bezieht und sie an verschiedenen Stellen als Adressbuch dient.
  • ProxyAddresses
    Exchange hat den großen Vorteil, dass ein Benutzer mehrere SMTP-Adressen haben kann. Bei einer Umbenennung müssen Sie die neue Adresse zusätzlich addieren und primär setzen. Ob und wann Sie die alte Adresse entfernen, bleibt ihnen überlassen.

früher gab es ja noch den Exchange 2000/2003 RUS, welcher ausgehend von Empfängerrichtlinien im Hintergrund die Mailadressen gepflegt hat. Das konnte manchmal dazu führen, das sie eine Änderung des Nachnamens im AD durchgeführt haben und beim nächsten Durchlauf des RUS sich auch Mailadressen verändert haben. Seit Exchange 2007 gibt es diese Hintergrundprozess nicht mehr und jede direkte Änderung am AD-Objekt wird nicht in Exchange nachgezogen. Hierauf müssen Sie Rücksicht nehmen oder zusätzliche Schritte einplanen.

  • Displayname bei alten Mails
    Der "Name" beim Absender oder Empfänger einer Mail wird nur im Moment der "Erstellung" der Mail übernommen. Gehen Sie also nicht davon aus, dass sich der Name einer vorher erstellten Mail danach noch einmal ändert.
  • ActiveSync Partnerschaft
    Wenn der Anwender sich per UPN auf dem Mobilgerät gegen Exchange ActiveSync authentifiziert, dann muss der den geänderten UPN eintragen. Bislang bedeutet dies, dass auf dem Mobilgerät die Bestehende Partnerschaft entfernt und neu eingerichtet werden muss. Mails, die der Benutzer zwischenzeitlich "offline" geschrieben hat, werden nicht synchronisiert! Das Problem ist nicht vorhanden, wenn sicher der Anwender noch klassisch mit "Domäne\SamAccountname" anmeldet. In Office 365 ist das aber natürlihc niciht möglich.
  • OAB
    Die Änderungen werden im AD natürlich sehr schnell umgesetzt. die Outlook Clients mit Cached-Mode aber nutzen das Offline Address Buch und das muss von Exchange erst neu generiert (per Default einmal täglich um 05:00) und von den Client dann herunter geladen werden. Es kann also im Extremfall fast 48h dauern.
  • Nicknamecache
    In der lokalen NK2-Datei hinterlegt Outlook die zuletzt genutzten Empfänger. Ein Rename des Ziels ist nicht schädlich, solange die alte SMTP-Adresse weiter gültig ist bzw. der LegacyExchangeDN unverändert geblieben ist. Der Displayname bleibt aber der alte Name, bis der Anwender den Eintrag aus dem Cache löscht und mit der nächsten Mail neu addiert
  • S/Mime-Zertifikat
    Mehrere Mailadressen in einem persönlichen Zertifikat sind "unüblich". Wenn das Ziel also eine neue primäre Adresse hat, dann muss auch ein neues SMIME-Zertifikat gerechnet werden, welches dann auch bei der Gegenseite hinterlegt sein muss um verschlüsselt zu empfangen
  • Rights Management Server (RMS/DRM)
    Dieses Produkt nutzt normal die primäre Mailadresse als weltweit eindeutige Identifizierung. ändert sich die Mailadresse, kann der Benutzer keine RMS-Tokens mehr erhalten und damit ist er aus Sicht von RMS ein anderer Benutzer mit allen Folgen.

Ein Rename des DisplayName im AD ist also nicht automatisch überall präsent.

Lync und SIP-Adresse

Mit Lync sind der Displayname und die SIP-Adresse die beiden relevanten Felder. Die Änderung des Displaynamens erfolgt ja schon durch die Umbenennung des Kontos und muss nicht in Lync erneut durchgeführt werden. Die SIP-Adresse kann zumindest bei einer lokalen Lync Installation Über die PowerShell oder das Lync Control Panel (CSCP) sehr einfach geändert werden.

Set-CsUser `
   -Identity "Frank Carius" `
   -SipAddress "sip:frank.carius3@msxfaq.de"

Im Hintergrund ändert Lync zwei Felder, wie ich in meinem Trace mit GET-ADChanges schnell ermitteln konnte.

Technisch ändert sich bei der SIP-Adress-Änderung das Feld "msRTCSIP-PrimaryUserAddress" am AD-Objekt. Zusätzlich ändert sich aber auch das Feld "ProxyAdresses", in dem auch noch mal die SIP-Adresse hinterlegt ist.

Es ist wichtig, dass in den ProxyAddresses auch die SIP-Adresse vorhanden ist, da ansonsten z.B. OWA den Benutzer nicht mit Lync anmelden kann.

Ich rate immer dazu, dass die SIP-Adresse identisch zur Mailadresse ist oder die SIP-Adresse zumindest eine "Sekundäre Mailadresse" ist, denn wenn ich eine "Instant Message" nicht lese, dann landet diese als "Missed Conversation" in meinem Posteinfang mit der SIP-Adresse als "Absender"

Ansonsten wird eine Antwort auf so eine "verpasste Unterhaltung" zu einer Unzustellbarkeit führen

Die Änderung wird zwar am AD-Objekt vorgenommen aber in Lync wird diese Änderung erst wirksam, wenn der Lync User Replicator die Änderung in die SQL-Datenbanken übertragen hat. Das geht aber in der Regel innerhalb von Minuten. Bis die Änderung aber dann bei allen Anwendern "sichtbar" wird, kann es wie bei Exchange etwas dauern. Auch Lync generiert ein Offline Adressbuch, welche der Client herunter lädt. Verzögerungen von bis zu zwei Tagen können durchaus vorkommen.

Im Gegensatz zu Exchange kann ein Anwender in Lync immer nur genau eine SIP-Adresse haben eine "zweite" sekundäre Adresse ist ohne Drittprodukte nicht möglich. Durch due Umbenennung ändert sich damit die primäre Adresse. Der Benutzer ist ab sofort dann nicht mehr unter seiner alten Adresse erreichbar. Das hat Auswirkungen:

  • Buddylist-Eintrag bei internen Kontakten
    Wenn der Benutzer bei einem anderen Anwender in der Buddy-liste erscheint, dann bleibt die Namensänderung oder eine Änderung SIP-Adresse problemlos, denn Lync verwaltet intern die Benutzer mit entsprechenden IDs, die sich natürlich nicht ändern. Allerdings sehen die Anwender diese Änderung erst nach der nächsten Neuanmelden. Erst dann wird der "Displayname" entsprechend übernommen. Die internen Partner müssen also nichts an ihren Buddylisten ändern.
  • Federation Buddy
    Lync-Anwender außerhalb der Firma addieren Benutzer über die SIP-Adresse, die auch so gespeichert wird. Wenn sich nun die Adresse eines Kontakts ändern, dann sieht der Partner nicht mehr den Status, sondern nur noch "Präsenz unbekannt". Wer also seinen Namen ändert, sollte seinen Kommunikationspartnern die neue SIP-Adresse mitteilen, so dass diese ihre Buddyliste manuell aktualisieren können.
  • Meetings
    Wenn der Anwender Meetings organisiert hat, dann wird sich durch die Änderung des Userparts der SIP-Adresse auch die Konferenz URL ändern. Alle Links für Meetings werden ungültig. Der Anwender muss daher die Meetings neu planen, damit Sie wieder einen gültigen Link enthalten.
  • Anmeldung
    Der Anwender hat im Lync Client die SIP-Adresse hinterlegt. Nach der Änderung kann sich der Anwender natürlich nur noch mit der neuen SIP-Adresse anmelden. Diese muss er selbst eintragen, denn die Applikation kann dies ja nicht wissen. Das gilt insbesondere für mobilen Versionen von Lync

Wird mit der Umbenennung auch der DN geändert, dann kann die in Lync 2013 zu Problemen führen, die in den Release Notes auch dokumentiert sind:

If a User's distinguished name (also known as DN) is changed in Active Directory Domain Services, any additional changes will not be Updated in the Address Book Service (ABS). This does not affect sign-in or presence für the User, but it will prevent communication für the User if the SIP address is also changed, because searches will return an outdated SIP address.
Quelle: http://technet.microsoft.com/en-us/library/jj205120.aspx

Leider ist hier die einzige Lösung, den DN nicht zu ändern. Man sieht, dass die Replikation von Verzeichnisdiensten auch hier nicht immer fehlerfrei ist. Hoffentlich müssen Sie den DN nicht ändern. Ansonsten könnten Sie den Anwender Temporär für Lync deaktivieren, umbenennen und wieder aktivieren. Die Meetings muss er eh neu planen und seine Buddyliste können Sie natürlich vorher exportieren und danach importieren. Er verschwindet aber bei seinen Kollegen aus deren Buddylisten, da es dann wirklich ein "neuer" User ist.

Download Lync / Skype for Business Meeting Update Tool
x86 https://www.microsoft.com/en-us/download/details.aspx?id=47729
x64 https://www.microsoft.com/en-ca/download/details.aspx?id=47728 

Weitere Links