Wisi

vor 1 Stunde schrieb EitieOS:

Betroffen sind nur Win10 Pro 1909 und Office 2010. Mit Office 2013 und auch 365 haben wir keine Probleme.

Idee wäre ein Downgrade auf 1903 - oder Neuinstallation. Den Aufwand wollen wir uns aber sparen.

Ich habe auch fast das Gefühl, dass das 1909 hier ein entscheidender Faktor ist. Leider haben wir mit dem Rollout direkt dort begonnen, ich habe also nichts davor zum Vergleich.

Evtl. kann ich aber mal aus der Automatisierung mir eine entsprechende Kette schnell zusammenbauen.

vor 4 Minuten schrieb NilsK:

Also: "System" bezeichnet in Berechtigungen immer das lokale System. Bei einem Share wäre das also das Betriebssystem des Dateiservers. Also mit Sicherheit nicht die Instanz, die da zu schreiben versucht - das wäre ja das Betriebssystem des Clients. Diese Berechtigung passt also schon mal nicht.

Danke, Wald und Bäume, das klingt für mich in der Tat sehr logisch, hätte man selbst drauf kommen können. Aber eine Idee mit welchen Berechtigungen, bzw. welchem User etc. das Ding kommt, hast du auch nicht? Scheinen wohl eher wenige Leute zu verwenden.

vor 5 Minuten schrieb NilsK:

Dann: Man sollte auf Share- und NTFS-Ebene nicht in dieser Form die Berechtigungen unterschiedlich halten. Da NTFS das leistungsfähigere Berechtigungssystem hat, sollten nur dort die Berechtigungen stehen. Das Share wird dann für "Jeder: Vollzugriff" berechtigt.

Unser Dozent, als ich mit der Thematik vor zig Jahren angefangen habe, hat immer gepredigt, dass er "Jeder" nicht für so geeignet hält wie "Authentifizierte Benutzer". Das war beim Training für MCP Prüfungen in einem Testcenter, in dem nur geprüfte Trainer anwesend waren. Haben das bisher immer so beibehalten und uns darüber keine weiteren Gedanken beim Thema "Jeder" vs "Authentifizierte Benutzer". Was nicht heißt, dass man mal nach aktuellem Stand neu drüber nachdenken könnte, wenn der MVP schon drauf hinweist ;) Beim Rest keine Frage, so ist das bei uns auch, am Share wird nichts weiter abgefangen, es wird auf der NTFS Ebene berechtigt.

vor 7 Minuten schrieb NilsK:

Ob der Mechanismus, den du beschreibst, den Sicherheitsanforderungen genügt, die man zur Ablage von Bitlocker-Schlüsseln haben sollte, kann ich nicht einschätzen. Seltsam klingt für mich, dass du die Keys von "Standalone-Clients" in das Share legen willst. Sind die nicht Mitglieder im AD? Dann wirst du dort kaum eine sinnvolle Berechtigung vergeben können.

Nein, deshalb schrieb ich, das gilt für interne Clients als zweite Option. Bei den externen/Standalone machen wir das mit Mitteln unseres Client Managements, da dort eben keine Bordmittel greifen (können). Ich könnte theoretisch auch drauf verzichten und die internen Clients ebenso mit dem Client Management abfragen (was wir wohl auch umsetzen werden im weiteren Workflow). Man will aber ja trotzdem das Problem erfassen und lösen, bevor man es abhakt.

vor 31 Minuten schrieb MurdocX:

Das klingt interessant, dennoch sagt es nichts   Welche Berechtigung hast du denn vergeben (lesen/lesen & schreiben/ändern/vollzugriff)? 

In der Tat wieder mal zu kurz gesprungen. Das kommt davon, wenn man schon länger damit rum macht und dann denkt jeder weiß wovon man redet...

Share - Authentifizierte Benuzter -> Vollzugriff

Ordner/NTFS - Administratoren/System -> Vollzugriff

vor 38 Minuten schrieb MurdocX:

Was denkst du mit welchem Benutzer das Betriebssystem denn auf das Share schreibt?

Das wäre meine Frage an euch Experten ;) Ich hätte vermutet "System", aber ich weiß es schlicht nicht, weil ich auch noch nirgends ein System habe, wo das funktioniert, sonst hätte ich mir es dort angeschaut, wer der Besitzer ist. Leider steht es auch in keinem einzigen Tutorial, jeder legt nur die Ordner an und verweist auf die Richtlinie. Was er konkret für Berechtigungen auf Share/Ordner gesetzt hat, verschweigen sie alle.

vor 27 Minuten schrieb NorbertFe:

Wir lassen das ins AD schreiben. Ohne Verbindung zum AD gibts kein Bitlocker.

Da lass ich es normal natürlich auch rein schreiben, oder alternativ erfasst unser Client Management die Standalone Clients und beim Job der Aktivierung von BitLocker schreibt er dann direkt den Recovery Key (nach Abruf über Powershell) in die Eigenschaften des Clients und schickt nach Möglichkeit auch von dort aus direkt noch eine Mail mit den Informationen über unser eigenes Gateway.

Insofern wollte ich das Share eigentlich mehr oder weniger als "doppelten" Boden für interne Clients haben.

Mit Office 2010 kann ich unter 1909 nicht mehr dienen, das ist bei uns keine vorgesehene Definition mehr.

Aber spannend, dass du das dort auch hast. Ich habe in der Zwischenzeit auch mit den neueren Office Releases experimentiert und immer noch keine Lösung gefunden.

Rein interessehalber, setzt Ihr Kaspersky ein? Vielleicht lässt es sich ja eingrenzen...

Hallo in die Runde,

wir führen gerade großflächig BitLocker ein (rein auf TPM Basis, damit die Platte ohne Hardware in Zukunft wertlos ist) und im Prinzip funktioniert auch schon alles. Nur eine Sache kriege ich irgendwie nicht hin und zwar, dass er die Recovery Keys auch als TXT im definierten Share ablegt.

Ich habe die Richtlinie "Standardordner für Wiederherstellungskennwort auswählen" gesetzt, einen Pfad auf unserem DFS dafür festgelegt und diesen kann ich auch beschreiben. Aus der Logik her habe ich dem Share selbst die Berechtigung "Authentifizierte Benutzer" gegeben und die NTFS Berechtigung im Dateisystem ist "Administratoren und System", da ich davon ausgehe, dass das System die Datei ablegen möchte und auch kein User das lesen braucht. Allerdings hat sich bis jetzt dort nie eine .txt gebildet, wenngleich die Verschlüsselung aktiviert ist und funktioniert.

Wo liegt der Fehler, bzw. wie muss dieses Share gesetzt sein, damit es funktioniert bei euch?

Jetzt hab ich mich heute mal ran gesetzt und das Deployment aktualisiert im Bezug auf das Office und habe die neueste Version mit der Setup.exe geladen. Im Dateipfad ist dann auch die 16.0.10354.20022 vermerkt. Wenn ich jetzt damit installiere, lande ich aber wieder bei der 10352.20042. Unabhängig davon, ob es ein Upgrade, oder eine neue Installation ist. Update Check bringt auch die Meldung, dass das die neueste Version wäre.

Ich bin davon ausgegangen, dass dort dann auch die 10354.20022 stehen müsste, wenn ich dessen Source nutze? Hat wer Office 2019 Pro Plus im Einsatz zum Gegencheck?

Interessanter Ansatz, da hab ich nicht dran gedacht, aber für mich schaut das ausnahmslos ok aus...

Es gibt auf jeden Fall eine History, ich werde jetzt mal die aktuellste Version laden: https://docs.microsoft.com/en-us/officeupdates/update-history-office-2019

Wir haben installiert mit September 10, 2019 Version 1808 (Build 10350.20019), sind aktuell auf November 12, 2019 Version 1808 (Build 10352.20042) und es gibt January 14, 2020 Version 1808 (Build 10354.20022). Das teste ich jetzt als nächstes.

vor 24 Minuten schrieb zahni:

Eigentlich wird die geschützte Ansicht mit diesen Einstellungen überall aktiviert, bis auf die  vertrauenswürdigen Speicherorte. Die sind bei uns als UNC-Pfad per GPO hinterlegt. 

Das war auch unser Plan, nur leider können die Leute dann derzeit keine Excel oder Word Dokumente im Anhang öffnen, weil diese immer beschädigt angezeigt werden. Haken raus und es geht. Aktuell also so nicht umsetzbar.

Gibt es vielleicht irgendwo eine Übersicht welche Office 2019 Versionen released wurden? Evtl. haben wir bei unserer Deployment Vorbereitung eine Version erwischt, die schon ersetzt wurde... Man kann das ja nur noch per Setup zum Download antriggern.

vor 20 Minuten schrieb NorbertFe:

Kann ich grad mangels Office 2019 nicht testen. Ich meine mich aber zu erinnern, dass man weitere Settings für den protected view zur Verfügung hat. evtl. kollidieren die ja an einer Stelle.

Da wir aktuell absichtlich keine Abweichungen vom Standard eingestellt haben an der Stelle, abgesehen von den oben beschriebenen Optionen, wäre das zwar schizophren von MS, aber nicht ausgeschlossen ;)

Zitat

Gabs da überhaupt die von dir geschilderten Optionen? :)

Gute Frage, hab ich ehrlich gesagt gerade auch nicht gegengeprüft

Zitat

Ich überlege grad, was jetzt das eigentliche Problem ist? Können die Dateien nicht geöffnet werden, sind sie defekt, oder stört die NUtzer nur, dass das Handling aufgrund der Sicherheitsoptionen jetzt ein anderes ist als mit Windows 7 und Office 2010?

Die Dateien lassen sich dann nicht öffnen, es ist also gar nicht erst möglich damit zu arbeiten (Office behauptet Datei ist defekt, dieselbe kann bei deaktivierter Option aber problemlos geöffnet und auch bearbeitet werden). Beim Handling würde ich einfach verlangen, dass die Mitarbeiter da mitdenken zwecks der Warnung oben im Office und dann ist das eben so. Aber dass diese es gar nicht erst öffnen können, ist natürlich ein Problem :)

Nachtrag:

Zitat

Gabs da überhaupt die von dir geschilderten Optionen? :)

Jupp, gab es

Hi, du hast recht... Man sollte sowas nicht zwischen zwei Telefonaten abschicken, weil die Zeit knapp ist. Das hilft keinem weiter. Ich hoffe es ist jetzt klarer.

Hallo in die Runde,

während unseres Windows 10 Rollouts kamen immer mal wieder Klagen auf wegen Anhängen an Emails und dem Öffnen selbiger im Office. Zudem das Problem, dass auch Dateien auf Netzlaufwerken als Defekt gemeldet werden beim Öffnen.

Nach kurzer Suche war klar, dass es mit der "Geschützten Ansicht" aus Office zusammenhängt (Beispiel Screenshot aus Word). Deaktiviert man diese Option(en), dann funktioniert es alles auf Anhieb und wie gewohnt.

Bei den Netzlaufwerken haben wir das damit gelöst, dass wir den UNC Pfad zu unserem DFS in die "Vertrauenswürdigen Speicherorte" hinzugefügt haben, damit war das Thema dann erst mal erledigt und wir konnten die Haken gesetzt lassen.

Bei den Anhängen bringt das aber leider keinen Fortschritt, da eine der Optionen ja explizit mit Outlook zusammenhängt. Gemäß BSI Empfehlung (https://www.allianz-fuer-cybersicherheit.de/ACS/DE/_/downloads/BSI-CS/BSI-CS_138.pdf?__blob=publicationFile&v=9) soll man das entsprechend eigentlich auch nicht deaktivieren, wenngleich wir das derzeit machen, um einen Betrieb sicherzustellen.

Wir hatten davor Windows 7 Pro mit Office 2010 Pro Plus und keinerlei Probleme in der Hinsicht. Auch auf den Clients, welche zwischendurch zum Test für den Rollout schon installiert wurden und Office 2013 installiert ist, tritt das Problem nicht auf. Allerdings ist dort auch 1809 verwendet worden und nicht 1909, insofern vermutlich sehr schwierig zu vergleichen, da einfach zu viele Änderungen dahinter sind.

Berichte dazu gibt es bspw. hier, wobei eigentlich alle darin enden, dass man es deaktiviert...:

https://community.spiceworks.com/topic/2219489-having-to-disable-protected-view-in-outlook-attachments-in-excel-word-etc-why

https://www.msoutlook.info/question/884

https://www.remosoftware.com/info/outlook-2016-error-opening-word-or-excel-attachment-file

Hat noch jemand von euch das Problem in der Konstellation Windows 10 Pro 1909 und Office 2019 Pro Plus? Natürlich könnten wir das jetzt via GPO einfach deaktivieren, aber wir sind immer noch auf der Suche nach dem auslösenden Problem.

Vielleicht hat ja noch jemand anders Erfahrungen damit und kann hier berichten.

Du hast auch sicherlich in deinem Klientel nicht viele aus den folgenden Personengruppen (und das ohne es böse zu meinen und ohne konkrete Reihenfolge): Lehrer, Pädagogen, Hausmeister, Putzfrauen um mal die härtesten Gruppen zu nennen ;)

Die machen Ihren Job, aber haben halt von dem Rest wenig Ahnung. Das ist auch in Ordnung, dafür sorge ich dann halt für Laufwerke :)

Das stimmt in der Theorie, dann würde ich aber auch auf den anderen Adressen nach diesem Stil Mails erwarten und diese sind sauber.

Gegen VMWare und Veeam spricht mittlerweile aber auch, dass dort weitere Emailadressen nach dem Schema vorhanden sind und diese auch sauber sind.

Aber ich habe noch mal nachgeschaut was an Mails aufgelaufen ist, es gibt noch zwei weitere Hersteller (TE-Systems und C4B, falls das jemand prüfen möchte) denen wir diese Emailadresse anvertraut haben und da sind keine von den anderen hinterlegt. Insofern werde ich jetzt beobachten ob es bei der einen Adresse bleibt...

Mir ging es auch erst mal darum zu schauen ob jemand von euch evtl. ähnliches die letzten Tage gesehen hat um eben die beiden ausschließen zu können. Könnte evtl. jemand die beiden Firmen aus dem Topic löschen, da es zu dediziert ist an der Stelle?

Danke!

Statische Laufwerke halte ich für keine sinnvolle Idee in einer Umgebung mit 500 Clients ;) Wäre natürlich aber möglich.

Aber wie gesagt, wir bauen jetzt um und dann muss ich mich nicht mehr ärgern...

Hi, leider nicht dieses Problem. Dann würde das Skript ja gar nicht ausgeführt werden (das kannte ich auch schon...). Es wird aber ausgeführt und es funktioniert an sich auch. Nur wird der erhöhte Adminkontext nicht mit dem niedrigeren Userkontext verknüpft. Das ist ja der Sinn von EnableLinkedConnections.

Schau mal vorne in den Screenshots, dann siehst du was gemeint ist. Nach dem normalen Anmelden sind die Laufwerke ja gemappt worden, nur im falschen Kontext.

Wenn du die UAC abschaltest, dann hast die Laufwerke auch wieder (weil es keine verschiedenen Kontexte mehr gibt).

Manuell kannst du alles machen. Nur beim Logon gehts halt nicht. Wenn ich dasselbe Skript noch mal ausführe, ist auch alles gut.

Schau dir mal meine Screenshots vorne an, dann siehste was passiert. Die Laufwerke werden im erhöhten UAC Kontext gemappt...

Und Systemwiederherstellung bringt ja nichts, weil du das alles problemlos mit den Updates "regulär" reproduzieren kannst. Ganz ohne Wiederherstellung. Patch drauf -> geht nicht. Patch deinstallieren -> geht. Auf demselben System. Mehr brauchts nicht um festzustellen, dass in den Patches ein Problem drin ist.

Naja, trauriges Fazit: nachdem es Microsoft nicht fertig bringt, ist die erste Handlung Anfang nächsten Jahres die Umstellung auf GPP in allen Domänen. Dafür müssen wir das ganze Anmeldethema überarbeiten. Sehen wir es positiv, die vor kurzem durchgeführte Bereinigung macht die Umstellung leichter und transparenter.

Hallo,

ich teste das ja auf meinem Client zuerst. Das Problem tritt übrigens auch auf 10/2012 R2 auf. Da stört es mich aktuell nur nicht, weil keine Arbeitsworkstation bei uns damit vorhanden ist. Insofern also auch keine Lösung.

Es lässt sich ohne Systemwiederherstellung ganz einfach lösen indem man die Patches deinstalliert, soweit funktioniert der Prozess zumindest sauber.

Problem dabei: da es kumulativ ist, fehlen dir zig Updates in der Zwischenzeit, weil du ja nicht den einen Problempatch rausnehmen kannst wie früher.

Wie zu erwarten: auch im Dezember Update kein Fix. Wann endlich wird das gefixt?

Hallo,

hat jemand evtl. in den letzten Tagen auf Lizenz Emailadressen auch direkt adressierten Spam bekommen? Wir haben auf einer Emailadresse, die nur zum Empfang von Lizenzinformationen bei Veeam und VMWare eingerichtet ist und auch nie zum Versand benutzt wird, Spams bekommen. Auf der Standardadresse nicht weiter verwunderlich, aber auf dieser ganz speziellen Adresse, auf einer Domain auf der auch nur genau diese eine Adresse überhaupt angelegt ist (keine Onlinepräsenz, nichts), verwundert mich das sehr...

Puh, ganz toll, das nächste Update, welches den Fehler hervorruft (eigentlich klar, weil kumulativ). Hatte gehofft Microsoft hätte das in der Zwischenzeit geklärt.

Dann mal die Frage: wo genau kann ich das eigentlich melden, bisher sind die Fehler immer von selbst behoben worden oder das Update wurde sowieso zurückgezogen...

Betroffenes Update bei uns: November 2016 – monatliches Sicherheitsqualitätsrollup für Windows 8.1 für x64-basierte Systeme (KB3197874)

So, das erste Update ist schon mal gefunden: KB3192392. Allerdings ist es das wohl nicht alleine. Bei mir ist das Problem vorhanden sobald installiert und weg nachdem deinstalliert. Beim Kollegen ist das Problem aber nach Deinstallation noch vorhanden.

Edit: da gibts mit dem Update derzeit wohl auch noch deutlich mehr Probleme, siehe http://www.borncity.com/blog/tag/kb3192392/

Edit2: auch das andere Update KB3185331 was dort genannt wird, erzeugt das Problem

Fazit für mich: die beiden Updates sind derzeit nicht zu empfehlen. Jedes von den beiden für sich alleine reicht um das Problem hervorzurufen. Test beim Kollegen ebenso erfolgreich abgeschlossen. Die beiden runter und alles passt.

Edit3: Unter Windows 7 installieren wir das entsprechende KB3192391 aber - ohne Probleme. KB31292393 wiederum unter 2012 genau das gleiche Thema wie unter 8.1 (war aber fast zu erwarten).

Edit4: Nachdem ich schon dabei bin: KB3192403 für Windows 7 geht, KB3192404 und KB3192406 selbes Spiel -> Finger weg

Das war mir soweit eigentlich schon klar was da passiert. Frage ist nur, warum funktioniert es jetzt NICHT mehr...

Hast du intern keinen IIS laufen, auf welchen du den DNS Eintrag mappst und dort machst einfach einen Index mit Redirect drauf?

Ich werde mir den Spaß auch mal bei der 8.1 Version machen:

- zuerst mal ohne UAC (ich erwarte, dass das dann problemlos funktioniert)

- Zuweisung via GPP mit UAC an (erwarte, dass auch das funktioniert)

- ein Update nach dem anderen aus Oktober deinstallieren (darauf deutet es ja derzeit hin)

Dann müsste ja irgendein Ergebnis raus kommen und wir wissen was noch geht und was nicht und v.a. was es auslöst.

Aber gut, dass wir jetzt schon mal einen Ansatz haben und dass auch noch jemand anders seit den Oktober Updates Probleme hat.