I'm not sure if I'm explaining this properly because your both off the mark slightly. Jooel you are sort of correct in your statement. The current directory inside my GPO is located in the sysvol which then becomes my working directory, but it's not my netlogon share. I think you meant working directory instead of netlogon there.

There is one of two things happening here. Either kix32.exe is executing from the netlogon share (instead of inside the GPO) which then makes my working directory the netlogon share. Thus why the login.kix script runs from there.
Or kix32.exe is executing from inside the GPO, but the script is executing from the netlogon share. I can't explain why it's doing this, I just know it is doing one of those two things.

And Les that is not the case, the current directory for the GPO is on the sysvol not in the netlogon. GPO's as well as any scripts inside a GPO are all stored in the sysvol. There is no legacy script being called. I'm using test accounts for all my testing. They don't run any login scripts at all unless I specifically move the user account into the OU that houses the GPO i'm using to test.

Simply put, if I set a GPO to run a kix script from within a batch file, it should in no way be looking to execute anything from the netlogon share unless I specifically state that in my script. That's why I'm also still leaving the possibility open that this is a strange kix/batch issue when used with group policy objects.

I'm going to do a little more testing to see if this is isolated to kix or if it affects all batch scripts in a GPO.