|
|
|||||||
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. |
||||||||
|
|
|||||||
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 |
||||||||
|
|
|||||||
Oh - and Welcome to KORG! Glenn |
||||||||
|
|
|||||||
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 |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
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 |
||||||||
|
|
|||||||
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 |
||||||||
|
|
|||||||
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 |