[w2k server] Batch file via Scheduled tasks

[MrJ]

Hi,

Ik kom er zojuist achter de batchfile die gebruikt wordt voor het backuppen van een DB via de Scheduled Tasks niet werkt.

De job wordt wel als klaar aangegeven, maar de DB is niet gekopieerd naar desbetreffende directory.

Als ik die batchfile met de hand draai, doet 'ie 't wel gewoon keurig.

Iemand enig idee?

[Verwijderd]

Roep eens een batch-file aan met alleen pause erin.

[MrJ]

Hij komt iig niet op het scherm, 't lijkt alsof hij op de achtergrond wordt uitgevoerd.

Dit omdat cmd.exe wel in de taskmanager staat.

[Verwijderd]

laat me raden... met de hand run je het onder een admin account... gescheduled staat het met het system account oid...

[MrJ]

Gescheduled staat 'ie onder het local admin account.

Dat had ik al gechecked.

/edit
Argh!

Een collega had het lokale pwd aangepast.

Nu doet 'ie 't.

[ Voor 39% gewijzigd door MrJ op 08-05-2003 13:18 ]

[Verwijderd]

hehe

[MrJ]

Oeps, the story continues...

Hij had er dus wel bij nagedacht die task aan te passen.

Maar nu blijkt dat de task simpelweg niet onder het lokaleadmin account draait. Wel onder het domain admin account.

Hoe kan dit? Lokaal hebben ze evenveel rechten.


/edit
Aangelogd onder het local admin account doet 'ie 't wel.
Aangelogd onder het domain admin account (maar dus gescheduled door het local admin account) niet.

Hij hoort 't toch gewoon te doen?

[ Voor 29% gewijzigd door MrJ op 08-05-2003 13:51 ]

[Verwijderd]

local account heeft NIET per definitie rechten op andere servers, dus kan je beter een (daarvoor) geschikt domain-account gebruiken. Maak er 1 speciaal aan en gebruik deze voor dit soort zaken, met password never expires, met natuurlijk een ander password als "password"

[MrJ]

Ja, maar een local admin gebruiken om een lokale batch te runnen moet toch lukken?

Dat lukt dus ook, maar alleen als hij zelf aangelogd is, is er een andere aangelogd gebeurd er niets.

En een service account bestaat al, die wordt ook op een aantal servers gebruikt, maar het password daarvan hebben we hier intern zeer goed opgeborgen. Niet meer te vinden dus. Kan wel een pwd crack proggie gebruiken, maar los het nu wel ff lokaal op.

[Verwijderd]

schrijf wat logging in je batch dan kan je zien wat er niet uitgevoerd wordt.

of post je batch eens...

[MrJ]

Heel simpel:

time /t > c:\test.log
d:
cd\
cd aasdbsrv
Dbbackup.exe -c "ENG=AASSERVER;Start=dbclient.exe;DBS=AASSERVER -x DDE,;UID=DBA;PWD=SQL" -y d:\aasdbsrv\backup
time /t > c:\test2.log

Test.log en test2.log worden beide wel aangemaakt.

Die dbbackup.exe loopt kennelijk niet. Maar als je dus weer aflogged als domain admin zijnde, en weer aanlogged als die local admin waaronder de job gescheduled is, doet 'ie 't wel.

[Verwijderd]

je bedoelt als je hem handmatig uitvoert werkt het wel?

probeer eens:

start dbbackup etc....

[ Voor 29% gewijzigd door Verwijderd op 08-05-2003 17:34 ]

[MrJ]

Handmatig die batch draaien gaat perfect ja.

Alles gescheduled onder localadmin, en de domainadmin is ingelogd (normale situatie) dan loopt er iets mis.

De batch draait (op de achtergrond) maar de kopieerslag via dbbackup.exe werkt kennelijk niet. Als ik die batch op de voorgrond kon krijgen, zou ik dmv een aantal 'pause' commando's meer te weten kunnen komen. Maar dat gaat helaas niet.

[Verwijderd]

gebruik dus "start"

[MrJ]

Helaas, geen verschil.

[Remco]

maak er eens .cmd van in plaats van .bat

[MrJ]

Again; helaas geen resultaat.

[antimute]

Kan je in die batch niet een run as: maken waarbij dus username>password combi ingeeft waardoor t altijd met de goeie account wordt uitgevoerd of denk ik nu te makkelijk?

[MrJ]

Ik denk dat je te makkelijk denkt.

Het heeft dus te maken met het feit dat een scheduled task onder (local)admin 'A', niet draait als (domain)admin 'B' is ingelogd.

[Verwijderd]

antimute schreef op 09 May 2003 @ 14:36:
Kan je in die batch niet een run as: maken waarbij dus username>password combi ingeeft waardoor t altijd met de goeie account wordt uitgevoerd of denk ik nu te makkelijk?

dat doe je dus door een batch te schedulen met een bepaald account...

maar het blijft een vaag probleem...

process tracking eens aanzetten?

[MrJ]

Zal eens kijken volgende week. Nu ff geen zin meer in.

Tnx iig.

[ Voor 11% gewijzigd door MrJ op 09-05-2003 17:13 ]

[Remco]

Was er niet een of andere tekortkoming van de standaard scheduler ?
Zoiets staat me bij van een klant van ons.
Het runnen van batches of executables ging niet of zoiets vaags.....
Ik weet het niet meer, misschien dat er bij iemand anders nu een lichtje gaat branden ?

[Verwijderd]

Kijk es voor de gein of er niet met de NTFS rechten voor de local admin geknoeit is!(de kopieer slag werkt niet)

[MrJ]

Nope, daar ligt 't niet aan.

Dit somt 't probleem dus wel aardig op:?

Het heeft dus te maken met het feit dat een scheduled task onder (local)admin 'A', niet draait als (domain)admin 'B' is ingelogd.

[Verwijderd]

Wordt de backup helemaal niet uitgevoerd, of verschijnt hij alleen niet op het scherm?

Het klopt namelijk dat een scheduled task niet op de desktop van een andere user zichtbaar is. Dat probleem ben ik ook tegengekomen. Ik kan me herinneren dat in dat geval de batchfile wel draaide en resultaten gaf, maar niet zichtbaar was.

Ik heb er toen voor gekozen om de scheduled task te draaien als de user die normaal op de desktop aangelogd is, en zelf voor andere zaken met Terminal Server Remote Admin te werken. (Dit was op een w2k server).

Je zou nog kunnen kijken naar group policies. Onder "user rights assignments" staat een optie dat een user dingen interactief met de desktop mag uitvoeren.
Misschien helpt dat?

[MrJ]

Hij wordt helemaal niet uitgevoerd (de backup zelf dan, de batch wel, maar het backup gedeelte daarvan niet).

Het klopt iig dat als je onder een andere user ingelogd bent, hij per default geen interactie heeft met de desktop.

Maar het kan nooit kwaad om morgen de group policies uit te pluizen nee.

[ Voor 14% gewijzigd door MrJ op 11-05-2003 16:33 ]

[HermeS]

Ik had een paar weken terug een vergelijkend probleem (een bepaald programma werkte niet via TMS, maar wel als je het via de scheduler deed. Anway op de ene pc werkte het perfect en op de andere niet. Na een tijde heb ik het complete pad aangeven van de executable (terwijl ik de .exe file in \%sytemroot%\system32\ had neergezet). En toen draaide hij wel.