Kategorien
Exchange Office Tipps & Tricks

Outlook-Suche im Exchange-Postfach für ältere Elemente schlägt fehl

Hat man den Cache-Modus in Outlook für ein Exchange-Postfach auf einen bestimmten Zeitraum begrenzt, muss die Suche für frühere Ergebnisse auf dem Server fortgesetzt werden. Dazu wird man meist in der untersten Zeile der Suchergebnisse dann aufgefordert. Fälschlicherweise kann es dann hier zu der Meldung kommen, dass der Server offline oder nicht erreichbar ist.

Server unavailable. 12 months of results shown.

Fehlermeldung auf Englisch

Ob der Server tatsächlich ein Problem hat, können Sie bei Exchange-Postfächern sehr einfach über die „Outlook Web App“ prüfen. Wenn hier die Suche erfolgt, hat der Server normalerweise keine Probleme. Kommt es auch hier zu Fehlern, genügt es in den meisten Fällen, den Datenbank-Index neu aufzubauen. Das wollen wir aber in dem Fall nicht behandeln, wir gehen also davon aus, dass die Suche in OWA funktioniert.

Die Lösung, um die augenscheinliche Falschmeldung in Outlook zu beheben, ist mehr als seltsam. Bitte befolgen Sie folgende Schritte:

  • Klicken Sie per Rechtsklick links in der Ordnerübersicht auf Ihre Email-Adresse (also in der obersten Ebene)
  • Klicken Sie auf „Datendateieigenschaften….“
  • Klicken Sie auf „Ordnergröße…“
  • Wechseln Sie auf den Reiter „Serverdaten“. Hier müsste der Aufbau ein paar Sekunden benötigen.
  • Das war’s, sie können die Fenster wieder in umgekehrter Reihenfolge schließen.

Versuchen Sie im Anschluss die Suche erneut. Nun sollte die Schaltfläche wieder verfügbar sein, die es Ihnen ermöglicht, ältere Ergebnisse auf dem Server zu suchen.

Hat es Ihnen geholfen? Wir freuen uns auf Ihr Feedback!

Exchange-Postfächer in jeder Edition und Größe können Sie übrigens bei uns ganz unkompliziert buchen, schauen Sie mal vorbei unter: https://cloud4you.biz/cloud/kommunikation/hosted-exchange

Kategorien
CRM Office Windows

Diese Website funktioniert in Microsoft Edge besser – Dynamics 365 for Outlook

Problembeschreibung

Unter bestimmten Umständen ist möglich, dass das Outlook-Addin „Dynamics 365 for Outlook“ nach Installation und Einrichtung immer wieder einmal (oder spätestens bei Dynamics-Aktionen, wie dem Nachverfolgen von Mails) zunächst einen Internet Explorer-Tab mit dem Titel „Diese Website funktioniert in Microsoft Edge besser“ öffnet und anschließend den eigentlich innerhalb des Addins sichtbaren Inhalt in einem Edge-Browser öffnet.

Lösung

Vorausgesetzt, dass der Internet Explorer eh nicht mehr benötigt wird, können wir diesen einfach deinstallieren und das Problem somit umgehen. Wechseln Sie hierzu mit einem Administratorkonto in der Einstellungs-App zum Punkt „Apps & Features“ (einfach in der Suche eingeben) und klicken dann auf „Optionale Features“. Hier sollte der Internet Explorer 11 gelistet sein, den Sie markieren und dann mit Klick auf „Deinstallieren“ vom PC verbannen. Ein anschließender Neustart ist notwendig.

Kategorien
Exchange Server Windows

Exchange-Server schließt IMAP- oder POP3-Verbindungen sofort wieder (Aktualisiert)

Szenario:
IMAP- oder POP3-Verbindungen mittels Email-Clients funktionieren einfach nicht mehr, die Verbindungen werden vom Server sofort wieder geschlossen. Bei der weiteren Recherche stellt sich raus, das man mittels Telnet auf dem Exchange-Server selbst unter Verwendung von 127.0.0.1 die Dienste noch abfragen kann. Führt man jedoch Telnet von einer anderen Maschine remote aus, so wird die Verbindung sofort wieder getrennt. Die jeweiligen Dienste sind jedoch auf dem Server aktiv.

Problem:
Wenn oben beschriebenes teilweise oder gar komplett auf Sie zutrifft, liegt es vermutlich daran, dass die Proxy-Komponente des jeweiligen Dienstes inaktiv ist. Prüfen können Sie das, indem Sie eine PowerShell-Eingabeaufforderung starten, und folgende Zeile eingeben:

Get-ServerComponentState -Identity [Servername]

Folgendes könnten Sie als Ausgabe zurückbekommen:

Server Component State
-------
[...]
[Servername] ImapProxy Inactive
[...]
[Servername] PopProxy Active
[...]

Die Ausgabe ist selbstverständlich nicht eingefärbt, dies dient nur der Veranschaulichung.

Behebung:
Sollte nun eine oder gar mehrere Komponenten als Inactive angezeigt werden, müssen wir selbige wieder aktivieren. Dies erfolgt durch folgenden PowerShell-Befehl:

Set-ServerComponentState -Identity [Servername] -Component [Komponente] -Requester HealthAPI -State Active

In unserem Beispiel würde der Befehl wie folgt aussehen:

Set-ServerComponentState -Identity SRV-EXCHANGE -Component ImapProxy -Requester HealthAPI -State Active

Damit sollten die Verbindungen wieder möglich sein. Eventuell müssen die jeweiligen Dienste noch neugestartet werden.

Ursache:
Auch nach weiterer Recherche konnte nicht herausgefunden werden, was den Server dazu trieb, die Komponente auf inaktiv zu setzen. Zwar sieht man im Eventlog, dass er es tat, aber keinen tieferen Grund. Sollte sich hier noch etwas ergeben, werde ich den Blogeintrag entsprechend erweitern.

Nachtrag:
Scheinbar führt irgendein Softwarefehler beim Exchange Server 2013 regelmäßig zum Absturz solcher Komponenten. Aus diesem Grund wurde ein Script angefertigt, das dieses Problem automatisiert behebt, falls es existent sein sollte. Dieses ist auch TaskScheduler-kompatibel, kann hier also ganz einfach eingesetzt und alle 5 Minuten gestartet werden:

#Ausführung des Remoting-Scripts, der Pfad muss bei anderen Server-Versionen abgeändert werden
. "C:\Program Files\Microsoft\Exchange Server\V15\bin\RemoteExchange.ps1" | Out-NULL
Connect-ExchangeServer -auto | Out-NULL

$LocalHost = $env:computername

Write-Host "Checking IMAP4: " -NoNewline
$ImapState = (Get-ServerComponentState -Identity $LocalHost -Component ImapProxy).State
if($ImapState -eq "Active")
{
   Write-Host "$ImapState" -ForegroundColor Green
}
else
{
   Write-Host "$ImapState" -ForegroundColor Red
   Write-Host "Enabling Component ImapProxy: " -NoNewline
   Set-ServerComponentState -Identity $LocalHost -Component ImapProxy -Requester HealthAPI -State Active
   Write-Host "done." -ForegroundColor Green
   Write-Host "Restarting IMAP4 Backend Service: " -NoNewline
   Restart-Service "MSExchangeIMAP4BE"
   Write-Host "done." -ForegroundColor Green
   Write-Host "Restarting IMAP4 Service: " -NoNewline
   Restart-Service "MSExchangeImap4"
   Write-Host "done." -ForegroundColor Green
}
Write-Host ""

Write-Host "Checking POP3: " -NoNewline
$PopState = (Get-ServerComponentState -Identity $LocalHost -Component PopProxy).State
if($PopState -eq "Active")
{
   Write-Host "$PopState" -ForegroundColor Green
}
else
{
   Write-Host "$PopState" -ForegroundColor Red
   Write-Host "Enabling Component PopProxy: " -NoNewline
   Set-ServerComponentState -Identity $LocalHost -Component PopProxy -Requester HealthAPI -State Active
   Write-Host "done." -ForegroundColor Green
   Write-Host "Restarting POP3 Backend Service: " -NoNewline
   Restart-Service "MSExchangePOP3BE"
   Write-Host "done." -ForegroundColor Green
   Write-Host "Restarting POP3 Service: " -NoNewline
   Restart-Service "MSExchangePop3"
   Write-Host "done." -ForegroundColor Green
}
Write-Host ""

Zur besseren Veranschaulichung der Ausgabe besitzt dieses Script einige Zeilen, die im Taskscheduler natürlich unnötig sind. Diese habe ich violett markiert.

Kategorien
Clients Office Windows

Reparieren Ihrer Persönlichen Ordner-Datei (.pst oder .ost) in Outlook

Merkmal


Outlook stürzt unerwartet ab und zeigt folgende Meldung:

AppName: Outlook.exe
AppVer: 14.0.4760.1000
ModName: Kernelbase.dll
ModVer: 6.1.7600.16385
Offset: 0003194b

Ursache


Diese Problem tritt bei dem Verfall der Outlook Dateien (.pst oder .ost) auf.

Lösung


Um dieses Problem zu lösen, nutzen Sie das „Tool zum Reparieren von Microsoft Office“ um die Outlook Dateien zu reparieren.

1. Schließen Sie Outlook

2. Gehen Sie zu folgendem  Ordner:  C:\Programme\Microsoft Office\Office[Version]

3. Doppelklick Scanpst.exe

Unbenannt0

4. Klicken Sie im Dialogfenster „Tool zum Reparieren von Microsoft Office“  Durchsuchen.

Unbenannt

5. Wählen Sie Ihr Outlook Dateien (.pst oder .ost) aus, dann klicken sie Öffnen.

6. Klicken Sie im Dialogfenster „Tool zum Reparieren von Microsoft Office“  Start.

  • Bei Windows 7, Windows 10 und Windows Vista ist der Default Ort für die Outlook Dateien in Outlook 2010:

(.pst file)

C:\Users\username\Documents\Outlook-Dateien

Unbenannt1

(.ost file)

C:\Users\username\AppData\Local\Microsoft\Outlook

Unbenannt

Notiz: Um diesen Pfad für die .ost Datei zu sehen, müssen Sie die versteckten Dateien und Ordner sichtbar machen mit dn folgenden Schritten

1. Öffnen Sie die Ordneroptionen, indem Sie auf die Schaltfläche StartSchaltfläche  klicken, auf Systemsteuerung klicken, auf Darstellung und Anpassung klicken und dann auf Ordneroptionen klicken.

2. Klicken Sie auf die Registerkarte Ansicht.

3. Klicken Sie unter Erweiterte Einstellungen auf Ausgeblendete Dateien, Ordner und Laufwerke anzeigen, und klicken Sie anschließend auf OK.

7. Nachdem Ihre Datei gescannt wurde, überprüfen sie bitte die angezeigte Information des Dialogfensters „Tool zum Reparieren von Microsoft Office“ .

Wichtig:  Setzen Sie den Hacken bei Sicherungskopie von geprüfter Datei vor Reparatur, damit das „Tool zum Reparieren von Microsoft Office“ eine Backup Datei erstellt bevor es den Prozess der Reparatur startet.

Unbenannt2

8. Klicken Sie Reparieren.

9. Nachdem der Reparaturprozess abgeschlossen ist, klicken Sie OK.

Unbenannt3

Wenn der Reparaturprozess fertiggestellt ist, werden Sie folgende drei Dateien finden:

 File  Description
 filename.bak Das ist die ursprüngliche nicht reparierte Backup-Datei. Wenn sie auf diese Datei in Outlook zurückgreifen wollen, benennen Sie die .bak Datei um zu einer .pst Datei.
 filename.log  Dieses log file dokumentiert den Reparatur Prozess aufgeführt durch „Tool zum Reparieren von Microsoft Office“.
 filename.pst oder filename.ost  Dies ist die reparierte Outlook Datenbank Datei.

Unbenannt4

Kategorien
Hyper-V Server VMM Windows

Häufige VMM-Migrationsfehler und Lösungsansätze

Migrationen über den VMM (vorallem zwischen Clustern) können oft zu merkwürdigen Fehlern führen, die sich nicht immer logisch erklären lassen. Aus diesem Grund habe ich hier mal die mir widerfahrenen Probleme aufgelistet, gemeinsam mit Lösungsansätzen.

  • Es konnte keine verfügbare Verbindung mit dem ausgewählten VM-Netzwerk gefunden werden.
  • Es wurde keine Verbindung zu „[VM-Netzwerkname]“ mit ausreichenden Ressourcen gefunden.

Das ist ein seltsamer Bug. Wenn wir jedoch im VMM aus dem Menüband die PowerShell-Konsole öffnen, und darüber die Migration durchführen, so funktioniert es ohne Probleme – Vorausgesetzt natürlich, dass das Netzwerk tatsächlich an dem Zielhost anliegt. Hierzu gehen wir folgendermaßen vor:

$VMHost = Get-VMHost -ComputerName "[Ziel-Host]"
$VM = Get-VM -Name "[Zu migrierdende VM]"
$VMPath = $VMhost.Vmpaths[[Index des korrekten Speicherorts]]
Move-VM -VM $VM -VMHost $VMHost -Path $VMPath

Move-VM : Die VM „XXXXX“ kann aufgrund von Inkompatibilitätsproblemen nicht zu Host „XXXXXXX“ migriert
werden. The virtual machine ‚XXXXX‘ is using processor-specific features not supported on physical computer ‚XXXX‘.
To allow for migration of this virtual machine to physical computers with different processors, modify the virtual
machine settings to limit the processor features used by the virtual machine. (Virtual machine ID
xxxxxxxx-xxxxxx-xxxxxxx-xxxxxxxx) (Fehler-ID: 23008, Detaillierter Fehler: )

Beheben Sie das Inkompatibilitätsproblem, und wiederholen Sie den Migrationsvorgang.

Hier ist die VM auf einem Host erstellt worden, dessen Prozessorgeneration neuer ist, als der Zielhost der Migration. Behoben werden kann das Ganze, in dem man die VM herunterfährt, den Haken unter „Hardware“ -> „Prozessor“ -> „Migration zu einem virtuellen Maschinenhost mit abweichender Prozessorversion zulassen“ setzt und dann die Migration erneut durchführt. Nach der Migration sollte die Maschine erneut heruntergefahren werden, um diesen Haken wieder zu entfernen.


Move-VM : Der Hostvorgang auf dem Server „XXXXXXXXX“ kann von VMM aufgrund des folgenden Fehlers nicht
abgeschlossen werden: Virtual machine migration operation for ‚XXXXXXXX‘ failed at migration source ‚XXXXXXX‘. (Virtual
machine ID xxxxxxxx-xxxxxx-xxxxxx-xxxxxxxxx)
Virtual machine migration for ‚XXXXXXX‘ failed because configuration data root cannot be changed for a clustered
virtual machine. (Virtual machine ID xxxxx-xxxxxxxxx-xxxxxxxx-xxxxxx) (Fehler-ID: 12700, Detaillierter Fehler:
Unknown error (0x8005))

Beheben Sie das Problem auf dem Host, und wiederholen Sie dann den Vorgang.

Dieser Fehler kann behoben werden, indem man im Anschluss an den Fehler auf „Reparieren“ -> „Ignorieren“ klickt, und anschließend die Migration erneut triggert. Notfalls über PowerShell. 

Kategorien
Exchange

Event ID 1677 – Unified Messaging kann nicht für einen Benutzer aktiviert werden

Wenn sich ein bestimmter User nicht für Unified Messaging aktivieren lässt und Sie folgende Fehlermeldung bekommen, dann haben wir hier die Lösung:

Error occurred during execution of UM Mailbox Cmdlet for user „/o=XXX/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=929fc9a62f634c198ea7f630a2593615-XXX“, Error: „Microsoft.Exchange.UM.UMCommon.UmUserException: Access to Active Directory failed.
at Microsoft.Exchange.UM.UMCommon.UmPasswordManager.CommitPasswordAndUpdateChecksum()
at Microsoft.Exchange.UM.UMCommon.UmPasswordManager.SetPassword(EncryptedBuffer digits, Boolean isExpired, LockOutResetMode lockoutResetMode)
at Microsoft.Exchange.UM.UMCommon.Utils.SetUserPassword(MailboxSession mbxSession, UMMailboxPolicy umMbxPolicy, ADUser adUser, String pin, Boolean expired, Boolean lockedOut)
at Microsoft.Exchange.UM.UMCommon.CrossServerMailboxAccess.XSOUMUserMailboxAccessor.<>c__DisplayClassa.<SaveUMPin>b__9()
at Microsoft.Exchange.UM.UMCommon.CrossServerMailboxAccess.XSOUMUserMailboxAccessor.ExecuteXSOOperation(Action function)“

Ursache: Diese typisch nichtssagende Meldung bekommen wir dann, wenn das Postfach aus irgendeinem Grund nicht in den (in der Address Book Policy festgelegten) Adresslisten eingetragen ist.

Behebung: Im ersten Schritt sollte man sich die Address Book Policy anschauen und feststellen, in welche Adresslisten das Postfach gehören sollte. Anschließend schauen wir uns das Postfach an und überprüfen, in welchen Listen es auch eingetragen ist. Im dritten Schritt überprüfen wir die Aufnahmeregeln der Listen, in denen das Postfach nicht ist aber sein sollte und führen dementsprechende Anpassungen durch.

Kategorien
Server Windows

Windows Server 2012 R2 – Installationsfehler: Windows cannot find the Microsoft Software License Terms

Nach der Auswahl der Server-Version (Standard oder DTC) kann es vorkommen, dass man mit solchen Fehlern konfrontiert wird:

Windows cannot find the Microsoft Software License Terms. Make sure the installation sources are valid and restart the installation.

Keine Sorge, Ihr Installationsmedium ist nicht beschädigt. Dieser Fehler taucht auch meines Wissens nach nur bei virtuellen Maschinen auf.

Die Lösung ist einfach: Die Maschine hat zu wenig Arbeitsspeicher beim Systemstart. Erhöhen Sie bei dynamischem RAM einfach den beim Start verfügbaren und ansonsten den insgesamt bereitgestellten Arbeitsspeicher. Damit sollte das Problem behoben sein.