Login Script: Advanced Run External Program

Sorry to hear you're moving to a platform that will increase your IT costs, limit your technology options, and provide less-reliable services. Doesn't sound like a good business decision to me, but who knows, mebbe your company's competitors are making smarter business moves.

Why not simply implement Native File Access Protocols (NFAP) on the NetWare v5.1 server? This was introduced in NetWare v6, but a backport was made freely available to licensed v5.1 networks. Think of it as "Samba for NetWare" - it allows a NetWare server to appear as a CIFS server to Windoze clients (just minus the BSODs).

Have you tried using the # instead of the @?

You could create a batch file that is called but if the command prompt PIF isn't set for running minimized, they'd still get a window.

If you are using newer windows client PC's you could probably use wirdows scripting and call that instead.

If it takes so long to map a drive with net use, that should tell you something, though.  You do realize of course, that Windows - even Windows 2003 server, has only a crude subset of NetWare's filesystem security, and the ACL inheritance isn't dynamic from the directory down meaning the user sees all of the directories and subdirectories rather than just what they're given rights to?  That NetWare still beats Windows, even Windows 2003, in file and print serving?  That it takes 2-3 multiprocessor Windows servers to do the work of one, uniprocessor NetWare server?  That when LongWait finally gets released, in order to use the version of AD that ships with LongWait's server version, you'll need to do a wholsale upgrade of all of your Windows AD controller servers?  And that means you'll have to upgrade all of your user CALs to the LongWait CAL, at full price, if you didn't subscribe to a SA contract?  That Active Directory is still playing catch-up to eDirectory/NDS, and there is no indication that Microsoft will ever make a non-Windows version of Active Directory while eDirectory runs on all flavors of Windows server on the NT4 and above kernel, NetWare 5.1, 6.x and beyond, several flavors of Linux, Solaris, AIX, HP-UX, and more?

Moving to windows is not my choice rather a Government mandate. I don't care which way we go I just want them to choose one and stick with it, supporting two seperate systems is such a pain. Either way I can't change what we use so let's get back to my question please?

Using # would only slow things down since they would have to wait for the mapping to finish to continue with the rest of the script.

I don't want to use windows scripting because then I would have to maintain two seperate login scripts. There are several other people that maintain the network so the simpler the better.

Can anyone give me an example of running a batch file from an MS share? Would something like this work? @\\server\share\path\filename.bat  
Is there any way to get that to run minimized?

NFAP sounds interesting, I would love to get rid of the novell client entirely and just use AD. I could move the novell login script to a windows login script and streamline the whole process. Would I have to join the Novell server to AD in order for the users to authenticate or would I still need the novell client for that?

Cant you call the .wsh file from the NetWare login script just like you'd call a .bat file or any other external executable filetype?

I believe NFAP/CIFS server can join a traditional NT4 domain.  I don't know if it can join an AD domain.  The users will still have to be in both environments, because the filesystem rights will still be controlled in the NetWare/NDS environment.

Government mandate to use Windows.  No wonder we've got deficits. ;D

Maybe that's where the "good enough for Government work" phrase came from ;D

NFAP is good to know about but I don't think its what I need in this situation.

Running a .WSH actually might work, no DOS window involved. For some reason I didn't think about that. Not quite as simple as I would like since its a seperate file to maintain but its better than what we are doing now.

Do I have to run a Novell server to create a novell share? Could I somehow create a Novell Share on the MS 2003 box then just use the regular Novell MAP command? It's actually a DFS share replicated across 3 servers, how would I make that visible to Novell?

To be honest, I've never looked into login script processing using clientless login to NFAP/CIFS, so I don't know if you can use a NetWare login script to map any CIFS/SMB share.  Since you need the Novell client to process the NetWare login script, I would think you'd have to do a NET USE to map an NFAP/CIFS share just like you would with a Windoze share.  

If that's the case, then you could transition to using Windoze-based login scripts with a NET USE for the NFAP/CIFS shares.  You'd just have to figure out how to only use the Windoze login scrpt for those PC's that have had the Novell client removed.

 I don't know to what extent NSS on NetWare 5.1 uses DFS, and I don't even know that the DFS support in NSS on modern NetWare can work as part of a Windoze DFS share.

I had a similar problem trying to map a drive to a samba share on my linux box.

Here's a very simplistic AutoIt3 script to map a drive letter.

Compile it to an executable, stick that in the \\sys\login folder and run it from the login script. It works pretty well. You can tart it up with lots of bells and whistles, error checking, etc.
 

; Simple AutoIt script to map an SMB share with a simple progress dialog.
; public domain, no copyright

$UNCPath = "\\server\share"
$DriveLetter = "U:"
$i = 0 ;
$status =  0
$timeout = 1000


ProgressOn("Please wait...", "Mapping network drives") ;

DriveMapAdd($DriveLetter, $UNCPath )  ; Map the drive letters

do
   ProgressSet( 50, "Waiting for network drive...") ;

until FileExists("U:\")

ProgressSet( 100, "Done...");
Sleep(100)   ;
ProgressOff();

Kudos for using AutoIt, I love that software. I didn't realize there was a new version out either, the GUI stuff should be really fun to play with. I think I am going to go with the WSH script though, not many people know about AutoIt yet and that makes it harder to maintain.

>
> Cant you call the .wsh file from the NetWare login script just like you'd call a .bat file or any other external executable filetype?
>

I tried running a .VBS file and it didn't work, will it work with a WSH file?

whoops, I forgot the cscript  before the VBS path whish is why it didn't work. Unfortunatly a DOS box is still open in the background while the VBS file runs so it's no better solution than before.

Actually the best option so far is the AutoIt script, the DOS box is still launched (I don't think there's any way to get around the DOS window) but it disappeares right away and the AutoIt App continues to run. It's a huge pain to maintain though since it need to be compiled again whenever there's a change.

I think I'm pretty much stuck, there seems to be no way to get rid of the DOS windows when running an external program.

So I can:

    1: Leave it as is, just tell users not to close ODS window
    2: Map the drives using a GPO, but that creates a second script to maintain
    3: Write an AutoIt program that maps the drives, which is even harder to maintain than a GPO script

For right now I guess I'm going with option 1, it's the easiest to maintain though its the ugliest implimentation for the users.

Unless someone can offer a way around the DOS window I think I'm going to have to ask for a points refund since no one could really offer a solution.

If Windows Scripting Host is running on the PC's, then a .WSH file *should* work, IMO.  I don't know, 'cause I don't have to do it, so I've never tried, but it makes sense to me that it would.

I think it would, but it would still be launched in a DOS window so that doesn't help any.

Crap.  Oh, well, we tried...

If you want to give it a try, here's a compiled executable version of the above script.
 
http://www.milleniumhandandshrimp.com/upload/drivemap.exe

Passing in the drive mapping from the script is something I hadn't thought of at all, I was thinking maybe reading the mapping in from text file but this is much better. Launching an executable DOES  open a DOS window but it merly flashes on the screen for a second so its much less obtrusive. Also since the mappings are in the Novell login script itself it becomes much easier to maintain.

I will test this tomorrow, but I think we have a winner!

Could it be there's something else in your login script causing the DOS box to appear?  When I run an executable in my login script with the # prefix, there's no DOS window at all, not even a hidden one.  Maybe it's due to differences in our clients and platforms or something.

Maybe, I'm using Netware 5.1 with 4.9 client on windows XP SP2 machines. I have been using the @ sign instead of the # because I thought the only difference between the two was that # launches the external program then waits for it to finish before continuing the rest of the Novell script while the @ launches the external program then continues without waiting.

I will try it the other way and see what happens. Is it possible that this is configurable on the Novell server somewhere?

Hmm, I'm using Netware 6, but everything else is the same, and I'm pretty sure this worked the same when I was still on 5.
I doubt there's a server setting for this, it seems more like a client function. But I don't know for sure.
Maybe something else in the environment is different, possibly related to your mixed-platform environment. Maybe using @
spawns a new process via command prompt or something. I'll fart around with it and see if I notice a difference.

I tried this today and it worked great! For some reason I am still getting the DOS window for a second but other than that it's perfect. Using # or @ doesn't seem to make any difference. Thanks for the help!!

You're welcome!