#118449 - 2004-04-21 10:59 PM
Upgrading? To Upgrade?
|
jeremywright
Fresh Scripter
Registered: 2004-04-21
Posts: 20
Loc: Canada
|
Hey,
This'll be my first (hopefully not last) post here. I hadn't even realised there was a Kix community.
Anyways, we're running Kix 95 right now. Wondering if there's a compelling reason to upgrade?
Jeremy
|
|
Top
|
|
|
|
#118451 - 2004-04-21 11:11 PM
Re: Upgrading? To Upgrade?
|
Kdyer
KiX Supporter
   
Registered: 2001-01-03
Posts: 6241
Loc: Tigard, OR
|
The big reason to upgrade from KiX95 to Kix2001, is that there is greater functionality built in.
Kent
|
|
Top
|
|
|
|
#118453 - 2004-04-22 03:38 PM
Re: Upgrading? To Upgrade?
|
jeremywright
Fresh Scripter
Registered: 2004-04-21
Posts: 20
Loc: Canada
|
I'm not really sure we'd use the functionality. So there is no platform reason we shouldn't? If scripts work on 9x and up on KiX95, they'll work in 2001?
Thanks
|
|
Top
|
|
|
|
#118455 - 2004-04-22 04:04 PM
Re: Upgrading? To Upgrade?
|
jeremywright
Fresh Scripter
Registered: 2004-04-21
Posts: 20
Loc: Canada
|
Sorry, I realise I was overly vague.
We aren't running AD (we use eDirectory for directory services), and the scripts we are running are very, very basic (assigning drive mappings according to NT groups and/or users).
I'm fairly sure they'd work, here's a sample:
Code:
? "Time is now being sychronized to network ..." SETTIME "\\HSCXNTDC0001"
IF INGROUP("DESKTOP") ;IF @USERID = "TUSER2" IF @DOS >= "4.0" ; ? "Windows NT Version is " + @DOS SLEEP 5 CALL "ZENUPGRADE.KIX" ENDIF ENDIF
; MAPS ALL USERS' HOME PERSONAL FOLDER TO H:
;USE H: @HOMESHR USE H: "\\HSC01FP1\" + @USERID + "$"
; *** DEPARTMENT RESOURCE MAPPING ***
; Children's Hospital Family Library Mappings IF INGROUP("CHFL") ? "Welcome to Children's Hospital Family Library...!" USE S: \\HSC01FP1\CHFL_Shared ENDIF
And then the groups and user mappings just repeat all the way down.
|
|
Top
|
|
|
|
#118456 - 2004-04-22 04:05 PM
Re: Upgrading? To Upgrade?
|
Radimus
Moderator
   
Registered: 2000-01-06
Posts: 5187
Loc: Tampa, FL
|
the difference is MAINLY in COM automation and a few additional built in macros.
If you are only mapping drives and basic registry edits, the 3.6x is sufficient. Look around here and see some of the things we do, Like UDFs, and ADSI, and WMI, and such, then you will upgrade.
You can only resist for just so long...
|
|
Top
|
|
|
|
#118457 - 2004-04-22 04:27 PM
Re: Upgrading? To Upgrade?
|
maciep
Korg Regular
   
Registered: 2002-06-14
Posts: 947
Loc: Pittsburgh
|
Actually, didn't INGROUP change? Look at the return values
3.63
Quote:
INGROUP( )
Action: Checks whether the current user is a member of a group. Syntax: INGROUP ("group name") Parameters: Group name - Identifies the group in which to check the user's membership. Remarks: INGROUP can be used to check for groupmembership of groups that exist on the domain or server where the user is logged on, or to check for groupmembership of groups on a specific domain or server. When checking for a local group, INGROUP identifies that the user is indirectly a member of the group by virtue of being a member of a global group which, in turn, is a member of the local group.
If you want to check for membership in a group on a specific domain or server, use the following format:
"OtherDomain\group" –or – "\\SomeServer\group"
For Windows 9x clients, INGROUP works on local groups only if the KiXtart RPC service is running. Returns: 0 The user is not a member of a group with this name. 1 The user is a member of a global group with this name. 2 The user is a member of a local group with this name. Examples: IF INGROUP("Domain Users") DISPLAY "z:\users.txt" ENDIF
IF INGROUP("Developers") = 2 ? "Member of local group Developers" ENDIF
IF INGROUP("\\" + @WKSTA + "\Developers") = 2 ? "Member of local group Developers on local system" ENDIF
4.22
Quote:
InGroup( )
Action: Checks whether the current user is a member of a group. Syntax: INGROUP ("group name" [<,> "group name 2"], mode) Parameters: Group name, group name 2, group name X… Identifies the group(s) in which to check the user's membership. You may pass multiple group names as arguments -or- a single array who's element(s) are the names of one or more groups to test. Note: This function does not currently support passing multiple arrays as arguments.
Mode
Optional integer parameter indicating whether or not InGroup checks for group membership of one or all groups in the list (default = 0). Possible values:
0 InGroup checks for membership of ONE of the groups in the list (default) 1 InGroup checks for membership of ALL of the groups in the list Remarks: INGROUP can be used to check for groupmembership of groups that exist on the domain or server where the user is logged on, or to check for groupmembership of groups on a specific domain or server. When checking for a local group, INGROUP identifies that the user is indirectly a member of the group by virtue of being a member of a global group which, in turn, is a member of the local group.
If you want to check for membership in a group on a specific domain or server, use the following format:
"OtherDomain\group" –or– "\\SomeServer\group"
For Windows 9x clients, INGROUP works on local groups only if the KiXtart RPC service is running. Returns: 0 The user is not a member of a group with this name 1 The user is a member of a global group with this name See Also: EnumGroup( ), EnumLocalGroup( ), Group Membership Information Examples: If InGroup("Domain Users") DISPLAY "z:\users.txt" EndIf
If InGroup("Developers", "Testers") = 1 ? "Member of Developers OR Testers group" EndIf
If InGroup("Developers", "Testers", 1) = 1 ? "Member of Developers AND Testers group" EndIf
$Array = "Developers", "Testers" If InGroup($Array, 1) = 1 ? "Member of Developers AND Testers group" EndIf
If InGroup("\\" + @WKSTA + "\Developers") = 1 ? "Member of Developers on local system" EndIf
_________________________
Eric
|
|
Top
|
|
|
|
#118458 - 2004-04-22 05:33 PM
Re: Upgrading? To Upgrade?
|
jeremywright
Fresh Scripter
Registered: 2004-04-21
Posts: 20
Loc: Canada
|
Looks like it'll work, as the command "IF INGROUP("GROUPNAME")" is still valid, right?
It looks like they've added functionality while allowing for backwards compatibility.
|
|
Top
|
|
|
|
#118459 - 2004-04-22 05:35 PM
Re: Upgrading? To Upgrade?
|
Radimus
Moderator
   
Registered: 2000-01-06
Posts: 5187
Loc: Tampa, FL
|
if you aren't going to Active Directory, you will be OK with the old versions of Kix
|
|
Top
|
|
|
|
#118460 - 2004-04-22 06:03 PM
Re: Upgrading? To Upgrade?
|
jeremywright
Fresh Scripter
Registered: 2004-04-21
Posts: 20
Loc: Canada
|
The version of KiX we're running doesn't have the @ProductType, something we need for a script we're writing now. Also, we'll be eventually going to AD (to some degree) anyways, as we need to upgrade our DC's to 2000 (and so need to define the AD forest / scope).
|
|
Top
|
|
|
|
#118461 - 2004-04-22 06:18 PM
Re: Upgrading? To Upgrade?
|
Radimus
Moderator
   
Registered: 2000-01-06
Posts: 5187
Loc: Tampa, FL
|
you can get around the @producttype by using some older code (that we used when this wasn't available)
It is about 3 years old, and I never bothered collecting all the details for the Wintendo clients, but you can see the way it works.
The UDF OSID() has expanded on this quite a bit, but your version of kix will not run UDFs
Code:
select Case @inwin=1 $kernel ="WinNT" $prodkey ="HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ProductOptions" $prodrole="HKEY_LOCAL_MACHINE\Security\Policy\PolSrvRo" $DCRole =READVALUE("$prodrole","(No Name)") $type =ReadValue("$prodkey","ProductType") $Svcpack =ReadValue("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion","CSDVersion")
$ProductSuite="" $ProductSuite=READVALUE("$prodkey","ProductSuite") IF LEN($ProductSuite)>0 $ProductSuite=SUBSTR($ProductSuite,1,INSTR($ProductSuite,"|")-1) EndIf
select Case @dos=5.1 $system="WinXP" Case @dos=5.0 $system="Win2k" Case @dos=4.0 $system="WinNT" endselect select Case $type="LANMANNT" $flavor="$DCRole $ProductSuite Domain Controller" Case $type="ServerNT" $flavor="$ProductSuite Member Server" Case $type="WinNT" $flavor="Professional" endselect Case @inwin=2 $kernel="Win9x" $Svcpack="" $SubVer=ReadValue("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion","SubVersionNumber") select Case @dos="???" $system="WinME" $flavor="A" Case @dos="4.10" $system="Win98" select Case $subver="???" $flavor="SE" Case $subver="a" $flavor="A" endselect Case @dos="4.0" $system="Win95" select Case $subver=" C" $flavor="OSR2.5" Case $subver=" B" $flavor="OSR2" Case $subver="a" $flavor="A" endselect endselect endselect
? "Kernel type is "+$kernel ? "Operating System is "+$system $Svcpack ? "OS Flavor is "+$flavor get $k ;Pauses script to view output
|
|
Top
|
|
|
|
#118462 - 2004-04-22 06:50 PM
Re: Upgrading? To Upgrade?
|
jeremywright
Fresh Scripter
Registered: 2004-04-21
Posts: 20
Loc: Canada
|
Does @INWIN work? It's not in my documentation for KiX95?
I think we'll just upgrade and take advantage of the simplicity of @PRODUCTTYPE. If it's not going to cause any problems, and gives us added functionality we'll do it.
We've slated to do it for tomorrow at this time, so if I have any questions I'll definitely ask.
Thanks for your help everyone
|
|
Top
|
|
|
|
Moderator: Jochen, Allen, Radimus, Glenn Barnas, ShaneEP, Ruud van Velsen, Arend_, Mart
|
0 registered
and 764 anonymous users online.
|
|
|