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
Sonntag, 13. März 2016
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...
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:
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.
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
Montag, 4. Januar 2016
Absicherung Outlook Anywhere
Hallo zusammen,
Outlook Anywhere impliziert den Zugriff auf den Dienst Outlook von überall - von potentiell jedem Gerät aus. Doch welche Möglichkeiten bestehen diesen Zugriff zu reglementieren, so dass z.B. nur unternehmenseigene Geräte eine Verbindung zum Exchange Server aufbauen können. Nachfolgend einige Möglichkeiten um diese Anforderung zu realisieren:
Einrichtung oder Nutzung einer bestehenden VPN Infrastruktur
Direct Access - Im Gegensatz zu VPN benötigt DirectAccess kein benutzerseitiges initiieren einer Verbindung, sondern stellt bereits beim Start des Computers automatisch eine Verbindung zum Unternehmensnetzwerk her, falls sich ein Client außerhalb des Unternehmensnetzwerk befindet. Durch die automatische Verbindung der Clients zum Netzwerk ist ein Verwalten von externen Computern, sogenanntes „Manage-Out“, für Unternehmen möglich
Security by obsecurity
Die vermeintlich einfachste Lösung, die Implementierung von Client Zertifikaten wird leider von Microsoft im Outlook Anywhere Kontext nicht unterstützt.
Outlook Anywhere impliziert den Zugriff auf den Dienst Outlook von überall - von potentiell jedem Gerät aus. Doch welche Möglichkeiten bestehen diesen Zugriff zu reglementieren, so dass z.B. nur unternehmenseigene Geräte eine Verbindung zum Exchange Server aufbauen können. Nachfolgend einige Möglichkeiten um diese Anforderung zu realisieren:
Einrichtung oder Nutzung einer bestehenden VPN Infrastruktur
- Outlook Anywehre (OA) wäre in diesem Szenario von extern nicht mehr verfügbar, nur noch im VPN
- Benutzer welche auf OA zugreifen möchten, müssten zuerst eine VPN Verbindung aufbauen um den Dienst zu nutzen
- Setzt bei größeren Firmen eine einheitliche VPN Lösung voraus
Direct Access - Im Gegensatz zu VPN benötigt DirectAccess kein benutzerseitiges initiieren einer Verbindung, sondern stellt bereits beim Start des Computers automatisch eine Verbindung zum Unternehmensnetzwerk her, falls sich ein Client außerhalb des Unternehmensnetzwerk befindet. Durch die automatische Verbindung der Clients zum Netzwerk ist ein Verwalten von externen Computern, sogenanntes „Manage-Out“, für Unternehmen möglich
- Die interessantes Lösung bzw. Ansatz um so einfach wie möglich den Mitarbeitern Zugriff auf das Firmennetzwerk zu erteilen – keine VPN Clients mehr, keine auslaufenden Tokens mehr – nur noch den Laptop anmachen und arbeiten.
- „Konkurrenz“ Produkt zu einer potentiell bestehenden VPN Lösung. Zwar können beide Lösungen gleichzeitig betrieben werden, strategisch macht allerdings nur eine Lösung Sinn
- Die Anforderungen für Direct Access sind auf dem folgenden Link beschrieben, https://technet.microsoft.com/de-de/library/dd637797(v=ws.10).aspx (zu beachten ist, dass die Clients min. Windows 7 Enterprise bzw. Ultimate installiert haben müssten)
Security by obsecurity
- Verwendung von privaten Stammzertifizierungsstellen zum Erstellen von SSL Zertifikaten für die jeweiligen Computer
- Ohne diese Stammzertifizierungsstelle wäre es somit nicht möglich eine OA Verbindung aufzubauen
- Sehr einfach zu umgehen, indem auf nicht vertrauenswürdigen Geräten schlicht das Stammzertifikat installiert werden würde
- „Konkurrenz“ Produkt zu einer bestehenden Firewall Lösung
- Wird mit Microsoft TMG realisiert, https://www.microsoft.com/en-us/download/details.aspx?id=23708 – dieses Produkt ist bereits von Microsoft abgekündigt, http://tmgblog.richardhicks.com/2012/09/12/forefront-tmg-2010-end-of-life-statement/
Die vermeintlich einfachste Lösung, die Implementierung von Client Zertifikaten wird leider von Microsoft im Outlook Anywhere Kontext nicht unterstützt.
Abonnieren
Posts (Atom)