Page 1 of 1 1
Topic Options
#214072 - 2022-04-13 08:43 PM Troubleshooting issues in logon script
User10101 Offline
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
#214073 - 2022-04-13 10:51 PM Re: Troubleshooting issues in logon script [Re: User10101]
Allen Administrator Online   shocked
KiX Supporter
*****

Registered: 2003-04-19
Posts: 4545
Loc: USA
Is this script defined in a GPO or as part of the user via the Logon Script?
Top
#214074 - 2022-04-13 11:20 PM Re: Troubleshooting issues in logon script [Re: Allen]
ShaneEP Moderator Offline
MM club member
*****

Registered: 2002-11-29
Posts: 2125
Loc: Tulsa, OK
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?
Top
#214079 - 2022-04-14 10:06 AM Re: Troubleshooting issues in logon script [Re: ShaneEP]
User10101 Offline
Just in Town

Registered: 2022-04-13
Posts: 4
Loc: UK
 Originally Posted By: Allen
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:

 Originally Posted By: Batch File
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





 Originally Posted By: ShaneEP
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:

 Originally Posted By: Kixtart.kix

;************************************************************************************
;* 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.

 Originally Posted By: Kixtart.kix

$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 Administrator Offline
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! \:D

Top
#214081 - 2022-04-14 05:09 PM Re: Troubleshooting issues in logon script [Re: Glenn Barnas]
ShaneEP Moderator Offline
MM club member
*****

Registered: 2002-11-29
Posts: 2125
Loc: Tulsa, OK
Like Glenn mentioned...That OS check is going to exit for everything other than XP or Win 7. I tested it on my win 10 system, and it would indeed exit for me. This could be the issue. Just remove or comment that section and see if it fixes it.
Top
#214082 - 2022-04-14 08:21 PM Re: Troubleshooting issues in logon script [Re: Glenn Barnas]
User10101 Offline
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.


 Originally Posted By: Glenn Barnas
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
#214084 - 2022-04-14 08:45 PM Re: Troubleshooting issues in logon script [Re: User10101]
Glenn Barnas Administrator Offline
KiX Supporter
*****

Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
The batch file for indirect VPN logon can be as simple as:
 Code:
@\\<DOMAIN>\NetLogon\Kix32.exe \\<DOMAIN>\Netlogon\login_Script.kix
This would run far more quickly and again, target the DC - usually the "closest" server to the endpoint. Rarely any legit need to copy the files to the local computer. Also - when copied locally, the logic can be exposed if the laptop is stolen or compromised.

You can look at the User Manual for our commercial Kix-based login script here: https://dist.mspbuilder.com/downloads/Universal_Login_Script_User_Guide.pdf

Note that if you're running an older version of Kix32.exe, the @PRODUCTTYPE macro may not properly reflect the newer O/S versions, resulting in mixed results. It's the one macro we basically never use, instead pulling data directly from the local machine's registry.
_________________________
Actually I am a Rocket Scientist! \:D

Top
#214086 - 2022-04-14 11:04 PM Re: Troubleshooting issues in logon script [Re: Glenn Barnas]
User10101 Offline
Just in Town

Registered: 2022-04-13
Posts: 4
Loc: UK
 Originally Posted By: Glenn Barnas

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
Page 1 of 1 1


Moderator:  Jochen, Allen, Radimus, Glenn Barnas, ShaneEP, Ruud van Velsen, Arend_, Mart 
Hop to:
Shout Box

Who's Online
1 registered (Allen) and 466 anonymous users online.
Newest Members
gespanntleuchten, DaveatAdvanced, Paulo_Alves, UsTaaa, xxJJxx
17864 Registered Users

Generated in 0.056 seconds in which 0.022 seconds were spent on a total of 13 queries. Zlib compression enabled.

Search the board with:
superb Board Search
or try with google:
Google
Web kixtart.org