tobinator_1991

@mikro

ja und den ganzen Server auch schon 

@Sunny61

Danke dir 

Zitat

Get-inboxrule -mailbox "" -includehidden |fl

Zitat

Sagt das Messagetrack denn das sie mails "stored" wurde?

das steht sowas hier:

ok danke

da befindet sich eine Junk E-Mail Rule:

Im Junk Ordner ist aber auch nichts 

Hallo @mikro

dort stehen merkwürdigerweise auch beide als Empfänger drin.

Mit Postfachregel meinst du eine Regel im Outlook?

Hallo,

ich habe leider wieder einmal ein seltsames Problem:

Es handelt sich um einen Exchange 2019 neuste CU installiert.

Dort wurde im Nachrichtenfluss eine Mailweiterleitung eingerichtet, so das die Mails per BCC an den Stellvertreter gehen.

Diese Regel wurde nun erst deaktiviert und dann gelöscht.

Nun ist es so das die Mails trotzdem noch beim Stellvertreter ankommen und beim eigentlichen Empfänger gar nichts mehr ankommt.

Unter "Get-TransportRule *" taucht die Regel auch nicht mehr auf, der Exchange wurde mittlerweile sogar neu gestartet.

vor 6 Minuten schrieb NorbertFe:

Üblicherweise greift sich der Exchange aber nur DCs aus einer Site. Oder ist bei dir die Site/IP Zuordnung nicht gegeben bzw. Geografisch übergreifend? Das was du da jetzt konfiguriert hast, fällt dir im Allgemeinen spätestens beim Austausch dieses DCs auf die Füße. Ich rate davon ab, das statisch zu konfigurieren.

ja wie gesagt es gibt 2 Standorte die geografisch getrennt sind.

Den DC werden wir so schnell nicht austauschen.

Hallo,

nach langer Zeit melde ich mal mit dem Endergebnis.

Es lag letztendlich daran das in der Umgebung 2 DC´s gibt, die an verschiedenen Standorten stehen und über eine Site to Site Tunnel verbunden sind.

Und genau da lag der Haase begraben, nachdem nun ein DC static bzw. der 2. ausgeschlossen wurde, ist das ECP und auch die Performance allgemein im Outlook deutlich besser.

Hier noch die Befehle:

Abfrage:

Get-ExchangeServer -identity Exchangename -status | fl *current*

Einen DC ausschließen:

set-exchangeserver -Identity "Exchangename" -StaticExcludedDomainControllers "FQDN DC"

DC Static einstellen:

set-exchangeserver -Identity "Exchangename" -StaticDomainControllers "FQDN DC" -StaticGlobalCatalogs "FQDN DC" -StaticConfigDomainController "FQDN DC"

erneute Abfrage:

Get-ExchangeServer -identity Exchangename -status | fl *static*

moin @andrew

melde dich doch via RDP auf dem Exchange an und erzeuge den CSR über die IIS

Moin,

was sagt denn der Befehl : 

Get-MailboxDatabaseCopyStatus *

auf deinem Exchange?

Moin zusammen,

ich muss mal wieder eine doofe Frage stellen und auf eure Kompetenz hoffen 

auf einem Exchange 2013 mit dem CU 23 sollen die Audit Logs funktionieren, soweit so gut.

Hab also geschaut was Get-AdminAuditLogConfig | fl *log* anzeigt:

AdminAuditLogEnabled         : True
LogLevel                     : Verbose
TestCmdletLoggingEnabled     : False
AdminAuditLogCmdlets         : {*}
AdminAuditLogParameters      : {*}
AdminAuditLogExcludedCmdlets : {}
AdminAuditLogAgeLimit        : 90.00:00:00

sieht also ja meiner Meinung nach ganz gut aus, wenn ich jetzt allerdings übers ECP die Logs aufrufen will, wird mir nichts angezeigt.

Dem Admin habe ich auch in die Gruppe "Compliance Management" hinzugefügt.

Und auch über PowerShell Befehl werden keine Ergebnisse angezeigt. 

Hallo @Nobbyaushb

ja sowas hab ich mir schon gedacht aber du sagtest ja das es bei dir schon gefunzt hat.

Hast du denn noch mehr eingestellt außer die GPO´s ?

Hey Ho Zusammen,

ich habe in einer Windows Terminalserver Umgebung mit 2 Servern und Broker folgendes Problem:

USB Webcam an Windows 10 PC angeschlossen, funktioniert dort auch einwandfrei, in der RDP ist die Cam auch sichtbar und ausgewählt zum durchleiten.

Wenn sich der Benutzer anmeldet funktioniert dann Grundsätzlich erst einmal nur das Mikrofon der Cam, um die Kamera zum laufen zu bekommen muss dann das sie über Remote FX dazuschalten.

Dann funktioniert aber nur die Webcam und das Mikro nicht mehr.

Gruppenrichtlinien sind folgende eingestellt:

Ich hoffe jemand von euch hat noch eine coole Idee.

@NorbertFE

Nein, bzw. keine Ahnung was die Ursache ist, deswegen hab ich ja hier nachgefragt. 

Aber ich werde dann wohl zu mindestens die DB auf eine extra Partition schaufeln und euch dann berichten ob es was gebracht hat. 

Moin erstmal an alle,

das ist ja alles schön und gut das ihr mit extra Partitionen oder Mount Points arbeitet.

Ich kann nur sagen wir/ich die Exchange Server bis jetzt immer so installiert hatten, auch Exchange 2019 und das der erste Server ist der diese Probleme hat.

BTW der Exchange hat nun die 128 GB und nutzt davon sage und schreibe 14% aus 

Zitat

Wie lange hast du denn gewartet? Das muss sich ja auch erstmal replizieren. Exchange cached ja auch hier und da einiges etwas länger.

ja ok sehe ich auch ein ^^ aber auch jetzt nach über 16 Stunden ist noch keine Besserung in Sicht 

@testperson

danke für die Hinweise, ich hab tatsächlich noch eine alte DC Leiche gefunden und auch gleich beseitig, nur hat das leider keine Besserung gebracht.

Beim PowerShell Befehl "Get-DomainController" löst er auch alles korrekt auf.

Und wenn ich die Berechtigungen über PowerShell setzte geht das auch ohne Verzögerungen, es ist wirklich einzig und allein im Admin Center über Browser lahm ars***ig und ja ich habe auch schon andere Browser getestet ;)

@LukiHoer

Vorher war der Server ohne Antivirenschutz unterwegs aber ich werde auch das Avast mal testweise deinstallieren, schaden kann es ja nicht.

Die Exchange Installation + die DB und die Logs liegen zusammen auf einer Partition.

IPv6 ist ebenfalls eingeschaltet.

Hallo LukiHoer,

ja es ist Avast Antivirus Pro Plus installiert, das Problem bestand aber auch schon vor der Antiviren Installation.

zu deinen Fragen:

1. es sind insgesamt 37 Benutzerpostfächer, 5 Ressourcen Postfächer und 5 Freigebende Postfächer auf dem Server die Datenbank ist momentan gute 40 GB groß.

2. der Server hat 8 Kerne a 3.20 GHz und ich bin auch schon dabei ihm mehr RAM zu geben, wobei ich sagen musss das es nicht wirklich einen Unterschied macht.

3. die Exchange Installation befindet sich auf einer eigenen Partion und die virtuellen Festplatten wiederum auf einem SAS SSD Raid 5

HMM, 

andere Exchange 2019 sind identisch oder sogar noch mit weniger CPU und/oder RAM ausgestattet und dort habe ich diese Probleme nicht.

Aber Danke für deine Hinweise.

Hallo und schönen Urlaub, 

es handelt sich um eine Hyper-V VM mit 8 CPU´s und 22 GB RAM.

Die Auslastung ist auch nicht sonderlich hoch, CPU dümpelt bei 3% rum und der RAM ist zu 70% belegt.

Das Seltsame ist ja das es nur bei der Postfachstellvertretung so lange lädt.

Hallo,

Leider habe ich ein Problem mit langen Ladezeiten wenn zum Beispiel bei einem Benutzer Postfach die Postfachstellvertrung geändert werden soll (dauert hier teilweise 2-3 Minuten bis man Einstellungen vornehmen kann).

Es handelt sich hierbei um einen Exchange 2019 mit dem CU 12, das CU wurde auch erst letzte Woche installiert, in der Hoffnung das es das Problem löst aber Pustekuchen. 

Ich hoffe jemand von euch hat eine Idee.

Hallo mwiederkehr,

Danke für deine schnelle Antwort.

Ja, es handelt sich um einen IIS und der Zugriff vom RP aus auf die interne URL des EWS funktioniert auch.

Aber hier mal die Detaillierte Fehlermeldung:

Hallo Zusammen,

ich möchte für ein Projekt den Zugriff auf das EWS von extern (WAN) möglich machen.

Das Ganze ist so konfiguriert das ein Reverseproxy in einer DMZ vorgeschaltet ist und dort ein Rewrite eingerichtet ist. Der OWA Zugriff funktioniert auch, nur halt beim EWS Zugriff erscheint die folgende Meldung:

Vielleicht hat ja von euch ja noch jemand einen Tipp, achso es handelt sich um eine Exchange 2016 CU 22.

Danke schonmal für jegliche Hilfe.

Das Problem ist das die VPN Verbindung nicht über das normale Internet aufgebaut wird, sondern über ein Landesnetzt verwirklicht wird.

Somit ist dort auch keine DNS Auflösung möglich und es wird auf die Standalone Lösung hinauslaufen.

Danke auf jeden Fall für eure Ideen.

Moin,

bei unseren Kunden werden alle Mails als Sam maskiert.

Es werden folgende Blacklist Server genutzt:

blackholes.mail-abuse.org

sbl.spamhaus.org

bl.spamcop.net

cbl.abuseat.org

ix.dnsbl.manitu.net

dnsbl-1.uceprotect.net

dnsbl-2.uceprotect.net

und es war natürlich der letzte Server (dnsbl-2.uceprotect.net) in der Liste der die Probleme verursacht hat.

@cj_berlin

Genau beim VPN liegt das Problem, das ist ein VPN über ein gesondertes Netz, deswegen wird es auf den extra Host hinauslaufen der dann Standaolone ist.