Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit
GELÖST

Aus einer .hta heraus WDSUTIL aufrufen funktioniert nicht

Frage Entwicklung VB for Applications

Mitglied: Edi.Pfisterer

Edi.Pfisterer (Level 2) - Jetzt verbinden

07.07.2011, aktualisiert 12:40 Uhr, 11171 Aufrufe, 9 Kommentare

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

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:
01.
Set wshell = CreateObject("WScript.Shell")  
02.
wshell.run "%COMSPEC% /C WDSUTIL /Set-Server /PxePromptPolicy /Known:NoPrompt", 9, TRUE  
03.
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:
01.
<head> 
02.
<title>Edi's Aufwecker... ;-)</title> 
03.
<HTA:APPLICATION 
04.
APPLICATIONNAME="Wake on LAN" 
05.
 
06.
     BORDER="thin" 
07.
     BORDERSTYLE="normal" 
08.
     CAPTION="yes" 
09.
     ICON="" 
10.
     MAXIMIZEBUTTON="yes" 
11.
     MINIMIZEBUTTON="yes" 
12.
     SHOWINTASKBAR="yes" 
13.
     SINGLEINSTANCE="yes" 
14.
     SYSMENU="yes" 
15.
     VERSION="1.0" 
16.
     WINDOWSTATE="maximize"/> 
17.
 
18.
</head> 
19.
<script language="VBScript"> 
20.
function aufrufWDSUtil 
21.
 
22.
 
23.
Set wshell = CreateObject("WScript.Shell") 
24.
                                                                                     'wshell.run "ohneF12.vbs", 9, true --> funktioniert auch NICHT, identer Fehler "Befehl nicht gefunden..." 
25.
wshell.run "%COMSPEC% /K WDSUTIL /Set-Server /PxePromptPolicy /Known:NoPrompt", 9, false 
26.
 
27.
end function 
28.
</script> 
29.
 
30.
<body bgcolor=#FAF8AF onLoad="aufrufWDSUtil"> 
31.
<font face=verdana> 
32.
<a href="ohneF12.vbs">anwerfen!</a> 
33.
 
34.
</font> 
35.
</body>
Hier ein Screenshot des Servers, die obere Command-Shell wurde vom Script aufgerufen, die untere über start/ausführen/cmd:
aca6e9e4632b5f7356af47a309f34023 - Klicke auf das Bild, um es zu vergrößern

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
Mitglied: bastla
07.07.2011 um 12:49 Uhr
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
Bitte warten ..
Mitglied: Edi.Pfisterer
07.07.2011 um 13:06 Uhr
Hallo bastla!
Danke für die rasche Antwort!!!!

Ergebnis von set der NICHT-FUNKTIONIERENDEN Shell:
01.
C:\>set 
02.
ALLUSERSPROFILE=C:\ProgramData 
03.
APPDATA=C:\Users\administrator.HAKNEUSIEDL\AppData\Roaming 
04.
CLIENTNAME=ILVA 
05.
CommonProgramFiles=C:\Program Files (x86)\Common Files 
06.
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files 
07.
CommonProgramW6432=C:\Program Files\Common Files 
08.
COMPUTERNAME=WICKY 
09.
ComSpec=C:\Windows\system32\cmd.exe 
10.
FP_NO_HOST_CHECK=NO 
11.
HOMEDRIVE=C: 
12.
HOMEPATH=\Users\administrator.HAKNEUSIEDL 
13.
LOCALAPPDATA=C:\Users\administrator.HAKNEUSIEDL\AppData\Local 
14.
LOGONSERVER=\\WICKY 
15.
NUMBER_OF_PROCESSORS=8 
16.
OS=Windows_NT 
17.
Path=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32 
18.
\WindowsPowerShell\v1.0\;C:\Program Files\Windows Imaging\;C:\Program Files (x86 
19.
)\Dell\SysMgt\oma\bin;C:\Program Files (x86)\Dell\SysMgt\idrac 
20.
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC 
21.
PROCESSOR_ARCHITECTURE=x86 
22.
PROCESSOR_ARCHITEW6432=AMD64 
23.
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 26 Stepping 5, GenuineIntel 
24.
PROCESSOR_LEVEL=6 
25.
PROCESSOR_REVISION=1a05 
26.
ProgramData=C:\ProgramData 
27.
ProgramFiles=C:\Program Files (x86) 
28.
ProgramFiles(x86)=C:\Program Files (x86) 
29.
ProgramW6432=C:\Program Files 
30.
PROMPT=$P$G 
31.
PSModulePath=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\ 
32.
PUBLIC=C:\Users\Public 
33.
SESSIONNAME=RDP-Tcp#0 
34.
SystemDrive=C: 
35.
SystemRoot=C:\Windows 
36.
TEMP=e:\Temp\2 
37.
TMP=e:\Temp\2 
38.
USERDNSDOMAIN=HAK-NEUSIEDL.LOCAL 
39.
USERDOMAIN=HAKNEUSIEDL 
40.
USERNAME=administrator 
41.
USERPROFILE=C:\Users\administrator.HAKNEUSIEDL 
42.
windir=C:\Windows
Ergebnis von set in der funktionierenden Shell:
01.
C:\>set 
02.
ALLUSERSPROFILE=C:\ProgramData 
03.
APPDATA=C:\Users\administrator.HAKNEUSIEDL\AppData\Roaming 
04.
CLIENTNAME=ILVA 
05.
CommonProgramFiles=C:\Program Files\Common Files 
06.
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files 
07.
CommonProgramW6432=C:\Program Files\Common Files 
08.
COMPUTERNAME=WICKY 
09.
ComSpec=C:\Windows\system32\cmd.exe 
10.
FP_NO_HOST_CHECK=NO 
11.
HOMEDRIVE=C: 
12.
HOMEPATH=\Users\administrator.HAKNEUSIEDL 
13.
LOCALAPPDATA=C:\Users\administrator.HAKNEUSIEDL\AppData\Local 
14.
LOGONSERVER=\\WICKY 
15.
NUMBER_OF_PROCESSORS=8 
16.
OS=Windows_NT 
17.
Path=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32 
18.
\WindowsPowerShell\v1.0\;C:\Program Files\Windows Imaging\;C:\Program Files (x86 
19.
)\Dell\SysMgt\oma\bin;C:\Program Files (x86)\Dell\SysMgt\idrac 
20.
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC 
21.
PROCESSOR_ARCHITECTURE=AMD64 
22.
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 26 Stepping 5, GenuineIntel 
23.
PROCESSOR_LEVEL=6 
24.
PROCESSOR_REVISION=1a05 
25.
ProgramData=C:\ProgramData 
26.
ProgramFiles=C:\Program Files 
27.
ProgramFiles(x86)=C:\Program Files (x86) 
28.
ProgramW6432=C:\Program Files 
29.
PROMPT=$P$G 
30.
PSModulePath=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\ 
31.
PUBLIC=C:\Users\Public 
32.
SESSIONNAME=RDP-Tcp#0 
33.
SystemDrive=C: 
34.
SystemRoot=C:\Windows 
35.
TEMP=e:\Temp\2 
36.
TMP=e:\Temp\2 
37.
USERDNSDOMAIN=HAK-NEUSIEDL.LOCAL 
38.
USERDOMAIN=HAKNEUSIEDL 
39.
USERNAME=administrator 
40.
USERPROFILE=C:\Users\administrator.HAKNEUSIEDL 
41.
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...
Bitte warten ..
Mitglied: Edi.Pfisterer
07.07.2011 um 13:33 Uhr
YESSS!!!!

Danke Bastla, you are my man

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
Bitte warten ..
Mitglied: bastla
07.07.2011 um 14:12 Uhr
Hallo Edi!

Knifflige Sache, hast Du aber sauber gelöst ...

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

Grüße
bastla
Bitte warten ..
Mitglied: Edi.Pfisterer
07.07.2011 um 14:16 Uhr
... 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:
01.
set wsh=createobject("wscript.shell") 
02.
befehl = "c:\windows\system32\cmd /k WDSUTIL /Set-Server /PxePromptPolicy /Known:NoPrompt" 
03.
 wsh.run Befehl,9,true
Danke im Voraus
lg
edi
Bitte warten ..
Mitglied: Edi.Pfisterer
07.07.2011 um 14:21 Uhr
oder alternativ:
was mache ich mit folgendem in einer 64-bit-Umgebung?

01.
dbFile = DBPath & "MyActiveDirectory1.mdb" 
02.
 
03.
 
04.
connStr = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source="  & dbFile 
05.
 
06.
 Set dbc = CreateObject("ADODB.Connection") 
07.
        dbc.Provider = "Microsoft.Jet.OLEDB.4.0" 
08.
        dbc.ConnectionString = "Data Source=" & dbFile 
09.
 
10.
        Set objFSO = CreateObject("Scripting.FileSystemObject") 
11.
        If NOT objFSO.FileExists(dbFile) then 
12.
          call WriteDB 
13.
        End if 
14.
 
15.
        dbc.Open 
16.
 
17.
 
18.
function WriteDB 
19.
 
20.
            set cat = CreateObject("ADOX.Catalog") 
21.
 
22.
            cat.Create connStr 
23.
 
24.
            const adInteger = 3 'Integer 
25.
            const adVarChar = 202 'Variable Character 
26.
            const adLongVarWChar = 203 'Memo 
27.
            const adUnsignedTinyInt = 17' Byte 
28.
 
29.
            dim new_table 
30.
                set new_table = createobject("adox.table") 
31.
                new_table.ParentCatalog = cat 
32.
 
33.
            new_table.Name = "ComputerImAD" 
34.
            new_table.columns.append "id", adInteger 
35.
            new_table.Columns("id").Properties("AutoIncrement") = True 'Ändern in Autowert 
36.
            new_table.columns.append "ComputerName", adVarChar, 255 
37.
            new_table.columns.append "MAC", adVarChar, 255 
38.
            new_table.columns.append "IPAdresse", adVarChar, 255 
39.
            new_table.columns.append "OrganisationUnit", adVarChar, 255 
40.
            new_table.columns.append "Beschreibung", adLongVarWChar 
41.
 
42.
 
43.
            'Feld kann leer bleiben Einstellung 
44.
            new_table.Columns("ComputerName").Properties("Jet OLEDB:Allow Zero Length") = True 
45.
            new_table.Columns("MAC").Properties("Jet OLEDB:Allow Zero Length") = True 
46.
            new_table.Columns("IPAdresse").Properties("Jet OLEDB:Allow Zero Length") = True 
47.
            new_table.Columns("OrganisationUnit").Properties("Jet OLEDB:Allow Zero Length") = True 
48.
            new_table.Columns("Beschreibung").Properties("Jet OLEDB:Allow Zero Length") = True 
49.
 
50.
            new_table.keys.append "pk_cust_id", 1, "id" 'Setzen des Primärschlüssels 
51.
            cat.Tables.Append new_table 
52.
 
53.
            set new_table = nothing 
54.
            set cat = nothing 
55.
 
56.
END function
arghhhh
Bitte warten ..
Mitglied: bastla
07.07.2011 um 14:23 Uhr
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 ...

Grüße
bastla
Bitte warten ..
Mitglied: Edi.Pfisterer
08.07.2011 um 00:06 Uhr
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 .... ]

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

lg
edi
Bitte warten ..
Mitglied: Edi.Pfisterer
11.07.2011 um 13:15 Uhr
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:

01.
set wsh=createobject("wscript.shell") 
02.
befehl = "c:\windows\system32\cmd.exe /k WDSUTIL /Set-Server /PxePromptPolicy /Known:NoPrompt" 
03.
 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:
01.
set wsh=createobject("wscript.shell") 
02.
befehl = "c:\myCMD\cmd.exe /k WDSUTIL /Set-Server /PxePromptPolicy /Known:NoPrompt" 
03.
 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...

01.
function copyCMD 
02.
 
03.
 
04.
Set fso = CreateObject("Scripting.FileSystemObject") 
05.
 
06.
	If NOT fso.FolderExists("C:\wol1") then Set objFolder = FSO.CreateFolder("C:\wol1") 
07.
 
08.
   If NOT fso.FileExists("C:\wol1\cmd.exe") then 
09.
   fso.CopyFile "C:\windows\system32\cmd.exe", "C:\wol1\" 
10.
   set fso = nothing 
11.
 end if 
12.
 
13.
 
14.
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

lg
edi
Bitte warten ..
Neuester Wissensbeitrag
Humor (lol)

Linkliste für Adventskalender

(3)

Information von nikoatit zum Thema Humor (lol) ...

Ähnliche Inhalte
Virtualisierung
Drucker aus einer VM heraus funktioniert nicht (5)

Frage von NCCTech zum Thema Virtualisierung ...

Linux
LTSP: PXE Boot funktioniert nicht (15)

Frage von Fenris14 zum Thema Linux ...

Heiß diskutierte Inhalte
Exchange Server
gelöst Exchange 2010 Berechtigungen wiederherstellen (20)

Frage von semperf1delis zum Thema Exchange Server ...

Windows Server
DHCP Server switchen (20)

Frage von M.Marz zum Thema Windows Server ...

Hardware
gelöst Negative Erfahrungen LAN-Karten (19)

Frage von MegaGiga zum Thema Hardware ...

Exchange Server
DNS Einstellung - zwei feste IPs für Mailserver (15)

Frage von ivan0s zum Thema Exchange Server ...