|
|
|||||||
I came across this a while back but never got a chance to look into it futher. Our AD profiles run a batchfile to lauch kixtart on login, which comprises of:- Code: @ECHO OFF %0\..\Kix32.exe %0\..\kixtartSig.kix I've placed kixtart 462 into a sub folder and amended the batch file to Code: @ECHO OFF %0\..\KIX462\Kix32.exe %0\..\kixtartSig.kix What i've noticed is that when logging in my home drive isn't mapping the U: If I put it back to running 4.12 it's fine Any ideas? |
||||||||
|
|
|||||||
I don’t think this is related to how you call the script. Can you post the code that is supposed to map the U drive? |
||||||||
|
|
|||||||
You wouldn't have thought so, the U: is connected using the users profile in AD....but If I have not set to run the batch file, my U: is mapped If I edit to run from \412\ my U: is mapped If I edit to run as before my U: is mapped If I edit to run from \462 my U: is not mapped |
||||||||
|
|
|||||||
Let us see your drive mapping code. |
||||||||
|
|
|||||||
Allen, See: Originally Posted By: sparkie ... U: is connected using the users profile in AD ... |
||||||||
|
|
|||||||
Yes... but something is happening during the script to cause it to remove U... so without seeing the script... only guesses. |
||||||||
|
|
|||||||
You might add this to your logon script prior to running the kix script just to make certain U: is there. Code: if exist "U:\" echo "U:\ mapped" |
||||||||
|
|
|||||||
There's nothing in the script refering to U: All U: assigning is done via AD user profile tab U: must be there before running the kix script otherwise it wouldn't show when I've logged in when I've removed the entry in the user profile to run the .bat file, which in turn runs the script. Also, why does it work with 4.12 |
||||||||
|
|
|||||||
Ok, I've found the problem 4.62 does not like this command. Code: USE * /DELETE |
||||||||
|
|
|||||||
What I would do is enumerate all mapped network drives before any other part of the script starts and write that to a text file and do the same after the entire script has completed and compare both values. Some debugging is the only way to see what is going on. We are running 4.62 almost since it was released and have no issues whatsoever with the home drives not being set by the settings in AD. The example below requires the EnumNetworkDrives() from the UDF section. An example: Code: Break on $rc = Open(1, "c:\DriveDebug.txt", 5) $drives = EnumNetworkDrives() For Each $drives in $drives $rc = WriteLine(1, $drive + "#") Next $rc = Close(1) |
||||||||
|
|
|||||||
Well, USE * /DELETE would indeed remove all mapped drives, including the home drive mapped by the user profile. That's why in our login script, we don't use this syntax, but instead remove all drives individually except for the home drive and any other drive letters "permitted" to be used for ad-hoc mapping. Sounds like it might be a timing issue between 4.12 and 4.62. It seems like the home drive hasn't been fully processed when 4.12 hits the USE * /DELETE command. Glenn |
||||||||
|
|
|||||||
which would indicate that 4.62 is slower anyways, Glenn, I think you are correct on that one. |
||||||||
|
|
|||||||
Same here. Use * /delete is nice but imho it is a bit like cutting a toothpick with a chainsaw. Just a little too aggressive I guess 4.62 still likes Use * /delete and from the posts above it seems it does exactly what is is supposed to do. We just enumerate all connected drives, check and map all needed drives and disconnect whatever was connected but is not needed (anymore) one by one. |
||||||||
|
|
|||||||
Caught between the devil and the deep blue sea then. If 4.62 is indeed slower then that's not a solution (for us anyway), expecially when you have 50 odd people logging in and out of TS Vitual Machines all the time. I'll probably look to delete individually and re-add within the script rather than using a txt file, simply to keep things together, but at least I now know what the issue is and can deal with it. Thanks all |
||||||||
|
|
|||||||
I think you might have interpreted slower a little to slow ... milisecs slower might be a better description. I use 4.62 for everything I do, and can tell you it is not slow. |
||||||||
|
|
|||||||
The text file I mentioned is just for debugging to see if the U drives exists in the beginning and if it still exists when all is done. I also use 4.62 for everything and it is working just fine and fast enough. A user will not notice a delay of a few milliseconds. |
||||||||
|
|
|||||||
I use Glenn's MapDrive UDF and it just works! Prior to using it, was seeing similar issues between KIX Versions/OS Versions. Using 4.62 with it currently on Windows 7/8 CP. |
||||||||
|
|
|||||||
Well, it is bigger, thus takes a ms or three longer to load (esp. over the network), so it COULD be possible that 4.12 removes the mapped drives BEFORE the profile connects the home share, while later versions do it right after the home share is mapped. It's a few ms either way and not an excuse to not code this properly. I'd have clients in an uproar if we blindly removed ALL mapped drives during login.. most sites allow a small range of drive letters for users to define their own connections. As for logging, take a look at the MSG() UDF - makes it easy to write timestamped logs, errors, and debug messages. Glenn |
||||||||
|
|
|||||||
Is the U: mapping from AD profile considered persistent? I think the Use statement in 4.62 was upgraded to also handle persistent connections when using the use * /delete syntax. That could be the difference between the older and the new. |
||||||||
|
|
|||||||
if the homedrive U: comes from the properties on the traditional settings of homedrive-path or whatever it is called, then it's not persistent. |
||||||||
|
|
|||||||
My interpretation of persistent is a mapping that reconnects after a reboot or logout, so yes the U: which is defined in AD member settings is persistent. Btw, the drive settings applied during the script are not set as persistent so to avoid any conflicts. Regardless, the two versions are acting differently and once I get this little project request out of the way, I'll be wanting to goto 4.62 and will address the mappings then. |
||||||||
|
|
|||||||
"Persistent" doesn't necessarily relate to whether the drive shows up every time, but rather how that is accomplished. In the case of persistent, then it has to be in HKEY_CURRENT_USER\Network. |
||||||||
|
|
|||||||
How to implement "USE MOST /DELETE" Code: ; Define drives not to remove - home drive and any "permitted, persistent mappings" $Exceptions = '%HOMEDRIVE% O: P: Q:' ; remove non-excepted drive mappings For $D = 65 to 90 $DL = Chr($D) + ':' If Not InStr($Exceptions, $DL) 'use ' $DL ' /delete' ? ; use $DL /delete Else 'not deleting drive map!' ? EndIf Next Note that no error checking/reporting is done in this example. Also, our commercial script will determine if the logon process is active or not, and either ignore trying to map the home share if it is, or will map it if it isn't. This is useful in situations where a user might connect via VPN after loggong on to their PC and maps their drives by manually invoking the login script. Glenn |