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

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

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





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

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:



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

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

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


Viele Grüße, Jens

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:

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

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%

Viele Grüße, Jens

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:

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

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:

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

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:

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

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

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:


  • 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


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}


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

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