sparkie
(Getting the hang of it)
2012-04-19 09:26 AM
KIX462 issue

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?


Mart
(KiX Supporter)
2012-04-19 09:34 AM
Re: KIX462 issue

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?


sparkie
(Getting the hang of it)
2012-04-19 09:46 AM
Re: KIX462 issue

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


AllenAdministrator
(KiX Supporter)
2012-04-19 02:39 PM
Re: KIX462 issue

Let us see your drive mapping code.

Mart
(KiX Supporter)
2012-04-19 02:48 PM
Re: KIX462 issue

Allen,

See:
 Originally Posted By: sparkie

...
U: is connected using the users profile in AD
...


AllenAdministrator
(KiX Supporter)
2012-04-19 02:51 PM
Re: KIX462 issue

Yes... but something is happening during the script to cause it to remove U... so without seeing the script... only guesses. \:\(

AllenAdministrator
(KiX Supporter)
2012-04-19 02:56 PM
Re: KIX462 issue

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"


sparkie
(Getting the hang of it)
2012-04-19 04:46 PM
Re: KIX462 issue

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



sparkie
(Getting the hang of it)
2012-04-19 04:59 PM
Re: KIX462 issue

Ok, I've found the problem

4.62 does not like this command.

 Code:
USE * /DELETE


Mart
(KiX Supporter)
2012-04-19 05:04 PM
Re: KIX462 issue

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)


Glenn BarnasAdministrator
(KiX Supporter)
2012-04-19 05:09 PM
Re: KIX462 issue

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


LonkeroAdministrator
(KiX Master Guru)
2012-04-19 05:16 PM
Re: KIX462 issue

which would indicate that 4.62 is slower \:\(

anyways, Glenn, I think you are correct on that one.


Mart
(KiX Supporter)
2012-04-19 05:17 PM
Re: KIX462 issue

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.


sparkie
(Getting the hang of it)
2012-04-19 05:25 PM
Re: KIX462 issue

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 \:\)


AllenAdministrator
(KiX Supporter)
2012-04-19 05:36 PM
Re: KIX462 issue

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.

Mart
(KiX Supporter)
2012-04-19 05:40 PM
Re: KIX462 issue

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.


KIXKicks
(Starting to like KiXtart)
2012-04-19 06:25 PM
Re: KIX462 issue

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.

Glenn BarnasAdministrator
(KiX Supporter)
2012-04-19 07:49 PM
Re: KIX462 issue

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


ShaneEP
(MM club member)
2012-04-19 07:52 PM
Re: KIX462 issue

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.


LonkeroAdministrator
(KiX Master Guru)
2012-04-19 08:39 PM
Re: KIX462 issue

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.

sparkie
(Getting the hang of it)
2012-04-20 09:11 AM
Re: KIX462 issue

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.


BradV
(Seasoned Scripter)
2012-04-20 12:11 PM
Re: KIX462 issue

"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.

Glenn BarnasAdministrator
(KiX Supporter)
2012-04-20 01:01 PM
Re: KIX462 issue

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
This works, but is pretty basic. The messages should be used only during debugging as it's pretty chatty otherwise.

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