Archiv für die Kategorie » Exchange & Lync «

16 | 12 | 2016

Quest Migration Manager for Exchange: Nun auch nach Exchange 2010 mit MAgE!

Geschrieben von um 19:36 Uhr

Still und heimlich hat Quest, noch unter der Marke „DELL Software“, ein Update-Paket für den Migration Manager 8.13 rausgebracht. Neben den üblichen Bugfixes gibt es eine tolle Neuerung: Der „neue“ Migration Agent fpr Exchhange (MAgE) kann nun auch nach Exchange 2010 migrieren. Das ermöglicht gleich zwei Dinge, die bis dato nicht gingen:

  • Migration von Exchange 2013 nach 2010 (der „alte“ Mail Source Agent konnte und kann nicht mit Exchange 2013 sprechen)
  • Migration in bestehende Postfächer (rettet mit gerade ziemlich den Abend, der alte Agent musste sie selber neu anlegen, bevor er bereit war, per MAPI da hinein zu schreiben)

Drei Dinge sind beim Einsatz des MAgE zu beachten:

  • Die SQL-Datenbank wird richtig groß (1.036 Bytes pro synchronisiertes Element) – das ist generell so bei MAgE, nicht nur mit Exchange 2010
  • Wenn die Synchronisierung eines Postfachs mit dem alten MSA/MTA begonnen wurde, kann man nicht auf MAgE umstellen, ohne dass es massenhaft Dubletten gibt
  • Man muss zwingend CPUU ab 5.6.4 einsetzen, um Profile zu migrieren.

Danke Quest, das war lange fällig! Und ja, es wird noch nach Exchange 2010 migriert 🙂

Tags » , , , , «

+

16 | 12 | 2016

Erstes Treffen der EXUSG Berlin – das war schön :-)

Geschrieben von um 19:25 Uhr

Gestern haben wir uns bei der dama.go am Spittelmarkt zum ersten Mal getroffen. Der Abend war ein voller erfolg – geballtes Know-How in einem Raum, inspirierende Vorträge, tolle Gespräche und auch ein bißchen Nostalgie 🙂

Mein Vorschlag, Termine für die Treffen in 2017 bereits jetzt festzulegen, wurde zumindest nicht abgelehnt. Die Termine stehen unter http://exusg.de/veranstaltungen/terminplanung-2017/ zur Abstimmung nach dem Motto „wer was dagegen hat, möge sich jetzt äußern oder für immer schweigen“.

Ich freue mich schon auf das nächste Treffen, voraussichtlich im Februar.

Tags » , , , , , , «

+

06 | 11 | 2016

Exchange User Group Berlin geht an den Start!

Geschrieben von um 22:40 Uhr

http://exusg.de : Die Exchange User Group Berlin ist nun offiziell gegründet und als Microsoft Technical Community anerkannt. Das erste Treffen ist für den 15.12.2016 geplant. Der genaue Ort und das Programm werden in den nächsten Tagen veröffentlicht.

Wir wollen über konkrete Herausforderungen im Betrieb von Exchange, Lync, OOS usw. – aber auch um die Zukunft der Kommunikation im Unternehmen sprechen.

Alle Neuigkeiten der neuen Gruppe findet ihr auf http://exusg.de.

Also: Bitte mitmachen und fleißig weitersagen!

Tags » , , , «

+

24 | 10 | 2016

Exchange 2013 CU14 und 2016 CU3: Probleme mit der Suche

Geschrieben von um 23:42 Uhr

Ein Wort der Warnung: Die vor kurzem erschienenen CUs von Exchange 2013 und 2016 haben anscheinend gravierende Probleme bei der Indizierung.

Ein Beispiel hier: https://social.technet.microsoft.com/Forums/en-US/a05ea439-8d7a-4d83-a8c4-fcc7e78904bf/exchnage-2013-cu-14-database-indexing-failed?forum=exchangesvradmin

In Kürze: Der Indexdienst verweigert für einige (in manchen Fällen auch für alle) Datenbanken die Indizierung. Die einzige Lösung ist die Installation eines zusätzlichen Servers mit einem älteren Patch-Stand und Verschiebung der Postfächer dorthin.

Wer also gerade sein Update plant, sollte lieber etwas warten und v2 oder halt ein nächstes CU installieren.

Tags » , , , , , «

+

04 | 10 | 2016

Ablaufdatum für moderierte Nachrichten festlegen

Geschrieben von um 23:04 Uhr

Wenn man in Exchange Moderation, z.B. für eine Gruppe, einschaltet, greift ein Expiration-Mechanismus, der nach einer gewissen Zeitspanne die Mails (mit Benachrichtigung) verwirft, falls bis dahin keiner der Moderatoren sie freigegeben oder abgelehnt hat. Das Ganze wird durch den MFA gesteuert, indem die Nachrichten erst mal in einer Arbitration Mailbox liegen, bis sie freigegeben werden. Der MFA schaut gemäß seinem Zeitplan nach, ob sie nicht veraltet sind, und verarbeitet sie dann entsprechend.

Um herauszufinden, wie lange man Zeit hat, eine Mail zu genehmigen, schaut man entweder in die Doku oder in seine Exchange-Installation. Und siehe da – der Blick in die Installation lohnt sich, denn die Doku und die Realität widersprechen sich. Unter https://technet.microsoft.com/en-us/library/dd297936(v=exchg.150).aspx liest man:

If the approver either deletes or ignores the approval message, an expiration message is sent to the sender. This happens after two days in Exchange Online, and after five days in Exchange Server 2013. (In Exchange Server 2013, you can change this time period).

In Wirklichkeit aber sind es on premise auch zwei Tage. Und diese sieht man ganz deutlich hier:

Get-RetentionPolicyTag -IncludeSystemTags | where { $_.SystemTag } | ft Name, AgeLimitForRetention

moderatedEine Nachricht, die am Freitagabend abgesendet wird, nachdem der Approver bereits nach Hause gegangen ist, hat also keine Chance!

Global kann man das Limit (z.B. auf die dokumentierten 5 Tage) erhöhen mit

Get-RetentionPolicyTag moderatedrecipients | Set-RetentionPolicyTag -AgeLimitForRetention 5

Wünscht man sich hingegen mehr Ganularität, muss man anfangen, mit zusätzlichen Arbitration Mailboxen zu arbeiten. Denen weist man dann eine entsprechend präparierte Retention Policy zu:

New-RetentionPolicyTag "LongExpiry" -SystemTag $true -AgeLimitForRetention 10 -RetentionEnabled $true -RetentionAction DeleteAndAllowRecovery
New-RetentionPolicy "LongExpiryPolicy" -RetentionPolicyTagLinks LongExpiry,AutoGroup,AsyncOperationNotification
New-Mailbox -Arbitration "LongExpiryMFA" -UserPrincipalName longexpirymfa@domain.de -RetentionPolicy LongExpiryPolicy

Anschließend muss natürlich die Arbitration Mailbox-Verknüpfung bei den gewünschten Rezipienten angepasst werden:

Get-DistributionGroup "All Employees" | Set-DistributionGroup -ArbitrationMailbox LongExpiryMFA

Tags » , , , , , , «

+

29 | 05 | 2016

PowerShell Hack: Statischen Domain Controller in Lync setzen

Geschrieben von um 23:15 Uhr

Keine Ahnung, wo die Anforderung wirklich her kommt, aber scheinbar gibt es die: In Lync (Skype for Business) einen oder mehrere fixe(n) DC für Benutzer-Synchronisierung konfigurieren. Da denkt man, kein Problem – das Cmdlet Set-CsUserReplicatorConfiguration hat ja einen Parameter DomainControllerList (siehe https://technet.microsoft.com/de-de/library/gg398540.aspx). Und denkt man dann, man würde hergehen und mit so etwas Erfolg haben:

Set-CsUserReplicatorConfiguration-Identity global -DomainControllerList @{Add='dc-one.my.domain.name'}

Doch weit gefehlt. Es kommt eine Typenkonvertierungs-Fehlermeldung:

Set-CsUserReplicatorConfiguration : Unable to cast object of type 'System.String' to type 'Microsoft.Rtc.Management.WritableConfig.Settings.UserReplicator.DomainControllerType'.
At line:1 char:1
+ Set-CsUserReplicatorConfiguration -Identity global -DomainControllerList @{Add=" ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [Set-CsUserReplicatorConfiguration], InvalidCastException
+ FullyQualifiedErrorId : System.InvalidCastException,Microsoft.Rtc.Management.Xds.SetUserReplicatorConfigurationCmdlet 

Nach einigem Grübeln gibt es die folgende Lösung für das Phänomen:

[Microsoft.Rtc.Management.WritableConfig.Settings.UserReplicator.DomainControllerType]$newdc = 'DC=my,DC=domain,DC=name'
$newdc.DomainControllerFQDN.Add('dc-one.my.domain.name')
$newdc.DomainControllerFQDN.Add('dc-two.my.domain.name')

Set-CsUserReplicatorConfiguration -Identity global -DomainControllerList @{Add=$newdc}

Nicht umsonst sagt Microsoft im oben verlinkten TechNet-Artikel:

Normalerweise kann der Benutzerreplikationsdienst Domänencontroller über die Windows-API „DsGetDcName“ identifizieren. Deshalb sollten Sie sich von Microsoft-Supportmitarbeitern beraten lassen, bevor Sie Domänencontroller manuell über diesen Parameter auswählen.

 

 

Tags » , , , «

+

25 | 05 | 2016

PowerShell Hack: Namen von Standardordnern in einem Exchange-Postfach

Geschrieben von um 17:39 Uhr

Manchmal muss man den lokalisierten Namen eines Standardordners (Inbox/Posteingang, Calendar/Kalender) usw. wissen, z.B. um mit *-MailboxFolderPermission dort Berechtigungen zu lesen oder zu setzen. Schnell und einfach kann man den Namen des Ordners feststellen mit

$calendar_folder = "$($mailbox):\$((Get-MailboxFolderStatistics $mailbox | where {$_.FolderType -eq 'Calendar'} | Select-Object -First 1).Name)"

$contacts_folder = "$($mailbox):\$((Get-MailboxFolderStatistics $mailbox | where {$_.FolderType -eq 'Contacts'} | Select-Object -First 1).Name)"

$inbox_folder = "$($mailbox):\$((Get-MailboxFolderStatistics $mailbox | where {$_.FolderType -eq 'Inbox'} | Select-Object -First 1).Name)"

Das funktioniert auch für ‚Sent Items‘ und ‚Deleted Items‘.

Tags » , , «

+

16 | 01 | 2016

Exchange: Kein Drag & Drop in Outlook – Ursache und Lösung

Geschrieben von um 0:00 Uhr

Nach einer Migration von Exchange 2010 auf Exchange 2013, die mit dem DELL Migration Manager for Exchange durchgeführt wurde, haben sich Nutzer beschwert, dass sie in Outlook keine Elemente per Drag & Drop in einen bestimmten Unterordner des Posteingangs und dessen Unterordner verschieben können. Da dieser Ordner der e-Mail-Archivierung im Unternehmen diente, betraf es alle Nutzer und war auch beliebig reproduzierbar. Eine weitere Untersuchung ergab, dass:

  • auch keine neuen Elemente in diesen Ordnern erstellt werden können,
  • das Verschieben per Rechtsklick –> Verschieben nach… funktioniert
  • in OWA auch Drag & Drop funktioniert
  • nur diese archivierungsbezogenen Ordner betroffen sind
  • es keine Unterschiede in den Zugriffsrechten zwischen funktionierenden und nicht funktionierenden Ordnern gibt.

Der Blick auf die MAPI-Properties der Ordner per MFCMAPI ergab folgendes Bild, das auch schnell zur Lösung führte:

  • in Exchange 2010 fehlt in den betroffenen Ordner die Property PR_CONTAINER_CLASS komplett
  • in Exchange 2013 haben die „defekten“ Ordner zwar diese Property, sie ist aber leer
  • in beiden Systemen haben die Default-Ordner und solche, die von Hand angelegt wurden (und wo Drag & Drop ausnahmslos funktioniert) die Property auf den korrekten Wert „IPF.Note“ gesetzt.

Der Versuch, manuell den Wert für PR_CONTAINER_CLASS auf IPF.Note in einem der „defekten“ Ordner zu setzen, brachte sofort die Linderung für den betreffenden Ordner. Da 1.200 Postfächer betroffen waren und die Unterordner-Strukturen überall unterschiedlich waren, habe ich das folgende Skript geschrieben, das die Angelegenheit global heilt:


$ex_ps_url = "http://EXCHANGE01/PowerShell/"
$ex_ews_path = “C:\Program Files\Microsoft\Exchange\Web Services\2.2\Microsoft.Exchange.WebServices.dll”
$log_file = "C:\temp\folder_class.log"
$res_file = "C:\temp\folder_class_set.log"

################################################################
#                 F U N C T I O N S
################################################################

Function WriteLog ($text, $uname) {
    if ($uname) {
        $xname = $uname + " | "
    } else {
        $xname = "######## | "
    }
    ((Get-Date -Format "dd.MM.yyyy hh:mm:ss").ToString() + " | " + $xname + $text) | Out-File -FilePath $log_file -Append
}

Function DoSubFolder ($folder, $path) {
    $folderView = new-object Microsoft.Exchange.WebServices.Data.FolderView(2147483647)
    $subfolders = $folder.FindFolders($folderView)
    if (!$path) { $path = $folder.DisplayName }
    foreach ($subfolder in $subfolders) {
        if ($subfolder.SearchParameters -ne $null) {
            # If it's a search folder, just skip it
            continue
        }
        $xpath = $path + "\" + $subfolder.DisplayName
        if (!($subfolder.folderClass)) {
            WriteLog ($xpath + " has no FolderClass set! Setting FolderClass to IPF.Note") $name
            ($name + " --> " + $xpath) | Out-File -FilePath $res_file -Append
            $subfolder.FolderClass = "IPF.Note"
            $subfolder.Update()
        } else {
            WriteLog ($xpath + " has FolderClass property of " + $subfolder.folderClass) $name
        }
        DoSubfolder $subfolder $xpath
    }
}

################################################################
#                         S T A R T
################################################################

Add-Type -Path $ex_ews_path
$ExchangeVersion = [Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2013
$Service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService($ExchangeVersion)

if (!(Get-Command "Get-ExchangeServer" -EA SilentlyContinue)) {
    WriteLog "Connecting to Exchange using $ex_ps_url"
    $ex_rem_session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri $ex_ps_url -Authentication Kerberos -EA SilentlyContinue -WA SilentlyContinue
    Import-PSSession $ex_rem_session -DisableNameChecking -EA SilentlyContinue -WA SilentlyContinue > $null
} else {
    WriteLog "Exchange environment already established"
}

$mbxs = @(Get-Mailbox -ResultSize Unlimited)
$nmbx = $mbxs.Count
WriteLog ($nmbx.ToString() + " mailboxes to process...")
$i = 0
foreach ($mbx in $mbxs) {
    $mail = $mbx.PrimarySMTPAddress
    $name = $mbx.SamAccountName
    $i++
    WriteLog "Processing mailbox $i of $nmbx ..." $name
    Write-Host ([math]::Round((($i / $nmbx) * 100),2)).ToString() " % $name"
    if ($mail) {
        WriteLog "Primary email address is: $mail" $name
        $Service.AutodiscoverUrl($mail,{$true})
        WriteLog ("Autodiscover URL: " + $Service.Url.OriginalString) $name
        $Service.ImpersonatedUserId = new-object Microsoft.Exchange.WebServices.Data.ImpersonatedUserId([Microsoft.Exchange.WebServices.Data.ConnectingIdType]::SmtpAddress, $mail)
        $fldInbox = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($Service, [Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Inbox)
        WriteLog ("Default Inbox folder: " + $fldInbox.DisplayName + " contains " + $fldInbox.TotalCount + " item(s)") $name
        DoSubFolder $fldInbox
    } else {
        WriteLog "Primary email address NOT SPECIFIED! Skipping mailbox..." $name
    }
}

if ($ex_rem_session) {
    Remove-PSSession $ex_rem_session -EA SilentlyContinue -WA SilentlyContinue
}

Damit dieser Code ausgeführt werden kann, benötigt das ausführende User-Account mindestens das Recht, alle Postfächer aufzulisten und deren SAMAccountName und PrimarySMTPAddress zu lesen (also: Mitgliedschaft in irgendeiner Exchange-Administratorrolle) sowie die ApplicationImpersonation-Berechtigung. Da alle Postfächer zu bearbeiten waren, war das Zuweisen dieser Berechtigung denkbar einfach:

New-ManagementRoleAssignment –Name "adminuser_may_impersonate" –Role ApplicationImpersonation –User: "DOMAIN\adminuser"

Noch ein wenig Hinergrund: Die Unterordner im Quellsystem wurden mit einem Skript angelegt, welches EWS Managed API 2.0 und ebenfalls ApplicationImpersonation nutzt. Dabei wurde denkbar einfach vorgegangen:

$oFolder = new-object Microsoft.Exchange.WebServices.Data.Folder($exchService)
$oFolder.DisplayName = "Mailarchiv"
$oFolder.Save([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::inbox)

Die FolderClass-Eigenschaft wurde nicht explizit gesetzt. Offensichtlich erstellt dabei EWS Managed API auch keine Property PR_CONTAINER_CLASS. DELL Migrator hingegen erstellt diese Property offenbar standardmäßig, bestückt sie jedoch strikt mit dem Wert, den sie im Quellsystem hatte. In diesem Fall also: mit keinem.

Happy troubleshooting!

Tags » «

+

27 | 07 | 2015

MCSE: Messaging

Geschrieben von um 14:37 Uhr

Ab heute (und zumindest für die nächsten drei Jahre) bin ich nun stolzer Träger des MCSE:Messaging 🙂

Tags » «

+

12 | 02 | 2015

DELL-Zertifizierung

Geschrieben von um 13:05 Uhr

Ich bin nun als Implementation Consultant für die DELL Software (ehem. QUEST) – Produkte

  • Migrator for Active Directory und
  • Migrator for Exchange

zertifiziert. Der Kurs und die Prüfungen, beides geleitet von Phil Welsh, haben großen Spaß gemacht – aber ich kann niemandem empfehlen, beide Prüfungen am selben Tag zu machen 😉

Tags » , , , , , , «

+