winmadness

@possum72 Sind die Exchange Dienste (OWA, ECP etc.) über Port 443 aus dem Internet erreichbar? Wenn ja, dann diese bei einer Neuinstallation auf jeden durch eine vorgeschaltete Firewall blockieren. Die Dienste dann über VPN erreichbar machen.

@DL10 Danke für das Feedback. Hast Du einen Test mit deaktivierten Virenscanner vorgenommen? Ansonsten kanst Du mal einige Reperaturläufe für den Server durchführen - gute Übersicht hier Was mir noch einfällt - hast Du schon mal die Eventlogs geprüft?

Hallo, evtl. liegt es an den Einstellungen für die Laufwerke. In den Eigenschaften eines Laufwerkes z.B. C: auf dem Tab "Allgemein" die Option "Zulassen, dass für Dateien ... indiziert werden". Sollte zwar keinen Einfluss haben, aber ist ohne Aufwand zu prüfen. Was passiert, wenn Du im Ordner-Auswahl-Fenster den Button "Alle Orte anzeigen" betätigst? Zwei Gruppenrichtlinien, welche Du prüfen könntest: Computerkonfiguration -> Administrative Vorlagen -> Windows Komponenten -> Suche Indizierung bestimmter Pfade verhindern Das Anpassen von indizierten Speicherorte in der .... Ein guter Tipp ist auch immer das Ausschalten des Virenscanners (Defender oder Drittanbieter)

Ich habe noch etwas zu Objekte in "Gelöschte Elemente" gefunden. Auszug

@teletubbieland nur für mein Verständnis, hast Du nun ein Standard-Tag angelegt und danach konntest Du die Richtlinien in Outlook sehen? Bzgl. Warte hier noch mal bis morgen - kann etwas dauern.

Hallo @DocZenith, hier einige Checks, die mir einfallen: Ich gehe davon aus, dass die User die Excel-Datei nicht ändern dürfen. Welche Version von MS Office hast Du im Einsatz? Ältere Versionen (z.B. 2007) haben Temp-Dateien im selben Verzeichnis wie die Office Datei gespeichert. Evtl. mal testen und für einen User Schreibrechte vergeben. Teste mal mit einer .txt Datei - gleiches Problem oder hängt es mit Excel zusammen? Lasse Dir mal über die Eigenschaften - Sicherheit - Effiktiver Zugriff die Zugriffsrechte für ein Userverzeichnis und für die Excel-Datei anzeigen, evtl. hier reinkopieren Erstelle mal einen zusätzliches Vereichnis für einen User im Ordner "Personal" und vergebe dort die gleichen Rechte. Dann Test mit der Excel Datei im Original-Userordner. Wenn der Fehler auftritt, "verschwindet" dann auch der zusätzliche Ordner? Nachtrag - noch einige Ideen (einiges erscheint abwegig - ist aber schnell getestet) Ist auf dem Client die "Dateivorschau" aktiviert - mal deaktivieren Manchmal funkt auch der Virenscanner dazwischen - mal auf Sever und Client deaktivieren Deaktiveren der Option "Zugriffsbasierte Aufzählung aktivieren" Nur zur Sicherheit - Du verwendest kein DFS, oder? Im Ressourcenmanager für Dateisever - sind "Dateiprüfungen" vorhanden? besteht eine stabile Netzverbindung zum Server - sind die Client im LAN oder über VPN angebunden? wie groß sind die Excel-Dateien?

Hallo, ich würde den externen Mitarbeiter ein Postfach erstellen und die entsprechenden Rechte einrichten. Sicherheitstechnisch sollte der Zugriff natürlich über VPN erfolgen (ProxyLogon Exploit!). Edit: Gewähren von Zugriffsrechten für die Formular Bibliothek

Hallo Peter, wenn für Deine Kunden der Erwerb von gebrauchten Lizenzen in Betracht kommt, dann schaue Dir mal folgende Anbieter an. Ich hatte mich ausführlich mit dem Thema beschäftigt und die folgenden Anbieter liefern Dir die von Microsoft geforderten und durch Gerichtsurteile bestätigte Dokumentation (sog. Audit sicher): https://www.preo-ag.com/de https://www.relicense.com/de/index.php https://www.vendosoft.de/ Laut eigener Aussage ebenfalls "Audit sicher", war mir persönlich aber zu unsicher: https://www.usedsoft.com/de/ https://www.s2-software.com/ Die Informationen spiegeln die persönliche Erfahrung und Meinung des Autors wieder.

Hallo, hast Du schon mal probiert, das bestehende "Problem-Benutzerprofil" komplett zu löschen und den Benutzer auf dem Rechner neu anzulegen?

@skipper02 Ich gehe davon aus, dass Du in der "Systemsteuerung -> E-Mail" alle Profile gelöscht hast. Du kannst in der Registry unter dem Schlüssel "Computer\HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Profiles" prüfen, ob auch alle Profile gelöscht wurden. Evtl. wird der autodiscover über die Registry "umgebogen". Check mal den Schlüssel "Computer\HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover" und "...\RedirectServers". Registry Einträge gelten für MS Outlook 2016, evtl. Versionsinfo im Pfad anpassen.

Hallo Peter, mit der Problematik hatte ich mich auch schon beschäftigt. Unser Lizenzberater hat damals ausgeführt, dass auch für Replikationsserver alle VMs vollständig lizenziert sein müssen - egal ob diese laufen oder nicht. Also in Deinem Fall würdest Du 4x Windows 2019 benötigen. Und natürlich auf die Mindest-Core-Anzahl achten. Bitte beachte, diese ist keine rechtsverbindliche Aussage. Immer mit MS bzw. Deinem Lizenzhändler abklären.

Hallo Dukel, habe ich getan. Da ich ein eigenes Zertifikat erstellt habe und diese sowohl der Default Web Site als auch dem Back End zugewiesen habe, habe ich natürlich ein anderes Zertifikat mit Get-ExhangeCertificate als mit Geth-Authconfig (hier kommt das originale MS Auth Exchange Certificate). Auch mit "netsh http show ssl" wird für den Port 444 (Back End) das eigene Zertifikat angezeigt. Natürlich wird Dir bei beiden Befehlen das gleiche Zertifikat angezeigt, wenn Du die Default Exchange Installation nicht veränderst.

@Dukel Bist Du sicher? Noch meiner Kenntnis ist das "Get-AuthConfig" Zertifikat notwendig für die OAuth Authentication und in Hybrid-Umgebungen - entsprechender Artikel hier und hier.

@cj_berlin Sehe ich nicht so. Es hindert Dich schließlich niemand daran, Deine Gedanken zur Absicherung im LAN hier zu posten. Bisher waren es nur ein paar Stichworte ohne weitere Erläuterungen / Links. Und auf die Nachfrage von @magicpeter hast Du auch nicht reagiert. Ansonsten gebe ich Dir Recht, das auch im LAN die Möglichkeiten zur Absicherung genutzt werden müssen. Es gehört zum Gesamtkonzept. Also wie verhindere ich, dass überhaupt Angreifer ins Netz gelangen und wenn doch, wie hindere ich die Angreifer daran sich im Netz auszubreiten. Ein weiterer Aspekt der LAN-Sicherheit besteht sicherlich in der Möglichkeit, dass "kriminelle oder neugierige" Mitarbeiter das Netz von innen angreifen.

Alles klar, jetzt habe ich es verstanden. Nur für mein Verständnis. Ich gehe davon aus, dass der eigentliche Exchange Admin das Standard Exchange Auth Zertifikat explizit gelöscht hat, da es mit Get-ExchangeCertificate nicht aufgeführt wird. In diesem Fall wären ja schon früher Fehler (Eventlog) aufgetreten, wenn der nicht gleichzeitig über Set-AuthConfig das Zertifikat neu gesetzt hätte. Oder übersehe ich hier etwas? Sorry, will Dich nicht nevern - ich will es nur verstehen und lerne gerne dazu.

Habe ich verstanden. Deswegen wundert mich Deine Aussage (Zitat) nach der negativen Überprüfung der Bindungen mit netsh und "Get-ExchangeCertificate". Was habe ich übersehen?

Verstehe ich nicht so ganz. Er hat doch geprüft, ob das eigene Zertifikat im System oder an Exchange gebunden ist - nach seiner Aussage nein. Ausserdem ist in dem Link die Erstellung eines Zertifikates mit "New-ExchangeCertificate " beschrieben. Ich z.B. verwende zwei Zertifiakte - ein offizielles Wildcard-Zertifikat für SMTP und mein virtuelles ActiveSync Directory und ein mit Windows Zertifizierungsstelle erstelltes für die Default Web Site / Exchange Back End.

Hier noch einige Ideen: Mit "Get-MessageTrackingLog" mal das Nachrichtenprotokoll prüfen, evtl. findest Du hier eine Spur Hast Du einen MTA (z.B. Exchange Edge) im Einsatz - diesem mal überprüfen wie @tessoschon geschrieben hat, mal mit "Get-MailboxDatabase <database> | fl JournalRecipient" die DB prüfen Zwar abwegig, aber mal die Exchange Regeln im "Nachrichtenfluss" prüfen

Hallo Michael, das sieht nach einer Journalregel zur Mail Archivierung aus. Schaue mal im ECP unter "Verwaltung der Compilance -> Journalregeln" ob dort eine Regel mit Deinem Postfach als Empfänger eingetragen ist. Alternativ auch mit dem Exchange Powershell Befehl "Get-JournalRule"

Ist nur eine Idee zur Lösung Deines Problems. Ich hatte bisher immer eine Standard-Tags mit Ordner-Tags gemischt und nie Probleme, deswegen der Vorschlag.

Richtig, aber Du benötigst nach meinen Wissen eine Standard-Regel. In dieser setzt Du den "Aufbewahrungszeit" auf "Nie", sodass diese nicht greift. Dann weist Du diese Deiner Aufbewahrugnsrichtlinie zu und damit sollte es funktionieren.

In diesem Fall benötigst Du Beeftext nicht. Es geht einfach, wenn Du ein Powershellskript erstellst, welche alle benötigten Informationen in einer EMail sendet. Ich würde hier ohne Parameter arbeiten und in der EMail alle benötigten Informationen einstellen. Z.B. $User = ([System.Environment]::UserName) $bios = (Get-CimInstance Win32_bios).SerialNumber $newline = "`n" $body = "User: $user${newline}SN: $bios" Send-MailMessage -to support@firma.de -from $user@mail.de -subject "Systeminformationen" -body $body -SmtpServer mail.firma.de Absenderadresse bewußt mit "mail.de", da bei "firma.de" es Probleme mit dem Recht zu senden geben kann - ja nach euerer Exchange Konfiguration.

Ich meinte eine allgemeingültigen Tag, also neben Deinen Tags für spezielle Ordner. Im ECP in der Spalte "Typ" sollte also "STandard" stehen.

Hast Du der Aufbewahrungsrichtlinie auch einen allgemein gültigen Aufbewahrungstag ("Standard" oder "Persönlich") zugewiesen? Es könnte daran liegen, dass Du nur Tags für spezielle Ordner erstellt hast.

Welche Regel, werden wo angezeigt? Prüfe mal auf dem Exchanger Sever mit Powershell die Zuweisung: Get-Mailbox <mailboxname> | Select RetentionPolicy Get-RetentionPolicy -Identity <regelname> | fl