Environment: W2K Pro workstations, logging on locally, but using system Startup scripts
as specified in policies on W2K Server.

When I run my logon.bat (from my server's NETLOGON share), which is:

@ECHO OFF
%0\..\kix32 %0\..\logon.kix

....and logon.kix is:

BREAK ON
REDIRECTOUTPUT("c:\temp\NAVCheck.log",1)
IF @INWIN = 1 ; If O/S is NT
$RESULT = KEYEXIST("HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Norton AntiVirus NT\Install\7.0")
IF $RESULT = 1
$NetDir = ("\\Zacchaeus\c$$\Admin\Updates\Norton Antivirus\")
$NetFile = DIR("\\Zacchaeus\c$$\admin\updates\norton antivirus\*.exe",1)
While $NetFile <> "" and @ERROR = 0
$NetFile = Dir("",1)
Loop
ENDIF
$NAVDate=RTrim(Substr($NetFile,1,4))
$z=Substr(@DATE,1,4)+$NAVDate

; Check currently applied definition

$X=ReadProfileString("c:\Program Files\Common Files\Symantec Shared\VirusDefs\Definfo.dat","DefDates","CurDefs")
IF @ERROR=0
$DefDate=Substr($X,1,8)
ENDIF

; Compare dates of network update file and current client definition

If $NAVDate <> $DefDate ; file dates out of sync......
MESSAGEBOX("This computer's AntiVirus definitions are out of date. Click 'OK' to continue....","AntiVirus Definitions Update...",64)
RUN $NetDir+$NetFile +" /q" ; execute update in quiet mode
LOGEVENT(0,2,"AntiVirus definitions " + $NETFile + " have been applied on " + @WKSTA + "(" + @USERID + ")", @LSERVER)
SENDMESSAGE("mreed","Virus definitions on " + @WKSTA + "(" + @USERID + ") have been updated.")
ENDIF
ENDIF
RETURN

I find the following in the workstation's Event Log:

"The description for Event ID (1312) in source (KIXtart) cannot be found. The local computer may not have
the necessary registry information or message DLL files to display messages from a remote computer. The
following information is part of the event: WkstaUserGetinfo failed error: A specified logon
session does not exist. It may alredy have been terminated (0x520/1312)."

Can someone help me figure this out ????

TIA !

Spinning in circles.....

- Michael

CompTrends - interview with Ruud van Velsen

[Thank you MCA for re-hosting this]

This is an interview with Ruud Van Velsen - the Developer of KiXtart. He da man. He da big man ! Once you open this page - hit crtl+f and type in

"what issue"

This will take you directly to his comments about this error... basically a very common error (I get about a bazillion of these a week). It spooked me the first time I saw it too. kiXtart posts this message to the event log then merrily continues on it way.

But wait a tick - this error usually appears when you run KiXtart under the scheduler or task scheduler. Are you saying that your getting this when you run it manually ?

What happens (when running KiX under the scheduler) is that KiXtart is trying to get some user context (username,homedir) all that crap - but can't. Scheduler (by default) runs under the system account. Folks that really hate this message usally just change the service to "log on as" a domain account with password. This gives KiXtart the "user context" it needs. But like I said - (we) don't bother with that and just ignore the messages...

So are you getting this error when you run it manually - have you tried logging in with a domain account and running it ?

[man I ramble - don't I ?]

-Shawn

p.s. Ahhh - I just re-read your comments - SYSTEM STARTUP SCRIPTS - I think you just found a wonderful new excuse for KiXtart to post a 1312 eventlog error. I suppose that SYSTEM STARTUP SCRIPTS run with zero user context ?

[This message has been edited by Shawn (edited 08 June 2001).]

Thanks for the reply. Yeah, I'm gainin' on it.... two steps forward, one and half back.
I will take up the baton again tomorrow....

TTFN.....

- Michael

Read the interview stuff; obviously, Ruud is a genius!
Oh, but then so are some of the users on this board!
Okay. So...I guess I'll either have to rethink how to deploy updates via logon scripts,
or find a way to introduce [the apparent] requisite "user" info. to the SYSTEM context
(and I'm clueless here...).
Given that my users (non-admin rights)logon locally to their W2K machines, I wanted this NAVCheck script,
as well as others, to be centrally controlled.
Now another related issue; the script doesn't appear to run at all for non-admin users.
More ideas gladly welcomed!

Continued THANKS for everyone's help. This is an awesome board!

- Michael

There are a quite a number of genius's on this board - I'm hoping that one of them can step in and help us out

Have you considered using the autoupdate feature of NAV. Bryce has done a lot or work in this area - he even has some admin scripts that can deploy and configure NAV automatically for you ... I'm hoping he can step away from his busy consolidation and help you out...

Houston - we have a problem...

Have you tried searching the board for other options ? NAV is a big topic arounf here, you'll probably find about a million posts on this subject ...

Here's my two cents. I'm thinking maybe you can setup a scheduled task to do this... it would work like this ...

1) Configure a task in Task Scehduler to run at user logon ...

2) Provide the username and password of a domain account that has access to your NAV shares. This account would be (what we call anyway) a "functional id". One where the password never changes

3) Logoff your workstation and pray

I've never actually tried this but eh - you never know !

-Shawn

Thanks again for the response.

Yeah, I've found quite a few scripts involving NAV (asst'd versions); think I'll revisit them, in hopes of finding the right
pieces-parts that'll fit this peculiar happenin'.

Plus experimenting with logons/rights/locations, etc.

Haven't done much with Task Scheduler; will add that to my "to-do" list.

Keep up the good work!

- Michael

My admin script were for Mcafee not NAV , but.... what i did for mcafee could be duplicated for NAV.

what i did for mcafee was this.

• Configure mcafee's task scheduler to autoupgrade it self from a folder on the local network, checking random X number of minutes after the hour. All of this information was in the reg.
  
• Create a DOMAIN\McafeeUpdate user account
  
• gave the Domain\McafeeUpdate account local admin rights on the target pc's
  
• granted the Domain\McafeeUpdate account the "Logon as Service" rights on the target PC's
  
• ran Mcafee's Task scheduler under the Domain\McafeeUpdate account.
  

Here is the admin script that did all of this for me. NT_Mcafee.kix (i still use this script, just used it a little while ago )

There were some extra steps, involving the superdat file and you can find those here.

If i had NAV.... i would be glad to help out more

But Shawn's idea sounds like it might work!

------------------
kix.isorg.net

What version of NAV are you using? We are using Norton AntiVirus Corp Edition v7.51 build 48a
This software keeps almost all users up to date (90%+) on its own. I want to use KiXtart to find those other 10% and take action on them.

Check back soon...

Thanks!

We're using only client-based NAV vers. 7.0.

It would be nice if I had Corporate Edition.

I think I'm going to have to read up on SU, as it's beginning to appear I have some rights issues
on the clients; how to give the .kix script Domain Admin privilege without
giving the users the same.

- Michael