Guten Abend Community,
ich habe vor einigen Jahren "ein bisschen" DSM bzw. Enteo administriert und paketiert und habe bei meinem neuen AG aktuell wieder temporär / Vertretungsweise ein bisschen mit DSM zu tun. Aktuell stecken wir in den Windows 10 Tests und haben etwas Probleme bei der Zuverlässigkeit der Installation des DSM Agenten. Was ich hier vorgefunden habe ist ein OS Set, bestehend aus einem PreOS Action Package für Partition und Format, sowie einem OS Action Package für die Windows 10 Installation.
Dort ist ein AutoLogon mit einem Domänenbenutzer konfiguriert, über dessen Loginscript der DSM Agent installiert wird, wenn er noch nicht drauf ist. Hier hängt es, speziell bei den Remote Standorten, da so wie ich das verstehe der DSM Agent hier nicht mehr direkt installiert wird, sondern über den Server (SIS?) auf den Client gepusht wird. Dort hängt das Problem bei uns, da der Server schneller ist, als der DNS Server und er den Client noch nicht auflösen kann. Das Problem existiert wohl schon seit dem Update, auch mit anderen Betriebssystemen wie ich hier mittlerweile erfahren habe.
Ich hätte es gerne nun so gemacht, wie ich es damals erlebt / gelernt hatte. Über ein PostOS Action Package. Das wird aber aktuell blöderweise nicht ausgeführt, da es den Service dafür nicht gibt. Früher hatten wir in der unattend.xml eine eInstall.cmd im RunSynchronus Teil. Das gibt's hier zwar auch, allerdings ist die eInstall.cmd leer, bzw. nur ein Platzhalter mit einem Exit /b 0 drin. Das ist ebenso in allen OS Action Templates so, die DSM mit sich bringt.
Genug drum herum gequasselt: Ich stehe etwas auf dem Schlauch, was jetzt in die eInstall.cmd rein muss, dass das Universell funktioniert (also nicht von einem Depot abhängig ist) und der Client während der Windows Installation / via Post-OS Package nachinstalliert wird?
Im Vorfeld schon mal Danke.
Ralf