SAS-wsm is available for use with SAS 9.4 deployments

[AndyForeman]

SAS Technical Support is excited to announce that SAS Windows Services Management, or SAS-wsm, is available for use with SAS® 9.4 deployments on Microsoft Windows operating systems. This project is open source, available via SAS Software GitHub, and is free to download, modify, and contribute to.

The SAS-wsm utility offers the capabilities of the .servers scripts that are available on UNIX operating systems but it uses Microsoft PowerShell for similar functionality on Windows. This utility provides SAS Windows administrators with convenient start-up and shutdown control and status checking of SAS services on their systems.

SAS-wsm is based around a user-defined configuration file system that allows administrators to create various definitions for control over multiple deployments or varying subsets of deployment components. The configuration file defines a consistent order in which services are started and stopped, ensuring that dependencies are always available. Log file-based validation checks are automatically called on components that might take a long time to be usable after initial start-up; a complete start-up is not reported until they are truly available.

To learn more about SAS-wsm, or to obtain the utility and try it out on your system, refer to the project page on GitHub: https://github.com/sassoftware/sas-wsm

[Nigel_Pain]

This is great! Thanks Andy (and also Greg Wootton who I think might have first conceived of the idea). I'm having a bit of a think to see if it can be modified to cover services running on multiple servers, that would be quite cool.

[Nigel_Pain]

I've managed to modify the script to handle services over multiple servers. The config file is comma separated with service and server names and there's an extra array definition containing the server names as well. @AndyForeman if you want it I can send it to you to do what you wish with it. I haven't got to grips with Git I'm afraid.

[AndyForeman]

I'd certainly be interested in taking a look @Nigel_Pain , happy to implement multi-server support into the codebase if it seems viable. Curious on the method used for sure.

Without using GitHub, I might suggest you open a track with Technical Support to get it to me, or attach it to a reply on this post (don't want to have my email public on this comment thread!).

[Nigel_Pain]

Here you are @AndyForeman (or anyone else who wants it). Feel free to do what you like with it. No guarantees on how well it works, it seems to work for me but I don't have a good testing environment to try it properly.

I understand very much about not publicising your email address.

[Nigel_Pain]

Hi @AndyForeman 

I've made a few changes to my multi-server version. The background to this was that when I upgraded our servers from Windows Server 2012 R2 to Windows Server 2019 the WMI-based applets were returning "not authorised" errors when trying to connect to the remote servers. Out of interest, and partly because WMI is a deprecated technology, I thought I'd try changing them to using CIM instead of WMI. There's an interesting article about this here:

https://devblogs.microsoft.com/scripting/should-i-use-cim-or-wmi-with-windows-powershell/ 

Anyway, CIM seems to work: Get-WmiObject is replaced by Get-CimInstance, but all the parameters can stay the same. Unfortunately, you can't use the stopservice or startservice methods with CimInstance objects. Instead, you have to use the Invoke-CimMethod applet. However, this will take the CimInstance object as an InputObject. So, the following changes are made:

$status = $service.startservice()

becomes

$status = Invoke-CimMethod -InputObject $service -MethodName StartService

and

$status = $service.stopservice()

becomes

$status = Invoke-CimMethod -InputObject $service -MethodName StopService