Page 1 of 1 1
Topic Options
#211716 - 16/06/29 11:59 AM Kix based on OS Ver
jszkudlapski Offline
Just in Town

Registered: 16/06/29
Posts: 4
Loc: UK
Hi
As we are rolling out Win10 x64 Enterprise, is there a way I can have Kixtart run scripts based on if its Win7x32 or Win10X64?

At present we have 4 main KixScripts (two for Win7 and two for Win10) so ideally id like something like;

Selection.kix which just contains;

If Win7x32 run Win7_Main.kix
If Win10x64 run Win10_Main.kix

Which will then do OS specific commands etc.

Thank you Wizards of the Kixtart world.

Top
#211717 - 16/06/29 12:24 PM Re: Kix based on OS Ver [Re: jszkudlapski]
Glenn Barnas Moderator Offline
KiX Supporter
*****

Registered: 03/01/28
Posts: 4211
Loc: New Jersey
The most basic way is with the @DOS macro, which is built-in and returns the OS version. There's also a simple way to determine the platform architecture. There are UDFs on my web site that might be helpful:

ARCH() - returns "x64" or "x86" depending on the architecture.
Is64Bit() - returns 1 if running on a 64-bit O/S, 0 if 32-bit.
(Both of the above are in the same UDF file.

HostIsServer() - returns 1 if the host is a server O/S, 0 otherwise.
HostIsWkstn() - returns 1 if the host is a workstation O/S, 0 otherwise.

OSVer() - returns the O/S Version from a local or remote computer via reg reads of Major/Minor version keys. (Could provide different results on W10 than @DOS, as some early versions of W10 reported 6.x while @DOS reports "10". After the latest updates on my W10 workstation, @DOS reports "10" while OSVer() reports "10.0".

Glenn
_________________________

Actually I am a Rocket Scientist! \:D

Top
#211718 - 16/06/29 12:28 PM Re: Kix based on OS Ver [Re: Glenn Barnas]
Glenn Barnas Moderator Offline
KiX Supporter
*****

Registered: 03/01/28
Posts: 4211
Loc: New Jersey
Oh - and Welcome to KORG!

Glenn
_________________________

Actually I am a Rocket Scientist! \:D

Top
#211719 - 16/06/29 12:34 PM Re: Kix based on OS Ver [Re: Glenn Barnas]
Glenn Barnas Moderator Offline
KiX Supporter
*****

Registered: 03/01/28
Posts: 4211
Loc: New Jersey
Now that I've had some coffee, I'm wondering why you need separate scripts for different platforms and architectures?

Consider installing a program with separate architectures - rename the installers as:
Application_x86.msi
Application_x64.msi

Use the Arch() UDF to determine the platform architecture:
$Arch = Arch() ; now contains either "x86" or "x64"

Copy the install file to a common name
Copy "Application_" + $Arch + ".msi" "C:\Temp\Application.msi"

Then simply run the "application.msi" installer. Same deal if you're using an EXE.

You could extend this concept if there were different versions for W7 and W10.

We support about 2500 endpoints and have over 100 app installers that work this way - each installer uses these UDFs to determine what source package to deploy.

Glenn
_________________________

Actually I am a Rocket Scientist! \:D

Top
#211729 - 16/06/30 01:05 PM Re: Kix based on OS Ver [Re: Glenn Barnas]
jszkudlapski Offline
Just in Town

Registered: 16/06/29
Posts: 4
Loc: UK
Hi
Thanks for the reply.

Essentially we have a historic kix script based on Windows7 which includes a load of reghacks and custom copy file commands.

With our Win10 we are trimming this down and moving them into GPO and using the power of Kix to correctly Map the drives and printers - as this is way quicker than GPO.

So I just need to have a command (I was thinking could I do it with a IF File exists?

So something like;

If file exists
c:\windows\_custom\startmenu.xml
then run "Win10_Main.kix"
else
run "Win7_Main.kix"

The problem we have at the minute is that if we let it just run it breaks some Win10 custom stuff on login (desktop shortcuts/desktop wallpaper) so as we phase Win7 out this wont be a problem but at the minute I need to support both at for at least a month.

Top
#211730 - 16/06/30 02:34 PM Re: Kix based on OS Ver [Re: jszkudlapski]
Glenn Barnas Moderator Offline
KiX Supporter
*****

Registered: 03/01/28
Posts: 4211
Loc: New Jersey
This can be handled very easily in Kix, especially with the UDFs I mentioned above.
 Code:
; at top of script to set the platform type & architecture
$MyVer = OSVer()
$MyArch = Arch()
$IsX64 = Is64Bit()
; body of script - init processes
;
; To run something platform and possibly Architecture specific
If InStr('6.1,6.2', $MyVer) ; Windows 7, 8
  If IsX64
    ; Do 64-bit stuff
  Else
    ; do 32-bit stuff
  EndIf
  ; Deploy platform/Arch-specific reg file based on name
  Shell '%COMSPEC% /c REG IMPORT settings_' + $MyArch + '.REG'
  ; This same process could invoke an arch-specific installer
EndIf
; Duplicate above for Windows 10 stuff, if needed.
Glenn
_________________________

Actually I am a Rocket Scientist! \:D

Top
#211732 - 16/06/30 03:25 PM Re: Kix based on OS Ver [Re: Glenn Barnas]
jszkudlapski Offline
Just in Town

Registered: 16/06/29
Posts: 4
Loc: UK
Thanks Glenn, do you think something like this would work;

 Quote:


; at top of script to set the platform type & architecture
$MyVer = OSVer()
; body of script - init processes
;
; To run something platform and possibly Architecture specific
If InStr('10.0', $MyVer) ; Windows 10
CALL "Win10_Main.kix"
Else
Call "Win7_Main.kix"
EndIf


Ive got the seperate Win7_Main & Win10 Main kix files running perfect as seperate files, just now need one to sit above it to basically go....

Oh your on Win10, hit the Win10_Main.kix file please, if your not, go hit the Win7_Main.kix file please.

John Paul

Top
#211734 - 16/06/30 04:03 PM Re: Kix based on OS Ver [Re: jszkudlapski]
jszkudlapski Offline
Just in Town

Registered: 16/06/29
Posts: 4
Loc: UK
I have done it this way and it seems to work;

 Quote:

$ntversion = READVALUE("HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\", "CurrentVersion")
SELECT
CASE $ntversion = "6.1"
CALL "Win7-Main.kix"
CASE $ntversion = "6.3"
CALL "Win10-Main.kix"
ENDSELECT


Edited by jszkudlapski (16/06/30 04:17 PM)

Top
#211735 - 16/06/30 05:16 PM Re: Kix based on OS Ver [Re: jszkudlapski]
Glenn Barnas Moderator Offline
KiX Supporter
*****

Registered: 03/01/28
Posts: 4211
Loc: New Jersey
Either way would work.

I prefer to use UDFs as the call to the UDF usually makes it clear what's happening. \:\) I also don't have to remember all of the different ways to get reg data. In this case, you're getting "6.3" instead of "10.0" - it comes down to readability for later support.

Our login script can do this kind of stuff natively, so it's just one script, one config file. I tend to avoid using multiple scripts or config files whenever possible. My last deployment was probably the exception - one script, but one config file for each RDS host - there were about 20 - one to support administration of each major financial platform. The ability to use host-specific config files came in handy!

Glenn
_________________________

Actually I am a Rocket Scientist! \:D

Top
Page 1 of 1 1


Moderator:  Jochen, Allen, Radimus, Chris S., Glenn Barnas, ShaneEP, Arend_, Mart 
Hop to:
Shout Box

Who's Online
1 registered (green78) and 144 anonymous users online.
Newest Members
Keris2112, Jorromans, qrstuv140696, Bloodboy, NIJAKIX
17451 Registered Users

Generated in 0.045 seconds in which 0.016 seconds were spent on a total of 13 queries. Zlib compression enabled.

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