edi.pfisterer
Goto Top

Aus einer .hta heraus WDSUTIL aufrufen funktioniert nicht

Nachdem ich alle mir bekannten Fehlerquellen ausgeschlossen habe, könnt nur noch ihr mir helfen...

Hallo KollegInnen!

Ich hoffe, ihr könnt mir bei folgendem Problem behilflich sein - meine Weisheit ist am Ende face-wink

Umgebung:
Windows Server 2008 R2 mit installiertem und funktionierendem Windows Deployment Service (WDS)

Ziel:
Ich schreibe gerade an einer .hta, die mir aus dem AD alle OUs inkl. Computer ausliest, aus dem DHCP die dazugehörigen IP-Adressen und vor allem die MAC-Adressen ausliest. (das funktioniert schon alles).
Nun sollte aus der .hta heraus die Einstellung des WDS "Drücken von F12 durch den Benutzer erforderlich machen [...]" nach "PXE-Start immer fortsetzen" (bei bekannten Clients) geändert werden.

Dies funktioniert in der Command-Shell mit "WDSUTIL /Set-Server /PxePromptPolicy /Known:NoPrompt", eine einfache ohneF12.vbs mit folgendem Inhalt funktioniert ebenfalls:
Set wshell = CreateObject("WScript.Shell")   
wshell.run "%COMSPEC% /C WDSUTIL /Set-Server /PxePromptPolicy /Known:NoPrompt", 9, TRUE   
wscript.echo "F12 ist NICHT mehr nötig!"  

Problem:
Aus einer .hta heraus führt der selbe Code zu einer interessanten Fehlermeldung:
"Der Befehl "WDSUTIL" ist entweder falsch geschrieben oder
konnte nicht gefunden werden."

hier der Code der hta:
<head>
<title>Edi's Aufwecker... ;-)</title>  
<HTA:APPLICATION
APPLICATIONNAME="Wake on LAN"  

     BORDER="thin"  
     BORDERSTYLE="normal"  
     CAPTION="yes"  
     ICON=""  
     MAXIMIZEBUTTON="yes"  
     MINIMIZEBUTTON="yes"  
     SHOWINTASKBAR="yes"  
     SINGLEINSTANCE="yes"  
     SYSMENU="yes"  
     VERSION="1.0"  
     WINDOWSTATE="maximize"/>  

</head>
<script language="VBScript">  
function aufrufWDSUtil


Set wshell = CreateObject("WScript.Shell")  
                                                                                     'wshell.run "ohneF12.vbs", 9, true --> funktioniert auch NICHT, identer Fehler "Befehl nicht gefunden..."  
wshell.run "%COMSPEC% /K WDSUTIL /Set-Server /PxePromptPolicy /Known:NoPrompt", 9, false  

end function
</script>

<body bgcolor=#FAF8AF onLoad="aufrufWDSUtil"> 
<font face=verdana>
<a href="ohneF12.vbs">anwerfen!</a>  

</font>
</body>

Hier ein Screenshot des Servers, die obere Command-Shell wurde vom Script aufgerufen, die untere über start/ausführen/cmd:
aca6e9e4632b5f7356af47a309f34023

Kurios, oder?

Ein dir in der oberen Shell findet wdsutil NICHT unter c:\windows\system32, die untere Shell hingegen schon...


bisher (vergeblich) versuchte Lösungen:

- aus der hta heraus die ohneF12.vbs aufzurufen (direkt in der Funktion / als Link) --> selber Fehler
- RUNAS... befehl = "runas /savecred /user:administrator ""cmd /k WDSUTIL /Set-Server /PxePromptPolicy /Known:NoPrompt""" --> selber Fehler
- verstärkte Sicherheitskonfiguration des Internet Explorer deaktiviert --> selber Fehler
- localhost / servername bei "vertrauenswürdige Sites" hinzugenommen --> selber Fehler


Nach 6 Stunden des mehr oder minder nicht fruchtbringenden Probierens wende ich mich nun an Euch in der Hoffnung, jemand hat eine Lösung für dieses Problem!
Ich bn für jeden Hinweis sehr sehr dankbar!
Vielen Dank im Voraus

glg
Edi

Content-Key: 169305

Url: https://administrator.de/contentid/169305

Printed on: April 18, 2024 at 07:04 o'clock

Member: bastla
bastla Jul 07, 2011 at 10:49:25 (UTC)
Goto Top
Hallo Edi!

Lass Dir zum Vergleich einmal jeweils in den beiden CMD-Shells mit
set
die Systemvariablen anzeigen (insbes. auch %PATH% beachten) ...

Grüße
bastla
Member: Edi.Pfisterer
Edi.Pfisterer Jul 07, 2011 at 11:06:22 (UTC)
Goto Top
Hallo bastla!
Danke für die rasche Antwort!!!!

Ergebnis von set der NICHT-FUNKTIONIERENDEN Shell:
C:\>set
ALLUSERSPROFILE=C:\ProgramData
APPDATA=C:\Users\administrator.HAKNEUSIEDL\AppData\Roaming
CLIENTNAME=ILVA
CommonProgramFiles=C:\Program Files (x86)\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
CommonProgramW6432=C:\Program Files\Common Files
COMPUTERNAME=WICKY
ComSpec=C:\Windows\system32\cmd.exe
FP_NO_HOST_CHECK=NO
HOMEDRIVE=C:
HOMEPATH=\Users\administrator.HAKNEUSIEDL
LOCALAPPDATA=C:\Users\administrator.HAKNEUSIEDL\AppData\Local
LOGONSERVER=\\WICKY
NUMBER_OF_PROCESSORS=8
OS=Windows_NT
Path=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32
\WindowsPowerShell\v1.0\;C:\Program Files\Windows Imaging\;C:\Program Files (x86
)\Dell\SysMgt\oma\bin;C:\Program Files (x86)\Dell\SysMgt\idrac
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_ARCHITEW6432=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 26 Stepping 5, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=1a05
ProgramData=C:\ProgramData
ProgramFiles=C:\Program Files (x86)
ProgramFiles(x86)=C:\Program Files (x86)
ProgramW6432=C:\Program Files
PROMPT=$P$G
PSModulePath=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
PUBLIC=C:\Users\Public
SESSIONNAME=RDP-Tcp#0
SystemDrive=C:
SystemRoot=C:\Windows
TEMP=e:\Temp\2
TMP=e:\Temp\2
USERDNSDOMAIN=HAK-NEUSIEDL.LOCAL
USERDOMAIN=HAKNEUSIEDL
USERNAME=administrator
USERPROFILE=C:\Users\administrator.HAKNEUSIEDL
windir=C:\Windows

Ergebnis von set in der funktionierenden Shell:
C:\>set
ALLUSERSPROFILE=C:\ProgramData
APPDATA=C:\Users\administrator.HAKNEUSIEDL\AppData\Roaming
CLIENTNAME=ILVA
CommonProgramFiles=C:\Program Files\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
CommonProgramW6432=C:\Program Files\Common Files
COMPUTERNAME=WICKY
ComSpec=C:\Windows\system32\cmd.exe
FP_NO_HOST_CHECK=NO
HOMEDRIVE=C:
HOMEPATH=\Users\administrator.HAKNEUSIEDL
LOCALAPPDATA=C:\Users\administrator.HAKNEUSIEDL\AppData\Local
LOGONSERVER=\\WICKY
NUMBER_OF_PROCESSORS=8
OS=Windows_NT
Path=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32
\WindowsPowerShell\v1.0\;C:\Program Files\Windows Imaging\;C:\Program Files (x86
)\Dell\SysMgt\oma\bin;C:\Program Files (x86)\Dell\SysMgt\idrac
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 26 Stepping 5, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=1a05
ProgramData=C:\ProgramData
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
ProgramW6432=C:\Program Files
PROMPT=$P$G
PSModulePath=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
PUBLIC=C:\Users\Public
SESSIONNAME=RDP-Tcp#0
SystemDrive=C:
SystemRoot=C:\Windows
TEMP=e:\Temp\2
TMP=e:\Temp\2
USERDNSDOMAIN=HAK-NEUSIEDL.LOCAL
USERDOMAIN=HAKNEUSIEDL
USERNAME=administrator
USERPROFILE=C:\Users\administrator.HAKNEUSIEDL
windir=C:\Windows

hm.... sieht auf den ersten Blick doch relativ ident aus...

[update:
es scheint wohl ein 32/64-bit Problem zu sein.... (zumindest liegt der Verdacht nahe)....
vor allem bei
ProgramData=C:\ProgramData
ProgramFiles=C:\Program Files (x86)
ProgramFiles(x86)=C:\Program Files (x86)
ProgramW6432=C:\Program Files

bzw.

PROCESSOR_ARCHITECTURE=x86
PROCESSOR_ARCHITEW6432=AMD64

bzw.

CommonProgramFiles=C:\Program Files (x86)\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
CommonProgramW6432=C:\Program Files\Common Files

gehen die Einträge auseinander...]

what now?
mshta trägt sich im Taksmanager als mshta.exe *32 ein, ebenso die aufgerufene shell als cmd.exe *32 (die funktionierende nur als cmd.exe)

ist es möglich, die mshta.exe in der 64-bit-version zu starten? gibts die? hm...
Member: Edi.Pfisterer
Edi.Pfisterer Jul 07, 2011 at 11:33:31 (UTC)
Goto Top
YESSS!!!!

Danke Bastla, you are my man face-wink

Des Rätsels Lösung (ich bin mir SICHER, dieses Problem wird in Hinkunft noch mehrere Menschen beschäftigen):

auf einem Windows Server 2008 R2 (ohne SP1) sind mehrere mshta.exe vorhanden:
1.) mshta.exe in c:\windows\system32 - Dateiversion 8.0.7600.16385
2.) mshta.exe in c:\windows\winsxs\amd64_microsoft-windows-ie-htmlap... - Dateiversion 8.0.7600.16385
3.) mshta.exe in c:\windows\sysWOW64 - Dateiversion 8.0.7600.16385
4.) mshta.exe in c:\winsxs\wow64_microsoft-windows-ie-htmlap... - Dateiversion 8.0.7600.16385

bei mir wurde per default jede .hta mit "C:\Windows\SysWOW64\mshta.exe" gestartet - evtl. könnte dies jemand von Euch ebenfalls testen und einen entsprechenden Hinweis hier hinterlassen, ob das ein allgemeines "default" ist oder nur bei mir so...
dies führt dazu, dass die mshta als 32-bit-Anwendung gestartet wird...
dies führt dazu, dass aus der hta aufgerufene shells im Pfad "C:\Windows\SysWOW64\cmd.exe" gestartet werden - ebenfalls als 32-bit-Anwendung
dies führt dazu, dass nur ein eingeschränkter Befehlsumfang zur Verfügung steht, speziell der WDS in der Version des 2008 R2 (64-bit-only) ist damit nicht per command-line zu steuern...

Danke nochmals an Bastla!!!!!

lg
Edi
Member: bastla
bastla Jul 07, 2011 at 12:12:15 (UTC)
Goto Top
Hallo Edi!

Knifflige Sache, hast Du aber sauber gelöst ... face-smile

... und Du hast sicher recht damit, dass sich mit diesem Problem noch viele herumplagen werden.

Grüße
bastla
Member: Edi.Pfisterer
Edi.Pfisterer Jul 07, 2011 at 12:16:50 (UTC)
Goto Top
... zu früh gefreut... ;-(

jetzt funktioniert zwar das Scripten des WDS, aber der Datenbankzugriff nicht mehr....

ich verändere also meine Frage in:
"Kann mir jemand dabei helfen, aus einer mshta.exe *32 (aus dem Ordner c:\windows\sysWOW64) heraus eine cmd.exe mit 64-bit-Befehlsumfang zu starten?"

Anmerkung:
folgendes funktioniert leider NICHT:
set wsh=createobject("wscript.shell")  
befehl = "c:\windows\system32\cmd /k WDSUTIL /Set-Server /PxePromptPolicy /Known:NoPrompt"  
 wsh.run Befehl,9,true

Danke im Voraus
lg
edi
Member: Edi.Pfisterer
Edi.Pfisterer Jul 07, 2011 at 12:21:16 (UTC)
Goto Top
oder alternativ:
was mache ich mit folgendem in einer 64-bit-Umgebung?

dbFile = DBPath & "MyActiveDirectory1.mdb"  


connStr = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source="  & dbFile  

 Set dbc = CreateObject("ADODB.Connection")  
        dbc.Provider = "Microsoft.Jet.OLEDB.4.0"  
        dbc.ConnectionString = "Data Source=" & dbFile  

        Set objFSO = CreateObject("Scripting.FileSystemObject")  
        If NOT objFSO.FileExists(dbFile) then
          call WriteDB
        End if

        dbc.Open


function WriteDB

            set cat = CreateObject("ADOX.Catalog")  

            cat.Create connStr

            const adInteger = 3 'Integer  
            const adVarChar = 202 'Variable Character  
            const adLongVarWChar = 203 'Memo  
            const adUnsignedTinyInt = 17' Byte  

            dim new_table
                set new_table = createobject("adox.table")  
                new_table.ParentCatalog = cat

            new_table.Name = "ComputerImAD"  
            new_table.columns.append "id", adInteger  
            new_table.Columns("id").Properties("AutoIncrement") = True 'Ändern in Autowert  
            new_table.columns.append "ComputerName", adVarChar, 255  
            new_table.columns.append "MAC", adVarChar, 255  
            new_table.columns.append "IPAdresse", adVarChar, 255  
            new_table.columns.append "OrganisationUnit", adVarChar, 255  
            new_table.columns.append "Beschreibung", adLongVarWChar  


            'Feld kann leer bleiben Einstellung  
            new_table.Columns("ComputerName").Properties("Jet OLEDB:Allow Zero Length") = True  
            new_table.Columns("MAC").Properties("Jet OLEDB:Allow Zero Length") = True  
            new_table.Columns("IPAdresse").Properties("Jet OLEDB:Allow Zero Length") = True  
            new_table.Columns("OrganisationUnit").Properties("Jet OLEDB:Allow Zero Length") = True  
            new_table.Columns("Beschreibung").Properties("Jet OLEDB:Allow Zero Length") = True  

            new_table.keys.append "pk_cust_id", 1, "id" 'Setzen des Primärschlüssels  
            cat.Tables.Append new_table

            set new_table = nothing
            set cat = nothing

END function

arghhhh
Member: bastla
bastla Jul 07, 2011 at 12:23:48 (UTC)
Goto Top
Hallo Edi!

Ist natürlich nur mal der Versuch eines Workarounds, aber: Wie wäre es, wenn Du die HTA (zB über eine Verknüpfung) mit der "richtigen" mshta.exe ausführen lässt?

Selber testen kann ich momentan leider ncht ... face-sad

Grüße
bastla
Member: Edi.Pfisterer
Edi.Pfisterer Jul 07, 2011 at 22:06:35 (UTC)
Goto Top
Hallo bastla!

<OT>Bin mit meinem 13 Wochen alten Töchterl auf "Lepschi" gewesen (wie wir Österreicher so sagen...), daher die verspätete Antwort....</OT>

Diesen Workaround hab ich ursprünglich als die Lösung meines Problems angesehen. Also habe ich kurzerhand die Standardapplikation für .hta auf c:\windows\system32\mshta.exe verändert und WDSUtil hat wundervoll auf meine hta reagiert...

Nur:
ich habe - wie in meinem letzten Posting vermerkt - innerhalb meiner gesamten .hta (die das AD ausliest nach OUs + Clients und den DHCP inkl Mac u IP) eine Anbindung an eine .mdb
Diese Anbindung funktionert mit der C:\Windows\SysWOW64\mshta.exe (= im Taksmanager mshta.exe *32 --> funny, oder? bei DEM Pfad...) einwandfrei, dh, obiger Code wird problemlos ausgeführt und es wird die DB mit der Tabelle und allen Feldern angelegt. (dafür funktioniert aber das Skripten des WDS nicht...)

Führe ich diesen Code mit c:\windows\system32\mshta.exe aus (mshta.exe OHNE *32), dann erscheint (im obigen Code für Zeile 15) folgender Fehler:
"Der Provider kann nicht gefunden werden. Möglicherweise ist er nicht richtig installiert worden" Code 0

Workarounds nun:
1.) die DB-Verbindung umzuschreiben (dann läuft die hta aber vmtl nicht mehr auf einem 2008 ohne R2 (= 32 bit) oder
2.) die DB-Verbindung so zu lassen, wie sie ist und unter 32-bit funktioniert und
2a.) eine wmi-abfrage zu machen, ob R2 oder ohne R2 (sinniger, weil WDS anders geskciptet wird unter R2..... GRRRR)
2b.) wenn ohne R2 --> cmd in 32-bit version öffnen (also alles so zu lassen wie es derzeit schon funktioniert...) oder
2c.) wenn mit R2 --> 64-bit-version der cmd aufrufen

daher meine Frage: wie schaffe ich 2C, dh, aus einer hta, die unter 32-bit ausgeführt wird, eine cmd-shell in der 64-bit-version zu öffnen.....

Zur Nachvolllziehbarkeit kann ich gerne per PM die aktuelle Version der hta jedem Interessierten zukommen lassen....
[@ bastla: dir hab ich sie schon - unaufgefordert - geschickt .... face-wink ]

ich bin weiterhin Allen (Didi1954 - plz help!) für jeden Hinweis dankbar!

lg
edi
Member: Edi.Pfisterer
Edi.Pfisterer Jul 11, 2011 at 11:15:08 (UTC)
Goto Top
So, jetzt die endgültige Lösung bzw. 2 Lösungswege:

sollte jede hta mit der 64-bit-version der mshta ausgeführt werden, muss als Standardanwendung für den Dateityp .hta das Programm c:\windows\system32\mshta.exe gewählt werden (über Rechtsklick auf eine .hta --> öffnen mit --> Standardprogramm wählen...)

Da Programmteile, die unter der 32-bit-Version noch funktionierten, unter der 64-bit-Version nicht mehr funktionieren (zb das Erstellen einer Datenbank... siehe meinen Beitrag inkl. Code-Beispiel oben), kann die Umstellung auf die 64-bit-Version der mshta.exe nachteilig sein.

Geht es nun nur darum, dass aus einer hta, die in der 32-bit-Umgebung ausgeführt wird, eine 64-bit-Commandshell geöffnet werden soll (um zb WDSUTIL darin abzuarbeiten), dann gilt folgendes:
das einfachste wäre, die 64-bit-cmd-shell aufzurufen

doppelklick auf c:\windows\system32\cmd.exe erkennt den Befehl wdsutil
doppelklick auf c:\windows\sysWOW64\cmd.exe erkennt den Befehl wdsutil NICHT

daher müsste folgendes funktionieren:

set wsh=createobject("wscript.shell")  
befehl = "c:\windows\system32\cmd.exe /k WDSUTIL /Set-Server /PxePromptPolicy /Known:NoPrompt"  
 wsh.run Befehl,9,true

ABER: das funktioniert leider NICHT!

der Workaround (der funktioniert... ich habe nur keinerlei Erklärung warum...):
1.) man kopiert die c:\windows\system32\cmd.exe in einen beliebigen Ordner (in diesem Beispiel c:\myCMD)
2.) man führt folgendes aus:
set wsh=createobject("wscript.shell")  
befehl = "c:\myCMD\cmd.exe /k WDSUTIL /Set-Server /PxePromptPolicy /Known:NoPrompt"  
 wsh.run Befehl,9,true

Aber Achtung:
die .cmd muss per Hand kopiert werden (oder mit einer vbs datei...),
ABER: folgender Code aus der hta heraus führt dazu, dass die 32-bit-Version kopiert wird (ARGHHH), wodurch wdsutil wiederum ein unbekannter Befehl ist...

function copyCMD


Set fso = CreateObject("Scripting.FileSystemObject")  

	If NOT fso.FolderExists("C:\wol1") then Set objFolder = FSO.CreateFolder("C:\wol1")  

   If NOT fso.FileExists("C:\wol1\cmd.exe") then  
   fso.CopyFile "C:\windows\system32\cmd.exe", "C:\wol1\"  
   set fso = nothing
 end if


end function

falls jemand eine Erklärung hat, warum das funktioniert, wäre ich natürlich gespannt, ansonsten schiebe ich es in die Schublade "Voodoo" und lass es einfach dort face-wink

lg
edi