#29118 - 2002-09-17 05:18 AM
Determining OS type...remotely
|
MikeB
Fresh Scripter
Registered: 2002-09-17
Posts: 6
|
Hi all!
I have read through many of the message threads posted here, however I still have yet to find a comprehensive answer to my particular problem (albeit rudimentary as it may seem to some of you experts). I am looking for a method (via Kix 4.x) to get the same functionality of the @Producttype macro on remote machines. I have admin scripts that I would like to run that require the OS type to perform branch functions. I run the full gauntlet of clients from W2K Adv Server to Win98, and need to get as granular as possible when determing the OS on remote machines (even differentiating between W2K Server and W2K Advanced server). Please keep in mind that I need this info ported into the logic of the script to determine the brach to follow. Any advice would be most appreciated!
Mike B.
|
|
Top
|
|
|
|
#29119 - 2002-09-17 05:26 AM
Re: Determining OS type...remotely
|
Kdyer
KiX Supporter
   
Registered: 2001-01-03
Posts: 6241
Loc: Tigard, OR
|
MikeB,
Welcome to the board!
Rather than detecting what OS it is remotely, why not have the client do it with a login script? At the time he/she logs in, you could write this information to a database, log file, etc.
The other issue I can see with detection remotely, is that you have to insure that all systems are turned on.
HTH,
Kent
|
|
Top
|
|
|
|
#29120 - 2002-09-17 05:33 AM
Re: Determining OS type...remotely
|
MikeB
Fresh Scripter
Registered: 2002-09-17
Posts: 6
|
My aplogies if I was not too clear on what I was looking to do. The scripts I am developing are not intended to be used as logon scripts, yet admin scripts that I will run against a list of NetBIOS names (mostly server class machines that are in a 24x7 environment that rarely have anybody logging onto them). My appreciation for your quick responses and valuable advice remain immeasurable...
Mike B.
|
|
Top
|
|
|
|
#29121 - 2002-09-17 02:36 PM
Re: Determining OS type...remotely
|
Radimus
Moderator
   
Registered: 2000-01-06
Posts: 5187
Loc: Tampa, FL
|
you can use WMIQuery() UDF to do it, but the client machine needs WMI installed.
XP, 2k, NTsp4+ have it built in (including servers) 95, 98 need to have it installed ME might have it built in
pending that:
$os=wmiquery("Caption","Win32_OperatingSystem",$remotecomputer)
|
|
Top
|
|
|
|
#29124 - 2002-09-17 07:12 PM
Re: Determining OS type...remotely
|
MikeB
Fresh Scripter
Registered: 2002-09-17
Posts: 6
|
Thank you all for your help with this, but I have a couple comments after trying a couple of your suggestions...
1) Using the registry keys referenced by sealeopard only seems to be valid on W2K/XP machines.
2) I believe the same is true for the WMI queries.
You would think that this age old issue that is so common in many admin scripts would have an easy answer. I would not think it too difficult to allow KIX macros to be ran on remote machines with minimal code revisions.
Mike B
|
|
Top
|
|
|
|
#29125 - 2002-09-17 07:16 PM
Re: Determining OS type...remotely
|
Radimus
Moderator
   
Registered: 2000-01-06
Posts: 5187
Loc: Tampa, FL
|
that is because wintendos are unmanageable
the only thing win95 gives you is a start button, everything else, you will have to work for.
|
|
Top
|
|
|
|
#29126 - 2002-09-17 07:21 PM
Re: Determining OS type...remotely
|
MikeB
Fresh Scripter
Registered: 2002-09-17
Posts: 6
|
Althouh I tend to agree that there has been a lack of follow through in design of the varios MS platforms that make it rather difficult to manage, that still does not change the fact that the majority of the Fortune 500 companies and the world in general have lied in bed with the devil and system engineers and application developers alike have to pay the price. Any other creative suggestions to the problem at hand?
Many thanks,
Mike B.
|
|
Top
|
|
|
|
#29127 - 2002-09-17 07:25 PM
Re: Determining OS type...remotely
|
Radimus
Moderator
   
Registered: 2000-01-06
Posts: 5187
Loc: Tampa, FL
|
test for failures...
if you get WMIQuery() that will tell you winnt,2k,and xp... even if you don't feel like installing it on your 95/98 machines
if it fails and C$ exists, then you have an old NT box
everything else is wintendo
|
|
Top
|
|
|
|
#29129 - 2002-09-17 11:00 PM
Re: Determining OS type...remotely
|
NTDOC
Administrator
   
Registered: 2000-07-28
Posts: 11628
Loc: CA
|
Mike,
Try taking a look at the utils on this website. I would think you might be able to do what you're wanting to do using one or more of these utils.
freeware utilities
|
|
Top
|
|
|
|
#29130 - 2002-09-18 12:10 AM
Re: Determining OS type...remotely
|
kholm
Korg Regular
   
Registered: 2000-06-19
Posts: 714
Loc: Randers, Denmark
|
Doc,
Your Freeware utilities link seems very promissing, i have only tested ShortCut v.1.0, it seems to be able to do the same job as MakeScut from ScriptLogic, AND more, it can extract the properties of an existing shortcut and change properties on existing shortcuts.
Only drawback i have found: It only works on .lnk files, NOT .url
Also it is small, only 40 kb
The: Last Updated: 10/02/2000 and support for XP seams contradictive, but it dos work on XP, also the comment part.
|
|
Top
|
|
|
|
#29131 - 2002-09-18 12:49 AM
Re: Determining OS type...remotely
|
MikeB
Fresh Scripter
Registered: 2002-09-17
Posts: 6
|
Thanks for the help... Although many suggestions were rather elegant in their approach, and I have implmented a combination of ideas to accomplish what I was looking to do, I still would like to see the next version of KIX port the simple producttype macro (and others like it) into a distributed environement where a centralized admin station can run various scripts across a multitude of machines while using these scripts. WMI is great, but deploying the agents to non WMI compatible machines is bit of overhead when you have in excess of 5000 nodes.
Thank you, Mike B
|
|
Top
|
|
|
|
#29134 - 2002-09-18 06:09 PM
Re: Determining OS type...remotely
|
MikeB
Fresh Scripter
Registered: 2002-09-17
Posts: 6
|
I think if there is anything that should come of all of this, is the fact that although rather kludgy in operation, there 'is' the capability to do what we need done ins some way or another. Perhaps I am not using KIX for what it was originally desinged (primarily a logon script engine), but realistically incorperating the ability for the SAME functionality on a remote machine that you can get by running a script locally should not take a miracle. Accessing COM modules, registry hooks, etc whether it be local or remote is a simple matter of modifying an entrypoint rather than an entire re-design of the code.
Great stuff all!
Mike B
|
|
Top
|
|
|
|
Moderator: Jochen, Allen, Radimus, Glenn Barnas, ShaneEP, Ruud van Velsen, Arend_, Mart
|
0 registered
and 657 anonymous users online.
|
|
|