Lync Share

Jeder Lync Pool benötigt auch einen Dateishare, auf dem die Lync Server dieses Pools gemeinsame Daten ablegen. Diese Seite beschreibt den Aufbau und Inhalt dieses Share.

Ablage und Zugriff

Auch wenn es ein Datei-Share ist, so greifen nur die Lync Server darauf zu. Es ist also nicht erforderlich, dass Anwender oder Administratoren per SMB diese Freigabe nutzen. Allerdings muss diese Freigabe "verfügbar" sein, was besonders für einen Frontend Pool natürlich eine Herausforderung sein kann. Wäre doch ungeschickt, wenn mehrere Frontend Server die Verfügbarkeit hochhalten sollen aber ein Single "File Server" im Hintergrund mal nicht erreichbar ist.

Mit Lync 2010 war es bei Pools üblich, den Dateishare auf einem Fileserver Cluster bereit zu stellen. Es muss ein SMB-Share sein, aber das heißt nicht, dass es auch ein Windows Server im Hintergrund sein muss. Allerdings muss der Share natürlich die gestellten Verfügbarkeitsanforderungen erreichen oder übererfüllen.

Share auf DFS

Mit Lync 2013 kann man als Share mittlerweile einen DFS-Share nutzen, d.h. statt eines Windows Clusters als Dateiserver mit einer Shared Disk können nun mehrere Windows Server in einem Domain-DFS eine Freigabe bereitstellen.

Auf einem Lync Pool aus mehreren Servern kann man auch auf dem Frontend einen Share anlegen und per DFS replizieren lassen. Ich habe keine Quellen, die dieses Vorgehen verbieten oder als supported beschreiben. Es scheint aber fast problemlos zu funktionieren.

"Fast" nur daher, weil Sie auf dem Server einen Registrierungsschlüssel setzen müssen, damit der Server mit einem DFS-Namen auf sich selbst zu greifen kann:

Windows Registry Editor Version 5.00 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Mup\Parameters] 
"EnableDfsLoopbackTargets"=dword:00000001

Eine weitere Einstellung kann die "Loopback Protection" des Betriebssystems sein. Sie verhindern auch in einigen Fällen, dass ein Zugriff über den kurzen Servernamen möglich ist aber nicht über den FQDN.

Windows Registry Editor Version 5.00 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA] 
"DisableLoopbackCheck"=dword:00000001

Oder auch per PowerShell:

New-ItemProperty `
   -Path HKLM:\System\CurrentControlSet\Control\Lsa `
   -Name "DisableLoopbackCheck" `
   -value "1" `
   -PropertyType dword
  • 2666344 You cannot add a DFS file share as a file store in Topology Builder of Lync Server 2010
  • 896861 You receive error 401.1 when you browse a Web site that uses Integrated Authentication and is hosted on IIS 5.1 or a later version

Wir sind noch nicht ganz fertig, denn seit Windows 2008 bis 2012 RTM ist DFS AutoResume deaktiviert. Wenn Sie also einen DFS-Server mal unkontrolliert durchstarten und DFS von einem "Dirty Shutdown" ausgeht, dann bleibt er nach dem Neustart inaktiv. Wer sein Eventlog überwacht, kann es sehen

Log Name:     DFS Replication
Source:       DFSR
Event ID:     2213
Level:        Warning
Description: The DFS Replication service sto pped replication on volume C:. This occurs when a DFSR JET 
  database is not shut down cleanly and Auto Recovery is disabled. To resolve this issue, back up the files 
  in the affected replicated folders, and then use the ResumeReplication WMI method to resume replication. 
 
Additional Information: 
Volume: C: 
GUID: xxxxxxxxxxxxxxxxxxxxx
 
Recovery Steps 
1. Back up the files in all rep licated folders on the volume. Failure to do so may result in data loss
     due to unexpected conflict resolution during the recovery of the replicated folders. 
2. To resume the replication fo r this volume, use the WMI method ResumeReplication of the DfsrVolumeConfig 
     class.
  • 2663685 Changes that are not replicated to a downstream server are lost on the upstream server after an automatic recovery process occurs in a DFS Replication environment in Windows Server 2008 R2

Dieser Fall ist nicht einfach zu erkennen aber die Effekte sind z.B. dass Meetings nicht mehr zuverlässig funktionieren oder PowerPoint-Inhalte nicht mehr immer funktionieren, weil eben nicht mehr alle Server in der DFS-Farm nun immer die aktuellen Dateiinformationen haben.

Durch den folgenden Kniff können Sie DFS auf den Servern anweisen, nach einem Autorecovery die Replikation alleine wieder zu starten

Windows Registry Editor Version 5.00 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\S ervices\DFSR\Parameters] 
"StopReplicationOnAutoRecovery"=dword:00000000
# Der Wert kann auch per Powershell gesetzzt werden
Set-ItemProperty `
   -Path "HKLM:\SYSTEM\CurrentControlSet\Services\DFSR\Parameters" `
   -Name "StopReplicationOnAutoRecovery" `
   -Value 0

Allerdings hilft das nicht, wenn die Replikation schon seit über 60 Tagen nicht funktioniert hast. Auch das ist im Eventliog zu sehen

Log Name:    DFS Replication
Source:      DFSR
Event ID:    4012
Level:       Error
Description: 
The DFS Replication service sto pped replication on the folder with the following local path:
   C:\DFSRoots\l yncp1. This server has been disconnected from other partners für 92 days, which 
   is longer than the time allowed by the MaxOfflineTimeInDays parameter (60). DFS Replication 
    considers the data in this folder to be stale, and this server will not re plicate the folder 
    until this error is corrected. 
 
To resume replication of this f older, use the DFS Management snap-in to remove this server from the 
   replic ation group, and then add it back to the group. This causes the server to perform an 
   initial synchronization task, which replaces the stale data with fresh data from other members 
   of the replication group.

Allerdings hat mir das ein einem Case auch nicht geholfen. Der DFS-Server wollte einfach nicht mehr replizieren. geholfen hat dann aber letztlich ein Reset der DFS-Konfiguration auf dem Server, indem ich eine CMD-Shell als Admin gestartet habe und dann unter "System Volume Information" die XML-Datei umbenannt hatte:

Achtung: Machen Sie dies NICHT auf einem Domain Controller. Ich habe diese Holzhammermethode bislang nur auf Lync und Skype für Business Servern durchgeführt um den Pool Share zu reparieren.

stop-service DFSR
Rename-Item `
   -Path "D:\System Volume Information\DFSR\database_XXXX_XXXX_XXXX_XXXX" `
   -NewName "database_XXXX_XXXX_XXXX_XXXX_OLD"
start-service DFSR

Sie sollten aber mitnehmen, dass Sie ihre DFSR-Replikation überwachen sollten, insbesondere wenn der Skype für Business Pool darauf seine Daten ablegt.

Es gibt noch einen weiteren Key, der in der gleichen Ecke Auswirkungen hat aber von mir in Zusammenhang mit Lync noch nicht eingesetzt wurde. Vielleicht kann das aber später einmal erforderlich werden. für SharePoint ist der Eintrag wohl wichtiger.

Windows Registry Editor Version 5.00 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\MSV1_0] 
"BackConnectionHostNames"=hex(7):31,00,00,00,32,00,00,00,00,00

Dies ist ein "Multiline String" und daher HEX-codiert. In RegEdit sieht man aber, dass dieses Beispiel hier zwei Strings sind. Per Default ist der Eintrag nicht vorhanden.

Sie müssen daher den Wert erst anlegen und mit den korrekten Hostnamen füllen. Das geht auch per PowerShell:

Get-Item -path "HKLM:\System\CurrentControlSet\Control\Lsa\MSV1_0" `
   | new-Itemproperty `
       -Name "BackConnectionHostNames" `
       -Value ("site1.msxfaq.de", "alias.msxfaq.de") `
       -PropertyType "MultiString"

Share Root oder Unterverzeichnis

Bei der Freigabe eines Verzeichnisses per DFS (oder Freigabe) können Sie für Lync entweder eine eigene Freigabe einrichten oder vielleicht nur ein Verzeichnis in einer bestehenden Freigabe.

  • \\domain.com\lyncshare
  • \\domain.com\subfolder\lyncshare

Interessanterweise muss man wissen, das ein DFS-Root-Ordner nicht direkt mit einem normalen Share zu vergleichen ist. Der Lync Topologybuilder versucht beim "Publish" diesen Share einzurichten und Berechtigungen zu vergeben. Das scheint nicht möglich zu sein, wenn es ein DFS-Root-Ordner ist, wohl aber wenn es ein "normaler Share" ist. Das Problem ist aber wohl nicht da, wenn sie als Basisverzeichnis einen Unterordner nutzen. Wer die Rechte auf den Share selbst aber sowieso manuell vergibt, stößt nicht auf diese Problem.

Verzeichnisstruktur, Anlage

Die Freigabe müssen Sie von Hand einrichten und wenn die den Lync Topologybuilder nicht als Administrator starten, müssen Sie auch die Rechte auf dem Wurzelverzeichnis manuell einrichten.

Damit Lync den bereitgestellten File store nutzt, müssen Sie ihn natürlich bei der Definition des Pools mit angeben. Auch wenn der "File store" eine "Shared Component" unter Lync 2013 ist, sollte ein File Store immer nur von genau einem Pool genutzt werden. Das ist meist schon aus geografischen Überlegungen schon der Fall.

Mit dem "Publish" der Topologie legt der Deployment Wizard dann in diesem Share eine umfangreiche Verzeichnisstruktur an und hinterlegt auch entsprechende NTFS-Berechtigungen. Die vier Basisverzeichnisse sind folgende unterverzeichnisse. wobei die Nummern sich an der Lync Site und dem Pool ausrichten.

Interessanter wird es, wenn sie sich die unterverzeichnisse in den Bereichen anschauen:

Achtung: Auf viele Verzeichnisse haben Sie keine Rechte. Wer also "reinschauen" will, muss sich die Rechte erst geben, was aber die Funktion stören kann. Addieren Sie sich daher besser in die erforderlichen Lync-Gruppen, in denen auch die Lync Server sind anstatt die NTFS-Rechte anzupassen.

Alle Verzeichnisse haben gemeinsam, dass Sie in der Regel nur wenige Daten (weniger 1 GB) halten und die IO-Last moderat ist und daher keine allzu hohen Anforderungen an den bereitstellenden Server stellen. Nur die Verfügbarkeit ist zu beachten. Der Lync Server greift ganz einfach per SMB mit seinem "Computerkonto" auf diese Dateifreigabe zu.

Bereich Beschreibung

Die diesem Verzeichnis lagert der Lync Pool Informationen zur gemeinsamen Nutzung der verteilten Dienste. Ein Client greift nicht direkt darauf zu.

Der Bereich des Central Management Store wird für den Abgleich des Lync CMS genutzt. Ein Server im Pool ist der Master Replicator, der Änderungen an der XDS-Datenbank exportiert und der File Transfer Agent überträgt diese an die anderen Server in der Topologie. Sie finden hier in den Verzeichnissen daher temporär die entsprechend gepackten Dateien, die generiert, übertragen, empfangen und verarbeitet werden.

Für jeden weiteren Server gibt es quasi ein Verzeichnis mit dem FQDN des Servers, der wie ein "Postfach" genutzt wird.

Die meisten Verzeichnisse sind leer, da die Dateien nur kurzfristig vorhanden sind.

Wer die seit Lync 2013 vorhandene Rolle "Persistent Chat" installiert hat, für den wird dieses Verzeichnis vom Lync Pool genutzt.

Wie der Name schon sagt beinhaltet diese Verzeichnis die "Webservices", die jeder Lync Server den Clients als LyncWeb bereit stellt. Der Client greift aber nicht direkt auf diesen Fileshare zu sondern nutzt die Lync Webeseite:

  • ABFiles
    Hier liegen die Lync Adressbücher, die von einem Server im Pool regelmäßig erstellt und von den Clients dann per HTTP/HTTPS herunter geladen werden. Siehe auch Lync Addressbook
  • CollapContent/CollabJournal/CollabMetadata
    Hier liegen Dateien rund um die Konferenzen, z.B. Powerpoints und Umfragen
  • DeviceUpdateLogs
    Lync Telefone können ihre Updatelogs per https an den Lync Server hochladen. Die landen in diesem Verzeichnise
  • DeviceUpdatestore
    Hier speichert Lync die neue Firmware für die verschiedenen Telefone, die über den Device Update Service bereit gestellt werden
  • LMStaticData
    Ganz ganz früher wurden Meetings über "LiveMeeting" bereit gestellt. Das ist quasi eine Altlast für OCS migrierte Meetings.
  • Storage Service
    Hier speichert Lync Daten in Verbindung mit dem Exchange 2013 Backend Server (Stichwort Unified Contact Store)
  • WebAuthStore
    Ablage für früher ausgestellte Zertifikate

Der Blick in diese Verzeichniss ist manchmal ganz hilfreich, z.B. Um zu sehen, was wirklich im Adressbuch liegt. Zu einer Regelaufgabe sollten Sie sich dies aber nicht machen.

Berechtigungen

Auch wenn kein Benutzer oder Client direkt auf den Lync Share zugreift und eigentlich nur "vertrauenswürdige Server" den Share direkt nutzen, richtet der Topologie Builder für de Verzeichnisse auch entsprechende Berechtigungen ein:

Bereich  Berechtigungen

Dateifreigabe

Von Hand vergeben Sie in der Regel "Administratoren:Full,Change,Read".
Beim Publish der Topology wird daraus dann:

RTCHSUniversalServices          Modify
RTCComponentUniversalServices   Modify
RTCUniversalServerAdmins        Modify
RTCUniversalConfigReplicator    Modify

Root

NETWORK SERVICE	                Modify
RTCHSUniversalServices          Modify
RTCComponentUniversalServices   Modify
RTCUniversalServerAdmins        Modify
RTCUniversalConfigReplicator    Modify
RTC Local Administrators        Modify
RTC Local Config Replicator     Modify
RTC Server Local Group          Modify
RTC Component Local Group       Modify

1-ApplicationServer-1\AppServerFiles

NETWORK SERVICE                 Modify
RTCComponentUniversalServices   Modify
RTCUniversalServerAdmins        Modify
RTC Server Local Group          Modify
RTC Component Local Group       Modify

1-CentralMgmt-1\CMSFileStore

NETWORK SERVICE                 Modify
RTCUniversalConfigReplicator    Modify
RTC Local Config Replicator     Modify

1-WebServices-1\ABFiles

NETWORK SERVICE                 Modify
RTCHSUniversalServices          Modify
RTCComponentUniversalServices   Read, Execute
RTC Server Local Group          Modify
RTC Component Local Group       Read, Execute

1-WebServices-1\DeviceUpdateLogs

NETWORK SERVICE                 Modify
RTCComponentUniversalServices   Modify
RTCUniversalServerAdmins        Modify
RTC Server Local Group          Modify
RTC Component Local Group       Modify

1-WebServices-1\DeviceUpdatestore

NETWORK SERVICE                 Read, Execute
RTCComponentUniversalServices   Read, Execute
RTCUniversalServerAdmins        Modify
RTC Server Local Group          Modify
RTC Component Local Group       Modify

1-WebServices-1\CollabContent
1-WebServices-1\CollabJournal
1-WebServices-1\CollabMetaData
1-WebServices-1\DataConf
1-WebServices-1\LMStaticData
1-WebServices-1\StorageService
1-WebServices-1\WebAuthStore

NETWORK SERVICE                 Modify
RTCComponentUniversalServices   Modify
RTC Component Local Group       Modify

Clientzugriffe über den IIS

Wie schon beschrieben greift kein Client direkt auf diese Dateifreigabe zu. Das würde sowieso nur im internen LAN funktionieren, aber Lync muss ja auch von extern und anderen Client funktionieren und da ist HTTP/HTTPS einfach der universellere Weg. Entsprechend legt der Lync Server zwei Webseiten auf jedem Frontend Server an., die sowohl lokale Applikationen aber eben auch die Verweise auf den Lync Share beinhalten. Hier die Ansicht auf die beiden Webseiten reduziert auf die Verzeichnisse mit Verweis auf den Lync Share

Schaut man sich die Verknüpfungen per PowerShell an , dann ist sehr viel einfacher zu erkennen, welche virtuellen Verzeichnisse im IIS auf welches Verzeichnis gehen. (Allerdings nicht nach den WebSites unterschieden)

PS C:\> Get-WebVirtualDirectory | ft  -AutoSize

Name           Physical Path
----           -------------
CollabContent  \\lyncstd1.msxfaq.net\LyncShare\1-WebServices-26\CollabContent
Files          \\lyncstd1.msxfaq.net\LyncShare\1-WebServices-26\DeviceUpdatestore
Files          \\lyncstd1.msxfaq.net\LyncShare\1-WebServices-26\ABFiles
PersistentChat C:\Program Files\Microsoft Lync Server 2013\Web Components\PersistentChat\Ext
CollabContent  \\lyncstd1.msxfaq.net\LyncShare\1-WebServices-26\CollabContent
Files          \\lyncstd1.msxfaq.net\LyncShare\1-WebServices-26\DeviceUpdatestore
Files          \\lyncstd1.msxfaq.net\LyncShare\1-WebServices-26\ABFiles

Ignorieren Sie bitte das Verzeichnis "PersistentChat", welche auf den lokalen Server verweist.

Meetings im Lync Share

Neugierig war ich natürlich, wie ein Lync Meeting sich auf dem Dateishare auswirkt. Wir wissen ja schon, dass bei Lync 2013 z-B. Powerpoint-Dateien nicht mehr über Lync selbst "geteilt" werden sondern über den WAC Server. Dennoch müssen die Informationen ja irgendwo liegen.

Sowohl unter "CollabMetadata" als auch unter "CollabContent" gibt es pro Meeting ein unterverzeichnis mit der MeetingID, welche verschiedene Dateien enthält.

  • CollabMetadata
    Hier scheint Lync die Meta-Informationen für ein Meeting zu speichern aber nicht die Meetingdaten selbst. Die meisten Dateien sind nur "0 Bytes" groß oder enthalten unverständlichen Inhalt.
  • CollabContent
    Interessanter wird es hier, da auch hier ein Verzeichnis mit der Meeting-ID angelegt wird, welche durchaus ein paar mehr Daten enthält. Hier sieht man z.B. auch, wenn jemand eine PowerPoint-Datei "hoch lädt". Allerding ist die Datei nicht 1:1 vorhanden.

Wenn Sie genau hingeschaut haben, dann haben Sie auch eine Datei "Meeting.Active" gefunden. Wer also auf dem Lync Share eine Suche nach dieser Datei durchführt, findet sehr gut alle aktuell aktiven Meetings.

Pro Meeting gibt es natürlich zwei Dateien und die MeetingID ist am Ende, erlaubt aber auch noch keinen Rückschluss auf den Besprechungsorganisator. für eine erste numerische Auswertung reicht es aber schon.

Lync löscht abgelaufenen Content nach 15 Tagen (Default) alleine. Sie können diese Einstellung auch anpassen:

Set-CsConferencingConfiguration `
   -ContentGracePeriod <wert>

Kleinster Wert ist 30 Minuten (00:30:00 ). Maximalwert ist 180 Tage (180:00:00)

Share umziehen

Es ist möglich, den Share des eines Pool oder Standard-Servers auf einen anderen Server umzuziehen. Das geht aber nicht ohne "Downzeit". Die Schritte sind recht schnell erzählt

  1. Neuer Fileshare auf Backend anlegen
    Die nächsten Schritte erwarten, dass der Share (auf einem Server oder als DFS-Share) schon angelegt und berechtigt sind.
    Auf dem Share sollte "Everyone:Full" haben und in den Verzeichnissen die vier SkypeforBusiness Gruppen ebenfalls "Full"
  2. Dienste auf allen Frontends dieses Pools stoppen
    "stop-cswindowsservice". Ab hier beginnt die DownTime
  3. Topologie: Neuer Fileshare anlegen und zuweisen
    Hier wird erst der neue Share angelegt und dann auf dem Pool der neue Share ausgewählt. Der alte Share ist aber noch nicht entfernbar
  4. Topologie Publizieren
    Dann wird die Konfigurationsänderung veröffentlicht.
  5. Kontrolle des Share
    Nun sollten die Rechte auf dem Share angepasst worden sein. Bei einem DFS-Share müssen Sie die Rechte manuell setzen
  6. Replikation abwarten
    Die Änderungen der Topologie werden über die File Replication auf alle Server übertragen. Sie können den Status mit "Get-CSManagementStoreReplicationStatus" abfragen. Hier müssen alle auf "TRUE" stehen.
  7. Kopieren der Informationen auf dem Share
    Das geht am einfachsten mit Robocopy und folgender Zeile

    Robocopy \\Alterserver\AlterShare \\NeuerServer\NeuerShare /S /R:10 /W:10 /XF Meeting.Active /MT

    Je nach Größe des Pools und Anzahl der früheren Meetings mit PowerPoint-Folien kann dies einige Zeit dauern.
  8. Pool starten
    Nun können Sie auf jedem Server des Pools wieder die Dienste starten. Bei Skype for Business geht das einfach mit "Start-CSPool". Ansonsten mit "Start-CSWindowsService" auf jedem Server.
  9. Alter Share in der Topologie entfernen
    Nun können Sie erneut den Topologie Builder nutzen, um den nun obsoleten Share aus der Topologie zu entfernen und die Topologie neu zu veröffentlichen.
  10. Alter Share auf dem Quellserver entfernen
    Zuletzt sollten Sie den alten Share auf dem alten Server entfernen und die Dateien löschen.

Es gibt aber auch entsprechende Beschreibungen im Internet.

Weitere Links