Page 1 of 2 12>
Topic Options
#200178 - 2010-10-06 06:24 PM Windows 7 x64 - Kix Install Problem
aacajo Offline
Fresh Scripter

Registered: 2009-02-13
Posts: 34
Loc: Canada
I'm sure this has been posted before but I cannot find any relevant thread to our problem.

On our Windows 7 x64 systems we're getting the error "kix32 is not a valid application" when running our logon script. Is there any special install steps for Win7 x64 systems?

Top
#200179 - 2010-10-06 06:31 PM Re: Windows 7 x64 - Kix Install Problem [Re: aacajo]
Allen Administrator Online   shocked
KiX Supporter
*****

Registered: 2003-04-19
Posts: 4545
Loc: USA
What is your @kix/version?

I've been running 4.53 and 4.61 under x64 with no issues.

Top
#200180 - 2010-10-06 06:41 PM Re: Windows 7 x64 - Kix Install Problem [Re: Allen]
aacajo Offline
Fresh Scripter

Registered: 2009-02-13
Posts: 34
Loc: Canada
We're using 4.6. I've placed KIX32.exe in SysWOW64 directory and our logon script automatically copies it to C:\Windows\System32 for our Windows XP users. Is there some sort of conflict there?

Edited by aacajo (2010-10-06 06:41 PM)

Top
#200181 - 2010-10-06 06:43 PM Re: Windows 7 x64 - Kix Install Problem [Re: aacajo]
Allen Administrator Online   shocked
KiX Supporter
*****

Registered: 2003-04-19
Posts: 4545
Loc: USA
Just curious why you are doing that? Logon scripts run from the Netlogon folder, without the need to copy/"install" the kix executable to the workstation.
Top
#200182 - 2010-10-06 06:48 PM Re: Windows 7 x64 - Kix Install Problem [Re: Allen]
aacajo Offline
Fresh Scripter

Registered: 2009-02-13
Posts: 34
Loc: Canada
Interesting...I wasn't aware of that. Here's the batch file from our DC:

IF NOT EXIST "C:\Windows\System32\kix32.exe" XCOPY %0\..\KIX32.EXE %WINDIR%\System32 /D /H /I /R /V >NUL
IF NOT EXIST "C:\Windows\System32\kixtart.dll" XCOPY %0\..\kixtart.dll %WINDIR%\System32 /D /H /I /R /V >NUL
KIX32.EXE %0\..\logon.kix

Should I just put %LOGONSERVER%\NETLOGON\company\KIX32.EXE %0\..\logon.kix ? I'll try it and see what happens.

Top
#200183 - 2010-10-06 06:56 PM Re: Windows 7 x64 - Kix Install Problem [Re: aacajo]
aacajo Offline
Fresh Scripter

Registered: 2009-02-13
Posts: 34
Loc: Canada
Ah didn't work. If i remove kix32 from System32 and Syswow64 it gives me the same error. How do I specifically call it to run from the DC?

Edited by aacajo (2010-10-06 06:58 PM)

Top
#200184 - 2010-10-06 07:06 PM Re: Windows 7 x64 - Kix Install Problem [Re: aacajo]
Allen Administrator Online   shocked
KiX Supporter
*****

Registered: 2003-04-19
Posts: 4545
Loc: USA
I'm assuming you set the properties of each user to run something like logon.bat, and have kix32.exe in the netlogon folder.

If so it should be nothing more than putting this in the logon.bat
kix32.exe scriptname.kix

If you are running 4.6, I highly suggest replacing it with 4.61. There were a number of odd issues in 4.6.

Top
#200185 - 2010-10-06 07:08 PM Re: Windows 7 x64 - Kix Install Problem [Re: Allen]
aacajo Offline
Fresh Scripter

Registered: 2009-02-13
Posts: 34
Loc: Canada
Same result on 4.61

Kix32 is not recognized as an internal or external command.

Though the script works when I copy KIX32.exe to syswow64. Strange.


Edited by aacajo (2010-10-06 07:12 PM)

Top
#200186 - 2010-10-06 07:24 PM Re: Windows 7 x64 - Kix Install Problem [Re: aacajo]
Allen Administrator Online   shocked
KiX Supporter
*****

Registered: 2003-04-19
Posts: 4545
Loc: USA
The only time I have seen the "is not valid" is times when I have downloaded a file that was not complete, and I tried to run it. Maybe you have a bad kix32.exe file? AV?

"Kix32 is not recognized" sounds like it can't find it in the path. Make sure it is in the Netlogon folder.

I'm headed out, maybe someone else will have some suggestions.

Top
#200187 - 2010-10-06 09:46 PM Re: Windows 7 x64 - Kix Install Problem [Re: aacajo]
Glenn Barnas Administrator Offline
KiX Supporter
*****

Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
Using a batch file is "old school" and generally not needed unless you still support Win9x systems. In environments without WinTendo platforms, the login batch file simply complicates the process without any benefit.

I'd update YOUR user profile to test the new configuration, and change the login script to simply "Kix32.exe login.kix". If you have these files in a subfolder of the netlogon share (not recommended) then change the login script definition in your profile to "subfolder\kix32.exe subfolder\login.kix". Note that there is NO leading "\".

Before testing, open a command prompt and type "DIR \\<mydomain>\NETLOGON" - you should see the kix files. Again, if you use a subfolder, use "DIR \\<mydomain>\NETLOGON\<subfolder>" instead. If the Kix32.exe file isn't there, you've copied it to the wrong path.

Once you've confirmed that the files exist in the correct location in the Netlogon share, log off and back on to verify that it works. If so, you can update the remaining user accounts to reference the files directly.

Also - copying the DLL file is unnecessary. It is present only to support Win9x computers in a Windows Domain environment. It provides no benefit on 32-bit or 64-bit platforms.

Glenn
_________________________
Actually I am a Rocket Scientist! \:D

Top
#200188 - 2010-10-06 10:25 PM Re: Windows 7 x64 - Kix Install Problem [Re: Glenn Barnas]
cjutting Offline
Fresh Scripter

Registered: 2010-02-05
Posts: 40
Loc: IA
Not to derail this, but what your suggesting is to not use a batch file to launch kix?

right now i have just a simple batch file that looks like this:
Welcome to Domain

\\domain\netlogon\kix32 \\domain\netlogon\mylogon.kix

EDIT:

Guess I should add that the previous admin before me had used a batch file as the logon script so I un did his work and use the batch file to call kix since everyone in AD already has the name of the batch file in their AD Account info


Edited by cjutting (2010-10-06 10:26 PM)

Top
#200189 - 2010-10-06 10:41 PM Re: Windows 7 x64 - Kix Install Problem [Re: cjutting]
aacajo Offline
Fresh Scripter

Registered: 2009-02-13
Posts: 34
Loc: Canada
Thanks Glenn bypassing the batch simplifies things much more.

Is there a reason why subfolders are no recommended? We have subfolders because our international division and US divisions are still using legacy logon scripts.


Edited by aacajo (2010-10-06 10:49 PM)

Top
#200190 - 2010-10-07 01:31 AM Re: Windows 7 x64 - Kix Install Problem [Re: aacajo]
Glenn Barnas Administrator Offline
KiX Supporter
*****

Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
Using a batch file is appropriate IF it has merit.. supporting Win9x systems in certain older AD environments needed the batch file. Current systems do not receive any benefit from doing so, and the batch file simply adds one more level of complexity to the environment. Things are hard enough to troubleshoot - why add more layers without adding value?

Changing the users login script setting is quite easy, either through the GUI or programatically. From the GUI, simply select ALL of the users (or all the users that you want to change), right-click and select properties. Change the login script property and click OK. Kix can be used to script the change, enumerating the users, selecting them based on criteria, and updating the setting.

As for using folder structure in NetLogon, the same logic applies. Don't do it just to put your login scripts in a folder - that's what NetLogon is for. Not my words, but those of a MS engineer that came on-site to do an AD audit (RAP) at a large client. We had used a subfolder to hold the login script during a migration from one AD structure to another, and had not removed it when the audit started. Of course, if there's a reason (different divisions using different scripts) then that's OK. I've seen clients that put their single login script into a subfolder and have the Netlogon root empty - that's not recommended by MS and doesn't make much sense to me.

Our login script actually handles the different division processing quite well, either using a division-specific name for the script or using the standard name in a folder.

The general point is - KISS makes sense. Appropriate complexity for security or management, but not beyond or without value.

Glenn
_________________________
Actually I am a Rocket Scientist! \:D

Top
#200191 - 2010-10-07 02:07 AM Re: Windows 7 x64 - Kix Install Problem [Re: cjutting]
Glenn Barnas Administrator Offline
KiX Supporter
*****

Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
No derailment - just taking a siding. \:\)

Replacing the login.bat content with a call to Kix is a step in the right direction, and a step that required little effort to implement (the .KIX login script not withstanding). This allowed you to easily migrate an entire environment to a new script in one step.

The next step would be to change a few users to reference the script directly, eliminating the batch file. A few minutes to hour of effort to eliminate the bat file from the remaining users reduces unnecessary complexity. The benefit will be when you need to troubleshoot a problem. Fewer layers means easier troubleshooting.

FYI - the reason that the leading "\" isn't needed and that simply specifying "kix32.exe kixtart.kix" in the user login profile works is that the netlogon share (\\domain\netlogon) is inserted at the beginning of the PATH variable during logon, so that is the FIRST place that the OS looks for commands. (this is one of the reasons that subfolders are discouraged - they won't be searched!)

Thus, if all files relative to the login process are directly in the Netlogon share, the commands can be called without any explicit path parameters and will execute as expected.

Glenn
_________________________
Actually I am a Rocket Scientist! \:D

Top
#200193 - 2010-10-07 02:20 AM Re: Windows 7 x64 - Kix Install Problem [Re: Glenn Barnas]
Allen Administrator Online   shocked
KiX Supporter
*****

Registered: 2003-04-19
Posts: 4545
Loc: USA
As everyone has one... I throw my opinion in to the mix too. I like having a the bat file. In fact, I'm almost surprised Glenn is not doing it too, knowing how he's spoken in the past about creating bats for all your scripts. I like it because if I am testing, making changes, or for some reason just need to rerun the script, all I need to do is go to the folder and double click. Otherwise you are typing, or dragging and dropping to the run console, or logging off and back in.

And where is Shawn when I need a ? at the beginning of the line. Old school works for me. \:\) I think of all things we gripe about around here, this is the least important.

Top
#200194 - 2010-10-07 02:32 AM Re: Windows 7 x64 - Kix Install Problem [Re: Allen]
cjutting Offline
Fresh Scripter

Registered: 2010-02-05
Posts: 40
Loc: IA
I'm in the same boat as Allen. Double clicking shorter than click and drop

Edited by cjutting (2010-10-07 02:48 AM)

Top
#200195 - 2010-10-07 04:33 AM Re: Windows 7 x64 - Kix Install Problem [Re: cjutting]
Glenn Barnas Administrator Offline
KiX Supporter
*****

Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
Drag & drop? LOL!

I don't think I've ever used drag-n-drop to run a script, except once when Doc mentioned a problem and I tried it as part of the diagnosis. If I have a GUI script, the script is in my start menu. Non-GUI scripts (Kix, Bat, or otherwise) are run (exclusively) from the command line, never by double-clicking. Invoking a command line script from the GUI results in one of two crucial compromises - either you don't see the result/error message when the window closes, or you need to add a "press a key" mechanism. Unless you somehow build a timeout into the "press a key" process, that makes the script effectively useless for any form of unattended operation.

I never configure end-user systems this way to maintain security, but management and development systems have the following settings defined to allow direct execution of Kix scripts:

 Quote:
Kix32.exe is installed in a specific location in C:\Program Files, along with WKix32.exe. These are the latest versions (4.61). I also have these named Kix32_4.61.exe, and a copy of 4.53 named Kix32_4.53.exe (and the corresponding WKix32 files) in the same folder. 4.53 and 4.61 are the two most stable versions, but are incompatible when scripts are tokenized. Having these named this way allows me to invoke specific versions either for testing or backward compatability. This folder is added to the beginning of the system PATH variable.

I define the following extension associations:
.KIX Kix32.exe "%1" %* Kix Scripts (source or tokenized)
.KX Kix32.exe "%1" %* Kix Scripts (tokenized)
.KXW WKix32.exe "%1" %* Kix GUI Scripts (source or tokenized)
.K53 Kix32_4.53.exe "%1" %* Kix 4.53
.K61 Kix32_4.61.exe "%1" %* Kix 4.61
.K53w and .Kw61 are similarly associated with the WKix versions

All of these extensions are added to the PATHEXT variable.


I also define .UDF and .KXF associations to my editor, allowing direct access to UDF files. The content is the same, but we use .UDF to identify externally developed UDFs and .KXF to identify those developed internally.

Since the implementation of GetCommandLine, I never use BAT files to launch kix scripts anymore. The exception is KGEN.BAT, which is a hybrid script - the first 3 lines and the last line are BAT code that invokes Kix to run the actual kix script that is in lines 4 through 2122 - thus, one file that handles both the DOS prep and the Kix script commands. ;\)

Anyway, what all of this does for me is provide the ability to place my Kix scripts in the same folder as Kix32 executables. That folder is first in the PATH, writable only by admins. Thus, when I run a script - say LogCleanup.kix, I simply open a command prompt (actually, define a scheduled task) and run "LogCleanup --S:EventLog" to invoke the daily event log cleanup. It recognizes the .KIX extension as a command, and knows it's associated to Kix32.exe and launches it, passing the arguments. Likewise, the shortcut to tsAdm.kxw - the Task Scheduler Admin Tool - is simply "tsadm.kxw". I can invoke it from the command line simply as "tsadm".

No "kix32" or path statements, no .KIX extensions.. nice and clean. Very few of my scripts run outside of an administrative context.. no scripts are run by end users other than the login script, which is invoked explicitly - Kix32.exe kixtart.kix - so it runs anywhere. (remember, Netlogon is in the path during logon.) In the environments that I support, users are not local admins, so most of my kix scripts would be pointless for them.

I do have a couple of end user scripts, mostly to automate data collection or perform special reporting. In these rare situations, I do use a Bat file to invoke "@%S_BIN%\Kix32 "@%S_BIN%\script.kix", but it's the rare exception.

As an aside, the Customize package that can be downloaded from my web site performs all of these file associations, path updates, and related modifications, along with installing Kix executable, the KixForms DLL, and any additional tools you wish to deploy.

Glenn
_________________________
Actually I am a Rocket Scientist! \:D

Top
#200196 - 2010-10-07 05:22 AM Re: Windows 7 x64 - Kix Install Problem [Re: Glenn Barnas]
Allen Administrator Online   shocked
KiX Supporter
*****

Registered: 2003-04-19
Posts: 4545
Loc: USA
I don't think you interpreted my drag and drop for what I meant... Drag the kix32.exe to the Run console... space... drag the script to the Run console. It's just like typing it... Includes the paths and what not, usually works pretty well, aside from having to add the quotes, Still takes too long compared to the batch.
Top
#200197 - 2010-10-07 03:38 PM Re: Windows 7 x64 - Kix Install Problem [Re: Allen]
cjutting Offline
Fresh Scripter

Registered: 2010-02-05
Posts: 40
Loc: IA
It would appear that I did.. I tried to edit my post last night, but by the time I thought about what I had and decided I shouldn't have said it.. it was already too late.

Guess my biggest thing is that it works for me. And if it works for me that's all that really matters

Top
#200198 - 2010-10-07 04:13 PM Re: Windows 7 x64 - Kix Install Problem [Re: Allen]
Glenn Barnas Administrator Offline
KiX Supporter
*****

Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
Now to me, that seems like a lot of work compared to typing "scriptname" in a command prompt window. \:\)

I guess it is based on our development process, too.

We have a dev share on the network that is mapped to all users that do development. There is a KixLib folder in the root of that share that holds every one of our UDFs. Development of Kix scripts is done in a folder somewhere in that share. Large scripts are often broken into smaller pieces, with the header and var inits in SCRIPTNAME.TXT, and other components in .KXF files. When we're ready to build the script, we just run KGEN in that folder. It loads the SCRIPTNAME.TXT and all .KXF and .UDF files from that folder and then scan for external UDFs. Based on settings in the BUILD.INI file, KGen will tokenize the script and even copy it to one or more locations, run Sanity, and perform other tasks.

We can usually test the code right there in the dev folder. If it relies on other config files, we might have two command prompts open, one to the dev folder and one in the app folder. Up-Arrow and Enter to repeat the command for testing and we're done.

Then too, most of our Kix scripts are admin tools that run as system services or under the control of the task scheduler. A few are invoked manually, but its a small percentage compared to the other tools.

I'm not saying that one way is right or wrong, but if you never tried anything other than Drag-n-Drop or Double-Click methods, you might not ever realize some of the shortcomings of those methods, or be aware that Kix can run as a system service.

One case in point.. our LogCleanup script can run interactively, from the task scheduler, or as a system service. There's no difference between running it manually or from a scheduled event - both require an argument to define which cleanup task to perform. As a service, however, it is self contained. The cleanup config file not only defines the source and destination paths and other parameters, but defines the cycle in which to execute. The service mode "wakes up" every 60 seconds, checks if a task should be run, and dispatches a child process to perform the cleanup. All of this is in a single .KIX file. The point is, using methods other than the command prompt to launch scripts might mask some of the capabilities by limiting your imagination.

I am aware of several ways to launch Kix, and they are all in my arsenal for appropriate use. One of my favorite Kix scripts is KGen.bat. Yes, .BAT. Kix32 needed to be able to locate the script, assuming only that Kix32 would be in the PATH or current folder. Over 2100 lines of this BAT file are Kix code, with 4 lines of Batch commands:
 Code:
;@echo off
;kix32.exe "%~f0" %*
;Goto END
All the Kix code follows, except that the last line is ":END", which is valid for both DOS and KIX. The batch file can be placed anywhere as long as Kix32 is in the PATH. It could be a fixed location as well, but that creates consistency issues. The %~f0 represents the full path to the KGen.bat file, telling Kix32 exactly where the script is that should be run. All of the arguments are passed directly to the script.

Glenn
_________________________
Actually I am a Rocket Scientist! \:D

Top
Page 1 of 2 12>


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

Who's Online
2 registered (morganw, mole) and 414 anonymous users online.
Newest Members
gespanntleuchten, DaveatAdvanced, Paulo_Alves, UsTaaa, xxJJxx
17864 Registered Users

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

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