Jump to content

steal2k

Members
  • Gesamte Inhalte

    30
  • Registriert seit

  • Letzter Besuch

Profile Fields

  • Member Title
    Newbie

Fortschritt von steal2k

Contributor

Contributor (5/14)

  • Erste Antwort
  • Engagiert
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei

Neueste Abzeichen

10

Reputation in der Community

  1. Hallo zusammen, gibt es keinen Experten, der diesbezüglich eventuell einen hilfreichen Tipp hätte? Danke und Gruss, Steal2k
  2. Hallo zusammen, nach langem hin und her, bin ich nun gezwungen, aufgrund eines merkwürdigen Verhalten einen Forumthema zu erstellen. Ausgangslage: Im unserem Unternehmen ist Office 2010 Professional eine Basisanwendung. Zusätzlich bieten wir Softwarepakete an, um nachträglich u.a Access, Project, Visio, InfoPath, ... zu installieren. Die Sourcen liegen in unserem Netzwerk. Bei der Office-Installation verweisen wir somit auf den jeweiligen Ordner im Netzwerk - die Installation funktioniert tadellos. Ziel: Alle neuen Office-Patches (auch für sämtliche Folgeprodukte) in den Installationsprozess aufnehmen, damit nicht bei jeder Neuinstallation die Patches vom WSUS bezogen werden - dies soll als eine erhebliche Erleichterung für unseren Service-Desk dienen (Zeitersparnis). Im Grunde keine grosse Hexerei, aber... Problem: Nachdem sämtliche offene Office-Patches heruntergeladen, entpackt und in die Office-Source im Netzwerk (Update-Ordner) hinzugefügt wurden, will der Client nach einer Neuinstallation die bereits integrierten Patches vom WSUS erneut beziehen. Dies ist nicht bei allen Patches der Fall, aber bei sehr sehr vielen. Einige Tests haben dann gezeigt, dass die heruntergeladenen Patches die z.B: bereits im Update-Ordner der Office-Installation vorhanden sind, zusätzlich noch in die Source von z.B: Project hinzugefügt werden muss. Gehen wir mal davon aus, dass zuerst nur Office in der Grundkonfiguration installiert ist - der Client verlangt per WSUS keine Patches. Im Nachhinein wird dann das Softwarepaket "Project" hinzugefügt - und jetzt werden über 15 Patches über WSUS abgerufen. Der Haken an der Geschichte ist, dass die jeweiligen Sourcen der Patches bereits im Update-Ordner des Office UND des Project schon vorhanden sind. Warum also, will der Client die Patches erneut beziehen? Gibt es auch eine andere Möglichkeit, Office-Patches in die Installation zu integrieren? Ich hoffe ich habe es halbwegs verständlich erklärt... jetzt freue ich mich über eure Feedbacks und bin sehr gespannt. Im Voraus danke für eure Bemühungen. Gruss, Steal2k
  3. Hallo zusammen, nach langem hin und her, bin ich nun gezwungen, aufgrund eines merkwürdigen Verhalten einen Forumthema zu erstellen. Ausgangslage: Im unserem Unternehmen ist Office 2010 Professional eine Basisanwendung. Zusätzlich bieten wir Softwarepakete an, um nachträglich u.a Access, Project, Visio, InfoPath, ... zu installieren. Die Sourcen liegen in unserem Netzwerk. Bei der Office-Installation verweisen wir somit auf den jeweiligen Ordner im Netzwerk - die Installation funktioniert tadellos. Ziel: Alle neuen Office-Patches (auch für sämtliche Folgeprodukte) in den Installationsprozess aufnehmen, damit nicht bei jeder Neuinstallation die Patches vom WSUS bezogen werden - dies soll als eine erhebliche Erleichterung für unseren Service-Desk dienen (Zeitersparnis). Im Grunde keine grosse Hexerei, aber... Problem: Nachdem sämtliche offene Office-Patches heruntergeladen, entpackt und in die Office-Source im Netzwerk (Update-Ordner) hinzugefügt wurden, will der Client nach einer Neuinstallation die bereits integrierten Patches vom WSUS erneut beziehen. Dies ist nicht bei allen Patches der Fall, aber bei sehr sehr vielen. Einige Tests haben dann gezeigt, dass die heruntergeladenen Patches die z.B: bereits im Update-Ordner der Office-Installation vorhanden sind, zusätzlich noch in die Source von z.B: Project hinzugefügt werden muss. Gehen wir mal davon aus, dass zuerst nur Office in der Grundkonfiguration installiert ist - der Client verlangt per WSUS keine Patches. Im Nachhinein wird dann das Softwarepaket "Project" hinzugefügt - und jetzt werden über 15 Patches über WSUS abgerufen. Der Haken an der Geschichte ist, dass die jeweiligen Sourcen der Patches bereits im Update-Ordner des Office UND des Project schon vorhanden sind. Warum also, will der Client die Patches erneut beziehen? Gibt es auch eine andere Möglichkeit, Office-Patches in die Installation zu integrieren? Ich hoffe ich habe es halbwegs verständlich erklärt... jetzt freue ich mich über eure Feedbacks und bin sehr gespannt. Im Voraus danke für eure Bemühungen. Gruss, Steal2k
  4. Hallo Community, gibt es zu meiner obenstehenden Anregung/Frage noch etwas hinzuzufügen? Bin um jeden Tipp/Anregung sehr dankbar. Gruss, Steal2k
  5. Hallo Community, ich danke euch für eure Inputs. Wir haben uns dazu entschlossen, den SP2 per WSUS zu verteilen. Herzlichen Dank. Gruss, Steal
  6. Hallo IT-Community, würdet ihr in einer grösseren Firmenumgebung (+ 5000 Clients) den SP2 für das Office 2010 unbedingt verteilen? Die ganzen enthaltenen Sicherheitspatches etc. sind bei uns bereits auf den Clients per WSUS installiert. Reichen Gründen für den SP2 wie Stabilität und Kompatibilität für Windows 8 aus? Es gibt natürlich mehrere Optionen, den SP2 im Unternehmen zu verteilen. WSUS und die Softwareverteilung. Für welche Variante habt ihr euch in der Vergangenheit entschieden und was waren die Gründe dafür? Freue mich auf viele verschiedene und konstruktive Feedbacks. Grüsse, Steal.
  7. Möchte mich an dieser Stelle für eure informativen und interessanten Rückmeldungen bedanken! Zum Teil hat es sich mit meiner Meinung gedeckt und zum anderen konnte ich noch weitere Update-Möglichkeiten (LUP) dazulernen. PS: Im Moment sieht es stark nach einer "Bedarfslösung" aus. Eine präventive Update-Strategie kommt derzeit nicht in Frage! Gruss, steal
  8. Hatte ein kleines Problem mit dem Posting - jetzt ist er aber aktiv. Sorry!
  9. 1.) Den Thread habe ich deshalb eröffnet, um mir mehrere Meinungen einholen zu können. Zu Beginn dachte ich ebenfalls, dass nur bei Störungen ein zentrales Treiberupdate erfolgen sollte. Trotzdem war es für mich wichtig, dies auch von anderen Administratoren bestätigen zu lassen. In solchen Themen können mehrere Meinungen/Tipps doch sehr hilfreich sein! 2.) Ein Kurz-Anleitung habe ich vom LUP gelesen - anschliessend bin ich davon ausgegangen, dass dies nicht auf die schnelle zu implentieren ist. Es fehlt in diesem Thema schlichtweg das Know-How und unsere Auftraggeber pochen auf eine relativ rasche Lösung. 3.) Die LAN-Treiber sind in der Tat eine heisse Geschichte. Bei uns hat es zur Zeit den anschein, dass es sich in erster Linie um Grafikkarten-Treiber und Chipset-Treiber handeln wird. 4.) Unsere Ziele sind relativ klar. Wir wollen eine Möglichkeit haben die es uns ermöglicht, im Störungsfall rasch reagieren zu können (sollte ein bestehender Treiber irgendwelche seltsamen Dinge generieren). Als kleines i-Tüpfelchen wäre es natürlich toll, wenn man die ausgearbeitete Möglichkeit auch präventiv anwenden könnte (sollte das so überhaupt gewünscht werden. Aus unseren letzten Antworten haben wir ja festgestellt, dass das Risiko vermutlich zu hoch ist). Gruss, Steal
  10. Hallo zusammen, Danke für die ersten informativen Anmerkungen. Ich versuche nun auf die markantesten Punkte einzugehen: - natürlich soll es keine Arbeitsbeschaffung sein -> im Gegenteil: der Aufwand sollte sich in Grenzen halten. - mögliche Nebenwirkungen sind auf alle Fälle nicht zu unterschätzen -> es war ebenfalls mein erster Grundgedanke, nur im Störungsfall einen Treiber-Rollout vorzunehmen. - mit WUP/LUP habe ich absolut keine Erfahrung -> gehe ich richtig davon aus, dass der Aufwand etc. zu hoch dafür ist? - im Moment sehe ich einen möglichen Treiber-Rollout am ehesten mit der aktuellen Software-Verteilung -> schnelle und Ressourcen schonende Vorgehensweise (keine weitere Infrastruktur/Server/Tools) notwendig. Gibt es von eurer Seite noch andere hilfreiche Inputs, die man berücksichtigen sollte? Generelle Vor- Nachteile? Grüsse, Steal
  11. Hallo IT-Community, zur Zeit beschäftige ich mich mit dem Thema "zentrale Treiberverwaltung für Windows Clients in einem Unternehmen". Nach mehreren interessanten Gesprächen mit anderen IT-Profis möchte ich nun auch eure Meinung/Ratschläge/Ideen zu diesem Thema hören. Es handelt sich hierbei um ein Unternehmen mit über 3.000 Windows Clients. Ziele: - im Störungsfall zeitnah reagieren zu können (z.B aktuellen Treiber ausrollen) - vorbeugende Massnahmen treffen (z.B: bei fehlerhaftem Verhalten von div. Hardware) Folgende interessante Fragen gäbe es zu beantworten: a) Gibt es ein Server-Tool, mit dem man eine zentrale Treiberverwaltung/Deployment betreiben kann? b) Soll man in regelmässigen Abständen Treiber-Updates durchführen oder nur in Störungsfällen? c) Treiber-Deployment über die Softwareverteilung (Erfahrungen, Vorteile, Nachteile)? d) ... jede weitere Anmerkung ist hilfreich. Danke und einen schönene Abend. Euer, steal2k
  12. Hallo zusammen, ich werde mich die nächsten 2 Monate intensiv mit dem Buch "Windows 8 für Administratoren" auf die Prüfung 70-687 vorbereiten. Das Buch ist keine klassische Prüfungsvorbereitung wie ein MS-Press, dennoch würde ich gerne von euch wissen, ob man mit der Erfahrung in Kombination mit diesem sehr technischen Buch die Prüfung bestehen kann? Oder muss man sich wirklich ein Buch organsieren, wo man Beispielfragen bekommt und einen genauer auf die möglichen Fragen vorbereitet? Eure Einschätzung wäre toll. Danke und Gruss, Steal2k.
  13. Hallo zusammen, ich versuche gerade div. Applikationen mit dem Microsoft Application Virtualization Sequencer zu virtualisieren und anschließend auf dem APPV-Server zur Verfügung zu stellen. Nun in möglichst guten Stichworten meine Situation: - Software X virtualisiert und auf dem Server importiert (*.sprj File) - im dazugehörigen *.osd File den Pfad auf den APPV-Server angepasst - Software X auf dem Client sichtbar, aber lässt sich nicht starten --> Fehlermeldung: "Application Virtualization Client konnte Software X nicht starten. Das angeforderte Paket wurde nicht im Systemdatenspeicher gefunden, oder die diesem Paket zugeordneten Dateien wurden nicht auf dem Server gefunden. Fehlercode: 4615186-1690140A-20000194" - die benötigen Dateien liegen jedoch auf dem gewünschten Share ( \\appvserver\content\... - der Client hat auch Zugriff auf den Share - bei der Installation wird als Vorführeffekt eine Default Application mit installiert. Diese Software wird auf dem Client angezeigt und lässt sich seltsamerweise auch starten!!?? Ich haben nun in diversen Foren einige Beiträge gefunden (Computerkonto auf NTFS Basis eintragen, APPV Service Berechtigungen prüfen, etc.) aber all das hat nichts gebracht. Zu beachten bleibt, dass die Default Software sich nach wie vor starten lässt, aber alle neu erstellen Applikationen nicht mehr. Bin um jede Idee / Tipp sehr dankbar. Greets.
  14. Hallo Community, nun hab auch ich meine erste Microsoft Prüfung erfolgreich abgeschlossen. Die vielen Lernwochen haben sich nun gelohnt. Nun ein kleiner Überblick über meine Prüfung: a) Überwachung/Fehlerbehebung b) Deployment c) BranchCache d) viele Fragen zu EFS und NTFS Berechtigungen nur einzelne Fragen aus den Bereichen Netzwerk, Internet Explorer und WSUS! Greets.
  15. Vielen Dank für die Antwort. Ich werde versuchen, die Beispiele im Buch zu machen, um mir die Praxis näher zu bringen.
×
×
  • Neu erstellen...