3 Replies Latest reply on Jul 20, 2017 5:01 PM by luckydevil

    DSM-Services mit dem Hardwarelieferanten verknüpfen, zwecks OS Deployment (Erstinstallation). Pro und Contra

    luckydevil Specialist

      Hallo Forum,

      DSM-Services mit dem Hardwarelieferanten verknüpfen, zwecks OS Deployment (Erstinstallation). Pro und Contra?

      Wie sind Eure Erfahrungen?

      Reicht evtl. OS-Quelle dem Hardwarelieferanten zu übergeben. Rest erfolgt dann über AD-Join (inkl. Gruppenrichtlinie: DSM-Client installation) --> Damit ist die Hardware auch in der DSM-Umgebung bekannt.

      ODER

      Vollständige DSM-Services in abgesicherten Bereich des Hardwarelieferanten aufbauen, damit der Hardwarelieferant (weltweit) dem User (bis auf Userprofil&DSM-User-Part alles FIX&FERTIG inkl. TPM-Bitlocker, Asset&Inventory-Themen) die Hardware zukommen lassen kann.

      Viele Grüße

      lucky devil

        • 1. Re: DSM-Services mit dem Hardwarelieferanten verknüpfen, zwecks OS Deployment (Erstinstallation). Pro und Contra
          Klaus Salger Expert

          Hi lucky devil,

           

          interessantes Thema.

           

          Ich denke, die beste Lösung hängt vor allem von der Menge und den Logistik-Prozessen bzw. ganz allgemein von den Anforderungen ab.

          Ich nehme mal an, dass es hier um die direkte Lieferung der Hardware an den Arbeitsplatz geht und wir von größeren Mengen von neu auszuliefernder Hardware reden.

           

          Von Erfahrungen kann ich nicht berichten, hier mein Einschätzung:

           

          Variante 1 - Lieferung mit vorinstalliertem OS

          Man spart sich nach der HW-Lieferung den PXE-Boot und die OS-Installation - einige GB Traffic und ca. 20 Minuten Zeit.

          Wenn der der Lieferant regelmäßig die aktuellen Cumu-Patches integriert bzw. vorinstalliert käme nochmal etwas Traffic- und Zeit-Ersparnis für das erste OS Patching dazu.

          OSD muss ich aber weiterhin bereitstellen und betreiben weil evtl. mal eine Reinstallation am Arbeitsplatz nötig ist.

          Und Patchen muss ich ja ohnehin laufend.

           

          Wenn man bedenkt, dass dazu auch noch alle halbe Jahre neue Feature Updates kommen (wir reden von Win10, oder?) und sich im Zuge dessen womöglich auch mal die Konfiguration ändert wird's schon relativ mühsam. Die gelieferte Konfiguration soll ja möglichst immer aktuell sein.

           

          Statt das ganze Thema selbst in der Hand zu haben, muss man sich mit dem Lieferanten abstimmen bzw. auch ständig neue Images liefern.

          Der Gewinn ist hier also übersichtlich und steht m.E. in keinem günstigen Verhältnis zum einmaligen und laufenden Aufwand bzw. dem Verlust an Flexibilität.

           

          Pro

          • etwas schneller bei Erstinstallation
          • etwas geringere Belastung der Ressourcen

           

          Contra

          • mehr Komplexität
          • weniger flexibel

           

          Variante 2 - Lieferung komplett fertig per DSM vorinstalliert

          Finde ich ganz interessant - der Lieferant betreibt die Installationsstraße direkt selbst und liefert komplett vorinstalliert an den Arbeitsplatz.

          Spontan sehe ich ein Datenschutz-Problemen: physischer Zugriff bedeutet letzten Endes auch Zugriff auf alle lokalen Daten incl. Passwörter und Keys. Während der Installation noch mehr als sonst.

          Ansonsten verursachen Anbindung, Aufbau und Betrieb der DSM-Infrastruktur beim Lieferanten natürlich Aufwand. Das dürfte wohl etwas über dem Aufwand für einen zusätzlichen Standort sein.

          Entscheidend ist hier m.E. wer was macht.

          Wenn der Lieferant nur Computer in seiner Installationsstraße an- und abstöpselt und die interne IT die Konfiguration in DSM macht, dann mag sich der organisatorische Aufwand und überhaupt die Änderungen gegenüber dem tradistionellen System in Grenzen halten.

           

          Was mich auch bei der Variante nicht vollständig überzeugt ist, dass die Ersparnis sich doch in Grenzen hält.

          Wenn man die interne Installationsstraße durch die des Herstellers ersetzt mag das aber bzgl. Logistik schon nütlich sein.

           

          Pro

          • schnelle Erstinstallation (auch in Außenstellen)
          • geringe Ressourcenbelastung (auch in Außenstellen)

           

          Contra

          • Implementierungsaufwand
          • komplexer (Berechtigung für externe Admins?, Arbeitsteilung, extra Standort, interne + externe Netze)
          • Koordinationsaufwand intern / extern
          • Datenschutz-Problem

           

          Variante 3 - Lieferung nur der nackten Hardware incl. BIOS-Config + HW-Infos

          Konfiguration BIOS u.a. mit PXE + WoL durch den Lieferanten

          Übermittlung der Mac + SMBios GUID durch den Lieferanten und Import der Computerobjekte in DSM im Vorfeld der Lieferung.

          Import und Konfiguration OU- und Gruppenmitgliedschaften werden von der internen IT erledigt.

          Komplette Installation OS und Applikationen am Arbeitsplatz.

           

          Anstöpseln, vollautomatische Installation, fertig für die Benutzeranmeldung innerhalb von 2 Stunden (oder so).

          Flexibel, unabhängig vom Liefanten, ohne großen organisatorischen Aufwand.

           

          Pro

          • volle Kontrolle
          • flexibel
          • einfache Schnittstellen
          • Datenschutz gewährleistet

           

          Contra

          • Erstinstallation langsamer
          • höhere Belastung der Ressourcen (insbesondere bei Massenrollouts und in Außenstellen)

           

           

          Wenn man schon eine interne Installationsstraße betreibt und die durch die des Lieferanten ersetzen möchte, dann finde ich Variante 2 interessant. Vorausgesetzt die Stückzahlen rechtfertigen den Aufwand.

          Ansonsten finde ich Variante 3 schon ziemlich gut.

           

          Ciao

            Klaus

          1 of 1 people found this helpful
          • 2. Re: DSM-Services mit dem Hardwarelieferanten verknüpfen, zwecks OS Deployment (Erstinstallation). Pro und Contra
            Nico Schmidtbauer Apprentice

            Hallo Lucky_Devil,

            ich sitz so gesehen auf beiden Seiten, einerseits als Admin, der den "Managed Workplace" bei Kunden betreut, andererseits als jemand dessen Mutterkonzern genau solche Services anbietet.

             

            Ich gehe mal von uns aus... wir haben insgesamt 4 verschiedene Szenarien:

            1. Installation beim Kunden vor-Ort (entweder durch Kunde selbst, oder durch Onsite Techniker), durch DSM:

            Hier gibt es je nach Ausprägung und Standort lange Installationszeiten. Gerade bei Branch Offices, die evtl. nicht über eigene Depot verfügen ist es entweder extrem langsam oder muss über eine Zwischenstelle bearbeitet werden (z.B. Betankung am Hauptstandort, dann weiter in die Zweigstelle).

             

            2. Installation vor-Ort via USB Stick durch Onsite Techniker:

            Das ist ein Szenario, dass wir gerne während Rollouts einsetzen. In dem Fall  haben wir eine Basisinstallation (abzüglich der nicht-Image fähigen Teile) genommen, mit Sysprep behandelt und dann einen WinPE USB Stick gemacht, der beim Booten je nach Modell die HDD Formatiert, ein WIM File bzw. den Index eines WIM Files auswählt und dann das Image aufspielt. Der Rest läuft dann via unattend.xml File bzw. DSM Client, der dann nur noch das Delta nachzieht, was sich seit Imageerstellung verändert hat, sowie die Userteile. Mit schnellen USB Sticks (z.B. den SanDisk Extreme) sind die Rechner meist innerhalb von 3-5 Minuten gestaged und booten aus eigener Kraft. Der Rest dann abängig wie viel DSM noch mache muss. Ist nur relativ aufwändig in der Vorbereitung. Lohnt sich am eheseten für einen Rollout, nicht für dauerhaften Betrieb.

             

            3. Pre-Imaged:

            Ähnlich zu Variante 2, nur dass das Image bereits auf dem Rechner ist. Die Nacharbeiten sind evtl. etwas aufwändiger, je nachdem wie gut man die per Skript steuern kann. Aber so ein Image wird halt auch ältern, und irgendwann ist man an einem Punkt, an dem das Delta vielleicht so groß wird, dass man das Image sowieso erneuern muss. Davon abgesehen finden alle 1-2 Jahre Modellwechseln statt mittlerweile, wo man sowieso regelmäßig neu liefern muss.

             

            4. Staging beim Hersteller direkt:

            Ich bin ganz ehrlich gesagt kein Experte. Bei Fujitsu wird das i.d.R. via Site2Site VPN und Depot / OSD Proxy vor Ort erledigt. Die Sicherheitsbedenken wurden ja schon geäußert zum Thema Datenschutz etc. dazu kann ich nur sagen, dass die Factory bei uns doch sehr gut absichert ist und viel auf den Security Aspekt geachtet wird Der Vorteil, zumindest bei uns, ist, dass es auch möglich ist Rechner direkt mit zu Individualisieren, also ggf. mit Software direkt für den User individualisiert zu vorsorgen (aus eurem eigenen DSM). Sprich es ist irgendwo hinterlegt... Herr / Frau Soundso bekommt folgende Software, dann steuert dass unser DeskLoad Tool direkt via Webservice im DSM. Die genaue Technik dahinter kenne ich leider nicht... dafür haben wir andere Experten. Ich selbst hatte von meinen mittelständischen Kunden leider noch keinen Fall wo wir das umgesetzt haben. Im Enterprise Segment (wo die Wahl eher richtung SCCM fällg) gibt es aber einige Kunden die da nutzen. Ebenfalls gibt es Kunden, die wir rein mit Hardware versorgen, die ein DSM Beinchen in unsere Factory gestellt haben und so ihre fertig installierten und (Softwareseitig) individualiserten Rechner bestellen. Für den Endanwender ist dass dann (fast) Plug & Play.

             

            Aus meiner Sicht macht es je nach Größe und Strukur durchaus Sinn Variante 3 oder 4 zu nehmen. Wenn ich eine Typische mittelständische Firma nehme... 5-10 Standorte, alle mit Infrastruktur vor-Ort... gehen wir eher Weg 1 oder 2. Aber gerade bei Großkunden, oder Kunden die sehr stark verteilt sind (ein Beispiel: Ein Kunde der Weltweit viele "Shops" selbst betreibt und die auch jeweile mit IT ausstattet), hat mit diesen Variante doch einige Vorteile, sei es logistischer, zeitlicher oder ggf. auch finanzieller Natur.

            1 of 1 people found this helpful
            • 3. Re: DSM-Services mit dem Hardwarelieferanten verknüpfen, zwecks OS Deployment (Erstinstallation). Pro und Contra
              luckydevil Specialist

              Großen Dank für Eure Zeit und Eure Meinung.

               

              1.

              In der Tat es geht um über 80 weltweite Standorte mit insgesamt über 10.000 Clients eines Unternehmens mit Töchtern in einer AD-Domäne.

              Bisher gibt es in jedem Standort DSM-Services (OSD. PXE mit OSD-SelfService, NetInstall), WSUS-Patch-Management., AD-Services.

              Die durchschnittliche OS-Erstinstallationszeit (inkl. AD-Join) liegt unter 20 Minuten. Restzeit wird mit individualisierter Softwareinstallation verbracht. Bisher (... und es läuft wirklich gut) erfolgt die Steuerung der Berechtigung zum Empfangen der DSM-Berechtigungen über externe dynamische DSM-Gruppen basierend auf AD-Gruppenmitgliedschaften. Variante mit USB-Stick betreiben (... auch wenn sehr, sehr genutzt) wir auch.

               

              2.

              Was leider, leider (bei uns) fehlt ist das zur Laufzeit der WinPE/OS-Installation benötigten Daten wie Computername nicht automatisch aus anderen Infrastrukturquellen (..wie SAP, Anlagenbuchhaltung, Inventarisierung) zur Verfügung stehen. Das verheiraten des Computernames mit der Hardware erfolgt also noch manuell (OSD-SelfService, DSMC). Nach der Erstinstallation mit Inventarsierungsclient landen Computername und Hardwareinfo (inkl. Service-TAG) Richtung InventariserungsMgmt. Das InventarisierungsMgmt holt sich ebenfalls die Beschaffungsdaten der Hardware aus SAP. Im Computernamen sind Buchungskreise und Tochterunternehmen hinterlegt. Erst jetzt wird erkennbar welche Hardware überhaupt in welchen Tochterunternehmen fließen. Sprich der IT-Supporter stellt diese Beziehung im DSM-OSD-SelfSerice her - Fehler sind somit schon vorprogrammiert. Ferner ist zum diesen Zeitpunkt des Computers noch keinem endgültigen Arbeitsplatz zugewiesen - Sprich: User/Workspace ist noch unbekannt.... (DELL Venue mit AutoCAD.... Uuups).

              Umgekehrt die Information zu erhalten und abrufbar zu machen wäre für alle Beteiligten besser... Ich hoffe noch...

              Man könnte es sich sogar  "ohne" die OSD-SelfService-Phase vorstellen, oder einer noch einfacheren OSD-SelfService-Phase vorstellen. Aus meiner Sicht dürfte der User als Workspace-Kenner nicht nur bei der Erstinstallation mehr mitwirken. Spätesten bei der OS-Reinstallation wird er nicht um diese Themen drum herum kommen - egal ob er es dann ausführt oder der lokale IT-Supporter. Warum denn nicht schon bei der Erstinstallation!?!  (Ich möchte nun nicht noch in das Thema Benutzerprofilmanagement verfallen.... gibt es bei uns nicht automatisiert)

               

              3.

              Inwieweit der Hardwarelieferant sich in diesem Szenario zurecht findet bleibt spannend. Zumal die Produktionstraße des Hardwarelieferanten nicht im Land des Unternehmens liegt.

              Vor diesem Hintergrund könnte, wenn man in puncto OS-Erstinstallation (gestartet wirdvermutlich im "WINDWOS as a Service"-Umfeld in Multilingualen Umgebungen -> W10 Pro, Pilot-SAC, Breit-SAC, mit Möglichkeit auf LTSB zu wechseln ... Überraschungs-SAC  -> mMn: "Eindeutig ZUVIEL SERVICE") auch an den Hardwarelieferanten herantritt, sollte (für uns) der Wunsch erfüllt werden an Punkt 2. mitzuarbeiten.

               

              4.

              Was sonst noch:

              • Nicht nur bei einem DSM-Upgrade müsste sichergestellt werden das beim Lieferanten ebenfalls alles klappt. Nicht das es heißt: Lieferant kann nicht liefern weil DSM dort nicht funktioniert.
              • Auch auf andere Kunden-Unternehmensinfrastrukturelemente (AD, SAP, etc.) müsste der Lieferant Zugriff mit "Rund um die Uhr"-Support des Unternehmens. Beide Seiten müssen diese Supportzeiten vorhalten um Lieferungen stabil zu halten. Datenschuitz &Rechtslage (international)!?!.
              • Nicht alle DSM-Pakete sind im DSM-Depot des Lieferanten aus verschiedene Gründen vorhanden.
              • Änderungen der DSM-Berechtigung während der Auslieferungszeit gehen u.a. zu Lasten auf das Zeit-,Netzwerktrafifc und Geduldskonto. -> Stichwort Provisioning und Deprovisioning
              • Auslieferung an falsche (fremde) Adressaten --> Bekommt die auf beiden seiten überhaupt mit!?!
              • weltweite Auslieferungszeiten Richtung Zielstandort müssen bekannt sein und eingehalten werden
              • Lieferantenwechsel mit mehr Aufwand
              • Ausarbeitung im Fehlerfall erhöht -> Z.B.: "nur auf Hardware mit Lieferanten-DSM tauchen Fehler auf - nicht wenn selbe Hardeware mit Unternehmen-DSM aufgesetzt wird"
              • Freigabe von Software muss immer auch in Verbindung mit Lieferanten-Umgebung (DSM-Depot und DSM-Services, AD, etc...) auf definierter Hardware erfolgen.
              • Lieferanten-DSM nur für Erstinstallation -> Wer betreut im Fehlerfall?  ->  Lierfanten-DSM zwecks Aktualisierung können UnternehmensUser nicht nutzen.
              • Wie erkennt man einfach eine Lieferanten-DSM-Erstinstallation, Unternehmens-DSM-Erst-, Neu-, Reinstallation...

               

              Viele Grüße

              lucky devil