2 Replies Latest reply on Apr 5, 2012 7:48 PM by NicoS1

    Client Migration XP > WIN7 Konzept

    bretzeli Expert
      Update: 13.06.2012

      Das Problem resp. die Herausforderung hat sich mit Enteo V7.1 gelöst. Es gibt dort ein Windows PE mit "Self Service" Funktion. Dies heisst der "Supporter" kann:

      - Den PC Namen
      - Eine Variable wählen
      - Ein Passwort angeben

      Dann wird mittels Dynamischen Gruppen das Computer Obket einer Enteo OU zugewiesen. Ich brauchte einen halben Tag um die Anleitung "OSD Self Service" ZU entschlüsseln. Leider sind absolut keine Screenshot darin enthalten. Bei der V7.1 gibt es neu einzelne PDF's pro Thema (Gut) aber die Anleitung ist mager. Gerade bei einem so heissen Eissen wie Autoinsert oder das Zuweisen von OS Sets auf dynamische Gruppen sollte dies ausführlicher sein.

      Mit viel Geduld und rätseln > Integration klappt und wir werden diese fuer eine XP > Win7 Migration nutzen.




      Hallo,
      Hallo Frank, ;-)
      Hallo Zierer und Rest der Enteo Bande ;-) Ich nenn Sie mal so...

      Ich habe einen Kunden mit Windows XP der auf WIN7 (64BIT) will. Die OS Sets fuer alle Hardware Typen haben wir fertig. Die 32/64BIT Packages auch im ganzen und groben. Von den Packages habe ich es geschaft mal nichts frei zu geben damit ich nicht in der "Revision-hell" Lande. Das mach ich ganz am Schluss...

      So sieht es aus:

      * Bestehende Hardware bleibt (Desktop/Laptop)
      * neue client (Ersatz fuer non W7 tauglich) werden vor installiert
      * Es gibt Autoinsert (Dynamische Gruppen) mit den Treibern je HP client
      * Die xxx clients werden in 10er Gruppen migriert
      * Wir werden Flexprofiles neu einsetzen (Wegen TS was aber nichts mit Enteo zu tun hat)
      * Laptops werden die XP Platten vor der Migration raus genommen und durch leere ersetzt. Dies wegen der Verschlüsselung (Nicht Bitlocker) und  neuer Verschlüsselung. (Platten wegen Fallback falls was nicht geht)

      Gibt es hierzu eine Empfehlung wie man das ganze machen soll?

      Ich meine vom zeitlichen her? Man muss ja vor dem Weekend bei den 10 PC's den Autoinsert wechseln z.B. von HP_8100_XPSP3 auf HP_8100_W7_64BIT.
      Dann das "OS Set neu zuweisen". Wir haben dies jeweils manuel auf EINEN client und nicht die gane Dynamische Gruppe zu gewiesen. Dies weil es in den OS Sets beim XP Aenderungen gab SP2/SP3 Integration.

      Wenn Die bestehenden clients jetzt in einer neuen dynamischen Gruppe W7 sind und ich "der ganzen Gruppe" ein OS Set zuzweise. Ab wann fängt er dann zu installieren oder was zu machen. 1) Erst wenn ich ein Computer neu installieren mache 2) In dem Moment wo ich es zuweise. Ohne, dass ich es jetzt teste...

      Die Zeitliche Planung dann?

      Ich wills nichts im Detail wissen nur wie das in "der Regel" dann gemacht wird mit V7? Jetzt ohne API und Scripts dafuer ist er dann wieder zu klein.

      Gruss aus der Schweiz und Danke fuer jegliche Hilfe
        • 1. Re: Client Migration XP > WIN7 Konzept
          _Mel_ Master
          sobald der rechner ne gelbe osd policy hat, wird die auch ausgeführt (außer es gibt eine rote osd policy).
          den reinstall kann man machen, muß man aber nicht. der ist hauptsächlich für den reinstall fall...

          zeitliche planung: kommt darauf an wie schnell das netzwerk und der depotserver ist. der osdproxy sollte bei halbwegs anständiger hardware nicht das bottleneck sein (im zweifelsfall das erweiterte logging vom clientproxy runterdrehen/ausschalten)
          unter last wird wahrscheinlich der tftp als erstes probleme machen (wenn clients timeouts bekommen), aber das sollte bei 10 parallelen client noch kein problem sein - ich hab auch schon gesehen, daß 100 clients in 10 sekunden abständen gestartet wurden und erfolgreich installiert wurden.

          also eine anständige umgebung (netzwerk, hardware) vorausgesetzt, würde ich sagen, daß man in einer nacht mindestens 1000 clients installieren kann.
          • 2. Re: Client Migration XP > WIN7 Konzept
            NicoS1 Master
            Hallo Bretzeli,

            auf die Gefahr hin, das ich jetzt nicht richtig verstanden habe, was überhaupt deine Frage ist. Ich persönlich würde so vorgehen:

            a) Dynamische Gruppen für die Treiber und Hardwarespezifische Pakete erstellen. Du bräuchtest nicht mal unbedingt spezielle WXP oder W7 Gruppen, da du das OS ja am Paket flaggen kannst. Aber macht es übersichtlicher. Bzw. du kannst die dynamischen Gruppen ja auch verschachteln. Eine HP_8100 Gruppe, und darunter nochmal nach XP und W7 filtern. Aber das ist kosmetik. Funktionieren würden alle 3 Varianten.

            b) Statische Gruppe(n) erstellen, für die OS Installation(en). Je Installationsstandard. Mit den Installationsvariablen und "bei zuweisung Änderbar" bist du hier ja sehr flexibel und kannst mit einem Paket alle möglichen Konstellationen abbilden.

            c) Beim Wechsel von XP auf 7, würde ich mir die Liste der Clients aus DSM exportieren (Spalte Initiale MAC einblenden und dann mit der neuen Funktion der V7 einfach in eine CSV exportieren)... und dann die betroffenen Clients löschen und neu anlegen. Einfach um sicher zu stellen, dass alle alten Policys weg sind, ansonsten hast du je nach Paket einen haufen rote Policys auf den Clients. Find ich sauberer, auch wenns etwas mehr Arbeit ist. Alternativ solltest du definitiv dann zusätzlich zum Zuweisen des OS Sets die Funktion "Computer neu Installieren" wählen, und das XP OS Set löschen, falls noch zugewiesen. Dann gehen alle Policys auf gelb, einige Basic Inventory Informationen werden zurückgesetzt und es kann nicht passieren, dass DSM auf einmal her geht, und grüne XP Policys wieder auf gelb setzt und versucht zu deinstallieren, weil ja die Serverseitigen Vorraussetzungen nicht mehr passen etc. vollständig korrektes flagging deiner Pakete vorrausgesetzt.

            d) Wenn du die Clients am Wochenende in "Päckchen" installieren willst, kannst du auch alles über statische Gruppen, oder Einzelzuweisungen vorbereiten. Sprich, alle betroffenen Clients löschen, neu anlegen mit der MAC Adresse und ein Policy Startdatum / Startzeit dem OS Set mitgeben. So kannst sicherstellen, dass die ersten 10 Clients erst um 08 Uhr betankt werden, die nächsten 10 erst um 09 Uhr usw. oder man steuerts einfach manuell, in dem man halt nur die 10 Clients anschaltet, je nachdem wie man will usw.

            Die OS Installation geht los, sobald die OS-Set Policy da ist, auf gelb steht und das Startdatum erreicht ist.

            Ich denke mal, ist alles eine Frage, wie man so einen Rollout durchführen will. Ist ein DSM-Operator dabei, kann er die Clients immer on-Demand vorbereiten, solange er wartet das die einen fertig sind... oder man bereitet alles vor und jemand geht dann rum und schaltet die Clients an... oder es geht über WOL , dann macht man ein paar Testläufe, und wenn alles klappt, macht der DSM Operator sich ein schönes Wochenende, und der Rest kann dann theoretisch von einer nicht-Fachkraft durchgeführt werden.

            So, ich hoffe dass die Infos etwas helfen

            Ich muß nur noch ehrlich gestehen, dass ich noch keinen Massen-OS-Wechsel mit Installation über OSD so durchgeführt habe... nicht mit der DSMv7 und meinem heutigen wissen. Damals wars noch Enteo v6(.0!!) und mehr mit Hand am Arm. Der letzte OS wechsel wurde während der Arbeitszeit durchgeführt und auf expliziten Kundenwunsch hin nicht über das Netzwerk...
            Dafür hatte ich dann je Hardwaretyp ein System vorinstalliert inkl. Basissoftware. Dann den DSM Client wieder gelöscht, die unattend.xml von DSM integriert, Sysprep und mit Batch noch ein kleines bisschen getrickst (wegen dem Rechnernamen in der unattend.xml)... und das ganze auf DVDs und USB Sticks verteilt.
            Somit mussten die Rollouthelfer nur noch die DVD oder den USB Stick booten, "install" eingeben, einen Rechnernamen eingeben und der Rest lief vollautomatisch. Nach im Schnitt 20 Minuten konnte der User wieder arbeiten, und der durchführende braucht nur minimale IT-Kenntnisse