FiMA-KB

Nach dem verbinden einer zurvor gelöschten Mailbox ist der Login in OWA und Oultook nicht möglich.

in OWA erhält der Benutzer den Fehler: Serverfehler in der Anwendung /owa

Lösung:

https://support.microsoft.com/en-us/topic/you-cannot-access-a-mailbox-for-several-hours-after-you-disconnect-and-then-reconnect-the-mailbox-in-an-exchange-server-2010-sp2-environment-ead687f3-25ee-516c-1441-ff748d3837f6

Details zum Befehl:

https://docs.microsoft.com/en-us/powershell/module/exchange/clean-mailboxdatabase?view=exchange-ps

Wenn die Mailbox in der Exchange GAL „hidden“ gesetzt ist, wird sie nicht über die AutoMap Funktion automatisch einem Outlook Konto hinzufügt. Ausserdem kann sie nicht direkt über den Dialog Mailbox Hinzufügen“ eingerichtet werden, da Oultook die Mailbox nicht finden kann.

Lösung:

Hierzu muss der legacyExchangeDN der Mailbox verwendet werden.

Dieser kann relativ einfach ausgelsen werden:

ADSI Edit –> OUT=meineDomäne –>  die entsprechende OU suchen –>  die Mailbox finden

–> Properties Attribute Editor den Eintrag legacyExchangeDN suchen

Der Eintrag sollte so ähnlich ausschauen:

/o=meineDomäne/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=e5a3d4fa2888423699341cab22b8dd1f-checks

–> Alternativ kann natürlich einfach das Attribut “hidden“ auf der Mailbox für ein paar Minuten entfernet werden. 

Zum prüfen welche Policy dem Benutzer zugeordet ist, am einfachsten im ECP prüfen:

–> Empfänger –> Postfächer –>  Benutzer wählen

Nun in der Shell die Einstellungen der Policy prüfen.

Get-MobileDeviceMailboxPolicy -Identity:"BLABLA"

Nun suchen wir den Eintrag der Policy den wir anpassen wollen.

In unserem Bsp. die AllowStorageCard Policy.

Nun Ändern wir den Wert von False auf True

Set-MobileDeviceMailboxPolicy -Identity:" BLABLA " -AllowStorageCard:$true

zum prüfen nochmals mit “Get-MobileDeviceMailboxPolicy -Identity "BLABLA” die Policy prüfen.

Fertig

Beschreibung:

Eine Applikation soll über den bestehenden Exchange 2007 / 2010 E-Mails an Kunden versenden können.

Lösung:

Das Versenden von E-Mails einer Dritt-Anwendung über den bestehenden Exchange Server wird mit dem Fehler „550 5.7.1 Unable to relay“  quittiert.

Um dies ohne Probleme bewerkstelligen zu können, sind folgende Schritte notwendig:

1. Dem Exchange eine zusätzliche IP Adresse zuweisen (in unserem Fall 192.168.1.11)

2. Einen zusätzlichen Empfangs Connector auf dem Exchange einrichten:

Auf einem Englischen System:

New-ReceiveConnector -Name Relay -usage Custom -Bindings '192.168.1.11:25' –fqdn FQDN_Mail_Server -RemoteIPRanges IP_des_Applikations_Servers -server MeinExchangeServerName -permissiongroups AnonymousUsers

Auf einem DeutschenSystem:

New-ReceiveConnector -Name Relay -usage Custom -Bindings '192.168.1.11:25' –fqdn FQDN_Mail_Server -RemoteIPRanges IP_des_Applikations_Servers -server MeinExchangeServerName -permissiongroups AnonymousUsers

3. Dem Connector nun die Berechtiung für das relying geben

Auf einem Englischen System:

Get-ReceiveConnector AllowRelay | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient"

Auf einem Deutschen System:

Get-ReceiveConnector AllowRelay | Add-ADPermission -User "NT-AUTORITÄT\ANONYMOUS-ANMELDUNG" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient"

4. Nun den Applikations-Server so konfigurieren, dass die zusätzliche IP Adresse des Exchange Servers (in unserm Fall 192.168.1.11) als SMTP Server verwendet wird.

   Sollten weitere Server das Recht für das relaying benötigen, dann diese am einfachsten über den ESM erfassen…..

Fehlerbeschreibung:

Nach Sie eine Request-Anforderung gemacht haben, kann es vorkommen, dass das req-File wie folgt aussieht

Beispiel:
????A ?»?????????????[??¯???????……

anstelle

—–BEGIN NEW CERTIFICATE REQUEST—–
MIIESjCCAzICAQAwODELMAkGA1UEBhMCQ0gxDTALBgNVBAoMBEZJTUExGjAYBgNV
BAMMEWZpbWFzcnYwMS5maW1hLmxpMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEA41tbcNnyeXTxf2nic/2vqygWeSnjItPSXnxqQI0NrbBsoEhqvSDPP+dv
…
—–END NEW CERTIFICATE REQUEST—–
 

Ursache:

In Exchange 2010 wurde der Befehl mit dem Parameter verwendet "-BinaryEncoded:$True".

Lösung:

Es gibt verschiedene Lösungsansätze.

Variante 1:
Request-File via EMS und den Parameter  "-BinaryEncoded:$False" erstellen.

Variante 2:
Request-File mit dem nachfolgenden Befehl von Binary in Base64 umwandeln:
C:\>certutil -encode cert.req certb64.req

Fehler:
Folgender Eventlog-Eintrag erscheint unregelämssig.

Ursache:
Ein Client versucht auf den Port 443 auf HTTP zuzugreiffen (z..b. http://server-ip:443)

Lösung:

• regedit
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
• EventLogging auf 0 setzen

Nach einem Reboot des Servers wird der "Microsoft Exchange Information Store" nicht mehr gestartet.

Der Event Log meldet den Fehler:

7024 – Der Dienst "Microsoft Exchange Information Store" wurde mit folgendem dienstspezifischem Fehler beendet: %%-2147221213.

Lösung: Kontrolliert die Uhrzeit des Server, synct mit dem PDC, prüft gegebenfalls die Uhrzeit mit dem ESX Host System.

Weitere Infos zu diesem Registry-Schlüssel findet man bei Microsoft unter
http://technet.microsoft.com/en-us/library/cc960646.aspx

Erstellt ein zusätzliches POP3 Konto. Wenn gewünscht sicherstellen dass eine Kopie der E-Mails auf dem Server gelassen werden.

Es wird automatisch eine PST für das neue POP3 Konto im Benutzerprofil Ordner angelegt. (C:\%userprofile%\Documents\Outlook-Dateien)

Nun einfach in den Kontoeinstellungen unter dem Punkt:

"Vom ausgewählten Konto werden neue Nachrichten an den folgenden Speicherort übermittelt"

den Button "Ordner wechseln" klicken und den Posteingang im Exchange Konto auswählen.

–> nun dann in der Ordnerliste das POP3 Konto mit rechtsklick geschlossen werden.

Diese Einstellung gilt auch für "Gesendete Elemente"

Beim Start der Exchange-Verwaltungskonsole kommt ein Initialisierungsfehler und wird nicht vollständig gestartet.

"…Das Systemlastenkontingent von 1000 Anforderungen pro 2 Sekunden…"

Fehlerbehebung:

WWW-Publishingdienst neu starten.