#211721 - 2016-06-30 08:35 AM
Wkix problem.....maybe
|
DKBofh
Fresh Scripter
Registered: 2016-06-29
Posts: 9
Loc: Denmark
|
Yesterday i updated (at last) kix from 2010.453 to 2010.466
Kix and wkix is placed in the Netlogon folder on all servers - script is not changed.
All user profiles are set to run "wkix32.exe scriptname.kix"
After updating I tested by running script manually from 2 servers and everything was working fine.
Today - no one seems to get any drives or anything - returns error when trying to run wkix32.
I just put in the old version to get 90 users and the boss off my back. Now i am wondering ?????
What am i missing here ?????
Edited by DKBofh (2016-06-30 08:59 AM)
_________________________
/Erik
----------------------------------
I'm always up for extra vacation.
|
|
Top
|
|
|
|
#211723 - 2016-06-30 09:35 AM
Re: Wkix problem.....maybe
[Re: Mart]
|
DKBofh
Fresh Scripter
Registered: 2016-06-29
Posts: 9
Loc: Denmark
|
It was....... something with "could not recognize wkix32 .....
The old versin was renamed to wkix32.exe.old - new file/version wkix32.exe
So the fix was just renaming - back again and then it worked.
Odd thing is - severel users logged on yesterday after normal working hours - no problem !
But at the break of dayligt something has happend..... I know that netlogon shares are sync'ed but to avoid problems i always sync manually just after changes or updates - got a batchjob for this.
I'm just wondering if something has changed about kix /wkix - same installation method ??
I'm suspecting antivirus or backup right now.... :-(
_________________________
/Erik
----------------------------------
I'm always up for extra vacation.
|
|
Top
|
|
|
|
|
#211727 - 2016-06-30 11:23 AM
Re: Wkix problem.....maybe
[Re: Arend_]
|
DKBofh
Fresh Scripter
Registered: 2016-06-29
Posts: 9
Loc: Denmark
|
hmmm... makes sense
I will try tonight and again tomorrow morning...... right now the error will not reproduce which puts me in the antivirus direction again.
Error was (as i recall it) - could not recognize wkix32.exe as an internal or external command.
But - i was so busy getting all users online i forgot to make a screendumb :-(
_________________________
/Erik
----------------------------------
I'm always up for extra vacation.
|
|
Top
|
|
|
|
|
#211728 - 2016-06-30 01:04 PM
Re: Wkix problem.....maybe
[Re: DKBofh]
|
Glenn Barnas
KiX Supporter
Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
|
Welcome to KORG!
As the owner of the login script, my profile is usually different from all other users - where other users have "kix32.exe kixtart.kix", mine is "kix32a.exe kixtart.kix". When I update Kix, I copy it to "kix32a.exe" so I get the new version first and verify that it works. After validating the operation, I copy Kix32a.exe to kix32.exe so both versions are the same file, not just the same version. This should let you check independent of the users.
Also - related - it's always better to put the "old" designation in the middle of the file name, not change the extension. This way, you can find the original version by its name OR extension, and having the OLD between the name and extension is pretty obvious - "Kix32.OLD.exe", for example. I also maintain a copy of every version of Kix available in my tools directory - in my PATH - so I can run any version at will - these are named "Kix32-4.xx.exe", where the "xx" represents the minor version.
Other things to check:- Is your login script tokenized? Re-gen it if so.
- Delete all copies* of Kix32.exe from all DCs, then place the Kix file on one DC's netlogon folder. Verify that it replicates to ALL of the other DCs. *Make sure you have a local copy of your original Kix 4.53 executable.
- Add "Shell %COMSPEC% /c Set > %TEMP%\Env.txt" to the login script - check the file. Does the environment look normal? Is the NetLogon folder FIRST in the PATH statement? If the PATH isn't set properly, it won't find the Kix32.exe file.
- Do you run AV on your DCs? Make sure the NetLogon physical path is excluded, or at least, exclude "Kix32*.exe" from AV on all systems.
- Try running the script after logon, via "\\YourDomain\Netlogon\Kix32.exe \\YourDomain\Netlogon\scriptname.kix" - does that work? If so, I'd be focused on the session state at logon time - path, env, etc all set correctly and all necessary files replicated in all netlogon share folders.
- Modify your account as I mentioned above to use the new Kix version - log on/off of a machine a couple of times, then try a few other machines to verify before updating the rest of the users.
- Give my logon script a try, even if you only invoke it to define a command that runs your logon script. When invoked with --D, it creates a TON of diagnostic information in the user's %USERPROFILE% folder. This has helped several organizations identify corrupt platforms and faulty replication in their environment. If you want to try this and have more than 4 DCs, PM me and I'll give you a 30-day trial license key. The script is free for environments with up to 4 DCs.
Good luck! Let us know what you find.
Glenn
_________________________
Actually I am a Rocket Scientist! 
|
|
Top
|
|
|
|
|
#211733 - 2016-06-30 03:59 PM
Re: Wkix problem.....maybe
[Re: Glenn Barnas]
|
DKBofh
Fresh Scripter
Registered: 2016-06-29
Posts: 9
Loc: Denmark
|
Well this is an odd thing
I started with the upgrade on server 1 - both kix32.exe and wkix32.exe
test - \\server1\netlogon\wkix32.exe scripname.kix - works like a charm.
Then i manually copied to all DC's - just to make sure.
Home office users (vpn logon) has a batch file that does exactly the same as above.
Works fine
But after upgrade it seem as it worked for - like 5 -6 hours (I was doing some tests on my personal script) - several users report it was working yesterday night but not this morning. 3 of them are always using the batch logon method.
Later - and again this morning users encountered the error - The only server I can be sure of is server1 - hence this is called manually from all home offices.
Just put the old version to work again - and voila. - i alsp keep the old versions :-)
Only thing that has changed in the enviroment was the kix32/wkix32 files. It might be a single incident - but for now i'm not upgrading until further investigation has been done.
_________________________
/Erik
----------------------------------
I'm always up for extra vacation.
|
|
Top
|
|
|
|
|
#211741 - 2016-07-01 10:26 AM
Re: Wkix problem.....maybe
[Re: Glenn Barnas]
|
DKBofh
Fresh Scripter
Registered: 2016-06-29
Posts: 9
Loc: Denmark
|
Hmmmm.
DC's on 5 sites in a lan2lan net.
Until now ...... userprofile - in the profile .... "wkix32.exe scriptname.kix" - no problems.
Could it be that simple - i have to change it to \\domain\netlogon\wkix32.exe scriptname.kix ?????
It does make sense......
replication method - point taken....
_________________________
/Erik
----------------------------------
I'm always up for extra vacation.
|
|
Top
|
|
|
|
|
#211742 - 2016-07-01 01:41 PM
Re: Wkix problem.....maybe
[Re: DKBofh]
|
Glenn Barnas
KiX Supporter
Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
|
No - not in the user profile, but in any manual invocation or your bat file for VPN users.. Your examples above illustrated a full path for Kix32 but NOT for the script, and also to a specific server. That could cause the (correct) script to not be found in specific situations. when invoking manually from \\DOMAIN\Netlogon, prefix both Kix32 and the script with the UNC path to avoid any ambiguity.
Having "Kix32.exe script.kix" in the user profile should be fine and is the correct configuration.
Did you add the shell command I recommended to check the local environment? Find anything odd? The PATH must have the netlogon folder listed FIRST during a logon session.
Your error isn't coming from Kix that the script is failing or not found, it's coming from the O/S reporting that the Kix32.exe wasn't found. This points to an AD or possible replication issue. If one server fails to fully replicate, the file may not "be" an exe even though it has that extension. In your testing, you've been specifying a single server, but logins are serviced by the first responding DC. You need to run your test against every DC. Also- be sure that your Sites are set up properly. We had a DC on the west coast that was both mis-configured and in the east coast site. It was responding to login requests at the HQ site and took a long time to process the login script - 40-seconds instead of the typical 2-3 seconds - when it worked at all. This will also show up in the environment dump that I recommended as %LOGONSERVER%.
I'd verify the Sites & Subnets first, then remove the EXE's from the PDCe and force a replication, middle of the day when logins aren't likely or over the weekend. Do the files disappear from the other DCs? Wait 30 minutes - do any still exist or reappear? For a properly configured WAN setup, replication could take up to 3 hours unless you then force the replication. (I'd still wait the 30 minutes before forcing.)
Verify the replication - run \\server\netlogon\kix32 /? and verify that they all report the same and desired version and do not report a failure of any kind.
Finally, if you aren't calling wkix32.exe for your scripts, don't put it in netlogon - its just one more file to replicate needlessly. Use one or the other - they are both the same except that wkix won't open a command window by default unless you generate output. It's designed for silent operation apps, such as Windows Services and KixForms GUI apps, or scripts that should not (and will not) display any text output.
Glenn
_________________________
Actually I am a Rocket Scientist!
|
|
Top
|
|
|
|
Moderator: Jochen, Allen, Radimus, Glenn Barnas, ShaneEP, Ruud van Velsen, Arend_, Mart
|
0 registered
and 128 anonymous users online.
|
|
|
