-
Gesamte Inhalte
2.029 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von magicpeter
-
-
vor 25 Minuten schrieb mikro:
Moin,
Google mal LegacyExchangeDn. Outlookautovervollständigung bei den Kollegen mal löschen oder ein X500 Objekt generieren.
Gruß Mirko
Super - Danke für deinen Input. Genau das war es!
Hier steht noch mal alles genau beschrieben.
https://www.windowspro.de/roland-eich/outlook-kann-mail-adresse-nicht-finden-legacyexchangedn-als-x500-adresse-exchangeoder einfach Exchange PowerShell gibt den LegacyExchangeDN Wert auslesen
Get-Mailbox -identity Benutzername | select LegacyExchangeDN
Wert kopieren und in Exchange ECP Benutzer E-Mail also X500 Eintrag eintragen
fertig.Es kommen dann sofort alle internen E-Mails wieder an.
-
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...
-
vor 6 Stunden schrieb NorbertFe:
Ich habe nicht behauptet, dass es dann funktioniert, sondern dass es supported ist.
Ja, ist schon klar. Danke Dir für die Info.
-
vor 3 Stunden schrieb NorbertFe:
Doch, mit entsprechenden Voraussetzungen:
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.
-
vor 3 Stunden schrieb massaraksch:
Hi,
man kann auch ohne Verschieben den Suchindex eines Postfachs neu erstellen:
Start-MailboxAssistant -Identity mailbox@contoso.com -AssistantName BigFunnelRetryFeederTimeBasedAssistant
Wenn das Problem allerdings nach einiger Zeit wieder auftaucht...
PS: Ich glaube, das ist erst seit CU11 verfügbar.
Habe ich probiert, hat aber auch auf Dauer nichts genutzt...
Danke trotzdem...
-
vor 1 Minute schrieb Nobbyaushb:
Outlook 2013 ist nicht in der Support-Matrix für Exchange 2019
Und nein, ich kenne keine Lösung.
Geht mal, mal nicht, manchmal hilft Neuaufbau Index - nicht immer
Ja, schade das die nicht mal eine vernünftige Suchfunktion hinbekommen ;)
Ich habe meinen eigenen Beitrag dazu aufgemacht. Vielleicht kann ja jemand helfen. -
vor 2 Minuten schrieb Nobbyaushb:
Suche klappt mit Exchange 2019 nicht gut - noch nie.
Was is Outlook 2012?
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.
-
vor 12 Minuten schrieb mikro:
Moin
KB5008212 vielleicht?
Gruß mirko
Was ist denn das für Update und für welches Betriebssystem?
Was genau macht das Update?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-VDer 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 BigFunnelCorruptedCountSchlussfolgerungen:
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-ScannerWenn 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-d5392500de30Logpresso 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-
1
-
-
vor 8 Stunden schrieb cj_berlin:
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
-
vor 3 Minuten schrieb tesso:
Wozu gibt es DNS?
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
-
Gerade eben schrieb tesso:
Deine Bastelei an den hosts Dateien sind eine Fehlerquelle.
Die habe ich schon seit Jahren nicht mehr anfassen müssen.
Das ist aber interessant. Wie hättest du das Problem denn gelöst?
-
1
-
-
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.
-
Gerade eben schrieb tesso:
DNS nutzen doch auch die PCs. Sorg dafür das das funktioniert.
Ja, der DNS der Hauptstelle ist bei den PC´s eingetragen.
Share klappen auch, aber da war es dann auch.. ;)
-
vor 1 Minute schrieb tesso:
Da stehen doch PCs.
Ja, das stimmt die auch... ;)
Aber kein Server oder dergleichen....
-
vor 11 Minuten schrieb tesso:
Dann weißt du doch was du brauchst damit es funktioniert. Frisch ans Werk.
Im Lager steht leider nichts davon. Nur eine Firewall.
-
vor 2 Stunden schrieb tesso:
Mal eine Frage an den Profi: Welcher Dienst wird benötigt um einen DC zu finden?
DNS und AD DC
Warum fragst du? -
vor 8 Minuten schrieb cj_berlin:
Das VPN und evtl. Firewalls soweit gerade ziehen, dass die Kommunikation funktioniert?
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öst2. Auf dem anderen Server ist ein DimmModul defekt (korregiertbar defekt) wird jetzt ausgetauscht
Die PowerSettings schau ich mir noch mal an djmaker
-
vor 14 Minuten schrieb tesso:
Hast du mal den Ram getestet?
Nein noch nicht, das wäre jetzt mein nächster Step mittels mdsched.exe
Netzwerklaufwerke machen über den VPN-Tunnel immer wieder Probleme beim anklicken
in Windows Server Forum
Geschrieben
Umgebung:
Windows Server 2019 Std. DC & Fileserver mit Shares
Firewall Lancom UF-260 mit SSL VPN-Tunnel
20 Rechner in der Firma und 10 Rechner im Homeoffice
10 Rechner im Homeoffice und das Problem tritt nur bei einem PC im Homeoffice auf.
Im Homeoffice ist der Rechner per VPN-Tunnel an das Firmennetzwerk angebunden. Wenn man ein Netzlaufwerk anklickt dann funktioniert es oft nicht das Inhaltsverzeichnis sauber anzuzeigen, oft hängt auch der Windows Explorer mit „Keine Rückmeldung“ und der Bildschirm wird schwarz, nach einer gewissen Zeit fängt sich dann oft der Rechner wieder.
Die Shares sind per IP-Adresse \\192.168.32.127\daten auf dem Rechner verbunden.
Woran könnte das liegen?
Kann es sein das irgendwelche Energiesparfunktionen dafür verantwortlich sind?
Ich habe einmal einen permanenten Ping auf den DNS Server in der Firma durch den VPN-Tunnel gestartet, danach ist das Problem nicht mehr aufgetreten.
Als Workaround ganz nett, aber eine richtige Lösung ist das nicht.