@kvprasoon it's been a while since you commented so hopefully it was safe to assume you aren't looking at this? If you are then I'm sorry for treading on your toes, but hopefully the questions below are useful. :)
If not @iSazonov could I be assigned to this please?

I've got a working implementation that retrieves the triggers, but before I submit a PR I'd like some guidance on how we should add them to the output, please.

Firstly, any outputs that aren't already properties on the ServiceController object are added as NoteProperties to the PSObject. So far, all additional outputs are just single values, triggers would need to be an array of PSObjects. Is this acceptable? I did have a look at Get-ScheduledTask which returns the triggers as an array of CimInstance objects, but I don't think that helps us here.

Each trigger has four properties: TriggerType, Subtype, Action and SpecificDataItems. (https://docs.microsoft.com/en-us/windows/win32/api/winsvc/ns-winsvc-service_trigger)

Questions:

Should we return the TriggerType as an integer or its string representation? I'm currently using the enum below to map to the string value. Another question is if we return the string value, should we trim the "SERVICE_TRIGGER_TYPE" prefix? My preference would be to return the string as defined in the docs, but I'm not sure if there is a precedent already set elsewhere.

internal enum ServiceTriggerType : byte
{
	SERVICE_TRIGGER_TYPE_CUSTOM = 20,
	SERVICE_TRIGGER_TYPE_DEVICE_INTERFACE_ARRIVAL = 1,
	SERVICE_TRIGGER_TYPE_DOMAIN_JOIN = 3,
	SERVICE_TRIGGER_TYPE_FIREWALL_PORT_EVENT = 4,
	SERVICE_TRIGGER_TYPE_GROUP_POLICY = 5,
	SERVICE_TRIGGER_TYPE_IP_ADDRESS_AVAILABILITY = 2,
	SERVICE_TRIGGER_TYPE_NETWORK_ENDPOINT = 6
}

Not so much of a question, but I think we can just return the guid for the subtype.
Same question as Q1 but for the action, should we return the integer value or string representation? Again, mapping enum below:

internal enum ServiceTriggerAction : byte
{
    SERVICE_TRIGGER_ACTION_SERVICE_START = 1,
    SERVICE_TRIGGER_ACTION_SERVICE_STOP = 2
}

Some triggers also have an array of SERVICE_TRIGGER_SPECIFIC_DATA_ITEM, however the type of data that is returned varies depending on the TriggerType. (https://docs.microsoft.com/en-us/windows/win32/api/winsvc/ns-winsvc-service_trigger_specific_data_item)

If the TriggerType is SERVICE_TRIGGER_TYPE_DEVICE_INTERFACE_ARRIVAL or SERVICE_TRIGGER_TYPE_NETWORK_ENDPOINT this is a string.
If the TriggerType is SERVICE_TRIGGER_TYPE_FIREWALL_PORT_EVENT this is a multi-string containing the port, protocol and potentially the executable path and service name.
Finally, if the TriggerType is SERVICE_TRIGGER_TYPE_CUSTOM then the data is defined by the ETW provider.

Excluding the CUSTOM TriggerType (I'm not sure what to do with this yet and I don't have a service to test), one approach is to return a custom PSObject whose properties depend on the TriggerType, for example:

SERVICE_TRIGGER_TYPE_DEVICE_INTERFACE_ARRIVAL would have a single property called "DeviceId"
SERVICE_TRIGGER_TYPE_FIREWALL_PORT_EVENT would have "Port", "Protocol", "ExecutablePath" and "ServiceName" properties.
SERVICE_TRIGGER_TYPE_NETWORK_ENDPOINT could have a "NetworkEndpoint" property.

To be honest, I don't really like this as it isn't user-friendly, especially if you're trying to script something and the output changes constantly. However I can't think of a way to standardise it. I'm open to suggestions.

Also, should we support returning the data items for TriggerType SERVICE_TRIGGER_TYPE_CUSTOM? I think the answer to this may depend on what we do with the others.

Thank You

SERVICE_TRIGGER (winsvc.h) - Win32 apps
Represents a service trigger event. This structure is used by the SERVICE_TRIGGER_INFO structure.

SERVICE_TRIGGER_SPECIFIC_DATA_ITEM (winsvc.h) - Win32 apps
Contains trigger-specific data for a service trigger event.

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions