rundll32 psexec segítségével

Microsoft Windows

sziasztok!

van egy script, ami gyárt egy windows-os gépre egy nyomtató telepítő scriptet (.cmdbe lerakja), majd megfelelő joggal távolról meghívja psexec segítségével. a script rém egyszerű, kb az alábbi:

net use p: /d
net use p: \\server\drivershare
call %windir%\system32\regsvr32 /s %windir%\system32\prnadmin.dll
%windir%\system32\cscript c:\tmp\padd.vbs

rundll32 printui,PrintUIEntry /q /if /b "nyominév" /f "drive:\útvonal\inf.inf" /r "portneve" /m "prn model név"

a fenti script eleje bármikor rendesen lefut. viszont a nyomtató nevét variálva (script cseréli ki a megfelelő változókat a megfelelő értékre!) egy nyomtatóra (egy bizonyos) működik, 2 másikra meg nem (még jó, hogy "élesítés" előtt kipróbáltam másik nyomtatóra...).

a telepítés lépése kb ez:
- script felépítése a port létrehozásra (padd.vbs előállítása)
- driver telepítő cmd file előállítása
- psexec-kel való meghívás

az egyes kimeneteket látva mindig minden jól hajtódik végre, viszont a rundll-es sor, ami a drivert az elkészített portra feltelepíti, az nem. próbaképpen megcsináltam azt, hogy amikor előállítottam a cmd állományt és a vbs filet, akkor kézzel lefuttattam a tesztgépen. ekkor bármilyen nyomtatóra működött. amikor sikerült, akkor drivert és portot letöröltem, a scriptet érintetlenül hagytam, és az utsó fázist újra távolról indítottam (psexec a cmd filera).

van valakinek ötlete arra, hogy mi lehet az oka, hogy nem megy? ha egyáltalán nem lehetne így, akkor miért meg az egyikkel? ha mennie kéne, akkor miért nem megy mindegyikkel (továbbá miért mert úgy, hogy drirekt kézzel katt a file-ra).

hátha látja benne valaki a logikát, mert én nem... :/

  • 2077 megtekintés

( Xterm v | 2009. 09. 15., k – 08:30 )

hátha csak rossz időpontban kérdeztem :)

--
xterm

( bolond | 2009. 09. 16., sze – 11:20 )

Távolról is elindul a rundll32, de nem csinál semmit?

:)

pontosan. ugyan azt teszi, mint ahogy tenné helyben, vagy ahogy a "működő" esetben. canon 3225-ösnél megy, de canon 1024, hp 2055 esetében nem (több "tesztállatot" még nem csináltam, de referenciának már a hiba is elég sajna...)

annyi csak a különbség, hogy amikor csinál is valamit, akkor értelem szerint tovább tart. de csak ennyi.

--
xterm

azokkal is folyik a kísérletezés, de ott is vannak gondok (leginkább azért, mert félmegoldások. pl. a drivert telepíthetné (leszámítva a 87-es hibakódot, amibe futottam; tele van vele a gugli... :/), viszont porthoz nem tudja rendelni. ami tud portot buzerálni, az nem tud local portot (fogalmam sincs miért, mert hát ez csak egy típus beli különbség).

leginkább azt nem értem, hogy ez lenne a "hivatalos megoldás", de valamiért mégse megy. jó, lehet, hogy a kutya az inf-ben van elásva, de akkor meg miért nincs valami egzakt hiba és miért csak exitál... (meg sem jegyzem, hogy amikor régen kerestem megoldást akkor még ment, csak (gondolom a driver változás) most nem megy. mondjuk akkor csak "passzió lett volna", most meg "fontos" lenne...

próbáltad azokat esetleg ilyen célra? jótanácsot velük kapcsolatban szívesen fogadok :)

--
xterm

( foci v | 2009. 09. 16., sze – 13:13 )

Ha IP nyomató akkor a nyomtatási szolgáltatást ujra kell inditani, ha most adtál hozzá portot.

( foci v | 2009. 09. 16., sze – 13:16 )

Ja meg a másik hogy a "net use ..." is ugyan azzal a felhasználói névvel fut le mint a psexec ?
Mert akkor a p: meghajtó nem látszik....

ez nem számít, lévén, hogy a net use az egy cmd fileban van, ami "magának elvégzi" a csatolását a p: meghajtóra. a psexec csak indítja. ha nem így lenne, akkor egy nyomtató sem tudna települni, nem csak pár. pont azért kerül a cmd a gépre és psexec-kel van végrehajtva, hogy ne legyen az szempont, hogy egy harmadik gépre mutat a port (a driver telepítés szempontjából tulajdonképpen mindegy is, maga a rundll32 hívás nem megy le szerintem. scak mivel tojik infót adni magáról, hogy mi a baja, ezért lövésem sincs miért megy egy drivernél, miért nem megy egy másiknál.

kiegészítés: korábban egy olyan driverrel bírtam kipróbálni az elvet, ami nem volt aláírva. ez interaktívan nem zavart (nem is kérdezett! csak jelezte egy plus sorban a varázsló), de a printui távolról megállt és várt, hiszen nem tudtam ok-t nyomni egy nem létező ablakon. ez meg tudtam kerülni, hogy a hibaüzenetet kikapcsoltam. meglehet amúgy, hogy itt lesz a kutya elásva, csak azt nem értem, hogy miért fut le hibátlanul úgy, hogy nem csinálja meg (0-ás exitkód). bár gondolom azért, mert ezt a 0-t nem a printui-tól kapom, hanem a rundll32-től, ami meg hát lefut. ő meg gondolom megkapja a kibakódot, csak nem adja át, nem írja ki. még file-ba se....

--
xterm

a script admin joggal fut, mivel telepíteni nem tudna másképp drivert. a map-elést meg nem admin joggal teszi, de miért is tenné, hiszen nem arról a gépről van szó, indiferens milyen user joggal teszi.

a driver meg nincs fent, mivel leginkább az a tuti ellenörzés, hogy "balra fordítom a fejem és megnézem, sikerült-e a telepítés" (lévén, hogy hibaüzenet, log, stb nincs a dologról...)

sajnos nem ez tehát a probléma.

--
xterm

vagy én nem értem mit szeretnél, vagy te nem érted mit írok :) a psexec "belogol", indít egy cmd file-t. ergo, a cmd file egy session. a net use felcsatol egy meghajtót egy másik gépen, ahol szükség szerint nincs meg az az user, aki a sessiont futtatja. ilyen esetben _csak_ egy valós userrel tudsz map-pelni a másik gépen. ha a session-ön belül teszed, akkor azt bizony a session nyitó user tudja használni. jó vicc, ha nem tudná, akkor egyetlen olyan megosztást, meghajtót, stb nem tudnál használni, ami nem a tied. ;)

--
xterm

áruld már el miért nem kéne mennie?! csak mert bármilyen sessionből tudsz másik gépre csatlakozni más, a tiedtől különböző felhasználóval (feature). továbbá mit teszteljek azon, ami megy? (ld. ha már másképp nem érted, hogy az egyik driverrel megy!) szóval inkább teszted te ;) pl. belépés után vegyél fel egy másik meghajtót egy olyan gépen, ahol nincs usered. faszán tudod használni. vagy legalább írd már le, hogy miért nem kéne menjen...

--
xterm

Bocs, de fogalmazás gátlót szedek. :)
Szóval Gizike felhasználói névvel a távoli gépen megcsinálod a meppelést és Győzike távoli felhasználóként akarod használni?
Na ez nem fog menni.
Csak nem látom innen mi mit hiv meg milyen sorrendben.
Hogy ne legyen vele szívás inkább ne csatold csak használd unc formában.
A másik hogy igy hivd meg:
"cmd.exe /c rundll32.exe ..."

Ha nem IP nyomtató, akkor lehet hogy DOT4 támogatás kell neki.
Azt meg nem telepíti addigra mire odaérsz, vagy nem talál hozzá drivert.

oks, akkor tisztába rakom :) hrgy84, a te jogos észrevételedre is ide írom a választ, ne kelljen két helyre válaszolni.

van 2 script. egy vbs, meg egy cmd. a cmd file tartalmát a témanyitásban olvashatjátok. a vbs tartalma gyakorlatilag nem lényeg, mivel az rendesen lefut. sőt, akár cmd se kell, mivel csak a psexec rundll32 hívás nem fut le jól.

a folyamat a következő:
- előállítom a vbs scriptet (csak egy portot hoz létre, ha még nem volt), amit a célgépre másolok
- előállítom a cmd file-t (ld fent témanyitásnál), majd átmásolom a célgépre a vbs mellé
- psexec a távoli gépen admin jogú userrel indítja a cmd file-t, ami felcsatolja a driverek helyét, futtatja a vbs-t a port miatt, majd futtatja a printui-t a rundll32 segítségével.

ez utóbbi rész egy driverrel működik, egy driverrel meg nem (tehát a kinek jogával futtatok és mappelek kérdés remélem most már tiszta. sőt, az is, hogy működik, mivel van amikor sikeresen fut)

így már érthető mit szeretnék?

--
xterm

igazán nem kötekszem, de nem érted. nem az van, hogy nem látszik a telepített nyomtató, hanem nem csinálja meg! a rundll hívás szinte azonnal kilép. a "működő" nyomtatódriver esetén meg elvan ugye elég sokáig, mert drivert másol. (értsd: lpt portra se települ a driver, pedig ott nem kell létre se hozni). a vbs, ami csak a portot hozza létre, az _mindig_ lefut _és azonnal_ látszik az eredmény (debug módban is nyomtam, soronként billentyűleütésekre, stb váratva, hogy lássam mit csinál.

valami az inf-ben más és ezért a printui elbarmolja, nem csinálja meg. :/

--
xterm

No varjal, valami azert itt meg nem tiszta.
1) sambas(domaines?) kornyezetben _elvben_ van joga a usernek (amennyire tudom, ez a Doman Users csoport tagjaira biztos igaz) mindenfele varazslas nelkul is csatlakozni a megosztott nyomtatohoz, a rendszer automatan letolti a szukseges drivereket a szerverrol, amennyiben ez a lehetoseg biztositott a szerveroldalon. Felhasznalonkent csak 1x kell csatlakozni a nyomtatohoz, a drivertelepitest pedig csak egyszer kell valakinek elvegezni.
2) ip nyomtatohoz altalaban nem kell nagy varazslat, vagy PS vagy PCL drivert kell felrakni, mindegy milyent.

Kezdjuk az alapoknal: milyen rendszer ez, a prinyo hogy kapcsolodik a rendszerhez? Vagy kliensgepi helyi prinyo? Ha igen, lehet hogy egyszerubb lenne ezt a prinyot felkotni egy szerverre es megosztani.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

oké, leírom, bár azért nem írtam le, mert a feladat szempontjából gyakorlatilag teljesen mindegy (rundll32 hiba egyik inf esetén, sikeres futás a másik esetben).

a teszt és az éles környezet is winxp zömmel. van domain és van nem domain tag komponens is. a probléma abból adódik, hogy egy pritert telepíteni win környezetben nem sikerült. úgy indult, hogy a local port nevű feature-t nem lehet a meglevő eszközökkel létrehozni úgy, hogy a kliens máshol van és ott egy nem admin jogú user van belépve.

a portot már létre tudom hozni bárhol, bármikor. (még olyat is, amit interaktívan admin se tudna :D). most erre a portra kéne fellógatni egy drivert is, hogy nyomtató legyen belőle. ez nem megy simán, holott több dedikált eszköz is van erre (és egyik sem működik, ilyen olyan oknál fogva, univerzálisan).

ha a feladat az, hogy egy nem létező portra drivert tegyünk, akkor milyen más módszert választasz? plusz "infó": a domain admin baszik segíteni (értsd eszközöket adni, ha van). ergo, marad a meglevő eszközpark és a local admin jogok alkalmazása... ebben akadtam el egy inf hibából (valszeg) és erre keresem a választ.

kimerítő így már? :)

--
xterm

Igen. Most mar csak azt szeretnem tudni, miert nem megoldas az, hogy a fajlszerverre/DC-re fellogatjatok a nyomtatot, es megosztjatok sima SMB megosztassal. Igy nem kellene local porttal backolodni, a drivert ra kell kotni a smb megosztassal letrejovo portra (ez automatikusan megtortenik a szerverrol valo driver telepiteskor), oszt annyi.

Megfelelo beallitas mellett barkinek felmaszhat a nyomtato, akinek az ACL listaban engedelyezve van. Es innentol ez az egesz problema nem letezik.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

kerülő megoldás sokféle van, azért választottam ezt a megoldást, mert egyfelől univerzális, másfelől erre van lehetőség. mint mondtam, nem a port a probléma, totál lényegtelen, hiszen az bármikor létrejön hibátlanul. felfoghatod úgy is a kérdést (és akkor a domain, driver megosztása, stb nem is "zavar be"), hogy "miként lehet nyomtató drivert telepíteni a win natív eszközeivel, amennyiben azok NEM működnek úgy, ahogy bizonyos driverekkel mennek."

a problémát millió és egy módon meg lehet oldani, nem is ezért kezdtem bele a nyomozásba. hanem abban találtam hibát, hogy az egyiknél lefut, a másiknál nem. és nem értem az okot. félre ne értsd, nem piszkálni akarom azt, aki segíteni próbál! a dolog lényege pont az, hogy adva van egy környezet, egy eszköz és egy probléma. meg kell oldjam. a helyszín jellegzetessége, hogy elég idióta infrastruktúra és még idiótább user környezet van. pl: drivert sem telepíthet user. ne kérdezd, nyomtató drivert miért nem (az user fura faj, nálunk az lenne az első, hogy letörölné...)

ha a problémát sikeresen megoldom, akkor azt user és domain interakció nélkül is meg tudom tenni (pl. nincs domain). ezért úgy gondolom nem teljesen elvetendő ötlet megfejteni, hogy az ms pont erre kitalált vacak miképp vehető rá a működésre (tényleg erre találták ki, jó lenne működtetni is...)

--
xterm

Meg mindig nem erted a problema lenyeget. Te login/akarmilyen scriptbol probalsz nyomtatot telepiteni, ami valamilyen oknal fogva nem jon ossze. En erre azt mondom, hogy oke, akkor legyen ez interaktivan (ez a script ugyanis _nem_ interaktiv mint kiderult, es akar ez is lehet a gond!!!), a Windows beepitett varazsloival megoldva (tehat nem valami osszehekkelt CMD-vel, hanem tenylegesen a Windows erre kitalalt beepitett eszkozeivel megoldva), ami akar mar interaktiv is lehet, hiszen a nyomtato automatikus telepitese egy interaktiv varazsloval tortenik.

Igy egyfelol megszabadulsz a script terhetol (ami szerintem egyebkent sem ertelmes valami nyomtatotelepitesre), masfelol egyszerusited a sajat eletedet is, hiszen igy tenylegesen csak egyszer kell odakattintani a nyomtatora, a Windows pedig onmukodoen elvegzi azt a munkat, amivel te most itt izzadsz valami cmd-vel. A Windows fejlesztoi mar csak jobban tudjak mint te, hogy kell meghivni azt a ruhes printui.dll-t hogy mukodjon a dolog, nem?
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

jó-jó, értem én :) igaz, hogy az általad írt működhet, ahol az usernek erre van joga, ott így is kéne csinálni. (és mi van, ha nem?). akkor már csak azt nem értem, hogy mivel lehetne megmagyarázni azt, hogy van, amikor működik (pl az említett canon ir3225, vagy akár az _összes_ gyárilag települő inf-es, winnel szállított driverrel).

de, hogy legyen ok más is, legyen a köv szitu. akarsz egy olyat, hogy usernek legyen egy nyomtatója. mondjuk legyen most és még 5 percig. majd NE legyen ott tovább (ne mond, hogy nincs ilyen, gyárthatok teoretikus eseteket, nem ez a lényeg). ezt az általad vázolt kattints ide, majd települ, ha van jogod, cuccal nem tudod megoldani. erre marad az, hogy valamilyen scripttel (a win szállít erre eszközöket, amik nem működnek, feltehetően inf hibából). ilyenkor mit csinálsz? fontos: csak azt a problémát megoldani, ami felmerül (nem kattintásvezérelt, hanem esemény vezértelten kerüljön oda).

jutott eszembe életszerűbb szitu is: van egy megoldásszállító (közbesz, kikerülhetetlen), akinek a hibája esetén le kéne kezelni a nyomtatást. ha tudne menni a script, akkor bármikor vissza tudnám állítani a "megoldás" előttire nyom nélkül. ott NEM megoldás az, hogy user hova kattint. főleg mert a sajátgép ikont se találja meg!!! ebben a szituban nincs mese, nekem kell csinálni. nem akarok kimenni és kattintani helyette, ergo valami kell, amivel eltakarítom, majd létrehozom azt, ami kell. erre van ötleted?

--
xterm

Az elso otletre az a megoldas, hogy Windows Serveren lehet idoablakot is megadni a nyomtatonak, hogy az mikor hasznalhato. Azt hiszem, hogy 5 perces idoablakot nem, csak 1 orasat tud max, de nyilvan nem 5 perc jon elo a valosagban.

A masodik dolgot nem ertem... Windows Serveren lehet nyomtatokbol poolt csinalni, es a pool tagjain szabalyozni a nyomtatas lehetoseget. Ez esetben te a pool-t veszed fel a kliens gepen, a szerver oldalon pedig a pool tagjait engedelyezgeted/tiltod. De ennek a mikentjenek utana kell nezni, mert ilyen orult megoldasokra meg nem volt szuksegem.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

hm... akkor egyszerűsítem: csak drivert akarok telepíteni egy beépített eszközzel, és azzal nem megy. a feladatom nem a driver telepítése, hanem annak a megoldása, megértése, hogy miért nem megy az, ami erre van kitalálva, csak bizonyos driverekkel (mert még mindig egyértelműen az látszik, hogy a driver "hibája" miatt nem megy a telepítés).

értem én, hogy jobb megoldás van, de hidd el, nem csak szopatni akarom magam. olyan ez, mintha lenne egy csavar, amit három kulccsal is be tudok csavarni, de csak egy féle van és nem vehetek másikat (mindegy miért). elhiszem, hogy van másik két megoldás IS, de a lényeg, hogy a nálam levő kulccsal is működnie kell. :)

az "őrült megoldás" meg leginkább az igen őrült kezdeti feltétel miatt van. és mint a neve is mutatja, feltétel, szóval más problémát csinálni nem tudok belőle (pedig képes lennék rá :D)

--
xterm

Xterm, mi lenne, ha megmutatnad a cmd es a vbs fajl pontos forrasat, csak a rendszerspecifikus reszeket (jelszavak, ip cimek, etc) kimaszkolasaval? Akkor mindenki megertene mire gondolsz, es esetleg tudna segiteni is. Igy csak egy fekete dobozt bokodunk buzogannyal.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( hrgy84 | 2009. 09. 16., sze – 13:59 )

Tipp: a rundll-t meghivhatod a vbs-bol is... a WScript.Shell ojjektumnak van valami exec fuggvenye.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( snq- | 2009. 09. 16., sze – 14:00 )

>> akkor miért meg az egyikkel?

elképzelhető, hogy valamelyik interaktálna a desktoppal

én is ezt hiszem, csak nem tudom miként lehetne rájönni a megfejtésre (interaktívan indítva _semmi különbség nincs, csak psexec esetén, távolról. tehát a cmd file sosem vár interakciót, a rundll32 hívás se.)

van esetleg ötleted arra, hogy lehetne az interakciójáról valami infót kinyerni? mert ez kell legyen az ok valahol...

--
xterm

az event logban szinte semmi. pontosabban a rendszer ágban ott van a psexec indulása, majd leállása. illetve annál az egy nyomtatónál, ahol sikeres a dolog (canon 3225), ott még az is ott van figyelmeztetésként (?vajon miért?), hogy driver lett telepítve, az alábbi fileok társaságából, és ott a lista. látszólag nem ír mást semelyik másik event ágba.

--
xterm

néztem ott is psexec-kel (ott is az ip-jével hivatkozva, hátha számít), de semmi különbség, ott sem fut le (tehát itt lesz talán a kutya elhantolva). viszont (!) -i kapcsolóval nem próbáltam, lévén pont azt akarom, hogy az user ne avatkozhasson bele. erre a próbára viszont érdekes eredményt ad:
- helyben a teszten futtatva -i kapcsolóval lefut (és semmi interakció nincs!)
- távolról -i kapcsolóval lefut, de továbbra sem történik semmi, csak úgy, mint -i kapcsoló nélkül.

valószínüleg a gyökér iniben van a megoldás, csak hát annak a szerkezetét abszolut nem ismerem, lövésem sincs hol kéne a megfejtést keresni...

--
xterm

( bocs | 2009. 09. 16., sze – 20:14 )

a rundll32 sajnos nem ad vissza error kódot, neked pedig pont arra lenne szükséged.

ötlet 1.: nem command line hosszúság gondod van? próbáld meg a @-os változattal, külső fájlba rakva a parancssort
ötlet 2: szimuláld a rundll hívást: írj egy nyúlfarknyi scriptet vagy C programot, ami meghívja a kérdéses függvényt direktben, de kiírja a hibát

A PrintUIEntry pont parancssori hivasra lett kitalalva, es eleg sok helyen mukodik, tehat ezzel szerintem nincs gond.

Az errorkod visszaadas hianyaban en nem hiszek, ennyire bena nem lehet a rundll32, inkabb arrol van itt szo, hogy nem nezi senki a visszateres erteket, es a PrintUIEntry meg nem logolja le a bajat a konzolon kivul mashova.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

lehetne valahogy nézni azt a visszatérési értéket? mármint ki lehetne belőle kényszeríteni? mondjuk alapvetően a printui-val van a bajom, frászért nem mondja mi a baja (ha az ember interaktívan dolgozik vele, akkor is tud orbitális ökörségeket kiírni "hibaüzenetként". pl. jártam vele úgy, hogy a LaserJet nevet elgépeltem Laserjet-nek és emiatt panaszolta, hogy nem lehet végrehajtani. nem azt, hogy nincs ilyen, hanem hogy nem lehet végrehajtani. meg voltak negatív, longint méretű hibakódjaim is :)

--
xterm

( bocs | 2009. 09. 17., cs – 11:28 )

sajnos a rundll32 definíció szerint void, tehát semmilyen hibakódod nem lehet.

amit lehet: natív Win32 Printer API függvényekkel dolgozva elérni ugyanezt a hatást, és kiírni a hibákat.

de először én megnézném a parancssor hosszára vonatkozó ötletet, mert ha az bejön, akkor minden működni fog.