Unified Contact Store

Hallo zusammen,

keine kennt ihn und doch nutzen ihn alle, die einmal Skype onpremise installiert haben, die Rede ist vom Unified Contact Store (UCS). Dieser ist per Default aktiviert und ist für die Speicherung der s.g. Buddy List in Skype verantwortlich. By Default wird der UCS in Exchange gespeichert.

Der UCS ist für Cloud Umgebungen nicht mehr supported, siehe auch https://docs.microsoft.com/en-us/lyncserver/lync-server-2013-supported-hybrid-configurations.

Dieser Artikel beschreibt den Weg den UCS loszuwerden um keine Probleme bei einer Cloud Migration zu erhalten.

Vorarbeiten:
Im Vorfeld muss eine Policy erstellt werden, die zukünftig den UCS deaktiviert. Dies ist aber nur die Hälfte der Arbeit, denn es reicht nicht aus nur die Policy zu erstellen und diese den Benutzer zuzuweisen. Im folgenden Skype PowerShell Befehl wird eine Policy erstellt, die den UCS "deaktiviert":

New-CsUserServicesPolicy –Identity DisallowUnifiedContactStore–UcsAllowed $False


Durchführung:
Mit dem folgenden Befehl werden zuerst sämtliche onprem Exchange Postfächer in eine CSV Datei gespeichert:
Get-Mailbox -ResultSize Unlimited | select *Primarysmtp* | export-csv -Path C:\temp\exports.csv

Der nachfolgende Befehl deaktiviert dann den UCS für alle Benutzer, die in der CSV Datei hinterlegt sind. Die Variable %Poolname% muss durch den entsprechenden Skype Poolnamen ersetzt werden. Sicherheitshalber wird die aktuelle Buddy List vorab exportiert, denn man weiß ja nie...

$Users = import-csv "C:\temp\exports.csv" foreach ($User in $Users) {Export-CsUserData -userFilter $User.PrimarySmtpAddress -FileName "C:\Temp\SFB\$User.PrimarySmtpAddress.zip" -PoolFqdn %poolname%Grant-CsUserServicesPolicy -PolicyName DisallowUnifiedContactStore -Identity $User.PrimarySmtpAddressInvoke-CsUcsRollback –Identity $User.PrimarySmtpAddress -Confirm:$False

Der UCS ist somit deaktiviert und die Skype Kontakte werden fortan in der SQL Sykpe Datenbank direkt gespeichert.

Kontrolle:
Der Replikation sollte man im Anschluss ein wenig Zeit lassen und nachdem sich der Benutzer am Skype neu angemeldet hat kann über die Verbindungseinstellungen geprüft werden, dass UCS nun deaktiviert ist

Ergebnis:
Die Postfächer sind nun optimal vorbereitet um diese und andere Services wie Skype etc. in die Online Welt zu verschieben.

In einem späteren Artikel befasse ich mich mit der Thematik sofern das Postfach bereits in der Cloud liegt, Skype jedoch noch onprem liegt. Dies ist keine unübliche Situation, denn meistens werden Technologien nicht gleichzeitig, sondern nacheinander in die Cloud verschoben. Wie auch immer, sollte das Postfach schon in O365 liegen, wir die folgende Meldung beim Deaktivieren des UCS dargestellt:

Invoke-CsUcsRollback -Identity John.Doe@contoso.com -Confirm:$False
Invoke-CsUcsRollback : Failed to roll back the user from unified contact store mode as the contact list export from
Exchange failed. Contact list export from Exchange failed with reason code:
At line:1 char:1
+ Invoke-CsUcsRollback -Identity John.Doe@contoso.com -Confirm:$ ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (John.Doe@contoso.com:String) [Invoke-CsUcsRollback], Exception
    + FullyQualifiedErrorId : RollbackException,Microsoft.Rtc.Management.AD.Cmdlets.RollbackUcsCmdlet


Viele Grüße, Jens
-->

Kurz notiert: Export aller X500 Attribute (legacyexchangedn)

Hallo zusammen,

im Rahmen einer PST Exchange Migration - egal wohin, sind die X500 Adressen eine wichtige Information der Zielpostfächer. Ohne die X500 Adressen im Zielsystem können die Benutzer keine "alten", migrierten Emails beantworten, da Outlook die X500 Adresse nicht mehr auflösen kann. Nachfolgend ein kleines Script welches die X500 Adressen zur weiteren Verwendung exportiert:

Get-ADUser -SearchBase “OU=DE,OU=EU,DC=contoso,DC=local” -Filter * -Properties SamAccountName,legacyExchangeDN,mail | Select-Object SamAccountName,legacyExchangeDN,mail | Export-CSV C:\UserExport.csv -NoTypeInformation

Viele Grüße, Jens

Office/Outlook Versionen und die Nutzung mit O365/M365 MFA/SSO

Hallo zusammen,

um Zuge einer O365 / Exchange Online Migration ist es durchaus wichtig einen Blick auf die aktuell genutzten Outlook / Office Versionen zu werfen. Denn nicht alle Outlook Versionen sind kompatibel mit O365, siehe auch https://docs.microsoft.com/en-us/exchange/troubleshoot/accessing-email-data/rpc-over-http-end-of-support.

Anbei ein Script welches auf dem lokalen Exchange onprem Server die Logs auswertet und eine ziemlich gute CSV Datei mit den Ergebnissen bereitstellt, siehe hier, https://gallery.technet.microsoft.com/office/Determine-all-outlook-d43bd71f


Anbei die Übersicht der Versions-Nummern und der jeweiligen Outlook Versionen:

Version Name	Version Number
Outlook 97	8.0
Outlook 98	8.5
Outlook 2000	9.0
Outlook XP/2002	10.0
Outlook 2003	11.0
Outlook 2007	12.0
Outlook 2010	14.0
Outlook 2013	15.0
Outlook 2016	16.0
Outlook 2019	16.0
Office 365	16.0

Outlook 2010 funktioniert zwar mit O365 jedoch sind hier einige Einschränkungen zu beachten:

• keine Multi Faktor Authentifizierung möglich, da diese Modern Authentication erfordert. Und Modern Authentication funktioniert nicht für Outlook 2010. 
• kein Single Sign On. Auch wieder wieder das gleiche Spiel, Seamless Single Sign on benötigt Modern Authentication, siehe auch https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso-quick-start

Viele Grüße, Jens

mobile Nutzung der Response Groups in Skype for Business in deren Grenzen

Hallo zusammen,

mit der aktuellen Skype for Business 2015 onprem Version 6.0.9319.534 (CU7) ist es natürlich möglich mit Response Groups zu arbeiten. In einer mobilen Welt arbeiten immer mehr Benutzer nicht nur mit einem Skype Client an einem PC sondern auch mit einem Skype Client an einem mobilen Endgerät und genau hier gibt es derzeit noch Grenzen:

• Ein Benutzer in z.B. Mitglied in der Response Group IT und hat neben seinem Arbeitsplatz PC noch den Skype Client auf seinem Android Smartphone installiert. Ruft nun ein externer Anrufer auf der Rufnummer der Response Group an, wird der Anruf auf dem Android Smartphone signalisiert und der Benutzer kann das Gespräch mobil entgegennehmen und auch das Gespräch führen
  
• Ein anderer Benutzer ist ebenfalls Mitglied der Response Group IT und hat neben seinem Arbeitsplatz PC noch den Skype Client auf seinem IOS Gerät installiert. Ruft nun ein externer Anrufer auf der Rufnummer der Response Group an, wird der Anruf zwar auf dem IOS Gerät signalisiert aber der Anruf kommt nicht zustande sobald der Anruf mobil entgegengenommen wird.

Ob das Problem mit IOS Geräten mit dem im Januar 2019 veröffentlichte CU8 behoben worden ist, wird sich zeigen sobald die ersten Updates durchgeführt und getestet sind.

Viele Grüße, Jens

Handhabung Skype for Business Client Probleme

Hallo zusammen,

immer wieder passiert es, dass einzelne Benutzer sich nicht (mehr) an ihrem Skype for Business Client anmelden können oder andere beliebige Fehler beim Arbeiten in Skype for Business haben (hierzu zählen auch ein fehlerhaftes Screensharing oder das Problem beim Einwählen in eine Konferenz). Ich habe nachfolgend die wichtigsten Erkenntnisse und Schritte zusammengefasst die in den letzten Jahren recht häufig das Endgeräte wieder dazu gebracht haben mit dem Skype for Business Server zu kommunizieren:

Aktueller Skype for Business Client

Klingt banal ist es auch. Eines der Wichtigsten Themen bei dem ein oder anderen Client Problem ist die Tatsache, dass der Skype for Business Client grundsätzlich auf der aktuellen Version sein sollte. Benutzer welche die O365 C2R (Click to Run) Version nutzen, haben weniger das Problem, da diese Installation perse auf dem aktuellen Stand via Windows Updates gehalten wird.

Es gibt dennoch nach wie vor eine Skype for Business Version 15.x und eine 16.x.
Die Version 15.x ist deutlich veraltet und sollte in diesem Fall schnellstmöglich auf die aktuelle Version aktualisiert werden. Der Basic Client (Ohne Enterprise Voice, Festnetztelefonie) kann unter dem folgenden Link heruntergeladen werden, https://www.microsoft.com/de-de/download/details.aspx?id=49440

Regelmäßiges Neustarten der eingesetzten Hardware

Hört sich auch banal und absolut normal an, ist aber auch nicht zu vernachlässigen. Die meisten Benutzer dürften mit ihrem Laptop mobil unterwegs sind und auch immer wieder sich per VPN in ein Firmennetz einwählen. Somit werden immer wieder lokal Routen und Netzwerke hinzugefügt oder getrennt und verschiedene Wifi Hotspots werden betreten und wieder verlassen.
Die Erfahrung Zeit, dass ein Reboot gut tut, je regelmäßiger desto besser.


Löschen des Skype for Business Profils

Wenn alles nicht hilft, müssen "größere" Maßnahmen ergriffen werden um Probleme zu lösen, hierzu zählt auch das Löschen des Skype Profils ähnlich zu sehen wir das Löschen eines Outlook Profils.

• Das Skype Profil wir im lokalen AppData Verzeichnis gespeichert, am besten gelangt ihr über "%LocalAppData%" über den Windows Explorer in das Verzeichnis 

          

• Im Anschluss in das entsprechende Benutzerverzeichnis wechseln, in meinem Fall lautet dies "jens.kleinhans" bzw. meine Skype for Business Version ist die 16.0 (sofern ältere Clients installiert sind, kann an dieser Stelle auch 15.0 der richtige Absprungspunkt sein, "%LOCALAPPDATA%\Microsoft\Office\16.0\Lync\"
• Es werden nun alle Skype for Business Profile angezeigt und das zu löschende Profil kann dann über den Windows Explorer gelöscht werden

Das Löschen des Skype for Business Profiles löscht lediglich das Profil, aber keine Inhalte, d.h. die Adresslisten sind nach der nächsten Neuanmeldung alle wieder vorhanden. Es ist zwingend notwendig, dass die Applikation Skype zum Zeitpunkt des Löschens geschlossen sein muss. 

Löschen des lokalen Zertifikats

Sobald sich ein Benutzer an Skype for Business angemeldet hat, wird ein lokales und benutzerspezifisches Zertifikat in den Benutzer Zertifikatsspeicher abgelegt. Dies ist auch der Grund warum sich der SfB Client bei jedem Neustart automatisch - ohne Hinterlegen von Benutzername/Passwort - anmeldet. Dieses Zertifikat kann ebenfalls problemlos gelöscht werden, sobald der Benutzer sich danach erneut - dieses Mal mit SIP Adresse / Passwort - anmeldet wird ein neues Zertifikat erstellt.

• "Start" - "Ausführen" - "MMC" eintragen und return drücken
• "Datei" - "snap-in Hinzufügen oder Entfernen"
• "Zertifikate" bzw. "Certificate" (sofern eine englisches Betriebssystem installiert ist)
• Im nächsten Schritt auf "Zertifikate - aktueller Benutzer" - "Eigene Zertifikate" - "Zertifikate" wechseln und das entsprechende Zertifikat löschen

           

Löschen der gespeicherte Anmeldeinformationen

Mit der Anmeldeinformationsverwaltung können Sie die gespeicherten Anmeldeinformationen für die Anmeldung auf Websites, verbundene Anwendungen und Netzwerke anzeigen und löschen.

• Gebe zum Öffnen der Anmeldeinformationsverwaltung in das Suchfeld auf der Taskleiste Anmeldeinformationsverwaltung ein und wähle Anmeldeinformationsverwaltung in der Systemsteuerung aus.
• Wähle Webanmeldeinformationen oder Windows-Anmeldeinformationen aus, um auf die Anmeldeinformationen, die du verwalten möchten, zuzugreifen und lösche diese ggf.

          

Alternativ kann dies auch über die PowerShell mit dem nachfolgenden DOS-Befehl gelöscht werden "cmdkey /list | ForEach-Object{if($_ -like "*Target:*"){cmdkey /del:($_ -replace " ","" -replace "Target:","")}}" - das DOS Fenster mit administrativen Rechten öffnen

Tracing Ordner analysieren

Die Skype Software dokumentiert Client-seitig die Calls dahingehend dass wertvolle Troubleshooting Informationen aus dem s.g. Tracing Ordner zu gewinnen sind. Der Tracing Ordner liegt unter %LOCALAPPDATA%\Microsoft\Office\16.0\Lync\tracing und kann durchaus groß werden. Daher ist es ratsam diesen mit einem ZIP Programm zu verkleinern, sofern dieser anderen Personen zur Verfügung gestellt werden sollte.


Viele Grüße, Jens

Doppelte Postfächer in O365 und Exchange onprem

Hallo zusammen,

es ist tatsächlich möglich in einer Exchange Hybrid Umgebung einem Benutzer zwei Postfächer zuzuweisen. Ich lasse die Umstände bewusst hier außen vor, der Benutzer hatte jedenfalls externe Emails auf sein onprem Postfach erhalten (die MX Records) zeigen auf die onprem Umgebung und interne Emails von O365 Kollegen kamen im O365 Postfach an. Das ist natürlich maximal komplex, wenn man sich schon am Anfang Gedanken macht wie der Content wieder zusammengeführt wird - hierzu aber zu einem späteren Zeitpunkt mehr.

Nachfolgend habe ich beschrieben welche Schritte durchgeführt wurden um aus zwei Postfächer wieder ein harmonisiertes O365 Postfach zu machen.

1. Erstellung einer PST Sicherung beider Postfächer.
   Onprem ist das kein Problem und habe ich über den folgenden Befehl realisiert
   In O365 gibt es das CMDlet new-mailboxexportreqeust, so dass ich das Postfach auf eine andere Art exportiert habe (hierzu auch später mehr).
   Weiterhin erstelle ich mir einen Screenshot in welchem ersichtlich ist welche O365 Lizenzen dem Benutzer zugewiesen sind. Diese Info benötigen wir zu einem späteren Zeitpunkt erneut.
   
2. Im O365 wird der Exchange Online (Teil-) Plan entfernt. Ab jetzt erhält das Postfach somit auch keine internen Emails von O365, d.h. ab jetzt kommt auch der Zeitfaktor ins Spiel. Des Postfach existiert jetzt nur noch auf Exchange onprem.
   
   
   
3. Verschieben des Benutzerkonto im Active Directory in eine OU welche nicht im Sync Scope des AAD-Connect ist. Dies hat den Effekt, dass der Benutzer beim nächsten AAD-Connect Sync automatisch gelöscht wird. Die Replikation abwarten und im Azure AD kontrollieren ob der Benutzer tatsächlich nicht mehr vorhanden ist.
   
   
4. Der Benutzer im Azure AD noch in den gelöschten Elementen löschen
   
5. Im Anschluss verschieben wir den Benutzer im lokalen AD wieder in eine OU welche im AAD Connect Sync definiert ist und nochmals Abwarten bis der Sync abgeschlossen ist und der Benutzer im Azure AD wieder vorhanden ist.
   
6. Das Postfach wird nun wieder nach Exchange Online verschoben (sofern gewünscht, in meinem Fall werden alle Postfächer in Exchange Online betrieben)
   
7. Sofern das Postfach über die ECP von O365 verschoben werden sollte, wird "nur" der Status synchronisiert im ECP erscheinen.
   
   
   
   Das Postfach ist somit noch nicht final nach Exchange online migriert. Um die Migration abzuschließen, habe ich mich via Remote PowerShell an O365 angemeldet und folgenden Befehl abgesetzt um die Migration abzuschließen, complete-migrationbatch.
   
8. Das Postfach ist nun wieder nach O365 verschoben, was sicherheitshalber im O365 ECP nach überprüft werden sollte. Da der Benutzer im Azure AD komplett neu angelegt wurde, fehlen sämtliche Produktlizenzen, diese sind nun wieder über das Admin Center hinzuzufügen.
   
9. Da das onprem Postfach nun wieder in O365 vorhanden ist, muss zum Abschluss noch der Postfachinhalt des zu Beginn gelöschten O365 Postfach in das Postfach importiert werden. Diese Tätigkeit habe ich in diesem Fall direkt über Outlook und einen PST Import durchgeführt.
   
10. Zum Schluss jeweils eine externe und interne Email dem Postfach zustellen um sicherzustellen dass das Email Routing sauber funktioniert.

In diesem Sinne viel Spass beim Wiederherstellen, solltet ihr mal in die Lage kommen dies durchführen zu müssen.

Viele Grüße, Jens

Anpassen internes O365 Email Routing

Hallo zusammen,

ich hatte vor einigen Tagen die Anforderung, dass sämtliche internen O365 Emails nicht direkt "intern" in O365 direkt zugestellt werden sollen, sondern zuerst zu einem externen Dienstleister gesendet werden sollen. Erst im Anschluss soll die Email in O365 zugestellt werden.

Der externe Dienstleister ist in diesem Fall die Hornetsecurity, welche in diesem Fall für das Verschlüsseln/Signieren, Anhängen der Email Signatur und Archivieren der Emails zuständig ist. So dass somit jede Email, also jede interne und jede externe Email entsprechend "behandelt" wird muss diese zweifelsohne auch über die Infrastruktur der Hornetsecurity geroutet werden.

In meinem Test-Szenario arbeite ich mit der Test-Domäne drmaxx.com.
Für diese Domäne habe ich bereits in O365 einen Tenant angelegt, die öffentlichen MX Records zeigen in diesem Fall auf die Hornetsecurity Cloud Plattform.

Zuerst muss sichergestellt werden, dass alle Emails die zur Hornetsecurity gesendet werden auch weiter zu O365 geroutet werden. An dieser Stelle ist wichtig, den richtigen DNS Eintrag zu verwenden. Hierzu meldet meldet man sich im O365 Tenant an und wechselt in das Admin-Center-> Setup->Domänen-> hier ist nun die Standard-Domäne auszuwählen. In meinem Fall ist das drmaxx.com. Um Anschluss werden u.a. sämtliche Infos zu Exchange Online angezeigt, der "MX Eintrag" wird nun zwischengespeichert

Der "MX" Wert wird nun im Hornetsecurity Control Panel als Ziel-System hinterlegt und gespeichert:

Die Vorbereitungen sind somit abgeschlossen. Im nächsten Schritt verbinde ich mich mit der Remote PowerShell von O365, siehe https://backendfrontend.blogspot.de/2018/05/tooltip-powershell-verbindung-nach-o365.html

Um die internen Emails eindeutig zu identifizieren wird eine s.g. Transportregel erstellt. Diese Transportregel stellt sicher, dass sämtliche interne Emails an den HSE Sende-Connector übermittelt werden. 

Im nächsten Schritt der der s.g. Sende-Connector angelegt. Hierzu im Exchange Admin Center unter "Mail flow" -> "Connectors" wechseln und einen neuen Connector anlegen:

Definition Name des Send-Connectors

Abhängigkeit Sende-Connector zu zuvor angelegter Transportregel

Definition Smarthost

Konfiguration Verschlüsselung der Kommunikation

Viele Grüße, Jens