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

Ü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

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

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

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

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

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

• 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

Implementierung einer IPSEC Lösung

• „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.