#200178 - 2010-10-06 06:24 PM
Windows 7 x64 - Kix Install Problem
|
aacajo
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
|
|
|
|
#200180 - 2010-10-06 06:41 PM
Re: Windows 7 x64 - Kix Install Problem
[Re: Allen]
|
aacajo
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
|
|
|
|
#200182 - 2010-10-06 06:48 PM
Re: Windows 7 x64 - Kix Install Problem
[Re: Allen]
|
aacajo
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
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
|
|
|
|
#200185 - 2010-10-06 07:08 PM
Re: Windows 7 x64 - Kix Install Problem
[Re: Allen]
|
aacajo
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
|
|
|
|
#200189 - 2010-10-06 10:41 PM
Re: Windows 7 x64 - Kix Install Problem
[Re: cjutting]
|
aacajo
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
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!
|
Top
|
|
|
|
#200193 - 2010-10-07 02:20 AM
Re: Windows 7 x64 - Kix Install Problem
[Re: Glenn Barnas]
|
Allen
KiX Supporter
Registered: 2003-04-19
Posts: 4548
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
|
|
|
|
#200195 - 2010-10-07 04:33 AM
Re: Windows 7 x64 - Kix Install Problem
[Re: cjutting]
|
Glenn Barnas
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:
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!
|
Top
|
|
|
|
#200198 - 2010-10-07 04:13 PM
Re: Windows 7 x64 - Kix Install Problem
[Re: Allen]
|
Glenn Barnas
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:;@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!
|
Top
|
|
|
|
Moderator: Jochen, Allen, Radimus, Glenn Barnas, ShaneEP, Ruud van Velsen, Arend_, Mart
|
0 registered
and 331 anonymous users online.
|
|
|