What if instead of “wrapping” a service around it the script ran as a scheduled task every 5 minutes?

For the task properties the command line becomes something like C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

And the argument &'C:\Path_To_Client\ XymonPSClient.ps1'

Put a tick in repeat task, set the period to 5 mins and the duration to indefinably. Probably no need to save the password.

The task can be exported as an xml file for import into other systems and/or included in the distribution package.

Regards Graeme

From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of David Baldwin Sent: Wednesday, 13 November 2013 3:55 PM To: Jason Richards Pagh; xymon at xymon.com Subject: [Xymon] Re: WinPSClient - Updates?

Jason,

Thanks for the email. So it looks like the WinPSClient hasn’t been updated in a few months. I had seen a thread from quite a while ago about some issues David was running into, but can’t tell if he’s still around and willing/able to work on it.

In principle I am interested, but don't have a lot of time to work on it at present.

I’ve been able to get XymonPSClient.exe (aka SrvAny) to run powershell natively as a 64-bit executable. The only change necessary to enable this was changing the PowerShell executable to running as %windir%\sysnative\WindowsPowerShell\v1.0\powershell.exe. The sysnative portion prevents a 32-bit program (SrvAny) from being redirected to %windir%\SysWow64. (See http://msdn.microsoft.com/en-us/library/windows/desktop/aa384187(v=vs.85).aspx<http://msdn.microsoft.com/en-us/library/windows/desktop/aa384187%28v=vs.85%29.aspx>).

Thanks - I found the "sysNative" workaround a month or two ago also. Very useful for running PS scripts from BBWin since it is still 32-bit only.

I also found a better service wrapper than SrvAny, namely nssm (http://nssm.cc/). This has the ability to detect if powershell fails and restart it, which is something SrvAny lacks. It also comes in both 32-bit and 64-bit versions, so when using the latter the sysnative piece isn’t necessary. I’ve only been working at this for a day or two, so it probably needs more testing, but it looks promising.

That's an awesome improvement. Definitely a big advance :)

Is there any work (design contemplation) about how xymonclient.ps1 could handle external scripts? I assume this was just a future phase and not so much a limitation or barrier that hadn’t yet been overcome.

I'd played around with things like start-job in PS, but I hadn't worked through all of the legacy reporting mechanisms from BBNT/BBWin (e.g. writing text files into directory - that's an easy one in practice) but more to the point worked out throttling mechanisms for long-running scripts that don't exit, etc. Had also considered just running external scripts as scheduled tasks, but not had time to investigate.

All,

Apologies on not responding to this.

The existing XymonPSClient works just fine running its own scheduling. For the most part it also seems to be well behaved and not leak memory - it is fairly proactive about explicit garbage collection. On first run it gathers a number of data items from WMI on a much longer refresh cycle and reports them as part of the client report - these items are fairly slow to report and don't change much if at all. While that could be handled by saving and restoring state between runs and using a Scheduled task rather than service runner, it makes things more complicated. Also need to consider measures to prevent multiple instances running if Scheduled tasks fire up when the previous one is still running - for example doing the refresh of the long refresh cycle WMI info (maybe there's an in-built mechanism for this?).

External scripts however are much more problematic to manage scheduling for, and using scheduled tasks could be a much better way to handle them.

David.

I’m very interested on WinPSClient too. I’m planning to install it on a series of servers that we will be configuring in the next few weeks.

I second the idea of using Windows Task Scheduler.

Has there been any thought on how to enable creating extensions? It could be like what’s done in Unix, or copy what’s done in BBWin.

Thanks!

glauber

*From:*Xymon [mailto:xymon-bounces at xymon.com] *On Behalf Of *Shea, Graeme A *Sent:* Thursday, November 14, 2013 14:31 *To:* xymon at xymon.com *Subject:* Re: [Xymon] WinPSClient - Updates?

What if instead of “wrapping” a service around it the script ran as a scheduled task every 5 minutes?

For the task properties the command line becomes something like C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

And the argument &'C:\Path_To_Client\XymonPSClient.ps1'

Put a tick in repeat task, set the period to 5 mins and the duration to indefinably. Probably no need to save the password.

The task can be exported as an xml file for import into other systems and/or included in the distribution package.

Regards

Graeme

*From:*Xymon [mailto:xymon-bounces at xymon.com] *On Behalf Of *David Baldwin *Sent:* Wednesday, 13 November 2013 3:55 PM *To:* Jason Richards Pagh; xymon at xymon.com <mailto:xymon at xymon.com> *Subject:* [Xymon] Re: WinPSClient - Updates?

Jason,

Thanks for the email.

So it looks like the WinPSClient hasn’t been updated in a few
months. I had seen a thread from quite a while ago about some
issues David was running into, but can’t tell if he’s still around
and willing/able to work on it.

 

In principle I am interested, but don't have a lot of time to work on it at present.

I’ve been able to get XymonPSClient.exe (aka SrvAny) to run powershell natively as a 64-bit executable. The only change necessary to enable this was changing the PowerShell executable to running as %windir%\sysnative\WindowsPowerShell\v1.0\powershell.exe. The sysnative portion prevents a 32-bit program (SrvAny) from being redirected to %windir%\SysWow64. (See http://msdn.microsoft.com/en-us/library/windows/desktop/aa384187(v=vs.85).as... <http://msdn.microsoft.com/en-us/library/windows/desktop/aa384187%28v=vs.85%29.aspx>).

Thanks - I found the "sysNative" workaround a month or two ago also. Very useful for running PS scripts from BBWin since it is still 32-bit only.

I also found a better service wrapper than SrvAny, namely nssm (http://nssm.cc/). This has the ability to detect if powershell fails and restart it, which is something SrvAny lacks. It also comes in both 32-bit and 64-bit versions, so when using the latter the sysnative piece isn’t necessary. I’ve only been working at this for a day or two, so it probably needs more testing, but it looks promising.

That's an awesome improvement. Definitely a big advance :)

Is there any work (design contemplation) about how xymonclient.ps1 could handle external scripts? I assume this was just a future phase and not so much a limitation or barrier that hadn’t yet been overcome.

I'd played around with things like start-job in PS, but I hadn't worked through all of the legacy reporting mechanisms from BBNT/BBWin (e.g. writing text files into directory - that's an easy one in practice) but more to the point worked out throttling mechanisms for long-running scripts that don't exit, etc. Had also considered just running external scripts as scheduled tasks, but not had time to investigate.

From memory there were some other issues such as dealing with memory leaks (periodic service restart would solve that).

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 david.baldwin at ausport.gov.au <mailto:david.baldwin at ausport.gov.au> Leverrier Street Bruce ACT 2617

---

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.

---

*Important - *This email and any attachments may be confidential. If received in error, please contact us and delete all copies. Before opening or using attachments check them for viruses and defects. Regardless of any loss, damage or consequence, whether caused by the negligence of the sender or not, resulting directly or indirectly from the use of any attached files our liability is limited to resupplying any affected attachments. Any representations or opinions expressed are those of the individual sender, and not necessarily those of the Department of Education and Early Childhood Development.

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

-- 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 david.baldwin at ausport.gov.au Leverrier Street Bruce ACT 2617

I have now one such external script. It’s invoked every “x” minutes by the Windows Scheduler. It’s a Powershell script, which utilizes the xymonsend Powershell function to send status updates. It’s been running for 24 hours, and so far no problems.

The send function might be renamed to something like Send-XymonMessage, to be more comforming with Powershell standards.

g

From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Ribeiro, Glauber Sent: Friday, November 22, 2013 11:30 To: David Baldwin; xymon at xymon.com Subject: Re: [Xymon] WinPSClient - Updates?

Thanks, David!

Are you aware of any concerns that might stop me from using the current Powershell client in the real world?

(I understand that it’s pre-production and no guarantees, etc.)

glauber

From: David Baldwin [mailto:david.baldwin at ausport.gov.au] Sent: Wednesday, November 20, 2013 16:48 To: Ribeiro, Glauber; xymon at xymon.com<mailto:xymon at xymon.com> Subject: Re: [Xymon] WinPSClient - Updates?

All,

Apologies on not responding to this.

The existing XymonPSClient works just fine running its own scheduling. For the most part it also seems to be well behaved and not leak memory - it is fairly proactive about explicit garbage collection. On first run it gathers a number of data items from WMI on a much longer refresh cycle and reports them as part of the client report - these items are fairly slow to report and don't change much if at all. While that could be handled by saving and restoring state between runs and using a Scheduled task rather than service runner, it makes things more complicated. Also need to consider measures to prevent multiple instances running if Scheduled tasks fire up when the previous one is still running - for example doing the refresh of the long refresh cycle WMI info (maybe there's an in-built mechanism for this?).

External scripts however are much more problematic to manage scheduling for, and using scheduled tasks could be a much better way to handle them.

David. I’m very interested on WinPSClient too. I’m planning to install it on a series of servers that we will be configuring in the next few weeks.

I second the idea of using Windows Task Scheduler.

Has there been any thought on how to enable creating extensions? It could be like what’s done in Unix, or copy what’s done in BBWin.

Thanks!

glauber

From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Shea, Graeme A Sent: Thursday, November 14, 2013 14:31 To: xymon at xymon.com<mailto:xymon at xymon.com> Subject: Re: [Xymon] WinPSClient - Updates?

What if instead of “wrapping” a service around it the script ran as a scheduled task every 5 minutes?

For the task properties the command line becomes something like C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

And the argument &'C:\Path_To_Client\ XymonPSClient.ps1'

Put a tick in repeat task, set the period to 5 mins and the duration to indefinably. Probably no need to save the password.

The task can be exported as an xml file for import into other systems and/or included in the distribution package.

Regards Graeme

From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of David Baldwin Sent: Wednesday, 13 November 2013 3:55 PM To: Jason Richards Pagh; xymon at xymon.com<mailto:xymon at xymon.com> Subject: [Xymon] Re: WinPSClient - Updates?

Jason,

Thanks for the email. So it looks like the WinPSClient hasn’t been updated in a few months. I had seen a thread from quite a while ago about some issues David was running into, but can’t tell if he’s still around and willing/able to work on it.

In principle I am interested, but don't have a lot of time to work on it at present. I’ve been able to get XymonPSClient.exe (aka SrvAny) to run powershell natively as a 64-bit executable. The only change necessary to enable this was changing the PowerShell executable to running as %windir%\sysnative\WindowsPowerShell\v1.0\powershell.exe. The sysnative portion prevents a 32-bit program (SrvAny) from being redirected to %windir%\SysWow64. (See http://msdn.microsoft.com/en-us/library/windows/desktop/aa384187(v=vs.85).aspx<http://msdn.microsoft.com/en-us/library/windows/desktop/aa384187%28v=vs.85%29.aspx>).

Thanks - I found the "sysNative" workaround a month or two ago also. Very useful for running PS scripts from BBWin since it is still 32-bit only. I also found a better service wrapper than SrvAny, namely nssm (http://nssm.cc/). This has the ability to detect if powershell fails and restart it, which is something SrvAny lacks. It also comes in both 32-bit and 64-bit versions, so when using the latter the sysnative piece isn’t necessary. I’ve only been working at this for a day or two, so it probably needs more testing, but it looks promising.

That's an awesome improvement. Definitely a big advance :) Is there any work (design contemplation) about how xymonclient.ps1 could handle external scripts? I assume this was just a future phase and not so much a limitation or barrier that hadn’t yet been overcome.

I'd played around with things like start-job in PS, but I hadn't worked through all of the legacy reporting mechanisms from BBNT/BBWin (e.g. writing text files into directory - that's an easy one in practice) but more to the point worked out throttling mechanisms for long-running scripts that don't exit, etc. Had also considered just running external scripts as scheduled tasks, but not had time to investigate.