Uh, oh. Now what do I do? Need help badly.

I think I may have really screwed the pooch on this one.

We've been using NOD32 for 1.5 years and have .5 years left on our license for 80 PCs. We will gladly renew, as NOD32 has been great.

A few days ago, I noticed, on a download website, that NOD32 had a much newer version, 2.51.xx, while all my PCs had 2.50.xx. So I thought, ok, I need to download the new version, install it, and publish it to our corporate mirror, and executed that plan.

I must have downloaded the wrong version, because once I did that, every one of our 75 PCs started reporting that "You have been using NOD32 for more than the 30 day trial period. Update is no longer possible."

Crap! .. So, sure enough, the copy I downloaded was from Eset's trialware area, and not from the secure spot on eset's website. When I published the upgraded components to the mirror, every one of my licenses turned to trial, and now refuse to update.

I thought, ok, uninstall the trial copy on my PC, install the licensed one, then publish to the mirror and let the 75 PCs pick up the licensed upgrade. That didn't seem to work.

I still have control of them through the remote server/console, though. I've tried changing their config, adding our user/password to their update profile .. adding the .lic file to the config and publishing that. Nothing works.

Furthermore, it appears that to get a copy to go from Trial to licensed, it appears you must run an uninstall, reboot, then install, plus reboot. Dear god, if I have to do that to 75 PCs, I'll go crazy.

Anyone have any bright ideas? HELP!

 

certainly a pickle my friend. i'm sure someone will be able to offer some advice, but bear in mind that its a bank holiday (easter) weekend so you may not get an official response until office hours start again. hang in there and good luck!

 

If you have a license for Remote Administrator, use it to uninstall NOD32 and deploy a commercial version remotely.

 

yowser, how's that for service!?

 

We do have a license for RA .. I tried doing remote installs 1.5 years ago, and didn't have any luck. I suppose I should try to figure that out again. We don't use an authentication server of any sort, it's just a big ad-hoc network, and I think that was the issue. I'll give it a try, thanks for a tip.

Thankfully, Nod32 seems to be running on all machines, it just refuses to update .. well, at least I think it's working. nod32krn.exe is running as a process, so I assume it is still scanning.

 

Again .. plea for help.

Yeah, I need to bump this, hopefully someone can come up with something to help me.

While we have the RA Console, doing remote installations is probably not going to work. I've given it a number of tries .. unfortunately, it either won't connect with any PC, or will give "IPC connection failed".

So .. is there ANY chance there's some way of .. putting componant upgrades into the mirror, and forcing the clients to get them? Or am I totally screwed, since the clients are all refusing to update, perhaps they're not looking at the mirror anymore whatsoever.

The only thing that reliably works right now is the ability to push a config out to clients. Any chance there's SOMETHING in there that will help me?

ARGH!!!!

 

Re: Again .. plea for help.

Here is something from the Eset support FAQs that may help:

The basic reason for this is that "simple file sharing" allows remote users to access the computer with a "Guest" account, but actions like pushing an installation are not allowed to "guests". Unfortunately, you can turn off Simple File Sharing only if you have Windows XP Professional. There is no way to turn it off with WinXP Home.

 

Interesting .. are you talking about file sharing (set not to Simple) on the server pushing, or the client receiving?

I'm guessing file sharing on the client needs to be turned ON, not to simple .. ?

 

The "Simple File Sharing" option should be changed on the clients receiving the package. Problem is, you may have to go around the office and do this on 75 computers.......

I do not believe you actually have to create any file shares on the remote computers in order for this to work, though. The "Simple File Sharing" option really changes the way that remote users authenticate. There are hidden administrative shares that exist by default on Windows computers. For example, the C: drive is shared as "C$". By using a username/password with Administrator privileges on the receiving computer, the NOD32 RA console will have what it needs to install the program.

A brief history of "Simple File Sharing":

Suppose you configure Computer_A to share files, and you want to access these files from Computer_B. In Windows 95/98/ME, Computer_A typically shares its files without requiring a password to connect (though there is an option to require one). On the other hand, Windows NT/2000 did require the use of a password to connect, since these versions of Windows were more security conscious.

Come Windows XP, which is based upon Windows NT/2000. In order to make things easy for the home users coming from Win95/98/ME, Microsoft gave the ability to do "no password" sharing by automatically using a "Guest" account to log into Computer_A, and they called this "Simple File Sharing". The problem you are running into is that Windows will not let you install program remotely with a Guest account, because that would be a huge security hole, even for home users.

As for the username/password to use when installing the packages, any valid username/password combination for the computer receiving the package should work, as long as it has Administrator privileges. One word of caution, though...... I am not sure if a username with a "blank" password will work. This may be another security restriction imposed by Windows.

 

Should be able to do it all from the RAC. Before talking about XPHomeless much...what is your network setup? With over a dozen PC's...I hope you have a domain controller, with active directory.

 

Nope, as stated above, it's just an ad-hoc network of Win XP Pro. No domain controller, no authentication server. Our only network appliance is just a network storage device with security. No login scripts.

So .. hopefully someone will have a bright idea.

 

Can you at least try disabling Simple File Sharing on one of the computers to see if that lets you install remotely? If nothing else, that would at least confirm the cause of the problem.

 

I tried enabling simple file sharing .. no luck, either. The machine did have a shared directory, too .. and I had the account information correct.

BUT ** BREAKTHRU. I remembered old Norton AV could be fooled into giving you an update after you subscription expired by setting windows' clock back a year, then running update.

Sure enough, that trick works for NOD32 as well. I set a test PC's clock back, requested an Update-now thru RA, and presto, it worked. Back in business, as it grabbed the correct (non-trial) componants from Eset. Set the clock forward again, and everything is perfect.

QUESTION: Is there a way to provoke a Nod32 update-now via DOS command line?

What I'd like to do is create a .bat file that sets the date back, provokes a NOD32 update, then sets the date back to current.

.. I first thought that I could just leave the date in the past and let Windows TIme Service correct it later .. but that's not a great idea, plus, WTS for whatever reason blows up when the current clock date is in the past.

 

Just a tip that's off topic of this thread.....from someone who supports small to medium business networks for a living...once you get up past the dozen mark for computers...especially up past the 20 computer mark...it's time for centralized management. Many other reasons....but for a time saver as far as managing the network goes.

As the "peer to peer" network grows (ad-hoc is more a wireless type of P2P) it becomes more difficult to switch over to a proper domain...the larger it gets..the more difficult it becomes to mount such a project of introducing active directory.

Someone poor sap in our Speedguide forums came in and asked how to do several things they suddenly need to do...to a wide area network of over 300 computers...and they're all running peer to peer...they have "servers"..but whoever tried to call themselves the IT guy never promoted them to DCs...only left it in workgroup mode. Just an example of "you're screwed" once it gets to a certain size.

That part over.....are the local Administrator passwords the same, on your 80 or so computers?

 

I think duncantuna has the literal meaning of ad hoc in mind, meaning, "for the particular end or case at hand, without consideration of wider application." I think you will agree, this describes his network pretty well.

(no disrespect intended, duncantuna )

Funny how tech jargon (or any sort of jargon) takes general terms like "ad hoc" and limits them to have narrow, specific definitions.

 

External Application scheduler problem

New question.

I can't seem to get an external task to execute.

I've created a task that should execute a batch file, test.bat. Inside test.bat is a simple command, MKDIR c:\test ..

Upon running this task via Run Now, it should run test.bat, which would create the directory \test. It does not. No error message, nothing in the log, zippo.

Heck, if I delete test.bat alltogether, and hit Run Now on the task, it doesn't error, which it should, since it shouldn't be able to find the test.bat file to run.

Am I doing something wrong, or is the external application task not able to run .bat files?

(Notes: I'm on WinXP, running these tasks thru NOD32's GUI on the desktop. I deleted all other tasks, this is the only one scheduled.)

 

Re: External Application scheduler problem

Hmmm, I just tried that, and the same thing happened. Let me look into this some more, because I know all the other NOD32 scheduled tasks are running fine.

***EDIT***
Quick question. If you double-click on test.bat, does the C:\test folder actually get created?

***DOUBLE EDIT***
I am an idiot. I had a typo in the test.bat file.

The scheduled event does run just fine. However, there is no message in the Event Log.

 

AHA!

It's a bug. Or a feature. I'd call it a bug.

I was running the test.bat from my networked G:/ drive.

On a hunch, I moved test.bat to c:/ and tried the Run Now. WORKED!

I need to execute it from a networked drive (75 clients) .. so I tried an absolute path (10.1.1.18/test.bat) and that WORKED.

So .. I'd say that's a bug, not being able to execute tasks on network drive letters.

Seriously, thanks everyone for your help.

 

you may prefer to just run the date command directly without a b*tch file - might be easier than having to copy out a bat to heaps of PC's...
just a thought

 

To end this thread with the resolution for anyone who might have this problem again ..

In order to update a trial version with our originally licensed version, I needed to change all PC clocks to the year 2004 and update.

I did that via creating a .bat file, with the command "date 04-19-04". Then, you need to add that task to a config file in the scheduler (external application) and push the config out to all clients. Once this is picked up, when the task runs, all clocks should be at 2004.

Then run an update-now. Hope that works.

Then push out another config with another task, batch file setting the date to 2006.

-- Indeed, running the tasks seemed slow. For this procedure, I had all PCs hitting the RA server every minute, yet the scheduled task seemed to take 3-5 minutes to actually execute. The batch file to go to 2006 seemed to take even longer, so many people noticed their calendars were fubar, and I told them to manually change their year.

Anyhow .. thanks to all who offered hints on solving this issue. Some have warned me that this may not flip them all from trialware .. I'll keep my fingers crossed for a few days to make sure, but I've checked some of the machines, and their info no longer reports trial .. so far so good.