Windows XymonPSClient v2.37 🔗 link

The key fixes are:

* replaced WMI call to get number of processors with Windows API call

The WMI call to get processor information was taking anything from 4-5 seconds on most of my VMs, some experience much longer waits and high CPU usage while this WMI call executed. There have also been instances where the WMI call returns incorrect data or no data. This has been replaced with a call to GetNativeSystemInfo(), which should work on 32-bit and 64-bit platforms and in testing executes in milliseconds.

* only supply diskpart data if EnableDiskPart = 1

There is a test in the client which uses ‘diskpart’ to gather information about clustering every slow scan. This is included in the data sent to Xymon, but it’s not generally displayed – you can extract it for reporting if needed. Hardly anyone uses this and for some reason for some people it is causing memory issues in the Microsoft Virtual Disk Service. Therefore by default the test will now not be run, you can enable it with the EnableDiskPart setting in xymonclient_config.xml.

* add a dummy, ignored config item in the internal client-local config table so that there is always some configuration present (even if nothing in the server-side client-local for this host)

We found that if there is no client-local.cfg for the host and no default client-local.cfg (like [powershell] or [XymonPS]), on some platforms there appears to be a memory leak. The fix ensures there is always something in the internal cache of client-config even if nothing is received from the server.

* XymonAcceptUTF8 - default (0) is now to use the original ASCII encoding, added setting for 'pure' ASCII coding which strips/converts diacritic characters

Prior to this version, by default, the client uses ASCII encoding to send to the server but also attempts to encode/filter diacritic characters. This was added in v2.20, and for some people it adds a large time overhead when sending data.

It’s been changed so that the default setting of 0 acts like it did before v2.20 – no diacritic encoding – I’m calling this ‘original’ ASCII encoding. XymonAcceptUTF8 = 1 is unchanged, uses UTF8. XymonAcceptUTF8 = 2 is the v2.20 setting, use ASCII and encode/filter diacritics – I’m calling this ‘pure’ ASCII encoding. I don’t think this will impact on many people other than saving time/cpu for the default setting.

Full changelog:

v2.37

* replaced WMI call to get number of processors with Windows API call

* fixed servicecheck parentheses

* use TLS for uploading data to xymoncgi if using http reporting and URL begins https

* add milliseconds to log timestamp

* add a dummy, ignored config item in the internal client-local config table so that there is always some configuration present (even if nothing in the server-side client-local for this host)

* fix a couple of instances where we were using variables before they are assigned

settings changes/additions:

* XymonAcceptUTF8 - default (0) is now to use the original ASCII encoding, added setting for 'pure' ASCII coding which strips/converts diacritic characters

* only supply diskpart data if EnableDiskPart = 1

Zak


This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential 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. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.

www.accenture.com

I'm trying to remotely update a v2.28 client to the latest 2.37 version by following the instructions in the XymonPSClient.doc, but the client isn't updating.  Here's what I've done.  Maybe I'm missing something.

1. Download the latest xymonclient.ps1 from github and place it in my server's scripts directory.  (This is the directory where I run other client scripts successfully)

2. Rename the xymonclient.ps1 file to xymonclient_2.37.ps1 (per the doc instructions)

3. Get the md5sum of the file

4. Add the following line to the client-local.cfg file on the server for the specific host I'm trying to update. (per the doc instructions)

5. Check that the xymonclient_config.xml on the client has
<clientremotecfgexec>1</clientremotecfgexec>

When I look at the logs on the client it says it sees the instruction from the server, but it doesn't perform any action.  The client version never changes.


Kris Springer


On 2/15/19 5:03 AM, Beck, Zak wrote:
Hi

I have committed v2.37 today, this has a big performance related fix and other fixes - thanks to SebA <user-4631430d620a@xymon.invalid<mailto:user-4631430d620a@xymon.invalid>> and Andy user-982f5f6d4d28@xymon.invalid<mailto:user-982f5f6d4d28@xymon.invalid> for extra work and prompting in this area.

The key fixes are:

* replaced WMI call to get number of processors with Windows API call

The WMI call to get processor information was taking anything from 4-5 seconds on most of my VMs, some experience much longer waits and high CPU usage while this WMI call executed. There have also been instances where the WMI call returns incorrect data or no data. This has been replaced with a call to GetNativeSystemInfo(), which should work on 32-bit and 64-bit platforms and in testing executes in milliseconds.

* only supply diskpart data if EnableDiskPart = 1

There is a test in the client which uses 'diskpart' to gather information about clustering every slow scan. This is included in the data sent to Xymon, but it's not generally displayed - you can extract it for reporting if needed. Hardly anyone uses this and for some reason for some people it is causing memory issues in the Microsoft Virtual Disk Service. Therefore by default the test will now not be run, you can enable it with the EnableDiskPart setting in xymonclient_config.xml.

* add a dummy, ignored config item in the internal client-local config table so that there is always some configuration present (even if nothing in the server-side client-local for this host)

We found that if there is no client-local.cfg for the host and no default client-local.cfg (like [powershell] or [XymonPS]), on some platforms there appears to be a memory leak. The fix ensures there is always something in the internal cache of client-config even if nothing is received from the server.

* XymonAcceptUTF8 - default (0) is now to use the original ASCII encoding, added setting for 'pure' ASCII coding which strips/converts diacritic characters

Prior to this version, by default, the client uses ASCII encoding to send to the server but also attempts to encode/filter diacritic characters. This was added in v2.20, and for some people it adds a large time overhead when sending data.

It's been changed so that the default setting of 0 acts like it did before v2.20 - no diacritic encoding - I'm calling this 'original' ASCII encoding. XymonAcceptUTF8 = 1 is unchanged, uses UTF8. XymonAcceptUTF8 = 2 is the v2.20 setting, use ASCII and encode/filter diacritics - I'm calling this 'pure' ASCII encoding. I don't think this will impact on many people other than saving time/cpu for the default setting.

Full changelog:

v2.37
* replaced WMI call to get number of processors with Windows API call
* fixed servicecheck parentheses
* use TLS for uploading data to xymoncgi if using http reporting and URL begins https
* add milliseconds to log timestamp
* add a dummy, ignored config item in the internal client-local config table so that there is always some configuration present (even if nothing in the server-side client-local for this host)
* fix a couple of instances where we were using variables before they are assigned

settings changes/additions:
* XymonAcceptUTF8 - default (0) is now to use the original ASCII encoding, added setting for 'pure' ASCII coding which strips/converts diacritic characters
* only supply diskpart data if EnableDiskPart = 1


Zak


This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential 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. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.

On 2/20/19 8:58 AM, Beck, Zak wrote:

Hi

The client only updates on slowscans – usually every 6 hours – one of 
first lines in the logs will tell which scan number you are on and 
which will be the next slow scan.

You can force a slow scan by stop/starting the service.

If you have waited more than 6 hours, then you have some other issue – 
can you check the log on a slow scan? Usually easiest to do this by 
stopping the service and then running the client manually in a 
Powershell prompt.

Cheers

Zak

*Sent:* Wednesday, 20 February 2019 15:39
*To:* Beck, Zak <user-aada0fa38bf8@xymon.invalid>; Xymon MailingList 
<xymon at xymon.com>
*Subject:* [External] Re: [Xymon] Windows XymonPSClient v2.37

This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly 
with links and attachments.


I'm trying to remotely update a v2.28 client to the latest 2.37 
version by following the instructions in the XymonPSClient.doc, but 
the client isn't updating.  Here's what I've done.  Maybe I'm missing 
something.

1. Download the latest xymonclient.ps1 from github and place it in my 
server's scripts directory.  (This is the directory where I run other 
client scripts successfully)

2. Rename the xymonclient.ps1 file to xymonclient_2.37.ps1 (per the 
doc instructions)

3. Get the md5sum of the file

4. Add the following line to the client-local.cfg file on the server 
for the specific host I'm trying to update. (per the doc instructions)
clientversion:2.37:https://my.domain.com/xymon/scripts:MD5:md5sumadlkfskdkfkfdl 

On 2/15/19 5:03 AM, Beck, Zak wrote:

    Hi

    I have committed v2.37 today, this has a big performance related
    fix and other fixes – thanks to SebA <user-4631430d620a@xymon.invalid
    <mailto:user-4631430d620a@xymon.invalid>> and Andy user-982f5f6d4d28@xymon.invalid
    <mailto:user-982f5f6d4d28@xymon.invalid> for extra work and prompting in this area.

    Download from SVN

    (the documentation has been updated also, including uninstall
    instructions).

    The key fixes are:

    * replaced WMI call to get number of processors with Windows API call

    The WMI call to get processor information was taking anything from
    4-5 seconds on most of my VMs, some experience much longer waits
    and high CPU usage while this WMI call executed. There have also
    been instances where the WMI call returns incorrect data or no
    data. This has been replaced with a call to GetNativeSystemInfo(),
    which should work on 32-bit and 64-bit platforms and in testing
    executes in milliseconds.

    * only supply diskpart data if EnableDiskPart = 1

    There is a test in the client which uses ‘diskpart’ to gather
    information about clustering every slow scan. This is included in
    the data sent to Xymon, but it’s not generally displayed – you can
    extract it for reporting if needed. Hardly anyone uses this and
    for some reason for some people it is causing memory issues in the
    Microsoft Virtual Disk Service. Therefore by default the test will
    now not be run, you can enable it with the EnableDiskPart setting
    in xymonclient_config.xml.

    * add a dummy, ignored config item in the internal client-local
    config table so that there is always some configuration present
    (even if nothing in the server-side client-local for this host)

    We found that if there is no client-local.cfg for the host and no
    default client-local.cfg (like [powershell] or [XymonPS]), on some
    platforms there appears to be a memory leak. The fix ensures there
    is always something in the internal cache of client-config even if
    nothing is received from the server.

    * XymonAcceptUTF8 - default (0) is now to use the original ASCII
    encoding, added setting for 'pure' ASCII coding which
    strips/converts diacritic characters

    Prior to this version, by default, the client uses ASCII encoding
    to send to the server but also attempts to encode/filter diacritic
    characters. This was added in v2.20, and for some people it adds a
    large time overhead when sending data.

    It’s been changed so that the default setting of 0 acts like it
    did before v2.20 – no diacritic encoding – I’m calling this
    ‘original’ ASCII encoding. XymonAcceptUTF8 = 1 is unchanged, uses
    UTF8. XymonAcceptUTF8 = 2 is the v2.20 setting, use ASCII and
    encode/filter diacritics – I’m calling this ‘pure’ ASCII encoding.
    I don’t think this will impact on many people other than saving
    time/cpu for the default setting.

    Full changelog:

    v2.37

    * replaced WMI call to get number of processors with Windows API call

    * fixed servicecheck parentheses

    * use TLS for uploading data to xymoncgi if using http reporting
    and URL begins https

    * add milliseconds to log timestamp

    * add a dummy, ignored config item in the internal client-local
    config table so that there is always some configuration present
    (even if nothing in the server-side client-local for this host)

    * fix a couple of instances where we were using variables before
    they are assigned

    settings changes/additions:

    * XymonAcceptUTF8 - default (0) is now to use the original ASCII
    encoding, added setting for 'pure' ASCII coding which
    strips/converts diacritic characters

    * only supply diskpart data if EnableDiskPart = 1

    Zak


    This message is for the designated recipient only and may contain
    privileged, proprietary, or otherwise confidential 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. Your privacy is
    important to us. Accenture uses your personal data only in
    compliance with data protection laws. For further information on
    how Accenture processes your personal data, please see our privacy
    statement at https://www.accenture.com/us-en/privacy-policy.

wrote:

I left it running overnight to see if the slowscan was the issue, but the
cycle has passed more than once now.  The current log said it was on
collection 36 of 72.

I just restarted the service, waited 15 minutes to let things cycle a few
times, but still no update is occurring.

Here's the last few lines of the xymonclient.log

2019-02-20 08:48:16  Connecting to host 10.0.0.55
2019-02-20 08:48:16  Sent 84667 bytes to server
2019-02-20 08:48:16  Received 101 bytes from server
2019-02-20 08:48:16  RepeatTests: nothing to do!
2019-02-20 08:48:16  Using new remote config, saving locally

2019-02-20 08:48:16  XymonLogSend: nothing to do!
2019-02-20 08:48:16  Delaying until next run: 295.3749488 seconds

Kris Springer


On 2/20/19 8:58 AM, Beck, Zak wrote:

Hi


The client only updates on slowscans – usually every 6 hours – one of
first lines in the logs will tell which scan number you are on and which
will be the next slow scan.


You can force a slow scan by stop/starting the service.


If you have waited more than 6 hours, then you have some other issue – can
you check the log on a slow scan? Usually easiest to do this by stopping
the service and then running the client manually in a Powershell prompt.


Cheers


Zak


*From:* Kris Springer <user-c2caa0a7a8d5@xymon.invalid>
<user-c2caa0a7a8d5@xymon.invalid>
*Sent:* Wednesday, 20 February 2019 15:39
*To:* Beck, Zak <user-aada0fa38bf8@xymon.invalid> <user-aada0fa38bf8@xymon.invalid>; Xymon
MailingList <xymon at xymon.com> <xymon at xymon.com>
*Subject:* [External] Re: [Xymon] Windows XymonPSClient v2.37


This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with
links and attachments.


I'm trying to remotely update a v2.28 client to the latest 2.37 version by
following the instructions in the XymonPSClient.doc, but the client isn't
updating.  Here's what I've done.  Maybe I'm missing something.

1. Download the latest xymonclient.ps1 from github and place it in my
server's scripts directory.  (This is the directory where I run other
client scripts successfully)

2. Rename the xymonclient.ps1 file to xymonclient_2.37.ps1 (per the doc
instructions)

3. Get the md5sum of the file

4. Add the following line to the client-local.cfg file on the server for
the specific host I'm trying to update. (per the doc instructions)

<https://urldefense.proofpoint.com/v2/url?u=https-3A__my.domain.com_xymon_scripts-3AMD5-3Amd5sumadlkfskdkfkfdl&d=DwMD-g&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=S-aLwpx-PHBTBMIG_c2JczRC0SfuZCmsiH9Iams25FI&m=nCeHIt-8vEpIrED5Cu3dEPfxpWypoQE_ddD6QQAX9Ws&s=05m99yiMkc-55R1AKXecttl5doV-7QYCPGCbqVr5S_s&e=>;

5. Check that the xymonclient_config.xml on the client has
<clientremotecfgexec>1</clientremotecfgexec>

When I look at the logs on the client it says it sees the instruction from
the server, but it doesn't perform any action.  The client version never
changes.


Kris Springer


On 2/15/19 5:03 AM, Beck, Zak wrote:

Hi


I have committed v2.37 today, this has a big performance related fix and

Download from SVN
<https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_p_xymon_code_HEAD_tree_sandbox_WinPSClient_&d=DwMD-g&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=S-aLwpx-PHBTBMIG_c2JczRC0SfuZCmsiH9Iams25FI&m=nCeHIt-8vEpIrED5Cu3dEPfxpWypoQE_ddD6QQAX9Ws&s=L-dhmcu_CM75-ARQ7kmDxV7wP_abxGZqOuUDmZXC-RE&e=>;
(the documentation has been updated also, including uninstall instructions).


The key fixes are:


* replaced WMI call to get number of processors with Windows API call


The WMI call to get processor information was taking anything from 4-5
seconds on most of my VMs, some experience much longer waits and high CPU
usage while this WMI call executed. There have also been instances where
the WMI call returns incorrect data or no data. This has been replaced with
a call to GetNativeSystemInfo(), which should work on 32-bit and 64-bit
platforms and in testing executes in milliseconds.


* only supply diskpart data if EnableDiskPart = 1


There is a test in the client which uses ‘diskpart’ to gather information
about clustering every slow scan. This is included in the data sent to
Xymon, but it’s not generally displayed – you can extract it for reporting
if needed. Hardly anyone uses this and for some reason for some people it
is causing memory issues in the Microsoft Virtual Disk Service. Therefore
by default the test will now not be run, you can enable it with the
EnableDiskPart setting in xymonclient_config.xml.


* add a dummy, ignored config item in the internal client-local config
table so that there is always some configuration present (even if nothing
in the server-side client-local for this host)


We found that if there is no client-local.cfg for the host and no default
client-local.cfg (like [powershell] or [XymonPS]), on some platforms there
appears to be a memory leak. The fix ensures there is always something in
the internal cache of client-config even if nothing is received from the
server.


* XymonAcceptUTF8 - default (0) is now to use the original ASCII encoding,
added setting for 'pure' ASCII coding which strips/converts diacritic
characters


Prior to this version, by default, the client uses ASCII encoding to send
to the server but also attempts to encode/filter diacritic characters. This
was added in v2.20, and for some people it adds a large time overhead when
sending data.


It’s been changed so that the default setting of 0 acts like it did before
v2.20 – no diacritic encoding – I’m calling this ‘original’ ASCII encoding.
XymonAcceptUTF8 = 1 is unchanged, uses UTF8. XymonAcceptUTF8 = 2 is the
v2.20 setting, use ASCII and encode/filter diacritics – I’m calling this
‘pure’ ASCII encoding. I don’t think this will impact on many people other
than saving time/cpu for the default setting.


Full changelog:


v2.37

* replaced WMI call to get number of processors with Windows API call

* fixed servicecheck parentheses

* use TLS for uploading data to xymoncgi if using http reporting and URL
begins https

* add milliseconds to log timestamp

* add a dummy, ignored config item in the internal client-local config
table so that there is always some configuration present (even if nothing
in the server-side client-local for this host)

* fix a couple of instances where we were using variables before they are
assigned


settings changes/additions:

* XymonAcceptUTF8 - default (0) is now to use the original ASCII encoding,
added setting for 'pure' ASCII coding which strips/converts diacritic
characters

* only supply diskpart data if EnableDiskPart = 1


Zak


This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise confidential 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. Your privacy is important to us.
Accenture uses your personal data only in compliance with data protection
laws. For further information on how Accenture processes your personal
data, please see our privacy statement at
https://www.accenture.com/us-en/privacy-policy.


www.accenture.com

On 2/20/19 12:18 PM, Timothy Williams wrote:

Likely the URL is not accessible from the box. Try to use the bb:// 
version to pick up file from xymon/download folder. I had issues a few 
weeks ago on one of my networks reaching any HTTP sites, but the bb:// 
uses TCP port 1984 directly off Xymon server..

clientversion:2.37:bb://

Tim Williams


On Wed, Feb 20, 2019 at 11:55 AM Kris Springer 
<user-c2caa0a7a8d5@xymon.invalid <mailto:user-c2caa0a7a8d5@xymon.invalid>> wrote:

    I left it running overnight to see if the slowscan was the issue,
    but the cycle has passed more than once now.  The current log said
    it was on collection 36 of 72.

    I just restarted the service, waited 15 minutes to let things
    cycle a few times, but still no update is occurring.

    Here's the last few lines of the xymonclient.log

    2019-02-20 08:48:16  Connecting to host 10.0.0.55
    2019-02-20 08:48:16  Sent 84667 bytes to server
    2019-02-20 08:48:16  Received 101 bytes from server
    2019-02-20 08:48:16  RepeatTests: nothing to do!
    2019-02-20 08:48:16  Using new remote config, saving locally
    2019-02-20 08:48:16  Found a command:
    clientversion:2.37:https://redacted.com/xymon/scripts|MD5|a438ab32188505438e41444558578477

    On 2/20/19 8:58 AM, Beck, Zak wrote:

    Hi

    The client only updates on slowscans – usually every 6 hours –
    one of first lines in the logs will tell which scan number you
    are on and which will be the next slow scan.

    You can force a slow scan by stop/starting the service.

    If you have waited more than 6 hours, then you have some other
    issue – can you check the log on a slow scan? Usually easiest to
    do this by stopping the service and then running the client
    manually in a Powershell prompt.

    Cheers

    Zak

    *From:*Kris Springer <user-c2caa0a7a8d5@xymon.invalid>
    *Sent:* Wednesday, 20 February 2019 15:39
    *To:* Beck, Zak <user-aada0fa38bf8@xymon.invalid>

    *Subject:* [External] Re: [Xymon] Windows XymonPSClient v2.37

    This message is from an EXTERNAL SENDER - be CAUTIOUS,
    particularly with links and attachments.


    I'm trying to remotely update a v2.28 client to the latest 2.37
    version by following the instructions in the XymonPSClient.doc,
    but the client isn't updating.  Here's what I've done.  Maybe I'm
    missing something.

    1. Download the latest xymonclient.ps1 from github and place it
    in my server's scripts directory.  (This is the directory where I
    run other client scripts successfully)

    2. Rename the xymonclient.ps1 file to xymonclient_2.37.ps1 (per
    the doc instructions)

    3. Get the md5sum of the file

    4. Add the following line to the client-local.cfg file on the
    server for the specific host I'm trying to update. (per the doc
    instructions)
    clientversion:2.37:https://my.domain.com/xymon/scripts:MD5:md5sumadlkfskdkfkfdl
    <https://urldefense.proofpoint.com/v2/url?u=https-3A__my.domain.com_xymon_scripts-3AMD5-3Amd5sumadlkfskdkfkfdl&d=DwMD-g&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=S-aLwpx-PHBTBMIG_c2JczRC0SfuZCmsiH9Iams25FI&m=nCeHIt-8vEpIrED5Cu3dEPfxpWypoQE_ddD6QQAX9Ws&s=05m99yiMkc-55R1AKXecttl5doV-7QYCPGCbqVr5S_s&e=>;

    5. Check that the xymonclient_config.xml on the client has
    <clientremotecfgexec>1</clientremotecfgexec>

    When I look at the logs on the client it says it sees the
    instruction from the server, but it doesn't perform any action. 
    The client version never changes.


    Kris Springer
      
      
    On 2/15/19 5:03 AM, Beck, Zak wrote:

        Hi

        I have committed v2.37 today, this has a big performance
        related fix and other fixes – thanks to SebA
        <user-4631430d620a@xymon.invalid <mailto:user-4631430d620a@xymon.invalid>> and Andy
        user-982f5f6d4d28@xymon.invalid <mailto:user-982f5f6d4d28@xymon.invalid> for extra work
        and prompting in this area.

        Download from SVN
        <https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_p_xymon_code_HEAD_tree_sandbox_WinPSClient_&d=DwMD-g&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=S-aLwpx-PHBTBMIG_c2JczRC0SfuZCmsiH9Iams25FI&m=nCeHIt-8vEpIrED5Cu3dEPfxpWypoQE_ddD6QQAX9Ws&s=L-dhmcu_CM75-ARQ7kmDxV7wP_abxGZqOuUDmZXC-RE&e=>;
        (the documentation has been updated also, including uninstall
        instructions).

        The key fixes are:

        * replaced WMI call to get number of processors with Windows
        API call

        The WMI call to get processor information was taking anything
        from 4-5 seconds on most of my VMs, some experience much
        longer waits and high CPU usage while this WMI call executed.
        There have also been instances where the WMI call returns
        incorrect data or no data. This has been replaced with a call
        to GetNativeSystemInfo(), which should work on 32-bit and
        64-bit platforms and in testing executes in milliseconds.

        * only supply diskpart data if EnableDiskPart = 1

        There is a test in the client which uses ‘diskpart’ to gather
        information about clustering every slow scan. This is
        included in the data sent to Xymon, but it’s not generally
        displayed – you can extract it for reporting if needed.
        Hardly anyone uses this and for some reason for some people
        it is causing memory issues in the Microsoft Virtual Disk
        Service. Therefore by default the test will now not be run,
        you can enable it with the EnableDiskPart setting in
        xymonclient_config.xml.

        * add a dummy, ignored config item in the internal
        client-local config table so that there is always some
        configuration present (even if nothing in the server-side
        client-local for this host)

        We found that if there is no client-local.cfg for the host
        and no default client-local.cfg (like [powershell] or
        [XymonPS]), on some platforms there appears to be a memory
        leak. The fix ensures there is always something in the
        internal cache of client-config even if nothing is received
        from the server.

        * XymonAcceptUTF8 - default (0) is now to use the original
        ASCII encoding, added setting for 'pure' ASCII coding which
        strips/converts diacritic characters

        Prior to this version, by default, the client uses ASCII
        encoding to send to the server but also attempts to
        encode/filter diacritic characters. This was added in v2.20,
        and for some people it adds a large time overhead when
        sending data.

        It’s been changed so that the default setting of 0 acts like
        it did before v2.20 – no diacritic encoding – I’m calling
        this ‘original’ ASCII encoding. XymonAcceptUTF8 = 1 is
        unchanged, uses UTF8. XymonAcceptUTF8 = 2 is the v2.20
        setting, use ASCII and encode/filter diacritics – I’m calling
        this ‘pure’ ASCII encoding. I don’t think this will impact on
        many people other than saving time/cpu for the default setting.

        Full changelog:

        v2.37

        * replaced WMI call to get number of processors with Windows
        API call

        * fixed servicecheck parentheses

        * use TLS for uploading data to xymoncgi if using http
        reporting and URL begins https

        * add milliseconds to log timestamp

        * add a dummy, ignored config item in the internal
        client-local config table so that there is always some
        configuration present (even if nothing in the server-side
        client-local for this host)

        * fix a couple of instances where we were using variables
        before they are assigned

        settings changes/additions:

        * XymonAcceptUTF8 - default (0) is now to use the original
        ASCII encoding, added setting for 'pure' ASCII coding which
        strips/converts diacritic characters

        * only supply diskpart data if EnableDiskPart = 1

        Zak


        This message is for the designated recipient only and may
        contain privileged, proprietary, or otherwise confidential
        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. Your privacy is important to us.
        Accenture uses your personal data only in compliance with
        data protection laws. For further information on how
        Accenture processes your personal data, please see our
        privacy statement at
        https://www.accenture.com/us-en/privacy-policy.

        www.accenture.com <http://www.accenture.com>;


        Xymon at xymon.com  <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.xymon.com_mailman_listinfo_xymon&d=DwMD-g&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=S-aLwpx-PHBTBMIG_c2JczRC0SfuZCmsiH9Iams25FI&m=nCeHIt-8vEpIrED5Cu3dEPfxpWypoQE_ddD6QQAX9Ws&s=dlri1VGEnUrfF1SmKT2_B0vclSkFM--ZA8iIjLbfCtk&e=>;

          

Kris Springer


On 2/20/19 8:58 AM, Beck, Zak wrote:

Hi

The client only updates on slowscans – usually every 6 hours – one of 
first lines in the logs will tell which scan number you are on and 
which will be the next slow scan.

You can force a slow scan by stop/starting the service.

If you have waited more than 6 hours, then you have some other issue – 
can you check the log on a slow scan? Usually easiest to do this by 
stopping the service and then running the client manually in a 
Powershell prompt.

Cheers

Zak

*From:*Kris Springer <user-c2caa0a7a8d5@xymon.invalid>
*Sent:* Wednesday, 20 February 2019 15:39
*To:* Beck, Zak <user-aada0fa38bf8@xymon.invalid>; Xymon MailingList 
<xymon at xymon.com>
*Subject:* [External] Re: [Xymon] Windows XymonPSClient v2.37

This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly 
with links and attachments.


I'm trying to remotely update a v2.28 client to the latest 2.37 
version by following the instructions in the XymonPSClient.doc, but 
the client isn't updating.  Here's what I've done.  Maybe I'm missing 
something.

1. Download the latest xymonclient.ps1 from github and place it in my 
server's scripts directory.  (This is the directory where I run other 
client scripts successfully)

2. Rename the xymonclient.ps1 file to xymonclient_2.37.ps1 (per the 
doc instructions)

3. Get the md5sum of the file

4. Add the following line to the client-local.cfg file on the server 
for the specific host I'm trying to update. (per the doc instructions)
clientversion:2.37:https://my.domain.com/xymon/scripts:MD5:md5sumadlkfskdkfkfdl 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__my.domain.com_xymon_scripts-3AMD5-3Amd5sumadlkfskdkfkfdl&d=DwMD-g&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=S-aLwpx-PHBTBMIG_c2JczRC0SfuZCmsiH9Iams25FI&m=nCeHIt-8vEpIrED5Cu3dEPfxpWypoQE_ddD6QQAX9Ws&s=05m99yiMkc-55R1AKXecttl5doV-7QYCPGCbqVr5S_s&e=>;

5. Check that the xymonclient_config.xml on the client has
<clientremotecfgexec>1</clientremotecfgexec>

When I look at the logs on the client it says it sees the instruction 
from the server, but it doesn't perform any action.  The client 
version never changes.


Kris Springer
  
  
On 2/15/19 5:03 AM, Beck, Zak wrote:

    Hi

    I have committed v2.37 today, this has a big performance related
    fix and other fixes – thanks to SebA <user-4631430d620a@xymon.invalid
    <mailto:user-4631430d620a@xymon.invalid>> and Andy user-982f5f6d4d28@xymon.invalid
    <mailto:user-982f5f6d4d28@xymon.invalid> for extra work and prompting in this area.

    Download from SVN
    <https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_p_xymon_code_HEAD_tree_sandbox_WinPSClient_&d=DwMD-g&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=S-aLwpx-PHBTBMIG_c2JczRC0SfuZCmsiH9Iams25FI&m=nCeHIt-8vEpIrED5Cu3dEPfxpWypoQE_ddD6QQAX9Ws&s=L-dhmcu_CM75-ARQ7kmDxV7wP_abxGZqOuUDmZXC-RE&e=>;
    (the documentation has been updated also, including uninstall
    instructions).

    The key fixes are:

    * replaced WMI call to get number of processors with Windows API call

    The WMI call to get processor information was taking anything from
    4-5 seconds on most of my VMs, some experience much longer waits
    and high CPU usage while this WMI call executed. There have also
    been instances where the WMI call returns incorrect data or no
    data. This has been replaced with a call to GetNativeSystemInfo(),
    which should work on 32-bit and 64-bit platforms and in testing
    executes in milliseconds.

    * only supply diskpart data if EnableDiskPart = 1

    There is a test in the client which uses ‘diskpart’ to gather
    information about clustering every slow scan. This is included in
    the data sent to Xymon, but it’s not generally displayed – you can
    extract it for reporting if needed. Hardly anyone uses this and
    for some reason for some people it is causing memory issues in the
    Microsoft Virtual Disk Service. Therefore by default the test will
    now not be run, you can enable it with the EnableDiskPart setting
    in xymonclient_config.xml.

    * add a dummy, ignored config item in the internal client-local
    config table so that there is always some configuration present
    (even if nothing in the server-side client-local for this host)

    We found that if there is no client-local.cfg for the host and no
    default client-local.cfg (like [powershell] or [XymonPS]), on some
    platforms there appears to be a memory leak. The fix ensures there
    is always something in the internal cache of client-config even if
    nothing is received from the server.

    * XymonAcceptUTF8 - default (0) is now to use the original ASCII
    encoding, added setting for 'pure' ASCII coding which
    strips/converts diacritic characters

    Prior to this version, by default, the client uses ASCII encoding
    to send to the server but also attempts to encode/filter diacritic
    characters. This was added in v2.20, and for some people it adds a
    large time overhead when sending data.

    It’s been changed so that the default setting of 0 acts like it
    did before v2.20 – no diacritic encoding – I’m calling this
    ‘original’ ASCII encoding. XymonAcceptUTF8 = 1 is unchanged, uses
    UTF8. XymonAcceptUTF8 = 2 is the v2.20 setting, use ASCII and
    encode/filter diacritics – I’m calling this ‘pure’ ASCII encoding.
    I don’t think this will impact on many people other than saving
    time/cpu for the default setting.

    Full changelog:

    v2.37

    * replaced WMI call to get number of processors with Windows API call

    * fixed servicecheck parentheses

    * use TLS for uploading data to xymoncgi if using http reporting
    and URL begins https

    * add milliseconds to log timestamp

    * add a dummy, ignored config item in the internal client-local
    config table so that there is always some configuration present
    (even if nothing in the server-side client-local for this host)

    * fix a couple of instances where we were using variables before
    they are assigned

    settings changes/additions:

    * XymonAcceptUTF8 - default (0) is now to use the original ASCII
    encoding, added setting for 'pure' ASCII coding which
    strips/converts diacritic characters

    * only supply diskpart data if EnableDiskPart = 1

    Zak


    This message is for the designated recipient only and may contain
    privileged, proprietary, or otherwise confidential 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. Your privacy is
    important to us. Accenture uses your personal data only in
    compliance with data protection laws. For further information on
    how Accenture processes your personal data, please see our privacy
    statement at https://www.accenture.com/us-en/privacy-policy.

    www.accenture.com <http://www.accenture.com>;


    Xymon at xymon.com  <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.xymon.com_mailman_listinfo_xymon&d=DwMD-g&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=S-aLwpx-PHBTBMIG_c2JczRC0SfuZCmsiH9Iams25FI&m=nCeHIt-8vEpIrED5Cu3dEPfxpWypoQE_ddD6QQAX9Ws&s=dlri1VGEnUrfF1SmKT2_B0vclSkFM--ZA8iIjLbfCtk&e=>;

      

Zak

From: Kris Springer <user-c2caa0a7a8d5@xymon.invalid>
Sent: Wednesday, 20 February 2019 21:49
To: Beck, Zak <user-aada0fa38bf8@xymon.invalid>; Xymon MailingList <xymon at xymon.com>
Subject: [External] Re: [Xymon] Windows XymonPSClient v2.37

So I was able to mess around and fix my issues.  Here's the specifics of my problems and resolutions.

1. The clientversion:2.37:Servername:MD5:sum line requires the : between each section.  I had tried that once before and then changed it to | because my other scripts have | instead of : and they run just fine.  But apparently the clientversion check must have :

2. When I originally downloaded the new xymonclient.ps1 from sourceforge I used wget, and it downloaded a bunch of html garbage along with the file.  So I redownloaded the file and made sure it was only the script and none of the junk.

3. After making sure the file was good, I restarted the XymonPSClient service and let it run a few cycles.  First cycle didn't produce a change since it uses the cached clientconfig info.  Second cycle it pulled the updated clientconfig info from the server, checked the xymonclient.ps1 version, downloaded the new v2.37 file, and updated correctly.  Third cycle it ran the new v2.37 xymonclient.ps1 and populated the new info in the logs that got reported to the server.

Now that I have it working on my test machine, I'm gonna see if it magically works on another box without my having to restart the service.  The whole point of this is to remotely update without having to interact with the client.  :-)  Hope this helps someone else if they run into issues.


Kris Springer


On 2/20/19 8:58 AM, Beck, Zak wrote:
Hi

The client only updates on slowscans – usually every 6 hours – one of first lines in the logs will tell which scan number you are on and which will be the next slow scan.

You can force a slow scan by stop/starting the service.

If you have waited more than 6 hours, then you have some other issue – can you check the log on a slow scan? Usually easiest to do this by stopping the service and then running the client manually in a Powershell prompt.

Cheers

Zak

From: Kris Springer <user-c2caa0a7a8d5@xymon.invalid><mailto:user-c2caa0a7a8d5@xymon.invalid>
Sent: Wednesday, 20 February 2019 15:39
To: Beck, Zak <user-aada0fa38bf8@xymon.invalid><mailto:user-aada0fa38bf8@xymon.invalid>; Xymon MailingList <xymon at xymon.com><mailto:xymon at xymon.com>
Subject: [External] Re: [Xymon] Windows XymonPSClient v2.37

This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments.

I'm trying to remotely update a v2.28 client to the latest 2.37 version by following the instructions in the XymonPSClient.doc, but the client isn't updating.  Here's what I've done.  Maybe I'm missing something.

1. Download the latest xymonclient.ps1 from github and place it in my server's scripts directory.  (This is the directory where I run other client scripts successfully)

2. Rename the xymonclient.ps1 file to xymonclient_2.37.ps1 (per the doc instructions)

3. Get the md5sum of the file

4. Add the following line to the client-local.cfg file on the server for the specific host I'm trying to update. (per the doc instructions)
clientversion:2.37:https://my.domain.com/xymon/scripts:MD5:md5sumadlkfskdkfkfdl<https://urldefense.proofpoint.com/v2/url?u=https-3A__my.domain.com_xymon_scripts-3AMD5-3Amd5sumadlkfskdkfkfdl&d=DwMD-g&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=S-aLwpx-PHBTBMIG_c2JczRC0SfuZCmsiH9Iams25FI&m=nCeHIt-8vEpIrED5Cu3dEPfxpWypoQE_ddD6QQAX9Ws&s=05m99yiMkc-55R1AKXecttl5doV-7QYCPGCbqVr5S_s&e=>;

5. Check that the xymonclient_config.xml on the client has
<clientremotecfgexec>1</clientremotecfgexec>

When I look at the logs on the client it says it sees the instruction from the server, but it doesn't perform any action.  The client version never changes.


Kris Springer


On 2/15/19 5:03 AM, Beck, Zak wrote:
Hi

I have committed v2.37 today, this has a big performance related fix and other fixes – thanks to SebA <user-4631430d620a@xymon.invalid<mailto:user-4631430d620a@xymon.invalid>> and Andy user-982f5f6d4d28@xymon.invalid<mailto:user-982f5f6d4d28@xymon.invalid> for extra work and prompting in this area.

Download from SVN<https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_p_xymon_code_HEAD_tree_sandbox_WinPSClient_&d=DwMD-g&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=S-aLwpx-PHBTBMIG_c2JczRC0SfuZCmsiH9Iams25FI&m=nCeHIt-8vEpIrED5Cu3dEPfxpWypoQE_ddD6QQAX9Ws&s=L-dhmcu_CM75-ARQ7kmDxV7wP_abxGZqOuUDmZXC-RE&e=>; (the documentation has been updated also, including uninstall instructions).

The key fixes are:

* replaced WMI call to get number of processors with Windows API call

The WMI call to get processor information was taking anything from 4-5 seconds on most of my VMs, some experience much longer waits and high CPU usage while this WMI call executed. There have also been instances where the WMI call returns incorrect data or no data. This has been replaced with a call to GetNativeSystemInfo(), which should work on 32-bit and 64-bit platforms and in testing executes in milliseconds.

* only supply diskpart data if EnableDiskPart = 1

There is a test in the client which uses ‘diskpart’ to gather information about clustering every slow scan. This is included in the data sent to Xymon, but it’s not generally displayed – you can extract it for reporting if needed. Hardly anyone uses this and for some reason for some people it is causing memory issues in the Microsoft Virtual Disk Service. Therefore by default the test will now not be run, you can enable it with the EnableDiskPart setting in xymonclient_config.xml.

* add a dummy, ignored config item in the internal client-local config table so that there is always some configuration present (even if nothing in the server-side client-local for this host)

We found that if there is no client-local.cfg for the host and no default client-local.cfg (like [powershell] or [XymonPS]), on some platforms there appears to be a memory leak. The fix ensures there is always something in the internal cache of client-config even if nothing is received from the server.

* XymonAcceptUTF8 - default (0) is now to use the original ASCII encoding, added setting for 'pure' ASCII coding which strips/converts diacritic characters

Prior to this version, by default, the client uses ASCII encoding to send to the server but also attempts to encode/filter diacritic characters. This was added in v2.20, and for some people it adds a large time overhead when sending data.

It’s been changed so that the default setting of 0 acts like it did before v2.20 – no diacritic encoding – I’m calling this ‘original’ ASCII encoding. XymonAcceptUTF8 = 1 is unchanged, uses UTF8. XymonAcceptUTF8 = 2 is the v2.20 setting, use ASCII and encode/filter diacritics – I’m calling this ‘pure’ ASCII encoding. I don’t think this will impact on many people other than saving time/cpu for the default setting.

Full changelog:

v2.37
* replaced WMI call to get number of processors with Windows API call
* fixed servicecheck parentheses
* use TLS for uploading data to xymoncgi if using http reporting and URL begins https
* add milliseconds to log timestamp
* add a dummy, ignored config item in the internal client-local config table so that there is always some configuration present (even if nothing in the server-side client-local for this host)
* fix a couple of instances where we were using variables before they are assigned

settings changes/additions:
* XymonAcceptUTF8 - default (0) is now to use the original ASCII encoding, added setting for 'pure' ASCII coding which strips/converts diacritic characters
* only supply diskpart data if EnableDiskPart = 1


Zak


This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential 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. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.