9 Replies Latest reply on Jul 17, 2018 4:14 AM by stephang

    Windows 10 Inplace-Upgrade für Remote-User

    FrankScholer Master

      Hallo zusammen,

       

      kürzlich kam bei einem Kunden die Frage auf, wie man das Windows 10 Inplace-Upgrade am geschicktesten auch Usern, die sich per VPN von Hotels, Heimarbeitsplätzen oder sonstwie unterwegs einwählen, anbieten könnte.

       

      Das neue Template für das Inplace-Upgrade, das über einen Installations-Parameter das zu verwendende OS Setup File Package referenziert, ist ja sehr schick, aber funktioniert natürlich nur in Umgebungen wirklich sinnvoll, wo eine Verbindung zum Depot mit LAN-Geschwindigkeit besteht. Gerade in ländlichen Gebieten plagen sich User noch teilweise mit einstelligen MBit-Bandbreiten beim Internet-Zugang herum und da macht es ja keinen Sinn, das Paketverzeichnis als Laufwerk zu mappen und von dort das Setup zu starten...

       

      Der Kunde hätte gerne, dass in einem solchen Fall das OS Setup File Package (auf Anforderung) in den Repository Cache gestaged werden kann - unter Ausnutzung aller bekannten Mechanismen wie Checkpoint Restart, Bandwidth Throtteling oder Neighborcast - und das Setup dann lokal aufgerufen werden kann.

       

      Stand heute gibt's sowas im Produkt ja nicht. Mein Vorschlag war im ersten Ansatz, die Sourcen per Robocopy in ein lokales Temp-Verzeichnis zu kopieren, aber das kann natürlich die genannten und wünschenswerten Eigenschaften des Stagings nicht nutzen.

       

      Was meint ihr: will man sowas haben? Soll ich im Uservoice-Bereich einen Feature Request dazu aufmachen?

       

      Allerdings kommt man, wenn man über den Wunsch auf Anforderung stagen zu können, nachdenkt, sehr schnell vom 100sten ins 1000ste. Zu Bedenken wären z.B.:

      • falls ein Paket on demand gestaged wird, wann darf das aus dem Repository Cache wieder gelöscht werden?
      • was passiert, wenn ein Paket, das ein anderes Paket im Repository Cache erwartet, ausgeführt wird und das andere Paket ist noch nicht gestaged? Wird dann ein Emergency Staging ausgeführt und der Installer wartet so lange? Oder geht er raus mit "abhängiges Paket noch nicht im Cache"? Oder geht es auf rot? Oder ganz anders?
      • was passiert bei Deinstallationen, Änderungen, Neuinstallation oder Reparaturen? Muss ggf. ein abhängiges Paket nochmals gestaged werden (großes Datenvolumen, lange Übertragungszeit), wenn es nicht mehr im Repository Cache vorhanden ist?

       

      Fallen euch womöglich noch andere Implikationen ein, die man bei so einem Feature / FR beachten müsste?

       

      Oder gibt es womöglich andere gute Ideen (außer zwei Pakete zu haben und den Remote-Usern das Paket mit den Sourcen im Extern$-Verzeichnis zuzuweisen), wie man das Windows 10 Inplace-Upgrade an schmalbandig angebundene Arbeitsplätze ausliefern könnte?

       

      Danke für Feedback, Infos und Ideen, Grüße

      Frank

        • 1. Re: Windows 10 Inplace-Upgrade für Remote-User
          nordin.markow Apprentice

          Hallo Frank

           

          Ich würde die Installation über ein normal gestagetes Paket immer vorziehen. Was passiert denn wenn mehrere 100 Clients gleichzeitig das Update aus dem Netzwerkshare installieren. Was machst du mit Usern die nur ein HTTPS Depot zur Verfügung haben?

          Lohnt sich da ein bisschin Speicherplatz auf dem/den Depots einzusparen? 5 GB mehr oder weniger machen meines Erachtens nicht viel aus. Wenn ich die gleiche Install.wim auf Server > 2012 verwende, schalte ich halt die Datendeduplizierung an dann brauch ich nichtmal mehr Platz. Also nach meinem Dafürhalten würde ich sagen den Aufwand so ein Feature zu programmieren lohnt nicht.

           

          Gruß

          Nordin

          • 2. Re: Windows 10 Inplace-Upgrade für Remote-User
            MarkusMichalski Specialist

            Moin Frank,

             

            man könnte das kopieren der Quellen auch per BITS/Powershellskript in die Aufgabenplanung von Windows eintragen:

            https://msdn.microsoft.com/en-us/library/windows/desktop/ee663885(v=vs.85).aspx

             

            Gruß, Markus

            • 3. Re: Windows 10 Inplace-Upgrade für Remote-User
              _Mel_ Master

              also wenn dein wunsch "normales staging" ist, dann wäre das ja recht einfach: per installationparameter referenzierte pakete werden genau dann heruntergeladen, wenn das zugewiesene paket heruntergeladen wird.

               

              ich würde auch nicht den speicherplatz als den hauptgrund dafür sehen, die sourcen aus dem ossetupfilepackage zu verwenden, sondern eher, daß die dateien ja auch verteilt werden müssen.

              wenn man anpassungen an den sourcen macht, muß man außerdem dafür sorgen, daß alle pakete auf demselben stand sind (sofern man das will)

               

              der aufwand hängt natürlich stark davon ab was man genau will.

              die einfache variante, die das setupfilepackage einfach dann runterlädt, wenn das escript heruntergeladen wird, sollte unter einem tag aufwand liegen - sind ja nur zwei stellen: hinzufügen zu der liste der zu cachenden pakete und vor der ausführung die prüfung ob es im cache ist.

               

              wenn man komplexere logik will, damit es nur dann wenn wirklich nötig lokal auf dem client liegt bzw heruntergeladen wird, dann bekommt man halt komplexere logik, bei der man sicherstellen muß, daß sie immer funktioniert und sowas läßt dann aufwände explodieren - wobei das, sofern man nicht völlig übertreibt, immer noch ein relativ kleines feature sein sollte.

              • 4. Re: Windows 10 Inplace-Upgrade für Remote-User
                Nico Schmidtbauer Apprentice

                Moin Frank,

                ich hab mir deinen Vorschlag mal durch den Kopf gehen lassen... und mir fällt da gerade nur eine Lösung dafür ein, die zumindest so in etwa bei mir im Kopf Sinn macht.

                 

                1. An einem Paket eine Eigenschaft / Parameter "Additionally Required Sources", in der ich ein Paket verlinken kann, dass dann mitgestaged wird.

                2. Eine weitere Eigenschaft am Paket, an der "pro Site" konfigurieren kann ob ein Paket gestaged werden soll oder online abgerufen werden soll.

                3. Ein "Platzhalter" ( wie ".\" mit dem ich auf das Paketverzeichnis des "Additional" Pakets verweisen kann).

                 

                Dann würde ich mein Source Package auf Online stellen und nur für die VPN Site auf Staging. Wird das Feature Update Paket gestaged, erkennt DSM anhand der Eigenschaften, dass noch ein weiteres Paket benötigt wird und staged dies (bei Bedarf) gleich mit.

                 

                Alles andere... z.B. über einen eScript Befehl der das Staging anstößt, würde auch dazu führen dass es während der Laufzeit des Scriptes passiert... was dazu führt... dass der Rechner auch nicht heruntergefahren werden kann usw... über ein Software Set... ein Paket mit Sourcen, ein Paket mit dem Feature Update ist man auch nicht flexibel genug dies Site bezogen zu lösen.

                 

                Mein aktueller Ansatz, um dies mit gegebenen Mitteln umzusetzen, verfolgt genau das, was Markus gepostet hat. In der VPN Site wird ein BITS Job erstellt, der die Sourcen runter läd. Im eScript für das FeatureUpdate habe ich eine Prüfung drin, ob ein Anwender via VPN Verbunden ist (je nach VPN Client eine Abfrage, im schlimmsten Fall ein ipconfig /all | find /I "vpn subnetz" mit Returncodeauswertung.

                Ist ein Anwender via VPN Verbunden, kommt eine Prüfroutine ob das Source Directory vollständig runtergeladen ist..., wenn ja => los gehts, wenn nicht => ExitProc(Undone).

                 

                Im LAN wird das direkt das OS Setup Source Package angesprochen.

                 

                Und zum Abschluss noch... sobald das Feature Update erfolgreich drauf ist, kommt ein Build-abhängiges Paket, welches mir die lokal gezogenen Sourcen wieder weglöscht.

                 

                Finde ich persönlich am sozialverträglichsten. Einerseits ist es kein Problem für Anwender die "nur mal kurz" online sind, andererseits ist auch beim Wechsel von VPN zu LAN kein Problem, dann wird das Paket nächstes mal einfach online ausgeführt. Und BITS kann man ja auch per GPO relativ nett steuern bzgl. Bandbreite.

                 

                Gruß

                Nico

                • 5. Re: Windows 10 Inplace-Upgrade für Remote-User
                  Klaus Salger Expert

                  Ja,ich will!

                   

                  So wie's Mel schon beschrieben hat.

                  OSSetupSource-Paket zusammen mit dem Win10-Upgrade-eScript stagen und ansonsten behandeln wie jedes andere Paket, also aus dem Cache entfernen, nachziehen wenn nochmal nötig, Neighborcast etc. wie üblich.

                   

                  Eine Möglichkeit das Staging unter Umständen, also z.b. in LAN-Sites -  auch zu vermeiden fände ich nett, müsste aus meiner Sicht im ersten Schritt aber gar nicht sein.

                  Was spricht gegen das Staging?

                  - es wird womöglich mehr herunter geladen als nötig

                  - es klemmt wenn nicht genug Plattenplatz da ist

                  Finde ich beides akzeptabel und wenn man partout nicht stagen möchte, dann kann man's ja wie üblich an der Policy einstellen. Das gilt dann allerdings auch das Upgrade-eScript.

                   

                  Ciao

                    Klaus

                  • 6. Re: Windows 10 Inplace-Upgrade für Remote-User
                    derniwi Master

                    Hallo,

                     

                    wenn Änderungen an DSM notwendig werden, könnte man evtl. auch noch eine Priorität für das Statging einfügen, sprich, Sicherheitsupdates hätten eine höhere Prio als einfache Programme oder das Inplace-Upgrade (natürlich für die Pakete oder Policies konfigurierbar). Damit würde der Download des Inplace-Paketes normale Pakete nicht blockieren und Pakete mit niedriger Prio werden auch erst dann dem Installer vorgeworfen, wenn sie da sind.

                     

                    Das mit der Site-abhängigen Konfiguration wäre auch für andere Pakete hilfreich. Lieber die Anwender haben draußen ein sicheres System als die aktuellste Version von XYZ.

                     

                    Gruß

                    Nils

                    • 7. Re: Windows 10 Inplace-Upgrade für Remote-User
                      FrankScholer Master

                      Hallo zusammen,

                       

                      ich habe auch mit der Entwicklung und dem Produktmanagement von Ivanti über das Thema gesprochen und wir sind übereingekommen, dass ich auf jeden Fall im Uservoice-Bereich einen Feature Request dazu eröffne. Das habe ich auch getan und würde mich freuen, wenn ihr alle dafür stimmt! :-)

                       

                      https://ivanticore.uservoice.com/forums/905674-dsm/suggestions/32598583-staging-on-demand

                       

                      Danke und Grüße

                      Frank

                      • 8. Re: Windows 10 Inplace-Upgrade für Remote-User
                        Nico Schmidtbauer Apprentice

                        Ich würde an der Stelle nochmal kurz das Thema von MarkusMichalski aufgreifen. Zum Thema Staging via BITS.

                         

                        Möchte man eine komplettes Verzeichnis via BITS Stagen, gibts hier kleinere Schwierigkeiten.

                        1. Wenn man einen BITS Transfer einrichten will, muss man jedes File einzeln angeben, eine Option ein ganzes Directory runterzuladen habe ich nicht gefunden.

                        2. Via RunAs hat es bei mir ebenfalls nicht funktioniert. Mit dem aktuell angemeldeten Nutzer funktioniert es. Fehlermeldung: "Der Benutzer ist nicht am Netzwerk angemeldet" (also Script im Userkontext laufen lassen).

                        3. Scheinbar gibt es ein Limit von 60 Bits Jobs die angelegt werden können. Ein Job der übertragen wurde, muss dann auch auf "Completed" gestellt werden (per PowerShell Befehl), bevor weitere Jobs angelegt werden können. Ein W10 Source Directory hat 900+ Files.

                         

                        Das alles zusammen hab ich mal in einem PowerShell Script zusammengefasst als Beispiel:

                         

                        # Download via BITS
                        Import-Module BITSTransfer
                        $sdir = "\\DSMServer\ni$\Work\Master\Projects\159252\extern$"
                        $tdir = "C:\W10_UPD_SRC"
                        # Target Pfad anlegen.
                        if (-NOT (test-path $tdir)) {
                            New-Item -ItemType directory -Path $tdir
                        }
                        # Alle Files des Source Directory auslesen
                        $list = get-childitem $sdir -Recurse -File
                        $list | ForEach-Object {
                         $sfile = $_.FullName
                         $tfile = $($_.DirectoryName).replace($sdir, $tdir)
                        # Ziel Ordner muss angelegt werden, wenn er nicht existiert.
                            if (-NOT (test-path $tfile)) {
                                New-Item -ItemType directory -Path $tfile
                            }
                        # BITS Limitiert auf 60 Jobs. Hier prüfen ob 60 Jobs angelegt sind. Wenn ja, alle Jobs die auf Transferred stehen Complete setzen, warten und erneut prüfen.
                            while($(get-bitstransfer).count -ge 60)
                            {
                                $jobs = get-bitstransfer
                                foreach($job in $jobs)
                                {
                                    if($job.JobState -eq 'Transferred')
                                    {
                                        complete-bitstransfer $job.JobId
                                    }
                                }
                                Start-Sleep -Seconds 5
                            }
                        # BITS Transfer starten.
                            Start-BitsTransfer -Source $sfile -Destination $tfile -Asynchronous
                        }
                        
                        • 9. Re: Windows 10 Inplace-Upgrade für Remote-User
                          stephang Apprentice

                          Das Staging on Demand Feature ist jetzt ja durch. 2018.1 setzen wir auch ein

                          Allerdings ist mir nicht so ganz klar wie wir das einbauen können vorallem weil das Feature nicht Staging on Demand in der Hilfe heißt

                           

                          Problem: 80% unserer Mitarbeiter sind "Remote Worker".

                          Wir haben für jeden Standort eine Site definiert. - VPN und HQ teilen sich ein Depot.

                           

                          Diese sollten gesteuert das Update starten können - erstmal nur im Software Shop (Staging on Demand) - dann per Popup (mit Vorstaging) - bis das ultimative Enddatum erreicht ist.

                          Ziel wäre es den Usern das Paket mit dem Upgrade vorzugsweise im Büro bereitzustellen. Auch wenn diese 10GB LTE Volumen haben. Wenn es richtung Enddatum geht - dann natürlich auch darüber.

                           

                          Grüße

                          Stephan