magicpeter

Umgebung: Exchange 2019 CU11 in einer Hyper-V Umgebung als VM Ich musste für einen Benutzer ein neues E-Mail Konto anlegen. Das habe ich gemacht und habe dann die E-Mail Alias des alten Kontos auf das neue Konto eingetragen, vorher habe ich bei dem alten Konto die Alices mit einem alt versehen. Also: Altes Konto War: benutzer1@domain.de Ist jetzt: benutzer1ALT@domain.de Neues Konto War: benutzer1NEU@domain.de Ist jetzt: benutzer1@domain.de Externe E-Mails kommen für den benutzer1@domain.de auf dem neuen Konto an. Auch wenn ich intern vom Administrator@domain.de eine E-Mail an benutzer1@domain.de sende kommt die an. Nur die E-Mail von seinen Kollegen kommen immer noch auf dem alten Konto an, obwohl dort der Alias gar nicht mehr eingetragen ist. Kann es sein das der ALIAS intern gar nicht für die Zustellung genommen wird sondern etwas anderes was ich. noch nicht umgestellt habe? Oder hängt das mit den internen Adressbüchern von Outlook zusammen? Weis einer eine Lösung dazu? Danke euch...

Ja, ist schon klar. Danke Dir für die Info.

Die neuesten Updates für Office 2013 (KB5002105, KB5002101) und dem Exchange 2019 CU11 sind alle installiert. Das Problem in der Such tritt aber immer noch auf.

Habe ich probiert, hat aber auch auf Dauer nichts genutzt... Danke trotzdem...

Ja, schade das die nicht mal eine vernünftige Suchfunktion hinbekommen ;) Ich habe meinen eigenen Beitrag dazu aufgemacht. Vielleicht kann ja jemand helfen.

Korrigiert, Outlook 2013 Was meinst du denn mit "Suche klappt mit Exchange 2019 nicht gut - noch nie." Da muss es doch eine Lösung geben!

Gibt es hier schon eine Lösung? Habe die gleichen Probleme mit Exchange 2019 CU11 und Outlook 2019 und Outlook 2013. Die Suche arbeitet nicht zuverlässig.

Was ist denn das für Update und für welches Betriebssystem? Was genau macht das Update? https://www.borncity.com/blog/2022/01/07/dezember-2021-sicherheitsupdate-kb5008212-killt-die-outlook-suche/ OK, ich habe mir das mal angeschaut was das macht, aber da der Fehler ja Windows 10 übergreifend ist scheint das nicht die Lösung zu sein. Trotzdem Danke... Ich teste das gerade aber trotzdem einmal an einem Windes 10 PC.

Ich habe jetzt noch ein paar weitergeleitete E-Mails gesucht und diese wurde auch gefunden. Es hat also doch nichts mir der Weiterleitung an sich zu tun. Aber es werden viele E-Mails einfach nicht gefunden. Ich denke es ist ein Exchange Problem. Ist das schon mal jemandem passiert?

Moin, ich habe ein sehr sehr komisches Problem mit der Outlooksuche bei einem Benutzer. Umgebung: Windows 2019 Std mit Exchange 2019 CU11 in einer VM auf einem Hyper-V Der Exchange wurde aus einem Exchange 2013 migriert. 25 Benutzer / Konten alle haben kein Problem bis auf ein Benutzer. Fehler: Der Benutzer nutzt Outlook 2013 in einer RDP-Sitzung und Outlook 2019 auf seinem Notebook. Der Fehler trifft bei allen Outlook gleich auf. Die Outlooksuche funktioniert nicht zuverlässig. Die E-Mails sind dann können aber nicht alle gefunden werden. Es scheint so als ob nur die weitergeleiteten E-Mails nicht mehr in der Outlooksuche erscheinen. Laut Benutzer tritt der Fehler erst seit dem neuen Exchange 2019 Server auf. Überprüfung: Einige E-Mails die weitergeleitet wurden erscheinen tatsächlich nicht mehr in der Suche. Aber ein direkter Test mit einer gerade weitergeleiteten E-Mail wird immer noch in der Suche gefunden. Bereits durchgeführt: E-Mail Konto auf Get-MailboxStatistics Benutzer | fl BigFunnel* 45 BigFunnelNoIndexCount 19 BigFunnelCorruptedCount Schlussfolgerungen: Die Exchange 2019 Big Funnel-Architektur und die interne Postfachindizierung machen Indizierungsprobleme viel einfacher zu beheben und relativ schnell. Die aktuelle und einzige Möglichkeit, bisher Indizierungsprobleme mit Postfächern in Exchange 2019 zu beheben, besteht nur darin, sie in eine andere Datenbank zu verschieben. Habe das Postfach in eine andere Datenbank verschoben. Der Fehler war dann erst mal behoben ist dann aber wieder aufgetreten. Weitere Vorgehensweise: Neues E-Mail Postfach für den Benutzer erstellt und die Daten rüber kopiert Der Fehler war dann erst mal behoben ist dann aber wieder aufgetreten. Jetzt weiss ich leider nicht mehr weiter. Hat jemand eine Idee?

Moin, ich nutze diese Scanner. PowerShell Scanner https://github.com/sp4ir/incidentresponse/blob/35a2faae8512884bcd753f0de3fa1adc6ec326ed/Get-Log4shellVuln.ps1 log4jscan.ps1 Windows Scanner exe-Datei https://github.com/logpresso/CVE-2021-44228-Scanner Wenn der Fehler auftritt: "VCRUNTIME 140.dll nicht vorhanden" Lösung: https://answers.microsoft.com/de-de/windows/forum/all/wie-kann-ich-vcruntime-140dll-runterladen/efd828b6-011a-4205-a03a-d5392500de30 Logpresso CVE-2021-44228 Vulnerability Scanner 1.5.0 (2021-12-15) Weitere Scanning Tools findest du hier: https://github.com/NCSC-NL/log4shell/tree/main/scanning

Danke, habe ich sofort durchgeführt... Hat jemand schon einen guten Scanner gefunden den man auf seinen Windows Server einmal laufen lassen kann um zu schauen ob der Spaß auf dem Server installiert ist. Scanner https://github.com/logpresso/CVE-2021-44228-Scanner

Stimmt, wenn man den DNS der Hauptstelle als Primären DNS in der Außenstelle gesetzt hat, dann kann man dich das sparen. Ich habe die Hosts-Einträge wieder entfernt. Danke

Das ist aber interessant. Wie hättest du das Problem denn gelöst?

Problem gelöst. Für die Erreichbarkeit der Domänen sind folgende Schritte notwendig: 1. Eintragung der Servernamen und der IP-Adresse in der hosts-Datei der PCs 2. Den DNS der Hauptstelle als Primären DNS und die Firewall / DNS als Sekundären DNS bei den PC´s eintragen. Durch das Setzen des DNS in der Netzwerkeinstellung für ipv4 kann sich der Rechner mit der Domäne verbinden und auch den AD Benutzer anmelden. Hier greifen jetzt auch die geänderten Passwörter.

Ja, der DNS der Hauptstelle ist bei den PC´s eingetragen. Share klappen auch, aber da war es dann auch.. ;)

Ja, das stimmt die auch... ;) Aber kein Server oder dergleichen....

Im Lager steht leider nichts davon. Nur eine Firewall.

DNS und AD DC Warum fragst du?

Die Kommunikation funktioniert es werden bereits die Shares vom DC im Lager genutzt. Nur halt nicht die Passwortänderung des Lager-PC klappt nicht. Ahja auf der Firewall sind alle Ports TCP/UDP im VPN-Tunnel testweise freigeben.

Moin, ich habe 2 Locations (Hauptstelle mit DC und Lager nur PCs) Hauptstelle: DC, Firewall mit VPN-Tunnel Netzwerk: 192.168.30.x Lager: Pc´s, Firewall mit VPN-Tunnel Netzwerk: 192.168.130.x Jetzt mussten bei allen Benutzern die Passwörter geändert werden. Kein Problem und schnell gemacht im AD. Leider sind die PC´s im Lager nicht mehr an das AD angebunden. Sie wurden in der Hauptstelle konfiguriert und im AD angebunden und gingen dann in das Lager. Das Lager hat ein anderes Netzwerk und leider kann der DC von dort per VPN nicht erreicht werden. Also an Pingen des AD geht schon, nslookup geht nicht. Wie kann ich jetzt die Passworte an den Lager PC´s ändern oder noch besser wie kann ich das Lahmer richtig an den DC anbinden. Danke euch...

Moin, danke für euren Input. Ergebnis: 1. Bios Update hat auf dem einen Server das Problem komplett gelöst 2. Auf dem anderen Server ist ein DimmModul defekt (korregiertbar defekt) wird jetzt ausgetauscht Die PowerSettings schau ich mir noch mal an djmaker

Nein noch nicht, das wäre jetzt mein nächster Step mittels mdsched.exe

Moin, seit ein paar Wochen stürzen 2 meiner Supermicroserver immer mal wieder mit deinem Fehler "driver irql not less or equal " ab. Bei dem Backupserver kann ich den Fehler sogar reproduzieren. Wenn ich mittels Veeam Backup & Replication eine Replication der VM´s starte dann steigt der Server mit dieser Meldung aus. Der Produktivserver zeigt den Fehler nur sporadisch. Ich habe jetzt als erstes das Bios auf die neueste Version gebracht. Hat jemand eine Idee voran das liegen könnte. Ausstattung der beiden Server: Windows 2019 Std. Supermicro Mainboard X10 DRi-LN4+ CPU: 2 x E5-2620v4 (16 Kerne, 2.1 GHz, 32 Logische Prozessoren) Raidcontroller OnBoard Intel Raipstorage Intel® C612 Chipsatz System-Speicher: 250 GB SSD - Raid 1 Performance-Speicher: 1 TB SSD - Raid 1 Performance2-Speicher: 4 TB SSD - Raid 1 SAN-Speicher: 8 TB HDD - Raid 1 Hauptspeicher: 128 GB (24x DIMM slots) Netzwerkkarten: 4 x 1 GB, 2 x 10 GB, 1 x IPMI Port Redundante Stromversorgung: 2 x 800W

Ich mache das auch immer so und setze alles auf einer neuen VM. Ein InPlace Upgrade ist für mich eine zu große Fehlerquelle die man besser vermeidet. Aber Danke für euren Input, damit hat isch meine Vermutung ja auch bestätigt.