|
|
|
FAQ
Q: How to start playing with and/or using PoorMan'sSMS?A: Start by downloading project files then:
- Unzip downloaded file, run Setup.wsf,
- Open (using favorite editor) and read carefully instructions:
C:\Program Files\_Scripts\PoorMan'sSMS\_ReadMe.txt
- Open (using favorite editor) and adjust contents of:
C:\Program Files\_Scripts\PoorMan'sSMS\Hosts.ini
C:\Program Files\_Scripts\PoorMan'sSMS\IPranges.ini
- Log on as Domain Administrator then:
- Hit Start Button,
- Navigate to Programs,
- Navigate to Poor Man's SMS,
- Click on InfoCollector icon to run your very first network scan.
- Results will go in ..PoorMan'sSMS\Jobs\TIME_STAMP_Job folder.
Q: What are the requirements and/or limitations of PoorMan'sSMS?
A: You can run this app and get expected results if (and only if):
- User running PoorMan'sSMS is logged on to the network using account with sufficient permissions. Account used must be a member of local administrators group on each of scanned hosts. One such that immediately crosses one's mind is the Domain Administrator...
- It is assumed that ALL host expected on the network will have WMI installed and enabled. Furthermore DCOM on these computers must be enabled.
- Computer running PoorMan'sSMS should be Win2K system with WSH 5.6 installed.
- Results fetched - the list of installed software on remote systems will be as good and as valid as the contents of Uninstall key of the remote systems is.
If the contents of registry key:
In (wonderful?) world of Windows, apps write
and delete keys from this branch of registry freely. For every entry
found there there is absolutely NO guarantee that the 'places'
Uninstall keys points to are really 'there'. In other words - no guarantees that application is really installed
as the key claims. Q: What can go wrong with PoorMan'sSMS?
So far I witnessed these most misfortunate and/or mysterious acts: - Some computers can not be scanned since DCOM on these systems is
disabled (for some reason and/or by someone's intention).
Therefore WMI can not instanciate remote objects. Run the 'dcomcnfg'
from the command line, flip to the "Default Properties" tab and
"Enable DCOM on this computer"
- While scanning the IP range, script would seem to stop, appearing
as if hanging or stalled while scanning single (random) IP address.
The root of this behavior lies in single threaded nature of MS
scripting environment. Namely, it may happen (very rarely though)
that remotely instanciated WMI object on remote system gets created
in a corrupted state, thus the call made against such an object
never returns. Solution - by rebooting problematic computer crash the remote object
deliberately, which as a consequence will free up the stalled thread.
Program flow will resume as if nothing happened (error will be logged). In some cases you will have to both re-boot remote computer with
'stalled' WMI AND kill the script and start scan all over again :-(
- Although all is fine, computer is on the network and you can see
the network neighborhood from it, WMI is there and working, for
some strange reason every time you try to scan it using ToScan.ini
as 'the driver' - you can see that as if the computer seems not to
be there? It is not responding to pings, therefore it ends up not
being scanned. Guess what is the problem... If you guessed that WINS server had incorrect NetBIOS name to IP
address mapping you were right! Delete incorrect WINS record and
your problem is gonner.
- Odd computer(s) although may have WMI install and enabled, and are
DCOM enabled, just can not be scanned. WMI calls will fail no matter
what. Workaround? Plain slash/re-install from scratch does it as always...
Stuff from the above happens rarely, but it does happen in my neighborhood
It will in yours too. Learn to live with it (if not love it), or
switch to something that just works the way it should (*nix anybody?).
is bogus or just plain inaccurate, fetched results will be bogus
and inaccurate too.
Any known problems and/or documented workarounds?
A: As per Muphy's laws...
D-oh!
D-oh^2!
D-oh^3!
D-oh^N!