Feature/PLAT-5837 PLAT-5871

[lmoretto]

No description provided.

[lmoretto]

@alexmaurizio please review this, but let's not merge it on our fork's master. We will sync it with upstream once it will be merged directly by Microsoft

[alexmaurizio]

This seems perfectly okay for a new deployment, LGTM.

My only doubts are about updates to running log anayltics worksapces with already ingested data AND already configured hunting queries (something that is OUTSIDE our personal scope, but on clients) and how it works for these use cases.

I think you already tested this scenario so i'm writing this for double check.

We could also ask MS on what happens with these changes (since they will need to review our code before merging and they are owner on this)

[lmoretto]

This seems perfectly okay for a new deployment, LGTM.

My only doubts are about updates to running log anayltics worksapces with already ingested data AND already configured hunting queries (something that is OUTSIDE our personal scope, but on clients) and how it works for these use cases.

I think you already tested this scenario so i'm writing this for double check.

We could also ask MS on what happens with these changes (since they will need to review our code before merging and they are owner on this)

In theory, we are simply adding a new column in the output table, the rest remains structurally unchanged.

I didn't get the chance to test an update scenario, but I'll try to do that (not that straightforward, unfortunately)

[lmoretto]

This seems perfectly okay for a new deployment, LGTM.
My only doubts are about updates to running log anayltics worksapces with already ingested data AND already configured hunting queries (something that is OUTSIDE our personal scope, but on clients) and how it works for these use cases.
I think you already tested this scenario so i'm writing this for double check.
We could also ask MS on what happens with these changes (since they will need to review our code before merging and they are owner on this)

In theory, we are simply adding a new column in the output table, the rest remains structurally unchanged.

I didn't get the chance to test an update scenario, but I'll try to do that (not that straightforward, unfortunately)

We tried a update-ish process by deploying version 3.0.3 as a custom template, connecting the connector, then deploying 3.1.0 as custom template.

Insights:

• after deploying 3.1.0, che connector UI has been properly updated. However the output table schema and log parsing didn't properly create LogData
• we then disconnected and reconnected (which triggers the deployment of internal resources) the connector, and now the table schema has been properly updated and log parsing started producing the new LogData field.

We will retry the upgrade process from the official store version. If the same experience occurs, customers will have to disconnect/reconnect, by reinserting the client credentials.