winmadness

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.

UPN auf name@firma.de geändert und Outlook Profil angelegt. Das Benutzer Zertfikat neu erstellt und in Windows Anmeldeinformationen hinterlegt. Leider das gleiche Verhalten, nach wie vor Kennwortabfrage, diesmal mit "name@firma.de" als Benutzer.

Danke für den Tipp. Ist bereits deaktiviert, da ansonsten Autodiscover nicht funktionieren würde. Bis auf "ExcludeHttpsAutoDiscoverDomain" sind alle "Exclude..." Schlüssel deaktiviert. Ich denke ich habe eine Spur. Unser Domainname lautet intern.de. Somit ist der UPN name@intern.de und hierüber erfolgt auch die Anmeldung am AD und die Erstellung / Anmeldung des Outlook Profils. Auch das Kerberos Ticket weist unter "Client" den Eintrag "name@intern.de" aus. Die primäre SMTP-Adresse (AD Feld "mail") ist name@firma.de (unsere offizielle Firmen-Domain). Auch in Outlook wird das Postfach unter "name@firma.de" angezeigt. Wenn ich nun über Outlook den "E-Mail-Autokonfiguration" Test durchführe muss über bei Eingabe der Adresse "name@intern.de" kein Passwort eingeben. Wenn ich aber den Test mit "name@firma.de" durchführe dann verlangt Outlook die Eingabe eines Passwortes. Ich trage dann als Benutzer name@intern.de und das entsprechende Passwort ein. Dann läuft der Test ohne Probleme. Die Frage wie löse ich das Problem. Den UPN kann ich nicht ändern. Welche Auswirkungen hätte die Änderung der Mail-Adresse (AD Feld mail)?

Ich habe ein Problem mit der Outlook Authentifizierung. Outlook verlangt die Eingabe des Benutzerkennwortes, obwohl ein Kerberos-Ticket für Outlook existiert. Wenn ich die Kennwort-Eingabe abbreche startet Outlook normal und ich habe Zugriff auf alle Outlook Elemente / Ordner. Aber es wird immer wieder die Eingabe eines Kennwortes verlangt (bei Abbruch der Anforderung). 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 und einmal OPNSense VM – bei beiden der gleiche Fehler) • Anmeldung an der UTM über einen VPN Benutzer • Kerberos Ticket wird über Benutzer Zertifikat (im AD beim Benutzer hinterlegt) gezogen • Das Benutzer Zertifikat ist im Windows Client in den Systemsteuerungen -> Windows-Anmeldeinformationen als „Zertifikatbasierte Anmeldeinformationen“ für die Domain hinterlegt • Zugriff auf Netzfreigaben über das Benutzer-Zertifikat / Kerberos-Tickt ohne Probleme möglich • Outlook Profil mehrmals neu angelegt, mit und ohne Exchange Cache • Outlook Verbindung über MAPIoverHTTP • In der Registry den Key „AuthenticationService„ unter „Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\Security“ auf 16 = Kerberos-Kennwortauthentifizierung angelegt • Im ECP unter Server -> Virtuelle Verzeichnisse für die Authentifizierungs-Methode für Server-Typ „mapi“ nur „Windows-Authentifizierung – Kerberos“ aktiviert. In der Outlook Übersicht „Verbindungsstatus“ wird mir unter Servername nur https://<exchange-server>/mapi/... und als Protokoll nur „http“ angezeigt. In der Spalte „Authn“ steht „Nego*“. Bei Abbruch der Passwort-Abfrage steht in der Outlook Statusleiste „Kennwort erforderlich“. Nach Betätigung des Buttons „Verbindung wiederherstellen“ im Verbindungsstatus-Fenster kann ich normal weiterarbeiten – bis zur nächsten Kennwort-Abfrage z.B. bei Wechsel eines Ordners innerhalb meines Postfaches. Ich kann trotz fehlender Kennwort-Eingabe ganz normal und fehlerfrei mit Outlook arbeiten.