Perhaps you missed one of the original posts. The user is logging into the machine and has a persistent drive mapping. It works fine. The executable being run by the task works just fine when run from the command line. When run from the task scheduler, even when the user is logged in, it fails. When the same user has his drive deleted (can't have two mappings to the same drive) and it is mapped by creating a bat file to map the drive as the same user, same password, then running the exe, then un-mapping and this bat file then run from the task scheduler, it works as a drive letter, not as a UNC connection.
From: Andrew S. Baker [mailto:[email protected]] Sent: Thursday, June 03, 2010 1:27 PM To: NT System Admin Issues Subject: Re: Server 2008 reading from Novell server >>The log says the source folder does not exist, then lists the correct source folder. Which we are to understand is using a UNC path, correct? >> but that is the point. The user account is not function inside the task under server 2008 as it did in server 2000. To say that there are substantial differences in the networking of server 2008 vs 2000, would be a huge understatement. However, it is still possible that there are other factors at work here. I wouldn't doubt, for instance, that there are different versions of the Novell client in play as well. >>OTOH, the ability to map a drive and use it within the same task indicates that it IS a rights issue. No, that's not a rights issue. If the drive could NOT be mapped for some reason, then that would be a problem with rights. However, when a task starts up, that user does not typically have any drive mappings associated with it. It does have all of it's rights to access remote resources -- as UNC. To use mapped drives, there must be a persistent mapping already in place, or it must be done at the running of the task. This has been true of Windows forever. One way around it would be to logon to the machine locally as the intended user and create a persistent drive mapping to the location in question. Alternately, you could perform the same function within a scheduled job using the appropriate user account. It is possible that this was done for that Windows 2000 machine at some time in the distant past. >> The task is working with the bat file workaround, Which implies that it is using a mapped drive, rather than a UNC path. Which makes what I said above more likely. -ASB: http://XeeSM.com/AndrewBaker On Thu, Jun 3, 2010 at 1:13 PM, Steve Kelsay <[email protected]> wrote: The executable is a single executable. It writes its' own log file. Nothing is showing in the system logs. The log says the source folder does not exist, then lists the correct source folder. Yes, it does indicate it is not a user account issue, but that is the point. The user account is not function inside the task under server 2008 as it did in server 2000. Everything is the same. OTOH, the ability to map a drive and use it within the same task indicates that it IS a rights issue. It is almost like the task is not using the correct account to execute the task. That sounds like the issue to me, but I am not knowledgeable enough about Novell to enable the auditing on it to see. I am looking at that now, but we are also moving our entire data center across town, (this is a part of the move) and I am a bit stressed now. The task is working with the bat file workaround, so the crisis is over for now. I may have to let this slide for a week or so, but I am interested in it for future task scheduling. From: Andrew S. Baker [mailto:[email protected]] Sent: Thursday, June 03, 2010 12:59 PM To: NT System Admin Issues Subject: Re: Server 2008 reading from Novell server We're still missing some key info, methinks. Is the scheduled job a single executable that does all of this wonderful magic? Where is the error message occurring, and how are you able to determine if it is the source location or destination that is having the problem? If you are able to get things to work with a batch file, doesn't that indicate that it's NOT an account permissions issue, but something else that is different between the old system and the new? -ASB: http://XeeSM.com/AndrewBaker On Thu, Jun 3, 2010 at 12:01 PM, Steve Kelsay <[email protected]> wrote: No, I think I led you astray. The executable does not use FTP. It picks up files that have been ftp from the external world to a Novell server, then moves the files using windows to a Microsoft server. That is the point that is failing, it cannot see the Novell folders in order to do the file moves. It is almost like the user account is not being recognized, but only for the Novell access. Why it is recognized while running outside of the scheduled task and is recognized running the exact same executable inside the task is the issue. From: Ziots, Edward [mailto:[email protected]] Sent: Thursday, June 03, 2010 11:10 AM To: NT System Admin Issues Subject: RE: Server 2008 reading from Novell server OK then can you see if it takes the information from the FTP server ( FTP logs) (Step 1), then audit the Microsoft Server to see if its put there with the auditing. Also you can use tcpview to take a look if the executable when run makes a connection to the FTP accordingly. Z Edward Ziots CISSP,MCSA,MCP+I,Security +,Network +,CCA Network Engineer Lifespan Organization 401-639-3505 [email protected] From: Steve Kelsay [mailto:[email protected]] Sent: Thursday, June 03, 2010 10:06 AM To: NT System Admin Issues Subject: RE: Server 2008 reading from Novell server It runs an executable which moves files from certain folder trees on a Novell FTP server to a Microsoft server to be processed by our tax system. Essentially, it just moves files from a public server to a private one and renames them according to some weird process incorporating account names and dates. From: Tom Miller [mailto:[email protected]] Sent: Thursday, June 03, 2010 10:03 AM To: NT System Admin Issues Subject: RE: Server 2008 reading from Novell server Can you tell us what the script/task you are attempting to run is supposed to do? >>> "Ziots, Edward" <[email protected]> 6/3/2010 9:57 AM >>> Can you lay down auditing on the target directory for the account you are using in the script and audit for read/write access for that account, this will tell you if the script is even attempting to read/write to the directory accordingly. Should pair down where you might be having issues. Remember auditing is your friend, when you have these issues. Either that or turn on filemon and look at the script when its running and see what its trying to touch. Z Edward Ziots CISSP,MCSA,MCP+I,Security +,Network +,CCA Network Engineer Lifespan Organization 401-639-3505 [email protected] From: Andrew S. Baker [mailto:[email protected]] Sent: Thursday, June 03, 2010 9:51 AM To: NT System Admin Issues Subject: Re: Server 2008 reading from Novell server >> It is the correct path, I can browse it using the same account. I take this to mean that you have logged on to the console with the same account as the "Microsoft account" in question and then you're running whatever the scheduler is running? >>when run from Task scheduler, it gets an error the target path cannot be found. What are the permissions on the folder and the share? Are you seeing any errors in the eventlog? >>The bat file will work, but there will be other problems until we can eliminate the Novell side, so I would like to get this to work. If the batch file is working, then isn't this a valid workaround? What other types of problems do you anticipate? -ASB: http://XeeSM.com/AndrewBaker On Thu, Jun 3, 2010 at 9:35 AM, Steve Kelsay <[email protected]> wrote: It is using a Microsoft account. Runs fine when run manually, when run from Task scheduler, it gets an error the target path cannot be found. It is the correct path, I can browse it using the same account. It is like the 2008 task scheduler does not like to connect to the novell box, but the server does just fine. I ran a bat file which maps a drive, then uses the drive letter, then deletes the drive, and it runs OK, but the UNC just ain't getting' it. The bat file will work, but there will be other problems until we can eliminate the Novell side, so I would like to get this to work. From: Andrew S. Baker [mailto:[email protected]] Sent: Thursday, June 03, 2010 9:00 AM To: NT System Admin Issues Subject: Re: Server 2008 reading from Novell server What account is the scheduled task using? Does the job work fine if you manually run it using the same credentials as the scheduled task? If not, what error is received? -ASB: http://XeeSM.com/AndrewBaker On Wed, Jun 2, 2010 at 4:03 PM, Steve Kelsay <[email protected]> wrote: The thing is, it all worked for years in all earlier version of Microsoft using UNC connections. Now in 2008, it is screwed. I need to do some workarounds, as this is a "big bucks going into the bank" issue. -----Original Message----- From: Ben Scott [mailto:[email protected]] Sent: Wednesday, June 02, 2010 2:56 PM To: NT System Admin Issues Subject: Re: Server 2008 reading from Novell server On Wed, Jun 2, 2010 at 1:55 PM, Steve Kelsay <[email protected]> wrote: > It is just that when running as a scheduled task, > the Novell login is popping up, which doesn't work if no one is on the > machine, and it will not run unattended. Scheduled Tasks don't have access to things like network drives when using the Microsoft SMB client. It's almost like they run in a different user profile. I would expect the same to apply to NetWare. Try using a local batch file as the Scheduled Task target. Have that batch file map the network drives, and then run whatever you want to run. You might still need to provide credentials to the NetWare client, but that's at least scriptable with a batch file. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
