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
Posts mit dem Label Exchange 2013 werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Exchange 2013 werden angezeigt. Alle Posts anzeigen
Donnerstag, 23. November 2017
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
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
Labels:
Exchange 2013,
PowerShell
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
Labels:
Exchange 2013,
IMAP,
POP3,
X509,
Zertifikat
Dienstag, 29. Dezember 2015
permanenter Status Wechsel des Content Index State
Hallo zusammen,
mal wieder ein seltsames Phänomen, welches sich aufzuschreiben lohnt. Ein Exchange 2013 (CU9) Multi-Role Server welcher Mitglied einer DAG ist, hatte permanent Probleme mit dem Content Index State der unterschiedlichsten Datenbanken. Durch die Bank war der Content Index State mal "healthy" und manchmal "failed".
Geprüft habe ich den jeweiligen Stauts mit folgenden PowerShell Befehl:
Get-MailboxDatabaseCopyStatus | FL Name,*Index*
Das Eregebnis war dann sehr aufschlussreich:
Name : Mailboxdatabase01
ContentIndexState : Failed
ContentIndexErrorMessage : An internal error occurred for the database or its index.
ContentIndexErrorCode : 2
Gleichzeitig wurde im Eventlog folgender Fehler (Event-ID 1009, MSExchangeFastSearch) protokolliert:
The indexing of mailbox database Mailboxdatabase01 encountered an unexpected exception. Error details: Microsoft.Exchange.Search.Core.Abstraction.OperationFailedException: The component operation has failed. ---> Microsoft.Exchange.Search.Core.Abstraction.OperationFailedException: The component operation has failed. ---> Microsoft.Exchange.Search.Fast.FastDocumentTimeoutException: The Content Submission Service returned failure for the document: Document timeout expired
. ---> System.TimeoutException: Document timeout expired
--- End of inner exception stack trace ---
at Microsoft.Exchange.Search.Fast.FastFeeder.EndSubmitDocument(IAsyncResult asyncResult)
at Microsoft.Exchange.Search.Mdb.RetryFeeder.DocumentCompleteCallback(IAsyncResult asyncResult)
--- End of inner exception stack trace ---
at Microsoft.Exchange.Search.Core.Common.Executable.EndExecute(IAsyncResult asyncResult)
at Microsoft.Exchange.Search.Engine.SearchFeedingController.ExecuteComplete(IAsyncResult asyncResult)
--- End of inner exception stack trace ---
at Microsoft.Exchange.Search.Core.Common.Executable.EndExecute(IAsyncResult asyncResult)
at Microsoft.Exchange.Search.Engine.SearchRootController.ExecuteComplete(IAsyncResult asyncResult)
Das Re-Seeding des Content Index, was ich als ersten getestet hatte, brachte leider nicht wirklich den Erfolg, Erst mit dem Anlegen einer globalen Sicherheitsgruppe namens "ContentSubmitters" konnte das Problem behoben werden. Sobald die Gruppe angelegt ist, in der Registerkarte "Sicherheit" die Benutzer "NetworkService" und "Administrators" die Berechtigung "Vollzugriff" zuweisen. Im Anschluss müssen die beiden folgenden Dienste neugestartet werden:
Restart-Service MSExchangeFastSearch
Restart-Service HostControllerService
Danach klappts auch wieder mit dem Content Index State.
Viele Grüße, Jens
mal wieder ein seltsames Phänomen, welches sich aufzuschreiben lohnt. Ein Exchange 2013 (CU9) Multi-Role Server welcher Mitglied einer DAG ist, hatte permanent Probleme mit dem Content Index State der unterschiedlichsten Datenbanken. Durch die Bank war der Content Index State mal "healthy" und manchmal "failed".
Geprüft habe ich den jeweiligen Stauts mit folgenden PowerShell Befehl:
Get-MailboxDatabaseCopyStatus | FL Name,*Index*
Das Eregebnis war dann sehr aufschlussreich:
Name : Mailboxdatabase01
ContentIndexState : Failed
ContentIndexErrorMessage : An internal error occurred for the database or its index.
ContentIndexErrorCode : 2
Gleichzeitig wurde im Eventlog folgender Fehler (Event-ID 1009, MSExchangeFastSearch) protokolliert:
The indexing of mailbox database Mailboxdatabase01 encountered an unexpected exception. Error details: Microsoft.Exchange.Search.Core.Abstraction.OperationFailedException: The component operation has failed. ---> Microsoft.Exchange.Search.Core.Abstraction.OperationFailedException: The component operation has failed. ---> Microsoft.Exchange.Search.Fast.FastDocumentTimeoutException: The Content Submission Service returned failure for the document: Document timeout expired
. ---> System.TimeoutException: Document timeout expired
--- End of inner exception stack trace ---
at Microsoft.Exchange.Search.Fast.FastFeeder.EndSubmitDocument(IAsyncResult asyncResult)
at Microsoft.Exchange.Search.Mdb.RetryFeeder.DocumentCompleteCallback(IAsyncResult asyncResult)
--- End of inner exception stack trace ---
at Microsoft.Exchange.Search.Core.Common.Executable.EndExecute(IAsyncResult asyncResult)
at Microsoft.Exchange.Search.Engine.SearchFeedingController.ExecuteComplete(IAsyncResult asyncResult)
--- End of inner exception stack trace ---
at Microsoft.Exchange.Search.Core.Common.Executable.EndExecute(IAsyncResult asyncResult)
at Microsoft.Exchange.Search.Engine.SearchRootController.ExecuteComplete(IAsyncResult asyncResult)
Das Re-Seeding des Content Index, was ich als ersten getestet hatte, brachte leider nicht wirklich den Erfolg, Erst mit dem Anlegen einer globalen Sicherheitsgruppe namens "ContentSubmitters" konnte das Problem behoben werden. Sobald die Gruppe angelegt ist, in der Registerkarte "Sicherheit" die Benutzer "NetworkService" und "Administrators" die Berechtigung "Vollzugriff" zuweisen. Im Anschluss müssen die beiden folgenden Dienste neugestartet werden:
Restart-Service MSExchangeFastSearch
Restart-Service HostControllerService
Danach klappts auch wieder mit dem Content Index State.
Viele Grüße, Jens
Labels:
ContentIndexState,
Exchange 2013
Freitag, 6. November 2015
BES5 / BES 10 Migration nach Exchange 2010 / Exchange 2013
Hallo zusammen,
im letzten Projekt hatten wir die Herausforderung Blackberry 5 und Blackberry 10 Benutzer von Exchange 2010 nach Exchange 2013 zu migrieren. Da dies alles in allem sehr zeitaufwendig und nervenaufreibend war möchte ich die gesammelten Erfahrungen gerne teilen...
Ausgangssituation:
X Benutzer auf BES5, die Postfächer liegen auf Exchange 2010
(Benutzerzugriff via Blackberry Technologie)
X Benutzer auf BES10, die Postfächer liegen auf Exchange
2010 (Benutzerzugriff via ActiveSync)
Der CAS Zugang ist bereits auf Exchange 2013 umgestellt,
d.h. alle Benutzer egal ob das Postfach auf Exchange 2010 oder 2013 liegt
greifen über die Exchange 2013er CAS Server auf die Mailboxen zu.
Ziel:
Alle Postfächer, egal ob BES5 oder BES10 nach Exchange 2013
migrieren ohne Auswirkungen auf die Endbenutzer (d.h. möglichst ohne
Neu-Aktivierung der Geräte)
Im Anschluss Migration der BES5 und BES10 Benutzer nach BES
12
Vorgehensweise
Blackberry 5:
- CDO.DLL auf Blackberry 5 aktualisiert, diese war nicht mehr aktuell, siehe http://support.blackberry.com/kb/articleDetail?ArticleNumber=000015779 (Download der CDO erfolgt hier: https://www.microsoft.com/en-us/download/details.aspx?id=3671 )
- Leitfaden für die Migration von BES5 nach Exchange 2013, http://support.blackberry.com/kb/articleDetail?articleNumber=000033406
- BES5 Vorbereitung zu Kommunikation mit Exchange 2013, http://support.blackberry.com/kb/articleDetail?ArticleNumber=000033413 (ist extrem wichtig, sonst kann BES5 kein Autodiscover was zwingend für Exchange 2013 notwendig ist). Jeder einzelne Schritt muss beachtet werden!
- Erteilen Postfachberechtigungen auf Exchange 2013 Benutzer für BESAdmin, http://support.blackberry.com/kb/articleDetail?ArticleNumber=000002276
- Migration BESAdmin von Exchange 2010 nach Exchange 2013
- Anpassung MAPI Profil auf BES5 unter „BlackBerry Server Configuration“ -> Blackberry Server -> Edit MAPI Profile, siehe auch http://support.blackberry.com/kb/articleDetail?ArticleNumber=000034416. Wichtig an dieser Stelle in Feld Servername muss zwingend die Exchange-GUID stehen. Steht dort noch der FQDN, so ist dies der FQDN des Exchange 2010 Servers und nunmehr falsch da sich das Postfach bereits auf Exchange 2013 befindet
- Der Regkey " RPCHTTPProxyMap_BES" unterhalb von HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem sollte sowohl die CAS URL als auch die Exchange 2013 GUID (aus der Server Configuration -> Blackberry Server - > edit MAPI Profile ) enthalten. Also so in etwa: *=https://cas.contoso.de; aaaaaaa-6a55-5678-1234-c3acaaaa3aa@contoso.de
- Durchführen erster BES 5 Testmigration nach Exchange 2013 inkl. Durchführung von Enterprise Aktivierung
Vorgehensweise
Blackberry 10:
Blackberry 10 arbeitet direkt mit Active Sync so dass hier
deutlich weniger Konfigurationsanpassungen durchgeführt werden müssen.
Auch der BES 10 hat ein konfiguriertes Profil welches im BAS
unter „Blackberry Solution Management“ -> „Profiles“ -> „Manage Profiles“
-> Registerkarte „Email Profile Settings“ angepasst werden muss. Hier wird
in aller Regel der Exchange 2010 CAS Server bzw. das CAS Server Array
hinterlegt sein. Dies bedeutet, dass Postfächer welche bereits auf Exchange 2013
liegen den Service Blackberry problemlos weiter konsumieren können – dies gilt
auch für Exchange 2010 Benutzer. Allerdings ist es nicht möglich das bereits
migrierte Benutzer auf Exchange 2013 eine Enterprise Aktivierung durchführen
können, da die URL auf Exchange 2010 zeigt. Die Umstellung auf das CAS2013
Array habe ich zum Abschluss der Postfachmigration von Exchange 2010 nach
Exchange 2013 durchgeführt. Ab diesem Zeitpunkt funktioniert auch wieder Email
Aktivierung für Blackberry 10 Geräte.
Viele Grüße, Jens
Labels:
Blackberry 10,
Blackberry 5,
Exchange 2010,
Exchange 2013,
Migration
Freitag, 11. September 2015
Organisator wird nicht im Termin angezeigt
Hallo zusammen,
hatte die Tage den Fall, dass Benutzer nicht mehr den Organisator im Termin einer Raum-Ressource gesehen hatten. Folgenden PowerShell Befehl wurde bereits abgesetzt:
Set-CalendarProcessing -Identity raum@contoso.com -AutomateProcessing Auotaccept -AddOrganizerToSubject $true
AutoAccept muss zwingend gesetzt werden, da ansonsten die Parameter -AddOrganizerToSubject nicht berücksichtigt werden.
Na ja, jedenfalls konnte ich im eigentlichen Termin des Raumpostfachs den Orgnaisator dennoch nicht anschauen, auch wenn natürlich dieser im Betreff bereits hinterlegt ist. Die Lösung war, dass meinem Benutzer bzw. der Gruppe schlicht die Berechtigung Reviewer gefehlt hatte:
set-MailboxFolderPermission -Identity raum@contoso.com:\calendar -User jens@contoso.com -AccessRights reviewer
Softern "\Calendar" nicht funktioniert, ist das Postfach aller Voraussicht nach in Deutsch und somit muss "\Kalender" hinterlegt werden.
Viele Grüße, Jens
hatte die Tage den Fall, dass Benutzer nicht mehr den Organisator im Termin einer Raum-Ressource gesehen hatten. Folgenden PowerShell Befehl wurde bereits abgesetzt:
Set-CalendarProcessing -Identity raum@contoso.com -AutomateProcessing Auotaccept -AddOrganizerToSubject $true
AutoAccept muss zwingend gesetzt werden, da ansonsten die Parameter -AddOrganizerToSubject nicht berücksichtigt werden.
Na ja, jedenfalls konnte ich im eigentlichen Termin des Raumpostfachs den Orgnaisator dennoch nicht anschauen, auch wenn natürlich dieser im Betreff bereits hinterlegt ist. Die Lösung war, dass meinem Benutzer bzw. der Gruppe schlicht die Berechtigung Reviewer gefehlt hatte:
set-MailboxFolderPermission -Identity raum@contoso.com:\calendar -User jens@contoso.com -AccessRights reviewer
Softern "\Calendar" nicht funktioniert, ist das Postfach aller Voraussicht nach in Deutsch und somit muss "\Kalender" hinterlegt werden.
Viele Grüße, Jens
Montag, 10. August 2015
Kurz notiert: Export der Email Adressen einer bestimmten OU
Hallo zusammen,
mit diesem PowerShell Script ist es möglich alle Mailbox Benutzer einer bestimmten OU zu exportieren - genauer gesagt wird hier lediglich die primäre Email Adresse exportiert, was aber beliebig erweitert werden kann.
get-mailbox -OrganizationalUnit "OU-Name" -resultsize unlimited | select-object PrimarySmtpAddress | Export-Csv "C:\temp\User.csv" -NoTypeInformation -Delimiter ";"
mit diesem PowerShell Script ist es möglich alle Mailbox Benutzer einer bestimmten OU zu exportieren - genauer gesagt wird hier lediglich die primäre Email Adresse exportiert, was aber beliebig erweitert werden kann.
get-mailbox -OrganizationalUnit "OU-Name" -resultsize unlimited | select-object PrimarySmtpAddress | Export-Csv "C:\temp\User.csv" -NoTypeInformation -Delimiter ";"
Viele Grüße, Jens
Labels:
Exchange 2010,
Exchange 2013,
PowerShell
Freitag, 10. Juli 2015
Handling ausgeschiedene Mitarbeiter
Hallo zusammen,
viele Firmen haben das Problem mit Postfachbehandlung ausgeschiedener Mitarbeiter. Sofern das Postfach gelöscht wird, versteht nahezu kein fachfremder ITler diesen komischen NDR, dass dieses Postfach nicht mehr existent ist.
Es muss also eine smartere, benutzer- und kundenfreundlichere Lösung her. Anbei beschreibe ich die Möglichkeit mit wenigen Befehlen eine anständige Abwesenheitsnotiz zentral durch die IT bereitgestellt in Kombination dass eingehende Emails direkt gelöscht werden, so dass das Postfach nicht potentiell überläuft und wieder unlesbare NDRs versendet werden:
viele Firmen haben das Problem mit Postfachbehandlung ausgeschiedener Mitarbeiter. Sofern das Postfach gelöscht wird, versteht nahezu kein fachfremder ITler diesen komischen NDR, dass dieses Postfach nicht mehr existent ist.
Es muss also eine smartere, benutzer- und kundenfreundlichere Lösung her. Anbei beschreibe ich die Möglichkeit mit wenigen Befehlen eine anständige Abwesenheitsnotiz zentral durch die IT bereitgestellt in Kombination dass eingehende Emails direkt gelöscht werden, so dass das Postfach nicht potentiell überläuft und wieder unlesbare NDRs versendet werden:
New-InboxRule -Mailbox %Mailbox%-MyNameInToOrCcBox $true –DeleteMessage $true
Mit dieser Posteingangsregel für den speziellen Benutzer
werden alle Emails die an dieses Postfach gesendet werden ohne Rückfrage gelöscht
$Message = Get-Content -path c:\temp\oof.txt
Mit diesem Befehl wird die Out-of-Office Vorlagen-Nachricht
in die Variable $Message eingelesen. Diese ist entsprechend der jeweiligen OOF
Meldung anzupassen.
Mit dem Befehl $Message kann man sich vorab schonmal das
Ergebnis anschauen
Set-MailboxAutoReplyConfiguration
-Id %Mailbox% -AutoReplyState enabled -InternalMessage "$Message"
-ExternalMessage "$Message"
Mit diesem Befehl
wird die OOF Nachricht für das entsprechende Postfach für eingehende und
ausgehende Emails ohne zeitlich Begrenzung gesetzt
Mit dem unten stehenden Befehl wird die OOF Einstellung wieder deaktiviert:
Set-MailboxAutoReplyConfiguration –id –AutoReplyState Disabled
Mit dem unten stehenden Befehl wird die OOF Einstellung wieder deaktiviert:
Set-MailboxAutoReplyConfiguration –id
Herzlichen Dank für Ihre E-Mail.
Leider existiert die von Ihnen angeschriebene E-Mailadresse nicht mehr.
Sehr gerne teilen wir Ihnen telefonisch einen persönlichen Ansprechpartner für Ihr Anliegen mit.
Wählen Sie hierzu einfach die Nummer unserer Zentrale.
Besten Dank und mit freundlichen Grüßen,
%Firmendaten%
Leider existiert die von Ihnen angeschriebene E-Mailadresse nicht mehr.
Sehr gerne teilen wir Ihnen telefonisch einen persönlichen Ansprechpartner für Ihr Anliegen mit.
Wählen Sie hierzu einfach die Nummer unserer Zentrale.
Besten Dank und mit freundlichen Grüßen,
%Firmendaten%
Viele Grüße, Jens
Labels:
ausgeschiedene Mitarbeiter,
Exchange 2013,
OOF,
PowerShell
Montag, 6. Juli 2015
Auswertung Mailbox Auslastung
Hallo zusammen,
mit dem unten stehenden PowerShell Script lässt sich einfach die aktuelle Mailbox Auslastung gemessen an der Quota als Exel Export darstellen:
mit dem unten stehenden PowerShell Script lässt sich einfach die aktuelle Mailbox Auslastung gemessen an der Quota als Exel Export darstellen:
Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails
usermailbox | Where {$_.UseDatabaseQuotaDefaults -eq $false} | Select-Object
@{label="ProhibitSendQuota";expression={(get-mailbox
$_).ProhibitSendQuota.Value.ToMB()}},
@{label="TotalItemSize(MB)";expression={(Get-MailboxStatistics
$_).TotalItemSize.Value.ToMB()}} | Export-Csv "C:\Scripts\UserMailboxSizes.csv"
-NoTypeInformation -Delimiter ";"
Viele Grüße, Jens
Labels:
Exchange 2013,
PowerShell,
Scripts
Montag, 1. Dezember 2014
Kurz notiert: Export aller Mitglieder einer Verteilerliste inkl. Details
Hallo zusammen,
mit dem folgenden Powershell Script werden sämtliche Mitglieder einer Verteilerliste ausgelesen und mit den entsprechenden Details exportiert:
mit dem folgenden Powershell Script werden sämtliche Mitglieder einer Verteilerliste ausgelesen und mit den entsprechenden Details exportiert:
Get-DistributionGroupMember
%name% | foreach {Get-ADUser $_.samaccountname -properties *}
| select name, Description, title, telephoneNumber, mobile, mail,
streetaddress, postalcode, City | export-csv -path
c:\temp\export.csv -delimiter ";"
Viele Grüße, Jens
Labels:
Exchange 2013,
PowerShell
Donnerstag, 27. November 2014
Löschen der mail.que Datenbank
Hallo zusammen,
ab und an kommt die Situation in der die mail.que Datenbank gelöscht werden muss. Anbei ein How-To wie die Datenbank korrekt gelöscht und neu-erstellt wird:
ab und an kommt die Situation in der die mail.que Datenbank gelöscht werden muss. Anbei ein How-To wie die Datenbank korrekt gelöscht und neu-erstellt wird:
Queue in Maintenance
versetzen:
Set-ServerComponentState
%hostname% -Component hubtransport -state draining -Requester maintenance
Dienst stoppen:
Microsoft Exchange
Transport Dienst
Löschen Verzeichnis:
C:\Program
Files\Microsoft\Exchange Server\V15\TransportRoles\data\Queue
Dienst starten:
Microsoft Exchange
Transport Dienst
Queue wieder aktiv
nehmen:
Set-ServerComponentState
%hostname% -Component hubtransport -state active -requester maintenance
Viele Grüße, Jens
Labels:
Exchange 2013
Mittwoch, 5. November 2014
Kurz notiert: Ausgabe aller Raumpöstfächer die potentiell keine Besprechungsanfragen automatisch akzeptieren
Hallo zusammen,
Ausgabe
aller Räume, die potentiell keine Autoaccept hinterlegt haben:
get-mailbox
-resultsize unlimited -filter {recipienttypedetails -eq "roommailbox"
-or recipient
typedetails -eq
"equipmentmailbox"} | Get-CalendarProcessing | Where-Object
{$_.CalendarProcessing -ne "autoaccept"}
Viele Grüße, Jens
Labels:
Exchange 2013,
PowerShell
Mittwoch, 3. September 2014
Blackberry Express 5.04 Migration nach Exchange 2013
Hallo zusammen,
in den vergangenen Wochen hatte ich leider ein paar graue Haar mehr bekommen, da doch einiges an Zeit und Nerven für die Blackberry Migration auf Exchange 2013 draufgegangen sind.
Erstmal zu Ausgangslage, eine bestehende Exchange 2010 Umgebung wird nach Exchange 2013 migriert, inkl. Blackberry Benutzer.
Eigentlich ganz einfach, jedoch stellt es sich so dar, dass Exchange 2013 mit seinen Clients nicht mehr MAPI spricht sondern direkt über EWS. Die Konfiguration so wie ich es bisher gekannt hatte hinsichtlich Blackberry funktioniert also so nicht mehr, Blackberry muss zwingend für die EWS Nutzung konfiguriert werden und das obwohl die MAPI Collaboration 1.2.1 Installation nach wie vor installiert werden muss.
Eine gute Installationsanleitung ist hier zu finden, http://ukblog.im-mobility.com/installing-blackberry-enterprise-server-504-mr2-microsoft-exchange-2013
Wir hatten MR04 installliert, dennoch fehlen noch wichtige Updates die so nicht mehr zur Verfügung stehen, die im Anschluss der Installation jedoch noch hinzugefügt und registriert werden muss. Die Dateien sind hier zu finden, https://www.dropbox.com/s/3kwksere6jy262w/BESUPDATE.zip
Nun ja, wir hatten uns aufgrund der Masse der Postfächer auf Exchange 2010 darauf geeinigt, dass wir scheibchenweise migrieren. Vorab sei festgehalten, dass der BESADMIN entweder Exchange 2010 Benutzer oder Exchange 2013 Benutzer bedienen kann, Benutzer aus beiden Technologien kann der BES 5.04 Express Server nicht bedienen. Wir mussten somit einen zweiten BESADMIN namens BESADMIN2013 auf Exchange 2013 anlegen und sämtliche entsprechenden Berechtigungen vergeben. Anbei die Auflistung der Tasks, die hier durchgeführt werden mussten:
http://btsc.webapps.blackberry.com/btsc/viewdocument.do?externalId=KB33406&sliceId=2&cmd=displayKC&docType=kc&noCount=true&ViewedDocsListHelper=com.kanisa.apps.common.BaseViewedDocsListHelperImpl
http://btsc.webapps.blackberry.com/btsc/viewdocument.do?noCount=true&externalId=de-de-KB20157&cmd=displayKC&docType=kc
In der Registry unter HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem muss ein neuer String Value namens "RPCHTTPProxyMap_BES" erstellt werden, der Inhalt variiet natürlich von Installation zu Installation, wichtig ist jedoch die Schreibweise *=https://[FrontEndPoolFQDN]
der DWORD LDAPSearch muss zwingend auf "0" stehen, [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Research In Motion\BlackBerry Enterprise Server\Agents] - sonst funktioniert das Device ganz genau 15min bis Blackberry im AD via LDAP Informationen abruft, die Blackberry nicht abrufen kann.
Nachdem der ganze Aufwand betrieben worden war, funktionierte der Blackberry Dienst teilweise, d.h. der Mailfluss hatte einwandfrei funktioniert, jedoch Kalendereinträge vom Gerät aus und von Outlook aus brachten leider im Eventlog die folgenden Fehlermeldungen:
{test10@contoso.com} MAPIMailbox::MAPIMailbox - OpenMsgStore (0x8004011d) failed, MailboxDN=/o=Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=4344a0fe985348b7b5cd99c0abfa53c9-test1, ServerDN=/o=Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=44212887-eaa5-4500-b823-026e215e66b5@contoso.com/cn=Microsoft Private MDB
/o=Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=test@contoso.com} Synchronize() failed: ERR_FAIL, Tag=7642
Leider konnte mir der Blackberry Support auch nicht wirklich helfen, so dass ich so lange dran gesessen bin, bis ich endlich die Lösung hatte.
Wenn ein Benutzer unter Exchange 2010 angelegt wird, wir im AD parallel auch das Attribute legacyExchangeDN befüllt, dass dann ungefähr so aussieht,
/o=Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=test@contoso.comfcc
Wenn ein Benutzer unter Exchange 2013 angelegt wird, wir im AD parallel auch das Attribute legacyExchangeDN befüllt, dass dann ungefähr so aussieht,
/o=Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=8b24c44ab9804d2ea68e24c7be6d7895-test@
der Blackberry hatte ja auch immer genau das bemängelt, dass die Attribute nicht passen würden, allerdings ändert Exchange bei der Postfachmigration von Exchange 2010 nach Exchange 2010 nicht das Attribut legacyExchangeDN und genau das habe ich dann von Hand gemacht, anbei die Anleitung:
in den vergangenen Wochen hatte ich leider ein paar graue Haar mehr bekommen, da doch einiges an Zeit und Nerven für die Blackberry Migration auf Exchange 2013 draufgegangen sind.
Erstmal zu Ausgangslage, eine bestehende Exchange 2010 Umgebung wird nach Exchange 2013 migriert, inkl. Blackberry Benutzer.
Eigentlich ganz einfach, jedoch stellt es sich so dar, dass Exchange 2013 mit seinen Clients nicht mehr MAPI spricht sondern direkt über EWS. Die Konfiguration so wie ich es bisher gekannt hatte hinsichtlich Blackberry funktioniert also so nicht mehr, Blackberry muss zwingend für die EWS Nutzung konfiguriert werden und das obwohl die MAPI Collaboration 1.2.1 Installation nach wie vor installiert werden muss.
Eine gute Installationsanleitung ist hier zu finden, http://ukblog.im-mobility.com/installing-blackberry-enterprise-server-504-mr2-microsoft-exchange-2013
Wir hatten MR04 installliert, dennoch fehlen noch wichtige Updates die so nicht mehr zur Verfügung stehen, die im Anschluss der Installation jedoch noch hinzugefügt und registriert werden muss. Die Dateien sind hier zu finden, https://www.dropbox.com/s/3kwksere6jy262w/BESUPDATE.zip
Nun ja, wir hatten uns aufgrund der Masse der Postfächer auf Exchange 2010 darauf geeinigt, dass wir scheibchenweise migrieren. Vorab sei festgehalten, dass der BESADMIN entweder Exchange 2010 Benutzer oder Exchange 2013 Benutzer bedienen kann, Benutzer aus beiden Technologien kann der BES 5.04 Express Server nicht bedienen. Wir mussten somit einen zweiten BESADMIN namens BESADMIN2013 auf Exchange 2013 anlegen und sämtliche entsprechenden Berechtigungen vergeben. Anbei die Auflistung der Tasks, die hier durchgeführt werden mussten:
http://btsc.webapps.blackberry.com/btsc/viewdocument.do?externalId=KB33406&sliceId=2&cmd=displayKC&docType=kc&noCount=true&ViewedDocsListHelper=com.kanisa.apps.common.BaseViewedDocsListHelperImpl
http://btsc.webapps.blackberry.com/btsc/viewdocument.do?noCount=true&externalId=de-de-KB20157&cmd=displayKC&docType=kc
In der Registry unter HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem muss ein neuer String Value namens "RPCHTTPProxyMap_BES" erstellt werden, der Inhalt variiet natürlich von Installation zu Installation, wichtig ist jedoch die Schreibweise *=https://[FrontEndPoolFQDN]
der DWORD LDAPSearch muss zwingend auf "0" stehen, [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Research In Motion\BlackBerry Enterprise Server\Agents] - sonst funktioniert das Device ganz genau 15min bis Blackberry im AD via LDAP Informationen abruft, die Blackberry nicht abrufen kann.
Nachdem der ganze Aufwand betrieben worden war, funktionierte der Blackberry Dienst teilweise, d.h. der Mailfluss hatte einwandfrei funktioniert, jedoch Kalendereinträge vom Gerät aus und von Outlook aus brachten leider im Eventlog die folgenden Fehlermeldungen:
{test10@contoso.com} MAPIMailbox::MAPIMailbox - OpenMsgStore (0x8004011d) failed, MailboxDN=/o=Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=4344a0fe985348b7b5cd99c0abfa53c9-test1, ServerDN=/o=Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=44212887-eaa5-4500-b823-026e215e66b5@contoso.com/cn=Microsoft Private MDB
/o=Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=test@contoso.com} Synchronize() failed: ERR_FAIL, Tag=7642
Leider konnte mir der Blackberry Support auch nicht wirklich helfen, so dass ich so lange dran gesessen bin, bis ich endlich die Lösung hatte.
Wenn ein Benutzer unter Exchange 2010 angelegt wird, wir im AD parallel auch das Attribute legacyExchangeDN befüllt, dass dann ungefähr so aussieht,
/o=Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=test@contoso.comfcc
Wenn ein Benutzer unter Exchange 2013 angelegt wird, wir im AD parallel auch das Attribute legacyExchangeDN befüllt, dass dann ungefähr so aussieht,
/o=Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=8b24c44ab9804d2ea68e24c7be6d7895-test@
der Blackberry hatte ja auch immer genau das bemängelt, dass die Attribute nicht passen würden, allerdings ändert Exchange bei der Postfachmigration von Exchange 2010 nach Exchange 2010 nicht das Attribut legacyExchangeDN und genau das habe ich dann von Hand gemacht, anbei die Anleitung:
- Migration der Postfächer von Exchange 2010 nach Exchange 2013
- Migration der BES Benutzer via Blackberry Transporter
- Zwischensicherung des legacyExchangeDN für den jeweiligen Benutzer und Inhalt von diesem Attribut löschen
- In Exchange 2013 eine weitere Adresse, X500, dem Benutzer hinzufügen und die legacyExchangeDN Information hinzufügen (Hintergrund: wird dies nicht gemacht, können Benutzer auf Emails vor der Migration nicht mehr antworten und das wäre blöd)
- Kontrolle des Felds legacyExchangeDN in ADSIEDIT, hier müsste nun die Exchange 2013 Schreibweise hinterlegt sind
- Wechsel auf den Blackberry Server und unter C:\Program Files (x86)\Research In Motion\BlackBerry Enterprise Server\Utility in DOS "HandheldCleanup -u" ausführen
- Im Anschluss ca. 15min warten und den Blackberry auf Herz und Nieren testen, wer schneller testen möchte startet den Blackberry Controller Dienst neu
Viele Grüße, Jens
Labels:
Blackberry,
Blackberry 5,
Exchange 2010,
Exchange 2013
Dienstag, 1. Juli 2014
massenhafte Änderung Alias, UPN und SAMAccountName via CSV (bulk change Alias)
Hallo zusammen,
mit diesem Script habe ich eine massenhafte Änderung an den AD Attributen ALIAS und UPN mittels csv Datei durchgeführt:
Import-Csv -Delimiter ‘;’ -Path C:\scripts\file.csv | ForEach-Object{Set-Mailbox $_.name -Alias $_.SAMAccountnameNEW}
Import-Csv -Delimiter ‘;’ -Path C:\scripts\file.csv | ForEach-Object{Set-Mailbox $_.name -SAMAccountName $_.SAMAccountnameNEW}
Import-Csv -Delimiter ‘;’ -Path C:\scripts\file.csv | ForEach-Object{Set-Mailbox $_.name -UserPrincipalName $_.UPN}
mit diesem Script habe ich eine massenhafte Änderung an den AD Attributen ALIAS und UPN mittels csv Datei durchgeführt:
Import-Csv -Delimiter ‘;’ -Path C:\scripts\file.csv | ForEach-Object{Set-Mailbox $_.name -Alias $_.SAMAccountnameNEW}
Import-Csv -Delimiter ‘;’ -Path C:\scripts\file.csv | ForEach-Object{Set-Mailbox $_.name -SAMAccountName $_.SAMAccountnameNEW}
Import-Csv -Delimiter ‘;’ -Path C:\scripts\file.csv | ForEach-Object{Set-Mailbox $_.name -UserPrincipalName $_.UPN}
Im CSV Datei müssen die Spalten auch entsprechend = SAMAccountNameNEW benamst sein. Dieses Spalte ist meine Quelle für das Neusetzen des Alias.
Viele Grüße, Jens
Labels:
Exchange 2010,
Exchange 2013,
PowerShell,
Scripts
Dienstag, 17. September 2013
Exchange 2013: Planung der CAS Rolle
Hallo zusammen,
Unter Exchange 2013 gibt es bekanntermaßen nur noch zwei Serverrollen, CAS- und Mailbox Server Rolle. Ich habe mich in den letzten Tagen mit der Planung speziell um die CAS Serverrolle gekümmert und möchte gerne meine Erkenntnisse teilen.
Grundsätzlich hat sich doch sehr viel in der CAS Rolle geändert...
- Ein CAS 2013 bedient Clients nur noch ausschließlich via HTTPs bzw. RPC over https
- Der CAS Server ist lediglich "nur" noch für Authentifizierung, Proxing und Redirection zuständig
- Sogar das Rendering der Email Inhalte passieren mittlerweile auf dem Mailbox Server
- keine Affinitäten mehr, alle Verbindungen hin zum CAS Server sind zustandslos
- es gibt keine enge Bindung mehr zwischen den CAS und Mailbox Server, wie damals noch unter Exchange 2010
So viel macht der CAS Server also gar nicht mehr, die Hauptarbeit bzw. die Hauptlast passiert mittlerweile auf dem Mailbox Server.
Daher stellt sich die Frage ob die CAS Rolle überhaupt noch von der Mailbox Rolle getrennt werden sollte bzw. muss - mal unabhängig der Anzahl der Mailboxen welche gehostet werden, denn salopp gesagt macht der CAS Server fast nur noch Proxying.
Die Frage warum es überhaupt noch zwei Rollen, CAS und Mailbox Rollen gibt, konnte mir so richtig noch niemand beantworten, die CAS Rolle macht meines Erachtens ja eh nicht mehr wirklich viel, siehe oben.
Unter der Voraussetzung dass das Unternehmen eine hochverfügbare Lösung möchte, gibt es meiner Meinung nach zwei Möglichkeiten (es ist zu beachten, dass Mailbox Server, die in einer DAG Mitglied sind, nicht noch zusätzlich Mitglied eines Windows NLB sein können).
Beispiel-Firma, Mittelständische Firma, deren zwei Mailbox Server ausreichen:
- zwei Mailbox Server als DAG plus zwei CAS Server als Windows NLB oder
- zwei Mailbox Server als DAG plus zwei Hardware Loadbalancer (z.B. F5, oder Kemp etc.)
Ein Windows NLB vergleiche ich einfach mal ganz frech mit einem Layer-4 Hardware NLB - das Load Balancing basiert auf IP Adressen. Fällt ein CAS Server aus, wird nur noch die IP Adresse vom anderen CAS Server bedient.
Ein Layer-7 NLB kann hier deutlich mehr, switcht beispielsweise auf Dienst- und Serververfügbarkeit, bringt aber noch weitere Features wie SSL Offloading mit.
Die Frage, die sich hinsichtlich der CAS Server Planung stellt ist, ob die Features wie Dienst- und Serververfügbarkeit tatsächlich benötigt wird? Alternativ könnte an dieser Stelle auch SCOM als Dienst- und Serverüberwachung eingesetzt werden. Weiterhin stellt sich die Frage der Kosten, zum einen was kosten vier Windows Server (2 x DAG + 2 x Windows NLB als CAS Server) zum anderen was kosten zwei Windows Server und zwei Hardware NLB (Layer-4 oder Layer-7).
Natürlich sollten auch noch weitere, weichere Aspekte beachtet werden:
- ein Hardware NLB im HA-Modus bedeutet auch gleich erhöhte Beschaffungskosten
- ein Hardware NLB muss auch betrieben werden, d.h. entsprechendes Know-How muss aufgebaut oder zugekauft werden
- ein Windows NLB kann auch von einem Windows Administrator betreut und erstellt werden
- Ein Hardware NLB wird per se mehr Power und deutlich mehr Features haben, als ein Windows NLB (dies ist gerade in großen Umgebungen nicht gerade unwichtig)
Grundsätzlich muss sich ein Unternehmen fragen was es tatsächlich an Features haben möchte, wenn einfaches IP Routing reicht, ist ein Windows NLB vollständig ausreichend. Ist jedoch eine Dienst- und Serverüberwachung und ein proaktives Umschwenken der Endpunkte oder erweiterte Features und viel Peformance wichtig, sollte überlebt werden ob Layer-7 Hardware NLB zum Einsatz kommen sollten.
Viele Grüße, Jens
Unter Exchange 2013 gibt es bekanntermaßen nur noch zwei Serverrollen, CAS- und Mailbox Server Rolle. Ich habe mich in den letzten Tagen mit der Planung speziell um die CAS Serverrolle gekümmert und möchte gerne meine Erkenntnisse teilen.
Grundsätzlich hat sich doch sehr viel in der CAS Rolle geändert...
- Ein CAS 2013 bedient Clients nur noch ausschließlich via HTTPs bzw. RPC over https
- Der CAS Server ist lediglich "nur" noch für Authentifizierung, Proxing und Redirection zuständig
- Sogar das Rendering der Email Inhalte passieren mittlerweile auf dem Mailbox Server
- keine Affinitäten mehr, alle Verbindungen hin zum CAS Server sind zustandslos
- es gibt keine enge Bindung mehr zwischen den CAS und Mailbox Server, wie damals noch unter Exchange 2010
So viel macht der CAS Server also gar nicht mehr, die Hauptarbeit bzw. die Hauptlast passiert mittlerweile auf dem Mailbox Server.
Daher stellt sich die Frage ob die CAS Rolle überhaupt noch von der Mailbox Rolle getrennt werden sollte bzw. muss - mal unabhängig der Anzahl der Mailboxen welche gehostet werden, denn salopp gesagt macht der CAS Server fast nur noch Proxying.
Die Frage warum es überhaupt noch zwei Rollen, CAS und Mailbox Rollen gibt, konnte mir so richtig noch niemand beantworten, die CAS Rolle macht meines Erachtens ja eh nicht mehr wirklich viel, siehe oben.
Unter der Voraussetzung dass das Unternehmen eine hochverfügbare Lösung möchte, gibt es meiner Meinung nach zwei Möglichkeiten (es ist zu beachten, dass Mailbox Server, die in einer DAG Mitglied sind, nicht noch zusätzlich Mitglied eines Windows NLB sein können).
Beispiel-Firma, Mittelständische Firma, deren zwei Mailbox Server ausreichen:
- zwei Mailbox Server als DAG plus zwei CAS Server als Windows NLB oder
- zwei Mailbox Server als DAG plus zwei Hardware Loadbalancer (z.B. F5, oder Kemp etc.)
Ein Windows NLB vergleiche ich einfach mal ganz frech mit einem Layer-4 Hardware NLB - das Load Balancing basiert auf IP Adressen. Fällt ein CAS Server aus, wird nur noch die IP Adresse vom anderen CAS Server bedient.
Ein Layer-7 NLB kann hier deutlich mehr, switcht beispielsweise auf Dienst- und Serververfügbarkeit, bringt aber noch weitere Features wie SSL Offloading mit.
Die Frage, die sich hinsichtlich der CAS Server Planung stellt ist, ob die Features wie Dienst- und Serververfügbarkeit tatsächlich benötigt wird? Alternativ könnte an dieser Stelle auch SCOM als Dienst- und Serverüberwachung eingesetzt werden. Weiterhin stellt sich die Frage der Kosten, zum einen was kosten vier Windows Server (2 x DAG + 2 x Windows NLB als CAS Server) zum anderen was kosten zwei Windows Server und zwei Hardware NLB (Layer-4 oder Layer-7).
Natürlich sollten auch noch weitere, weichere Aspekte beachtet werden:
- ein Hardware NLB im HA-Modus bedeutet auch gleich erhöhte Beschaffungskosten
- ein Hardware NLB muss auch betrieben werden, d.h. entsprechendes Know-How muss aufgebaut oder zugekauft werden
- ein Windows NLB kann auch von einem Windows Administrator betreut und erstellt werden
- Ein Hardware NLB wird per se mehr Power und deutlich mehr Features haben, als ein Windows NLB (dies ist gerade in großen Umgebungen nicht gerade unwichtig)
Grundsätzlich muss sich ein Unternehmen fragen was es tatsächlich an Features haben möchte, wenn einfaches IP Routing reicht, ist ein Windows NLB vollständig ausreichend. Ist jedoch eine Dienst- und Serverüberwachung und ein proaktives Umschwenken der Endpunkte oder erweiterte Features und viel Peformance wichtig, sollte überlebt werden ob Layer-7 Hardware NLB zum Einsatz kommen sollten.
Viele Grüße, Jens
Labels:
CAS,
Exchange 2013
Abonnieren
Posts (Atom)