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.
