We want to launch a session start script in Network Connect. However, we're getting very inconsistent results. It works for one user, and noone else. We're having big difficulties working out why. It doesn't appear to be dependent on the operating system. Does anyone else use session start scripts? Have you ever had these problems?
We have similar issues although our error rate is probably only around 5%
The other annoyance we have is that there is no support for passing DHCP through to a microsoft dhcp server to allow easy updating of DNS for out Network Connect clients. The issue it causes us is that our help desk will try to access their computer by computer name. The fix for this is in our login script. Unfortunately, most network connect related calls are for drives not mapping, which is also in the login script...
Originally we were trying to reach the script through a SAM connection, (ie local to the IVE). After several weeks working on it with a Juniper engineer, he eventually told us that SAM can only run local scripts, (ie C-drive only). He said it was, however, possible to reach scripts local to the IVE on NC. Further testing on NC has so far proven unsatisfactory, though. We managed to find the following error mesasges in networkconnect.log:
Can't copy win_start_script from \\server1\script.bat to: C:\DOCUME~1\user\LOCALS~1\Temp\3865.tmp.bat, err=53
There were a couple of other similar errors, 20 & 1326. So far, though, noone has decoded them, though. Any ideas, anyone?
I've run session start scripts for a long time. I originally used a local script with success, but eventually moved to a network-based script.
To answer your question - YES, I've had big problems. I've had MTU problems, issues with NetBIOS (hence, no script access) caused by Kerberos over UDP (yikes, that was awful), and problems with syntax (\\domain doesn't work in the UNC).
How did you make things work then? I am trying desperatly to make a WSAM script work upon logon. Yes I would like to have the script sit on a DC and not local.
I have a pair of 6500's with 6.1R5
I've had this working for some time. Assumes AD & Login Scripts.
I've only got .bat files to work reliably. you CAN'T use and LDAP attribute for the login script name (even though it's in the user's LDAP attribute list. That's an enhancement I wish would go on a wish list)
Hi, can you go into a bit more detail on that? Is NETLOGON a network share, or a server? Either way, whereabouts do you store the script?
>> We had MTU problems, issues with NetBIOS (hence, no script access) caused by Kerberos over UDP (yikes, that was awful).
I'm interested if you can provide more details about the statement above?
We have also had issues with MTU on external interface where home drive mapping over NC didn't work with some network cards and carriers. We also have had issues with Kerberos over UDP but no one of the above problems had been put in relation with the problems we have with login script not launching all the time.
Do you have any more details you can share with us/me, for example workarounds, releases that solved the problem, troubleshooting steps or anything I would be more then happy!
And for the rest of you, anyone more that having this kind of problems?
Thankyou / ahd71
Mine works fine with NC. WSAM isn't not an option with the current revs of code. The script I am running is sitting on a DC.
Hi, I am not sure if this is still an issue for you but in my investigations the err 53 is related to the dns lookup port (TCP 53). If you make sure your network connect access policy includes an entry for dns lookups (ie, add your dns servers tcp://192.168.0.1:53 for example) and also entries for the file server you are trying to reach than the network based login scripts should work.
Also, due to Juniper's limited login script ability (it can only run .bat or .exe files), rather than just use .bat files to run or call the scripts I used vb to create an executable file and then set Juniper to run the .exe file. By doing this I could make the whole login process far more professional looking (a few images, nicer fonts etc), a far better way to go for us when presenting Juniper to external staff or vendors.
Hope this helps,