Unified Contact Store

Mit Lync 2013 und Exchange 2013  (ältere Versionen funktionieren nicht) hat Microsoft die Integration von Lync 2013 und Exchange 2013 ein Stück weiter getrieben. Die als "Unified Contact Store" bezeichnete Funktion erlaubt die Ablage der Buddy-Listen im Exchange Postfach. Exchange wird also immer mehr der zentrale Speicher für alle möglichen Informationen. Ein Stück weit kann man das auch an dem Speicherort für die Bilder (Siehe Lync Photo) sehen, die mit Lync 2013 auch im Exchange Postfach gespeichert werden.

Warnung!

Microsoft hatte den Unified Contact Store in Office 365 im Jahr 2014 kurz eingeschaltet aber nach einigen Wochen wieder abgeschaltet und er ist bis heute aus.
Meine Empfehlung: Unified Contact Store nicht nutzen

Unified contact store is enabled by default. You can enable or disable Users für unified contact store globally, by site, by tenant, or by individuals or groups of individuals.
Quelle: http://technet.microsoft.com/en-us/library/jj204947.aspx

Vor der Migration einer Exchange Mailbox nach Exchange Online sollten sie den UCS abschalten, da ansonsten später die Migration des Anwenders nach SfB Online nur mit Mehraufwand oder Datenverlust möglich ist.

Ehe Sie voller Begeisterung über ein Exchange 2013 Postfach nun direkt auch ihre Lync-Richtlinie auf den Unified Contact Store umstellen, sollten Sie ein paar Dinge wissen.

  1. Upgrade einfach, Downgrade nur mit Hilfe des Admin
    Der Lync 2013 Client konvertiert alleine die Kontakte in den Outlook Store. Aber zurück geht es leider nicht mehr so einfach. Da muss der Lync Administrator mithelfen.
  2. Lync 2013 Client Only
    Zumindest in meiner Umgebung konnte ich mit dem Lync 2010 Client keine neuen Kontaktanfragen mehr in meine Buddyliste aufnehmen. Der Lync 2010 Client hat dies mit folgender Meldung quittiert
  3. Ordner in Outlook
    Die Lync Kontakte erscheinen in Outlook in einem eigene "Lync Kontakte"-Ordner unter dem normalen Kontaktorder

    Diesen Ordner gab es schon unter Lync 2010. Mit Lync 2013 ist der Ordner als "Schreibgeschützt" gekennzeichnet. Sie können die Kontakte darin weder erweitern noch ergänzen oder löschen. Das kann zu Dubletten führen, wenn Sie den Anwender sowieso schon als normalen Kontakt haben. Besonders stört dies z.B. wenn Sie mit einem Mobiltelefon (Bei mir IPhone) nach dem Kontakt suchen und ihn dann doppelt finden.
  4. Ordner in Outlook löschen
    Auch wenn die Elemente in dem Ordner "geschützt" sind, so können Sie den Ordner in Outlook dennoch löschen. Die Folge ist recht einfach: Sie haben gar keine Kontakte mehr in Lync.

    Ja, auch mir passiert sowas mal bei einer Aufräumaktion, was umgekehrt aber bedeutet, dass die Gruppen wiederum nicht im Unified Contact Store sind. Nun ja im Namen kommt auch nur der Begriff "Contact" vor.
  5. Backup !!
    Wenn Sie also vorhaben, ihre Kontakte in Exchange 2013 abzulegen. dann sollten Sie vorher vielleicht die Kontakte einfach mal sichern. Mit Lync 2013 geht das wieder etwas einfacher auch ohne. Siehe Export-CSUserData

Noch nicht abgeschreckt? Dann lesen Sie weiter. Aber ich werde das Gefühl nicht los, dass diese Funktion wieder primär für Office 365 gedacht ist um diese "Benutzerdaten" mit in das Exchange Postfach abzulegen, so wie auch die Lync Bilder dort mittlerweile landen. (Siehe Lync Photo)

Mein aktueller Eindruck:
Ich persönlich verzichte einige Zeit mal lieber auf diesen Unified Contact Store. Es gibt noch einige Ungereimtheiten und Effekte, auf die ich gerne verzichte. Vor allem sehe ich aber noch nicht den großen Vorteil einer Ablage im Postfach, wenn die Kontakte damit doppelt angelegt werden.

Können Sie ihn nutzen ?

Für den Einsatz des Unified Contact Store müssten vier Dinge erfüllt sein:

  • Lync 2013 Server oder höher
    Der Lync Server verbindet sich mit dem Exchange Server um die Kontakte zu laden und das geht erst mit der 2013 Version.
  • Exchange 2013 Postfach
    Natürlich muss es auch ein Exchange 2013 Server sein, auf dem Ihr Postfach liegt-
  • Lync 2013 Client
    Sie benötigen einen Lync 2013 Client, um den Unified Contact Store zu nutzen und die Daten dorthin zu migrieren
  • "Erlaubnis" durch den Administrator
    Erst durch die Zuweisung einer passenden CsUserServicePolicy mit dem Wert ucsAllowed=True kann der Anwender überhaupt diese Funktion nutzen.

Ist UCS schon aktiv ?

Ob der Unified Contact Store ihr Lync Client verwendet können Sie über die Anzeige der Konfigurationsinformation ermitteln. So sieht es aus, wenn UCS nicht aktiv ist.

Sie können aber nicht unterscheiden, ob der UCS nun aufgrund von Einstellungen auf ihrem Client (Policy), auf dem Lync Server oder nicht ausreichender Versionen abgeschaltet ist.

Aktivieren und Steuerung per Commandlets

Die komplette Steuerung des Unified Contact Store erfolgt ab Lync 2013 über entsprechende Richtlinien. Es gibt eine Default Richtlinie, die "global" wirkt. Gerade wer noch Lync 2010 Clients nutzt, wird nicht alle Anwender auf einen Schlag umstellen wollen, sondern mit einzelnen Pilotbenutzern starten und dann vielleicht in Gruppen die Funktion freischalten. Daher bietet es sich an, eine zweite Policy anzulegen und diese dann zuzuweisen.

New-CsUserServicesPolicy `
   -Identity "AllowUnifiedContactStore" `
   -UcsAllowed $True

Eine kurze Kontrolle der Einstellung:

PS C:\> Get-CsUserServicesPolicy

Identity   : Global 
ucsAllowed : False

Identity   : Tag:AllowUnifiedContactStore 
ucsAllowed : True

Das Zuweisen geht dann ebenfalls per PowerShell:

Grant-CsUserServicesPolicy `
   -Identity "Frank Carius" `
   -PolicyName "AllowUnifiedContactStore"

Und genauso schnell können Sie eine Liste generieren

PS C:\> Get-CsUser | ft name,UserServicesPolicy

Name UserServicesPolicy
----                                    ------------------
Frank Carius                            AllowUnifiedContactStore

Ob ein Benutzer schon umgestellt ist, können Sie mit einem "Test" einfach ermitteln

Test-CsUnifiedContactStore `
   -TargetFqdn nawlync001.netatwork.de `
   -UserSipAddress frank.carius@netatwork.de

Target Fqdn   : nawlync001.netatwork.de
Result        : Success
Latency       : 00:00:05.1733427
Error Message :
Diagnosis     :

Nebenbei bekommt Sie so auch mit, ob der Lync Server den Exchange 2013 Server und per Autodiscover das Postfach finden und erreichen kann.

Nachdem die Kontakte vom Lync SQL-Speicher in das Exchange Postfach übertragen wurden, bleibt in der Lync Datenbank eine "ReadOnly"-Version zurück. Sie kann von "Downlevel" Clients genutzt werden aber wird sehr bald nicht mehr den echten Kontakten entsprechen.

Alles zurück auf Anfang

Wenn Sie nun denken, Sie könnten einfach dem Benutzer über die Zuweisung der Policy oder die Änderung der Policy "zurückdrehen", dann werden sie über folgende Meldung stolpern: 

PS C:\> set-CsUserServicesPolicy -UcsAllowed $false
WARNING: Users who have already been migrated to the Unified Contact Store
(UCS) or who are about to be migrated to the Unified Contact Store will not be
affected when you disable Unified Contact Store; instead, those Users will
continue to have their contacts stored in the Unified Contact Store. To move
these Users' contacts from the Unified Contact Store to Lync Server you must
run the Invoke-CsUcsRollback cmdlet after disabling Unified Contact Store

So einfach geht es also nicht und man muss den Benutzer schon "zurückdrehen".

Eventuell ist es eine gute Idee, die Kontaktdaten erst mal zu sichern:
Export-CSUserData

Invoke-CsUcsRollback -Identity frank.carius@netatwork.de

Hier sehen Sie den RollBack mit meinem Benutzer, der beim ersten Mal funktioniert und beim zweiten Aufruf natürlich nicht mehr funktionieren kann, da ich ja keinen Unified Contact Store mehr habe.

Der Client bemerkt dies natürlich auch. Zumindest ein Lync 2010 Client belästigt den Anwender mit einer kleinen Warnung:

Auf dem parallel gestarteten Lync 2013-Client konnte ich keine Unterbrechung erkennen.

Hinweis: Der Ordner "Lync-Kontakte" im Outlook Postfach wird durch diese Zurückstellung nicht gelöscht.

Outlook und Lync Kontakte - mit MFCMAPI

Wann immer ein Programm "etwas" in Outlook und Exchange macht, schau mich mir die Interna per MFCMAPI oder ExFolders an. hier sieht man schön, dass der Ordner "Lync-Kontakte" es unter den Kontaktorder im Postfach geschafft hat und der Versuch ein Element davon zu löschen, wird zumindest in Outlook mit einem Fehler quittiert.

 

Schaut man sich die Berechtigungen an, so ist der Ordner eigentlich "normal" berechtigt

Und auch ein Blick mit MFCMapi zeigt, dass der Ordner nicht "READONLY" ist.

Per Outlook WebApp können problemlos die Lync Kontakte auch löschen Per MFCMAPI funktioniert es natürlich ebenfalls. Es handelt sich also keineswegs um einen "echten" Schreibschutz sondern rein um eine Softwarekomponente, die in Outlook diesen weichen Schutz umsetzt.

Ich hatte also per Outlook WebApp einen Kontakt gelöscht der dann flugs auch nicht mehr in Lync als Kontakt angeboten wurde. Ein "Zurückspielen" aus dem Papierkorb war aber nicht erfolgreich:

Überlegen Sie also zweimal, ob Sie in diesem Ordner überhaupt etwas anfangen.

Wenn ich schon mal bei MFCMAPI war, dann ist mir doch direkt noch ein Ordner aufgefallen. Nach allen Recherchen scheint der noch durch den alten OCS 2007R2 Communicator angelegt angelegt worden zu sein. Komisch nur, dass der Ordner angeblich am 26.10.2010 angelegt wurde.

 

Ich kann mir durchaus vorstellen, dass in dem ein oder anderen Postfach durchaus noch weitere versteckte Ordner liegen.

Der Link zwischen Lync und Exchange

Sobald ein Anwender mit dem Lync 2013 "Rich"-Client (Also Windows) auf einem Lync 2013 Server arbeitet und sein Postfach sich auf einem Exchange 2013 Server befindet und die Nutzung des universal Contact Store nicht über eine Lync Richtlinie verboten wurde, werden die Kontakte des Benutzers aus Lync nach Exchange migriert.

  1. Der Lync Clients ist der Initiator.
    Der Lync 2013 Communicator erkennt, wenn das Postfach auf Exchange 2013 liegt und informiert den Lync Server.
  2. Der Lync Server migriert
    Der Server prüft, ob er das Postfach auf dem Exchange Server per Autodiscover/EWS erreichen kann und migriert dann die bislang lokal gehaltenen Daten in das Postfach
  3. Lync Server informiert Client
    Nach Abschluss der Migration informiert der Lync Server den Client. Ab dem Moment greift der Client nur noch über Exchange auf seine Buddyliste zu.
  4. Backend Link
    Der Lync Server bezieht aber weiterhin Update der Buddyliste vom Exchange Server, damit er diese z.B. alten Clients oder Lync Telefonen bereitstellen kann.

Bei Gelegenheit sollte ich die SIP-Traces und EWS-Zugriffe noch mal aufzeichnen. Bei meiner ersten Umstellung habe ich das einfach verpasst. Der UCS ist ja per Default eingeschaltet und bei der Migration meines Exchange Postfachs hatte ich etwas anderes meine Aufmerksamkeit.

Natürlich könnte ein Lync Client direkt auf den Exchange Server zugreifen, aber was machen "einfachere" Clients wie z.B. UCWA, UCMA oder ein LyncPhone. Ohne Exchange 2013 und früher war es ja auch schon immer so, dass die Buddyliste per SIP-Provisioning an den Client übertragen wurde und das wurde auch beim Unified Contact Store nicht geändert. Daher spricht nun der Lync Server direkt mit dem Exchange Server.

Wichtig:
Der Lync 2013 Server ermittelt den Exchange Server über "Autodiscover" und nutzt dann die "ExternalURL" des Exchange Server.

Das kann man auch schön sehen, wenn ich eine solche Verbindung aktiv anstoße:

Test-CsUnifiedContactStore `
   -TargetFqdn lync2013.netatwork.de `
   -UserSipAddress User1@msxfaq.de -Verbose

Bei Fehlern können Sie noch ein Debug-CSUnifiedContactStore nutzen

Rechte?

Moment könnten Sie da sagen. Da kommt ein Lync Server daher und greift einfach in das Postfach aller Benutzer zu? Im IISLog kann der Zugriff des Lync Servers auf Exchange gefunden werden. Denken Sie daran, dass bei Exchange 2013 die Clients, und damit auch der Lync Server den CAS-Proxy auf dem Frontend anspricht:

POST /ews/exchange.asmx &cafeReqId=<GUID>; 443 UserSID 192.168.100.100 LYNC/5.0.8308.420/Storage - 200 0 0 15
POST /ews/exchange.asmx &cafeReqId=<GUID>; 443 UserSID 192.168.100.100 LYNC/5.0.8308.420/Storage - 200 0 0 328

Sie können diese Anfragen also recht einfach anhand des UserAgent "LYNC/5.0.8308.420/Storage" erkennen. Natürlich sind die Verbindungen per SSL verschlüsselt aber mit IIS Failed Request Tracing kann man doch einfach die Requests und Antworten analysieren ohne mühsam SSL zu decodieren oder abschalten zu müssen.

Sehr interessant ist hierbei der "Username", der das Computerkonto des Exchange Servers ist. Ich habe leider keinen Zugriff auf den Sourcecode aber ich vermute einfach mal, dass Exchange ähnlich wie bei Unified Messaging nach den "Lync Servern" sucht und diesen entsprechende Rechte einräumt.
Nein, ich habe nun noch nicht probiert, welche Rechte ein Programm auf dem Lync Server sonst noch auf Exchange Postfächer hat, wenn es als "Local System" des Lync Servers ausgeführt ist.

Wer mag kann natürlich auch die XML-Anfragen der WebServices etwas genauer untersuchen. Hier der Request von Lync an Exchange:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
        xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <soap:Header>
    <RequestServerVersion Version="Exchange2013" 
        xmlns="http://schemas.microsoft.com/exchange/services/2006/types" />
  </soap:Header>
  <soap:Body>
    <GetImItemList xmlns="http://schemas.microsoft.com/exchange/services/2006/messages">
      <ExtendedProperties>
        <ExtendedProperty 
              DistinguishedPropertySetId="PublicStrings" 
              PropertyName="TelURI" 
              PropertyType="String" 
              xmlns="http://schemas.microsoft.com/exchange/services/2006/types" />
        <ExtendedProperty 
              DistinguishedPropertySetId="Address" 
              PropertyName="ImContactSipUriAddress" 
              PropertyType="String" 
              xmlns="http://schemas.microsoft.com/exchange/services/2006/types" />
        </ExtendedProperties>
      </GetImItemList>
    </soap:Body>
</soap:Envelope>"

Und die Antwort auszugsweise.

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header>
    <h:ServerVersionInfo MajorVersion="15" MinorVersion="0" MajorBuildNumber="712"
        MinorBuildNumber="22" Version="V2_3" 
        xmlns:h="http://schemas.microsoft.com/exchange/services/2006/types"
        xmlns="http://schemas.microsoft.com/exchange/services/2006/types" 
        xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
  </s:Header>
  <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
          xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <GetImItemListResponse ResponseClass="Success" 
        xmlns="http://schemas.microsoft.com/exchange/services/2006/messages">
      <ResponseCode>NoError</ResponseCode>
        <ImItemList>
          <Groups xmlns="http://schemas.microsoft.com/exchange/services/2006/types">
          <ImGroup>
            <DisplayName>Favorites</DisplayName>
            <GroupType>IPM.DistList.MOC.Favorites</GroupType>
            <ExchangeStoreId Id="xxxiRAAAEdAxzAAA=" ChangeKey="EgAAAA=="/>
            <MemberCorrelationKey>
              <ItemId Id="xxxc5tmxX2AABlFJEjAAA=" ChangeKey="EQAAAA=="/>
            </MemberCorrelationKey>
          </ImGroup>
          <ImGroup>
            <DisplayName>Tagged</DisplayName>
            <GroupType>IPM.DistList.MOC.Tagged</GroupType>
            <ExchangeStoreId Id="xxxiRAAAEdAx0AAA=" ChangeKey="EgAAAA=="/>
          </ImGroup>
          <ImGroup>
            <DisplayName>Other Contacts</DisplayName>
            <GroupType>IPM.DistList.MOC.OtherContacts</GroupType>
            <ExchangeStoreId Id="xxxiRAAAEdAx1AAA=" ChangeKey="EgAAAA=="/>
            <MemberCorrelationKey>
              <ItemId Id="xxxc5tmxX2AABlFJEkAAA=" ChangeKey="EQAAAA=="/>
              <ItemId Id="xxxc5tmxX2AABlFJDYAAA=" ChangeKey="EQAAAA=="/>
              <ItemId Id="xxxc5tmxX2AABlFJCiAAA=" ChangeKey="EQAAAA=="/>
            </MemberCorrelationKey>
          </ImGroup>
....

Hier sieht man schon die Namen der Gruppen mit den Verweisen auf Items, die anhand der Exchange StoreID und ItemID referenziert werden

Lync 2013 CU1 ohne Exchange 2013

Kontrollieren Sie regelmäßig ihr Lync Eventlog? Wenn ja, dann sollte ihnen nach der Installation des Lync 2013CU1 aufgefallen sein, dass sehr viele Events 32054 erscheinen, zumindest solange ihre Anwender noch nicht auf Exchange 2013 Server migriert wurden.

Ein Blick in das Eventlog offenbart, dass der Lync Server hier sich beschwert, dass es die "falsche" Exchange Version ist und er keine Rechte darauf hat. Vielleicht haben Sie im Eventlog ihres Lync 2013 Servers schon folgende (hier etwas gekürzte) Meldungen gesehen.

Anscheinend hat es Microsoft mit dem Feb 2015 Update geschafft, diese Fehlermeldung abzuschalten, wenn der Lync Benutzer nicht auf einem Exchange 2013 Postfach liegt.

Log Name:      Lync Server
Source:        LS Storage Service
Event ID:      32054
Task Category: (4006)
Level:         Error
Keywords:      Classic User:          N/A
Description:
Storage Service had an EWS Autodiscovery failure. UnsupportedStoreException: code=ErrorIncorrectExchangeServerVersion, reason=GetUserSettings failed,
      smtpAddress=frank.carius@netatwork.de, 
      Autodiscover uri=https://autodiscover.netatwork.de/autodiscover/autodiscover.svc,
      Autodiscover WebProxy=<NULL> ---> Microsoft.Exchange.WebServices.Data.ServiceRequestException: 
      The request failed. The remote server returned an error: (401) unauthorized. ---> 
   at System.Net.HttpWebRequest.GetResponse()
   at Microsoft.Exchange.WebServices.Data.EwsHttpWebRequest.Microsoft.Exchange.WebServices.Data.
          IEwsHttpWebRequest.GetResponse()
   at Microsoft.Exchange.WebServices.Autodiscover.AutodiscoverRequest.InternalExecute()
   --- End of inner exception stack trace ---

Cause: Autodiscovery uri was not correctly configured or unreachable, that there is a problem with 
the Proxy, or other errors.
Resolution:
Check event details.  Check autodiscovery uri is properly configured and reachable. Check that 
proxy setting is properly configured and reachable.  Validate Lync to Exchange Autodiscovery 
configuration by following the trouble shooting guide. If problem persists, notify your 
organization's support team with the event details.

Bis Microsoft ein Update bringt, werden Sie mit der Fehlermeldung Leben müssen, denn es hilft nichts, die Nutzung von UCS in der globalen "Default"-Policy abzuschalten.

3rd Party Tools und EWS

Wenn Skype for Business Server und Lync 2013 Server die Buddy-Listen der Anwender nun in das Exchange Postfach auslagern, dann bietet sich damit eine geniale Möglichkeit an, diese Listen für die Benutzer zu verwalten. Eine direkte Verwaltung der Buddylisten in der Skype for Business Datenbank ist aktuell (Juli 2016) nur On-Premises über die Commandlets "Export-CSUserData" und "Import-CSUserData" oder über UCMA möglich. Eine direkte Änderung in den SQL-Datenbanken ist nicht erlaubt. Aber beide Wege sind in Skype for Business Online nicht möglich und bis irgendwann einmal entsprechende Commandlets oder ein Nutzung von UCWA mit Impersonation möglich ist, dauert es noch. Eventuell ist eine Impersonation beim Einsatz von ADFS möglich. Das habe ich aber noch nicht weiter untersucht

Impersonation ist aber beim Zugriff auf Exchange mittels EWS schon heute sowohl On-Prem als auch in der Cloud problemlos möglich. Über den Weg können Sie per PowerShell oder mit Drittprogrammen auf das Exchange Postfach zugreifen und damit auch die Skype for Business Kontakte bearbeiten. Sie müssen nur die Inhalte "richtig" pflegen, damit die Skype for Business Server damit umgehen können. Es gibt einige Programme, die dies schon kommerziell bereit stellen.

Bislang hatte ich noch keine Gelegenheit per PowerShell eine eigene Lösung zu entwickeln. Wenn ich die Zeit oder im Rahmen eines Auftrags dazu komme, werde ich die Seite entsprechend erweitern.

Bis dahin verlinke ich auf kommerzielle Tools oder andere Skripte. Der Umweg einer zentralen Verwaltung macht gerade dann Sinn, wenn Sie als Firma bestimmte Gruppen und Kontakte "vorladen" wollen oder z.B. durch eine Änderung der Mailadresse auch die SIP-Adresse angepasst werden soll. Über den Umweg können Sie auch mehr Gruppen verwalten, wen Sie in Office 365 an das Limit von 10 dynamischen Gruppen im Skype for Business Client stoßen

Verzeichnis DataExport

Die Lync/Skype-Server schreibt natürlich nicht direkt in das Exchange Postfach, sondern auch das erfolgt über Queues und Verzeichnisse.

Die folgenden Aussagen sind nicht verifiziert und daher mit Vorsicht zu betrachten

Bei einem Kunden ist aufgefallen, dass in einem Skype for Business 2015 Pool auf allen Frontend-Servern die Festplatten voll laufen. Nach kurzer Suche haben  wir sehr viele Dateien in folgendem Verzeichnis gefunden:

Microsoft Lync Server 2013\Share\1-WebServices-1\StorageService\DataExport\

Analog dazu haben wir auch in der LYNCLOCAL-SQL-Instanz eine hohe Datenmenge in der dbo.ItemQueue gefunden.

Da gibt es wohl Abhängigkeiten und wenn ich andere Treffer in Suchmaschinen richtig interpretiere, dann hat dies alles mit dem "Export zu Exchange 2013" zu tun. Meines Wissen kann das eigentlich nur der UCS sein, der aber z.B. nicht zu Exchange schreiben kann.

The StorageService folder is new in Lync 2013 and is used by the Lync Storage Service (LSS) to store data that it uses with Exchange Server 2013 for a back-end data store.
Quelle: Lync 2013 DataExport folder growing https://social.technet.microsoft.com/forums/lync/en-US/25325262-14a8-4395-aea8-5363ab06f0c2/lync-2013-dataexport-folder-growing

Weitere Links