Go Back   Desktop & Server Management (DSM) Forum > GERMAN > DSM 7
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read

Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old December 10th, 2015, 09:04
saoe's Avatar
saoe saoe is offline
Benutzer
 
Join Date: 07-04-13
Posts: 43
Default VBScript funktioniert nicht bei Pilotinstallation

Hallo zusammen,

ich verzweifle gerade daran, ein VBScript aus einem DSM-Paket auszuführen.
Das Script soll das Computerobjekt nach der Installation in eine AD-Gruppe packen und basiert im Kern hierauf: https://gallery.technet.microsoft.co...to-AD-dd4b4df5
  1. Wenn ich das Script manuell mit meinem berechtigten Admin-Konto ausführen ist alles OK.
  2. Wenn ich das Script manuell mit dem Konto ausführe, dass bei uns für das DSM SIS-Benutzerkonto benutzt wird ist ebenfalls alles OK.
  3. Und auch wenn ich das DSM-Paket per F7 (lokale Installation) aus der Konsole heraus ausführe funktioniert es.
  4. Nur beim nächsten Schritt, Pilotinstallation auf einem anderen Rechner, passiert nix.
    Das Paket wird zwar als erfolgreich ausgeführt und im Log steht nichts weiter, aber das Computerobjekt wird nicht zum Mitglieder der Gruppe.

Ich hab in den letzten Tagen schon das Forum durchsucht und div. Tipps bzgl. Script-Ausführung beherzigt:
  • RunAs, nur computerbezogen (nicht Service)
  • Set WshShell = CreateObject("WScript.Shell") statt ... WScript.CreateObject()...

Auch div. Optionen in RunAsEx probiert:
  • Statt dem Runtime-Service meinen Domain-Admin-User hinterlegt
  • Abschalten der Dateiumleitung auf x64-Maschinen
  • Ausführbare Datei mit %WINDIRSYSTEM%\cscript.exe als auch mit %windir%\Syswow64\cscript.exe probiert

Hat alles nix geholfen:
Das VBScript selbst ist in Ordnung, lokale Installation funktioniert -- Pilotinstallation nicht /

Hier das Kommando aus meinem eScript (mit Platzhalternamen...):
Code:
RunAs('%WINSYSDIR%\cscript.exe','.\Extern$\scriptname.vbs ADD "Gruppenname"','','','',raUseSisAccount+raHideWindow+UndoneContinueParentScript)/TW
Reply With Quote
  #2  
Old December 10th, 2015, 09:16
NicoS's Avatar
NicoS NicoS is offline
Erfahrener Benutzer
 
Join Date: 09-10-07
Location: Bad Rappenau
Posts: 1,340
Send a message via ICQ to NicoS
Default

Hallo,

hast du unterschiedliche Konten für SIS und Runtime? Funktioniert es auch mit dem Konto das für Runtime definiert ist?

Alternativ... warum ein VB Script für so eine einfache Angelegenheit?
%WINSYSDIR%\net.exe Group GRUPPENNAME %computername%$ /ADD /DOMAIN

__________________
- Nico Schmidtbauer
Fujitsu TDS GmbH
Privater Blog - Generelle IT & Deployment Themen, DSM Themen und DSM Automatisierung via PowerShell
Reply With Quote
  #3  
Old December 10th, 2015, 09:32
derniwi derniwi is offline
Erfahrener Benutzer
 
Join Date: 02-15-12
Posts: 1,654
Default

Hallo,

das Protokoll hast Du schon auf Debug-Level?

Code:
RunAs('%WINSYSDIR%\cscript.exe','".\Extern$\scriptname.vbs" ADD "Gruppenname"','','','',raUseSisAccount+raHideWindow+UndoneContinueParentScript)/TW
Und mal versucht, den Pfad zum Skript in Anführungszeichen zu packen?

Verwende auch mal RunAsEx (bzw. eigentlich jetzt dauerhaft, da RunAs nicht mehr offiziell in neuen Versionen unterstützt wird). Und dann mal den Rückgabewert abfragen. Wenn das Skript einen Fehler verursacht, sollte das eigentlich protokolliert werden.

Weiterhin kannst Du ja auch die Ausgabe von cscript.exe umleiten.
Code:
RunAsEx(%WINSYSDIR%\cscript.exe','".\Extern$\scriptname.vbs" ADD "Gruppenname" >C:\Windows\Temp\adddomain.log','','xxx','10','returncode',raShowMinimized+raUseSisAccount+WaitForExecution+raLogonWithProfile+UndoneContinueParentScript)/TW
Ach ja, wie darf das eScript denn ausgeführt werden? Wenn es im Kontext des Service läuft, kann das Dein Problem verursachen. Und zwar dann, wenn das Skript losläuft, aber kein Benutzer angemeldet ist. Dann könnte das Erstellen der DOS-Box das Problem sein, denn dies wirde evtl. scheitern.

Gruß
Nils
Reply With Quote
  #4  
Old December 10th, 2015, 10:45
saoe's Avatar
saoe saoe is offline
Benutzer
 
Join Date: 07-04-13
Posts: 43
Default

Hallo Nico, Hallo Nils,

danke für die Antworten, ich werfe das mal zusammen:

Quote:
hast du unterschiedliche Konten für SIS und Runtime? Funktioniert es auch mit dem Konto das für Runtime definiert ist?
Äh, nein... soweit ich das überblicke (ORG und Site-Konfigurationen im Expermode); unter welcher Bezeichung soll das denn laufen? Ich seh hier "Benutzerkonto für den Dienst" (ServiceSettings.SrvAccountName) , "SIS-Benutzerkonto" (SisSettings.AccountName)...

Quote:
Alternativ... warum ein VB Script für so eine einfache Angelegenheit?
%WINSYSDIR%\net.exe Group GRUPPENNAME %computername%$ /ADD /DOMAIN
Oh, auch praktisch... ändert aber nix: Läuft als F7/Lokale Installation, aber nicht als Pilot.

Quote:
das Protokoll hast Du schon auf Debug-Level?
Ja.

Quote:
Und mal versucht, den Pfad zum Skript in Anführungszeichen zu packen?
Mit und ohne: Kein Unterschied.

Quote:
Verwende auch mal RunAsEx (bzw. eigentlich jetzt dauerhaft, da RunAs nicht mehr offiziell in neuen Versionen unterstützt wird). Und dann mal den Rückgabewert abfragen. Wenn das Skript einen Fehler verursacht, sollte das eigentlich protokolliert werden.
RunAsEx: Macht keinen Unterschied.
Rückgabewert: Nix.

Quote:
Weiterhin kannst Du ja auch die Ausgabe von cscript.exe umleiten.
Probiert: Keine Datei.

Quote:
Ach ja, wie darf das eScript denn ausgeführt werden? Wenn es im Kontext des Service läuft, kann das Dein Problem verursachen. Und zwar dann, wenn das Skript losläuft, aber kein Benutzer angemeldet ist. Dann könnte das Erstellen der DOS-Box das Problem sein, denn dies wirde evtl. scheitern.
Behalte ich mal im Hinterkopf, aber die Pilotinstallation teste ich auf einer VM, an der in der Zeit auch ein Testuser angemeldet ist.

Sascha
Reply With Quote
  #5  
Old December 10th, 2015, 11:02
Mel Mel is offline
Erfahrener Benutzer
 
Join Date: 09-15-09
Posts: 1,874
Default

welcher installer soll's denn ausführen ?
serviceinstaller
autoinstaller direkt (user mit / ohne admin rechte)
autoinstaller über pipe

machst du die F7 installation zufällig aus einer als administrator gestarteten dsmc heraus ? mit deaktivierter UAC oder als admin gestartet ist die F7 installation mMn wenig aussagekräftig.
Reply With Quote
  #6  
Old December 10th, 2015, 12:12
saoe's Avatar
saoe saoe is offline
Benutzer
 
Join Date: 07-04-13
Posts: 43
Default

Quote:
Quote:
hast du unterschiedliche Konten für SIS und Runtime? Funktioniert es auch mit dem Konto das für Runtime definiert ist?
Äh, nein... soweit ich das überblicke (ORG und Site-Konfigurationen im Expermode
Nachtrag: Tatsächlich kein Unterschied. Ich sehe ja auch im Log, mit welchem User RunAsEx bzw. der Process aufgerufen wird: Ist ein und derselbe (= SIS).
Der hat auch die Rechte, sowas im AD zu verändern.

Quote:
welcher installer soll's denn ausführen ?
Eigentlich hätte ich auf Serviceinstaller gesetzt...

Quote:
machst du die F7 installation zufällig aus einer als administrator gestarteten dsmc heraus ? mit deaktivierter UAC oder als admin gestartet ist die F7 installation mMn wenig aussagekräftig.
Ja und ja: Deaktivierte UAC (ist auf jedem unserer Clients der Fall) und ja, bin selbst lokaler Admin wenn ich die Konsole aufrufe.
Reply With Quote
  #7  
Old December 10th, 2015, 12:36
Klaus Salger's Avatar
Klaus Salger Klaus Salger is offline
Erfahrener Benutzer
 
Join Date: 11-16-06
Location: Kissing b. München
Posts: 762
Default

Hallo Sascha,

was steht denn im Installer-Log?
Und wie sieht's mit den Windows Eventlogs aus?

Dein Problem scheint zu sein, dass der Installer-Prozess von DSM keine Programme ausgeführen kann, hat also wohl nichts mit VBS zu tun.
Es erinnert an das Problem, das nvandre gerade hat auch wenn es im Detail Unterschiede gibt http://forum.enteo.com/showthread.php?t=16154

Ich habe in beiden Fällen den Verdacht, dass da ein Sicherheitsmechanismus involviert sein könnte, der den Start von EXEn verhindert.
Software Restriction Policies, AppLocker, Virenscanner, irgend sowas.
Habt ihr womöglich den gleichen Virenscanner? z.B. McAfee mit aktiver Access Protection?

Ciao
Klaus
__________________
Klaus Salger | IT Consultant
www.axoquent.de/blog
Reply With Quote
  #8  
Old December 10th, 2015, 13:35
gl-hl gl-hl is offline
Benutzer
 
Join Date: 10-29-12
Posts: 53
Default

Quote:
Originally Posted by saoe View Post
Hier das Kommando aus meinem eScript (mit Platzhalternamen...):
Code:
RunAs('%WINSYSDIR%\cscript.exe','.\Extern$\scriptname.vbs ADD "Gruppenname"','','','',raUseSisAccount+raHideWindow+UndoneContinueParentScript)/TW
Probiere doch mal folgendes (als Beispiel)
Wichtig ist, dass die cscript.exe unter einem Win64 OS auch unter dem C:\Windows\SYSWOW64 gestartet wird bzw. beim RunAs/ExecuteEx-Befehl: Dateiumleitung auf x64 Computern abgeschalten

Code:
   If IsRunningOnX64
    Execute('%WINSYSDIR%\cscript.exe ".\Extern$\prnmngr.vbs" -a -r %_PrinterPort% -h %_PrinterPort%')/?/x64/TS
   Else
    Execute('%WINSYSDIR%\cscript.exe ".\Extern$\prnmngr.vbs" -a -r %_PrinterPort% -h %_PrinterPort%')/?/TS
Reply With Quote
  #9  
Old December 10th, 2015, 13:35
saoe's Avatar
saoe saoe is offline
Benutzer
 
Join Date: 07-04-13
Posts: 43
Default

Quote:
Originally Posted by Klaus Salger View Post
Hallo Sascha,

was steht denn im Installer-Log?
Und wie sieht's mit den Windows Eventlogs aus?
Hab's jetzt nochmal auf den Urzustand zurückgesetzt und als Pilot auf einer frischen VM losgelassen:

Code:
14:27:56.844 2        ---->Starting installation of "..."
14:27:56.846 1        SWMSRT: Checking if policies should run for the trigger 'On error'.
14:27:56.846 0        SWMSRT: No triggered jobs found

14:27:56.847 2        -> RunAsEx('C:\Windows\system32\cscript.exe','C:\Program Files (x86)\Common Files\enteo\RepositoryCache\141225\rev\1\Extern$\modifyGroupMembership.vbs ADD "Gruppenname"','','','','',raUseSisAccount+raHideWindow+UndoneContinueParentScript)/TW
14:27:56.847 1         Skipping wksta-cmd.

14:27:56.848 2        -> : $BeginUninstallScript
14:27:56.848 1         xniSetup: Install part of script done -> exiting
14:27:56.849 0        ExR status report is disabled for ...
14:27:56.849 0        nilsPipe: Both current project and new project are NULL
14:27:56.849 2        xniFPS: '{F1FBA935-B861-477B-83AC-7251C49A70EB}' is installed

14:27:56.850 2        ---->Installation of ... complete.
Im Eventlog sehe ich nichts; normalerweise würde ein Verstoß unserer Gruppenrichtlinien bzgl. EXE oder VBS-Ausführung protokolliert (aber unsere Admins -- also auch der SIS -- sind davon ausgenommen).

Quote:
Dein Problem scheint zu sein, dass der Installer-Prozess von DSM keine Programme ausgeführen kann, hat also wohl nichts mit VBS zu tun.
Es erinnert an das Problem, das nvandre gerade hat auch wenn es im Detail Unterschiede gibt http://forum.enteo.com/showthread.php?t=16154
Würde sagen eher nicht; hab letzte Woche ein anders Paket gebaut, mit Aufruf der üblichen Setup.exe und noch einiger anderer Clean-up-Programme: Kein Problem.
Unsere DSM-Umgebung ist ja auch nicht neu, wir installieren schon lange und fleissig damit.

Quote:
Ich habe in beiden Fällen den Verdacht, dass da ein Sicherheitsmechanismus involviert sein könnte, der den Start von EXEn verhindert.
Software Restriction Policies, AppLocker, Virenscanner, irgend sowas.
Habt ihr womöglich den gleichen Virenscanner? z.B. McAfee mit aktiver Access Protection?
Ja, wir haben Software Restriction Policies und McAfee im Einsatz.
Letzteres hat noch nie Probleme gemacht und die Software Restriction Policies gelten nicht für die Gruppe der Benutzer, zu der auch der SIS-User gehört.

Wenn es daran liegen würde, hätte ich schon viel mehr Probleme bei meinen Paketen ;-)

Ich hab eben auch nochmal in älteren Paketen meiner Vorgänger gestöbert:
Da werden auch an div. Stellen VBSkripten ausgeführt (mal via CallScript, mal via ExecuteEx), und die funktionieren auch (immernoch); nur sehe ich momentan keinerlei Unterschied zu meinem Ansatz (hab vor RunAsEx auch mit CallScript und Execute experimentiert)... muß mir die nochmal näher angucken.
Reply With Quote
  #10  
Old December 10th, 2015, 13:53
derniwi derniwi is offline
Erfahrener Benutzer
 
Join Date: 02-15-12
Posts: 1,654
Default

Das ist das Problem:
Code:
14:27:56.847 2        -> RunAsEx('C:\Windows\system32\cscript.exe','C:\Program Files (x86)\Common Files\enteo\RepositoryCache\141225\rev\1\Extern$\modifyGroupMembership.vbs ADD "Gruppenname"','','','','',raUseSisAccount+raHideWindow+UndoneContinueParentScript)/TW
14:27:56.847 1         Skipping wksta-cmd.
Wahrscheinlich wurde der Befehl schonmal ausgeführt (Kontext des Service) und jetzt soll dieser im Benutzerkontext laufen.
Was sagt das Log des Service Installers?

Last edited by derniwi : December 10th, 2015 at 13:59.
Reply With Quote
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

   

All times are GMT +1. The time now is 15:45.

Powered by vBulletin Version 3.6.7
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.