Can you provide the batch file you use as the work around? If the UNC path works for mapping the drive, it should work elsewhere.
-ASB: http://XeeSM.com/AndrewBaker On Thu, Jun 3, 2010 at 4:17 PM, Steve Kelsay <[email protected]> wrote: > <<The recommendation for years has been to use UNC paths in scheduled > tasks. >> > > OK, how do you get the unc path to work? That is the crux of what I have > been asking. It worked fine in 200, does not work in 2008. Nothing else has > changed except the task scheduler. I would love to do what you are > espousing, but it is not working, and therefore the emails to the list about > it. > > > > *From:* Andrew S. Baker [mailto:[email protected]] > *Sent:* Thursday, June 03, 2010 4:10 PM > > *To:* NT System Admin Issues > *Subject:* Re: Server 2008 reading from Novell server > > > > 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/> ~
