Xymon Powershell Windows client
list Zak Beck
Hi all, Today I have uploaded a new version of the Xymon Powershell client to SVN (in sandbox/WinPSClient). We (Accenture) are very pleased to be contributing these changes to the open source community. I've been working on this now for around 8 months on and off and hopefully the changes made will be of benefit to everyone! Whilst making changes, we have focussed mainly on making it work, improving reliability and most importantly improving performance. In most cases, on our 64 bit OS virtual machines, a data collection now takes around 5 seconds. On heavily loaded (CPU load or event log load) servers, the script is now considerably faster than originally. Key to this has been reducing the amount of WMI usage as this was a major culprit. We have also implemented some new features, largely based on our in-house requirements but hopefully useful to others: * Showing the process owner and command line in [procs]. This has been implemented using c# code, compiled at runtime. * Adding Active Directory replication test, Terminal Services sessions test * Ability to restart any stopped Windows service * Client self-update * Dirsize and dirtime checks (which were originally external scripts) Some things have changed slightly; for example, the local configuration which was registry-based is now XML-based (you can still use registry settings if you prefer). In the SVN repository I have also uploaded a Word document which describes how to install and the configuration options. I have uploaded all the revisions we have made to SVN so there is a history of development. Whilst we will endeavour to continue contributing changes and improvements in coming months, this is an open source project and as such we are not offering any formal support. If anyone wishes to bugfix, branch or whatever, please do so! Zak Beck Accenture
list Shawn Heisey
▸
On 2/13/2015 2:53 AM, user-aada0fa38bf8@xymon.invalid wrote:
Today I have uploaded a new version of the Xymon Powershell client to SVN (in sandbox/WinPSClient). We (Accenture) are very pleased to be contributing these changes to the open source community. I've been working on this now for around 8 months on and off and hopefully the changes made will be of benefit to everyone!
The required steps may be obvious to other people here, but I don't see anything in your email about where this SVN repo is or how to actually obtain the code, documentation, etc. Can you provide some links? Thanks, Shawn
list Brandon Dale
http://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/ -----Original Message----- From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Shawn Heisey Sent: Saturday, 14 February 2015 9:10 AM To: xymon at xymon.com Subject: Re: [Xymon] Xymon Powershell Windows client On 2/13/2015 2:53 AM, user-aada0fa38bf8@xymon.invalid wrote:
Today I have uploaded a new version of the Xymon Powershell client to SVN (in sandbox/WinPSClient). We (Accenture) are very pleased to be contributing these changes to the open source community. I've been working on this now for around 8 months on and off and hopefully the changes made will be of benefit to everyone!
The required steps may be obvious to other people here, but I don't see anything in your email about where this SVN repo is or how to actually obtain the code, documentation, etc. Can you provide some links? Thanks, Shawn
list Lukas Kohl
Hello Zak, thank you a lot for your good work. The Script works pretty well, until now everything went exactly as it should. Our Xymon server is on Version 4.3.17, but our Windows Clients are still using the old BBwin Binary. So they are configured local. Is there any chance to have a localclient.cfg, which can be used by your Powershell Script, like we have on the Linux Clients ? Otherwise a migration to the new Client would be very painfull for us. Kind regards, Lukas Kohl
list Zak Beck
Hi Lukas If you just want to use local config files and ignore any config returned by the Xymon server, your xymonclient_config.xml will need to look like the following: <XymonSettings> <!-- your Xymon server: --> <servers>xymonserver.domain.com</servers> <!-- where your local config file is: --> <clientconfigfile>c:\program files\xymon\clientconfig.cfg</clientconfigfile> <!-- client remotecfgexec = 0 = ignore config from server --> <clientremotecfgexec>0</clientremotecfgexec> </XymonSettings> You then setup the local config in the location specified as normal. The directives you can use are listed in http://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/XymonPSCli ent.doc. I use a similar setup for testing new features. Thanks Zak
▸
-----Original Message-----
From: user-cd4357c4ac57@xymon.invalid [mailto:user-cd4357c4ac57@xymon.invalid]
Sent: 16 February 2015 09:08
To: Beck, Zak
Cc: xymon at xymon.com
Subject: [Xymon] Xymon Powershell Windows client
Hello Zak,
thank you a lot for your good work. The Script works pretty well, until now
everything went exactly as it should.
Our Xymon server is on Version 4.3.17, but our Windows Clients are still
using the old BBwin Binary. So they are configured local.
Is there any chance to have a localclient.cfg, which can be used by your
Powershell Script, like we have on the Linux Clients ?
Otherwise a migration to the new Client would be very painfull for us.
Kind regards,
Lukas Kohl
list Lukas Kohl
Hello Zak,
please correct me if I am wrong, but I don't see a proper way to set these settings local:
HOST=example-host
UP 10m
LOAD 80 100
PROC java 10 -1
PORT LOCAL=%[.:]2000[0-9]$ MIN=5 MAX=10 STATE=LISTENING TRACK=ports
SVC XymonPSClient status=started startup=automatic
In contrast, here is a snippet of localclient.cfg, which is shipped with the Linux client (http://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.3.17/client/localclient.cfg):
# localclient.cfg - configuration file for a LOCAL Xymon client.
#
# By default, Xymon clients send raw data to the Xymon server,
# which in turn converts the data into status messages.
# In that case, THIS FILE IS NOT USED and you should IGNORE it.
#
# If you want to configure clients locally (on the server that the
# client runs one), you do it here. You MUST also change the
# clientlaunch.cfg file and add the "--local" option to the
# command launching xymonclient.sh
#
# The file defines a series of rules:
# UP : Changes the "cpu" status when the system has rebooted recently,
# or when it has been running for too long.
# LOAD : Changes the "cpu" status according to the system load.
# CLOCK : Changes the "cpu" status if the client system clock is
# not synchronized with the clock of the Xymon server.
# DISK : Changes the "disk" status, depending on the amount of space
# used of filesystems.
# MEMPHYS: Changes the "memory" status, based on the percentage of real
# memory used.
# MEMACT : Changes the "memory" status, based on the percentage of "actual"
# memory used. Note: Not all systems report an "actual" value.
# MEMSWAP: Changes the "memory" status, based on the percentage of swap
# space used.
# PROC : Changes the "procs" status according to which processes were found
# in the "ps" listing from the client.
# LOG : Changes the "msgs" status according to entries in text-based logfiles.
# Note: The "client-local.cfg" file controls which logfiles the client will report.
# FILE : Changes the "files" status according to meta-data for files.
# Note: The "client-local.cfg" file controls which files the client will report.
# DIR : Changes the "files" status according to the size of a directory.
# Note: The "client-local.cfg" file controls which directories the client will report.
# PORT : Changes the "ports" status according to which tcp ports were found
# in the "netstat" listing from the client.
# DEFAULT: Set the default values that apply if no other rules match.
...
Kind regards,
Lukas
▸
-----Original Message----- Hi Lukas If you just want to use local config files and ignore any config returned by the Xymon server, your xymonclient_config.xml will need to look like the following: <XymonSettings> <!-- your Xymon server: --> <servers>xymonserver.domain.com</servers> <!-- where your local config file is: --> <clientconfigfile>c:\program files\xymon\clientconfig.cfg</clientconfigfile> <!-- client remotecfgexec = 0 = ignore config from server --> <clientremotecfgexec>0</clientremotecfgexec> </XymonSettings> You then setup the local config in the location specified as normal. The directives you can use are listed in http://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/XymonPSCli ent.doc. I use a similar setup for testing new features. Thanks Zak -----Original Message----- From: user-cd4357c4ac57@xymon.invalid [mailto:user-cd4357c4ac57@xymon.invalid] Sent: 16 February 2015 09:08 To: Beck, Zak Cc: xymon at xymon.com Subject: [Xymon] Xymon Powershell Windows client Hello Zak, thank you a lot for your good work. The Script works pretty well, until now everything went exactly as it should. Our Xymon server is on Version 4.3.17, but our Windows Clients are still using the old BBwin Binary. So they are configured local. Is there any chance to have a localclient.cfg, which can be used by your Powershell Script, like we have on the Linux Clients ? Otherwise a migration to the new Client would be very painfull for us. Kind regards, Lukas Kohl
list Zak Beck
Hi Lukas The PS client does not support "localclient.cfg" in the manner described in the comments on your config (and never has done even before my amendments). I can't find documentation for localclient.cfg on xymon.com - I can see what it's doing from your example, but we use hosts.cfg / analysis.cfg with raw data sent back to the server.
▸
Thanks
Zak
-----Original Message-----
From: user-cd4357c4ac57@xymon.invalid [mailto:user-cd4357c4ac57@xymon.invalid]
Sent: 16 February 2015 09:46
To: Beck, Zak
Cc: xymon at xymon.com
Subject: Re: RE: [Xymon] Xymon Powershell Windows client
Hello Zak,
please correct me if I am wrong, but I don't see a proper way to set these
settings local:
HOST=example-host
UP 10m
LOAD 80 100
PROC java 10 -1
PORT LOCAL=%[.:]2000[0-9]$ MIN=5 MAX=10 STATE=LISTENING
TRACK=ports
SVC XymonPSClient status=started startup=automatic
In contrast, here is a snippet of localclient.cfg, which is shipped with the
Linux client(http://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.3.17/client/localc lient.cfg):
▸
# localclient.cfg - configuration file for a LOCAL Xymon client. # # By default, Xymon clients send raw data to the Xymon server, # which in turn converts the data into status messages. # In that case, THIS FILE IS NOT USED and you should IGNORE it. # # If you want to configure clients locally (on the server that the # client runs one), you do it here. You MUST also change the # clientlaunch.cfg file and add the "--local" option to the # command launching xymonclient.sh # # The file defines a series of rules: # UP : Changes the "cpu" status when the system has rebooted recently, # or when it has been running for too long. # LOAD : Changes the "cpu" status according to the system load. # CLOCK : Changes the "cpu" status if the client system clock is # not synchronized with the clock of the Xymon server. # DISK : Changes the "disk" status, depending on the amount of space # used of filesystems. # MEMPHYS: Changes the "memory" status, based on the percentage of real # memory used. # MEMACT : Changes the "memory" status, based on the percentage of "actual" # memory used. Note: Not all systems report an "actual" value. # MEMSWAP: Changes the "memory" status, based on the percentage of swap # space used. # PROC : Changes the "procs" status according to which processes were found # in the "ps" listing from the client. # LOG : Changes the "msgs" status according to entries in text-based logfiles. # Note: The "client-local.cfg" file controls which logfiles the client will report. # FILE : Changes the "files" status according to meta-data for files. # Note: The "client-local.cfg" file controls which files the client will report. # DIR : Changes the "files" status according to the size of a directory. # Note: The "client-local.cfg" file controls which directories the client will report. # PORT : Changes the "ports" status according to which tcp ports were found # in the "netstat" listing from the client. # DEFAULT: Set the default values that apply if no other rules match. ... Kind regards, Lukas -----Original Message----- Hi Lukas If you just want to use local config files and ignore any config returned by the Xymon server, your xymonclient_config.xml will need to look like the following: <XymonSettings> <!-- your Xymon server: --> <servers>xymonserver.domain.com</servers> <!-- where your local config file is: --> <clientconfigfile>c:\program files\xymon\clientconfig.cfg</clientconfigfile> <!-- client remotecfgexec = 0 = ignore config from server --> <clientremotecfgexec>0</clientremotecfgexec> </XymonSettings> You then setup the local config in the location specified as normal. The directives you can use are listed in http://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/XymonPSCli ent.doc. I use a similar setup for testing new features. Thanks Zak -----Original Message----- From: user-cd4357c4ac57@xymon.invalid [mailto:user-cd4357c4ac57@xymon.invalid] Sent: 16 February 2015 09:08 To: Beck, Zak Cc: xymon at xymon.com Subject: [Xymon] Xymon Powershell Windows client Hello Zak, thank you a lot for your good work. The Script works pretty well, until now everything went exactly as it should. Our Xymon server is on Version 4.3.17, but our Windows Clients are still using the old BBwin Binary. So they are configured local. Is there any chance to have a localclient.cfg, which can be used by your Powershell Script, like we have on the Linux Clients ? Otherwise a migration to the new Client would be very painfull for us. Kind regards, Lukas Kohl
list Scot Kreienkamp
Thank your for your hard work Zak, from all the combined Win/Linux shops. :) Scot Kreienkamp
▸
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of user-aada0fa38bf8@xymon.invalid
Sent: Friday, February 13, 2015 4:53 AM
To: user-834d44be5e50@xymon.invalid; xymon at xymon.com
Subject: [Xymon] Xymon Powershell Windows client
Hi all,
Today I have uploaded a new version of the Xymon Powershell client to SVN (in sandbox/WinPSClient). We (Accenture) are very pleased to be contributing these changes to the open source community. I've been working on this now for around 8 months on and off and hopefully the changes made will be of benefit to everyone!
Whilst making changes, we have focussed mainly on making it work, improving reliability and most importantly improving performance.
In most cases, on our 64 bit OS virtual machines, a data collection now takes around 5 seconds. On heavily loaded (CPU load or event log load) servers, the script is now considerably faster than originally. Key to this has been reducing the amount of WMI usage as this was a major culprit.
We have also implemented some new features, largely based on our in-house requirements but hopefully useful to others:
* Showing the process owner and command line in [procs]. This has been implemented using c# code, compiled at runtime.
* Adding Active Directory replication test, Terminal Services sessions test
* Ability to restart any stopped Windows service
* Client self-update
* Dirsize and dirtime checks (which were originally external scripts)
Some things have changed slightly; for example, the local configuration which was registry-based is now XML-based (you can still use registry settings if you prefer). In the SVN repository I have also uploaded a Word document which describes how to install and the configuration options.
I have uploaded all the revisions we have made to SVN so there is a history of development. Whilst we will endeavour to continue contributing changes and improvements in coming months, this is an open source project and as such we are not offering any formal support. If anyone wishes to bugfix, branch or whatever, please do so!
Zak Beck
Accenture
This message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, please note that you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by e-mail or by telephone at the above number. Thank you.
list Gavin Stone-Tolcher
Just a quick FYI:
I was just trying a test install on a 32bit windows 7 client and got this:
Cannot set "servers" because only strings can be used as values to set XmlNode p
At C:\Program Files\xymon\xymonclient.ps1:644 char:26
+ $script:XymonSettings. <<<< servers = $script:XymonSettings.server
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : PropertyAssignmentException
I had multiple IP in the <servers> etry in the config.
Changing the <servers> entry in xymonclient_config.xml to have a single entry rather than multiple whitespace entries allows the client to install with no error.
After installation adding a second IP to <servers> entry also does not seem to work with it just reporting to the first entry?
Also just another quick one, I have a mountpoint defined on this system that does not seem to be collected. Are mountpoints supported?
I re-ran the bbwin client on the same system and the mountpoint is detected and displayed.
Cheers,
Gavin Stone-Tolcher, IT Support Officer, Network Operations and Incident Response
Information Technology Services
The University of Queensland
Level 4, Prentice Building, St Lucia 4072
T: +61 7 334 66645, M: +61 401 140 838
E: user-6e44775a32e5@xymon.invalid<mailto:user-6e44775a32e5@xymon.invalid> W: www.its.uq.edu.au<http://www.its.uq.edu.au>;
ITS: Service. Team. Accountability. Results.
IMPORTANT: This email and any attachments are intended solely for the addressee(s), contain copyright material and are confidential. We do not waive any legal privilege or rights in respect of copyright or confidentiality. Except as intended addressees are otherwise permitted, you do not have permission to use, disclose, reproduce or communicate any part of this email or its attachments. Statements, opinions and information not related to the official business of The University of Queensland are neither given nor endorsed by us. By using this email (including accessing any attachments or links) you agree we are not liable for any loss or damage of any kind arising in connection with any electronic defect, virus or other malicious code we did not intentionally include.
Please consider the environment before printing this email.
CRICOS Code 00025B
▸
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of user-aada0fa38bf8@xymon.invalid
Sent: Friday, 13 February 2015 7:53 PM
To: user-834d44be5e50@xymon.invalid; xymon at xymon.com
Subject: [Xymon] Xymon Powershell Windows client
Hi all,
Today I have uploaded a new version of the Xymon Powershell client to SVN (in sandbox/WinPSClient). We (Accenture) are very pleased to be contributing these changes to the open source community. I've been working on this now for around 8 months on and off and hopefully the changes made will be of benefit to everyone!
Whilst making changes, we have focussed mainly on making it work, improving reliability and most importantly improving performance.
In most cases, on our 64 bit OS virtual machines, a data collection now takes around 5 seconds. On heavily loaded (CPU load or event log load) servers, the script is now considerably faster than originally. Key to this has been reducing the amount of WMI usage as this was a major culprit.
We have also implemented some new features, largely based on our in-house requirements but hopefully useful to others:
* Showing the process owner and command line in [procs]. This has been implemented using c# code, compiled at runtime.
* Adding Active Directory replication test, Terminal Services sessions test
* Ability to restart any stopped Windows service
* Client self-update
* Dirsize and dirtime checks (which were originally external scripts)
Some things have changed slightly; for example, the local configuration which was registry-based is now XML-based (you can still use registry settings if you prefer). In the SVN repository I have also uploaded a Word document which describes how to install and the configuration options.
I have uploaded all the revisions we have made to SVN so there is a history of development. Whilst we will endeavour to continue contributing changes and improvements in coming months, this is an open source project and as such we are not offering any formal support. If anyone wishes to bugfix, branch or whatever, please do so!
Zak Beck
Accenture
list Zak Beck
Hi Thanks for the bug report - I've committed a patch which should fix the multiple servers issue, please try it. There should be a single <servers> element in your config, containing the list of servers, space delimited: <servers>server1.domain.com server2.domain.com</servers> Re: mountpoints, if you add this to your XML config, you will get mountpoints. <wanteddisks>3 4</wanteddisks> By default, wanteddisks = 3 - possible settings below, and you can combine settings with spaces: 2=USB 3=Local disks 4=Network shares 5=CD But you will need the latest patch with the config fix for this to work properly. Regards, Zak
▸
From: Gavin Stone-Tolcher [mailto:user-6e44775a32e5@xymon.invalid]
Sent: 17 February 2015 00:09
To: Beck, Zak; user-834d44be5e50@xymon.invalid; xymon at xymon.com
Subject: RE: Xymon Powershell Windows client
Just a quick FYI:
I was just trying a test install on a 32bit windows 7 client and got this:
Cannot set "servers" because only strings can be used as values to set
XmlNode p
At C:\Program Files\xymon\xymonclient.ps1:644 char:26
+ $script:XymonSettings. <<<< servers =
$script:XymonSettings.server
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : PropertyAssignmentException
I had multiple IP in the <servers> etry in the config.
Changing the <servers> entry in xymonclient_config.xml to have a single
entry rather than multiple whitespace entries allows the client to install
with no error.
After installation adding a second IP to <servers> entry also does not seem
to work with it just reporting to the first entry?
Also just another quick one, I have a mountpoint defined on this system that
does not seem to be collected. Are mountpoints supported?
I re-ran the bbwin client on the same system and the mountpoint is detected
and displayed.
Cheers,
Gavin Stone-Tolcher, IT Support Officer, Network Operations and Incident
Response
Information Technology Services
The University of Queensland
Level 4, Prentice Building, St Lucia 4072
T: +61 7 334 66645, M: +61 401 140 838
E: <mailto:user-6e44775a32e5@xymon.invalid> user-6e44775a32e5@xymon.invalid W: <http://www.its.uq.edu.au>; www.its.uq.edu.au
▸
ITS: Service. Team. Accountability. Results.
IMPORTANT: This email and any attachments are intended solely for the
addressee(s), contain copyright material and are confidential. We do not
waive any legal privilege or rights in respect of copyright or
confidentiality. Except as intended addressees are otherwise permitted, you
do not have permission to use, disclose, reproduce or communicate any part
of this email or its attachments. Statements, opinions and information not
related to the official business of The University of Queensland are neither
given nor endorsed by us. By using this email (including accessing any
attachments or links) you agree we are not liable for any loss or damage of
any kind arising in connection with any electronic defect, virus or other
malicious code we did not intentionally include.
Please consider the environment before printing this email.
CRICOS Code 00025B
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of
user-aada0fa38bf8@xymon.invalid <mailto:user-aada0fa38bf8@xymon.invalid>
Sent: Friday, 13 February 2015 7:53 PM
To: user-834d44be5e50@xymon.invalid
<mailto:user-834d44be5e50@xymon.invalid> ; xymon at xymon.com
<mailto:xymon at xymon.com>
▸
Subject: [Xymon] Xymon Powershell Windows client
Hi all,
Today I have uploaded a new version of the Xymon Powershell client to SVN
(in sandbox/WinPSClient). We (Accenture) are very pleased to be contributing
these changes to the open source community. I've been working on this now
for around 8 months on and off and hopefully the changes made will be of
benefit to everyone!
Whilst making changes, we have focussed mainly on making it work, improving
reliability and most importantly improving performance.
In most cases, on our 64 bit OS virtual machines, a data collection now
takes around 5 seconds. On heavily loaded (CPU load or event log load)
servers, the script is now considerably faster than originally. Key to this
has been reducing the amount of WMI usage as this was a major culprit.
We have also implemented some new features, largely based on our in-house
requirements but hopefully useful to others:
* Showing the process owner and command line in [procs]. This has
been implemented using c# code, compiled at runtime.
* Adding Active Directory replication test, Terminal Services
sessions test
* Ability to restart any stopped Windows service
* Client self-update
* Dirsize and dirtime checks (which were originally external
scripts)
Some things have changed slightly; for example, the local configuration
which was registry-based is now XML-based (you can still use registry
settings if you prefer). In the SVN repository I have also uploaded a Word
document which describes how to install and the configuration options.
I have uploaded all the revisions we have made to SVN so there is a history
of development. Whilst we will endeavour to continue contributing changes
and improvements in coming months, this is an open source project and as
such we are not offering any formal support. If anyone wishes to bugfix,
branch or whatever, please do so!
Zak Beck
Accenture
list Gab Dito
can it be used in a MS cluster resource? can I monitor sql resource and space on it, independently of which node it is running on?
▸
On Fri, Feb 13, 2015, 06:35 null <user-aada0fa38bf8@xymon.invalid> wrote:
Hi all, Today I have uploaded a new version of the Xymon Powershell client to SVN (in sandbox/WinPSClient). We (Accenture) are very pleased to be contributing these changes to the open source community. I've been working on this now for around 8 months on and off and hopefully the changes made will be of benefit to everyone! Whilst making changes, we have focussed mainly on making it work, improving reliability and most importantly improving performance. In most cases, on our 64 bit OS virtual machines, a data collection now takes around 5 seconds. On heavily loaded (CPU load or event log load) servers, the script is now considerably faster than originally. Key to this has been reducing the amount of WMI usage as this was a major culprit. We have also implemented some new features, largely based on our in-house requirements but hopefully useful to others: · Showing the process owner and command line in [procs]. This has been implemented using c# code, compiled at runtime. · Adding Active Directory replication test, Terminal Services sessions test · Ability to restart any stopped Windows service · Client self-update · Dirsize and dirtime checks (which were originally external scripts) Some things have changed slightly; for example, the local configuration which was registry-based is now XML-based (you can still use registry settings if you prefer). In the SVN repository I have also uploaded a Word document which describes how to install and the configuration options. I have uploaded all the revisions we have made to SVN so there is a history of development. Whilst we will endeavour to continue contributing changes and improvements in coming months, this is an open source project and as such we are not offering any formal support. If anyone wishes to bugfix, branch or whatever, please do so! Zak Beck Accenture
list Zak Beck
Hi I'm not sure I understand the question fully, I'm sure there will be other people on the list who can help. The client runs as a Windows service and monitors the space and processes running on that one server. It then reports back those results every 5 minutes (by default) to the Xymon server. If you're asking whether this client can be running on server 1 and monitor server 2, no, it cannot. As far as I know, Xymon is not really designed like that. However, if each node is attached to shared storage, and the storage is presented as a mapped drive, then yes, it can monitor that. You'd need to use in the local config: <wanteddisks>3 4</wanteddisks> and use the update I committed earlier today. Thanks Zak
▸
From: Dito [mailto:user-b8c0e0047c63@xymon.invalid]
Sent: 17 February 2015 13:53
To: Beck, Zak; user-834d44be5e50@xymon.invalid; xymon at xymon.com
Subject: Re: [Xymon] Xymon Powershell Windows client
can it be used in a MS cluster resource? can I monitor sql resource and space on it, independently of which node it is running on?
On Fri, Feb 13, 2015, 06:35 null <user-aada0fa38bf8@xymon.invalid <mailto:user-aada0fa38bf8@xymon.invalid> > wrote:
Hi all,
Today I have uploaded a new version of the Xymon Powershell client to SVN (in sandbox/WinPSClient). We (Accenture) are very pleased to be contributing these changes to the open source community. I've been working on this now for around 8 months on and off and hopefully the changes made will be of benefit to everyone!
Whilst making changes, we have focussed mainly on making it work, improving reliability and most importantly improving performance.
In most cases, on our 64 bit OS virtual machines, a data collection now takes around 5 seconds. On heavily loaded (CPU load or event log load) servers, the script is now considerably faster than originally. Key to this has been reducing the amount of WMI usage as this was a major culprit.
We have also implemented some new features, largely based on our in-house requirements but hopefully useful to others:
* Showing the process owner and command line in [procs]. This has been implemented using c# code, compiled at runtime.
* Adding Active Directory replication test, Terminal Services sessions test
* Ability to restart any stopped Windows service
* Client self-update
* Dirsize and dirtime checks (which were originally external scripts)
Some things have changed slightly; for example, the local configuration which was registry-based is now XML-based (you can still use registry settings if you prefer). In the SVN repository I have also uploaded a Word document which describes how to install and the configuration options.
I have uploaded all the revisions we have made to SVN so there is a history of development. Whilst we will endeavour to continue contributing changes and improvements in coming months, this is an open source project and as such we are not offering any formal support. If anyone wishes to bugfix, branch or whatever, please do so!
Zak Beck
Accenture
list Scot Kreienkamp
Yes it can monitor a cluster, just not like dito is thinking. Have the client setup on both nodes, configure xymon to monitor both nodes and the cluster address, and use combo tests to get a cluster status. Setup the combo tests so they show status on the cluster address, and configure the combo tests so that as long as one of the two nodes is green then the cluster is green as well. That is the best way, I do the same thing with Linux clusters here. The other (less desirable) way is to hard code the cluster name in the config of the client, then set that service to failover and start with the cluster.
▸
Scot Kreienkamp
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of user-aada0fa38bf8@xymon.invalid
Sent: Tuesday, February 17, 2015 10:22 AM
To: user-b8c0e0047c63@xymon.invalid; user-834d44be5e50@xymon.invalid; xymon at xymon.com
Subject: Re: [Xymon] Xymon Powershell Windows client
Hi
I'm not sure I understand the question fully, I'm sure there will be other people on the list who can help.
The client runs as a Windows service and monitors the space and processes running on that one server. It then reports back those results every 5 minutes (by default) to the Xymon server.
If you're asking whether this client can be running on server 1 and monitor server 2, no, it cannot. As far as I know, Xymon is not really designed like that.
However, if each node is attached to shared storage, and the storage is presented as a mapped drive, then yes, it can monitor that. You'd need to use in the local config:
<wanteddisks>3 4</wanteddisks>
and use the update I committed earlier today.
Thanks
Zak
From: Dito [mailto:user-b8c0e0047c63@xymon.invalid]
Sent: 17 February 2015 13:53
To: Beck, Zak; user-834d44be5e50@xymon.invalid<mailto:user-834d44be5e50@xymon.invalid>; xymon at xymon.com<mailto:xymon at xymon.com>
Subject: Re: [Xymon] Xymon Powershell Windows client
can it be used in a MS cluster resource? can I monitor sql resource and space on it, independently of which node it is running on?
On Fri, Feb 13, 2015, 06:35 null <user-aada0fa38bf8@xymon.invalid<mailto:user-aada0fa38bf8@xymon.invalid>> wrote:
Hi all,
Today I have uploaded a new version of the Xymon Powershell client to SVN (in sandbox/WinPSClient). We (Accenture) are very pleased to be contributing these changes to the open source community. I've been working on this now for around 8 months on and off and hopefully the changes made will be of benefit to everyone!
Whilst making changes, we have focussed mainly on making it work, improving reliability and most importantly improving performance.
In most cases, on our 64 bit OS virtual machines, a data collection now takes around 5 seconds. On heavily loaded (CPU load or event log load) servers, the script is now considerably faster than originally. Key to this has been reducing the amount of WMI usage as this was a major culprit.
We have also implemented some new features, largely based on our in-house requirements but hopefully useful to others:
• Showing the process owner and command line in [procs]. This has been implemented using c# code, compiled at runtime.
• Adding Active Directory replication test, Terminal Services sessions test
• Ability to restart any stopped Windows service
• Client self-update
• Dirsize and dirtime checks (which were originally external scripts)
Some things have changed slightly; for example, the local configuration which was registry-based is now XML-based (you can still use registry settings if you prefer). In the SVN repository I have also uploaded a Word document which describes how to install and the configuration options.
I have uploaded all the revisions we have made to SVN so there is a history of development. Whilst we will endeavour to continue contributing changes and improvements in coming months, this is an open source project and as such we are not offering any formal support. If anyone wishes to bugfix, branch or whatever, please do so!
Zak Beck
Accenture
This message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, please note that you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by e-mail or by telephone at the above number. Thank you.
list Ryan Davis
Where is the zip file for distribution? On Tue, Feb 17, 2015 at 11:07 AM, Scot Kreienkamp <
▸
user-9678697f1438@xymon.invalid> wrote:
Yes it can monitor a cluster, just not like dito is thinking. Have the client setup on both nodes, configure xymon to monitor both nodes and the cluster address, and use combo tests to get a cluster status. Setup the combo tests so they show status on the cluster address, and configure the combo tests so that as long as one of the two nodes is green then the cluster is green as well. That is the best way, I do the same thing with Linux clusters here. The other (less desirable) way is to hard code the cluster name in the config of the client, then set that service to failover and start with the cluster. Scot Kreienkamp *From:* Xymon [mailto:xymon-bounces at xymon.com] *On Behalf Of * user-aada0fa38bf8@xymon.invalid *Sent:* Tuesday, February 17, 2015 10:22 AM *To:* user-b8c0e0047c63@xymon.invalid; user-834d44be5e50@xymon.invalid; *Subject:* Re: [Xymon] Xymon Powershell Windows client Hi I'm not sure I understand the question fully, I'm sure there will be other people on the list who can help. The client runs as a Windows service and monitors the space and processes running on that one server. It then reports back those results every 5 minutes (by default) to the Xymon server. If you're asking whether this client can be running on server 1 and monitor server 2, no, it cannot. As far as I know, Xymon is not really designed like that. However, if each node is attached to shared storage, and the storage is presented as a mapped drive, then yes, it can monitor that. You'd need to use in the local config: <wanteddisks>3 4</wanteddisks> and use the update I committed earlier today. Thanks Zak
*From:* Dito [mailto:user-b8c0e0047c63@xymon.invalid <user-b8c0e0047c63@xymon.invalid>]
▸
*Sent:* 17 February 2015 13:53
*To:* Beck, Zak; user-834d44be5e50@xymon.invalid; xymon at xymon.com
*Subject:* Re: [Xymon] Xymon Powershell Windows client
can it be used in a MS cluster resource? can I monitor sql resource and
space on it, independently of which node it is running on?
On Fri, Feb 13, 2015, 06:35 null <user-aada0fa38bf8@xymon.invalid> wrote:
Hi all,
Today I have uploaded a new version of the Xymon Powershell client to SVN
(in sandbox/WinPSClient). We (Accenture) are very pleased to be
contributing these changes to the open source community. I've been working
on this now for around 8 months on and off and hopefully the changes made
will be of benefit to everyone!
Whilst making changes, we have focussed mainly on making it work,
improving reliability and most importantly improving performance.
In most cases, on our 64 bit OS virtual machines, a data collection now
takes around 5 seconds. On heavily loaded (CPU load or event log load)
servers, the script is now considerably faster than originally. Key to this
has been reducing the amount of WMI usage as this was a major culprit.
We have also implemented some new features, largely based on our in-house
requirements but hopefully useful to others:
· Showing the process owner and command line in [procs]. This has
been implemented using c# code, compiled at runtime.
· Adding Active Directory replication test, Terminal Services
sessions test
· Ability to restart any stopped Windows service
· Client self-update
· Dirsize and dirtime checks (which were originally external
scripts)
Some things have changed slightly; for example, the local configuration
which was registry-based is now XML-based (you can still use registry
settings if you prefer). In the SVN repository I have also uploaded a Word
document which describes how to install and the configuration options.
I have uploaded all the revisions we have made to SVN so there is a
history of development. Whilst we will endeavour to continue contributing
changes and improvements in coming months, this is an open source project
and as such we are not offering any formal support. If anyone wishes to
bugfix, branch or whatever, please do so!
Zak Beck
Accenture
This message is intended only for the individual or entity to which it is
addressed. It may contain privileged, confidential information which is
exempt from disclosure under applicable laws. If you are not the intended
recipient, please note that you are strictly prohibited from disseminating
or distributing this information (other than to the intended recipient) or
copying this information. If you have received this communication in error,
please notify us immediately by e-mail or by telephone at the above number.
Thank you.
list Scot Kreienkamp
Read the doc file. There isn't one. Scot Kreienkamp
▸
On Feb 17, 2015, at 5:07 PM, Ryan Davis <user-a950128f4f12@xymon.invalid<mailto:user-a950128f4f12@xymon.invalid>> wrote:
Where is the zip file for distribution?
On Tue, Feb 17, 2015 at 11:07 AM, Scot Kreienkamp <user-9678697f1438@xymon.invalid<mailto:user-9678697f1438@xymon.invalid>> wrote:
Yes it can monitor a cluster, just not like dito is thinking.
Have the client setup on both nodes, configure xymon to monitor both nodes and the cluster address, and use combo tests to get a cluster status. Setup the combo tests so they show status on the cluster address, and configure the combo tests so that as long as one of the two nodes is green then the cluster is green as well. That is the best way, I do the same thing with Linux clusters here.
The other (less desirable) way is to hard code the cluster name in the config of the client, then set that service to failover and start with the cluster.
Scot Kreienkamp
From: Xymon [mailto:xymon-bounces at xymon.com<mailto:xymon-bounces at xymon.com>] On Behalf Of user-aada0fa38bf8@xymon.invalid<mailto:user-aada0fa38bf8@xymon.invalid>
Sent: Tuesday, February 17, 2015 10:22 AM
To: user-b8c0e0047c63@xymon.invalid<mailto:user-b8c0e0047c63@xymon.invalid>; user-834d44be5e50@xymon.invalid<mailto:user-834d44be5e50@xymon.invalid>; xymon at xymon.com<mailto:xymon at xymon.com>
Subject: Re: [Xymon] Xymon Powershell Windows client
Hi
I'm not sure I understand the question fully, I'm sure there will be other people on the list who can help.
The client runs as a Windows service and monitors the space and processes running on that one server. It then reports back those results every 5 minutes (by default) to the Xymon server.
If you're asking whether this client can be running on server 1 and monitor server 2, no, it cannot. As far as I know, Xymon is not really designed like that.
However, if each node is attached to shared storage, and the storage is presented as a mapped drive, then yes, it can monitor that. You'd need to use in the local config:
<wanteddisks>3 4</wanteddisks>
and use the update I committed earlier today.
Thanks
Zak
From: Dito [mailto:user-b8c0e0047c63@xymon.invalid]
Sent: 17 February 2015 13:53
To: Beck, Zak; user-834d44be5e50@xymon.invalid<mailto:user-834d44be5e50@xymon.invalid>; xymon at xymon.com<mailto:xymon at xymon.com>
Subject: Re: [Xymon] Xymon Powershell Windows client
can it be used in a MS cluster resource? can I monitor sql resource and space on it, independently of which node it is running on?
On Fri, Feb 13, 2015, 06:35 null <user-aada0fa38bf8@xymon.invalid<mailto:user-aada0fa38bf8@xymon.invalid>> wrote:
Hi all,
Today I have uploaded a new version of the Xymon Powershell client to SVN (in sandbox/WinPSClient). We (Accenture) are very pleased to be contributing these changes to the open source community. I've been working on this now for around 8 months on and off and hopefully the changes made will be of benefit to everyone!
Whilst making changes, we have focussed mainly on making it work, improving reliability and most importantly improving performance.
In most cases, on our 64 bit OS virtual machines, a data collection now takes around 5 seconds. On heavily loaded (CPU load or event log load) servers, the script is now considerably faster than originally. Key to this has been reducing the amount of WMI usage as this was a major culprit.
We have also implemented some new features, largely based on our in-house requirements but hopefully useful to others:
* Showing the process owner and command line in [procs]. This has been implemented using c# code, compiled at runtime.
* Adding Active Directory replication test, Terminal Services sessions test
* Ability to restart any stopped Windows service
* Client self-update
* Dirsize and dirtime checks (which were originally external scripts)
Some things have changed slightly; for example, the local configuration which was registry-based is now XML-based (you can still use registry settings if you prefer). In the SVN repository I have also uploaded a Word document which describes how to install and the configuration options.
I have uploaded all the revisions we have made to SVN so there is a history of development. Whilst we will endeavour to continue contributing changes and improvements in coming months, this is an open source project and as such we are not offering any formal support. If anyone wishes to bugfix, branch or whatever, please do so!
Zak Beck
Accenture
This message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, please note that you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by e-mail or by telephone at the above number. Thank you.
list Gavin Stone-Tolcher
Many many thanks for the quick fix for multiple servers. V1.97 is working OK now for me in this respect! I still am not seeing a windows MountPoint on my test Win 7 32bit client in the "disk" output with v1.97 and "wanteddisks" set to "3 4". Quickly looking at the client's code, it appears that "Get-WmiObject -Class Win32_LogicalDisk" is used to collect disk info? Several google clicks later, various sites seem to suggest windows MountPoint info is not really available using that class? e.g. http://learn-powershell.net/2012/08/10/locating-mount-points-using-powershell/ Another good site with code examples suggests using the "Win32_Volume" class to collect the info http://blogs.lessthandot.com/index.php/sysadmins/os/windows/getting-remote-mount-point-information/ While yet another site seems to be using the "Win32_MountPoint" class in his code to get MountPoint info from what I can see: http://www.powershelladmin.com/wiki/PowerShell_Get-MountPointData_Cmdlet#Showing_Used.2FFree_Space_On_Mount_Points I tried looking at the C++ code of winbb client but I'm afraid I can't make much sense of it. I am wondering if the "disk" code in the powershell client might need some tweaks to collect MountPoint info?
▸
Cheers, Gavin Stone-Tolcher, IT Support Officer, Network Operations and Incident Response Information Technology Services The University of Queensland Level 4, Prentice Building, St Lucia 4072 T: +61 7 334 66645, M: +61 401 140 838 E: user-6e44775a32e5@xymon.invalid<mailto:user-6e44775a32e5@xymon.invalid> W: www.its.uq.edu.au<http://www.its.uq.edu.au>; ITS: Service. Team. Accountability. Results. IMPORTANT: This email and any attachments are intended solely for the addressee(s), contain copyright material and are confidential. We do not waive any legal privilege or rights in respect of copyright or confidentiality. Except as intended addressees are otherwise permitted, you do not have permission to use, disclose, reproduce or communicate any part of this email or its attachments. Statements, opinions and information not related to the official business of The University of Queensland are neither given nor endorsed by us. By using this email (including accessing any attachments or links) you agree we are not liable for any loss or damage of any kind arising in connection with any electronic defect, virus or other malicious code we did not intentionally include. Please consider the environment before printing this email. CRICOS Code 00025B From: user-aada0fa38bf8@xymon.invalid [mailto:user-aada0fa38bf8@xymon.invalid] Sent: Tuesday, 17 February 2015 9:00 PM To: Gavin Stone-Tolcher; user-834d44be5e50@xymon.invalid; xymon at xymon.com Subject: RE: Xymon Powershell Windows client Hi Thanks for the bug report - I've committed a patch which should fix the multiple servers issue, please try it. There should be a single <servers> element in your config, containing the list of servers, space delimited: <servers>server1.domain.com server2.domain.com</servers> Re: mountpoints, if you add this to your XML config, you will get mountpoints. <wanteddisks>3 4</wanteddisks> By default, wanteddisks = 3 - possible settings below, and you can combine settings with spaces: 2=USB 3=Local disks 4=Network shares 5=CD But you will need the latest patch with the config fix for this to work properly. Regards, Zak From: Gavin Stone-Tolcher [mailto:user-6e44775a32e5@xymon.invalid] Sent: 17 February 2015 00:09 To: Beck, Zak; user-834d44be5e50@xymon.invalid; xymon at xymon.com Subject: RE: Xymon Powershell Windows client Just a quick FYI: I was just trying a test install on a 32bit windows 7 client and got this: Cannot set "servers" because only strings can be used as values to set XmlNode p At C:\Program Files\xymon\xymonclient.ps1:644 char:26 + $script:XymonSettings. <<<< servers = $script:XymonSettings.server + CategoryInfo : InvalidOperation: (:) [], RuntimeException + FullyQualifiedErrorId : PropertyAssignmentException I had multiple IP in the <servers> etry in the config. Changing the <servers> entry in xymonclient_config.xml to have a single entry rather than multiple whitespace entries allows the client to install with no error. After installation adding a second IP to <servers> entry also does not seem to work with it just reporting to the first entry? Also just another quick one, I have a mountpoint defined on this system that does not seem to be collected. Are mountpoints supported? I re-ran the bbwin client on the same system and the mountpoint is detected and displayed. Cheers, Gavin Stone-Tolcher, IT Support Officer, Network Operations and Incident Response Information Technology Services The University of Queensland Level 4, Prentice Building, St Lucia 4072 T: +61 7 334 66645, M: +61 401 140 838 E: user-6e44775a32e5@xymon.invalid<mailto:user-6e44775a32e5@xymon.invalid> W: www.its.uq.edu.au<http://www.its.uq.edu.au>; ITS: Service. Team. Accountability. Results. IMPORTANT: This email and any attachments are intended solely for the addressee(s), contain copyright material and are confidential. We do not waive any legal privilege or rights in respect of copyright or confidentiality. Except as intended addressees are otherwise permitted, you do not have permission to use, disclose, reproduce or communicate any part of this email or its attachments. Statements, opinions and information not related to the official business of The University of Queensland are neither given nor endorsed by us. By using this email (including accessing any attachments or links) you agree we are not liable for any loss or damage of any kind arising in connection with any electronic defect, virus or other malicious code we did not intentionally include. Please consider the environment before printing this email. CRICOS Code 00025B From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of user-aada0fa38bf8@xymon.invalid<mailto:user-aada0fa38bf8@xymon.invalid> Sent: Friday, 13 February 2015 7:53 PM To: user-834d44be5e50@xymon.invalid<mailto:user-834d44be5e50@xymon.invalid>; xymon at xymon.com<mailto:xymon at xymon.com> Subject: [Xymon] Xymon Powershell Windows client Hi all, Today I have uploaded a new version of the Xymon Powershell client to SVN (in sandbox/WinPSClient). We (Accenture) are very pleased to be contributing these changes to the open source community. I've been working on this now for around 8 months on and off and hopefully the changes made will be of benefit to everyone! Whilst making changes, we have focussed mainly on making it work, improving reliability and most importantly improving performance. In most cases, on our 64 bit OS virtual machines, a data collection now takes around 5 seconds. On heavily loaded (CPU load or event log load) servers, the script is now considerably faster than originally. Key to this has been reducing the amount of WMI usage as this was a major culprit. We have also implemented some new features, largely based on our in-house requirements but hopefully useful to others: * Showing the process owner and command line in [procs]. This has been implemented using c# code, compiled at runtime. * Adding Active Directory replication test, Terminal Services sessions test * Ability to restart any stopped Windows service * Client self-update * Dirsize and dirtime checks (which were originally external scripts) Some things have changed slightly; for example, the local configuration which was registry-based is now XML-based (you can still use registry settings if you prefer). In the SVN repository I have also uploaded a Word document which describes how to install and the configuration options. I have uploaded all the revisions we have made to SVN so there is a history of development. Whilst we will endeavour to continue contributing changes and improvements in coming months, this is an open source project and as such we are not offering any formal support. If anyone wishes to bugfix, branch or whatever, please do so! Zak Beck Accenture
list Scot Kreienkamp
With the latest version I get "Property 'serversList' cannot be found on this object;". If I change servers to serversList it seems to work ok. If it really did change to serversList you should update the doc or everyone that tries to install it will be emailing you. :)
▸
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of user-aada0fa38bf8@xymon.invalid Sent: Tuesday, February 17, 2015 6:00 AM To: user-6e44775a32e5@xymon.invalid; user-834d44be5e50@xymon.invalid; xymon at xymon.com Subject: Re: [Xymon] Xymon Powershell Windows client Hi Thanks for the bug report - I've committed a patch which should fix the multiple servers issue, please try it. There should be a single <servers> element in your config, containing the list of servers, space delimited: <servers>server1.domain.com server2.domain.com</servers> Re: mountpoints, if you add this to your XML config, you will get mountpoints. <wanteddisks>3 4</wanteddisks> By default, wanteddisks = 3 - possible settings below, and you can combine settings with spaces: 2=USB 3=Local disks 4=Network shares 5=CD But you will need the latest patch with the config fix for this to work properly. Regards, Zak From: Gavin Stone-Tolcher [mailto:user-6e44775a32e5@xymon.invalid] Sent: 17 February 2015 00:09 To: Beck, Zak; user-834d44be5e50@xymon.invalid<mailto:user-834d44be5e50@xymon.invalid>; xymon at xymon.com<mailto:xymon at xymon.com> Subject: RE: Xymon Powershell Windows client Just a quick FYI: I was just trying a test install on a 32bit windows 7 client and got this: Cannot set "servers" because only strings can be used as values to set XmlNode p At C:\Program Files\xymon\xymonclient.ps1:644 char:26 + $script:XymonSettings. <<<< servers = $script:XymonSettings.server + CategoryInfo : InvalidOperation: (:) [], RuntimeException + FullyQualifiedErrorId : PropertyAssignmentException I had multiple IP in the <servers> etry in the config. Changing the <servers> entry in xymonclient_config.xml to have a single entry rather than multiple whitespace entries allows the client to install with no error. After installation adding a second IP to <servers> entry also does not seem to work with it just reporting to the first entry? Also just another quick one, I have a mountpoint defined on this system that does not seem to be collected. Are mountpoints supported? I re-ran the bbwin client on the same system and the mountpoint is detected and displayed. Cheers, Gavin Stone-Tolcher, IT Support Officer, Network Operations and Incident Response Information Technology Services The University of Queensland Level 4, Prentice Building, St Lucia 4072 T: +61 7 334 66645, M: +61 401 140 838 E: user-6e44775a32e5@xymon.invalid<mailto:user-6e44775a32e5@xymon.invalid> W: www.its.uq.edu.au<http://www.its.uq.edu.au>; ITS: Service. Team. Accountability. Results. IMPORTANT: This email and any attachments are intended solely for the addressee(s), contain copyright material and are confidential. We do not waive any legal privilege or rights in respect of copyright or confidentiality. Except as intended addressees are otherwise permitted, you do not have permission to use, disclose, reproduce or communicate any part of this email or its attachments. Statements, opinions and information not related to the official business of The University of Queensland are neither given nor endorsed by us. By using this email (including accessing any attachments or links) you agree we are not liable for any loss or damage of any kind arising in connection with any electronic defect, virus or other malicious code we did not intentionally include. Please consider the environment before printing this email. CRICOS Code 00025B From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of user-aada0fa38bf8@xymon.invalid<mailto:user-aada0fa38bf8@xymon.invalid> Sent: Friday, 13 February 2015 7:53 PM To: user-834d44be5e50@xymon.invalid<mailto:user-834d44be5e50@xymon.invalid>; xymon at xymon.com<mailto:xymon at xymon.com> Subject: [Xymon] Xymon Powershell Windows client Hi all, Today I have uploaded a new version of the Xymon Powershell client to SVN (in sandbox/WinPSClient). We (Accenture) are very pleased to be contributing these changes to the open source community. I've been working on this now for around 8 months on and off and hopefully the changes made will be of benefit to everyone! Whilst making changes, we have focussed mainly on making it work, improving reliability and most importantly improving performance. In most cases, on our 64 bit OS virtual machines, a data collection now takes around 5 seconds. On heavily loaded (CPU load or event log load) servers, the script is now considerably faster than originally. Key to this has been reducing the amount of WMI usage as this was a major culprit. We have also implemented some new features, largely based on our in-house requirements but hopefully useful to others: * Showing the process owner and command line in [procs]. This has been implemented using c# code, compiled at runtime. * Adding Active Directory replication test, Terminal Services sessions test * Ability to restart any stopped Windows service * Client self-update * Dirsize and dirtime checks (which were originally external scripts) Some things have changed slightly; for example, the local configuration which was registry-based is now XML-based (you can still use registry settings if you prefer). In the SVN repository I have also uploaded a Word document which describes how to install and the configuration options. I have uploaded all the revisions we have made to SVN so there is a history of development. Whilst we will endeavour to continue contributing changes and improvements in coming months, this is an open source project and as such we are not offering any formal support. If anyone wishes to bugfix, branch or whatever, please do so! Zak Beck Accenture This message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, please note that you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by e-mail or by telephone at the above number. Thank you.
list Gavin Stone-Tolcher
I am wondering if the "disk" code in the powershell client might need some tweaks to collect MountPoint info?
For reference to client data chunks for the different clients are: Powershell v1.97: [disk] Filesystem 1K-blocks Used Avail Capacity Mounted Summary(Total\Avail GB) C 104753148 42705800 62047348 41% /FIXED/C 99.90\59.17 Bbwin v0.13 [disk] Filesystem 1K-blocks Used Avail Capacity Total Size Free Space Type Mount Point C 104753148 42706904 62046244 40% 99.90 GB 59.17 GB FIXED N/A MountPointTest 104753148 42706904 62046244 40% 99.90 GB 59.17 GB FIXED C:\MountPointTest\
▸
Cheers, Gavin Stone-Tolcher, IT Support Officer, Network Operations and Incident Response Information Technology Services The University of Queensland Level 4, Prentice Building, St Lucia 4072 T: +61 7 334 66645, M: +61 401 140 838 E: user-6e44775a32e5@xymon.invalid<mailto:user-6e44775a32e5@xymon.invalid> W: www.its.uq.edu.au<http://www.its.uq.edu.au>; ITS: Service. Team. Accountability. Results. IMPORTANT: This email and any attachments are intended solely for the addressee(s), contain copyright material and are confidential. We do not waive any legal privilege or rights in respect of copyright or confidentiality. Except as intended addressees are otherwise permitted, you do not have permission to use, disclose, reproduce or communicate any part of this email or its attachments. Statements, opinions and information not related to the official business of The University of Queensland are neither given nor endorsed by us. By using this email (including accessing any attachments or links) you agree we are not liable for any loss or damage of any kind arising in connection with any electronic defect, virus or other malicious code we did not intentionally include. Please consider the environment before printing this email. CRICOS Code 00025B From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Gavin Stone-Tolcher Sent: Wednesday, 18 February 2015 11:19 AM To: 'user-aada0fa38bf8@xymon.invalid'; user-834d44be5e50@xymon.invalid; xymon at xymon.com Subject: Re: [Xymon] Xymon Powershell Windows client Many many thanks for the quick fix for multiple servers. V1.97 is working OK now for me in this respect! I still am not seeing a windows MountPoint on my test Win 7 32bit client in the "disk" output with v1.97 and "wanteddisks" set to "3 4". Quickly looking at the client's code, it appears that "Get-WmiObject -Class Win32_LogicalDisk" is used to collect disk info? Several google clicks later, various sites seem to suggest windows MountPoint info is not really available using that class? e.g. http://learn-powershell.net/2012/08/10/locating-mount-points-using-powershell/ Another good site with code examples suggests using the "Win32_Volume" class to collect the info http://blogs.lessthandot.com/index.php/sysadmins/os/windows/getting-remote-mount-point-information/ While yet another site seems to be using the "Win32_MountPoint" class in his code to get MountPoint info from what I can see: http://www.powershelladmin.com/wiki/PowerShell_Get-MountPointData_Cmdlet#Showing_Used.2FFree_Space_On_Mount_Points I tried looking at the C++ code of winbb client but I'm afraid I can't make much sense of it. I am wondering if the "disk" code in the powershell client might need some tweaks to collect MountPoint info? Cheers, Gavin Stone-Tolcher, IT Support Officer, Network Operations and Incident Response Information Technology Services The University of Queensland Level 4, Prentice Building, St Lucia 4072 T: +61 7 334 66645, M: +61 401 140 838 E: user-6e44775a32e5@xymon.invalid<mailto:user-6e44775a32e5@xymon.invalid> W: www.its.uq.edu.au<http://www.its.uq.edu.au>; ITS: Service. Team. Accountability. Results. IMPORTANT: This email and any attachments are intended solely for the addressee(s), contain copyright material and are confidential. We do not waive any legal privilege or rights in respect of copyright or confidentiality. Except as intended addressees are otherwise permitted, you do not have permission to use, disclose, reproduce or communicate any part of this email or its attachments. Statements, opinions and information not related to the official business of The University of Queensland are neither given nor endorsed by us. By using this email (including accessing any attachments or links) you agree we are not liable for any loss or damage of any kind arising in connection with any electronic defect, virus or other malicious code we did not intentionally include. Please consider the environment before printing this email. CRICOS Code 00025B From: user-aada0fa38bf8@xymon.invalid [mailto:user-aada0fa38bf8@xymon.invalid] Sent: Tuesday, 17 February 2015 9:00 PM To: Gavin Stone-Tolcher; user-834d44be5e50@xymon.invalid; xymon at xymon.com Subject: RE: Xymon Powershell Windows client Hi Thanks for the bug report - I've committed a patch which should fix the multiple servers issue, please try it. There should be a single <servers> element in your config, containing the list of servers, space delimited: <servers>server1.domain.com server2.domain.com</servers> Re: mountpoints, if you add this to your XML config, you will get mountpoints. <wanteddisks>3 4</wanteddisks> By default, wanteddisks = 3 - possible settings below, and you can combine settings with spaces: 2=USB 3=Local disks 4=Network shares 5=CD But you will need the latest patch with the config fix for this to work properly. Regards, Zak From: Gavin Stone-Tolcher [mailto:user-6e44775a32e5@xymon.invalid] Sent: 17 February 2015 00:09 To: Beck, Zak; user-834d44be5e50@xymon.invalid; xymon at xymon.com Subject: RE: Xymon Powershell Windows client Just a quick FYI: I was just trying a test install on a 32bit windows 7 client and got this: Cannot set "servers" because only strings can be used as values to set XmlNode p At C:\Program Files\xymon\xymonclient.ps1:644 char:26 + $script:XymonSettings. <<<< servers = $script:XymonSettings.server + CategoryInfo : InvalidOperation: (:) [], RuntimeException + FullyQualifiedErrorId : PropertyAssignmentException I had multiple IP in the <servers> etry in the config. Changing the <servers> entry in xymonclient_config.xml to have a single entry rather than multiple whitespace entries allows the client to install with no error. After installation adding a second IP to <servers> entry also does not seem to work with it just reporting to the first entry? Also just another quick one, I have a mountpoint defined on this system that does not seem to be collected. Are mountpoints supported? I re-ran the bbwin client on the same system and the mountpoint is detected and displayed. Cheers, Gavin Stone-Tolcher, IT Support Officer, Network Operations and Incident Response Information Technology Services The University of Queensland Level 4, Prentice Building, St Lucia 4072 T: +61 7 334 66645, M: +61 401 140 838 E: user-6e44775a32e5@xymon.invalid<mailto:user-6e44775a32e5@xymon.invalid> W: www.its.uq.edu.au<http://www.its.uq.edu.au>; ITS: Service. Team. Accountability. Results. IMPORTANT: This email and any attachments are intended solely for the addressee(s), contain copyright material and are confidential. We do not waive any legal privilege or rights in respect of copyright or confidentiality. Except as intended addressees are otherwise permitted, you do not have permission to use, disclose, reproduce or communicate any part of this email or its attachments. Statements, opinions and information not related to the official business of The University of Queensland are neither given nor endorsed by us. By using this email (including accessing any attachments or links) you agree we are not liable for any loss or damage of any kind arising in connection with any electronic defect, virus or other malicious code we did not intentionally include. Please consider the environment before printing this email. CRICOS Code 00025B From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of user-aada0fa38bf8@xymon.invalid<mailto:user-aada0fa38bf8@xymon.invalid> Sent: Friday, 13 February 2015 7:53 PM To: user-834d44be5e50@xymon.invalid<mailto:user-834d44be5e50@xymon.invalid>; xymon at xymon.com<mailto:xymon at xymon.com> Subject: [Xymon] Xymon Powershell Windows client Hi all, Today I have uploaded a new version of the Xymon Powershell client to SVN (in sandbox/WinPSClient). We (Accenture) are very pleased to be contributing these changes to the open source community. I've been working on this now for around 8 months on and off and hopefully the changes made will be of benefit to everyone! Whilst making changes, we have focussed mainly on making it work, improving reliability and most importantly improving performance. In most cases, on our 64 bit OS virtual machines, a data collection now takes around 5 seconds. On heavily loaded (CPU load or event log load) servers, the script is now considerably faster than originally. Key to this has been reducing the amount of WMI usage as this was a major culprit. We have also implemented some new features, largely based on our in-house requirements but hopefully useful to others: * Showing the process owner and command line in [procs]. This has been implemented using c# code, compiled at runtime. * Adding Active Directory replication test, Terminal Services sessions test * Ability to restart any stopped Windows service * Client self-update * Dirsize and dirtime checks (which were originally external scripts) Some things have changed slightly; for example, the local configuration which was registry-based is now XML-based (you can still use registry settings if you prefer). In the SVN repository I have also uploaded a Word document which describes how to install and the configuration options. I have uploaded all the revisions we have made to SVN so there is a history of development. Whilst we will endeavour to continue contributing changes and improvements in coming months, this is an open source project and as such we are not offering any formal support. If anyone wishes to bugfix, branch or whatever, please do so! Zak Beck Accenture
list Gavin Stone-Tolcher
After searching through the mailing list, it seems that someone may have already produced code to get mountpoint info, see attached and:
I´ve already modified the winPSclient to consider the mountpoints and If I use this client I have all the graphs created without any problem.
I have asked the author off list if the code is public. Of course I am assuming that the v1.97 code is not pulling in the info on my win 7 32bit VM with PS 4. Has anyone else seen windows MountPoints being reported for the disk test with the new Powershell client v1.97?
▸
Cheers, Gavin Stone-Tolcher, IT Support Officer, Network Operations and Incident Response Information Technology Services The University of Queensland Level 4, Prentice Building, St Lucia 4072 T: +61 7 334 66645, M: +61 401 140 838 E: user-6e44775a32e5@xymon.invalid<mailto:user-6e44775a32e5@xymon.invalid> W: www.its.uq.edu.au<http://www.its.uq.edu.au>; ITS: Service. Team. Accountability. Results. IMPORTANT: This email and any attachments are intended solely for the addressee(s), contain copyright material and are confidential. We do not waive any legal privilege or rights in respect of copyright or confidentiality. Except as intended addressees are otherwise permitted, you do not have permission to use, disclose, reproduce or communicate any part of this email or its attachments. Statements, opinions and information not related to the official business of The University of Queensland are neither given nor endorsed by us. By using this email (including accessing any attachments or links) you agree we are not liable for any loss or damage of any kind arising in connection with any electronic defect, virus or other malicious code we did not intentionally include. Please consider the environment before printing this email. CRICOS Code 00025B From: Gavin Stone-Tolcher Sent: Wednesday, 18 February 2015 1:54 PM To: Gavin Stone-Tolcher; 'user-aada0fa38bf8@xymon.invalid'; xymon at xymon.com Subject: RE: Xymon Powershell Windows client
I am wondering if the "disk" code in the powershell client might need some tweaks to collect MountPoint info?
For reference to client data chunks for the different clients are: Powershell v1.97: [disk] Filesystem 1K-blocks Used Avail Capacity Mounted Summary(Total\Avail GB) C 104753148 42705800 62047348 41% /FIXED/C 99.90\59.17 Bbwin v0.13 [disk] Filesystem 1K-blocks Used Avail Capacity Total Size Free Space Type Mount Point C 104753148 42706904 62046244 40% 99.90 GB 59.17 GB FIXED N/A MountPointTest 104753148 42706904 62046244 40% 99.90 GB 59.17 GB FIXED C:\MountPointTest\ Cheers, Gavin Stone-Tolcher, IT Support Officer, Network Operations and Incident Response Information Technology Services The University of Queensland Level 4, Prentice Building, St Lucia 4072 T: +61 7 334 66645, M: +61 401 140 838 E: user-6e44775a32e5@xymon.invalid<mailto:user-6e44775a32e5@xymon.invalid> W: www.its.uq.edu.au<http://www.its.uq.edu.au>; ITS: Service. Team. Accountability. Results. IMPORTANT: This email and any attachments are intended solely for the addressee(s), contain copyright material and are confidential. We do not waive any legal privilege or rights in respect of copyright or confidentiality. Except as intended addressees are otherwise permitted, you do not have permission to use, disclose, reproduce or communicate any part of this email or its attachments. Statements, opinions and information not related to the official business of The University of Queensland are neither given nor endorsed by us. By using this email (including accessing any attachments or links) you agree we are not liable for any loss or damage of any kind arising in connection with any electronic defect, virus or other malicious code we did not intentionally include. Please consider the environment before printing this email. CRICOS Code 00025B From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Gavin Stone-Tolcher Sent: Wednesday, 18 February 2015 11:19 AM To: 'user-aada0fa38bf8@xymon.invalid'; user-834d44be5e50@xymon.invalid; xymon at xymon.com Subject: Re: [Xymon] Xymon Powershell Windows client Many many thanks for the quick fix for multiple servers. V1.97 is working OK now for me in this respect! I still am not seeing a windows MountPoint on my test Win 7 32bit client in the "disk" output with v1.97 and "wanteddisks" set to "3 4". Quickly looking at the client's code, it appears that "Get-WmiObject -Class Win32_LogicalDisk" is used to collect disk info? Several google clicks later, various sites seem to suggest windows MountPoint info is not really available using that class? e.g. http://learn-powershell.net/2012/08/10/locating-mount-points-using-powershell/ Another good site with code examples suggests using the "Win32_Volume" class to collect the info http://blogs.lessthandot.com/index.php/sysadmins/os/windows/getting-remote-mount-point-information/ While yet another site seems to be using the "Win32_MountPoint" class in his code to get MountPoint info from what I can see: http://www.powershelladmin.com/wiki/PowerShell_Get-MountPointData_Cmdlet#Showing_Used.2FFree_Space_On_Mount_Points I tried looking at the C++ code of winbb client but I'm afraid I can't make much sense of it. I am wondering if the "disk" code in the powershell client might need some tweaks to collect MountPoint info? Cheers, Gavin Stone-Tolcher, IT Support Officer, Network Operations and Incident Response Information Technology Services The University of Queensland Level 4, Prentice Building, St Lucia 4072 T: +61 7 334 66645, M: +61 401 140 838 E: user-6e44775a32e5@xymon.invalid<mailto:user-6e44775a32e5@xymon.invalid> W: www.its.uq.edu.au<http://www.its.uq.edu.au>; ITS: Service. Team. Accountability. Results. IMPORTANT: This email and any attachments are intended solely for the addressee(s), contain copyright material and are confidential. We do not waive any legal privilege or rights in respect of copyright or confidentiality. Except as intended addressees are otherwise permitted, you do not have permission to use, disclose, reproduce or communicate any part of this email or its attachments. Statements, opinions and information not related to the official business of The University of Queensland are neither given nor endorsed by us. By using this email (including accessing any attachments or links) you agree we are not liable for any loss or damage of any kind arising in connection with any electronic defect, virus or other malicious code we did not intentionally include. Please consider the environment before printing this email. CRICOS Code 00025B From: user-aada0fa38bf8@xymon.invalid [mailto:user-aada0fa38bf8@xymon.invalid] Sent: Tuesday, 17 February 2015 9:00 PM To: Gavin Stone-Tolcher; user-834d44be5e50@xymon.invalid; xymon at xymon.com Subject: RE: Xymon Powershell Windows client Hi Thanks for the bug report - I've committed a patch which should fix the multiple servers issue, please try it. There should be a single <servers> element in your config, containing the list of servers, space delimited: <servers>server1.domain.com server2.domain.com</servers> Re: mountpoints, if you add this to your XML config, you will get mountpoints. <wanteddisks>3 4</wanteddisks> By default, wanteddisks = 3 - possible settings below, and you can combine settings with spaces: 2=USB 3=Local disks 4=Network shares 5=CD But you will need the latest patch with the config fix for this to work properly. Regards, Zak From: Gavin Stone-Tolcher [mailto:user-6e44775a32e5@xymon.invalid] Sent: 17 February 2015 00:09 To: Beck, Zak; user-834d44be5e50@xymon.invalid; xymon at xymon.com Subject: RE: Xymon Powershell Windows client Just a quick FYI: I was just trying a test install on a 32bit windows 7 client and got this: Cannot set "servers" because only strings can be used as values to set XmlNode p At C:\Program Files\xymon\xymonclient.ps1:644 char:26 + $script:XymonSettings. <<<< servers = $script:XymonSettings.server + CategoryInfo : InvalidOperation: (:) [], RuntimeException + FullyQualifiedErrorId : PropertyAssignmentException I had multiple IP in the <servers> etry in the config. Changing the <servers> entry in xymonclient_config.xml to have a single entry rather than multiple whitespace entries allows the client to install with no error. After installation adding a second IP to <servers> entry also does not seem to work with it just reporting to the first entry? Also just another quick one, I have a mountpoint defined on this system that does not seem to be collected. Are mountpoints supported? I re-ran the bbwin client on the same system and the mountpoint is detected and displayed. Cheers, Gavin Stone-Tolcher, IT Support Officer, Network Operations and Incident Response Information Technology Services The University of Queensland Level 4, Prentice Building, St Lucia 4072 T: +61 7 334 66645, M: +61 401 140 838 E: user-6e44775a32e5@xymon.invalid<mailto:user-6e44775a32e5@xymon.invalid> W: www.its.uq.edu.au<http://www.its.uq.edu.au>; ITS: Service. Team. Accountability. Results. IMPORTANT: This email and any attachments are intended solely for the addressee(s), contain copyright material and are confidential. We do not waive any legal privilege or rights in respect of copyright or confidentiality. Except as intended addressees are otherwise permitted, you do not have permission to use, disclose, reproduce or communicate any part of this email or its attachments. Statements, opinions and information not related to the official business of The University of Queensland are neither given nor endorsed by us. By using this email (including accessing any attachments or links) you agree we are not liable for any loss or damage of any kind arising in connection with any electronic defect, virus or other malicious code we did not intentionally include. Please consider the environment before printing this email. CRICOS Code 00025B From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of user-aada0fa38bf8@xymon.invalid<mailto:user-aada0fa38bf8@xymon.invalid> Sent: Friday, 13 February 2015 7:53 PM To: user-834d44be5e50@xymon.invalid<mailto:user-834d44be5e50@xymon.invalid>; xymon at xymon.com<mailto:xymon at xymon.com> Subject: [Xymon] Xymon Powershell Windows client Hi all, Today I have uploaded a new version of the Xymon Powershell client to SVN (in sandbox/WinPSClient). We (Accenture) are very pleased to be contributing these changes to the open source community. I've been working on this now for around 8 months on and off and hopefully the changes made will be of benefit to everyone! Whilst making changes, we have focussed mainly on making it work, improving reliability and most importantly improving performance. In most cases, on our 64 bit OS virtual machines, a data collection now takes around 5 seconds. On heavily loaded (CPU load or event log load) servers, the script is now considerably faster than originally. Key to this has been reducing the amount of WMI usage as this was a major culprit. We have also implemented some new features, largely based on our in-house requirements but hopefully useful to others: · Showing the process owner and command line in [procs]. This has been implemented using c# code, compiled at runtime. · Adding Active Directory replication test, Terminal Services sessions test · Ability to restart any stopped Windows service · Client self-update · Dirsize and dirtime checks (which were originally external scripts) Some things have changed slightly; for example, the local configuration which was registry-based is now XML-based (you can still use registry settings if you prefer). In the SVN repository I have also uploaded a Word document which describes how to install and the configuration options. I have uploaded all the revisions we have made to SVN so there is a history of development. Whilst we will endeavour to continue contributing changes and improvements in coming months, this is an open source project and as such we are not offering any formal support. If anyone wishes to bugfix, branch or whatever, please do so! Zak Beck Accenture
list Zak Beck
Hmm, I think this might be a difference between different versions of Powershell. I think this is why it works for Gavin but not you, Scot. I could replicate your error on Powershell 2; I've committed a new revision which I have tested on Powershell 2 and Powershell 4. The intended usage is <servers> per my original email. Also, multiple <servers> elements containing one IP/FQDN per element should also work. Zak
▸
From: Scot Kreienkamp [mailto:user-9678697f1438@xymon.invalid]
Sent: 18 February 2015 03:16
To: Beck, Zak; user-6e44775a32e5@xymon.invalid;
user-834d44be5e50@xymon.invalid; xymon at xymon.com
Subject: RE: Xymon Powershell Windows client
With the latest version I get "Property 'serversList' cannot be found on
this object;". If I change servers to serversList it seems to work ok.
If it really did change to serversList you should update the doc or everyone
that tries to install it will be emailing you. :)
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of
user-aada0fa38bf8@xymon.invalid <mailto:user-aada0fa38bf8@xymon.invalid>
Sent: Tuesday, February 17, 2015 6:00 AM
To: user-6e44775a32e5@xymon.invalid <mailto:user-6e44775a32e5@xymon.invalid> ;
▸
user-834d44be5e50@xymon.invalid <mailto:user-834d44be5e50@xymon.invalid> ; xymon at xymon.com <mailto:xymon at xymon.com> Subject: Re: [Xymon] Xymon Powershell Windows client Hi Thanks for the bug report - I've committed a patch which should fix the multiple servers issue, please try it. There should be a single <servers> element in your config, containing the list of servers, space delimited: <servers>server1.domain.com server2.domain.com</servers> Re: mountpoints, if you add this to your XML config, you will get mountpoints. <wanteddisks>3 4</wanteddisks> By default, wanteddisks = 3 - possible settings below, and you can combine settings with spaces: 2=USB 3=Local disks 4=Network shares 5=CD But you will need the latest patch with the config fix for this to work properly. Regards, Zak From: Gavin Stone-Tolcher [mailto:user-6e44775a32e5@xymon.invalid] Sent: 17 February 2015 00:09 To: Beck, Zak; user-834d44be5e50@xymon.invalid <mailto:user-834d44be5e50@xymon.invalid> ; xymon at xymon.com <mailto:xymon at xymon.com> Subject: RE: Xymon Powershell Windows client Just a quick FYI: I was just trying a test install on a 32bit windows 7 client and got this: Cannot set "servers" because only strings can be used as values to set XmlNode p At C:\Program Files\xymon\xymonclient.ps1:644 char:26 + $script:XymonSettings. <<<< servers = $script:XymonSettings.server + CategoryInfo : InvalidOperation: (:) [], RuntimeException + FullyQualifiedErrorId : PropertyAssignmentException I had multiple IP in the <servers> etry in the config. Changing the <servers> entry in xymonclient_config.xml to have a single entry rather than multiple whitespace entries allows the client to install with no error. After installation adding a second IP to <servers> entry also does not seem to work with it just reporting to the first entry? Also just another quick one, I have a mountpoint defined on this system that does not seem to be collected. Are mountpoints supported? I re-ran the bbwin client on the same system and the mountpoint is detected and displayed. Cheers, Gavin Stone-Tolcher, IT Support Officer, Network Operations and Incident Response Information Technology Services The University of Queensland Level 4, Prentice Building, St Lucia 4072 T: +61 7 334 66645, M: +61 401 140 838 E: <mailto:user-6e44775a32e5@xymon.invalid> user-6e44775a32e5@xymon.invalid W: <http://www.its.uq.edu.au>; www.its.uq.edu.au ITS: Service. Team. Accountability. Results. IMPORTANT: This email and any attachments are intended solely for the addressee(s), contain copyright material and are confidential. We do not waive any legal privilege or rights in respect of copyright or confidentiality. Except as intended addressees are otherwise permitted, you do not have permission to use, disclose, reproduce or communicate any part of this email or its attachments. Statements, opinions and information not related to the official business of The University of Queensland are neither given nor endorsed by us. By using this email (including accessing any attachments or links) you agree we are not liable for any loss or damage of any kind arising in connection with any electronic defect, virus or other malicious code we did not intentionally include. Please consider the environment before printing this email. CRICOS Code 00025B From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of user-aada0fa38bf8@xymon.invalid <mailto:user-aada0fa38bf8@xymon.invalid> Sent: Friday, 13 February 2015 7:53 PM To: user-834d44be5e50@xymon.invalid <mailto:user-834d44be5e50@xymon.invalid> ; xymon at xymon.com <mailto:xymon at xymon.com> Subject: [Xymon] Xymon Powershell Windows client Hi all, Today I have uploaded a new version of the Xymon Powershell client to SVN (in sandbox/WinPSClient). We (Accenture) are very pleased to be contributing these changes to the open source community. I've been working on this now for around 8 months on and off and hopefully the changes made will be of benefit to everyone! Whilst making changes, we have focussed mainly on making it work, improving reliability and most importantly improving performance. In most cases, on our 64 bit OS virtual machines, a data collection now takes around 5 seconds. On heavily loaded (CPU load or event log load) servers, the script is now considerably faster than originally. Key to this has been reducing the amount of WMI usage as this was a major culprit. We have also implemented some new features, largely based on our in-house requirements but hopefully useful to others: * Showing the process owner and command line in [procs]. This has been implemented using c# code, compiled at runtime. * Adding Active Directory replication test, Terminal Services sessions test * Ability to restart any stopped Windows service * Client self-update * Dirsize and dirtime checks (which were originally external scripts) Some things have changed slightly; for example, the local configuration which was registry-based is now XML-based (you can still use registry settings if you prefer). In the SVN repository I have also uploaded a Word document which describes how to install and the configuration options. I have uploaded all the revisions we have made to SVN so there is a history of development. Whilst we will endeavour to continue contributing changes and improvements in coming months, this is an open source project and as such we are not offering any formal support. If anyone wishes to bugfix, branch or whatever, please do so! Zak Beck Accenture This message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, please note that you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by e-mail or by telephone at the above number. Thank you.
list Zak Beck
Thanks for the mountpoint info, I'll need to look at this in some detail. I'll put it on the todo list.
▸
Zak
From: Gavin Stone-Tolcher [mailto:user-6e44775a32e5@xymon.invalid]
Sent: 18 February 2015 01:19
To: Beck, Zak; user-834d44be5e50@xymon.invalid; xymon at xymon.com
Subject: RE: Xymon Powershell Windows client
Many many thanks for the quick fix for multiple servers. V1.97 is working OK
now for me in this respect!
I still am not seeing a windows MountPoint on my test Win 7 32bit client in
the "disk" output with v1.97 and "wanteddisks" set to "3 4".
Quickly looking at the client's code, it appears that "Get-WmiObject -Class
Win32_LogicalDisk" is used to collect disk info?
Several google clicks later, various sites seem to suggest windows
MountPoint info is not really available using that class?
e.g.
http://learn-powershell.net/2012/08/10/locating-mount-points-using-powershel l/
▸
Another good site with code examples suggests using the "Win32_Volume" class
to collect the info
http://blogs.lessthandot.com/index.php/sysadmins/os/windows/getting-remote-m ount-point-information/
▸
While yet another site seems to be using the "Win32_MountPoint" class in his
code to get MountPoint info from what I can see:
http://www.powershelladmin.com/wiki/PowerShell_Get-MountPointData_Cmdlet#Sho wing_Used.2FFree_Space_On_Mount_Points
▸
I tried looking at the C++ code of winbb client but I'm afraid I can't make much sense of it. I am wondering if the "disk" code in the powershell client might need some tweaks to collect MountPoint info? Cheers, Gavin Stone-Tolcher, IT Support Officer, Network Operations and Incident Response Information Technology Services The University of Queensland Level 4, Prentice Building, St Lucia 4072 T: +61 7 334 66645, M: +61 401 140 838 E: <mailto:user-6e44775a32e5@xymon.invalid> user-6e44775a32e5@xymon.invalid W: <http://www.its.uq.edu.au>; www.its.uq.edu.au ITS: Service. Team. Accountability. Results. IMPORTANT: This email and any attachments are intended solely for the addressee(s), contain copyright material and are confidential. We do not waive any legal privilege or rights in respect of copyright or confidentiality. Except as intended addressees are otherwise permitted, you do not have permission to use, disclose, reproduce or communicate any part of this email or its attachments. Statements, opinions and information not related to the official business of The University of Queensland are neither given nor endorsed by us. By using this email (including accessing any attachments or links) you agree we are not liable for any loss or damage of any kind arising in connection with any electronic defect, virus or other malicious code we did not intentionally include. Please consider the environment before printing this email. CRICOS Code 00025B From: user-aada0fa38bf8@xymon.invalid <mailto:user-aada0fa38bf8@xymon.invalid> [mailto:user-aada0fa38bf8@xymon.invalid] Sent: Tuesday, 17 February 2015 9:00 PM To: Gavin Stone-Tolcher; user-834d44be5e50@xymon.invalid <mailto:user-834d44be5e50@xymon.invalid> ; xymon at xymon.com <mailto:xymon at xymon.com> Subject: RE: Xymon Powershell Windows client Hi Thanks for the bug report - I've committed a patch which should fix the multiple servers issue, please try it. There should be a single <servers> element in your config, containing the list of servers, space delimited: <servers>server1.domain.com server2.domain.com</servers> Re: mountpoints, if you add this to your XML config, you will get mountpoints. <wanteddisks>3 4</wanteddisks> By default, wanteddisks = 3 - possible settings below, and you can combine settings with spaces: 2=USB 3=Local disks 4=Network shares 5=CD But you will need the latest patch with the config fix for this to work properly. Regards, Zak From: Gavin Stone-Tolcher [mailto:user-6e44775a32e5@xymon.invalid] Sent: 17 February 2015 00:09 To: Beck, Zak; user-834d44be5e50@xymon.invalid <mailto:user-834d44be5e50@xymon.invalid> ; xymon at xymon.com <mailto:xymon at xymon.com> Subject: RE: Xymon Powershell Windows client Just a quick FYI: I was just trying a test install on a 32bit windows 7 client and got this: Cannot set "servers" because only strings can be used as values to set XmlNode p At C:\Program Files\xymon\xymonclient.ps1:644 char:26 + $script:XymonSettings. <<<< servers = $script:XymonSettings.server + CategoryInfo : InvalidOperation: (:) [], RuntimeException + FullyQualifiedErrorId : PropertyAssignmentException I had multiple IP in the <servers> etry in the config. Changing the <servers> entry in xymonclient_config.xml to have a single entry rather than multiple whitespace entries allows the client to install with no error. After installation adding a second IP to <servers> entry also does not seem to work with it just reporting to the first entry? Also just another quick one, I have a mountpoint defined on this system that does not seem to be collected. Are mountpoints supported? I re-ran the bbwin client on the same system and the mountpoint is detected and displayed. Cheers, Gavin Stone-Tolcher, IT Support Officer, Network Operations and Incident Response Information Technology Services The University of Queensland Level 4, Prentice Building, St Lucia 4072 T: +61 7 334 66645, M: +61 401 140 838 E: <mailto:user-6e44775a32e5@xymon.invalid> user-6e44775a32e5@xymon.invalid W: <http://www.its.uq.edu.au>; www.its.uq.edu.au ITS: Service. Team. Accountability. Results. IMPORTANT: This email and any attachments are intended solely for the addressee(s), contain copyright material and are confidential. We do not waive any legal privilege or rights in respect of copyright or confidentiality. Except as intended addressees are otherwise permitted, you do not have permission to use, disclose, reproduce or communicate any part of this email or its attachments. Statements, opinions and information not related to the official business of The University of Queensland are neither given nor endorsed by us. By using this email (including accessing any attachments or links) you agree we are not liable for any loss or damage of any kind arising in connection with any electronic defect, virus or other malicious code we did not intentionally include. Please consider the environment before printing this email. CRICOS Code 00025B From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of user-aada0fa38bf8@xymon.invalid <mailto:user-aada0fa38bf8@xymon.invalid> Sent: Friday, 13 February 2015 7:53 PM To: user-834d44be5e50@xymon.invalid <mailto:user-834d44be5e50@xymon.invalid> ; xymon at xymon.com <mailto:xymon at xymon.com> Subject: [Xymon] Xymon Powershell Windows client Hi all, Today I have uploaded a new version of the Xymon Powershell client to SVN (in sandbox/WinPSClient). We (Accenture) are very pleased to be contributing these changes to the open source community. I've been working on this now for around 8 months on and off and hopefully the changes made will be of benefit to everyone! Whilst making changes, we have focussed mainly on making it work, improving reliability and most importantly improving performance. In most cases, on our 64 bit OS virtual machines, a data collection now takes around 5 seconds. On heavily loaded (CPU load or event log load) servers, the script is now considerably faster than originally. Key to this has been reducing the amount of WMI usage as this was a major culprit. We have also implemented some new features, largely based on our in-house requirements but hopefully useful to others: * Showing the process owner and command line in [procs]. This has been implemented using c# code, compiled at runtime. * Adding Active Directory replication test, Terminal Services sessions test * Ability to restart any stopped Windows service * Client self-update * Dirsize and dirtime checks (which were originally external scripts) Some things have changed slightly; for example, the local configuration which was registry-based is now XML-based (you can still use registry settings if you prefer). In the SVN repository I have also uploaded a Word document which describes how to install and the configuration options. I have uploaded all the revisions we have made to SVN so there is a history of development. Whilst we will endeavour to continue contributing changes and improvements in coming months, this is an open source project and as such we are not offering any formal support. If anyone wishes to bugfix, branch or whatever, please do so! Zak Beck Accenture
list Jason Jones
Hi Everyone,
Just thought we'd flag this - on some tests when the status is red the XML being returned has an invalid character.
I've tried (unsuccessfully) checking for release notes to see if this has been addressed previously but couldn't find anything (apologies in advance if it has been fixed previously).
See the XML below - the issue is on the CDATA line just after the € symbol
<ServerStatus>
<ServerName>[hostname]</ServerName>
<Type>http</Type>
<Status>red</Status>
<TestFlags></TestFlags> <LastChange>Fri Feb 13 17:08:14 2015</LastChange> <LogTime>Fri Feb 13 17:11:14 2015</LogTime>
<ValidTime>Fri Feb 13 17:41:14 2015</ValidTime>
<AckTime>N/A</AckTime>
<DisableTime>N/A</DisableTime>
<Sender>10.1.1.200</Sender> <Cookie>148280</Cookie>
<MessageSummary>
<![CDATA[status+30 [hostname].http red Fri Feb 13 17:11:14 2015: €]]>
</MessageSummary>
</ServerStatus>
We are currently running 4.3.18. If you need any more information please let us know.
Kind Regards,
Jason.
Jason Jones
Senior Analyst/Developer
Codel Software Ltd
Unit 1C
Charnwood Park
Bridgend
CF31 3PL
+44 (0)1656 750 858
+44 (0)1656 648 649
user-f3cd0ee20c57@xymon.invalid
http://www.codelsoftware.com
Follow Us:
@codel_software at activabsence
Linkedin
http://www.activabsence.co.uk
Registered in Wales No. 5838660
DELIVERING QUALITY: At Codel Software we are committed to delivering quality software, services and client interactions. We have demonstrated this through quality audits and customer satisfaction. Codel Software is an ISO 9001:2008 certified company.
CONFIDENTIALITY NOTICE: This message is confidential and for the use only of the intended recipient. If you receive the message in error you are not entitled to disseminate, copy or use the contents in any way. In such circumstances please forward the message back to the sender.
WARNING :While Codel Software takes steps to prevent computer viruses from being transmitted via electronic mail attachments we cannot guarantee that attachments do not contain computer virus code. You are therefore strongly advised to undertake anti virus checks prior to accessing the attachment to this electronic mail. Codel Software grants no warranties regarding performance use or quality of any attachment and undertakes no liability for loss or damage howsoever caused.
If you do not want to receive similar communications by e-mail from Codel Software, please reply to this e-mail with 'remove' in the subject line.
Help the environment –please don't print this email unless you really need to!
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
list Howard Snyder
Please remove me from this mailing list. Howard Snyder Principal – Advanced Technical Support Cisco / Adjunct Mobility EMS-AT Rethink Possible® AT&T Technology Operations XXXX Glenridge Drive Atlanta, GA XXXXX P: XXX.XXX.XXXX M: XXX.XXX.XXXX user-e66ae0780d99@xymon.invalid Mobility ATS website: https://operations.web.att.com/sites/EMS/default.aspx EMS-AT website: http://ems-at.sst.att.com/ EMS trouble tickets http://atsemsatticket.web.att.com<http://atsemsatticket.web.att.com/>; "This e-mail and any files transmitted with it are AT&T property, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender and delete this message immediately from your computer. Any other uses, retention, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited."
▸
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Jason Jones
Sent: Wednesday, February 18, 2015 5:15 AM
To: xymon at xymon.com
Subject: [Xymon] Invalid XML
Hi Everyone,
Just thought we'd flag this - on some tests when the status is red the XML being returned has an invalid character.
I've tried (unsuccessfully) checking for release notes to see if this has been addressed previously but couldn't find anything (apologies in advance if it has been fixed previously).
See the XML below - the issue is on the CDATA line just after the € symbol
<ServerStatus>
<ServerName>[hostname]</ServerName>
<Type>http</Type>
<Status>red</Status>
<TestFlags></TestFlags>
<LastChange>Fri Feb 13 17:08:14 2015</LastChange>
<LogTime>Fri Feb 13 17:11:14 2015</LogTime>
<ValidTime>Fri Feb 13 17:41:14 2015</ValidTime>
<AckTime>N/A</AckTime>
<DisableTime>N/A</DisableTime>
<Sender>10.1.1.200</Sender> <Cookie>148280</Cookie>
<MessageSummary>
<![CDATA[status+30 [hostname].http red Fri Feb 13 17:11:14 2015: €]]>
</MessageSummary>
</ServerStatus>
We are currently running 4.3.18. If you need any more information please let us know.
Kind Regards,
Jason.
Jason Jones
Senior Analyst/Developer
Codel Software Ltd
Unit 1C
Charnwood Park
Bridgend
CF31 3PL
[http://www.codelsoftware.com/wp-content/uploads/2014/06/miniicon-tel.gif] +44 (0)1656 750 858 [http://www.codelsoftware.com/wp-content/uploads/2014/06/miniicon-fax.gif] +44 (0)1656 648 649 [http://www.codelsoftware.com/wp-content/uploads/2014/06/miniicon-email.gif] user-f3cd0ee20c57@xymon.invalid<mailto:user-f3cd0ee20c57@xymon.invalid> [http://www.codelsoftware.com/wp-content/uploads/2014/06/miniicon-home.gif] http://www.codelsoftware.com<http://www.codelsoftware.com/>; Follow Us: [http://www.codelsoftware.com/wp-content/uploads/2014/06/miniicon-twitter.gif] @codel_software<http://twitter.com/codel_software>@activabsence<http://twitter.com/activabsence>; [http://www.codelsoftware.com/wp-content/uploads/2014/06/miniicon-linkedin.gif] Linkedin<http://www.linkedin.com/company/codel-software-ltd>; [http://www.codelsoftware.com/wp-content/uploads/2014/06/miniicon-aac.gif] http://www.activabsence.co.uk<http://www.activabsence.co.uk/>;
▸
Registered in Wales No. 5838660 DELIVERING QUALITY: At Codel Software we are committed to delivering quality software, services and client interactions. We have demonstrated this through quality audits and customer satisfaction. Codel Software is an ISO 9001:2008 certified company. CONFIDENTIALITY NOTICE: This message is confidential and for the use only of the intended recipient. If you receive the message in error you are not entitled to disseminate, copy or use the contents in any way. In such circumstances please forward the message back to the sender. WARNING :While Codel Software takes steps to prevent computer viruses from being transmitted via electronic mail attachments we cannot guarantee that attachments do not contain computer virus code. You are therefore strongly advised to undertake anti virus checks prior to accessing the attachment to this electronic mail. Codel Software grants no warranties regarding performance use or quality of any attachment and undertakes no liability for loss or damage howsoever caused. If you do not want to receive similar communications by e-mail from Codel Software, please reply to this e-mail with 'remove' in the subject line. Help the environment –please don't print this email unless you really need to! This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com
list Japheth Cleaver
▸
On Wed, February 18, 2015 2:15 am, Jason Jones wrote:
Hi Everyone, Just thought we'd flag this - on some tests when the status is red the XML being returned has an invalid character. I've tried (unsuccessfully) checking for release notes to see if this has been addressed previously but couldn't find anything (apologies in advance if it has been fixed previously).
See the XML below - the issue is on the CDATA line just after the â¬
▸
symbol
<ServerStatus>
<ServerName>[hostname]</ServerName>
<Type>http</Type>
<Status>red</Status>
<TestFlags></TestFlags>
<LastChange>Fri Feb 13 17:08:14 2015</LastChange>
<LogTime>Fri Feb 13 17:11:14 2015</LogTime>
<ValidTime>Fri Feb 13 17:41:14 2015</ValidTime>
<AckTime>N/A</AckTime>
<DisableTime>N/A</DisableTime>
<Sender>10.1.1.200</Sender> <Cookie>148280</Cookie>
<MessageSummary>
<![CDATA[status+30 [hostname].http red Fri Feb 13 17:11:14
2015: ⬠]]>
▸
</MessageSummary>
</ServerStatus>
We are currently running 4.3.18. If you need any more information please
let us know.
Kind Regards,
Jason.
Jason Jones
Senior Analyst/Developer
Interesting. Can you tell us if the errant XML occurs on all xymondx queries coming back, or just 'http' results? And all http results, or just this particular one? The text where the corruption is should be the post-HTTP Status response code text, if a connection was possible, or a string with certain types of connection issues (eg, 'No route to host'), if not. It's possible something is getting through corrupted. Is it a standard http server on the other end? Also, can you pipe this through "cat -A"? Regards, -jc
list Lukas Kohl
Hello Zak, today I recognized, that the msgs were sent broken: --- Full log eventlog_Security - 02/18/2015 13:54:50 - Microsoft-Windows-Security-Auditing - - 02/18/2015 13:54:50 - Microsoft-Windows-Security-Auditing - Full log eventlog_Application - 02/18/2015 13:54:51 - SceCli - --- I managed to track the issue down to my CurrentCulture setting ($Host or Get-Culture), which was de-DE at my Server. When I changed it to en-US, everything seems to be correct again: --- Full log eventlog_Application Information - 02/18/2015 16:04:57 - nssm - Started C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy RemoteSigned -NoLogo -NonInteractive -NoProfile -WindowStyle Hidden -File "C:\Program Files\xymonps\xymonclient.ps1" for service XymonPSClient in C:\Windows\System32\WindowsPowerShell\v1.0. Information - 02/18/2015 16:04:56 - nssm - Service XymonPSClient received START control, which will be handled. Information - 02/18/2015 16:04:55 - nssm - Killing PID 5100 in process tree of PID 5100 because service XymonPSClient is stopping. Information - 02/18/2015 16:04:55 - nssm - Killing process tree of process 5100 for service XymonPSClient with exit code 0 Information - 02/18/2015 16:04:54 - nssm - Killing process C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe because service XymonPSClient is stopping. Information - 02/18/2015 16:04:54 - nssm - Service XymonPSClient received STOP control, which will be handled. Information - 02/18/2015 15:31:58 - Microsoft-Windows-Security-SPP - The Software Protection service has stopped. --- The Problem is, that the commands [string]$entry.LevelDisplayName and [string]$entry.Message just return empty lines, when CurrentCulture is set to anything different than en-US --> http://powershell.com/cs/forums/p/14969/29273.aspx The behaviour can be fixed, when surrounding the Get-WinEvent with a different Culture (http://poshcode.org/2226): function Set-Culture([System.Globalization.CultureInfo] $culture) { [System.Threading.Thread]::CurrentThread.CurrentUICulture = $culture [System.Threading.Thread]::CurrentThread.CurrentCulture = $culture } $oldCulture = [System.Threading.Thread]::CurrentThread.CurrentUICulture trap { Set-Culture $oldCulture } Set-Culture en-US $logentries = @(Get-WinEvent -ErrorAction:SilentlyContinue -FilterXML $logFilterXML ` -MaxEvents $script:XymonSettings.MaxEvents) Set-Culture $oldCulture Aftwerwards, I can set the culture back to stock. Kind regards, Lukas
list Lukas Kohl
Hello Zak,
one more thing ;-)
Sometimes the msgs state switches to clear, because there are no new Logs.
You won't get this Problem with the Linux client, because it sends at least the monitored files.
It can be fixed, by adding an else Statement:
if ($logentries -ne $null)
{
....
else
{
$payload += "[msgs:eventlog_$l]" + [environment]::newline
}
In addition to that, you allways know, which logs are monitored.
Kind regards,
Lukas
list Zak Beck
Hi Lukas Thanks for reporting this. I have committed a patch based on your information - please try that. Regards
▸
Zak -----Original Message----- From: user-cd4357c4ac57@xymon.invalid [mailto:user-cd4357c4ac57@xymon.invalid] Sent: 18 February 2015 16:00 To: Beck, Zak Cc: xymon at xymon.com Subject: [Xymon] Xymon Powershell Windows client Hello Zak, today I recognized, that the msgs were sent broken: --- Full log eventlog_Security - 02/18/2015 13:54:50 - Microsoft-Windows-Security-Auditing - - 02/18/2015 13:54:50 - Microsoft-Windows-Security-Auditing - Full log eventlog_Application - 02/18/2015 13:54:51 - SceCli - --- I managed to track the issue down to my CurrentCulture setting ($Host or Get-Culture), which was de-DE at my Server. When I changed it to en-US, everything seems to be correct again: --- Full log eventlog_Application Information - 02/18/2015 16:04:57 - nssm - Started C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy RemoteSigned -NoLogo -NonInteractive -NoProfile -WindowStyle Hidden -File "C:\Program Files\xymonps\xymonclient.ps1" for service XymonPSClient in C:\Windows\System32\WindowsPowerShell\v1.0. Information - 02/18/2015 16:04:56 - nssm - Service XymonPSClient received START control, which will be handled. Information - 02/18/2015 16:04:55 - nssm - Killing PID 5100 in process tree of PID 5100 because service XymonPSClient is stopping. Information - 02/18/2015 16:04:55 - nssm - Killing process tree of process 5100 for service XymonPSClient with exit code 0 Information - 02/18/2015 16:04:54 - nssm - Killing process C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe because service XymonPSClient is stopping. Information - 02/18/2015 16:04:54 - nssm - Service XymonPSClient received STOP control, which will be handled. Information - 02/18/2015 15:31:58 - Microsoft-Windows-Security-SPP - The Software Protection service has stopped. --- The Problem is, that the commands [string]$entry.LevelDisplayName and [string]$entry.Message just return empty lines, when CurrentCulture is set to anything different than en-US --> http://powershell.com/cs/forums/p/14969/29273.aspx The behaviour can be fixed, when surrounding the Get-WinEvent with a different Culture (http://poshcode.org/2226): function Set-Culture([System.Globalization.CultureInfo] $culture) { [System.Threading.Thread]::CurrentThread.CurrentUICulture = $culture [System.Threading.Thread]::CurrentThread.CurrentCulture = $culture } $oldCulture = [System.Threading.Thread]::CurrentThread.CurrentUICulture trap { Set-Culture $oldCulture } Set-Culture en-US $logentries = @(Get-WinEvent -ErrorAction:SilentlyContinue -FilterXML $logFilterXML ` -MaxEvents $script:XymonSettings.MaxEvents) Set-Culture $oldCulture Aftwerwards, I can set the culture back to stock. Kind regards, Lukas
list Zak Beck
Hi Fixed this one as well :) - please test.
▸
Zak
-----Original Message-----
From: user-cd4357c4ac57@xymon.invalid [mailto:user-cd4357c4ac57@xymon.invalid]
Sent: 19 February 2015 10:22
To: Beck, Zak
Cc: xymon at xymon.com
Subject: [Xymon] Xymon Powershell Windows client
Hello Zak,
one more thing ;-)
Sometimes the msgs state switches to clear, because there are no new Logs.
You won't get this Problem with the Linux client, because it sends at least
the monitored files.
It can be fixed, by adding an else Statement:
if ($logentries -ne $null)
{
....
else
{
$payload += "[msgs:eventlog_$l]" + [environment]::newline
}
In addition to that, you allways know, which logs are monitored.
Kind regards,
Lukas
list Lukas Kohl
Hello Zak, works perfect: 2015-02-19 12:34:41 Event Log processing - max payload: 1024 - wanted logs: Application System Security 2015-02-19 12:34:41 Event log Application adding to payload 2015-02-19 12:34:41 Processing event log Application 2015-02-19 12:34:41 Setting thread/UI culture to en-US 2015-02-19 12:34:41 Resetting thread/UI culture to previous: de-DE / en-US 2015-02-19 12:34:41 Event log Application entries since last scan: 7 2015-02-19 12:34:41 Found a configured filter for log Application 2015-02-19 12:34:41 Event log System adding to payload 2015-02-19 12:34:41 Processing event log System 2015-02-19 12:34:41 Setting thread/UI culture to en-US 2015-02-19 12:34:42 Resetting thread/UI culture to previous: de-DE / en-US 2015-02-19 12:34:42 Event log System entries since last scan: 3 2015-02-19 12:34:42 Found a configured filter for log System 2015-02-19 12:34:42 Event log Security adding to payload 2015-02-19 12:34:42 Event log processing finished Kind regards, Lukas Von: <user-aada0fa38bf8@xymon.invalid> An: <user-cd4357c4ac57@xymon.invalid> Kopie: <xymon at xymon.com> Datum: 19.02.2015 11:51 Betreff: [SPAM] RE: [Xymon] Xymon Powershell Windows client
▸
Hi Lukas Thanks for reporting this. I have committed a patch based on your information - please try that. Regards Zak -----Original Message----- From: user-cd4357c4ac57@xymon.invalid [mailto:user-cd4357c4ac57@xymon.invalid] Sent: 18 February 2015 16:00 To: Beck, Zak Cc: xymon at xymon.com Subject: [Xymon] Xymon Powershell Windows client Hello Zak, today I recognized, that the msgs were sent broken: --- Full log eventlog_Security - 02/18/2015 13:54:50 - Microsoft-Windows-Security-Auditing - - 02/18/2015 13:54:50 - Microsoft-Windows-Security-Auditing - Full log eventlog_Application - 02/18/2015 13:54:51 - SceCli - --- I managed to track the issue down to my CurrentCulture setting ($Host or Get-Culture), which was de-DE at my Server. When I changed it to en-US, everything seems to be correct again: --- Full log eventlog_Application Information - 02/18/2015 16:04:57 - nssm - Started C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy RemoteSigned -NoLogo -NonInteractive -NoProfile -WindowStyle Hidden -File "C:\Program Files\xymonps\xymonclient.ps1" for service XymonPSClient in C:\Windows\System32\WindowsPowerShell\v1.0. Information - 02/18/2015 16:04:56 - nssm - Service XymonPSClient received START control, which will be handled. Information - 02/18/2015 16:04:55 - nssm - Killing PID 5100 in process tree of PID 5100 because service XymonPSClient is stopping. Information - 02/18/2015 16:04:55 - nssm - Killing process tree of process 5100 for service XymonPSClient with exit code 0 Information - 02/18/2015 16:04:54 - nssm - Killing process C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe because service XymonPSClient is stopping. Information - 02/18/2015 16:04:54 - nssm - Service XymonPSClient received STOP control, which will be handled. Information - 02/18/2015 15:31:58 - Microsoft-Windows-Security-SPP - The Software Protection service has stopped. --- The Problem is, that the commands [string]$entry.LevelDisplayName and [string]$entry.Message just return empty lines, when CurrentCulture is set to anything different than en-US --> http://powershell.com/cs/forums/p/14969/29273.aspx The behaviour can be fixed, when surrounding the Get-WinEvent with a different Culture (http://poshcode.org/2226): function Set-Culture([System.Globalization.CultureInfo] $culture) { [System.Threading.Thread]::CurrentThread.CurrentUICulture = $culture [System.Threading.Thread]::CurrentThread.CurrentCulture = $culture } $oldCulture = [System.Threading.Thread]::CurrentThread.CurrentUICulture trap { Set-Culture $oldCulture } Set-Culture en-US $logentries = @(Get-WinEvent -ErrorAction:SilentlyContinue -FilterXML $logFilterXML ` -MaxEvents $script:XymonSettings.MaxEvents) Set-Culture $oldCulture Aftwerwards, I can set the culture back to stock. Kind regards, Lukas
www.ergodirekt.de Blog: http://blog.ergodirekt.de Facebook: www.facebook.com/ERGODirekt Google+: www.google.com/+ergodirekt Twitter: www.twitter.com/ERGODirekt YouTube: www.youtube.com/ERGODirekt ERGO Direkt Lebensversicherung AG · Amtsgericht Fürth HRB 2787 · UST-ID-Nr. DE159593454 ERGO Direkt Versicherung AG · Amtsgericht Fürth HRB 2934 · UST-ID-Nr. DE159593438 ERGO Direkt Krankenversicherung AG · Amtsgericht Fürth HRB 4694 · UST-ID-Nr. DE159593446 Vorsitzender der Aufsichtsräte: Dr. Torsten Oletzky Vorstände: Dr. Daniel von Borries (Vorsitzender), Ralf Hartmann, Dr. Jörg Stoffels Sitz: Fürth Adresse: Karl-Martell-Straße 60 · 90344 Nürnberg · Deutschland
list Lukas Kohl
Hello Zak, this is also fixed:
▸
2015-02-19 12:34:42 Event log Security adding to payload
2015-02-19 12:34:42 Event log processing finished
Thank you for your quick response !
Kind regards,
Lukas
Von: <user-aada0fa38bf8@xymon.invalid>
An: <user-cd4357c4ac57@xymon.invalid>
Kopie: <xymon at xymon.com>
Datum: 19.02.2015 11:52
▸
Betreff: [SPAM] RE: [Xymon] Xymon Powershell Windows client Hi Fixed this one as well :) - please test. Zak -----Original Message----- From: user-cd4357c4ac57@xymon.invalid [mailto:user-cd4357c4ac57@xymon.invalid] Sent: 19 February 2015 10:22 To: Beck, Zak Cc: xymon at xymon.com Subject: [Xymon] Xymon Powershell Windows client Hello Zak, one more thing ;-) Sometimes the msgs state switches to clear, because there are no new Logs. You won't get this Problem with the Linux client, because it sends at least the monitored files. It can be fixed, by adding an else Statement: if ($logentries -ne $null) { .... else { $payload += "[msgs:eventlog_$l]" + [environment]::newline } In addition to that, you allways know, which logs are monitored. Kind regards, Lukas www.ergodirekt.de Blog: http://blog.ergodirekt.de Facebook: www.facebook.com/ERGODirekt Google+: www.google.com/+ergodirekt Twitter: www.twitter.com/ERGODirekt YouTube: www.youtube.com/ERGODirekt ERGO Direkt Lebensversicherung AG · Amtsgericht Fürth HRB 2787 · UST-ID-Nr. DE159593454 ERGO Direkt Versicherung AG · Amtsgericht Fürth HRB 2934 · UST-ID-Nr. DE159593438 ERGO Direkt Krankenversicherung AG · Amtsgericht Fürth HRB 4694 · UST-ID-Nr. DE159593446 Vorsitzender der Aufsichtsräte: Dr. Torsten Oletzky Vorstände: Dr. Daniel von Borries (Vorsitzender), Ralf Hartmann, Dr. Jörg Stoffels Sitz: Fürth Adresse: Karl-Martell-Straße 60 · 90344 Nürnberg · Deutschland
list Brandon Dale
Hi Zak,
I have been testing this on a few machines and playing around with it.
I'm trying to work out how best to handle the rules for filtering and alerting on event logs if there are both bbwin and PowerShell clients being used as the PowerShell client is slightly different in the way it collects the event logs.
Question 1:
In bbwin the raw data contains:
[collector:]
client testserver01.bbwin win32
In the updated PowerShell client it contains:
[collector:]
client testserver01.powershell PowerShell XymonPS
on the xymon server in client-local.cfg I have a setup like this.
[win32]
eventlog:security:10240
ignore blahblahblah
eventlog:system:10240
ignore blahblahblah
eventlog:application:10240
ignore blahblahblah
and then in analysis.cfg:
CLASS=win32
LOG %.* %^critical.* COLOR=red
LOG %.* %^error.* COLOR=red
LOG %.* %^failure.* COLOR=yellow
LOG %.* %^warning.* COLOR=yellow
I don't think Bbwin has an equivalent to the eventlogswanted:event_log_name:max_size command it seems to just pull all the event logs by default (all the logs listed in Get-EventLog -List | FT log).
Now because bbwin pulls all the logs by default, if I have a situation like the example below I get all the event logs on both servers and filters listed in client-local.cfg apply to the security,application,system logs which are the ones that contain most of the noise.
Example two servers, event logs collected in bbwin by default:
Server 1 (generic member server, nothing special)
[msgs:eventlog_application]
[msgs:eventlog_hardwareevents]
[msgs:eventlog_internet explorer]
[msgs:eventlog_key management service]
[msgs:eventlog_security]
[msgs:eventlog_system]
[msgs:eventlog_windows PowerShell]
Server 2 (Domain Controller)
[msgs:eventlog_application]
[msgs:eventlog_dfs replication]
[msgs:eventlog_directory service]
[msgs:eventlog_dns server]
[msgs:eventlog_file replication service]
[msgs:eventlog_internet explorer]
[msgs:eventlog_security]
[msgs:eventlog_system]
You can see the extra event logs present on the domain controller.
In the PowerShell client I can't work out how I can replicate this behaviour as by default it only collects Application,System,Security logs. I know I can specify additional logs using wantedeventlogs but I can't see how I can do that in a single general rule It seems like I would need to either
1. Have an entry in client-local.cfg under [PowerShell] with eventlogswanted and list every possible event log, this would mean on all clients these would display under msgs even if the log doesn't exist on the client
2. Create a separate entry with the [hostname] in client-local.cfg for each server where I want to collect anything outside of the three default logs and then list the ignore filters each time.
Have I misunderstood how this works or is there an easy way to replicate the same behaviour as bbwin?
Question 2:
I read through the documentation but I can't work out what is the advantage of setting any of these to 1: EnableWin32_Product, EnableWin32_QuickFixEngineering, EnableWMISections ? I understand they are disabled by default for performance but what do you actually gain if you enable them? I can see you get more info in the raw data but how is this used for the tests in xymon?
Question 3:
Would it be worth adding a filter to the client so get-winevents only returns critical,error,failure,warning events rather than everything. That would remove the need to have as many ignore rules in the client-local.cfg and I am guessing most people don't alert on events that are level=information. From memory I think that is how the original PowerShell client worked. I think ideally you should be able to specify this in the config xml or something similar.
Regards,
Brandon
▸
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of user-aada0fa38bf8@xymon.invalid
Sent: Friday, 13 February 2015 8:53 PM
To: user-834d44be5e50@xymon.invalid; xymon at xymon.com
Subject: [Xymon] Xymon Powershell Windows client
Hi all,
Today I have uploaded a new version of the Xymon Powershell client to SVN (in sandbox/WinPSClient). We (Accenture) are very pleased to be contributing these changes to the open source community. I've been working on this now for around 8 months on and off and hopefully the changes made will be of benefit to everyone!
Whilst making changes, we have focussed mainly on making it work, improving reliability and most importantly improving performance.
In most cases, on our 64 bit OS virtual machines, a data collection now takes around 5 seconds. On heavily loaded (CPU load or event log load) servers, the script is now considerably faster than originally. Key to this has been reducing the amount of WMI usage as this was a major culprit.
We have also implemented some new features, largely based on our in-house requirements but hopefully useful to others:
* Showing the process owner and command line in [procs]. This has been implemented using c# code, compiled at runtime.
* Adding Active Directory replication test, Terminal Services sessions test
* Ability to restart any stopped Windows service
* Client self-update
* Dirsize and dirtime checks (which were originally external scripts)
Some things have changed slightly; for example, the local configuration which was registry-based is now XML-based (you can still use registry settings if you prefer). In the SVN repository I have also uploaded a Word document which describes how to install and the configuration options.
I have uploaded all the revisions we have made to SVN so there is a history of development. Whilst we will endeavour to continue contributing changes and improvements in coming months, this is an open source project and as such we are not offering any formal support. If anyone wishes to bugfix, branch or whatever, please do so!
Zak Beck
Accenture
list Bruce White
I suggest going to: and following the unsubscribe instructions. Bruce White Senior Enterprise Systems Engineer | Phone: X-XXX-XXX-XXXX | user-58f975e8bf9d@xymon.invalid | www.fellowes.com<http://www.fellowes.com>; [cid:image603379.JPG at 3647e188.4985d9ca] Disclaimer: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Fellowes, Inc.
▸
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of SNYDER, HOWARD
Sent: Wednesday, February 18, 2015 6:43 AM
To: Jason Jones; xymon at xymon.com
Subject: Re: [Xymon] Invalid XML
Please remove me from this mailing list.
Howard Snyder
Principal – Advanced Technical Support
Cisco / Adjunct Mobility EMS-AT
Rethink Possible®
AT&T Technology Operations
XXXX Glenridge Drive
Atlanta, GA XXXXX
P: XXX.XXX.XXXX
M: XXX.XXX.XXXX
user-e66ae0780d99@xymon.invalid<mailto:user-e66ae0780d99@xymon.invalid>
▸
Mobility ATS website: https://operations.web.att.com/sites/EMS/default.aspx EMS-AT website: http://ems-at.sst.att.com/ EMS trouble tickets http://atsemsatticket.web.att.com<http://atsemsatticket.web.att.com/>; "This e-mail and any files transmitted with it are AT&T property, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender and delete this message immediately from your computer. Any other uses, retention, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited." From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Jason Jones Sent: Wednesday, February 18, 2015 5:15 AM To: xymon at xymon.com<mailto:xymon at xymon.com> Subject: [Xymon] Invalid XML Hi Everyone, Just thought we'd flag this - on some tests when the status is red the XML being returned has an invalid character. I've tried (unsuccessfully) checking for release notes to see if this has been addressed previously but couldn't find anything (apologies in advance if it has been fixed previously). See the XML below - the issue is on the CDATA line just after the € symbol <ServerStatus> <ServerName>[hostname]</ServerName> <Type>http</Type> <Status>red</Status> <TestFlags></TestFlags> <LastChange>Fri Feb 13 17:08:14 2015</LastChange> <LogTime>Fri Feb 13 17:11:14 2015</LogTime> <ValidTime>Fri Feb 13 17:41:14 2015</ValidTime> <AckTime>N/A</AckTime> <DisableTime>N/A</DisableTime> <Sender>10.1.1.200</Sender> <Cookie>148280</Cookie> <MessageSummary> <![CDATA[status+30 [hostname].http red Fri Feb 13 17:11:14 2015: €]]> </MessageSummary> </ServerStatus> We are currently running 4.3.18. If you need any more information please let us know. Kind Regards, Jason. Jason Jones Senior Analyst/Developer Codel Software Ltd Unit 1C Charnwood Park Bridgend CF31 3PL [http://www.codelsoftware.com/wp-content/uploads/2014/06/miniicon-tel.gif] +44 (0)1656 750 858 [http://www.codelsoftware.com/wp-content/uploads/2014/06/miniicon-fax.gif] +44 (0)1656 648 649 [http://www.codelsoftware.com/wp-content/uploads/2014/06/miniicon-email.gif] user-f3cd0ee20c57@xymon.invalid<mailto:user-f3cd0ee20c57@xymon.invalid> [http://www.codelsoftware.com/wp-content/uploads/2014/06/miniicon-home.gif] http://www.codelsoftware.com<http://www.codelsoftware.com/>; Follow Us: [http://www.codelsoftware.com/wp-content/uploads/2014/06/miniicon-twitter.gif] @codel_software<http://twitter.com/codel_software>@activabsence<http://twitter.com/activabsence>; [http://www.codelsoftware.com/wp-content/uploads/2014/06/miniicon-linkedin.gif] Linkedin<http://www.linkedin.com/company/codel-software-ltd>; [http://www.codelsoftware.com/wp-content/uploads/2014/06/miniicon-aac.gif] http://www.activabsence.co.uk<http://www.activabsence.co.uk/>; Registered in Wales No. 5838660 DELIVERING QUALITY: At Codel Software we are committed to delivering quality software, services and client interactions. We have demonstrated this through quality audits and customer satisfaction. Codel Software is an ISO 9001:2008 certified company. CONFIDENTIALITY NOTICE: This message is confidential and for the use only of the intended recipient. If you receive the message in error you are not entitled to disseminate, copy or use the contents in any way. In such circumstances please forward the message back to the sender. WARNING :While Codel Software takes steps to prevent computer viruses from being transmitted via electronic mail attachments we cannot guarantee that attachments do not contain computer virus code. You are therefore strongly advised to undertake anti virus checks prior to accessing the attachment to this electronic mail. Codel Software grants no warranties regarding performance use or quality of any attachment and undertakes no liability for loss or damage howsoever caused. If you do not want to receive similar communications by e-mail from Codel Software, please reply to this e-mail with 'remove' in the subject line. Help the environment –please don't print this email unless you really need to! This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com
list Gavin Stone-Tolcher
Just a comment, the field widths for the display of 1K blocks for the "disk" output should probably be increased from "9" to "10" or "11" to allow for terabyte class devices? Also the old BB client used to display the volume name enclosed in "()" after the "Mounted" field. e.g. Filesystem 1K-blocks Used Avail Capacity Mounted C 142632960 43665264 98967696 30% /FIXED/C () D 142734336 56339072 86395264 39% /FIXED/D (DATA) F 314572800 6421984 308150816 2% /FIXED/F (AUDIT) G 314572800 264085248 50487548 83% /FIXED/G (SHARED) I 629145600 608879424 20266156 96% /FIXED/I (PROJECTS1) J 629145600 234245312 394900288 37% /FIXED/J (PROJECTS2) K 629145600 267088320 362057280 42% /FIXED/K (USERS) Some of the Windows guys at my site would like to see that info in the powershell client test output. I wonder if a new field "Label" or "Volume" column could be added between the "Mounted" and "Summary" fields with that information. The "VolumeName" field from Win32_LogicalDisk class could be used for the data? I have added it locally and it does not seem to effect RRD collection or graphing for the test. This is what I currently have being generated using a locally modified version of the client. Filesystem 1K-blocks Used Avail Capacity Mounted Label Summary(Total\Avail GB) C 104753148 42324428 62428720 40% /FIXED/C (SYSTEM) 99.90\59.54 I am using the "Label" field from Win32_Volume class for the data in this particular case.
▸
Cheers, Gavin Stone-Tolcher, IT Support Officer, Network Operations and Incident Response Information Technology Services The University of Queensland Level 4, Prentice Building, St Lucia 4072 T: +61 7 334 66645, M: +61 401 140 838 E: user-6e44775a32e5@xymon.invalid<mailto:user-6e44775a32e5@xymon.invalid> W: www.its.uq.edu.au<http://www.its.uq.edu.au>; ITS: Service. Team. Accountability. Results. IMPORTANT: This email and any attachments are intended solely for the addressee(s), contain copyright material and are confidential. We do not waive any legal privilege or rights in respect of copyright or confidentiality. Except as intended addressees are otherwise permitted, you do not have permission to use, disclose, reproduce or communicate any part of this email or its attachments. Statements, opinions and information not related to the official business of The University of Queensland are neither given nor endorsed by us. By using this email (including accessing any attachments or links) you agree we are not liable for any loss or damage of any kind arising in connection with any electronic defect, virus or other malicious code we did not intentionally include. Please consider the environment before printing this email. CRICOS Code 00025B From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of user-aada0fa38bf8@xymon.invalid Sent: Friday, 13 February 2015 7:53 PM To: user-834d44be5e50@xymon.invalid; xymon at xymon.com Subject: [Xymon] Xymon Powershell Windows client Hi all, Today I have uploaded a new version of the Xymon Powershell client to SVN (in sandbox/WinPSClient). We (Accenture) are very pleased to be contributing these changes to the open source community. I've been working on this now for around 8 months on and off and hopefully the changes made will be of benefit to everyone! Whilst making changes, we have focussed mainly on making it work, improving reliability and most importantly improving performance. In most cases, on our 64 bit OS virtual machines, a data collection now takes around 5 seconds. On heavily loaded (CPU load or event log load) servers, the script is now considerably faster than originally. Key to this has been reducing the amount of WMI usage as this was a major culprit. We have also implemented some new features, largely based on our in-house requirements but hopefully useful to others: * Showing the process owner and command line in [procs]. This has been implemented using c# code, compiled at runtime. * Adding Active Directory replication test, Terminal Services sessions test * Ability to restart any stopped Windows service * Client self-update * Dirsize and dirtime checks (which were originally external scripts) Some things have changed slightly; for example, the local configuration which was registry-based is now XML-based (you can still use registry settings if you prefer). In the SVN repository I have also uploaded a Word document which describes how to install and the configuration options. I have uploaded all the revisions we have made to SVN so there is a history of development. Whilst we will endeavour to continue contributing changes and improvements in coming months, this is an open source project and as such we are not offering any formal support. If anyone wishes to bugfix, branch or whatever, please do so! Zak Beck Accenture
list Gavin Stone-Tolcher
Just a comment, the field widths for the display of 1K blocks for the "disk" output should probably be increased from "9" to "10" or "11" to allow for terabyte class devices?
Hmm, looking at the "-f" format operation, I see that this is really an "alignment", not a field width? What happens when the field output length is greater than the alignment value? I really should read a bit more about powershell it seems.
▸
Cheers, Gavin Stone-Tolcher, IT Support Officer, Network Operations and Incident Response Information Technology Services The University of Queensland Level 4, Prentice Building, St Lucia 4072 T: +61 7 334 66645, M: +61 401 140 838 E: user-6e44775a32e5@xymon.invalid<mailto:user-6e44775a32e5@xymon.invalid> W: www.its.uq.edu.au<http://www.its.uq.edu.au>; ITS: Service. Team. Accountability. Results. IMPORTANT: This email and any attachments are intended solely for the addressee(s), contain copyright material and are confidential. We do not waive any legal privilege or rights in respect of copyright or confidentiality. Except as intended addressees are otherwise permitted, you do not have permission to use, disclose, reproduce or communicate any part of this email or its attachments. Statements, opinions and information not related to the official business of The University of Queensland are neither given nor endorsed by us. By using this email (including accessing any attachments or links) you agree we are not liable for any loss or damage of any kind arising in connection with any electronic defect, virus or other malicious code we did not intentionally include. Please consider the environment before printing this email. CRICOS Code 00025B From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Gavin Stone-Tolcher Sent: Monday, 23 February 2015 11:01 AM To: 'user-aada0fa38bf8@xymon.invalid'; xymon at xymon.com Subject: Re: [Xymon] Xymon Powershell Windows client Just a comment, the field widths for the display of 1K blocks for the "disk" output should probably be increased from "9" to "10" or "11" to allow for terabyte class devices? Also the old BB client used to display the volume name enclosed in "()" after the "Mounted" field. e.g. Filesystem 1K-blocks Used Avail Capacity Mounted C 142632960 43665264 98967696 30% /FIXED/C () D 142734336 56339072 86395264 39% /FIXED/D (DATA) F 314572800 6421984 308150816 2% /FIXED/F (AUDIT) G 314572800 264085248 50487548 83% /FIXED/G (SHARED) I 629145600 608879424 20266156 96% /FIXED/I (PROJECTS1) J 629145600 234245312 394900288 37% /FIXED/J (PROJECTS2) K 629145600 267088320 362057280 42% /FIXED/K (USERS) Some of the Windows guys at my site would like to see that info in the powershell client test output. I wonder if a new field "Label" or "Volume" column could be added between the "Mounted" and "Summary" fields with that information. The "VolumeName" field from Win32_LogicalDisk class could be used for the data? I have added it locally and it does not seem to effect RRD collection or graphing for the test. This is what I currently have being generated using a locally modified version of the client. Filesystem 1K-blocks Used Avail Capacity Mounted Label Summary(Total\Avail GB) C 104753148 42324428 62428720 40% /FIXED/C (SYSTEM) 99.90\59.54 I am using the "Label" field from Win32_Volume class for the data in this particular case. Cheers, Gavin Stone-Tolcher, IT Support Officer, Network Operations and Incident Response Information Technology Services The University of Queensland Level 4, Prentice Building, St Lucia 4072 T: +61 7 334 66645, M: +61 401 140 838 E: user-6e44775a32e5@xymon.invalid<mailto:user-6e44775a32e5@xymon.invalid> W: www.its.uq.edu.au<http://www.its.uq.edu.au>; ITS: Service. Team. Accountability. Results. IMPORTANT: This email and any attachments are intended solely for the addressee(s), contain copyright material and are confidential. We do not waive any legal privilege or rights in respect of copyright or confidentiality. Except as intended addressees are otherwise permitted, you do not have permission to use, disclose, reproduce or communicate any part of this email or its attachments. Statements, opinions and information not related to the official business of The University of Queensland are neither given nor endorsed by us. By using this email (including accessing any attachments or links) you agree we are not liable for any loss or damage of any kind arising in connection with any electronic defect, virus or other malicious code we did not intentionally include. Please consider the environment before printing this email. CRICOS Code 00025B From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of user-aada0fa38bf8@xymon.invalid Sent: Friday, 13 February 2015 7:53 PM To: user-834d44be5e50@xymon.invalid; xymon at xymon.com Subject: [Xymon] Xymon Powershell Windows client Hi all, Today I have uploaded a new version of the Xymon Powershell client to SVN (in sandbox/WinPSClient). We (Accenture) are very pleased to be contributing these changes to the open source community. I've been working on this now for around 8 months on and off and hopefully the changes made will be of benefit to everyone! Whilst making changes, we have focussed mainly on making it work, improving reliability and most importantly improving performance. In most cases, on our 64 bit OS virtual machines, a data collection now takes around 5 seconds. On heavily loaded (CPU load or event log load) servers, the script is now considerably faster than originally. Key to this has been reducing the amount of WMI usage as this was a major culprit. We have also implemented some new features, largely based on our in-house requirements but hopefully useful to others: * Showing the process owner and command line in [procs]. This has been implemented using c# code, compiled at runtime. * Adding Active Directory replication test, Terminal Services sessions test * Ability to restart any stopped Windows service * Client self-update * Dirsize and dirtime checks (which were originally external scripts) Some things have changed slightly; for example, the local configuration which was registry-based is now XML-based (you can still use registry settings if you prefer). In the SVN repository I have also uploaded a Word document which describes how to install and the configuration options. I have uploaded all the revisions we have made to SVN so there is a history of development. Whilst we will endeavour to continue contributing changes and improvements in coming months, this is an open source project and as such we are not offering any formal support. If anyone wishes to bugfix, branch or whatever, please do so! Zak Beck Accenture
list Zak Beck
Hi Q1 You're right, BBWin does not have an equivalent server sent config for what event logs are wanted. It can be configured locally on the client in the registry if I recall correctly. This is why we added eventlogswanted - I wanted to be able to send that from the server. I think your two methods look correct (either way). This is a problem we have been thinking about for a while as we have no need to collect all logs (hence eventlogswanted) but managing all the configs can become a problem. Q2 Yes, they add to the raw data. They were in the original Powershell client, I added the switches to turn them off and be off by default but left them in as presumably someone does use them or did have a requirement for them. I wouldn't recommend enabling Win32_Product on any current Windows server - it has some nasty side effects (http://support.microsoft.com/kb/974524). Q3 You're right, the original Powershell client sent back Error and Warning events only. Not sure how this compares to BBWin. I can put this on the todo list - maybe as an additional option on eventlogswanted. Thanks Zak
▸
From: Brandon Dale [mailto:user-bf8ff8e1cedb@xymon.invalid]
Sent: 20 February 2015 02:55
To: Beck, Zak; xymon at xymon.com
Subject: RE: Xymon PowerShell Windows client
Hi Zak,
I have been testing this on a few machines and playing around with it.
I'm trying to work out how best to handle the rules for filtering and
alerting on event logs if there are both bbwin and PowerShell clients being
used as the PowerShell client is slightly different in the way it collects
the event logs.
Question 1:
In bbwin the raw data contains:
[collector:]
client testserver01.bbwin win32
In the updated PowerShell client it contains:
[collector:]
client testserver01.powershell PowerShell XymonPS
on the xymon server in client-local.cfg I have a setup like this.
[win32]
eventlog:security:10240
ignore blahblahblah
eventlog:system:10240
ignore blahblahblah
eventlog:application:10240
ignore blahblahblah
and then in analysis.cfg:
CLASS=win32
LOG %.* %^critical.* COLOR=red
LOG %.* %^error.* COLOR=red
LOG %.* %^failure.* COLOR=yellow
LOG %.* %^warning.* COLOR=yellow
I don't think Bbwin has an equivalent to the
eventlogswanted:event_log_name:max_size command it seems to just pull all
the event logs by default (all the logs listed in Get-EventLog -List | FT
log).
Now because bbwin pulls all the logs by default, if I have a situation like
the example below I get all the event logs on both servers and filters
listed in client-local.cfg apply to the security,application,system logs
which are the ones that contain most of the noise.
Example two servers, event logs collected in bbwin by default:
Server 1 (generic member server, nothing special)
[msgs:eventlog_application]
[msgs:eventlog_hardwareevents]
[msgs:eventlog_internet explorer]
[msgs:eventlog_key management service]
[msgs:eventlog_security]
[msgs:eventlog_system]
[msgs:eventlog_windows PowerShell]
Server 2 (Domain Controller)
[msgs:eventlog_application]
[msgs:eventlog_dfs replication]
[msgs:eventlog_directory service]
[msgs:eventlog_dns server]
[msgs:eventlog_file replication service]
[msgs:eventlog_internet explorer]
[msgs:eventlog_security]
[msgs:eventlog_system]
You can see the extra event logs present on the domain controller.
In the PowerShell client I can't work out how I can replicate this behaviour
as by default it only collects Application,System,Security logs. I know I
can specify additional logs using wantedeventlogs but I can't see how I can
do that in a single general rule It seems like I would need to either
1. Have an entry in client-local.cfg under [PowerShell] with
eventlogswanted and list every possible event log, this would mean on all
clients these would display under msgs even if the log doesn't exist on the
client
2. Create a separate entry with the [hostname] in client-local.cfg for
each server where I want to collect anything outside of the three default
logs and then list the ignore filters each time.
Have I misunderstood how this works or is there an easy way to replicate the
same behaviour as bbwin?
Question 2:
I read through the documentation but I can't work out what is the advantage
of setting any of these to 1: EnableWin32_Product,
EnableWin32_QuickFixEngineering, EnableWMISections ? I understand they are
disabled by default for performance but what do you actually gain if you
enable them? I can see you get more info in the raw data but how is this
used for the tests in xymon?
Question 3:
Would it be worth adding a filter to the client so get-winevents only
returns critical,error,failure,warning events rather than everything. That
would remove the need to have as many ignore rules in the client-local.cfg
and I am guessing most people don't alert on events that are
level=information. From memory I think that is how the original PowerShell
client worked. I think ideally you should be able to specify this in the
config xml or something similar.
Regards,
Brandon
From: Xymon [ <mailto:xymon-bounces at xymon.com>
mailto:xymon-bounces at xymon.com] On Behalf Of
<mailto:user-aada0fa38bf8@xymon.invalid> user-aada0fa38bf8@xymon.invalid
Sent: Friday, 13 February 2015 8:53 PM
To: <mailto:user-834d44be5e50@xymon.invalid>
user-834d44be5e50@xymon.invalid; <mailto:xymon at xymon.com>
▸
Subject: [Xymon] Xymon Powershell Windows client
Hi all,
Today I have uploaded a new version of the Xymon Powershell client to SVN
(in sandbox/WinPSClient). We (Accenture) are very pleased to be contributing
these changes to the open source community. I've been working on this now
for around 8 months on and off and hopefully the changes made will be of
benefit to everyone!
Whilst making changes, we have focussed mainly on making it work, improving
reliability and most importantly improving performance.
In most cases, on our 64 bit OS virtual machines, a data collection now
takes around 5 seconds. On heavily loaded (CPU load or event log load)
servers, the script is now considerably faster than originally. Key to this
has been reducing the amount of WMI usage as this was a major culprit.
We have also implemented some new features, largely based on our in-house
requirements but hopefully useful to others:
* Showing the process owner and command line in [procs]. This has
been implemented using c# code, compiled at runtime.
* Adding Active Directory replication test, Terminal Services
sessions test
* Ability to restart any stopped Windows service
* Client self-update
* Dirsize and dirtime checks (which were originally external
scripts)
Some things have changed slightly; for example, the local configuration
which was registry-based is now XML-based (you can still use registry
settings if you prefer). In the SVN repository I have also uploaded a Word
document which describes how to install and the configuration options.
I have uploaded all the revisions we have made to SVN so there is a history
of development. Whilst we will endeavour to continue contributing changes
and improvements in coming months, this is an open source project and as
such we are not offering any formal support. If anyone wishes to bugfix,
branch or whatever, please do so!
Zak Beck
Accenture
list Zak Beck
Adding the label stuff to the todo list. Nothing bad should happen (other than display glitches) if the value overflows the 9 length - it's just used for alignment. I can have a look at this when I do the mountpoint and label stuff. Thanks
▸
Zak From: Gavin Stone-Tolcher [mailto:user-6e44775a32e5@xymon.invalid] Sent: 23 February 2015 01:01 To: Beck, Zak; xymon at xymon.com Subject: RE: Xymon Powershell Windows client Just a comment, the field widths for the display of 1K blocks for the "disk" output should probably be increased from "9" to "10" or "11" to allow for terabyte class devices? Also the old BB client used to display the volume name enclosed in "()" after the "Mounted" field. e.g. Filesystem 1K-blocks Used Avail Capacity Mounted C 142632960 43665264 98967696 30% /FIXED/C () D 142734336 56339072 86395264 39% /FIXED/D (DATA) F 314572800 6421984 308150816 2% /FIXED/F (AUDIT) G 314572800 264085248 50487548 83% /FIXED/G (SHARED) I 629145600 608879424 20266156 96% /FIXED/I (PROJECTS1) J 629145600 234245312 394900288 37% /FIXED/J (PROJECTS2) K 629145600 267088320 362057280 42% /FIXED/K (USERS) Some of the Windows guys at my site would like to see that info in the powershell client test output. I wonder if a new field "Label" or "Volume" column could be added between the "Mounted" and "Summary" fields with that information. The "VolumeName" field from Win32_LogicalDisk class could be used for the data? I have added it locally and it does not seem to effect RRD collection or graphing for the test. This is what I currently have being generated using a locally modified version of the client. Filesystem 1K-blocks Used Avail Capacity Mounted Label Summary(Total\Avail GB) C 104753148 42324428 62428720 40% /FIXED/C (SYSTEM) 99.90\59.54 I am using the "Label" field from Win32_Volume class for the data in this particular case. Cheers, Gavin Stone-Tolcher, IT Support Officer, Network Operations and Incident Response Information Technology Services The University of Queensland Level 4, Prentice Building, St Lucia 4072 T: +61 7 334 66645, M: +61 401 140 838 E: <mailto:user-6e44775a32e5@xymon.invalid> user-6e44775a32e5@xymon.invalid W: <http://www.its.uq.edu.au>; www.its.uq.edu.au ITS: Service. Team. Accountability. Results. IMPORTANT: This email and any attachments are intended solely for the addressee(s), contain copyright material and are confidential. We do not waive any legal privilege or rights in respect of copyright or confidentiality. Except as intended addressees are otherwise permitted, you do not have permission to use, disclose, reproduce or communicate any part of this email or its attachments. Statements, opinions and information not related to the official business of The University of Queensland are neither given nor endorsed by us. By using this email (including accessing any attachments or links) you agree we are not liable for any loss or damage of any kind arising in connection with any electronic defect, virus or other malicious code we did not intentionally include. Please consider the environment before printing this email. CRICOS Code 00025B From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of user-aada0fa38bf8@xymon.invalid <mailto:user-aada0fa38bf8@xymon.invalid> Sent: Friday, 13 February 2015 7:53 PM To: user-834d44be5e50@xymon.invalid <mailto:user-834d44be5e50@xymon.invalid> ; xymon at xymon.com <mailto:xymon at xymon.com> Subject: [Xymon] Xymon Powershell Windows client Hi all, Today I have uploaded a new version of the Xymon Powershell client to SVN (in sandbox/WinPSClient). We (Accenture) are very pleased to be contributing these changes to the open source community. I've been working on this now for around 8 months on and off and hopefully the changes made will be of benefit to everyone! Whilst making changes, we have focussed mainly on making it work, improving reliability and most importantly improving performance. In most cases, on our 64 bit OS virtual machines, a data collection now takes around 5 seconds. On heavily loaded (CPU load or event log load) servers, the script is now considerably faster than originally. Key to this has been reducing the amount of WMI usage as this was a major culprit. We have also implemented some new features, largely based on our in-house requirements but hopefully useful to others: * Showing the process owner and command line in [procs]. This has been implemented using c# code, compiled at runtime. * Adding Active Directory replication test, Terminal Services sessions test * Ability to restart any stopped Windows service * Client self-update * Dirsize and dirtime checks (which were originally external scripts) Some things have changed slightly; for example, the local configuration which was registry-based is now XML-based (you can still use registry settings if you prefer). In the SVN repository I have also uploaded a Word document which describes how to install and the configuration options. I have uploaded all the revisions we have made to SVN so there is a history of development. Whilst we will endeavour to continue contributing changes and improvements in coming months, this is an open source project and as such we are not offering any formal support. If anyone wishes to bugfix, branch or whatever, please do so! Zak Beck Accenture
list Brandon Dale
Maybe for the eventlogs you could add support for an all command or wildcard type entry for the eventlogs something like eventlogswanted:*:max_size which will just pull all the log names available from Get-EventLog -List on the machine. Regards, Brandon
▸
From: user-aada0fa38bf8@xymon.invalid [mailto:user-aada0fa38bf8@xymon.invalid] Sent: Monday, 23 February 2015 7:55 PM To: Brandon Dale; xymon at xymon.com Subject: RE: Xymon PowerShell Windows client Hi Q1 You're right, BBWin does not have an equivalent server sent config for what event logs are wanted. It can be configured locally on the client in the registry if I recall correctly. This is why we added eventlogswanted - I wanted to be able to send that from the server. I think your two methods look correct (either way). This is a problem we have been thinking about for a while as we have no need to collect all logs (hence eventlogswanted) but managing all the configs can become a problem. Q2 Yes, they add to the raw data. They were in the original Powershell client, I added the switches to turn them off and be off by default but left them in as presumably someone does use them or did have a requirement for them. I wouldn't recommend enabling Win32_Product on any current Windows server - it has some nasty side effects (http://support.microsoft.com/kb/974524). Q3 You're right, the original Powershell client sent back Error and Warning events only. Not sure how this compares to BBWin. I can put this on the todo list - maybe as an additional option on eventlogswanted. Thanks Zak From: Brandon Dale [mailto:user-bf8ff8e1cedb@xymon.invalid] Sent: 20 February 2015 02:55 To: Beck, Zak; xymon at xymon.com<mailto:xymon at xymon.com> Subject: RE: Xymon PowerShell Windows client Hi Zak, I have been testing this on a few machines and playing around with it. I'm trying to work out how best to handle the rules for filtering and alerting on event logs if there are both bbwin and PowerShell clients being used as the PowerShell client is slightly different in the way it collects the event logs. Question 1: In bbwin the raw data contains: [collector:] client testserver01.bbwin win32 In the updated PowerShell client it contains: [collector:] client testserver01.powershell PowerShell XymonPS on the xymon server in client-local.cfg I have a setup like this. [win32] eventlog:security:10240 ignore blahblahblah eventlog:system:10240 ignore blahblahblah eventlog:application:10240 ignore blahblahblah and then in analysis.cfg: CLASS=win32 LOG %.* %^critical.* COLOR=red LOG %.* %^error.* COLOR=red LOG %.* %^failure.* COLOR=yellow LOG %.* %^warning.* COLOR=yellow I don't think Bbwin has an equivalent to the eventlogswanted:event_log_name:max_size command it seems to just pull all the event logs by default (all the logs listed in Get-EventLog -List | FT log). Now because bbwin pulls all the logs by default, if I have a situation like the example below I get all the event logs on both servers and filters listed in client-local.cfg apply to the security,application,system logs which are the ones that contain most of the noise. Example two servers, event logs collected in bbwin by default: Server 1 (generic member server, nothing special) [msgs:eventlog_application] [msgs:eventlog_hardwareevents] [msgs:eventlog_internet explorer] [msgs:eventlog_key management service] [msgs:eventlog_security] [msgs:eventlog_system] [msgs:eventlog_windows PowerShell] Server 2 (Domain Controller) [msgs:eventlog_application] [msgs:eventlog_dfs replication] [msgs:eventlog_directory service] [msgs:eventlog_dns server] [msgs:eventlog_file replication service] [msgs:eventlog_internet explorer] [msgs:eventlog_security] [msgs:eventlog_system] You can see the extra event logs present on the domain controller. In the PowerShell client I can't work out how I can replicate this behaviour as by default it only collects Application,System,Security logs. I know I can specify additional logs using wantedeventlogs but I can't see how I can do that in a single general rule It seems like I would need to either 1. Have an entry in client-local.cfg under [PowerShell] with eventlogswanted and list every possible event log, this would mean on all clients these would display under msgs even if the log doesn't exist on the client 2. Create a separate entry with the [hostname] in client-local.cfg for each server where I want to collect anything outside of the three default logs and then list the ignore filters each time. Have I misunderstood how this works or is there an easy way to replicate the same behaviour as bbwin? Question 2: I read through the documentation but I can't work out what is the advantage of setting any of these to 1: EnableWin32_Product, EnableWin32_QuickFixEngineering, EnableWMISections ? I understand they are disabled by default for performance but what do you actually gain if you enable them? I can see you get more info in the raw data but how is this used for the tests in xymon? Question 3: Would it be worth adding a filter to the client so get-winevents only returns critical,error,failure,warning events rather than everything. That would remove the need to have as many ignore rules in the client-local.cfg and I am guessing most people don't alert on events that are level=information. From memory I think that is how the original PowerShell client worked. I think ideally you should be able to specify this in the config xml or something similar. Regards, Brandon From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of user-aada0fa38bf8@xymon.invalid<mailto:user-aada0fa38bf8@xymon.invalid> Sent: Friday, 13 February 2015 8:53 PM To: user-834d44be5e50@xymon.invalid<mailto:user-834d44be5e50@xymon.invalid>; xymon at xymon.com<mailto:xymon at xymon.com> Subject: [Xymon] Xymon Powershell Windows client Hi all, Today I have uploaded a new version of the Xymon Powershell client to SVN (in sandbox/WinPSClient). We (Accenture) are very pleased to be contributing these changes to the open source community. I've been working on this now for around 8 months on and off and hopefully the changes made will be of benefit to everyone! Whilst making changes, we have focussed mainly on making it work, improving reliability and most importantly improving performance. In most cases, on our 64 bit OS virtual machines, a data collection now takes around 5 seconds. On heavily loaded (CPU load or event log load) servers, the script is now considerably faster than originally. Key to this has been reducing the amount of WMI usage as this was a major culprit. We have also implemented some new features, largely based on our in-house requirements but hopefully useful to others: * Showing the process owner and command line in [procs]. This has been implemented using c# code, compiled at runtime. * Adding Active Directory replication test, Terminal Services sessions test * Ability to restart any stopped Windows service * Client self-update * Dirsize and dirtime checks (which were originally external scripts) Some things have changed slightly; for example, the local configuration which was registry-based is now XML-based (you can still use registry settings if you prefer). In the SVN repository I have also uploaded a Word document which describes how to install and the configuration options. I have uploaded all the revisions we have made to SVN so there is a history of development. Whilst we will endeavour to continue contributing changes and improvements in coming months, this is an open source project and as such we are not offering any formal support. If anyone wishes to bugfix, branch or whatever, please do so! Zak Beck Accenture
list Jason Jones
Sorry just realised the list wasn't cc'd on this. Kind Regards, Jason. Jason Jones Senior Analyst/Developer Phone: +XX (X)XXXX XXXXXX E-mail: user-fd0f9ab1f051@xymon.invalid Hi jc, As requested:
# cat -A ServerStatus.txt
<ServerStatus>^M$ ^I<ServerName>[hostname]</ServerName>^M$ ^I<Type>http</Type>^M$ ^I<Status>red</Status>^M$ ^I<TestFlags></TestFlags>^I^M$ ^I<LastChange>Fri Feb 13 17:08:14 2015</LastChange>^I^M$ ^I<LogTime>Fri Feb 13 17:11:14 2015</LogTime>^M$ ^I<ValidTime>Fri Feb 13 17:41:14 2015</ValidTime>^M$ ^I<AckTime>N/A</AckTime>^M$ ^I<DisableTime>N/A</DisableTime>^M$ ^I<Sender>10.1.1.200</Sender> <Cookie>148280</Cookie>^M$ ^I<MessageSummary>^M$ ^I^I<![CDATA[status+30 [hostname].http red Fri Feb 13 17:11:14 2015: M-^@^C]]>^M$ ^I</MessageSummary>^M$ The HTTP server is running IBM HTTP Server (basically apache modded slightly) so I guess there may be something unexpected in the return, though at the time of this status the server was off so should not have produced anything special. Kind Regards, Jason. Jason Jones Senior Analyst/Developer Phone: +XX (X)XXXX XXXXXX E-mail: user-fd0f9ab1f051@xymon.invalid
▸
From: "J.C. Cleaver" <user-87556346d4af@xymon.invalid>
To: "Jason Jones" <user-fd0f9ab1f051@xymon.invalid>
Cc: xymon at xymon.com
Date: 18/02/2015 15:31
Subject: Re: [Xymon] Invalid XML
On Wed, February 18, 2015 2:15 am, Jason Jones wrote:Hi Everyone, Just thought we'd flag this - on some tests when the status is red the
XML
being returned has an invalid character.
I've tried (unsuccessfully) checking for release notes to see if this
has
been addressed previously but couldn't find anything (apologies in
advance
if it has been fixed previously).
See the XML below - the issue is on the CDATA line just after the €
symbol
<ServerStatus>
<ServerName>[hostname]</ServerName>
<Type>http</Type>
<Status>red</Status>
<TestFlags></TestFlags>
<LastChange>Fri Feb 13 17:08:14 2015</LastChange>
<LogTime>Fri Feb 13 17:11:14 2015</LogTime>
<ValidTime>Fri Feb 13 17:41:14 2015</ValidTime>
<AckTime>N/A</AckTime>
<DisableTime>N/A</DisableTime>
<Sender>10.1.1.200</Sender> <Cookie>148280</Cookie>
<MessageSummary>
<![CDATA[status+30 [hostname].http red Fri Feb 13 17:11:14
2015: € ]]>
</MessageSummary>
</ServerStatus>
We are currently running 4.3.18. If you need any more information please
let us know.
Kind Regards,
Jason.
Jason Jones
Senior Analyst/Developer
Interesting. Can you tell us if the errant XML occurs on all xymondx queries coming back, or just 'http' results? And all http results, or just this particular one? The text where the corruption is should be the post-HTTP Status response code text, if a connection was possible, or a string with certain types of connection issues (eg, 'No route to host'), if not. It's possible something is getting through corrupted. Is it a standard http server on the other end? Also, can you pipe this through "cat -A"? Regards, -jc This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com Codel Software Ltd Unit 1C Charnwood Park Bridgend CF31 3PL +44 (0)1656 750 858 +44 (0)1656 648 649 user-f3cd0ee20c57@xymon.invalid http://www.codelsoftware.com Follow Us: @codel_software at activabsence Linkedin http://www.activabsence.co.uk Registered in Wales No. 5838660 DELIVERING QUALITY: At Codel Software we are committed to delivering quality software, services and client interactions. We have demonstrated this through quality audits and customer satisfaction. Codel Software is an ISO 9001:2008 certified company. CONFIDENTIALITY NOTICE: This message is confidential and for the use only of the intended recipient. If you receive the message in error you are not entitled to disseminate, copy or use the contents in any way. In such circumstances please forward the message back to the sender. WARNING :While Codel Software takes steps to prevent computer viruses from being transmitted via electronic mail attachments we cannot guarantee that attachments do not contain computer virus code. You are therefore strongly advised to undertake anti virus checks prior to accessing the attachment to this electronic mail. Codel Software grants no warranties regarding performance use or quality of any attachment and undertakes no liability for loss or damage howsoever caused. If you do not want to receive similar communications by e-mail from Codel Software, please reply to this e-mail with 'remove' in the subject line. Help the environment –please don't print this email unless you really need to! Codel Software Ltd Unit 1C Charnwood Park Bridgend CF31 3PL +44 (0)1656 750 858 +44 (0)1656 648 649 user-f3cd0ee20c57@xymon.invalid http://www.codelsoftware.com Follow Us: @codel_software at activabsence Linkedin http://www.activabsence.co.uk Registered in Wales No. 5838660 DELIVERING QUALITY: At Codel Software we are committed to delivering quality software, services and client interactions. We have demonstrated this through quality audits and customer satisfaction. Codel Software is an ISO 9001:2008 certified company. CONFIDENTIALITY NOTICE: This message is confidential and for the use only of the intended recipient. If you receive the message in error you are not entitled to disseminate, copy or use the contents in any way. In such circumstances please forward the message back to the sender. WARNING :While Codel Software takes steps to prevent computer viruses from being transmitted via electronic mail attachments we cannot guarantee that attachments do not contain computer virus code. You are therefore strongly advised to undertake anti virus checks prior to accessing the attachment to this electronic mail. Codel Software grants no warranties regarding performance use or quality of any attachment and undertakes no liability for loss or damage howsoever caused. If you do not want to receive similar communications by e-mail from Codel Software, please reply to this e-mail with 'remove' in the subject line. Help the environment –please don't print this email unless you really need to! This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com
list Brandon Dale
Hi Zak, I want to be able to see the network traffic in/out on each NIC on my windows machines running the new PowerShell client, I have never really looked into how this worked in bbwin but if I look at a few example machines I see the following: 1. On a Linux machine I get Network Traffic and TCP/IP Statics graphs on the trends page a. Raw data contains [ifstat] and [netstat] information 2. On a windows machine running BBWin 0.13 I only get a TCP/IP Statics graph on the trends page a. [ifstat] is blank b. [netstat] contains data e.g [netstat] ipPacketsReceived=53513930 ipReceivedHeaderErrors=0 ipReceivedAddressErrors=355513 ipDatagramsForwarded=0 ipUnknownProtocolsReceived=2158 ipReceivedPacketsDiscarded=1266110 ipReceivedPacketsDelivered=52167159 ipOutputRequests=31961136 ipRoutingDiscards=0 ipDiscardedOutputPackets=5221 ipOutputPacketNoRoute=0 ipReassemblyRequired=730696 ipReassemblySuccessful=199056 ipReassemblyFailures=0 ipDatagramsSuccessfullyFragmented=0 ipDatagramsFailingFragmentation=0 ipFragmentsCreated=0 ipv6PacketsReceived=7895 ipv6ReceivedHeaderErrors=0 ipv6ReceivedAddressErrors=0 ipv6DatagramsForwarded=0 ipv6UnknownProtocolsReceived=0 ipv6ReceivedPacketsDiscarded=5199 ipv6ReceivedPacketsDelivered=7908 ipv6OutputRequests=2596918 ipv6RoutingDiscards=0 ipv6DiscardedOutputPackets=0 ipv6OutputPacketNoRoute=2 ipv6ReassemblyRequired=0 ipv6ReassemblySuccessful=0 ipv6ReassemblyFailures=0 ipv6DatagramsSuccessfullyFragmented=0 ipv6DatagramsFailingFragmentation=0 ipv6FragmentsCreated=0 3. On a windows machine running PowerShell client v1.98 I don't get any network related graphs however I seem to have data available: a. [ifstat] contains data e.g [ifstat] fe80::25a5:b99d:55cd:951f%12 2655878237 519887923 10.250.100.163 2655878237 519887923 a. [netstat] contains data e.g [netstat] PacketsReceived=3387463 ReceivedHeaderErrors=0 ReceivedAddressErrors=51034 DatagramsForwarded=0 UnknownProtocolsReceived=0 ReceivedPacketsDiscarded=146872 ReceivedPacketsDelivered=3219450 OutputRequests=950747 RoutingDiscards=0 DiscardedOutputPackets=102 OutputPacketNoRoute=0 ReassemblyRequired=83643 ReassemblySuccessful=27881 ReassemblyFailures=0 DatagramsSuccessfullyFragmented=0 DatagramsFailingFragmentation=0 FragmentsCreated=0 PacketsReceived=1266 ReceivedHeaderErrors=0 ReceivedAddressErrors=0 DatagramsForwarded=0 UnknownProtocolsReceived=0 ReceivedPacketsDiscarded=618 ReceivedPacketsDelivered=1264 OutputRequests=11680 RoutingDiscards=0 DiscardedOutputPackets=0 OutputPacketNoRoute=2 ReassemblyRequired=0 ReassemblySuccessful=0 ReassemblyFailures=0 DatagramsSuccessfullyFragmented=0 DatagramsFailingFragmentation=0 FragmentsCreated=0 The netstat data in the PowerShell client doesn't seem to have the ip / ipv6 infront of the values so they are listed twice in the example above. So I'm not sure what graphs should I be expecting to get under trends with the PowerShell client for network traffic? At the moment I'm guessing the ifstat data isn't in a format xymon will automatically graph and add to the trends page and the same for the netstat data possibly just because it has duplicate values for ipv4 and ipv6.
▸
Regards,
Brandon
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of user-aada0fa38bf8@xymon.invalid
Sent: Friday, 13 February 2015 8:53 PM
To: user-834d44be5e50@xymon.invalid; xymon at xymon.com
Subject: [Xymon] Xymon Powershell Windows client
Hi all,
Today I have uploaded a new version of the Xymon Powershell client to SVN (in sandbox/WinPSClient). We (Accenture) are very pleased to be contributing these changes to the open source community. I've been working on this now for around 8 months on and off and hopefully the changes made will be of benefit to everyone!
Whilst making changes, we have focussed mainly on making it work, improving reliability and most importantly improving performance.
In most cases, on our 64 bit OS virtual machines, a data collection now takes around 5 seconds. On heavily loaded (CPU load or event log load) servers, the script is now considerably faster than originally. Key to this has been reducing the amount of WMI usage as this was a major culprit.
We have also implemented some new features, largely based on our in-house requirements but hopefully useful to others:
* Showing the process owner and command line in [procs]. This has been implemented using c# code, compiled at runtime.
* Adding Active Directory replication test, Terminal Services sessions test
* Ability to restart any stopped Windows service
* Client self-update
* Dirsize and dirtime checks (which were originally external scripts)
Some things have changed slightly; for example, the local configuration which was registry-based is now XML-based (you can still use registry settings if you prefer). In the SVN repository I have also uploaded a Word document which describes how to install and the configuration options.
I have uploaded all the revisions we have made to SVN so there is a history of development. Whilst we will endeavour to continue contributing changes and improvements in coming months, this is an open source project and as such we are not offering any formal support. If anyone wishes to bugfix, branch or whatever, please do so!
Zak Beck
Accenture
list Jeremy Laidman
▸
On 4 March 2015 at 13:26, Brandon Dale <user-bf8ff8e1cedb@xymon.invalid> wrote:
3. On a windows machine running PowerShell client v1.98 I don’t get any network related graphs however I seem to have data available: a. [ifstat] contains data e.g [ifstat] fe80::25a5:b99d:55cd:951f%12 2655878237 519887923 10.250.100.163 2655878237 519887923
Yep, this should be parseable by Xymon. In principle.
At the moment I’m guessing the ifstat data isn’t in a format xymon will automatically graph and add to the trends page
Xymon will parse the [ifstat] data from a Windows machine, if it's in a
suitable format. From the source code, the regexp for this is:
^([a-zA-Z0-9.:]+)\s+([0-9]+)\s+([0-9]+)
I note that in the first [ifstat] line above, there's a percentage sign in
the first token, which doesn't match the regexp. I don't know of Xymon
continues on looking for other lines to match, or if it rejects the whole
[ifstat] section as corrupt. But I wonder what would happen if the IPv6
address wasn't in the [ifstat] client data. Any chance you can unbind IPv6
for testing?
Another thing to note is that some of the "powershell" processing in Xymon
just re-uses the "bbwin" processing. But there are some bits of parsing
code, including for "ifstat" it seems, that only look for the bbwin OS
string, and I can't see any place in the powershell handling code that
tries to fake the bbwin OS for ifstat. In other words, could be that the
code simply isn't there to do what you want. But it might also be the case
that adjusting the powershell client to report itself as the bbwin client
might do the trick.
J
list Zak Beck
Hi
Unfortunately, you can't fake the BBWin identifier for just one section – you have to change the client to report in as BBwin. It was changed so that we could experimentally use separate configuration options for BBWin clients and Powershell clients.
To change how the client reports itself, change line 2746 in the current commit:
2745 WriteLog "Performing main and optional tests and building output..."
2746 $clout = "client " + $clientname + ".powershell powershell XymonPS" | Out-String
2747 $clsecs = XymonClientSections | Out-String
In the original Powershell client, this line was:
$clout = "client " + $clientname + ".bbwin win32" | Out-String
So you can see we've changed '.bbwin' to '.powershell' and 'win32' to 'powershell'.
I appreciate this isn't very good and should probably be a configuration item.
[netstat] uses the output from netstat -s, but it appears the parsing is not very clever. [ifstat] uses a .Net object to pull out interface information. I haven't changed the code that generates either of these sections – quite likely it needs some work! I'll add it to the list.
Zak
▸
From: Jeremy Laidman [mailto:user-71895fb2e44c@xymon.invalid]
Sent: 04 March 2015 06:24
To: Brandon Dale
Cc: Beck, Zak; xymon at xymon.com
Subject: Re: [Xymon] Xymon PowerShell Windows client
On 4 March 2015 at 13:26, Brandon Dale <user-bf8ff8e1cedb@xymon.invalid <mailto:user-bf8ff8e1cedb@xymon.invalid> > wrote:
3. On a windows machine running PowerShell client v1.98 I don’t get any network related graphs however I seem to have data available:
a. [ifstat] contains data e.g
[ifstat]
fe80::25a5:b99d:55cd:951f%12 2655878237 519887923
10.250.100.163 2655878237 519887923
Yep, this should be parseable by Xymon. In principle.
At the moment I’m guessing the ifstat data isn’t in a format xymon will automatically graph and add to the trends page
Xymon will parse the [ifstat] data from a Windows machine, if it's in a suitable format. From the source code, the regexp for this is:
^([a-zA-Z0-9.:]+)\s+([0-9]+)\s+([0-9]+)
I note that in the first [ifstat] line above, there's a percentage sign in the first token, which doesn't match the regexp. I don't know of Xymon continues on looking for other lines to match, or if it rejects the whole [ifstat] section as corrupt. But I wonder what would happen if the IPv6 address wasn't in the [ifstat] client data. Any chance you can unbind IPv6 for testing?
Another thing to note is that some of the "powershell" processing in Xymon just re-uses the "bbwin" processing. But there are some bits of parsing code, including for "ifstat" it seems, that only look for the bbwin OS string, and I can't see any place in the powershell handling code that tries to fake the bbwin OS for ifstat. In other words, could be that the code simply isn't there to do what you want. But it might also be the case that adjusting the powershell client to report itself as the bbwin client might do the trick.
J
list Brandon Dale
I added in bbwin identifier and those two graphs started to appear.
This is what I have under ifstat with ipv6 enabled.
[ifstat]
fe80::25a5:b99d:55cd:951f%12 2677339075 541438677
10.250.100.163 2677339075 541438677
::1 0 0
127.0.0.1 0 0
This is what ends up on the graph, , the ipv6 address with the % symbol doesn’t display which might be a problem for some.
[cid:image001.png at 01D056B7.8B4B5BC0]
I also changed the xymonifstat function on line 1895 in the ps client to get rid of the loop back addresses.
function XymonIfstat
{
WriteLog "XymonIfstat start"
"[ifstat]"
[System.Net.NetworkInformation.NetworkInterface]::GetAllNetworkInterfaces() | ?{($_.OperationalStatus -eq "Up") -and ($_.NetworkInterfaceType -ne "loopback")} | %{
$ad = $_.GetIPv4Statistics() | select BytesSent, BytesReceived
$ip = $_.GetIPProperties().UnicastAddresses | select Address
# some interfaces have multiple IPs, so iterate over them reporting same stats
$ip | %{ "{0} {1} {2}" -f $_.Address.IPAddressToString,$ad.BytesReceived,$ad.BytesSent }
}
WriteLog "XymonIfstat finished."
}
Output is:
[ifstat]
fe80::25a5:b99d:55cd:951f%12 2678370580 543079717
10.250.100.163 2678370580 543079717
And now I don’t see the loopback addresses on the graph which “looks” better.
[cid:image002.png at 01D056BD.14C7A3E0]
▸
Regards,
Brandon
From: user-aada0fa38bf8@xymon.invalid [mailto:user-aada0fa38bf8@xymon.invalid]
Sent: Wednesday, 4 March 2015 7:48 PM
To: user-71895fb2e44c@xymon.invalid; Brandon Dale
Cc: xymon at xymon.com
Subject: RE: [Xymon] Xymon PowerShell Windows client
Hi
Unfortunately, you can't fake the BBWin identifier for just one section – you have to change the client to report in as BBwin. It was changed so that we could experimentally use separate configuration options for BBWin clients and Powershell clients.
To change how the client reports itself, change line 2746 in the current commit:
2745 WriteLog "Performing main and optional tests and building output..."
2746 $clout = "client " + $clientname + ".powershell powershell XymonPS" | Out-String
2747 $clsecs = XymonClientSections | Out-String
In the original Powershell client, this line was:
$clout = "client " + $clientname + ".bbwin win32" | Out-String
So you can see we've changed '.bbwin' to '.powershell' and 'win32' to 'powershell'.
I appreciate this isn't very good and should probably be a configuration item.
[netstat] uses the output from netstat -s, but it appears the parsing is not very clever. [ifstat] uses a .Net object to pull out interface information. I haven't changed the code that generates either of these sections – quite likely it needs some work! I'll add it to the list.
Zak
From: Jeremy Laidman [mailto:user-71895fb2e44c@xymon.invalid]
Sent: 04 March 2015 06:24
To: Brandon Dale
Cc: Beck, Zak; xymon at xymon.com<mailto:xymon at xymon.com>
Subject: Re: [Xymon] Xymon PowerShell Windows client
On 4 March 2015 at 13:26, Brandon Dale <user-bf8ff8e1cedb@xymon.invalid<mailto:user-bf8ff8e1cedb@xymon.invalid>> wrote:
3. On a windows machine running PowerShell client v1.98 I don’t get any network related graphs however I seem to have data available:
a. [ifstat] contains data e.g
[ifstat]
fe80::25a5:b99d:55cd:951f%12 2655878237 519887923
10.250.100.163 2655878237 519887923
Yep, this should be parseable by Xymon. In principle.
At the moment I’m guessing the ifstat data isn’t in a format xymon will automatically graph and add to the trends page
Xymon will parse the [ifstat] data from a Windows machine, if it's in a suitable format. From the source code, the regexp for this is:
^([a-zA-Z0-9.:]+)\s+([0-9]+)\s+([0-9]+)
I note that in the first [ifstat] line above, there's a percentage sign in the first token, which doesn't match the regexp. I don't know of Xymon continues on looking for other lines to match, or if it rejects the whole [ifstat] section as corrupt. But I wonder what would happen if the IPv6 address wasn't in the [ifstat] client data. Any chance you can unbind IPv6 for testing?
Another thing to note is that some of the "powershell" processing in Xymon just re-uses the "bbwin" processing. But there are some bits of parsing code, including for "ifstat" it seems, that only look for the bbwin OS string, and I can't see any place in the powershell handling code that tries to fake the bbwin OS for ifstat. In other words, could be that the code simply isn't there to do what you want. But it might also be the case that adjusting the powershell client to report itself as the bbwin client might do the trick.
J
Attachments (1)
attachment.png
list Zak Beck
Hi Thanks for the patch. Regarding the BBwin / powershell identifier, my proposal is to default to bbwin but to allow this to be overridden using the local client XML config – does this sound reasonable? The %<number> stuff is the zone index (https://en.wikipedia.org/wiki/IPv6_address#Link-local_addresses_and_zone_indices) – i.e. the adaptor number. I'm not sure how useful this is to Xymon and could probably be removed with a slight amendment to your patch like the following:
▸
function XymonIfstat
{
WriteLog "XymonIfstat start"
"[ifstat]"
[System.Net.NetworkInformation.NetworkInterface]::GetAllNetworkInterfaces() | ?{($_.OperationalStatus -eq "Up") -and ($_.NetworkInterfaceType -ne "loopback")} | %{
$ad = $_.GetIPv4Statistics() | select BytesSent, BytesReceived
$ip = $_.GetIPProperties().UnicastAddresses | select Address
# some interfaces have multiple IPs, so iterate over them reporting same stats
$ip | %{ "{0} {1} {2}" -f ($_.Address.IPAddressToString –replace '%\d+'), $ad.BytesReceived,$ad.BytesSent }
}
WriteLog "XymonIfstat finished."
}
I have not tested this but I think it should work.
Thanks
Zak Beck
Infrastructure Tech Support Specialist
Accenture
Tel: +XX (X) XXXX XXXXXX
Email: user-aada0fa38bf8@xymon.invalid <mailto:user-aada0fa38bf8@xymon.invalid>
Upcoming PTO (leave): Feb 20th, April 7th-10th, Jul 3rd, Jul 24th-Aug 10th
Our core values: Stewardship - Best People - Client Value Creation - One Global Network - Respect for the Individual - Integrity
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.
Accenture means Accenture (UK) Limited (registered number 4757301), registered in England and Wales with registered address at 30 Fenchurch Street, London EC3M 3BD.
▸
From: Brandon Dale [mailto:user-bf8ff8e1cedb@xymon.invalid]
Sent: 04 March 2015 09:58
To: Beck, Zak; user-71895fb2e44c@xymon.invalid
Cc: xymon at xymon.com
Subject: RE: [Xymon] Xymon PowerShell Windows client
I added in bbwin identifier and those two graphs started to appear.
This is what I have under ifstat with ipv6 enabled.
[ifstat]
fe80::25a5:b99d:55cd:951f%12 2677339075 541438677
10.250.100.163 2677339075 541438677
::1 0 0
127.0.0.1 0 0
This is what ends up on the graph, , the ipv6 address with the % symbol doesn’t display which might be a problem for some.
I also changed the xymonifstat function on line 1895 in the ps client to get rid of the loop back addresses.
function XymonIfstat
{
WriteLog "XymonIfstat start"
"[ifstat]"
[System.Net.NetworkInformation.NetworkInterface]::GetAllNetworkInterfaces() | ?{($_.OperationalStatus -eq "Up") -and ($_.NetworkInterfaceType -ne "loopback")} | %{
$ad = $_.GetIPv4Statistics() | select BytesSent, BytesReceived
$ip = $_.GetIPProperties().UnicastAddresses | select Address
# some interfaces have multiple IPs, so iterate over them reporting same stats
$ip | %{ "{0} {1} {2}" -f $_.Address.IPAddressToString,$ad.BytesReceived,$ad.BytesSent }
}
WriteLog "XymonIfstat finished."
}
Output is:
[ifstat]
fe80::25a5:b99d:55cd:951f%12 2678370580 543079717
10.250.100.163 2678370580 543079717
And now I don’t see the loopback addresses on the graph which “looks” better.
Regards,
Brandon
▸
From: user-aada0fa38bf8@xymon.invalid <mailto:user-aada0fa38bf8@xymon.invalid> [mailto:user-aada0fa38bf8@xymon.invalid]
Sent: Wednesday, 4 March 2015 7:48 PM
To: user-71895fb2e44c@xymon.invalid <mailto:user-71895fb2e44c@xymon.invalid> ; Brandon Dale
Cc: xymon at xymon.com <mailto:xymon at xymon.com>
Subject: RE: [Xymon] Xymon PowerShell Windows client
Hi
Unfortunately, you can't fake the BBWin identifier for just one section – you have to change the client to report in as BBwin. It was changed so that we could experimentally use separate configuration options for BBWin clients and Powershell clients.
To change how the client reports itself, change line 2746 in the current commit:
2745 WriteLog "Performing main and optional tests and building output..."
2746 $clout = "client " + $clientname + ".powershell powershell XymonPS" | Out-String
2747 $clsecs = XymonClientSections | Out-String
In the original Powershell client, this line was:
$clout = "client " + $clientname + ".bbwin win32" | Out-String
So you can see we've changed '.bbwin' to '.powershell' and 'win32' to 'powershell'.
I appreciate this isn't very good and should probably be a configuration item.
[netstat] uses the output from netstat -s, but it appears the parsing is not very clever. [ifstat] uses a .Net object to pull out interface information. I haven't changed the code that generates either of these sections – quite likely it needs some work! I'll add it to the list.
Zak
From: Jeremy Laidman [mailto:user-71895fb2e44c@xymon.invalid]
Sent: 04 March 2015 06:24
To: Brandon Dale
Cc: Beck, Zak; xymon at xymon.com <mailto:xymon at xymon.com>
Subject: Re: [Xymon] Xymon PowerShell Windows client
On 4 March 2015 at 13:26, Brandon Dale <user-bf8ff8e1cedb@xymon.invalid <mailto:user-bf8ff8e1cedb@xymon.invalid> > wrote:
3. On a windows machine running PowerShell client v1.98 I don’t get any network related graphs however I seem to have data available:
a. [ifstat] contains data e.g
[ifstat]
fe80::25a5:b99d:55cd:951f%12 2655878237 519887923
10.250.100.163 2655878237 519887923
Yep, this should be parseable by Xymon. In principle.
At the moment I’m guessing the ifstat data isn’t in a format xymon will automatically graph and add to the trends page
Xymon will parse the [ifstat] data from a Windows machine, if it's in a suitable format. From the source code, the regexp for this is:
^([a-zA-Z0-9.:]+)\s+([0-9]+)\s+([0-9]+)
I note that in the first [ifstat] line above, there's a percentage sign in the first token, which doesn't match the regexp. I don't know of Xymon continues on looking for other lines to match, or if it rejects the whole [ifstat] section as corrupt. But I wonder what would happen if the IPv6 address wasn't in the [ifstat] client data. Any chance you can unbind IPv6 for testing?
Another thing to note is that some of the "powershell" processing in Xymon just re-uses the "bbwin" processing. But there are some bits of parsing code, including for "ifstat" it seems, that only look for the bbwin OS string, and I can't see any place in the powershell handling code that tries to fake the bbwin OS for ifstat. In other words, could be that the code simply isn't there to do what you want. But it might also be the case that adjusting the powershell client to report itself as the bbwin client might do the trick.
J
list David Baldwin
Zak,
▸
Unfortunately, you can't fake the BBWin identifier for just one section – you have to change the client to report in as BBwin. It was changed so that we could experimentally use separate configuration options for BBWin clients and Powershell clients. To change how the client reports itself, change line 2746 in the current commit: 2745 WriteLog "Performing main and optional tests and building output..." 2746 $clout = "client " + $clientname + ".powershell powershell XymonPS" | Out-String 2747 $clsecs = XymonClientSections | Out-String In the original Powershell client, this line was: $clout = "client " + $clientname + ".bbwin win32" | Out-String So you can see we've changed '.bbwin' to '.powershell' and 'win32' to 'powershell'. I appreciate this isn't very good and should probably be a configuration item.
Changing the client from bbwin to something else is less harmful. Changing class from win32 to powershell will probably break LOTS of stuff. I suspect many users migrating from BBWin use "class=win32" in analysis.cfg (hobbit-clients.cfg) file extensively. The class is probably also used in the section parsing -> status reports/RRD data extraction. It will also break the config segment returned from client-local.cfg - e.g. [win32] dir:C:\Windows\Temp log:c:\WINDOWS\WindowsUpdate.log:20480 David. -- David Baldwin - Senior Systems Administrator (Datacentres + Networks) Information and Communication Technology Services Australian Sports Commission http://ausport.gov.au Tel 02 62147830 Fax 02 62141830 PO Box 176 Belconnen ACT 2616 user-cbbf693f2c89@xymon.invalid 1 Leverrier Street Bruce ACT 2617 Our Values: RESPECT + INTEGRITY + TEAMWORK + EXCELLENCE Keep up to date with what's happening in Australian sport visit http://www.ausport.gov.au This message is intended for the addressee named and may contain confidential and privileged information. If you are not the intended recipient please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you receive this message in error, please delete it and notify the sender.
list Jeremy Laidman
▸
On 04/03/2015 7:49 PM, <user-aada0fa38bf8@xymon.invalid> wrote:
Unfortunately, you can't fake the BBWin identifier for just one section – you have to change the client to report in as BBwin. It was changed so that we could experimentally use separate configuration options for BBWin clients and Powershell clients.
Of course the best option is to extend the server to match the features of the client. It wouldn't take much (like one line) to add the powershell OS into the ifstat handler, running the same code as for bbwin. J
list Brandon Dale
The problem is if you are running both bbwin and the powershell client you need a way to be able to setup separate commands in the client-local.cfg for each type of client. Regards, Brandon
▸
From: David Baldwin [mailto:user-cbbf693f2c89@xymon.invalid] Sent: Thursday, 5 March 2015 8:57 AM To: user-aada0fa38bf8@xymon.invalid; user-71895fb2e44c@xymon.invalid; Brandon Dale Cc: xymon at xymon.com Subject: Re: [Xymon] Xymon PowerShell Windows client Zak, Unfortunately, you can't fake the BBWin identifier for just one section – you have to change the client to report in as BBwin. It was changed so that we could experimentally use separate configuration options for BBWin clients and Powershell clients. To change how the client reports itself, change line 2746 in the current commit: 2745 WriteLog "Performing main and optional tests and building output..." 2746 $clout = "client " + $clientname + ".powershell powershell XymonPS" | Out-String 2747 $clsecs = XymonClientSections | Out-String In the original Powershell client, this line was: $clout = "client " + $clientname + ".bbwin win32" | Out-String So you can see we've changed '.bbwin' to '.powershell' and 'win32' to 'powershell'. I appreciate this isn't very good and should probably be a configuration item. Changing the client from bbwin to something else is less harmful. Changing class from win32 to powershell will probably break LOTS of stuff. I suspect many users migrating from BBWin use "class=win32" in analysis.cfg (hobbit-clients.cfg) file extensively. The class is probably also used in the section parsing -> status reports/RRD data extraction. It will also break the config segment returned from client-local.cfg - e.g. [win32] dir:C:\Windows\Temp log:c:\WINDOWS\WindowsUpdate.log:20480 David. -- David Baldwin - Senior Systems Administrator (Datacentres + Networks) Information and Communication Technology Services Australian Sports Commission http://ausport.gov.au Tel 02 62147830 Fax 02 62141830 PO Box 176 Belconnen ACT 2616
user-cbbf693f2c89@xymon.invalid<mailto:user-cbbf693f2c89@xymon.invalid> 1 Leverrier Street Bruce ACT 2617 Our Values: RESPECT + INTEGRITY + TEAMWORK + EXCELLENCE Keep up to date with what's happening in Australian sport visit www.ausport.gov.au<http://www.ausport.gov.au>;
▸
This message is intended for the addressee named and may contain confidential and privileged information. If you are not the intended recipient please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you receive this message in error, please delete it and notify the sender.
list Brandon Dale
That works [ifstat] fe80::25a5:b99d:55cd:951f 2725199676 586864638 10.250.100.163 2725199676 586864638 And it displays on the trends page. Still not perfect however as in most cases you don’t want to see both graphed as the traffic is going to be exactly the same. Ideally some logic to choose which to display would work best. Regards, Brandon
▸
From: user-aada0fa38bf8@xymon.invalid<mailto:user-aada0fa38bf8@xymon.invalid> [mailto:user-aada0fa38bf8@xymon.invalid] Sent: Thursday, 5 March 2015 2:16 AM To: Brandon Dale; user-71895fb2e44c@xymon.invalid<mailto:user-71895fb2e44c@xymon.invalid> Cc: xymon at xymon.com<mailto:xymon at xymon.com> Subject: RE: [Xymon] Xymon PowerShell Windows client Hi Thanks for the patch. Regarding the BBwin / powershell identifier, my proposal is to default to bbwin but to allow this to be overridden using the local client XML config – does this sound reasonable? The %<number> stuff is the zone index (https://en.wikipedia.org/wiki/IPv6_address#Link-local_addresses_and_zone_indices) – i.e. the adaptor number. I'm not sure how useful this is to Xymon and could probably be removed with a slight amendment to your patch like the following: function XymonIfstat { WriteLog "XymonIfstat start" "[ifstat]" [System.Net.NetworkInformation.NetworkInterface]::GetAllNetworkInterfaces() | ?{($_.OperationalStatus -eq "Up") -and ($_.NetworkInterfaceType -ne "loopback")} | %{ $ad = $_.GetIPv4Statistics() | select BytesSent, BytesReceived $ip = $_.GetIPProperties().UnicastAddresses | select Address # some interfaces have multiple IPs, so iterate over them reporting same stats $ip | %{ "{0} {1} {2}" -f ($_.Address.IPAddressToString –replace '%\d+'), $ad.BytesReceived,$ad.BytesSent } } WriteLog "XymonIfstat finished." } I have not tested this but I think it should work. Thanks Zak Beck Infrastructure Tech Support Specialist Accenture Tel: +XX (X) XXXX XXXXXX
Email: user-aada0fa38bf8@xymon.invalid<mailto:user-aada0fa38bf8@xymon.invalid>
▸
Upcoming PTO (leave): Feb 20th, April 7th-10th, Jul 3rd, Jul 24th-Aug 10th
Our core values: Stewardship - Best People - Client Value Creation - One Global Network - Respect for the Individual - Integrity
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.
Accenture means Accenture (UK) Limited (registered number 4757301), registered in England and Wales with registered address at 30 Fenchurch Street, London EC3M 3BD.
list David Baldwin
▸
On 5/03/15 10:07 AM, Brandon Dale wrote:
The problem is if you are running both bbwin and the powershell client you need a way to be able to setup separate commands in the client-local.cfg for each type of client.
If BBWin will just ignore (or at least be unaffected by) the ones it doesn't understand then that shouldn't be a problem, it's only if there are mutual incompatibilities that should be an issue. David.
Regards, *Brandon * *From:*David Baldwin [mailto:user-cbbf693f2c89@xymon.invalid]
▸
*Sent:* Thursday, 5 March 2015 8:57 AM *To:* user-aada0fa38bf8@xymon.invalid; user-71895fb2e44c@xymon.invalid; Brandon Dale *Cc:* xymon at xymon.com *Subject:* Re: [Xymon] Xymon PowerShell Windows client Zak, Unfortunately, you can't fake the BBWin identifier for just one section – you have to change the client to report in as BBwin. It was changed so that we could experimentally use separate configuration options for BBWin clients and Powershell clients. To change how the client reports itself, change line 2746 in the current commit: 2745 WriteLog "Performing main and optional tests and building output..." 2746 $clout = "client " + $clientname + ".powershell powershell XymonPS" | Out-String 2747 $clsecs = XymonClientSections | Out-String In the original Powershell client, this line was: $clout = "client " + $clientname + ".bbwin win32" | Out-String So you can see we've changed '.bbwin' to '.powershell' and 'win32' to 'powershell'. I appreciate this isn't very good and should probably be a configuration item. Changing the client from bbwin to something else is less harmful. Changing class from win32 to powershell will probably break LOTS of stuff. I suspect many users migrating from BBWin use "class=win32" in analysis.cfg (hobbit-clients.cfg) file extensively. The class is probably also used in the section parsing -> status reports/RRD data extraction. It will also break the config segment returned from client-local.cfg - e.g. [win32] dir:C:\Windows\Temp log:c:\WINDOWS\WindowsUpdate.log:20480 David. -- David Baldwin - Senior Systems Administrator (Datacentres + Networks) Information and Communication Technology Services Australian Sports Commission http://ausport.gov.au Tel 02 62147830 Fax 02 62141830 PO Box 176 Belconnen ACT 2616
user-cbbf693f2c89@xymon.invalid <mailto:user-cbbf693f2c89@xymon.invalid> 1 Leverrier Street Bruce ACT 2617 Our Values: RESPECT + INTEGRITY + TEAMWORK + EXCELLENCE Keep up to date with what's happening in Australian sport visit www.ausport.gov.au <http://www.ausport.gov.au>;
▸
This message is intended for the addressee named and may contain confidential and privileged information. If you are not the intended recipient please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you receive this message in error, please delete it and notify the sender.
-- David Baldwin - Senior Systems Administrator (Datacentres + Networks) Information and Communication Technology Services Australian Sports Commission http://ausport.gov.au Tel 02 62147830 Fax 02 62141830 PO Box 176 Belconnen ACT 2616 user-cbbf693f2c89@xymon.invalid 1 Leverrier Street Bruce ACT 2617 Our Values: RESPECT + INTEGRITY + TEAMWORK + EXCELLENCE
list Brandon Dale
Say I was mixing the commands and had this in client-local.cfg and it applied to both bbwin and powershell clients I might end up with something like: eventlogswanted:*:250000:warning,critical,error clientversion:1.98:\\testserver01\test\ eventlog:security:10240 ignore “insert some noisy informational event you are ignoring for bbwin but isn’t relevant for PowerShell as it’s not retrieving informational events” It looks confusing, the eventlog:log_name:max_size command would work for both clients just the powershell client won’t read the size. And Just in general it’s hard to tell which client is doing what. Maybe a solution is to have all the powershell commands start with something unique to the client so the commands can never overlap with bbwin.
▸
Regards,
Brandon
From: David Baldwin [mailto:user-cbbf693f2c89@xymon.invalid]
Sent: Thursday, 5 March 2015 10:46 AM
To: Brandon Dale; user-aada0fa38bf8@xymon.invalid; user-71895fb2e44c@xymon.invalid
Cc: xymon at xymon.com
Subject: Re: [Xymon] Xymon PowerShell Windows client
On 5/03/15 10:07 AM, Brandon Dale wrote:
The problem is if you are running both bbwin and the powershell client you need a way to be able to setup separate commands in the client-local.cfg for each type of client.
If BBWin will just ignore (or at least be unaffected by) the ones it doesn't understand then that shouldn't be a problem, it's only if there are mutual incompatibilities that should be an issue.
David.
Regards,
Brandon
list Zak Beck
Hi David
First of all, thanks for providing us with a great starting point with the Powershell client.
We've discussed this in-house and agree that the best long term solution would be to fix/extend the server code. Now, it's been a long time since I looked at any C code, but it looks to me (looking at commit 7594 in trunk) that do_ifstat.c needs the following addition:
case OS_SCO_SV:
if (pickdata(bol, ifstat_sco_sv_pcres[0], 0, &ifname, &rxstr, &txstr)) dmatch = 7;
break;
+ case OS_WIN32_POWERSHELL:
case OS_WIN32_BBWIN:
if (pickdata(bol, ifstat_bbwin_pcres[0], 0, &ifname, &rxstr, &txstr)) dmatch = 7;
break;
Zak
▸
From: David Baldwin [mailto:user-cbbf693f2c89@xymon.invalid]
Sent: 04 March 2015 23:50
To: Jeremy Laidman; Beck, Zak
Subject: Re: [Xymon] Xymon PowerShell Windows client
On 5/03/15 10:00 AM, Jeremy Laidman wrote:
On 04/03/2015 7:49 PM, <user-aada0fa38bf8@xymon.invalid <mailto:user-aada0fa38bf8@xymon.invalid> > wrote:Unfortunately, you can't fake the BBWin identifier for just one section – you have to change the client to report in as BBwin. It was changed so that we could experimentally use separate configuration options for BBWin clients and Powershell clients.
Of course the best option is to extend the server to match the features of the client. It wouldn't take much (like one line) to add the powershell OS into the ifstat handler, running the same code as for bbwin.
I took a look at the current code in trunk today - the powershell client (however that is detected) looks like it is treated the same as BBWin at present. Server-side extension in the C code is fine for those comfortable with that, but makes it difficult for those wanting to just try out the new client against an existing server.
David.
J
▸
-- David Baldwin - Senior Systems Administrator (Datacentres + Networks) Information and Communication Technology Services Australian Sports Commission http://ausport.gov.au Tel 02 62147830 Fax 02 62141830 PO Box 176 Belconnen ACT 2616 user-cbbf693f2c89@xymon.invalid <mailto:user-cbbf693f2c89@xymon.invalid> 1 Leverrier Street Bruce ACT 2617 Our Values: RESPECT + INTEGRITY + TEAMWORK + EXCELLENCE Keep up to date with what's happening in Australian sport visit www.ausport.gov.au <http://www.ausport.gov.au>; This message is intended for the addressee named and may contain confidential and privileged information. If you are not the intended recipient please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you receive this message in error, please delete it and notify the sender.
list Dirk Kastens
Hi,
I just downloaded the latest version of the Powershell client. I tried to install ist on a 64bit Windows 7 machine. The installation works, but I can't get the service to start.
The first thing is, that powershell complains about the xymonclient.ps1 not being digitally signed. So I set the execution policy to unrestricted. When I try to start the service I get the following message:
PS C:\Program Files\xymon> .\xymonclient.ps1 start
start-service : Fehler beim Starten des Diensts "XymonPSClient (XymonPSClient)".
In C:\Program Files\xymon\xymonclient.ps1:2708 Zeichen:60
+ if((get-service $xymonsvcname).Status -ne "Running") { start-service $xymons ...
+ ~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.ServiceProcess.ServiceController:ServiceController) [Start-Service], ServiceCommandException
+ FullyQualifiedErrorId : StartServiceFailed,Microsoft.PowerShell.Commands.StartServiceCommand
When I try to start the service manually with start-service I get:
PS C:\Program Files\xymon> Start-Service XymonPSClient
Start-Service : Fehler beim Starten des Diensts "XymonPSClient (XymonPSClient)".
In Zeile:1 Zeichen:1
+ Start-Service XymonPSClient
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.ServiceProcess.ServiceController:ServiceController) [Start-Service], ServiceCommandException
+ FullyQualifiedErrorId : StartServiceFailed,Microsoft.PowerShell.Commands.StartServiceCommand
Any ideas what could be wrong?
Dirk
list Scot Kreienkamp
Dirk, I don't read German, but I can guess what might be wrong. When I downloaded the script it was blocked from executing by Windows. I had to right click on the script, select properties, and there was an unblock button. It only had to be done once. That property stays with the script when you copy it to other computers. Scot Kreienkamp
-----Original Message----- From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Dirk Kastens Sent: Thursday, March 12, 2015 4:50 AM
▸
To: xymon at xymon.com
Subject: Re: [Xymon] Xymon Powershell Windows client
Hi,
I just downloaded the latest version of the Powershell client. I tried
to install ist on a 64bit Windows 7 machine. The installation works, but
I can't get the service to start.
The first thing is, that powershell complains about the xymonclient.ps1
not being digitally signed. So I set the execution policy to
unrestricted. When I try to start the service I get the following message:
PS C:\Program Files\xymon> .\xymonclient.ps1 start
start-service : Fehler beim Starten des Diensts "XymonPSClient
(XymonPSClient)".
In C:\Program Files\xymon\xymonclient.ps1:2708 Zeichen:60
+ if((get-service $xymonsvcname).Status -ne "Running") {
start-service $xymons ...
• ~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError:
(System.ServiceProcess.ServiceController:ServiceController)
[Start-Service], ServiceCommandException
+ FullyQualifiedErrorId :
StartServiceFailed,Microsoft.PowerShell.Commands.StartServiceCommand
When I try to start the service manually with start-service I get:
PS C:\Program Files\xymon> Start-Service XymonPSClient
Start-Service : Fehler beim Starten des Diensts "XymonPSClient
(XymonPSClient)".
In Zeile:1 Zeichen:1
+ Start-Service XymonPSClient
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError:
(System.ServiceProcess.ServiceController:ServiceController)
[Start-Service], ServiceCommandException
+ FullyQualifiedErrorId :
StartServiceFailed,Microsoft.PowerShell.Commands.StartServiceCommand
Any ideas what could be wrong?
DirkThis message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, please note that you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by e-mail or by telephone at the above number. Thank you.
list Dirk Kastens
Hi Scot,
I don't read German, but I can guess what might be wrong. When I downloaded the script it was blocked from executing by Windows. I had to right click on the script, select properties, and there was an unblock button. It only had to be done once. That property stays with the script when you copy it to other computers.
That was it!!! I didn't know about this property. Thanks for your help. Dirk
list Japheth Cleaver
Hi all, For some reason, my spam filter seems to have been penalizing xymon emails (perhaps a few too many commits coming through ;) ), and I missed this entire thread. I've just pushed an update into 4.3.19 that should take care of adding this into the RRD parsers: https://sourceforge.net/p/xymon/code/7609/. It seems to work on reports from my Win8x64 machine, but additional testing and validation would be greatly appreciated. In somewhat related news: I'm still looking at a few bug reports that I believe I missed (thank goodness for list archives!), but I'm currently hoping to put together a 4.3.19-RC1 within the next few days. And if all goes well, a full release perhaps by the end of this coming week. Regards, -jc