#214072 - 2022-04-13 08:43 PM
Troubleshooting issues in logon script
|
User10101
Just in Town
Registered: 2022-04-13
Posts: 4
Loc: UK
|
Hi,
We currently have a very old legacy kid setup that we've inherited from previous admins. Hasn't been substantially altered for quite some time.
We're currently running Windows 10 and the script works fine, maps everyone's drives absolutely fine. Does what it needs to.
However we have a Server 2016 setup for users that doesn't map drives on logon.
Opening CMD and running the same command in the logon script also doesn't work.
We do seem to have a batch file that functionally does the exact same commands that does work.
Any help working out what's going on would be useful.
|
|
Top
|
|
|
|
|
#214079 - 2022-04-14 10:06 AM
Re: Troubleshooting issues in logon script
[Re: ShaneEP]
|
User10101
Just in Town
Registered: 2022-04-13
Posts: 4
Loc: UK
|
Is this script defined in a GPO or as part of the user via the Logon Script?
Login script on AD records. Mapped via kix32 kixtart.kix /f
If we run the script from the file server via Batch file it does this:
C:
cd c:\temp
net use g: "[network drive\location\remote\]"
xcopy g:\kix32.exe c:\temp /Y
xcopy g:\kixtart.dll c:\temp /Y
xcopy g:\kixtart.kix c:\temp /Y
xcopy g:\mapdrives.kix c:\temp /Y
net use g: /delete
kix32.exe mapdrives.kix /f
timeout 5
There may also be a system check in the script that skips drive mappings if a server is detected. Would you mind copying an anonymized version of the script if it's not too large?
Its quite a large script in a couple of parts. Lot of company info in there so not easy to anonymize. Broken into Kixtart.kix which then calls mapdrives.kix
Looking at it based on these replies though I am wondering if it may be due to the script having two parts to it Kixtart.kix and mapdrives.kix - the batch drive explicitly calls mapdrives.kix.
The only part in kixtart.kix that references OS is this one which on looking is functionally useless:
;************************************************************************************
;* If the Operating System is not the current standard desktop, "Windows XP" *
;* do not run any login script commands. *
;************************************************************************************
if (INSTR(@ProductType, "Windows XP") = 0) AND (INSTR(@ProductType, "Windows 7")= 0)
Exit
ENDIF
There is also a reference to what image the devices are using that references W7 and XP - these are long deprecated and we don't use these.
$HKLMImageNo = ReadValue("HKEY_LOCAL_MACHINE\Software\[company]","ImageVersionNo")
IF (@ERROR = 0)
$HKLMImageNo = Left($HKLMImageNo,1)
ELSE
$HKLMImageNo = "0" ; PC is not a standard image or registry has been corrupt.
ENDIF
;************************************************************************************
;* Run common logon scripts for all machines, then run specific scripts for images *
;************************************************************************************
Call MapDrives.kix ; Maps drives for this user
But again, this is currently working fine for our users on desktop clients.
The Mapdrives file itself just maps drives based on AD membership and it is absolutely huge.
My initial thoughts were based on server OS and OU related issues - perhaps the way it process login scripts or SMB in server 2016.
|
|
Top
|
|
|
|
|
#214080 - 2022-04-14 02:25 PM
Re: Troubleshooting issues in logon script
[Re: User10101]
|
Glenn Barnas
KiX Supporter
Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
|
I've never seen an environment where the login script is copied from a file share to a local system. That's pretty fragile in itself. Login scripts are designed to be robust because they are delivered directly from a specific share on the DC - the specific DC that authenticated the user - so there's never a situation where it can't run. (well, it CAN fail if there are NO domain controllers available, but you won't be authenticated, either.) The DLL file generally isn't required, especially if it isn't being registered.
Size doesn't matter - we have Kix (not logon, though) well over 10-15,000 lines.
The O/S detect logic seems OK, actually, although LOOKS strange. It's looking for the current O/S to NOT be XP or W7. If the O/S was either of those, the match would not be zero, and the Exit would not execute. If you're running anything later than Windows 7 (8.x, 10, 11), the script will terminate right there. I would comment out that section.
The versioning logic only defines the $HKLMImageNo variable. You can search the remaining script to determine if/how that variable is used. Setting it to non-zero may work if this value is no longer being defined in the registry. Since MapDrives.kix is loaded via CALL, you must review that script as well for this variable use.
From a developer's perspective, this adds a significant amount of environmental complexity to what should be a relatively simple process.
I own a software dev company and Kix is a specialty. Would be happy to provide private assistance to troubleshoot if you don't want to post publicly. We sign NDA's with clients all the time to preserve confidential information. PM me if interested in this.
We actually have a "no-code" Kix-based login script that has a ton of features and runs quickly. We were able to reduce login script times from 1.5 minutes to 6-seconds for one large client with over 50 resource mapping references, with over 450 department-specific mappings. You can even map resources by AD attribute, like "Manager=Tom".
_________________________
Actually I am a Rocket Scientist! 
|
|
Top
|
|
|
|
|
#214082 - 2022-04-14 08:21 PM
Re: Troubleshooting issues in logon script
[Re: Glenn Barnas]
|
User10101
Just in Town
Registered: 2022-04-13
Posts: 4
Loc: UK
|
Yeah I did some work on it today and it does look like its the kixtart.kix, OS version that causing the issues.
If I run mapdrives.kix it works, if I run kixtart.kix then drives don't map.
I can comment that out and run from the C drives and drives map.
Like I say whats made this very odd is that we have somewhere around 800-900 machines that all call that Kix script on netlogon running W10 and they are all fine. Its just a couple of users RDS onto a Server 2016 box and the drives don't map.
I've never seen an environment where the login script is copied from a file share to a local system. That's pretty fragile in itself. Login scripts are designed to be robust because they are delivered directly from a specific share on the DC - the specific DC that authenticated the user - so there's never a situation where it can't run. (well, it CAN fail if there are NO domain controllers available, but you won't be authenticated, either.) The DLL file generally isn't required, especially if it isn't being registered.
Its not, Kixtart.kix calls mapdrives.kix which live on netlogon on the DC's. We have a batch file on a file share that calls mapdrives as we have VPN users who don't logon gracefully and this is a work around for not hitting logon properly when working remotely.
Our Kix has basically not been touched for a very long time so I'll keep your post in mind as we're looking at ways to get up to date with drive mapping.
|
|
Top
|
|
|
|
|
#214086 - 2022-04-14 11:04 PM
Re: Troubleshooting issues in logon script
[Re: Glenn Barnas]
|
User10101
Just in Town
Registered: 2022-04-13
Posts: 4
Loc: UK
|
We actually have a "no-code" Kix-based login script that has a ton of features and runs quickly. We were able to reduce login script times from 1.5 minutes to 6-seconds for one large client with over 50 resource mapping references, with over 450 department-specific mappings. You can even map resources by AD attribute, like "Manager=Tom".
How are the newer versions at calling O365/Azure AD mappings? We've some online fileshares
|
|
Top
|
|
|
|
Moderator: Jochen, Allen, Radimus, Glenn Barnas, ShaneEP, Ruud van Velsen, Arend_, Mart
|
1 registered
(mole)
and 405 anonymous users online.
|
|
|
