Jump to content

Wisi

Members
  • Content Count

    123
  • Joined

  • Last visited

Community Reputation

10 Neutral

About Wisi

  • Rank
    Junior Member
  1. Bezüglich Office 2010 hätte ich mir auch keine großen Hoffnungen mehr gemacht, aber in 2019 sollte eigentlich schon alles funktionieren wie vorgegeben...
  2. Nachdem du ja .txt Dateien hast, schau mal bitte rein, wer der Owner von der Datei ist, bzw. wer die erstellt hat. Wird das tatsächlich über den jeweils angemeldeten Benutzer erzeugt?
  3. 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.
  4. 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. 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. 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.
  5. 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 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. 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.
  6. 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...
  7. 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?
  8. 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?
  9. 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.
  10. 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.
  11. 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 ;)
  12. Gute Frage, hab ich ehrlich gesagt gerade auch nicht gegengeprüft 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: Jupp, gab es
  13. 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.
  14. 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.
  15. 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 :)
×
×
  • Create New...