Montag, 26. August 2019

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
-->

Donnerstag, 22. August 2019

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

Mittwoch, 14. August 2019

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 NameVersion Number
Outlook 978.0
Outlook 988.5
Outlook 20009.0
Outlook XP/200210.0
Outlook 200311.0
Outlook 200712.0
Outlook 201014.0
Outlook 201315.0
Outlook 201616.0
Outlook 201916.0
Office 36516.0

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


Viele Grüße, Jens

Montag, 18. Februar 2019

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

Montag, 4. Februar 2019

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






Samstag, 2. Februar 2019

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

Mittwoch, 6. Juni 2018

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



Samstag, 26. Mai 2018

Migration öffentliche Ordner Exchange 2010 nach Exchange 2016 - Teil1

Hallo zusammen,

in diesem ersten Teil der Migration der öffentlichen Ordner von Exchange 2010 nach Exchange 2016 beschäftige ich mich mit den Vorbereitungen, so dass Exchange 2016 Benutzer auf die noch bestehenden Exchange 2010 öffentlichen Ordner zugreifen können.

Zu Beginn ist es nicht unwichtig, dass Exchange 2016 Benutzer jederzeit auf öffentlichen Ordner der Exchange 2010 Server zugreifen können, somit ist es klar dass zuerst sämtliche Postfächer nach Exchange 2016 migriert sein müssen bevor die öffentliche Ordner Migration beginnen kann. In diesem Szenario gehe ich somit davon aus, dass sämtliche Benutzerpostfächer bereits nach Exchange 2016 migriert worden sind.

Sobald jedoch ein Benutzer nach Exchange 2016 migriert worden ist, hat dieser nicht perse Zugriff auf die öffentlichen Ordner des Exchange 2010 Servers. Um den Zugriff zu gewährleisten muss ein Proxy Postfach erstellt werden, welches zwischen den beiden Exchange Servern "kommuniziert" und Exchange 2016 Benutzern die öffentlichen Ordner des Exchange 2010 Servers im Outlook präsentiert. Es ist im übrigen nicht möglich über OWA 2016 auf die öffentlichen Ordner des Exchange 2010 Servers zuzugreifen.

Ohne diese Voraussetzungen begrüßt uns Outlook mit dem folgenden Fehler, sobald unser Exchange 2016 Benutzer auf die Exchange 2010 öffentliche Ordner zugreifen möchte:

Cannot expand the folder. The set of folders cannot be opened. Network problems are preventing connection to Microsoft Exchange.








Can’t complete your request
No public folders are available. Check that a public folders deployment exists in this Exchange organization. If so, please try again later



Somit widmen wir uns zuerst einmal den Voraussetzungen für den Zugriff der Exchange 2016 Benutzer auf die öffentlichen Ordner auf Exchange 2010. Wir stellen zunächst sicher
Outlook can't access public folders hosted on legacy Exchange servers

Wenn wir uns nun die zugewiesenen öffentlichen Ordern eines beliebigen Benutzers anschauen, sieht das wie folgt aus (der Wert "DefaultPublicFolderMailbox" ist leer)

get-mailbox -Identity jens.kleinhans| fl *public*



Nun weisen wir zunächst dem Benutzer Administrator Proxy Mailbox zu.
Set-Mailbox jens.kleinhans -DefaultPublicFolderMailbox (siehe Technet Artikel)


Im Anschluss wird erstmal getestet ob der Zugriff funktioniert indem versucht wird ob der Exchange 2016 Benutzer - via Outlook - die Exchange 2010 öffentlichen Ordner zu browsen.

Danach erteilen wir allen Benutzer der Datenbank(en) Zugriff auf die Exchange 2010 öffentlichen Ordner:

Set-MailboxDatabase (Get-Mailbox ).Database -PublicFolderDatabase (Get-MailboxDatabase (Get- Mailbox ).Database).PublicFolderDatabase

Zum Abschluss habe ich den MSExchangeRPC Dienst sicherheitshalber sowohl auf Exchange 2010 als auch auf dem Exchange 2010 durchgestartet.

Im nächsten Teil werden wir uns die Migration der öffentlichen Ordern von Exchange 2010 nach Exchange 2016 anschauen.

Viele Grüße, Jens



Freitag, 25. Mai 2018

Tooltip: PowerShell Verbindung nach O365

Hallo zusammen,

mit dem nachfolgenden Script ist es ganz einfach sich per Powershell auf seine O365 Umgebung zu verbinden um dort administrative Tätigkeiten durchführen zu können, https://www.cgoosen.com/2017/03/script-connect-365-ps-connect-to-office-365-services-using-remote-powershell/

Viele Grüße, Jens

Samstag, 19. Mai 2018

Exclaimer: Hinzufügen von Signaturen für IOS Geräte

Hallo zusammen,

wir haben vor kurzer Zeit die Anforderung eine neue automatisierte Signatur für einen Kunden via Exclaimer zu realisieren (für einen Exchange onpremise Server). Im Zuge der Konfiguration wurde "nur" die html Signatur erstellt, was sich als Fehler herausgestellt hat.

Beim Testen via Outlook wurde die Signatur wie gewünscht angefügt, allerdings wurden Signaturen über das IPhone bzw. IPAD nicht angezeigt. Die Lösung ist, dass auch noch eine Text-Signatur angelegt werden muss, da IOS Geräte Text Emails versenden. Ich habe hierzu einfach die html-Signatur kopiert und bei der Text Signatur eingefügt und schon klappt es auch mit den IOS Geräten.



Von daher am besten gleich von Anfang an auch die Text Signatur gleich erstellen, das spart Troubleshooting hintenraus.

Viele Grüße, Jens

Erweiterung User Profile Disks

Hallo zusammen,

zu Beginn der Erstellung einer RDS Collation muss sich der Administrator entscheiden, sofern dieser auf User Profile Disk setzt, wir groß die maximale Größe die User Profile Disk maximal werden darf.



Einmal eingestellt kann die maximale Größe der User Profile Disk nicht mehr geändert werden.
Was also tun, wenn die maximale Größe einzelner Benutzer nun doch erweitert werden muss, da der Benutzer das Limit gerissen hat und in seinem Profil beliebige Probleme hat (wie z.B. keine Speicherungen von Daten mehr auf dem Desktop mehr möglich)?

In einem früheren Beitrag habe ich die Vorgehensweise dokumentiert wie der Benutzername zu einer User Profile Disk ermittelt werden kann, https://backendfrontend.blogspot.com/2018/05/ermittlung-dateiname-einer-user-profile.html

Sofern die VM auf einem HyperV Server betrieben wird, muss die User Profile Disk Datei auf den HyperV Server kopiert werden. Sicherheitshalber ist es zum empfehlen eine Sicherung der Datei anzufertigen bevor hier Veränderungen vorgenommen werden. 

Sobald die VHDX Datei auf dem HyperV Server lokal vorliegt kann die Datei über den HyperV Manager erweitert werden.


Im weiteren ist nun die .vhdx Datei auszuwählen, die wir erweitern möchten:


Nun wählen wir "Erweitern" aus, da wir die bestehende Größe der Festplatte erhöhen möchten:


im letzten Schritt legen wir die neue maximale Größe der User Profile Disk fest und bestätigen mit "Fertigstellen"



Die bestehende Dateigröße der soeben angepassten .vhdx Datei bleibt unverändert, das Festplattenlimit wurde nur nun in diesem Fall auf 20 GB erhöht.
Die Datei wird nun wieder an ihren ursprünglichen Speicherort verschoben, so dass der Benutzer auf seine UPD wieder zugreifen kann. Sicherheitshalber bewahre ich die ursprüngliche .vhdx Datei noch ein paar Tage auf.

Viele Grüße, Jens




Mittwoch, 16. Mai 2018

Drucker und Terminal Server - Freunde fürs Leben

Hallo zusammen,

ich hatte in der vergangenen Zeit immer wieder Probleme mit dem Drucken aus dem Terminal Server heraus. Meine Umgebung besteht aus einer Windows Server 2016 RDS Farm und einem zentralen Print Server - ebenfalls Windows Server 2016. Die Drucker habe ich verbunden über den Netzwerkshare des zentralen Druckservers.

Mit den folgenden Symptomen habe ich zu kämpfen gehabt:

  • Der verbundener Drucker war von einem zum nächsten Tag nicht mehr vorhanden
  • Der verbundene Drucker wurde als "anderes Gerät" angezeigt
  • Der Drucker war zwar präsent, hat aber beim Drucken auf ein Treiber-Problem hingewiesen
Schlussendlich gab es beliebig viele Probleme, welche auch mit einem Neustart der RDS-und Druckserver nicht behoben werden konnte. Die Windows Updates waren selbstverständlich alle drauf.

Ich wusste mir anfangs nicht zu helfen als die Drucker wiederzu verbinden bzw. diese zu löschen und wieder neu hinzuzufügen. Dies konnte jedoch keine Lösung sein und habe nach einiger Recherche folgende Möglichkeiten gefunden um das Problem nachhaltig zu lösen:

Im Nachfolgenden Registry Key wurden die den Benutzern zugewiesenen Registry Schlüssel nach einer erfolgreichen RDS Abmeldung nicht auf den RDS Servern gelöscht. Daraufhin habe ich den Schlüssel sicherheitshalber exportiert und den Schlüssel vollständig gelöscht.

  • [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider]
    Im Anschluss habe ich erneut einen leeren Schlüssel namens "Client Side Rendering Print Provider" wieder angelegt.
  • Eine Alternative ist ebenfalls die Drucker per Gruppenrichtlinien zu verteilen. Dies hat den Vorteil, dass die GPO regelmäßig überprüft ob der Drucker vorhanden ist und legt ggf. den Drucker erneut an. Somit habe ich mir eine GPO angelegt



    Im Anschluss habe ich den freigegebenen Netzwerkdrucker hinterlegt:



    Unter "Gemeinsame Optionen" habe ich dann eingerichtet, dass der Drucker im Benutzerkontext hinzugefügt werden soll und dass der Drucker1 nur den Benutzern zugewiesen werden soll, die in der entsprechenden Gruppe Mitglied sind



    Nun noch die Gruppe auswählen, die dem Drucker zugewiesen ist.



Ich habe mich daraufhin mit einem Microsoft Support Spezialist unterhalten, dieses Problem war leider kein Einzelfall und es wäre auch müssig darüber zu diskutieren ob das Problem im Treiber des Druckerherstellers oder bei Microsoft selbst liegt. Wie auch immer, Microsoft empfiehlt das Verteilen der Drucker über GPOs zu realisieren.

Viele Grüße, Jens





Sonntag, 13. Mai 2018

Ermittlung Dateiname einer User Profile Disk

Hallo zusammen,

es kann manchmal vorkommen dass die User Profile Disks der Terminal Server Benutzer lokalisiert werden müssen. Die User Profile Disk Dateinamen werden allerdings als %SID%.vhdx Datei gespeichert:


Es gibt im Technet ein PowerShell Script zum Auschlüsseln der Benutzernamen hinter den .vhdx Dateien. Die Benutzer müssen hierzu übrigens nicht angemeldet sein, https://gallery.technet.microsoft.com/Retrieve-usernames-for-a-94780a9e 

Viele Grüße, Jens

Samstag, 5. Mai 2018

Migration VMWare nach HyperV

Hallo zusammen,

ich hatte das Vergnügen einige Tests VMs meiner VMWare Umgebung nach HyperV zu migrieren. Zu Beginn hatte ich den Fehler gemacht, dies auf einem Windows 7 Client auszuführen, bevor ich die Migration dann direkt auf dem HyperV Server durchgeführt habe.

Zu beachten an der Migration ist die Tatsache, dass für den Migrationszeitraum der doppelte Bedarf an Storage zur Verfügung stehen muss da sowohl die VMDK als auch die VHDX Datei gleichzeitig auf dem abgelegt werden.

Zu Beginn habe ich mir den Virtual Machine Converter erstmal auf dem HyperV Server installiert, anbei der Link zum Download, https://www.microsoft.com/en-us/download/details.aspx?id=42497

Es ist natürlich richtig, dass diese Software in Rente geschickt worden ist, sie hat jedoch einwandfrei funktioniert um meine VMs auf einen HyperV 2016 Server zu migrieren. Ich habe dabei sowohl Windows Server 2008 R2, Windows Server 201 R2 als auch Windows Server 2016 konvertiert.

Nach der Installation eine PowerShell öffnen und erstmal das Modul laden:
Import-Module 'C:\Program Files\Microsoft Virtual Machine Converter\MvmcCmdlet.psd1'

Im Anschluss können die Festplatten Stück für Stück migriert werden. Ich habe hier die Erfahrung gemacht nicht zu viele Jobs parallel durchzuführen, da mir zwischendurch immer mal wieder der RAM ausging und der Job abgebrochen.
ConvertTo-MvmcVirtualHardDisk -SourceLiteralPath C:\ClusterStorage\Volume1\Server1\Server1.vmdk -VhdType DynamicHardDisk -VhdFormat vhdx -destination C:\ClusterStorage\Volume1\Server1\

Viele Grüße, Jens

Donnerstag, 23. November 2017

Exchange Postfach Export bei ungleichem UPN zu Email Adresse

Hallo zusammen,

es kommt immer wieder vor, dass ein PST Postfach Export durchgeführt werden muss, bei dem der UPN nicht der Email Adresse entspricht. Gerade in einer cloudlastigen Zeit wird erwartet, dass der UPN der email Adresse entspricht um Benutzer beispielsweise ein single sign on für diverse Dienste anbieten zu können.

Warum nun dieses Script, es gab die Anforderung dass für eine Exchange Cross Forest Migration die Postfächer in PST Dateien exportiert wurden und diese dann automatisiert über ein Import Script in der Ziel Seite wieder importiert wurden. In der Zielseite wurde allerdings der UPN der Email Adresse gleichgesetzt. Das unten stehenden Script zieht sich nun anhand das AD Benutzer die Email Adresse und schreibt die Email Adresse in den Dateinamen rein um eine eindeutige Identifikation des Postfachs zu erhalten. Das Script funktioniert ab der Version Exchange 2010.

### PST Export für O365 Import bei unterschiedlichem UPN zu Email Adresse
#import-module activedirectory
#Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010

$Workload = "Exchange"
$Archiv = "FALSE"
$TargetRootFolder = "/"
$Date = (Get-Date).ToString('MM-dd-yyyy-HH-mm-ss')
$BasePath = "\\servername\g$\archive"
$ExportPath = $BasePath +"PSTs-" +$Date + "\"
$OutputFile = $BasePath +"Mailbox-O365" +"-" +$Date +".csv"
$ResultSize = 1000 #"unlimited"
$FilesCSV = @()
$CSVImportPath = "c:\temp\Migrationsliste.csv"
$UPN = @()
$Mbxsrollout = @()

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010
New-Item -ItemType directory -Path $ExportPath -ErrorAction SilentlyContinue

#get-mailbox -OrganizationalUnit $OU

#CSV (Es muss "Kein CSV" oder "CSV" aktiv sein! Nie Beide!)
$FilesCSV += Import-Csv $CSVImportPath
#$Mbxsrollout = $FilesCSV

$FilesCSV
#$FilesCSV.count

foreach ($object in $FilesCSV) {
#$WEA = $object.WindowsEmailAddress
write-host "$object.WindowsEmailAddress in Bearbeitung"
#$Mbxsset = Get-ADUser -Filter "UserPrincipalName -Eq '$WEA'" -Properties *
$Mbxsrollout += get-mailbox -Identity $object.WindowsEmailAddress
#$Mbxsrollout

}
#$Mbxsrollout | select *name*
#$Mbxsrollout.count
#$FilesCSV.count
#$Mbxsrollout.count
#$Mbxsrollout

$Files = $Mbxsrollout | Select-Object @{label="Workload";expression={$Workload}}, @{label="FilePath";expression={$FilePath}}, @{label="Name";expression={($_.WindowsEmailAddress.ToString() + ".pst")}}, @{label="Mailbox";expression={($_.PrimarySmtpAddress)}}, @{label="IsArchive";expression={($Archiv)}},@{label="TargetRootFolder";expression={($TargetRootFolder)}},@{label="SPFileContainer";expression={("")}},@{label="SPManifestContainer";expression={("")}},@{label="SPSiteUrl";expression={("")}}
$Files | Export-Csv $OutputFile -NoTypeInformation -Delimiter ","
#$Files

#Kein CSV (Es muss "Kein CSV" oder "CSV" aktiv sein! Nie Beide!)

#$Files = get-mailbox -ResultSize $ResultSize -OrganizationalUnit $OU | Select-Object @{label="Workload";expression={$Workload}}, @{label="FilePath";expression={$FilePath}}, @{label="Name";expression={($_.Name + ".pst")}}, @{label="Mailbox";expression={($_.PrimarySmtpAddress)}}, @{label="IsArchive";expression={($Archiv)}},@{label="TargetRootFolder";expression={($TargetRootFolder)}},@{label="SPFileContainer";expression={("")}},@{label="SPManifestContainer";expression={("")}},@{label="SPSiteUrl";expression={("")}}
#$Files | Export-Csv $OutputFile -NoTypeInformation -Delimiter ","
#$Files


foreach ($MB in $Files){
#[String]$MBName = $MB.Mailbox.local + "@" +$MB.Mailbox.Domain
#[String]$MBName = $MB.Mailbox.local + "@" +$MB.Mailbox.Domain
#[String]$MBName
#$MB.Mailbox
New-MailboxExportRequest -BadItemLimit 1000 -AcceptLargeDataLoss -mailbox $MB.Mailbox.ToString() -Domaincontroller %DomainController% -FilePath $ExportPath\$($MB.Name)
}

Write-Output "Der Pfad für den Folgeschritt Import lautet: " $ExportPath

Write-Output "`nDie zugehörige PST-Importzuordnungsdatei wurde hier abgelegt: " $OutputFile

#Skript erwartet bei CSV-Datei als Header: ("# " am Anfang beim Kopieren entfernen)
# #TYPE Selected.Microsoft.Exchange.Data.Directory.Management.Mailbox
# "WindowsEmailAddress"


viele Grüße, Jens

Freitag, 10. November 2017

Überprüfung DNS Einträge für Skype for Business

Hallo zusammen,

immer wieder gibt es ein Problem, dass Skype for Business sind sauber funktioniert, egal ob onpremis oder auch bei O365. Es fällt dabei immer wieder im Troubleshooting auf, dass DNS Einträge nicht bzw. nicht richtig gesetzt sind. 

Aus diesem Grund haben einige Kollegen das nachfolgende PS Script geschrieben um zu prüfen ob und welche DNS relevanten SfB Einträge gesetzt sind:

#Definition der SIP-Domains:
$SipDomain = "contoso.com","fabrikam.com"

#Überprüfung der oben hinterlegten SIP Domains:
$SipDomain
Foreach ($Item in $SipDomain) {
Write-Host "`n`n### Prüfe: ARECORD sip.$item ###`n"
#nslookup -q=a sip.$item
resolve-dnsname -type a sip.$item -ErrorAction SilentlyContinue
Write-Host "`n`n### Prüfe: CNAME sip.$item ###`n"
#nslookup -q=cname sip.$item
resolve-dnsname -type cname sip.$item -ErrorAction SilentlyContinue
Write-Host "`n`n### Prüfe: SRV _sip._tls.$item ###`n"
#nslookup -q=srv _sip._tls.$item 
resolve-dnsname -type srv _sip._tls.$item -ErrorAction SilentlyContinue
Write-Host "`n`n### Prüfe: SRV sipfederationtls._tcp.$item ###`n"
#nslookup -q=srv _sipfederationtls._tcp.$item
resolve-dnsname -type SRV _sipfederationtls._tcp.$item -ErrorAction SilentlyContinue
Write-Host "`n`n### Prüfe: CNAME lyncdiscover.$item ###`n"
#nslookup -q=cname lyncdiscover.$item
resolve-dnsname -type cname lyncdiscover.$item -ErrorAction SilentlyContinue
}

In einem weiteren Eintrag werde ich darauf eingehen welche DNS Einträge für SfB relevant sind.

Viele Grüße, Jens

Sonntag, 13. März 2016

Kurz notiert: Ausgabe aller Benutzer inkl. letzte Anmeldezeit

Hallo zusammen,

mit diesem Script werden alle Benutzer inkl deren letzte Anmeldezeit am Postfach in eine CSV Datei exportiert. Zusätzlich wird noch das Attribut Company mit ausgeben.

$mailbox = get-mailbox -resultsize unlimited

foreach ($mbx in $mailbox) {Get-MailboxStatistics -Identity $mbx | select displayname, lastlogo
ntime, @{name="office";exp={$mbx.office}} | Export-Csv "c:\temp\mailboxes.csv" -Append }

Viele Grüße, Jens

Donnerstag, 10. März 2016

Herausforderungen beim Austausch Exchange Zertifikate (POP, IMAP)

Hallo zusammen,

es gibt doch immer wieder Dinge die du beim Austausch von Exchange Zertifikaten dazulernst. Vorhanden war ein Wildcard Zertifikat welchen auf den Namen "*.contoso.com" hieß und gerne ausgetauscht werden wollte. Dieses Wildcard Zertifikat hatte als "Friendly Name" "webmail.contoso.com" hinterlegt.

Ich gehe an dieser Stelle jetzt nicht auf den Austausch des Zertifikats an sich ein (weitere gut dokumentierte Informationen findest du hier), vielmehr auf das Problem welches draus resultieren kann wenn Exchange sich anders verhält als das eigentlich gedacht.

Es wurde also das neue Zertifikat installiert, aus Rollback Gründen wurde jedoch das alte Zertifikat erstmal noch auf dem Server belassen, auch wenn dieses keine Services (IIS, SMTP etc.) mehr zugewiesen hatte. Das neue, ausgetauschte Zertifikat wurde allerdings mit dem "Friendly Name" "owa.contoso.com" beim Zertifikats-Anbieter beantragt und wurde somit auch so ausgestellt und schlussendlich auch so auf den Exchange Servern installiert.

An dieser Stelle ist zu beachten, dass ein ein Wildcard Zertifikat nicht über die Exchange Management Console und auch nicht über PowerShell gesetzt werden kann (jedenfalls im ersten Schritt).



Der POP3 Service müsste über folgenden PowerShell Befehl konfiguriert werden:
Set-POPSettings -X509CertificateName webmail.contoso.com

Der IMAP Service müsste über folgenden PowerShell Befehl konfiguriert werden:
Set-IMAPSettings -X509CertificateName webmail.contoso.com 

Aber zurück zum Thema, das Ganze hatte bis zum dem Zeitpunkt keine negativen Auswirkungen bis das alte Zertifikat (webmail.contoso.com) von den Exchange Servern entfernt wurde. Es läuft ja eh ab und um Irritationen und Fehler im Eventlog zu vermeiden muss es ja eh runter.
Ab diesem Zeitpunkt funktionierte weder POP3 noch IMAP.

Natürlich wurden die üblichen Maßnahmen durchgeführt wie...

  • Überprüfen der Zertifikatskette 
  • Neuinstallation des Zertfikats
  • Neustart der IMAP / POP3 Dienste (Frontend und Backend)
Auf den Exchange "Backend" Systemen also dort wo die POP3BE und IMAPBE Services laufen wurden jedoch Fehlermeldungen beim Neustart des Services hinterlegt.

Schlussendlich war die Lösung dann doch nahe liegend wenn auch nicht ganz nachvollziehbar. Das X509 Zertifikat ist konfiguriert auf "webmail.contoso.com" - der Friendly Name ist konfiguriert auf "owa.contoso.com" - und genau das war das Problem. Der Friendly Name MUSS mit der X509 Konfiguration zwingend übereinstimme.

Der Friendly Name kann über die Zertifikats Managementkonsole recht einfach geändert werden. Zum Ändern schlichtweg mit der rechten Mousetaste auf das Zertifikat klicken und Eigenschaften auswählen, nun kann der Wert geändert werden.

Zum Abschluss wurden die POP3 und IMAP Dienste noch neugestartet, diese Mal auch ohne Fehlermeldungen in der Ereignisanzeige.

Viele Grüße, Jens





Sonntag, 6. März 2016

RDS Profile werden nicht vollständig gespeichert

Hallo zusammen,

vor kurzem hatten wir das Problem dass nicht sämtliche Profildaten in einer RDS2012 R2 Farm gespeichert wurden, aber der Reihe nach. Das Problem tauchte in einer besagten RDS2012 R2 Farm in Kombination mit einem RDS 2012 R2 Broker / Gateway Service auf. Zum Abspeichern der Profile wurde die User Profile Disk benutzt.

Die Benutzer beklagten sich dass zwar Desktop Symbole in das Profil gespeichert wurden, aber z.B. Internet Explorer Favoriten, Symbole auf Start oder Anpassungen in den Office Applikationen wurden nicht gespeichert. Folgende Probleme wurden ausgeschlossen:


  • In der Ereignisanzeige der beiden RDS Worker gab es auch keinerlei Fehlermeldungen oder sonstige Probleme. 
  • Überprüfung der Berechtigungen bzw. Freigabeberechtigungen der User Profile Disk
  • Mehrfaches Löschen der User Profile Disk Daten
  • Da noch kein Windows Server 2012 R2 Domain Controller vorhanden war, wurde kurzerhand dieser installiert und die User Profile Disk dort platziert

Dies brachte jedoch alles nicht das gewünscht Ergebnis, dass eben alle Profildaten gespeichert wurden. 

Dies Lösung war dann doch in der RDS Umgebung zu finden, auch wenn ich diese nach wie vor nicht als logisch erachte. Ursprünglich war das Profil so konfiguriert, dass der Haken bei "Nur folgende Ordner auf dem Benutzerprofil-Datenträger speichern" aktiviert war. Dort war dann ALLES angehakt, außer "Musik". Und genau das war das Problem, der Haken muss auf "Alle Benutzereinstellungen und -daten auf dem Benutzerprofil-Datenträger speichern" gesetzt werden.


In diesem Sinne hoffe ich dass dieser Tip dem einen oder anderen hilft und vor allem Zeit spart bei der Suche des Problems.

Viele Grüße, Jens

Montag, 11. Januar 2016

Verhindern der Erstellung/Download einer .OST Datei (Verbieten Cached Mode / Erzwingen Online Mode)

Hallo zusammen,

die Daten mancher Postfächer sollten bzw. dürften das Rechenzentrum in dem der Exchange Server betrieben hat unter gewissen Umständen nicht verlassen. Wenn es beispielsweise um Personaldaten, Gehaltsabrechnungen etc. geht würde das jeweilige Postfach im Normalfall als .OST Datei auf den jeweiligen PC heruntergeladen. Sofern dieser PC/Laptop nun abhanden kommt, ist es ein Einfaches aus einer .OST Datei die Daten zu extrahieren, LINK

Die Realisierung erfolgt dann über GPOs in Kombination mit Registry Schüsseln.

Erstellung GPO
Zuerst sollte eine entsprechend neue GPO erstellt werden, https://technet.microsoft.com/en-us/library/cc753092.aspx

Manuelles Verbieten der .OST Datei in der Registry
Im nächsten Schritt kann über die Registry die Erstellung der .OST Datei, mit anderen Worten der Exchange Cached Modus deaktiviert werden, so dass das Postfach nur im Online Modus verbunden wird.

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\15.0\outlook\ost]
"NoOST"=dword:00000002

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\15.0\outlook\cached mode]
"Enable"=dword:00000000 


Setzen der Registry Schüssel via GPO
Natürlich kann der Registry Schlüssel auch per GPO gesetzt werden



Die GPO sollte vom Bereich dann auf die jeweiligen Benutzer definiert werden.


Viele Grüße, Jens