magicpeter

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.

Moin, hat jemand von euch schon mal ein In-Place-Upgrade - von Windows Server 2012 R2 auf Windows Server 2019 gemacht? Ich weis das das möglich ist, aber gemacht habe ich das noch nie. Wie sind euere Erfahrungen damit? Ich hätte eine 2012 R2 Hype-V Umgebung mit einem Windows server 2012 R2 DC. Ist das echt praktikabel? Ich setze eigentlich immer einen neuen DC auf und synchronisiere den mit den alten DC und dann ist gut.

Hat funktioniert und ja es gibt nur diesen einen Produktkey. Set-ExchangeServer SERVEREX1 -ProductKey AAAA-BBBB-CCCC-DDDD-EEEE Ahja, der Exchange 2019 läuft 180 Tage als Testserver.

Weil ich mir nicht sicher war. Danke für deinen Kommentar.

Soll das heißen es gibt nur diesen einen Produktkey für Exchange 2019 als Volumenlizenz? Dann werde ich Exchange mal mit der Exchange-Verwaltungsshell aktivieren.

Danke dir für deinen Kommentar. Schön zuhören. Ich hatte es mir schon fast gedacht.

Moin, ich migriere gerade einen Exchange 2013 aus dem Jahre 2013 auf einen Exchange 2019. Die Postfachdatenbank ist 190 GB groß und es dauert sehr lange . Ist aber bekannt. Ich habe jetzt einmal ein paar Konten getestet (E-Mail senden und empfangen) während der Übertrag und es scheint alles normal zu funktionieren. Kann man der Migration den E-Mail Verkehr normal weiterbetreiben?

Den Fehler habe ich jetzt nicht mehr zur Hand und kann gerade das nicht testen. Danke für deine Idee, ich werde das nach der Migration der Postfächer einmal ausprobieren.