winmadness

Hallo, eine Sicherheitsfirma hat unsere IT geprüft und dabei die Empfehlung ausgesprochen, TLS 1.1 für SMTP (Mailserver) zu deaktiveren. Wie ist eure Erfahrung - gibt es noch Mailserver die TLS 1.1 verwenden bzw. habt Ihr auf euren Systemen nur TLS 1.2 / 1.3 aktiviert?

Lösung gefunden! Die Lösung liegt in folgender Einstellung im OpenVPN Client: • Über das Menü „Settings“ aufrufen • „Advanced Settings“ einblenden • Die Option „IP4-Only Tunnel“ im Bereich „IPv6“ aktivieren Seltsam dass die anderen Clients ohne diese Einstellung funktionieren.

Folgende Konfiguration: Windows Server 2016 mit allen Patches – eine VM als DC und eine VM mit Exchange Server 2016 mit allen Patches Client Windows 10 mit allen Patches MS Office 2016 mit allen Patches VPN Verbindung über OpenVPN mit SSL (als UTM einmal WatchGuard VM) Anmeldung an der UTM über einen VPN Benutzer da WatchGuard für VPN Verbindungen kein IPv6 unterstützt, muss IPv4 verwendet werden In der Registry gemäß MS Empfehlung den Parameter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\DisabledComponents auf Hex-Wert 20 für "Prefer IPv4 over IPv6" gesetzt Es tritt nun einem Laptop das Problem auf, dass z.B. ping auf einen Intranet-Server (z.B. exchange.intern.de) mit einer IPv6 Adresse versucht wird, der natürlich fehl schlägt. Ein "ping -4 exchange.intern.de" funktioniert. Auch Outlook versucht zuerst eine Verbindung über IPv6 aufzubauen - dies verzögert den Verbindungsaufbau beim Start merklich. Auch das Öffnen von z.B. freigegebenen Kalendern dauert sehr lange, da zuerst auf den Timeout der IPv6 Verbindung gewartet wird. Als Bypass habe ich in der Registry über den Hex-Wert 0xFF das IPv6 Protokoll deaktiviet. Jetzt funktionert der ping und Outlook ohne Probleme. Das Problem tritt nur auf einem Laptop auf, alle anderen Computer mit der gleichen Konfiguration laufen ohne Probleme.

Ich empfehle Dir das Forum "Frag einen Anwalt". Dort erhältst Du eine rechtlich fundierte Antwort. Ausserdem findest Du einige Threads zum Thema "Urlaub alleinerziehende Mutter". Ich würde im ersten Schritt mit den Kollegen reden, natürlich abhängig vom Arbeitsklima / Verhältnis zueinander. Der nächste Schritt wäre dann das Gespräch mit dem Vorgesetzten.

Hier ist die Lösung! Das AD Feld "Managed-By" beinhaltet nur den "Haupt-Bestizer". Das AD Feld "ms-Exch-Co-Managed-By-Link" die weiteren Besitzer. Deshalb kannst Du mit dem Details Templates Editor z.B. eine neue Registerkarte mit der Bezeichnung "Besitzer" hinzufügen. Dort ein "Listenfeld" hinzufügen und als "AttributName" das Attribut "ms-Exch-Co-Managed-By-Link" zuweisen.

Du hast Recht, ist ein Bug von MS - das Attribut "Managed-by" ist im Template Editor nicht korrekt implementiert. Zwei Möglichkeiten: Ticket bei MS Support aufmachen oder ein Outlook Makro erstellen.

Die Anzeige der Gruppen-Besitzer ist tatsächlich ein "Bug". Du kannst das Formular auf dem Exchange Server mit der "Exchange ToolBox -> Details Templates Editor" ändern. Im Editor den Vorlagentyp "Group" für die gewünschte Sprache auswählen. Im Formular das Listenfeld für die "Besitzer" auswählen und rechts in den Eigenschaften "ScrollBars" auf "Both" festlegen. Des weiteren die Höhe der Box anpassen.

Gar nichts! Meine Meinung - verfolge den Weg eine Prozedur krampfhaft auf das fehlerhafte Tabellendesign anzupassen nicht weiter - never ending story. Wie bereits geschrieben hast Du noch keine Lösung für Feiertage und betriebsbedingten Urlaub. Meine Frage - kannst Du das Tabellendesign noch ändern? Wenn nicht, warum nicht?

Habt Ihr unterschiedliche Domains für das DC Netzwerk und die Firmen-Domain also z.B. intern.de und firma.de? Wenn ja, gehe ich davon aus das intern.de nicht offiziell registriert ist und somit über das Internet nicht aufgelöst werden kann. Werden die Hostnamen korrekt aufgelöst: mit Powershell Resolve-DnsName <dcserver>.intern.de und einem ping auf <dcserver>.intern.de? Wie loggen sich die User ein - mit "intern\<user>", "intern.de\<user>" oder mit "user@intern.de" - alles schon getestet? Du kannst zum Testen die IP Adressen der DNS Server mit der internen Domain in der Name Resolution Policy Table (NRPT) eintragen bzw. checken, ob dort evtl. ein falscher Eintrag steht. Auch mal die NRPT Einträge der Win 10 Clients mit dem Win 11 vergleichen, sofern vorhanden. PS: ich habe den Thread nicht weiter verfolgt also kann es durchaus sein dass meine Fragen / Anregungen bereits beantwortet / getestet wurden.

Muss der Webserver von extern erreichbar sein? Du schreibst "lokaler Webserver" darunter verstehe ich einen Webserver im Intranet / LAN. Die beste Lösung wäre dann natürlich, den Webserver nur im Intranet freizugeben. Also für "externe" Zugreifer über z.B. VPN Verbindung. PS: Ein Link auf den Tweet und ein kurzer Kommentar wären besser zu lesen und zu verstehen.

Mit dem bestehenden Tabellendesign wüsste ich keine Lösung mit einer select-Abfrage. Entweder Du erstellst eine Prozedur und selbst diese würde komplexer werden als auf dem ersten Blick gedacht. Was nicht geht: eine Einschränkung der Ergebnismenge über eine Where-Klausel mit dem aktuellen Tagesdatum. Damit könntest Du zwar ermitteln, ob er bis zum heutigen Tag abwesend ist, aber nicht ob die Abwesenheit andauert. In einer Prozedur müsste man, ausgehend vom aktuellen Tagesdatum, prüfen ob der aktuelle Tag plus anschließende Tage in der Tabelle stehen. Hier ergebt sich ein Problem bzgl. Wochenende / Feiertage. Wenn diese freien Tage nicht als Datensatz vorliegen, müsste man dies im Algorithmus berücksichtigen. Also aufwendig die Wochenende, Feiertage und evtl. auch betriebsbedingte freie Tage (z.B. Betriebsurlaub) ermitteln. Also mein Rat - Tabellendesign ändern: Mitarbeiter, Unterbrechungsgrund, Startdatum, Enddatum Wenn dies nicht möglich ist dann sollten die freien Tage (Wochenende, Feiertage etc.) innerhalb eines Urlaubs / Krankheit mit eingetragen werden und die Ermittlung der aktuellen Abwesenheit über eine Prozedur stattfinden.

Meine Idee: auf dem 2012er Server auf die höchst-mögliche IIS Version (8.5?) upgraden, dann eine Sicherung der Einstellungen vornehmen und hoffen, dass diese mit der Windows Server 2019 IIS Version (10?) kompatibel sind. Habe leider keine Erfahrungen mit IIS Versionen und Backup der Konfigurationsdateien, sicher können andere Forenteilnehmer Dir hier besser helfen.

Du kannst die Share Mailbox als zusätzliches Outlook Konto einbinden - vorher natürlich Automapping deaktivieren. Ich habe mehrere Shared Mailboxes als zusätzliches Konto im Outlook-Profil eingebunden und bekomme für jedes Konto eine Benachrichtigung bzw. Mail-Icon in der Taskleiste bei eingehenden Emails.

Wir hatten ebenfalls mit Outlook Performance Probleme auf einigen VPN-Clients. Es lag an IPv6. Deshalb würde ich prüfen, ob IPv6 in den Eigentschaften der Netzwerkverbindung aktiviert ist. Wenn es deaktiviert ist und IPv6 nicht im Einsatz ist, dann über die Registry "deaktivieren" - MS Anleitung . Ein weiteres Problem war die Internet-Verbindung im Home-Office. Bei DS Lite Anschlüssen brach die über IPv4 aufgebaute VPN Verbindung immer wieder ab bzw. bei bestehender Verbindung stürzte ein Datenbank-Client ab. Abhilfe schaffte der Aufbau der VPN Verbindung über IPv6.

Verstanden. Ich ging von der Produktseite von MS aus, hier wird explizit OneNote als Desktop App in der Basis-Version ausgeschlossen. Bin aber Deiner Meinung - erst mal Basic Version erwerben und testen, Upgrade auf Standard Version ist mit "einem Klick" möglich.

Nein, das habe ich doch geschrieben. Desktop Apps nur ab "Standard" Lizenzen. Die Basic Lizenzen beinhalten NUR die Web-Apps, keine Desktop-Apps. Sehe gerade, Norbert sagt das Gegenteil. @NorbertFeHast Du das schon getestet bzw. Erfahrung damit?

Welche Office Lizenz? MS Office 20xx Lizenz oder ein MS Office / Microsoft 365 Abo? Bitte genau definieren. Und ja, bei der Standard-Lizenz sind die MS Office Desktop Apps dabei. Wenn Du unbedingt mit Desktop Apps arbeiten willst benötigst Du mindestens "Microsoft 365 Business Standard". Wenn die Web-Apps (laufen in einem Browser z.B. Edge, Firefox oder Chrome) ausreichen dann genügt Dir die "Microsoft 365 Business Basic" Lizenz. Du könntest im ersten Schritt nur die Basic-Lizenz erwerben und evaluieren, ob die Web-Apps im täglichen Einsatz ausreichen. Du kannst dann jederzeit auf die Standard Lizenz mit den Desktop-Apps upgraden.

Ich verwende die Tools von ForensIT

Auf der Produktseite von MS sind für Basic Version nur die Web-Apps aufgelistet.

Ich habe die Lösung! Wie bereits erwähnt, trage ich das Benutzer-Zertifikat im Windows Client in den Systemsteuerungen -> Windows-Anmeldeinformationen als „Zertifikatbasierte Anmeldeinformationen“ für die Domain "*.intern.de" ein. Ich habe zusätzlich das Zertifikat für die Domain "*.firma.de" eingetragen - und siehe da, keine Outlook Passwort-Abfrage mehr Auch der Outlook E-Mail-Autokonfiguration-Test mit der Mail-Adresse <name>@firma.de funktioniert nun ohne Passworteingabe. Die Woche ist gerettet

Eine Anzeige mit klist gibt für beide Fällle (mail = <name>@firma.de und <name>@intern.de) das selbe Ergebnis: Client: <name> @ intern.de Server: HTTP/exchange.intern.de @ intern.de Tipp mit dem IIS Protokoll ist klasse - werde ich in Ruhe prüfen. Kein Problem, da diese offiziell registriert ist - also die Domain gehört uns.

Zertifikats-Daten: Aussteller: ..., DC = intern DC = de Daten im Zertifikat für UPN = name@intern.de, mail = name@firma.de Antragssteller: E = name@firma.de, CN = <Displayname>, OU = User <firma>, DC = intern, DC = de Alternativer Antragsstellername: Prinzipalname=<name>@intern.de, RFC822-Name=<name>@firma.de Daten im Zertifikat für UPN = name@firma.de, mail = name@firma.de Antragssteller: E = name@firma.de, CN = <Displayname>, OU = User <firma>, DC = intern, DC = de Alternativer Antragsstellername: Prinzipalname=<name>@firma.de, RFC822-Name=<name>@firma.de

Danke für die Hinweise, hatte ich befürchtet Werde den "steinigen" Weg gehen und das Passwort bei der Profil-Erstellung in Windows speichern. Wollte ich vermeiden und nur mit User-Zertifikaten arbeiten.

Auf dem DC im AD / User. Der Windows Client ist kein Domain-Mitglied. Die Verbindung erfolgt über VPN und dann wird über das Benutzer-Zertifikat ein Kerberos Ticket gezogen. D.h. eine Anmeldung im AD erfolgt nicht. War nur für Testzwecke, habe ich bereits gelöscht. Ich habe jetzt im AD das Feld "mail" und "UPN" auf name@intern.de geändert. Damit kommt in Outlook keine Kennwort-Abfrage mehr. Mal sehen welche Side-Effekts damit auftreten. Die primäre Mail-Adresse in Exchange-Postfach steht nach wie vor auf name@firma.de, also keine Auswirkungen auf den Mail-Verkehr.

Gute Idee, leider auch im abgesicherten Modus kommt die Abfrage. Und auch der "E-Mail-Autokonfiguration" Test verlangt bei der Adresse name@firma.de nach wie das Kennwort. Bei name@intern.de keine Kennwortabfrage. Noch eine Frage, das Kerberos Ticket wird nach wie vor für den Client "name@intern.de", also auf den Domainnamen des DC, ausgestellt. Ich denke hier liegt das Problem.