11 Replies Latest reply on Sep 23, 2014 5:15 AM by _Mel_

    Probleme mit DSM 2014.1 und WinPE 3.x

    XN04113 Specialist
      Nach dem Update unserer Integrationsumgebung können keine Clients mehr installiert werden die WinPE 3.x booten.

      WinPE 3.0 startet
      der alte im PE enthaltene DSM Agent startet
      der DSM Agent aktualisiert sich vom Server
      danach ist Ende
      Meldung "Function ReceiverPXEAnswer returns 1 (Server not found)"
      Am BLS ist in den LOGS nichts zu sehen!

      Mit einem aktualisierten Agent im WinPE tritt der Fehler sofort auf (es muß ja nichts mehr aktualisiert werden).
      Auch ein ganz neu erstelelr WinPE 3.0 zeigt das gleiche Verhalten.

      Wenn ich ein ganz altes PE 2.x auspacke klappt die Kommunikation nach dem Agent Update problemlos, d.h. die OS Installation läuft an.

      Jemand eine Idee?

      Gruß
      Mike
        • 1. Re: Probleme mit DSM 2014.1 und WinPE 3.x
          _Mel_ Master
          du hast option 43 am dhcp server eingetragen. mit relay agents funktionierts.
          • 2. Re: Probleme mit DSM 2014.1 und WinPE 3.x
            hermixx Apprentice
            Hi,

            ich habe das gleiche Problem, sobald die Option 43 über den DHCP verwendet wird, funktioniert mit dem neuen WinPeBin Client die Kommunikation mit dem OSD Proxy nicht mehr.
            Habe auch folgenden Test gemacht, auf dem OSD Proxy das aktuelle BinClient Verzeichnis durch den Stand 2013.2 ersetzt, da funktioniert die Aktualisierung und auch die Kommunikation danach. Ticket bei Frontrange dazu habe ich eröffnet, leider bisher noch keine Rückmeldung.

            Gruß
            Reiner
            • 3. Re: Probleme mit DSM 2014.1 und WinPE 3.x
              _Mel_ Master
              genau genommen blockt die windows PE Firewall anscheinend antworten vom dhcp server auf dhcp inform anfragen, wenn der dhcp server in einem anderen subnetz steht und die antwort direkt an den client schickt anstatt an den relay agent (was dem in RFC1532 beschriebenen verhalten entspricht)
              ich hab hier allerdings einen Microsoft DHCP server (Windows Server 2008 R2), der schickt die antwort an den relay agent - sprich: es funktioniert

              setzt ihr einen dhcp server von einem anderen hersteller ein oder eine andere
              euere windows server version ?
              • 4. Re: Probleme mit DSM 2014.1 und WinPE 3.x
                _Mel_ Master
                um meine Frage selber zu beantworten: ja, alle mit dem problem setzen einen nicht MS DHCP ein.

                da das problem auch den (vermutlich völlig irrelevanten aber (im unterschied zur verwendung der option 43) supporteten) Fall betrifft, daß der OSD Proxy auf dem DHCP server läuft, gibt's dafür einen Fix im HotfixBundle 2 (das ist NICHT der, der heute veröffentlicht wurde).
                Wer nicht so lange warten will, kann beim Support die betroffenen Files vorab bekommen.
                • 5. Re: Probleme mit DSM 2014.1 und WinPE 3.x
                  XN04113 Specialist
                  Korrekt, wir nutzen Option 43 und zwar mit Lucent/Alcatel QIP.

                  Habe am Freitag noch viel getestet, speziell mit DEBUG Boot Environments.
                  Wenn man mit WPEUTIL die Firewall ausschaltet kommt der 20124.1 Client etwas weiter und findet seinen Proxy. Danach ist aber wieder Schluss. Error 21

                  Mit einem im Debug Environment enhaltenen DSM Agent 2013.2. kam ich zum Erfolg. Man muß beim Booten nur sofort den DSM Agent abwürgen, dann im Command Window über RegEdit den Parameter setzen, dass dich der Client NICHT aktualiseren darf und den Agent neu Starten. Dann geht die OS Instalaltion problemlos weiter.

                  Für mich erschliesst sich darauf, daß der 2014.1 WinPE DSM Agend buggy ist.

                  Stellt sich mir nur die Frage wie ich
                  a) den alten Client wieder ins BootImage bekomme
                  b) den REG Key dauerhaft gesetzt bekomme

                  Werde jetzt aber am Montag erst einmal wieder den Support zu unserem Ticket nerven um die "gewissen" Files zu bekommen. Hoffentlich wissen die ob man Hotfix 1 vorher oder hinterher einspielen soll/kann/muß.

                  DANKE
                  Mike
                  • 6. Re: Probleme mit DSM 2014.1 und WinPE 3.x
                    _Mel_ Master
                    ein bug ist eine abweichung vom zugesicherten verhalten - da die verwendung von option 43 nicht supported ist, kann es also auch kein bug sein, wenn damit etwas nicht funktioniert (und damit funktionieren eine ganze reihe von osd features nicht)

                    dagegen war ein fehler in den clients von der 6.0 bis zur 2013.2, weil bei dem dhcpdiscover paket, mit dem der osdprox gesucht wird, die client ip in das falsche feld geschrieben wurde und nur dadurch hat die verwendung von option 43 ZUFÄLLIG funktioniert. 2014.1 schickt ein richtig ausgefülltes dhcpinform paket und die standardkonforme antwort darauf wird von der windows pe firewall geblockt.


                    was die reihenfolge des einspielens angeht:
                    im allgemeinen sollte man zuerst das letzte hotfixbundle und danach evtl einzelpatche einspielen, damit es keine probleme mit patchen gibt, die gleiche files betreffen oder voneinander abhängen.
                    in diesem speziellen fall besteht aber keine wie auch immer geartete abhängigkeit zu anderen patchen und damit ist es egal, ob man hotfixbundle 1 vorher, nachher oder garnicht einspielt.
                    • 7. Re: Probleme mit DSM 2014.1 und WinPE 3.x
                      XN04113 Specialist
                      Als wir uns vor Jahren in einem POC für enteo entschieden haben war Option 43 das ausschlaggebende Kriterium für die Produktauswahl.
                      Bis heute ist niemand vom Vertrieb, Support und Entwicklung an uns herangetreten und hat dies wiederrufen. Somit ist das für uns eine zugesichtere Funktion
                      Was auch dadurch bestätigt wird, daß wir vor ein paar Wochen ein Review der Umgebungen durch Frontrange durchführen haben lassen und dieser Punkt nicht als beachtenswert eingestuft wurde.
                      • 8. Re: Probleme mit DSM 2014.1 und WinPE 3.x
                        _Mel_ Master
                        die funktionalität, die es zu v6 zeiten gab, wird mit option 43 auf absehbare zeit wahrscheinlich keine größeren probleme machen, da es sich dabei nur um eine kombination von funktionen handelt, die ohnehin für regulär supportete funktionalität benötigt wird.
                        anders gesagt: man müßte sich extra arbeit machen um zu verhindern, daß option 43 in diesem fall funktioniert...

                        bei funktionen die ab DSM7 dazugekommen sind, sieht das dagegen anders aus. z.B. gibt der PXE standard nur eine weiterleitung auf einen anderen bootserver her und mit der option 43 leitet der dhcp server den client bereits auf den osdproxy um und damit ist es unmöglich die bootredirection von osd zu verwenden.




                        ...warum verwendet ihr die option 43 eigentlich ?

                        mir ist bisher ein halbwegs guter grund untergekommen und der war, daß das netz (WAN ?) von einem externen dienstleiter betrieben wurde, der keine einträge für eigene bootserver angeboten hat.

                        ein noch nachvollziehbarer grund war dann eine suboptimale zusammenarbeit zwischen abteilungen (sprich: die netzwerker wollten nichts umkonfigurieren)

                        dann gibt's noch ein paar gründe, die man zusammenfassen könnte als "wir haben keinen vernünftig konfigurierbaren relay agent, aber der dhcp server ist konfigurierbar und darum machen wir's über den"

                        und der rest bewegt sich zwischen "es war uns zuviel Aufwand alles richtig zu konfigurieren" und "wir haben's nicht hinbekommen alles richtig zu konfigurieren"

                        hab ich noch was vergessen ?


                        ...ich vermute ja, daß ein großer teil auf das konto von consultants geht, die time boxed arbeiten müssen und da spart ein "setz mal die zwei werte auf dem dhcp server" natürlich schon zeit.
                        • 9. Re: Probleme mit DSM 2014.1 und WinPE 3.x
                          Frank.Scholer Master
                          Hi Mel,

                          naja, ein Grund ist sicher auch, dass es durchaus Kunden gibt, die nicht nur einen PXE-Server in einer Broadcast-Domaein betreiben wollen (SCCM bzw. MDT/WDS, Telefonie, POCs, Parallelbetrieb verschiedener OSD-Versionen/-Umgebungen, andere Produkte, usw.) und die sich eben genau nicht auf die Redirection von OSD verlassen wollen (aus welcher Motivation raus auch immer ;-)... also machen sie ne Redirection durch ein System, dem sie mehr "vertrauen" bzw. wo es viele Jahre Erfahrungswerte gibt...

                          Ein Punkt könnte auch sein, dass es eben eingeführte Tools gibt, die die Optionen im DHCP-Server setzen (weiß ich von einigen Kunden, die das tun - sowohl mit MS DHCP-Server als auch mit ISC DHCP-Servern unter Linux) und diese Tools sind in die Prozesse eingebettet und abgenommen und die User können sie bedienen usw. usf. - könnte ein nicht unerheblicher Aufwand sein, das auf OSD Redirection umzustellen.

                          Grüße Frank
                          • 10. Re: Probleme mit DSM 2014.1 und WinPE 3.x
                            ReneScheruebl Apprentice
                            Hallo zusammen!
                            Vielleicht verstehe ich hier was falsch, aber seit enteo v6 braucht man am DHCP keine Optionen zu setzen. Dies war noch unter NetInstall 5.x der Fall. Bei läuft der DHCP auch separat und in einem eigenen VLAN. Es lediglich die IPHELPER im entsprechenden VLAN gesetzt werden, die auf den PXE zeigen und der Rest passiert von selbst. Wir haben MS DHCP Server im Einsatz - eventuell schieß ich da am Thema vorbei... ;-)
                            • 11. Re: Probleme mit DSM 2014.1 und WinPE 3.x
                              _Mel_ Master
                              @Rene: was du beschreibst ist die best practise - bleib dabei

                              @Frank: das meinte ich mit "keinen vernünftig konfigurierbaren relay agent"
                              es wundert mich eigentlich, daß dhcp server nicht von haus aus relay agent fähigkeiten mitbringen, denn wenn ein client bestimmte kriterien erfüllt anstatt bestimmte optionen zu schicken einfach den request an den richtigen bootserver weiterzuleiten sollte von aufwand und schwierigkeit her eher trivial sein.

                              was den parallelbetrieb angeht hast du mit den meisten systemen das problem, daß die mit option 66 und 67 arbeiten und damit bekommst du nichtmal die verschiedenen bootloader für die verschiedenen architekturen (stichwort: UEFI) hin (was mit option 43 zumindest theoretisch noch klappen könnte)
                              soweit es telefone betrifft, kann man in der 2014.1 wenn ich's noch richtig im kopf habe auch architekturen ausfiltern lassen (sprich: alles ignorieren, was nicht BIOS, UEFI32 oder UEFI64 ist) - vorausgesetzt die telefone schicken ihre architektur korrekt und haben keine PC architektur)