Küstennebel

Seit Kurzem haben wir auch verstärkt Mailrückläufer von 1&1 / IONOS. Eine IP Cam, die seit Jahren Alarmbilder verschickt, wird z.B. nicht mehr akzeptiert. In der Zwischenzeit habe ich mehrfach mit dem Support telefoniert. Am Ende kam heraus, dass 1&1 / IONOS seit dem 01.04.20 alle Mails konsequent auf Einhaltung von RFC 5321/5322 checkt. Und alles, was früher noch akzeptiert wurde, wird jetzt abgelehnt. Unsere Kamera (altes China Modell) sendet z.B. u.a. folgendes: ... From: "johndoe IP Cam" <ipcam1@johndoe.com> To: "name1@johndoe.com" Subject:Mail Test Date: Wed, 08 Apr 2020 08:29:21 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_25850421==_" Comment: Message-ID missing from received message, added by johndoe.com. Message-ID: <5ACBA5C7.5E8D8B62.03F4@johndoe.com> Im To: Feld steht nur ein Name in Quotation Marks, aber die E-mail Adresse selber in <> fehlt. Im Subject: fehlt ein Leerzeichen hinter dem Doppelpunkt. Im Date: Feld fehlt der TimeZone Offset. Eine Message ID fehlt auch und wird erst durch unseren Mailserver hinzugefügt. All das störte den 1&1 SMTP bis zum 01.04. überhaupt nicht. Ich weiß auch nicht konkret, ob nur einer der Fehler ausschlaggebend ist oder alles. Du solltest aber mal Deine betroffenen Mails auf RFC Konformität überprüfen.

Das macht der Zyxel SecuExtender aber leider nicht. Er weist eine IP aus dem Company LAN zu und übergibt auch den Company DNS, aber keinen Suffix. Also mit meinem begrenzten Wissen denke ich trotzdem, dass der DNS des DC sauber läuft. Hier gab es rückwirkend noch nie irgendwelche Probleme oder Fehler in der Ereignisanzeige. Die SSL VPN Verbindung gibt auch den richtigen lokalen DNS Server mit. Nach dem Verbinden sehe ich im VPN Status direkt die eigenen IP aus dem Company LAN, die Tunnel Server IP und auch die IP unseres Company DNS. Außerdem löst er ja die Namen des Server Share sauber auf, entweder, wenn man das DNS Suffix manuell in den Adaptereinstellungen einträgt oder aber das Share mit dem FQDN mapped. Also läuft für mich der DNS und ist auch erreichbar. Evtl. liegt es ja am Zyxel VPN. Der Tunnel wird dabei direkt mit der Zyxel Firewall aufgebaut und ist nicht irgendwie "domain-integriert" Für mich geht es jetzt nur noch darum, das Suffix per GPO zu verteilen, damit ich es nicht händisch überall eintagen muss. Und ich kann halt per GPO nicht nur die "disjoint clients" auswählen, weil diese halt auch ab und zu im "joint namespace", also direkt in der Firma, sind. Deshalb meine Frage, ob es irgendwelche Auswirkungen hat, das Domain Suffix einfach allen zuzuweisen. Mag vielleicht unsinnig sein, sollte aber auch kein Brot fressen, oder?

Hi Dukel, danke für die Rückmeldung. Klingt erst mal interessant. Allerdings steht in der MS Anleitung, dass diese GPO nur jenen Computern zugewiesen werden soll, welche sich im "disjoint namespace" befinden. Unsere Notebook sind aber mal in der Firma, direkt im Firmen-LAN, und mal zu Hause und nur per VPN verbunden. Hat es irgendwelche Auswirkungen, wenn ich das Domain Suffix per GPO einfach allen betreffenden Rechnern zuweise?

Moin, ich benötige mal etwas Nachhilfe von den Spezialisten hier. Innerhalb unserer Firmendomain (1x Server 2016 Standard DC/ 18x W10 Pro Clients) verbinden wir bestimmte Server Shares als Netzlaufwerke auf jedem Client via Profil Batch für jeden User (net use ... \\server1\share). Das läuft soweit seit Jahren. In Corona Zeiten mussten wir jetzt auf Home Office umstellen. Dabei verbinden sich die Home Office User per Zyxel SSL VPN Client mit der Zyxel Firewall und bekommen Zugriff auf's Firmen LAN. Auch das läuft zufriedenstellend. Allerdings, und obwohl der Firmen DNS per DHCP mit an den Tunnelclient übertragen wird, konnten die Clients zu Hause nicht das Server Share auflösen. Kurzfristig haben wir uns damit beholfen, dass wir das Server Share per IP Adresse des Servers mappen (\\192.168.21.230\share). Damit kamen dann alle, sowohl in der Firma als auch von zu Hause auf das Laufwerk. Später merkten wir dann aber, dass unsere Office Serienbriefe nicht mehr funktionierten. MS Word wollte die, mit dem Serienbrief verknüpften Datendateien einfach nicht mehr öffnen. Auch sämtliche Änderungsversuche am Word Trust Center halfen nichts. Nach Internetrecherche mussten wir dann lernen, dass Office wohl keine IP Adressen für diesen Zweck akzeptiert und dass beim Nutzen von IP Adressen auch Keberos nicht mehr genutzt wird. Also keine so gute Idee. Als Nächstes hatten wir dann den FQDN des Server Shares zum Mappen genutzt (\\server1.firma.local\share). Das lief eigentlich auch gut und das Share konnte vom Home Office aus aufgelöst werden. Allerdings wollte MS Word auch hier unsere Serienbriefe nicht mehr ordnungsgemäß öffnen. Ging also auch nicht. Am Ende blieb nur händisch das DNS Suffix "firma.local" in den erweiterten DNS Einstellungen des Netzwerkadapters des VPN Clients einzutragen. Dann konnte sowohl das Server Share von zu Hause aufgelöst werden als auch die Serienbriefe funktionieren wieder. Allerdings müssten jetzt auf 18 Client Rechnern die DNS Suffixe händisch eingetragen werden. Gibt es dafür einen eleganteren Weg oder fällt Euch etwas ganz anderes ein? Vielen Dank Jörg

Moin Norbert, nach kurzer Inventur haben wir derzeit im Einsatz: 1x MS Office 2010 Home & Business 10x MS Office 2013 Home & Business 10x MS Office 2016 Home & Business Ich teste zwischen den Jahren mal weiter. Dann sind meine User alle im Weihnachtsurlaub. Gruß Jörg

Funktioniert hatte es auf jeden Fall bei Office 2010 unter W10, dagegen bei Office 2007 unter W7 nicht und bei Office 2013 unter W7 auch nicht. Ich check morgen erst mal meine Installations- und Lizenzübersicht. Gruß Jörg

... ach Du Sch..., wenn ich Deine Links so lese, war ja meine ganze Office Makro GPO Erstellung von heute für den A... Das hätte ich mir ja nicht träumen lassen, dass die neueren Office Versionen nicht über GPOs angepasst werden können. Ich habe den halben Tag dazu recherchiert und in keiner Anleitung stand auch nur ein Wort darüber. Jetzt muss ich erst mal 'ne Weile drüber schlafen, ob ich mir die Mühe mache, die einzelnen Registry Key herauszubekommen, um diese dann direkt per GPO zu setzen. Aber dies für alle Office Versionen und/oder sogar einzeln für alle Excel, Word, Powerpoint durchzuführen, ist wohl nicht die Mühe wert, da der User diese auch wieder zurückstellen kann. Ich werde wohl eher unsere 20 Rechner zu Fuß abklappern und die Makrosicherheit manuell hochsetzen bzw. disablen. Wenigstens etwas. Danke Dir, Norbert, für die Hilfe und Aufklärung. Gruß Jörg

Wir haben hier eine bunt gemischte Umgebung aus Office 2007, 2010, 2013 und 2016. Alle Lizenzen sind über Dell beim Rechnerkauf bezogen worden. Die älteren mussten noch separat installiert und aktiviert werden, die Neueren sind alle vorinstalliert und aktiviert. Sind meistens Home & Office Varianten. Von "Klick2Run" habe ich noch nie gehört.

ich komme hier tagsüber schlecht an die Userrechner ... Wie es scheint, haben die W7 Rechner nur diese Probleme, obwohl gpresult auch hier auch alles ok anzeigt. Trotzdem sind die Makroeinstellungen in Word nicht disabled und die komische Infomeldung kommt, die besagt, dass es abgestellt ist. Bei den W10 Clients scheint alles richtig zu laufen. Die Makroeinstellung ist disabled und es kommt auch keine andere Warnmeldung. Hier kann ich mich auch mit verschiedenen Usern anmelden, bleibt alles, wie es soll. Ich muss morgen mal weiterprobieren. Jetzt geh' ich nach Hause. Schönen Feierabend.

Auf den User Also gpresult zeigt mir eine erfolgreiche Anwendung des GPO. Allerdings steht im Report weiter unten bei "Zusätzliche Registryeinstellungen": "Für einige Einstellungen konnten keine Anzeigenamen gefunden werden. Eine Aktualisierung der von der Gruppenrichtlinienverwaltung verwendeten ADM-Dateien behebt möglicherweise das Problem. " Darunter sind dann die verschiedenen Office Policies mit diversen Statusnummern (entweder 1 oder 4) aufgelistet.

Moin, heute haben wir uns auch dazu durchgerungen, die Ausführung von Makros erst mal komplett zu unterbinden. Dazu haben wir nach Anleitung von Matthias-Staud.de eine GPO erstellt. Die Anwendung der GPO wurde auf eine AD Sicherheitsgruppe eingeschränkt. Diese funktionierte zuerst wegen MS 16-072 nicht. Nachdem wir dann aber die Gruppe der "Domänen-Computer" bei Delegierungen eingetragen hatten, kam die GPO auf den Clients zur Anwendung. Allerdings habe ich zur Zeit etliche Rechner (W7, Office 2010), die trotz "Abschaltung der Makros ohne Warnhinweis" bei jedem Word Dokument (auch Dokumente ohne Makros), eine Makro Hinweis-Meldung ausgeben: "Sie versuchen eine Funktion auszuführen, die Makrounterstützung erfordert. Bei der Installation dieses Programms haben Sie (oder Ihr Admin) entschieden, die Unterstützung für Makros oder Steuerelemente nicht zu installieren...". Bisher haben wir schon mal eine Office Reparaturinstallation durchgeführt - ohne Erfolg. Fällt Euch noch ein Ansatzpunkt ein? Gruß Jörg

Wen's interessiert, hier die Rückmeldung zur Lösung, welche zumindest bei uns Wirkung zeigt. Teile davon habe ich z.B. hier gefunden: für die Sperrung des Computers nach zeitlicher Inaktivität: GPO an eine User OU geknüpft: Benutzerkonfiguration > Richtlinien > Administrative Vorlagen > Systemsteuerung > Anpassung: Bildschirmschoner aktivieren Kennwortschutz für den Bildschirmschoner verwenden Zeitlimit für Bildschirmschoner setzen Bestimmten Bildschirmschoner erzwingen (sofortiger Lock Screen mit „rundll32.exe user32.dll,LockWorkStation“) für die erzwungene Domänenanmeldung (kein Durchstarten des Rechners bis zum Desktop bei gespeicherten Anmeldedaten) GPO an eine Computer OU geknüpft: Computerkonfiguration > Einstellungen > Windows-Einstellungen > Registrierung: Hier muss dann folgender Registrywert angelegt und auf "Aktualisieren" gesetzt werden: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WinLogon > AutoAdminLogon auf „0“ Falls also ein User ein AutoLogon in seinem Windows aktviert hat (AutoAdminLogon auf „1“), wird dieser Wert überschrieben und wieder auf „0“ gesetzt.

In diesem Zusammenhang haben wir eben auch mal die GPO "Interaktive Anmeldung: Inaktivitätsgrenze des Computers" getestet. Hier wollten wir gerne erreichen, dass nach 30 Minuten Inaktivität der Rechner gesperrt wird. Doch die genannte GPO funktioniert nicht bei normaler Domänenanmeldung. Hier müssen wir wohl jetzt doch über den erzwungenen Bildschrimschoner gehen.

Moin und Dank für die zahlreichen Rückmeldungen. Hätte gedacht, da gibt's mittlerweile 'ne GPO für. Aber dann setze ich per GPO einfach den Registrywert "AutoAdminLogon" wieder auf "0" und die automatische Anmeldung müsste gegessen sein. Das Löschen des Schlüssels "DefaultPassword" kann ich mir dann schenken. (Bei uns sind einige User auch Lokale Admins auf Ihren Maschinen. Die Softwareentwickler müssen halt ständig Sachen installieren und testen. Und einige haben halt das AutoLogon aktiviert. Und wenn sie das dann später wieder auf "1" setzen, .... mal sehen, wann sie aufgeben. ) Gruß Jörg

Moin Forum, gibt es eine GPO für das Erzwingen des Anmeldebildschirms bei Rechnerstart? Bei uns haben einige User ihren Rechner auf "Durchstarten bis zum Desktop" eingestellt, ohne das die Anmeldeinformationen erneut eingegeben werden müssen. Nun, im Zuge der Einführung der EU-DSGV wollen wir hier mal einige Schwachstellen ausmertzen. Eine GPO für das Locken des Computers nach bestimmter Inaktivität habe ich gefunden, aber einen erzwungenen Anmeldebildschirm bei Rechnerstart leider nicht. Könnt Ihr mir da auf die Sprünge helfen? Gruß Jörg (DC Server 2016 / Windows 7 Clients)

Auf beiden.

Hi Norbert, IPv6 ist am Client wieder aktiviert, am DC lief es eh die ganze Zeit. Dank für die Aufklärung. An der Fehlermeldung, dass die Domäne (angeblich) nicht vorhanden ist, hat dies aber nichts geändert. Anmeldedienst läuft auch. Zumindest die Zeit synct ja erst mal wieder, seit der Rechner aus der Domäne entfernt und wieder reingesetzt wurde. Insofern ist die Domäne ja erst mal vorhanden.

Sowohl Richtung Internet, als auch intern nutzen wir aktiv nur das IPv4 Protokoll, deshalb ist bei allen Rechnern in den Adaptereinstellungen der Haken bei IPv6 rausgenommen Meint Ihr, das ist Quatsch? Sollte dies irgendetwas mit den genannten GPO Fehlern zu tun haben?

Hi Norbert, Rechner ist sauber in der Domäne. IPv6 ist schon immer komplett disabled. IPv4 kommt über DHCP. In dieser Richtung sieht alles sauber aus. Ich habe jetzt den Rechner trotzdem einmal aus der Domäne genommen, neu gestartet, Rechner wieder in die Domäne gesetzt, neu gestartet. > keine Änderung, Zeit bleibt weiterhin falsch - GPO scheint also wieder nicht übernommen worden zu sein. Daraufhin GPRESULT erneut laufen lassen. Jetzt kommt als Fehler nicht mehr: Schnittstelle unbekannt, sondern: Gruppenrichtlinieninfrastruktur ist aufgrund des unten aufgeführten Fehlers fehlgeschlagen. Die angegebene Domäne ist nicht vorhanden, oder es konnte keine Verbindung hergestellt werden. Hinweis: Aufgrund einer allgemeinen Schutzverletzung wurde keine der Richtlinien der anderen Gruppenrichtlinienkomponenten verarbeitet. Daher sind keine Statusinformationen für die anderen Komponenten verfügbar. Es sind möglicherweise weitere Informationen aufgezeichnet worden. Suchen Sie über die Registerkarte "Richtlinienereignisse" in der Konsole oder im Anwendungsereignisprotokoll nach Ereignissen zwischen 20.03.2018 13:21:10 und 20.03.2018 13:21:11. In der Domäne bin ich aber drin. Der Rechner ist ohne Fehler wieder aufgenommen worden. Das Ereignisprotokoll zeigt zu der betreffenden Zeit keinen Fehler. Etwas eher gibt es allerdings eine Warnung im Log, dass "der Windows-Benachrichtigungsabonnent <GPClient> nicht verfügbar war, um das Benachichtigungsereignis zu verarbeiten. Nachtrag: Jetzt, ca. 5 min später hat er die Zeit vom DC doch übernommen, allerdings bleibt die Fehlermeldung von GPRESULT weiter bestehen.

Hallo Leute, Umgebung: 1 DC: Server 2016 Standard, ca. 18 Windows 7 Clients, aktueller Updatestand Heute habe ich durch Zufall mitbekommen, dass die Zeit meines Rechners um ca. 2 Min von der des DCs abweicht. Auf dem DC läuft eine GPO "PDC Zeitserverkonfiguration", welche nur auf den DC mit WMI Filter "PDC Emulator" angewendet wird. Außerdem ist der OU "Client Computer" die GPO "Client Zeit Sync" zugeordnet. Neben dieser gibt es nur noch eine weitere Client Rechner GPO, welche die automatische Wiedergabe auf allen Laufwerken der Client Rechner abschaltet. Andere, User-bezogene GPOs, werden angewandt. GPRESULT bringt unter dem Bereich Gruppenrichtlinieninfrastruktur folgenden Fehler: Gruppenrichtlinieninfrastruktur ist aufgrund des unten aufgeführten Fehlers fehlgeschlagen. Die Schnittstelle ist unbekannt. Hinweis: Aufgrund einer allgemeinen Schutzverletzung wurde keine der Richtlinien der anderen Gruppenrichtlinienkomponenten verarbeitet. Daher sind keine Statusinformationen für die anderen Komponenten verfügbar. Es sind möglicherweise weitere Informationen aufgezeichnet worden. Suchen Sie über die Registerkarte "Richtlinienereignisse" in der Konsole oder im Anwendungsereignisprotokoll nach Ereignissen zwischen 20.03.2018 09:55:54 und 20.03.2018 09:55:54. Das Anwendungsereignisprotokoll ist aber sauber. Wer kann mir mal einen Tipp geben, wie ich den Fehler eingrenzen und beseitigen kann? edit: der Fehler scheint nur auf einem Computer aufzutreten. Alle anderen Rechner syncen ihre Zeit mit dem DC. Außerdem bring GPUPDATE /FORCE folgendes zurück: Fehler bei der Verarbeitung der Gruppenrichtlinie. Es konnte nicht bestimmt werden, ob sich Benutzer- und Computerkonto in der gleichen Gesamtstruktur befinden. Stellen Sie sicher, dass der Benutzerdomänenname mit dem Namen einer vertrauenswürdigen Domäne übereinstimmt, die sich in der gleichen Gesamtstruktur wie das Computerkonto befindet. Die Aktualisierung der Computerrichtlinie wurde erfolgreich abgeschlossen.

Problem: Einige Rechner können die neuen Windows Updates, die seit gestern (13.12.2017) verfügbar sind, nicht einspielen. Jeder Rechner updatet sich hier selber. Installation ist immer automatisch abends beim Runterfahren. Einen WSUS gibt es nicht. Wir haben nun gestern mitbekommen, dass sich einige Rechner updaten und andere nicht. Ein manuelles Anstoßen über "Nach Updates suchen" bringt nur die Meldung: "Mit Windows Updates kann derzeit nicht nach Updates gesucht werden, da der Dienst nicht ausgeführt wird. Möglicherweise müssen Sie den Computer neu starten." Die beiden Dienste (Intelligenter Hintergrundübertragungsdienst und Windows Update) laufen aber. Alles manuelle Rumdoctorn brachte nichts. Letztendlich half nur folgendes Tool: https://gallery.technet.microsoft.com/scriptcenter/Reset-Windows-Update-Agent-d824badc Dieses setzt alle Windows Update Funktionen zurück. Danach lief es wieder.

Hi Greez, Beim Health Scan im Kontentstore auf dem Server wurden keine Komponentenspeicherbeschädigungen erkannt. Danke und Gruß Jörg

Moin Nils, nein, der Alte hatte einen anderen Namen. Heute morgen haben wir ein anderes Phänomen. Einige Rechner können die neuen Windows Updates, die seit gestern verfügbar sind, nicht einspielen. Jeder Rechner updatet sich hier selber. Installation ist immer automatisch abends beim Runterfahren. Einen WSUS gibt es nicht. Wir haben nun gestern mitbekommen, dass sich einige Rechner updaten und andere nicht. Ein manuelles Anstoßen über "Nach Updates suchen" bringt nur die Meldung: "Mit Windows Updates kann derzeit nicht nach Updates gesucht werden, da der Dienst nicht ausgeführt wird. Möglicherweise müssen Sie den Computer neu starten." Die beiden Dienste (Intelligenter Hintergrundübertragungsdienst und Windows Update) laufen aber. Muss nichts mit dem Kerberos Fehler zu tun haben. Nervt aber genauso .... :cry: Gruß Jörg

Hier mal die gesamte Ausgabe. Der Server ist registriert. Die Gesamtstruktur "DC=domäne,DC=mbh" wird überprüft. CN=MARSRV9,OU=Domain Controllers,DC=domäne,DC=mbh HOST/marsrv9.domäne.mbh/DOMÄNE RPC/14a8ea97-1b85-4d2f-afc7-a2071757799d._msdcs.domäne.mbh GC/marsrv9.domäne.mbh/domäne.mbh HOST/marsrv9.domäne.mbh/domäne.mbh HOST/MARSRV9/DOMÄNE ldap/MARSRV9/DOMÄNE ldap/14a8ea97-1b85-4d2f-afc7-a2071757799d._msdcs.domäne.mbh ldap/marsrv9.domäne.mbh/DOMÄNE ldap/MARSRV9 ldap/marsrv9.domäne.mbh ldap/marsrv9.domäne.mbh/ForestDnsZones.domäne.mbh ldap/marsrv9.domäne.mbh/DomainDnsZones.domäne.mbh ldap/marsrv9.domäne.mbh/domäne.mbh DNS/marsrv9.domäne.mbh NtFrs-88f5d2bd-b646-11d2-a6d3-00c04fc9b232/marsrv9.domäne.mbh E3514235-4B06-11D1-AB04-00C04FC2DCD2/14a8ea97-1b85-4d2f-afc7-a2071757799d/domäne.mbh Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/marsrv9.domäne.mbh TERMSRV/marsrv9.domäne.mbh TERMSRV/MARSRV9 WSMAN/marsrv9.domäne.mbh WSMAN/marsrv9 RestrictedKrbHost/MARSRV9 HOST/MARSRV9 RestrictedKrbHost/marsrv9.domäne.mbh HOST/marsrv9.domäne.mbh Bestehender SPN wurde gefunden.

Hi Greez, Dank für die Konsolenkommandos. Abfrage 1 brachte: "0 Gruppe von doppelten SPNs gefunden" Abfrage 2 brachte: 25 Zeilen Ausgabe, von HOST über RPC, GC, LDAP, TERMSRV, etc. (Da habe ich zu wenig Ahnung, um darin einen Fehler zu finden.) Am Ende stand jedenfalls "Bestehender SPN wurde gefunden" Gruß Jörg