Stuff run from the scheduler probably gets a different security context which doesn't give it any access to network shares.

You can try LogonUser() followed by CreateProcessAsUser() (see Win32::AdminMisc from http://www.roth.net/, perhaps) or you can try to configure the scheduler service to run as a specific user (which still might not be enough).

Actually, I have tried everything I can think of as far as permissions go - even so far as to try the Domain administrator account and the local administrator account. No dice.

Well, I did say "and that might not be enough" ):

The scheduler may start jobs in a different security context than its own (you did stop and restart it, right?) and then you can be "domain admin" but have a security context that allows no net access.

You could look for configuration options in the scheduler to see if you can configure what type of security context it lauches its jobs.

You could skip using the scheduler and just have a Perl script running as a service.

You could try using Win32::NetResource to specify a username and password to the share in order to access the files.

You could try the LogonUser() and CreateProcessAsUser() thing.

You could also do some debugging to figure out where the script is dying. For example, redirect STDOUT and STDERR to a file inside a BEGIN block at the top of the script and print status messages.

        - tye (but my friends call me "Tye")

I had to deal with this about 2 years ago. my foggy recollection is that schedule jobs run as "System", and the "system" user has absolutely zero rights on other machines (but is like root on the local). You cannot get the system account priviledges set for other machines, so logging in as another user is required.

I am pretty sure I used the module mentioned by tye, but in effect, what I had to do was startup and then login/alias myself as a user that had priviledges on the target shares. I do remember it was a real pain in the ass (I recall swearing alot and damning all things windows to eternal hell), and ended up finding an alternative solution. I wish I could be more helpful, but it's been too long and I don't have any of that code.

if you can manage to get this going, I'd certainly ++ your tutorial :-)

PS: since it runs from an icon, maybe you need that rocking monkey toy that Homer Simpson used to tap his keyboard in order to keep the nuclear reactor from melting down? (oh wait, that didn't work) :-)

You might try putting in some debug prints to a log file you could check later (the contents of the %Env hash might be particularly useful if you suspect it's a security problem.

And while you say you're not trying to be too pretty yet, it strikes me as significantly easier to use one of the several mail modules (which would make it easier to debug, as well!) instead of doing raw socket writes. You might also investigate Archive::Zip (and Compress::Zlib) to do your zipping for you, too.

There's something to be said for building the walls and the roof out of pre-cut lumber rather than trees you uproot yourself.

I had a similiar problem under NT4.0. The problem was that the Scheduler task normally runs as 'System Account', a user with few priviledges. What I did to solve it was go into Start->Control Panel->Services, double-click on 'Scheduler', select the radio button for 'Log on as', and set the account/password you want the scheduler to run as.

I don't remember if that changes the scheduler instance only for jobs created by that user, or if other jobs scheduled by other users will now run under that account. I treat NT/Win2K as a single user system, not a casual terminal that people can log into, so I can't say.

I fought with this when it came to sharing drives. Everything was working fine, except I couldn't access a shared network resource. Anyway, I'm imagining that Win2K has something similiar, since it's so heavily NT based.

Update: Win2K has a similiar facility. Goto Start->Control Panel->Adminstrative Tools->Services. Scroll down and double-click 'RunAs Service', and select the 'Log On' tab.

Windows 2000 won't let you run the scheduler in the context of another account - it fails to start with the message "Run individual jobs in the context of the desired account" message. I also tried wrapping it in a batch file - same deal - when the batch file is double clicked, it works, when it's scheduled, it's not. I'm going to try a different file schedule utility - winat maybe - I'll keep you posted.

"Run individual jobs in the context of the desired account"

...which seems to imply that you can configure what security context you want each job to run it. That sounds like the easiest solution if you can just find where that is documented.

        - tye (but my friends call me "Tye")

UPDATE: I remembered what is was, it wasn't the network path. I had to wrap the perl script with a batch file. This was the batch file:

d:\perl\bin\perl.exe c:\path\script.pl
[download]

foreach my $item (@theseContents) {
      if (!($item =~ /\.zip$/)) {
           if (!($item =~ /^\./)) {
               my $temp = $thisDirectory.$item;
               if (-d $temp) {
                   .......
               }
           }
      }
}
[download]

foreach my $item(@theseContents){
    next unless ($item =~ /\.zip$/);
    next unless ($item =~ /^\./);
    ..... rest_of_code ......
}
[download]

my $file = shift; #grab the first arg to the sub
my $todayfile = sprintf("%02d%02d%02d\.log", 
                           $times[5]-100,$times[4]+1,
                           $times[3]);
#then your exit routine
[download]