Various blog posts and documentation mentions that there are 3 types of CIRA: User-initiated, scheduled, and remote alerts. I understand how scheduled remote connections are set-up, you call AMT_RemoteAccessService.AddRemoteAccessPolicyRule() to make an AMT_RemoteAccessPolicyRule with a "Periodic" trigger and with details about the period into the ExtendedData field.
However, I don't understand how to trigger remote connections in response to a specific alert (the "Remote Alerts" case). An AMT_RemoteAccessPolicyRule may have its trigger value set to "Alert", but there seems to be no further way to specify exactly which alert triggers this. For example, I would like remote connections spawned whenever a specific agent presence alert is generated, and not for any other alert.
The documentation for AMT_RemoteAccessPolicyRule.ExtendedData claims that this field is only for use with "Periodic" triggers and that "For the other triggers extended data is not defined and not needed. The length and data should be zero."
I am thinking that maybe this documentation is inaccurate, and you can actually use this field to specify alert identification details for "Alert" triggers?
Hi - I think I can address your question on how to setup "which" alert will trigger a CIRA connection. Basically, you would need to set up a Watchdog alert - a very easy way to do this is via the Manageability DTK. Below are some general steps:
Go to the MP Server
- Open AMT Commander, discover system and connect to it.
- Expand system name
- Go into "Networking" -> Watchdogs; Click on "Create New Watchdog"
- Select all defaults and click on "Add"
- We now have "SampleWatchdog" - click on this Watchdog
- Create State Transition Events - Click on Add
- Uncheck "Allstates" on both columns
- Old State: Select Running
- New State: Select Expired
- Select "Log this state change to Event Log"
- Click on "Add"
- Click on "Event Log" and then "Alert Subscriptions"
- Need to register: enter IP Address 192.168.1.1
- Select for Event Filter: 15-Any Entity, Any Type, System Event........
- Click on Add
- Click on Close
- Monitor Network Alerts from Event Log
Go back to the AMT Client
- Bring up AMT Outpost
- Under the General Tab enter username and password; click connect
- Go to Watchdog Tab and click Add"
- Leave all defaults and click OK
- Check the "SampleWatchdog" Box (It will start off as expired but will go to running when checked - this will cause a couple of state transition alerts.)
I don't see how this relates to CIRA? To clarify, I know exactly what event I care about. There just appears to be no publicly documented API for telling CIRA which exact event I care about.
CIRA/ alert based triggersworks by setting up a watchdog that watches for events that send an alert to a network address.
From the "Remote Access Overview" document in the SDK:
Alert trigger - Whenever an event occurs that sends an alert to a network address, the Intel AMT device initiates an MPS connection, if there is no connection currently active. The Watchdog that is created in the steps that I sent you is what is required to "catch" the event and tell AMT to start the connection.
It is a bit more granular than that. It depends on the subscriptions to WS-Events that were originally setup. The pertinent information is in section 4.24.3 of the WS-Management Flows.pdf document that's part of the SDK.
In short, when a WS-Eventing subscription is created, you specify the filter that will determine what events will be sent (there are six possible filters). With the Intel AMT:All filter, all possible events would try to send over the network. The details of exactly what events belong to which filters is in the WSEventAndPetTableReplacement.xls file in the documents.
Getting back to the original CIRA connection question, if CIRA is configured, any event that attempts to send over the network when environment detection determines that the system is outside of the defined intranet will attempt to open a CIRA connection.
Ok. I just thought there might be potentially some scenario where someone wanted multiple different alerts sent for different event filters, and might want to distinguish between them, but that isn't a big deal.