And I'm saying that this is not a new problem under Windows Server 2008. There was very likely something done on your 2000 server to accommodate this, because this is the way that Windows normally operates with mapped drives and scheduled tasks.
The recommendation for years has been to use UNC paths in scheduled tasks. I'd be interested to see if anyone else has a different experience. -ASB: http://XeeSM.com/AndrewBaker On Thu, Jun 3, 2010 at 4:02 PM, Steve Kelsay <[email protected]> wrote: > We are not communicating. The Batch file is mapping the drive fine. The > task is not able to run without the ,mapping taking place inside the task. > The question is, why do we need to map the drive inside the batch file? The > server has a drive already mapped, and under server 2000, the executable was > able to make a UNC connection without an explicit mapping. What is the > difference? > > We would prefer not to have to manage drive Mappings for every task that is > run. > > > > *From:* Andrew S. Baker [mailto:[email protected]] > *Sent:* Thursday, June 03, 2010 3:28 PM > > *To:* NT System Admin Issues > *Subject:* Re: Server 2008 reading from Novell server > > > > You can map a drive in one of 3 ways: > > - NETBIOS name > - FQDN > - IP address > > > > These methods can be done to the same resource simultaneously with > different credentials. > > > > If you have the batch file use one of the latter two options for mapping > the drive, there won't be any conflict with the user. > > > > -ASB: http://XeeSM.com/AndrewBaker > > > > On Thu, Jun 3, 2010 at 3:00 PM, Steve Kelsay <[email protected]> wrote: > > 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/> ~
